AWS Account Configuration
Miles Systems has deployed AWS Control Tower to help get a multi-account AWS environment up and running quickly. A multi-account AWS environment is a best-practice based on well-architected principals. See the Organizing Your AWS Environment Using Multiple Accounts AWS Whitepaper.
AWS Control Tower is an AWS managed service that orchestrates various AWS services to help simplify management of multiple AWS accounts within an organization. When AWS Control Tower is deployed, it creates a "landing zone". A landing zone is a well-architected, multi-account AWS environment that's based on security and compliance best practices.
Miles Systems' Control Tower landing zone has been deployed in the N. Virginia (us-east-1) region of the Master account and must be administrated from that account/region.
AWS Organizations is used as a means to govern AWS Accounts via the Master Account. Service Control Policies (SCPs) can be placed on accounts or organizational units to restrict access to regions and/resources.
Control Tower applies preventative guardrails through Service Control Policies (SCPs). SCPs can also be added to OUs and accounts outside of Control Tower's guardrails for additional flexibility. Please note, do not manually edit and SCPs that Control Tower manages, instead create your own and add attach them to OUs/accounts in addition to the Control Tower SCPs.
At Miles Systems, our accounts are grouped into four Organization Units:
- Root - The main parent OU. Only the Master account lives here. All other OUs have a child relationship to this OU. DO NOT make manual adjustments to this OU. It is completely managed by Control Tower.
- Security - Configured by Control Tower (should not be manually adjusted). Only the Logs Archive and Audit/Security accounts live in this OU. DO NOT make manual adjustments to this OU. It is completely managed by Control Tower.
- Shared Infrastructure - The Shared Networking accounts lives here. Any future shared environment accounts could also live here (e.g., a Shared Services account)
- Miles Systems App - Accounts relating to the Miles Systems app live here.
First, do not create OUs based off your corporate org chart. This is generally a bad idea because various business orgs may need varying levels of access to the same accounts. Instead, it's better to create new OUs based on workload or purpose.
Currently, the Miles Systems App lives in an OU with the same name that holds a Non-Prod and Prod account relating to the app. In the future, you may wish to create more accounts for each stage of the systems development lifecycle (e.g., dev, test, stage). You may also wish to create new accounts based on separate workloads. If you were to create another workload you would likely put it within a new OU if it's use case is different, and/or it is desirable to logically isolate resources. For example, in the future you may wish to collect telemetry and other data and store it in a data lake. You would likely create a new OU named "Data" or "Data Lake" and create the AWS accounts needed for the workload.
You may wish to create additional OUs based on the maximum IAM actions desired in an account. For example, for sandbox accounts, you would likely want to limit the scope of services available to those accounts and/or limit the instance sizes available to those accounts to help control costs. In this case, a "Sandbox" OU would have a service control policy attached to it that limits EC2 and RDS instance sizes to t2.*, t3.*, *.medium, and *.large instance sizes. You may also wish to restrict access to services that developers don't have a reason to use and/or are generally more expensive (e.g., AWS Glue, Amazon Kendra, Private Certificate Authorities in ACM, etc.).
There are three core accounts that are required by Control Tower:
- Master account - Used for billing and for everything in the landing zone (including the Account Factory, guardrails management, etc.)
- Audit/Security account - Also referred to as the security account, this is a restricted account that's designed to give security and compliance teams read and write access to all accounts in your landing zone via programmatic access to review accounts. This is accomplished by means of a role that is granted to Lambda functions only.
- Logs Archive account - Works as a repository for logs of API activities and resource configurations for all accounts managed by Control Tower.
For more details, please refer to the How AWS Control Tower Works documentation page.
-
Master Account
- Account ID: 012345678910
- Root Email: [email protected]
-
Audit (Security) Account
- Account ID: 012345678910
- Root Email: [email protected]
-
Logs Archive Account
- Account ID: 012345678910
- Root Email: [email protected]
Outside of the required Control Tower accounts, we have created 3 additional AWS accounts to manage various pieces of the infrastructure.
-
Shared Networking
- Account ID: 012345678910
- Root Email: [email protected]
- Description: Contains all the VPCs/Networking/DNS infrastructure for the AWS environment. VPCs are shared out to the other accounts from this account.
-
Production
- Account ID: 012345678910
- Root Email: [email protected]
- Description: Contains all production related application infrastructure
-
Development
- Account ID: 012345678910
- Root Email: [email protected]
- Description: Contains all non-production related application infrastructure
As part of the Control Tower configuration, AWS SSO is deployed to help manage access to accounts. AWS SSO determines what accounts users can access.
AWS SSO is deployed in the Master account in the same region as the Landing Zone (N. Virginia/us-east-1). User access to accounts can be administered from the AWS SSO Console page. User accounts are mapped to GSuite accounts. From there, users will be assigned to groups and/or individual accounts with appropriate permission sets.
Additional information about AWS SSO and Permissions sets can be found in the AWS Single Sign-On documentation page within this repo. Please refer to the official Managing identities in AWS SSO AWS Documentation for more in-depth instructions on managing users/groups with AWS SSO.