Managing AWS accounts like a PRO – Part 1

Using multiple AWS accounts is a best practice that can help you isolate and manage business applications and data.

If you have looked at the AWS Well-Architected Framework you might have seen that having multiple accounts for an organisation can help achieve operational excellence, security, reliability, and even cost optimisation.

At fourTheorem, we have helped dozens of organisations to set up their AWS accounts properly, regardless of their level of cloud maturity. We truly believe this is such a fundamental best practice that it should be considered even by organisations that are very new to the cloud and have just opened their first AWS account.

Starting with a good multi-account foundation is something that will enforce many best practices from day 0, like, for example, not having long-lived credentials on developers’ machines. And the benefits just get greater as the company grows and the level of cloud adoption increases. It’s a practice that scales well from 1 developer to thousands of developers!

Just to get short-lived credentials, I’d say that even for personal accounts, you should consider setting up your organisation structure with multiple accounts.

But where to start?

Having to set up and manage multiple accounts might sound scary, but fear not! In this series of articles, we will guide you through the process with tons of real examples and screenshots.

In the first article (this one) we will learn how to use IAM Identity Center and AWS Organizations to create your account structure and define users, groups, and permissions. We will also see how to install and configure granted, a CLI tool that allows you to easily assume a role to interact programmatically with a given account and avoid long-lived IAM credentials.

In this first article, we will do a bit of clickops (manually creating and configuring stuff from the web console). This is a great way to start, but it’s not ideal for long-term management of your accounts, especially as soon as you want to automate the creation of resources across multiple accounts. So, in the second article of this series, we will learn how to seamlessly migrate our manual configuration to Infrastructure as Code (IaC) using an open-source tool called OrgFormation.

Let’s start by highlighting in more detail what are the advantages of having multiple AWS accounts under one organisation umbrella.

Having to deal with multiple accounts, might seem like a lot of overhead and added complexity, so why is this practice so important? Here are a few reasons.

Each AWS account operates in isolation, providing a clear boundary for resources. This isolation helps in managing security, compliance, and resource access more effectively.

Different teams or departments within an organisation can have their own AWS accounts, allowing them to manage their resources independently. This segregation enhances control and reduces the risk of accidental interference with each other’s resources.

Isolation becomes especially important for larger organisation with very different workloads. Since every account has its quotas (for instance the total number of Lambda Functions that you could be executing at any given time), having different accounts, will prevent teams from accidentally exhausting all the resources for other teams.

Isolation is also relevant from a security perspective. Security policies can be enforced at the account level, ensuring that each account adheres to the organisation’s security standards. This helps in containing security breaches and limiting their impact to specific accounts.

Finally, some compliance standards may require strict isolation of resources. By utilising multiple AWS accounts, organisations can more easily demonstrate compliance with regulations such as GDPR, HIPAA, or PCI DSS.

Distinct AWS accounts can be used to segregate environments for specific workloads. For example, you could have one or more accounts for development purposes, accounts dedicated to various stages of testing, and, finally, a production account. This kind of segregation makes it easier to experiment and test without affecting production accounts which greatly reduces the risk of disruptions to critical systems.

I already said this is my favourite benefit and the reason why I think a multi-account setup is worth it even if you are a single developer with a personal organisation that you use only for learning purposes and maybe some occasional side project.

When you set up IAM Identity Center and AWS Organisations, you can easily allow developers to get temporary programmatic credentials for a specific account and a role. This has multiple benefits.

On one side, you can stop storing persistent IAM credentials in ~/.aws/credentials. Although this is considered the default approach, it is a very bad practice! Having long-lived credentials stored in a plain text file makes it very easy for an attacker to steal them if they somehow manage to access this file. And since these credentials will last indefinitely, the attacker can quietly harvest and store them for a while until they need to do something nasty! I have seen this happening on a couple of occasions, unfortunately. 😞

💡 Note that there are secure ways to store persistent credentials. For instance, aws-vault allows you to keep credentials encrypted which makes it harder for an attacker to steal them.

