How to Log In to AWS, Azure, and Google Cloud from the Command Line

How to Log In to AWS, Azure, and Google Cloud from the Command Line

Most cloud work starts with a simple question: am I logged in to the right cloud account, subscription, project, and region? This becomes even more important when you work across multiple environments such as commercial cloud, government cloud, development, staging, and production.

This article shows a practical command-line login flow for AWS, Microsoft Azure, and Google Cloud. The commands use placeholders so you can adapt them to your own organization without exposing account IDs, subscription IDs, usernames, SSO endpoints, or private profile names.

Before You Start

• Install the cloud CLI you need: AWS CLI, Azure CLI, or Google Cloud CLI.
• Confirm your organization’s authentication method, such as SSO, SAML, MFA, service principal, managed identity, or federated identity.
• Know which account, subscription, project, and region you are supposed to use.
• Avoid storing passwords, access keys, subscription IDs, tenant IDs, or internal SSO URLs in public notes or articles.
• After login, always run a small read-only command to confirm you are in the expected environment.

AWS Login

In AWS, the most common local workflow is to use named profiles. A profile keeps credentials and configuration separate for each account or environment. You can select a profile with the AWS_PROFILE environment variable or with the --profile option.

export AWS_PROFILE=my-profile

If your organization uses SAML-based SSO through a tool such as saml2aws, the login flow usually looks like this:

export AWS_PROFILE=my-profile
saml2aws login --force -a my-profile

After login, run a read-only AWS command to confirm access. Listing S3 buckets or describing VPCs is often enough to verify that your credentials, account, and region are working.

aws sts get-caller-identity
aws s3 ls
aws ec2 describe-vpcs --query "Vpcs[].{Name: Tags[?Key=='Name'].Value | [0], CIDR: CidrBlock}" --output table

AWS Commercial and GovCloud Profiles

If you work with both AWS commercial regions and AWS GovCloud regions, keep separate profiles. This reduces the chance of running a command against the wrong account or partition.

# Commercial AWS example
export AWS_PROFILE=my-commercial-profile
saml2aws login --force -a my-commercial-profile
aws sts get-caller-identity
aws s3 ls
aws ec2 describe-vpcs --region us-east-1 --output table

# GovCloud AWS example
export AWS_PROFILE=my-govcloud-profile
saml2aws login --force -a my-govcloud-profile
aws sts get-caller-identity
aws s3 ls
aws ec2 describe-vpcs --region us-gov-west-1 --output table

Use regions that match your environment. For example, a commercial workload may use a region such as us-east-1 or ca-central-1, while a GovCloud workload may use us-gov-west-1 or us-gov-east-1.

Azure Login

Azure login has two important parts: selecting the cloud environment and selecting the subscription. Azure public cloud and Azure Government are different cloud environments, so set the active cloud before choosing the subscription.

# Azure public cloud
az cloud set --name AzureCloud
az login
az account set --subscription my-subscription
az account show --output table
az network vnet list --output table

For Azure Government, switch the Azure CLI cloud first, then log in and select the subscription.

# Azure Government
az cloud set --name AzureUSGovernment
az login
az account set --subscription my-government-subscription
az account show --output table
az network vnet list --output table

If you use automation instead of an interactive shell, your organization may provide a service principal or managed identity. Do not place client secrets in article text, scripts, or shared notes. Use a secure secret store or your CI/CD platform’s protected variables.

# Service principal example
az login --service-principal --username my-app-id --password my-client-secret --tenant my-tenant-id
az account set --subscription my-subscription

# Managed identity example, usually from an Azure resource
az login --identity

Google Cloud Login

Google Cloud uses the gcloud CLI. For normal command-line administration, log in with your user account and set the active project.

gcloud auth login
gcloud config set project my-project-id
gcloud config list
gcloud compute networks list

For local application development, you may also need Application Default Credentials. This is separate from the login used by regular gcloud commands. Client libraries often use Application Default Credentials when running code from your laptop.

gcloud auth application-default login
gcloud auth application-default print-access-token

If your organization uses federated identity or service account impersonation, follow the organization-approved login configuration. A common pattern is to authenticate as a user first, then impersonate a service account for specific commands.

gcloud auth login
gcloud config set project my-project-id
gcloud compute instances list --impersonate-service-account=my-service-account@my-project-id.iam.gserviceaccount.com

Recommended Verification Commands

After logging in, do not immediately run write or delete commands. First confirm the active identity and target environment.

• AWS: Use aws sts get-caller-identity to confirm the active AWS account and role.
• AWS: Use aws ec2 describe-vpcs --output table to confirm network visibility in the selected region.
• Azure: Use az account show --output table to confirm the active subscription and tenant.
• Azure: Use az network vnet list --output table to confirm network visibility.
• Google Cloud: Use gcloud config list to confirm the active project and account.
• Google Cloud: Use gcloud compute networks list to confirm network visibility.

Common Mistakes to Avoid

• Using the right credentials against the wrong account, subscription, project, or region.
• Forgetting to switch from Azure public cloud to Azure Government before login.
• Using an AWS profile from a previous terminal session without checking AWS_PROFILE.
• Assuming gcloud auth login also configures Application Default Credentials for local application code.
• Copying real subscription IDs, internal SSO URLs, usernames, access keys, or tokens into documentation.
• Running write commands before confirming the active environment with read-only commands.

Simple Multi-Cloud Login Checklist

1. Open a new terminal.
2. Select the correct cloud environment.
3. Log in using the approved identity method.
4. Select the right account, subscription, project, profile, and region.
5. Run a read-only identity command.
6. Run a read-only network or resource listing command.
7. Continue only after the output matches the expected environment.

Final Thought

Cloud login is not just an authentication step. It is also an environment safety check. When you work across AWS, Azure, and Google Cloud, a small habit of confirming identity, account, project, subscription, and region can prevent expensive mistakes.