Artificial Intelligence

AWS Cross-Account Roles and Consolidated Billing

Amazon Web Service recently introduced support for cross-account ro


Amazon Web Service recently introduced support for cross-account roles. What this now means, is that you can use one IAM account to access multiple AWS accounts. For the Metal Toad Managed Services team, this means less logins to keep track of, resulting in higher security for our Custom Cloud clients, as well as a great level of convenience for our Cloud Engineers when they need to switch to the AWS Console for a different client. We also use Consolidated Billing to have our main AWS account receive all the charges for sub-accounts, having each client split into sub accounts translates to higher accuracy, and faster turn-around, on invoicing. One further advantage, we don't want to tie our clients to our main account, so having each in their own account means that if they decide Metal Toad is not going to be their Managed Service provider, we can just hand the account over with no complicated or expensive migration needed.

Setting all this up is much less painful than I imagined. Here's how!

Set up Consolidated Billing

  1. Sign up for a new AWS account.
    • https://portal.aws.amazon.com/gp/aws/developer/registration/index.html
    • Even though we will be using Consolidated Billing, you will need to supply a credit card for billing while setting up the account.
    • Each AWS account does require it's own unique email address for the root credentials. At Metal Toad we have an email group set up for our Amazon accounts, and take advantage of GMail's use of the '+' character in an address. So, an email like 'awsaccounts+client1@gmail-domain.com' will actually result in an email going straight to the 'awsaccounts' mailbox. Using this method, we can make sure that any important account notices are sent to the appropriate team.
  2. Sign in to your main AWS account, and head to 'Billing and Cost Management'
  3. On the Consolidated Billing page, use 'Send a Request', to send an invite to the email address of the new AWS Account.
    • That address will receive a message and just need to log in and accept to have the bill sent to your main AWS Account, just log in and 'Accept Request'.
    • The Consolidated Billing page in your new account should now show that the account is linked.
Set up Roles
  1. Sign in to the new AWS Account, and go to Roles page in IAM home. 
  2. Create a new 'Role for Cross-Account Access', and select the option to 'Provide access between AWS accounts you own'.
  3. On the 'Establish Trust' Step, you will need the 12-digit account number for your main AWS Account to create the role. We also chose to require the users have MFA on their IAM account.
  4. Choose what level of permissions to give this Role.
    • At this point, we are setting up a brand new client, so we chose to first create a full-access administrator role, and will create a role for our Cloud Engineers and on-call support staff as we build out the customer's environment. You can also upload a custom policy if the pre-built options do not fit with your use-case.
  5. Save the link!
    • The info is easily found, but this is the simplest method to grant users access to the new account.
  6. Log out of the new AWS Account, and back into your normal IAM account, then use the link to switch roles.
    • The drop-down under your username will retain the last 5 roles you used. We suggest saving the 'Switch Role' links in a shared password management tool, and granting access to them as needed for your teams.

A note about security

Metal Toad uses a physically secured MFA token for our root account credentials. This prohibits even a compromised password from giving unauthorized access to our AWS account. However, managing a physical key for each client account would quickly become burdensome. Another option would be to use a Virtual MFA device for root credentials, and then physically secure that device (something like an iPod Touch with Google Authenticator, stored in a safe). It is fairly uncommon for us to need to use the root credentials on any account, since full-access IAM users can do almost anything to an account. Because of the difficulties with MFA, we have chosen to use throw-away passwords for the new accounts. As long as we retain control of the email address used to establish the account, we can reset the password if the need arises, but that is truly a rare occurrence. Here is a blog post which helped us shape this decision : http://alestic.com/2014/09/aws-root-password

Similar posts

Get notified on new marketing insights

Be the first to know about new B2B SaaS Marketing insights to build or refine your marketing function with the tools and knowledge of today’s industry.