Persistent IAM credentials are generally scoped to the highest level of permissions that you need (for convenience). If this is a personal account, you probably have full admin permissions. If you are a developer in a company, you probably have more limited permissions, but still open enough for you to deploy various resources. If an attacker grabs these credentials, they will generally have significant scope to grant the attacker all kinds of dangerous permissions.

With IAM Identity Center temporary credentials, you can easily define multiple roles for every account. For example, you could have an admin role (that only a few users can use occasionally), a developer role, and even a read-only role. If you need to access an account just to do some routine checks (e.g. reading some logs or viewing some dashboards), you can assume the read-only role and save yourself from accidental edits or deletions. These credentials are much harder to steal, because they generally live only in a terminal session and are not persisted to files. They also have a limited duration, which gives a potential attacker a much smaller window of time to exploit them.

By separating resources into different accounts, it becomes easier to track and manage costs (without having to rely solely on Cost Allocation tags). AWS provides tools like AWS Cost Explorer and AWS Budgets that can be utilized at the account level for cost analysis and optimization.

You could for example set specific budget alarms for specific accounts. Most likely a development environment will need to have a lower threshold than a production account.

From a financial perspective, you can still pay your monthly bill for all the accounts as if it were a single account by enabling Consolidated billing for AWS Organizations.

Before getting our hands dirty with IAM Identity Center and AWS Organizations, we will assume you have already opened an AWS account and that you also have installed the AWS CLI on your development machine.

At this point, you should be able to log in to the AWS Web console.

Note that AWS frequently updates the look and feel of the AWS Web console, but don’t worry too much if our screenshots don’t match exactly what you see in your web console. The main concepts should still be relevant and we will try to describe what’s the goal of every step so that you can complete the various tasks confidently.

At this point, we assume you have only one AWS account which we will call the “management account”. Ideally, we won’t run any workload in this account but we will use it only as the place to go when we want to manage all the other accounts in the organisation.

Log into this account and go to the IAM Identity Center service (formerly known as AWS Single Sign-on).

You should see something that looks like the screenshot below:

IAM Identity Center is not enabled by default, so we need to enable it. On the right-hand side, you should see a button saying “Enable”. Click it to start the guided process to enable IAM Identity Center.

IAM Identity Center can be enabled across the entire organisation or on a single account. We want to have an organisation to manage multiple accounts, so when presented with the option, we need to pick “Enable with AWS Organizations”.

Once you have done all of that, you should be redirected to the IAM Identity Center dashboard.

One of the things that we can do here is to customise the AWS access portal URL.

What is the AWS access portal URL?

It is a unique login URL for your organisation. It looks like this:

https://<some_custom_name>.awsapps.com/start

By default, AWS pre-assigns you a random custom name, and as such, it is not going to be very memorable.

If you want, you can click on the AWS access portal URL “EDIT” link on the right-hand side of the dashboard (under Settings summary) to provide a more memorable name and customise your access portal URL:

You’ll need to type the custom name twice and then hit “Save”.

💡 Note that you won’t be able to change this URL later, so make sure to pick a name you will want to stick to! 😉

We will use this URL in a bit, so it might be a good idea to save it in your bookmarks!

Now it’s the time to start creating new accounts and organise them in a logical hierarchical structure.

In IAM Identity Center, we can navigate to “Multi-account permissions → AWS Accounts” (from the sidebar on the left).

At this point we should see our current structure of accounts:

It should look very simple with just a root “folder” and our “management account” under it.

The problem with this section of the AWS web console is that it gives us a “read-only” view of our accounts. To be able to edit this structure we need to switch to the AWS Organizations service.

Once we get there, we can select the menu item “AWS accounts”.

This screen looks very similar to the previous one, but this time we can see a button clearly saying “Add an AWS account”.

But before we get into that, this is a good time to give a more formal definition of Accounts and OUs (Organizational Units).

An AWS account is a container for resources within the AWS cloud infrastructure. AWS accounts are typically associated with a unique email address and are used to access AWS services and resources.

