In this step your Cloud Administrators will create several new team development AWS accounts via AWS Control Tower’s Account Factory.
This step should take about 30 minutes to complete.
As highlighted previously, an AWS best practice is to isolate the work of distinct builder teams by assigning a different development AWS account to each team. Benefits of this approach include:
Inherent Per Team Cost Allocation: Since AWS resource costs are, by default, attributable to each AWS account in which the resources are provisioned, at this early stage in your adoption, you don’t need to force builder teams to use cost allocation tags on their resources.
Inherent Isolation Between Teams: Since cloud resources managed by builder teams using different AWS accounts are, by default, completely isolated from each other, more advanced AWS Identity and Access Management (IAM) configurations are not needed to ensure that builder teams don’t inadvertently impact each other’s cloud resources.
Initially, you will likely need AWS accounts for the following teams:
Team Development Account | Purpose |
---|---|
Foundation Team | A team development AWS account for the initial few Cloud and Security Administrators to experiment, develop, and perform early testing of changes to the foundation. |
Workload Builder Team | A team development AWS account for the team that will be doing the workload specific work for your first formal workload on AWS. |
In AWS Control Tower, provision the initial set of team development AWS accounts for early experimentation, development, and testing.
You’ll follow these steps twice: Once to create the initial builder team development AWS account and again to create the Cloud Foundation team development AWS account.
master
account.Management console
associated with the AWSAdministratorAccess
role.Control Tower
.Account Factory
on the left.Enroll account
.Field | Recommendation |
---|---|
Account email |
Consult the set of AWS account root user email addresses that you established earlier. |
Display name |
dev-infra or dev-<team identifier> |
AWS SSO email |
Use the email address of your AWS Control Tower Admin user in AWS SSO. As long as you reference an existing AWS SSO user, the Account Factory will not create another AWS SSO user for this new AWS account. |
AWS SSO First Name |
AWS Control Tower |
AWS SSO Last Name |
Admin |
Organizational unit |
Select either infrastructure_dev or workloads_dev . |
Enroll Account
.It will take a few minutes to enroll the new account. You can check the status in Service Catalog
.
Once you create a new AWS account using Account Factory, there are several user account related tasks that you should perform to enhance the security of your environment.
Since AWS Control Tower’s Account Factory automatically grants the AWS SSO user specified in the Account Factory parameters administrative access to the newly created AWS account, you should remove this individual access. Since you’ll grant your Cloud Administrators access to the new AWS account using their AWS SSO group in a subsequent step, there’s no need to leave this individual access in place.
AWS SSO
.AWS accounts
in AWS SSO.dev-infra
AWS account.Remove access
from the User/group
entry that matches the AWS SSO email address you supplied in the previous step.Remove access
to confirm removal.Repeat these steps for the dev-<team identifier>
AWS account.
Perform the following steps for each of the new AWS accounts:
Set AWS Account Root User Password: See Log In as Root User in the AWS Control Tower documentation for instructions to set the root user’s password.
Enable Multi-Factor Authentication (MFA): See Enable MFA on the AWS Account Root User for instructions to enable MFA.
Since Cloud Administrators won’t automatically be granted sufficient access to newly created AWS accounts, you need to enable this access each time you create new AWS accounts via AWS Control Tower’s Account Factory.
master
account.Management console
associated with the AWSAdministratorAccess
role.AWS SSO
.AWS accounts
in AWS SSO.dev-infra
dev-<team identifier>
Assign users
.Groups
.example-cloud-admin
or similar.Next: Permission sets
.AWSAdministratorAccess
.Finish
.Now you’ve enabled all users who are part of the Cloud Administrator group in AWS SSO administrator access to the selected AWS accounts.
Since the names of shared subnets are not currently propagated to AWS accounts, as a Cloud Administrator, you should apply names to the shared subnets within each team development AWS account so that it’s easier for the builder teams to understand the role of each subnet as they configure resources for AWS services.
Management console
associated with the AWSAdministratorAccess
role.VPC
.Your VPCs
.dev-infra-shared
.Subnets
.Name
field of each private subnet to match the name of the private subnet as it’s configured in the network-prod AWS account. Caution: The subnets may not be listed in the same order in both AWS accounts by default.