Terraform With AWS AssumeRole

DZone 's Guide to

Terraform With AWS AssumeRole

Learn about how to set up different AWS accounts for different environments in software development and advantages of this practice.

· DevOps Zone ·
Free Resource

Using different AWS accounts for different environments is a best practice so that we can have complete isolation for all the environments.

Image title

In the above diagram from the segment.io blog, an Ops AWS account is the entry point for rest of the AWS accounts. This means we don't need to have users on Dev, Staging, and Prod AWS accounts; instead, we can use AWS STS and AssumeRole to bootstrap/access AWS services.


By using separate AWS accounts for different environments, we achieve

  1. Resource separation and isolation,
  2. Centralized access location,
  3. And much more.


We need 4 AWS accounts. Make sure to enable MFA for the root accounts.

Note: We can set this up with 2 AWS accounts, but in this post, we are considering 4 AWS accounts.

Let's give names to the 4 AWS accounts we will refer to in the post.

  1. Ops [Jump AWS account, or I call it, a Bastion AWS account]
  2. Dev AWS account
  3. Stage AWS account
  4. Prod AWS account

The ops account serves as the jump point and centralized login. Everyone in the organization can have an IAM account for it. The other environments have a set of IAM roles to switch between them. This means there’s only ever one login point for our admin accounts and a single place to restrict access.

As an example, Anay might have access to all three environments, but Abhi can only access Dev. They both login through the ops account.

Instead of having complex IAM settings to restrict access, we can easily lock down users by environment and group them by role. Using each account from the interface is as simple as switching the currently active role.

As soon as we get AWS accounts, we need to perform the steps below:

  1. Create IAM users in an Ops AWS account, e.g. Anay, Abhi, etc.
  2. Create roles in all 3 (Dev, Stage, and Prod) AWS accounts with a policy attached to them, or make them a part of a group with certain AWS access resources.
  3. While creating a role, make sure to add a trust relation between the Ops and Dev, Ops and Stage, and Ops and Prod AWS accounts.
automation, aws, config management, devops, provisioning, terraform, tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}