An Organizational Unit (OU) is a logical grouping of AWS accounts within an organisation. OUs help in organising and managing accounts based on criteria such as teams, departments, or projects. They provide a hierarchical structure for applying policies, permissions, and controls across multiple accounts.

So, if we want to make an analogy with a file system we could say that OUs are folders while Accounts are files and we can organise them hierarchically in whichever way makes the most sense to us.

Let’s start creating some OUs and accounts then!

You can select an OU (or the Root folder) and then click on actions to create a new children OU:

You can create accounts by clicking on the orange button “Add an AWS Account”.

If you have external accounts that you want to invite (e.g. you are already running workloads there), you can also invite them into your new organisation.

If you want to create a new account, you need to provide an account name, a unique email address (the account’s owner) and an IAM role name (which is the one that the management account can use to access resources in this new account). You can also optionally add tags to an account.

The account will be created in the background (it might take a minute or two) and once ready, it will be visible in your account structure in IAM Identity Center and AWS Organizations.

At any moment in time you can organise your accounts. You can simply select an account in AWS Organizations and move it into an OU by clicking on the “Actions” button.

💡 We said that every AWS account needs to be associated with a unique email (otherwise the creation will fail in the background). If you use Gmail (or Google Workspaces) you can use an interesting trick to generate aliases of your original email: you can append a “+” and suffix to your email name, for example:

– loigetemp+aws-sandbox@gmail.com
– loigetemp+aws-production@gmail.com
– loigetemp+aws-development@gmail.com

All these emails will redirect to loigetemp@gmail.com but they will look like different emails to AWS, so you can associate them to different accounts.This technique is called plus addressing or, more generically, subadressing. It is supported by many other email providers including Microsoft and Apple.

A potential structure of accounts for a personal use case (or for a small organisation) might look like the picture below:

In this particular example we have a pretty flat structure with 4 OUs alongside our management account:

• Workloads: containing 3 accounts (Development, QA, and Production). We can deploy our applications in these 3 accounts which provide environment segregation.
• Shared: an OU which contains accounts that can host shared resources. For instance, here we have a Security account which will probably contain security-related resources.
• Sandbox: an OU that is meant to host temporary workloads. In this example, we have 2 accounts: Workshops and Experiments. In both accounts, you could provision a Lambda that removes all the CloudFormation stacks at midnight to make sure that the accounts are kept clean and every deployed resource won’t last indefinitely.
• Marketplace: it has only one account (also called 559089). This account can be used to publish resources that will be published under the marketplace or that will be published in the Serverless Application Repository (SAR). In general, this can be a place where you can publish applications that can be easily installed by other AWS users.

Of course, this is just an example.

If you are looking for a guide and other suggestions on how to organise your accounts, there’s a great guide called “Off to a great start with AWS Organizations” in the OrgFormation repository.

OrgFormation is a tool that you can use to provision OUs and accounts using infrastructure as code. This is a recommended approach, especially if you are doing this for a larger organization. But we will get to using it in the second part of this tutorial, so don’t worry too much about it right now!

Now that we have created our OUs and our Accounts structure, we are ready to configure IAM Identity Center to specify which identity source we want to use to provide access to the AWS organisation.

So, if we head back to IAM Identity Center we should see a box that looks like the one below asking us to “Confirm your identity source”.

If you are an organisation, most likely you keep all your users in something like Google Workspaces, Active Directory, Okta, or similar. AWS allows you to integrate these identity solutions with your AWS organisation, effectively providing federated access to AWS.

If we click on “Confirm identity source” we should see a prompt with 3 options:

• Identity Center Directory: An AWS solution that allows you to create Users and Groups. This is probably the best option if you don’t have already a corporate identity solution or if you are an individual managing your personal organisation. The great thing about Identity Center Directory is that it comes for free, so you won’t have to pay an additional external subscription or a fee to use it.
• Active Directory: Allows you to integrate Active Directory solutions (AD) such as Azure AD (a.k.a. Microsoft Entra ID) or AWS Managed Microsoft AD (AWS hosted version of Microsoft AD) or AD Connector.
• External Provider: Allows you to integrate an external Identity Provide (IdP) using the SAML protocol.

