AWS accounts and access


For information on how permissions are granted within accounts see the IAM section of the AWS Resources page.


There are currently four AWS accounts we use:

  • main: the main account for globally utilised AWS infrastructure

  • development: used for local development and the preview environment

  • production: staging and production environments

  • backups: s3 bucket containing nightly db backups

The login email addresses for the root users of these accounts are listed in the credentials repo in the logins.enc file. In general, and following best practices, these root users are never normally used. As such, we don’t store the passwords for them. If you need to login as a root user you should trigger a password reset. The MFA codes for the accounts are distributed among various team members.


The main account is used for creating objects that are not direct attributes of an environment.

For example our Jenkins EC2 instance is environmentally agnostic because it has jobs that operate on preview, jobs that operate on staging and production, and jobs that operate freely of any DM environment. Our AWS users are actually environmentally agnostic too. They should be able to access the different environments. But they are not tied to one or the other.

As well as the Jenkins EC2 and our aws users, other AWS objects we create in the main account are:

  • SOPS AWS KMS keys (for decrypting the credentials in the credentials repo)

  • Route53 DNS apex records for the DNS zone

Development and Production

The Development account houses the infrastructure related to the preview environment of Digital Marketplace.

The Production account houses the infrastructure related to the staging and production environment of Digital Marketplace.

These include; Route53 DNS records for subdomains (e.g. www), S3 buckets, dedicated users for handling logging, cloudwatch log groups, and IAM policies that allow users from the main account to operate on objects in the Development and Production accounts.


The backups account houses two S3 buckets that contain encrypted and compressed copies of our database. For more on how they get there see the backups section of the manual.

A separate account is necessary because it is impossible to have MFA delete and a lifecycle deletion policy on the same bucket. To get around this we created an entirely new account protected by MFA, containing a bucket with a lifecycle deletion policy.

To access the backups account, for example to run Terraform, you will need to reset the root password and generate IAM credentials. Before doing this notify #cyber-security-help as they will receive an alert about the password reset.

AWS Console Access

All users have access to the main AWS account. Using the AWS console is IP restricted (GDS office IPS) and MFA is mandatory. Other accounts can be accessed by switching roles.

Logging in for the first time

All passwords have to comply with the following rules:

  • at least 12 characters long

  • contains at least one uppercase letter

  • contains at least one lowercase letter

  • contains at least one number

You can set up MFA the following way:

  • IAM -> Users -> [your user] -> Security credentials tab -> Assigned MFA device -> edit

  • After adding the MFA device you need to log out and log in again to have access to the services you are allowed to manage

Switching roles (to access other accounts)

You can switch roles by clicking on the top right on the <username>@account menu and choosing the ‘Switch Role’ action. You’ll also find the last several roles you used in there.

Available roles:

If needed you can construct a switch role url in the following format:<account_id_number>&roleName=<role_name>&displayName=<text_to_display>

To switch back to your original user click on the coloured role button on the top right and choose ‘Back to <username>’.

Programmatic access

Generating access keys

You can generate access key the following way:

  • IAM -> Users -> [your user] -> Security credentials tab -> Create access key

Storing your access keys

For local use it’s recommend to save your keys to ~/.aws/credentials in the following format:


Default credentials give you the permissions to use S3 development bucket when running apps locally and allow you to switch to different roles depending on your user groups.

Available roles

From AWS documentation on IAM roles:

An IAM role is similar to a user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have any credentials (password or access keys) associated with it. Instead, if a user is assigned to a role, access keys are created dynamically and provided to the user.

Roles allow you to switch between different AWS accounts. 12-digit account number in the role_arn is the target AWS account number the role is defined on.

Account name

Account number









If you need to switch to a different role you can define additional profiles in ~/.aws/config.

SOPS credentials access

This role has to be used for decrypting files in the digitalmarketplace-credentials repository.

[profile sops]
source_profile = default
mfa_serial = arn:aws:iam::398263320410:mfa/<IAM username>
role_arn = arn:aws:iam::398263320410:role/sops-credentials-access


These roles are needed to run Terraform or CloudFormation scripts against main, development (preview) and production (staging and production) accounts.

[profile development-infrastructure]
source_profile = default
mfa_serial = arn:aws:iam::398263320410:mfa/<IAM username>
role_arn = arn:aws:iam::381494870249:role/infrastructure

[profile production-infrastructure]
source_profile = default
mfa_serial = arn:aws:iam::398263320410:mfa/<IAM username>
role_arn = arn:aws:iam::050019655025:role/infrastructure

[profile main-infrastructure]
source_profile = default
mfa_serial = arn:aws:iam::398263320410:mfa/<IAM username>
role_arn = arn:aws:iam::398263320410:role/infrastructure

Using profiles

You may, and likely will, have several sets of AWS credentials that you use for different tasks.

  • Your sops credentials allow you to decrypt the files in the digitalmarketplace-credentials repo for example

  • Using the <ENVIRONMENT>-infrastructure roles will allow you to run terraform (see above)

Profiles are a way of grouping credentials and referring to them by name.

When using profiles you only need to set the AWS_PROFILE environment variable for your command/ applications:

export AWS_PROFILE=somerole

Some of the tools we use don’t have built-in support for assuming roles, so you need to provide them with temporary credentials by prefixing the command with aws-auth:

aws-auth <command>


Using SOPS to decode secrets:

AWS_PROFILE=sops aws-auth sops -d logins.enc

Running terraform (such as is done in the digitalmarketplace-aws Makefile):

AWS_PROFILE=development-infrastructure aws-auth terraform get
AWS_PROFILE=development-infrastructure make plan
AWS_PROFILE=development-infrastructure make apply

Billing and billing alerts

The AWS Cost Explorer [documentation] is enabled for the admin role in the main, development and production account. This allows you to get cost reports broken down in various ways.

There are billing alerts [documentation] configured for the development and production account where we might expect a greater degree of variance in billing month to month.