How to host a service
In GDS, we follow the Government Cloud First policy and use Amazon Web Services (AWS) as core infrastructure and to host services rather than using our own hardware.
You can find more details about GDS’ AWS Organizations on the GDS Hub.
Note: GOV.UK One Login has its own AWS organisation, managed by the Digital Identity directorate. More information is available in the #di-platform-fog-support Slack channel, and the guidance here does not apply.
User access to an AWS account
People joining GDS do not automatically have access to Amazon Web Services (AWS). There are two ways to get access, depending on whether the AWS accounts to which you need access use AWS Identity Center, or use cross-account access from the gds-users base account.
For more information on how to create a user account, see the ‘Requesting a new AWS user’ page on the GDS Hub.
For accounts using the cross-account access pattern, it’s then the individual teams’ responsibility to grant that user access to any team specific roles.
See ‘Cross-account access’ with gds-users for more information.
Managing AWS accounts
GDS teams can request as many AWS accounts as they need, for example for production, for automated testing, and for development.
Using separate AWS accounts for different workloads (for example, for production and test workloads) allows GDS teams to:
- enforce administrative isolation between workloads
- minimise the impact of security breaches, for example, a compromised AWS credential
- isolate audit data in separate accounts
You can read more information about multiple accounts in the AWS Multiple Account Security Strategy.
Admin roles
You should provide access to an administrative role to any engineers on your team that meet your personnel security requirements and are required to support your product in an engineering capacity. This role must allow them to fully bootstrap your account, for example by creating or fixing infrastructure-as-code pipelines that create the resources you need.
Except in development and sandbox accounts, such administrative roles should only be used in an emergency or when you’re first bootstrapping an environment. You should also create more limited support roles that allow your team to diagnose (and in some cases fix) problems that occur in your production and production-adjacent accounts.
Controls
You should consider limiting what kinds of resources can be created in an account. You might do this by:
- using Permissions Boundaries to restrict what resources your pipelines or support roles can create
- working with Engineering Enablement to implement service control policies (SCPs) to additionally constrain even your administrative roles
This could help you comply with a standard architectural pattern, prevent unnecessary spending, and reduce risks.
Deleting an AWS account
If an AWS account is no longer needed the team should request its closure so that it does not accrue unnecessary costs.
Remove access to AWS accounts
GDS teams are responsible for managing their own leavers’ process, and that includes removal of AWS user accounts. You can read more about responsibilities in the ‘AWS shared responsibility model’
Before you request someone’s removal make sure they do not need access to AWS in another team within GDS.
Detailed instructions are available on the GDS Hub.