In this article, for simplicity, we will go ahead with Identity Center Directory.

Now, it’s time to create some groups and some users.

A group is a logical container for users. We can attach specific permissions to groups and users that are part of that group will inherit these permissions. This will become more obvious once we get into permission sets.

To create a group, select “Groups” from the sidebar in IAM Identity Center. If you click on “Create Group” button, you should see something like this:

We need to provide a group name and, optionally, a description. We can start by creating a group called “Admin”.

Now let’s go to the “Users” section to create a user and click on “Add User”:

We will be presented with a very long form but we only need to fill in the “Primary Information” section:

This means providing a username, a password, an email address, and the first name and last name of the user. You can decide to generate a first-login password upfront or let AWS send an invitation email.

The next screen will allow you to add the user to a group. Select the “Admin” group and press “Next”

You should see a review screen. If you are happy with all the settings, press “Add user” to complete the user creation process.

Now, if you decided to let AWS generate a password, you should have received an email.

If that’s the case you can click on “Accept Invitation”. If not go to your AWS access portal URL and insert your newly created username and your first login password.

At this point, AWS will ask you to set up a new password for this account:

Once you have selected a password, you’ll be prompted to log in again using your new password (I know it’s a bit annoying but as a user you have to do this once!).

Now, the last step of the user creation is to decide what to do about Multi-Factor Authentication (MFA). AWS, by default, forces you to set up MFA. You can disable that at the organisation level, but why should you? It’s a good default that provides extra security to your AWS organisation for free, keep it!

When it comes to MFA, you currently have 3 options: Authenticator App, Security Key or Built-in Authenticator. Pick and configure your preferred method.

When that is done you should land on a page that looks like this:

So we should only see a message that says “You do not have any applications”. Bummer, right?!

But it makes sense, we haven’t told AWS who can access which accounts, so right now we can’t access any account… Let’s fix that!

To fix our access problem, we need to create permission sets!

A permission set refers to a collection of permissions that define what actions a user, group, or role can perform on AWS resources. It’s basically a collection of one or more IAM policies. Permission sets simplify the assignment of AWS account access for users and groups in your organization. For example, you can create a Database Admin permission set that includes policies for administering AWS RDS, DynamoDB, and Aurora services, and use that single permission set to grant access to a list of target AWS accounts within your AWS Organization for your database administrators

We can easily create predefined permission sets, for instance, AdministratorAccess and ReadOnlyAccess:

If you need more fine-grained control you can also create a Custom permission set. If you go down that path you can create a bundle where you can combine AWS-managed policies, customer-managed policies, inline policies, and permissions boundaries. For now, we will stick with the predefined permission set.

Let’s create an AdministratorAccess predefined permission set.

Next you can give the permission set a custom name and change the session duration:

For instance, you can set the session duration to 4 hours, which means that once a user logs in with this particular permission set, their session will last that long.

💡 That optional Relay state field might seem a bit cryptic. So, if you are wondering what it is all about, you can think of it as an option that allows you to provide a custom target URL where the user is sent after the login. A good use case could be if, for example, you are defining a permission set that should allow access only to files in S3. In that case, it might be nice to specify the S3 web dashboard URL (`https://s3.console.aws.amazon.com/s3/`)  as the Relay state. This way a user logging in with this permission set will be automatically redirected to S3 rather than seeing the default welcome dashboard. You would be saving that user an extra hop!

Once you are done with the AdministratorAccess permission set, you can repeat the process and create a ReadOnlyAccess permission set too.

Now that we have permission sets, we can assign them to different groups and accounts:

Let’s go to Multi-account permissions → AWS accounts and select all the accounts. Then click on “Assign users or groups”:

In the next section we need to select which groups are affected: We can select “Admin”:

Finally, we have to select which permission sets we want to make available to all the users who have the “Admin” group. We can select both AdministratorAccess and ReadOnlyAccess:

The last step is a usual review screen where we need to confirm creation.

Depending on the number of accounts and permissions sets, this might take a bit to complete. AWS will show a nice progress bar to see what’s the status!

