In this step your Cloud Administrators will review the initial development network design, create a new Network AWS account, provision a common centrally managed development network, and share the private subnets will all team development AWS accounts in your AWS organization.
This step should take about 60 minutes to complete.
As mentioned in the Initial Development Environment Solution Overview, it’s recommended that you start with a single centrally managed development VPC that has a set of public and private subnets of which only the private subnets will be shared across all team development AWS accounts.
In those AWS regions in which at least 3 Availability Zones (AZs) are available for customer use, it’s recommended that your initial set of VPCs have subnets in each of the 3 AZs so that your builder teams can experiment with and perform early testing of workloads and AWS services that can take advantage of 3 AZs.
At least one public subnet will have a NAT Gateway that enables workloads in any of the shared private subnets to send traffic outbound to the Internet. For example, to enable workloads to download content from Internet accessible source code and package repositories.
Option to filter outbound Internet traffic: As you progress in your journey, you may transition from this initial approach of providing builder teams with unfiltered outbound or egress Internet access via the initial set of public subnets and NAT Gateway to a more secure architecture where all Internet egress traffic is routed through your standard enterprise edge security services so that all egress traffic is inspected for compliance. This capability is highlighted in the optional development fast follow capabilities.
Since you will be provisioning the centrally managed development VPC directly using AWS CloudFormation, you need to ensure that the AWS Control Tower Account Factory network configuration is set to disable creation of a VPC when creating a new AWS account. Otherwise, the Account Factory will attempt to create a VPC each time you provision a new AWS account.
See Configuring AWS Control Tower Without a VPC for details on disabling automatic creation of VPCs.
In AWS Control Tower, provision a new Network AWS account that will initially contain the centrally managed development VPC.
Later in your journey, you’ll deploy more network related resources to this AWS account. For example, you will likely configure and manage AWS Transit Gateway resources in this dedicated AWS account when you start integrating on-premises network connectivity in your overall AWS environment.
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 |
network-prod |
AWS SSO email |
Use the same email address as Account Email . |
AWS SSO First Name |
Use a part of your account name. For example, Network . |
AWS SSO Last Name |
Use the remaining part of the account name. For example, Production |
Organizational unit |
Select the infrastructure OU you created earlier in this section. For example, infrastructure . |
Enroll Account
.It will take a few minutes to enroll the new account. You can check the status in Service Catalog
. Once it’s done, the e-mail address you used will receive 3 messages: 1) Your AWS Account is Ready, 2) Invitation to join AWS Single Sign-On, 3) Welcome to Amazon Web Services.
You can change AWS account settings later: Configuration settings of the AWS accounts you provision via Account Factory shouldn’t be considered static. Nearly every part of an AWS account can be changed and updated at a later date. See Account Factory for more details.
Since Cloud Administrators won’t automatically be granted sufficient access to the newly created AWS account, you need to enable this access each time you create a new AWS account via AWS Control Tower’s Account Factory.
master
account.Management console
associated with the AWSAdministratorAccess
role.AWS SSO
.AWS accounts
in AWS SSO.Network
AWS account.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 Network AWS account.
If you’re just experimenting and don’t care which IP address CIDR block is used to build the centrally managed development VPC, you can move to the next step, 6. Provision Development VPC.
Otherwise, if you have a formally assigned CIDR block to use, in this step you’ll:
The default parameters of the AWS CloudFormation template that you will use in the next step will result in a VPC with:
The CloudFormation template requires you to supply a CIDR block for each of the following:
To keep things simple, you can size the subnets identically.
If your Network team has supplied a relatively large non-overlapping CIDR block, for example a /16
- /20
, you should consider using only a subset of that block for your centrally managed development VPC so that the remaining address space can be used in support of pre-production test and production networks. Otherwise, if you’ve been allocated a /21
- /22
, then you should use the entire block for the centrally managed development VPC.
If you need to break down a larger block:
/nn
in the Network Address
field.Mask bits
field.Update
.Divide
link to break down the block into smaller blocks.When you’ve reached block sizes from /20
- /22
, select a block size of most interest to you and record that CIDR range so that you can use it in the next step.
Once you’ve determined the VPC CIDR block, breaking it down into an equal size block per subnets is straightforward.
/nn
the Network Address
field.Mask bits
field.Update
.Divide
links to start subdividing the larger block into 6 blocks of equal size.You can use this sample AWS CloudFormation template to easily deploy your centrally managed development network.
Download the sample AWS CloudFormation template vpc-multi-tier.yml to your desktop. You can review the README to understand the role of this template.
Next, access the new Network AWS account:
Network
AWS account.Management console
associated with the AWSAdministratorAccess
role.Now create a new AWS CloudFormation stack using the sample template you downloaded to your desktop:
CloudFormation
.Create stack
and With new resources
.Upload a template file
.Choose file
to select the downloaded template file from your desktop.Next
.Stack name
. For example, base-dev-vpc
.Parameters
:Parameter | Guidance |
---|---|
Business Scope |
Replace example with your organization identifier or stock ticker if that applies. This value is used as a prefix in the name of some of the VPC-related cloud resources. For example, in the name of the IAM role used to support VPC flow logs. |
VPC Name |
Change to dev . |
*Cidr |
Just Experimenting If you want to just experiment at this point and don’t care about using formally assigned IP address ranges, you can leave the CIDR block parameters at their default values. You Have Your Own CIDR Blocks Enter values for the pVpcCidr , pTier1.. , and pTier2... CIDR blocks from the prior step. You can ignore the pTier3... parameters because only two tiers - public and private - are being provisioned by default. |
Leave all of the other parameters at their default settings unless you’re comfortable changing them. You can always easily create another stack to experiment with other parameter values. Review the README for details on parameters.
Next
.Next
.Create stack
.In the Events
tab, monitor the progress of the stack creation process. After 5 or so minutes, creation of the stack should complete.
Review the newly created VPC and associated resources.
VPC
.Subnets
in the left menu and review. By default, you will see 6 subnets.Route Tables
and review. You will see one route table per subnet in addition to the VPC’s main route table.NAT Gateways
and review. With the default behavior of the CloudFormation template, a single NAT Gateway will be created.Elastic IPs
and review. You will see one EIP allocated for each NAT Gateway.CloudWatch
.Log groups
./base/dev/flowlogs
.Now that the centrally managed development VPC has been provisioned, your next step is to share the private subnets with all of the AWS accounts that will become part of the development
OU that you created earlier.
This is a one time operation.
master
account.Management console
associated with the AWSAdministratorAccess
role.Resource Access Manager
.Settings
.Enable sharing with AWS Organizations
.development
OU While you’re in the master AWS account, obtain and record the resource ID of the development
OU.
AWS Control Tower
.Organizational units
.development
.ID
of the form ou-szfb-rixl8jqc
(example) so that you can refer to it in the next step.Network
AWS account.Management console
associated with the AWSAdministratorAccess
role.Resource Access Manager
.Create a resource share
.Name
of base-dev-vpc-private-subnets
.Resources
, by default, the subnets that were just provisioned should be listed.Principals
, uncheck Allow external accounts
given that we’re sharing the subnets only with other AWS accounts within this AWS organization.development
OU.Create resource share
.Sharing names of VPC subnets: If you were to list the shared private subnets from within the team development AWS accounts, you would notice that the subnet names are blank. Currently, sharing of subnets does not include automatic propagation of resource tags, including the Name
tag. As a workaround, in a subsequent section where you provision the team development AWS accounts, you can manually assign names to the shared private subnets so that it will be easier for the builder teams to understand the role of each subnet. For example, by including the word “private” in the subnet names, builder teams will be able to more readily understand the role of the shared subnets.