iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
😸

Escape Login Hell: Switch AWS Accounts Instantly with Switch Role

に公開
  • Note: This page contains promotional content
    [What this article covers]
  1. Switch Role allows you to move to another account without logging out.
  2. You only need to remember "one" password to manage 10 AWS environments.
  3. The mechanism is exactly "AssumeRole".

[Addendum]
The "diagrams" in this article have received a great response for being easy to understand!
If you want to see diagrams for other services as well, please check out the following book that illustrates major AWS services!
(A partial free preview is currently available 👇)

https://zenn.dev/miyaco_log/books/d26a6fe78b33e9

Introduction: How many Chrome tabs do you have open?

"Logging in because I want to see S3 in the development environment." "Oh, I need to check CloudWatch in production too. Log out once, then log in with the production ID..." "Open an incognito window and log in with a different ID..."

That work is a waste of your life.

AWS has a killer feature called "Switch Role." With this, you can jump between accounts like a ninja with just one click.

In my previous article, I wrote that "pros don't use IAM users," and this is the "browser edition" of that topic.

1. Stop carrying a "clinking bunch of keys"

Are those of you with many accounts in this situation?

  • ID/password for Account A
  • ID/password for Account B
  • ID/password for Account C...

This is like carrying around a clinking bunch of different keys for every room. It's hard to manage, and if even one is leaked, you're in trouble.

When you use Switch Role, it looks like this:

ID/password for the management account (that's it!)

  • Of course, be sure to set up MFA (Multi-Factor Authentication) for this single account.
  • It is a best practice to keep the permissions of this account itself to a minimum and always perform work by switching to a role.

You log in with a single "master key (IAM user)" and then "transform" to enter the permitted rooms (other accounts).

▼ [Diagram] Clinking keys vs. Switch Role

2. The Mechanism is Exactly "AssumeRole"

For those who clicked when they heard "transformation"—impressive. This is a feature that AWS has made available with a single button on the Management Console, based on the "AssumeRole (putting on a hat)" command operation explained in the previous article.
https://zenn.dev/miyaco_log/articles/ebec1c1f64c046

  • Login: Enter with your IAM user.
  • Switch: Press "Switch Role" from the top-right menu.
  • Behind the scenes: AWS automatically retrieves a "temporary key" from STS and overwrites the browser's permissions.

What it's doing is the same as the CLI (the black screen). You're just swapping your "I am the administrator of the development account" hat (role) for a production account hat.

3. The Key to Configuration is "Trust Relationship"

To achieve this, the "Target account (destination)" must permit the "Source account (origin)."

This is the "Trust Relationship."

  • The development environment's (destination) perspective: "Basically no one is allowed in, but only 'Tanaka from the management account (Source)' is allowed to assume this administrator role."

If you forget this setting, you'll be turned away at the door with "Invalid permission" the moment you try to switch.

▼ [Diagram] Concept of Trust Relationship

4. "Color Settings" to Prevent Accidents

Switch Role has an unassuming yet powerful feature: the ability to change the theme color for each account.

  • Production environment: <span style="color:red">Red</span>
  • Development environment: <span style="color:green">Green</span>
  • Staging/Verification environment: <span style="color:blue">Blue</span>

By setting this up, the color of the header bar at the top of the screen changes the moment you switch. Since you can visually see that "you are currently in production," it helps prevent the most terrifying accidents for an engineer, such as "deleting a database thinking it was the development environment, only to realize it was actually production."

Absolutely set the production environment to "Red." This is a lesson learned from the blood of our predecessors.

Conclusion: Centralizing ID Management

What I introduced this time is "IAM Switch Role," but as a company's scale grows, a more advanced service called "IAM Identity Center (formerly AWS SSO)" is used.

However, the basic concept remains the same: "There is only one user (yourself). You perform work by borrowing permissions (roles)."

First, try setting up "Switch Role" in your personal AWS accounts or with small teams to free yourself from tab hell!

📚 For those who want to avoid accidents in AWS "account management"

"I'm afraid of writing Switch Role settings in JSON." "What is IAM Identity Center exactly?"

For those who want to learn more about account management best practices, I recommend this book.

▼ AWS no Usui Hon II: Basic Theory of Account Security
https://amzn.to/4jLE2OE

📕 [Announcement] Why not master AWS with "visuals"?

If you found the diagrams in this article interesting, please take a look at my own book as well.

In the book, I explain major AWS services in the same style as this article, using a diagram-heavy approach that minimizes technical jargon.

It's the perfect book for someone who says, "I'm not good at reading lots of text, but I want to grasp the big picture of AWS quickly."

▼ AWS Illustrated Notes - Understand through Pictures (Partial free preview available)
https://zenn.dev/miyaco_log/books/d26a6fe78b33e9

Discussion