💡 Under the hood, when Permission Sets are assigned, SSO creates Roles in each account. If you access any of your accounts and list your roles, you should see roles that start with the name AWSReservedSSO_.

When everything is done we can go back to our start URL and log in again! This time we should see something like this:

This shows the list of all the accounts we have access to. If we click on one account (e.g. Experiments) we see all the permission sets in that account and links to jump into the AWS management console with that particular set of permissions:

You can click on the Management Console link to access the specific account with the selected permission set. Doing this will automatically log you into a new session, so if you have other sessions of the web console active in the same browser, those will be invalidated.

Alternatively, If you just need to grab CLI credentials for some quick n’ dirty automation, you can click on “Command line or programmatic access” which will provide you with some temporary credentials that you can copy paste into your terminal.

Needless to say copy-pasting credentials is not ideal… and, of course, there’s a better way!

The AWS CLI has some functionality to interact with IAM Identity Center through the aws sso subcommand, but it isn’t the most complete and ergonomic and it still requires a lot of manual setup.

Our goal is to be able to easily log in and assume one of the roles we have access to, so that we can programmatically interact with one of the accounts at our disposal. All of this from the comfort of our lovely CLI and without having to copy-paste credentials here and there!

A great tool that makes this very easy is granted.

You can install granted in your platform by following the official instructions.

Once you have installed granted you can run the following command:

granted sso login --sso-region eu-west-1 --sso-start-url https://loigetemp.awsapps.com/start

Make sure to replace the region with the actual region you used when you enabled IAM Identity Center and to provide your correct AWS access portal URL.

Running this should open your browser and show a page that looks like this.

You can confirm this request and allow granted to access your AWS credentials.

Now your current CLI session is logged in.

You can now populate your ~/.aws/config file with all the accounts and roles you have access to by running the following command:

granted sso populate --sso-region eu-west-1 https://loigetemp.awsapps.com/start

Once again, make sure to use the correct region and the correct AWS access portal URL.

Once this is done, you can check the content of your ~/.aws/config file to see what was generated.

💡 If you want to do this operation for multiple organisations, keep in mind that you can specify a --prefix option to avoid conflicts in the profile names. For example:

granted sso populate --prefix loigetemp_ --sso-region eu-west-1 https://loigetemp.awsapps.com/start

At this point, if you want to assume a specific role, for example Experiments/AdministratorAccess, you can run:

assume Experiments/AdministratorAccess

Congratulations! Just like that, your current session is now running with credentials for this specific account!

Do you need proof? Try running:

aws sts get-caller-identity

💡 You can install CLI completion with granted completion. And if you don’t remember the name of your specific profiles, you can just run assume and it will interactively let you pick one of your available profiles.

You can also interactively use the assume command. If you just run assume it will provide a list of all the permission sets available and you can pick one interactively.

granted is not the only tool that can simplify getting credentials interactively. Other interesting tools offer similar capabilities. The most well-known ones are:

– aws-sso-util by Ben Kehoe
– Leapp by Noovolari
– Cloud Glance

The last 2 offer a visual UI, so they might be great alternatives if you are looking for a more visual approach.

This brings us to the end of this article. In this tutorial, we have learned

• Why you should seriously consider investing in organising your accounts into an organization (regardless of the size of your company and your level of cloud maturity)
• What are the IAM Identity Center and the AWS Organizations service
• How to use them to create and organise AWS accounts and Organizational Units (OUs)
• How to manage users, groups, and permissions sets to allow access to the various accounts in the organisation
• How to use granted to easily obtain short-lived programmatic credentials that you can use for automation

If you want to learn how to better manage your accounts using Infrastructure as Code (with OrgFormation) stay tuned for the second article in this series.

Meanwhile, you can deep dive into the topic of AWS accounts and learn some best practices directly from AWS thanks to their whitepaper: Organizing Your AWS Environment Using Multiple Accounts.

Bye! 👋

Thanks to Stella Samuel, Conor Maher, Eoin Shanaghy, and Laura Quinn for thoroughly reviewing this article and providing great suggestions!