AWS Login

Before we get started, let’s review some vocabulary. I’m going to be talking about users accessing an AWS account and a lot of these terms can sound interchangeable, but knowing the difference is key when discussing user access:

• Account: An AWS account. This is the place where your infrastructure lives. You login, you click around in the console, you are accessing the AWS account.
• User: A human being who needs to do stuff in an account, like spin up a database or change a configuration.
• Role: This is a machine user. Within an AWS account you can create roles to perform actions on your behalf: a lambda function that needs access to an S3 bucket, for example. You grant permissions to that role in order to access that bucket.
• Permissions: A specific ability given to a user or a role. It generally will sound like a verb. “Create a database instance” and “execute a lambda function” are two examples of permissions.
• IAM: Identity and Access Management. The tool that allows you to create users, roles and assign them permissions.
• Organization: An AWS construct that contains one or more accounts.

Background

One of my clients had just completed an acquisition. This client previously had one AWS account; now, they had two. I was tasked with granting users CLI access to that newly acquired  AWS account. I am a fervent believer in the principle of least privilege. Whether it’s a human user or machine role in question, they should only have the permissions needed to carry out explicit actions. 

However, I had several constraints that didn’t allow me to use the most common methods of granting access. Past-me would've been thrilled to find a blog post explaining all of this, so let’s review the issues I was up against, and my eventual solution.

The usual options—and why they didn't fit

Static IAM access keys

This is the option everyone reaches for because it works everywhere.

It also leaves a long-lived secret sitting on someone's laptop. Probably in plaintext, right there in a location everyone knows, /Users/<username>/.aws. Now you own the lifecycle: rotation, revocation, replacing keys when someone changes machines, and making sure it never ends up in a Git repository.

Can you do it safely? Absolutely. Well...kinda.

Would I choose it in 2026 if I had another option? Probably not.

IAM Identity Center (AWS SSO)

For most organizations, this is the answer I'd recommend.

Centralized user management, short-lived credentials, permission sets, and aws sso login is a genuinely pleasant CLI experience. aws sso login and you're off to the races.

However, Identity Center requires an AWS Organization.

If your account is standalone, AWS will quietly create a brand-new Organization when you enable Identity Center. Most of the time, that's totally fine. 

This wasn't 'most of the time.'

After the acquisition was complete, the idea was this account would eventually become part of an existing Organization, and AWS doesn't let you merge Organizations together. Turning on the Identity Center today would create cleanup work tomorrow.

SAML federation with your own Identity Provider

If you're already using Google Workspace, Okta, Microsoft Entra ID, or another identity provider, you can federate directly into IAM roles without using Identity Center at all.

This is a solid long-term architecture.

It's also more work than I wanted for a request late on Wednesday afternoon that basically boiled down to, "Can you get two developers CLI access by Thursday?" 

AWS CloudShell

CloudShell deserves more credit than it gets.

It's already there. No setup. No access keys. No credentials touching developer laptops.

The downside is that it splits your workflow. You write Terraform locally, then jump into a browser tab to run terraform plan and terraform apply.

That's perfectly reasonable for a few weeks.

It's not where I'd choose to live.

Enter aws login

Released in November 2025, aws login lets the AWS CLI authenticate using the same browser session you already use for the AWS Console. No IAM Identity Center. No access keys. No SAML setup.

Run the command and your browser opens to AWS. Pick an existing console session (or sign into a new one), approve the request, and the CLI caches temporary credentials locally.

Those credentials refresh automatically every fifteen minutes for up to twelve hours before you need to authenticate again.

No long-lived secrets ever touch your disk.

One subtle point that's worth calling out: this doesn't replace IAM. You're still using the exact same IAM user or federated identity with the exact same permissions. The only thing that's changing is how the CLI gets temporary credentials.

The experience ends up feeling remarkably similar to aws sso login, except without needing Identity Center in the first place; I’m a little surprised this didn't exist years ago.

Setting it up

The whole process took me less than five minutes.

1. Update the AWS CLI

You need AWS CLI version 2.32.0 or later.

aws --version

If you're running an older version, grab the latest installer from AWS.

2. Attach the required IAM policy

Attach the SignInLocalDevelopmentAccess managed policy to each IAM user, alongside whatever policies grant their normal permissions.

Root users don't need this policy.

(I'd also argue they shouldn't be your daily development identity, but that's a different blog post.)

3. Remove any old access keys

This is the step that's easiest to miss.

If you've previously configured an access key for this profile, remove it from ~/.aws/ credentials.

The CLI will happily prefer those static credentials over your shiny new login session, which eventually leads to confusing ExpiredToken errors.

If things start behaving strangely, this is the first place I'd look.

4. Log in

aws login

The first time you run it, AWS may ask for a default region.

After that, your browser opens, you pick your console session, click Allow, and you're done.

Updated profile default to use arn:aws:sts::123456789012:assumed-role/my-role/my-session credentials.

For a named profile:

aws login --profile my-dev-profile

5. Verify it worked

aws sts get-caller-identity

You should see the ARN for your IAM identity.

If you're curious where the CLI actually found your credentials, run:

aws configure list

The TYPE column should read:

login

If it says anything else, odds are an older credential source is taking precedence.

6. Logging out

Sessions last up to twelve hours (or whatever maximum session duration your IAM identity allows).

When you're done, either let the session expire naturally or run:

aws logout

to clear the cached credentials immediately.

Working over SSH?

If you're on a headless machine with no local browser, use:

aws login --remote

AWS gives you a URL to open on another device along with an authorization code to paste back into your terminal.

When this isn't the right tool

I'm not arguing that aws login replaces IAM Identity Center.

If you're managing dozens of engineers across multiple AWS accounts, Identity Center is still the better long-term investment. Centralized permission sets and group management are absolutely worth having.

But that's not the problem I was trying to solve.

I had one standalone account, a couple of engineers who needed CLI access, and a deadline.

aws login solved that problem in about five minutes without introducing long-lived access keys or standing up infrastructure I knew I'd eventually have to undo.

I suspect it's going to become my default recommendation for exactly this kind of consulting engagement.

More importantly, it removes one more excuse for handing out long-lived IAM access keys.

I'll take that trade every time.