Securely scale multi-account architecture with AWS Network Firewall and AWS Control Tower

Administrators and developers are always balancing the need for security with the need to move quickly. Recently, AWS published the Management and Governance Lens, an extension of the AWS Well-Architected Framework. The M&G Lens provides a set of prescriptive guidance to help customers build both securely and with speed. From this work, we learn about how to manage and govern so that you have migration ready, scale ready and optimized for efficiency cloud ready environments.

Many of our customers have adopted AWS Control Tower as a component of their multi-account strategy to achieve the twin objectives of business agility and centralized governance. After deploying AWS Control Tower, customers look to extend its benefits like creating a scalable and secure networking architecture, which can be seamlessly integrated with new accounts and VPCs.

In this blog post, we share a solution that gives developers the freedom and flexibility they need to innovate while providing centralized network security and inspection through automation. The solution uses a centralized AWS Network Firewall deployment and AWS Control Tower lifecycle events to deliver that capability, freeing up the time of developers and cloud administrators.

Architecture overview

Figure 1 shows a multi-account structure created by AWS Control Tower:

Figure 1 : Multi-account, multi-VPC architecture with AWS Transit Gateway and Network Firewall

AWS Control Tower is set up in the management account. It creates a security OU that includes log archive and audit accounts. Based on the landing zone best practice, a separate infrastructure OU contains the networking account. This account hosts all the centralized networking resources that support the networking requirements of the multi-account, multi-VPC architecture.

In this scenario, the networking account includes:

• AWS Transit Gateway for a scalable multi-account, multi-VPC architecture.
• Ingress and egress VPCs that control connectivity to the internet and connectivity to the on-premises network through an AWS Site-to-Site VPN connection or AWS Direct Connect.

This approach allows network administrators to govern and control networking requirements from a central location (the networking account). You can create other OUs and AWS accounts using AWS Control Tower such as OU A with account A and OU B with account B through Account Factory, as shown in Figure 1. This makes it possible to consistently and automatically apply the AWS Control Tower guardrails and security baseline across these new accounts. This solution uses Account Factory and AWS Identity and Access Management (IAM) roles created by AWS Control Tower for the automation.

When the solution is deployed, the following components are created as part of the architecture, as shown in Figure 1:

• The Lambda function in the management account listens for the AWS Control Tower lifecycle event, CreateManagedAccount, which is received when an account is created through Account Factory. Based on that event, it shares the transit gateway in the networking account to the newly created member account.
• AWS Network Firewall in the inspection VPC with a centralized deployment model. With this solution, you can inspect hundreds or thousands of VPCs and accounts in one place. The centralized deployment model allows for ease of management to inspect traffic between VPCs, internet, and on-premises networks. This solution saves you time by automating the process of provisioning a centralized firewall to inspect traffic between VPCs. You can also centrally configure and manage your firewall, firewall policies, and rule groups. This centralized deployment model architecture is described in the Deployment models for AWS Network Firewall blog post.
• The Lambda function in the networking account that listens for events from AWS Transit Gateway Network Manager. When it receives the event “VPC-ATTACHMENT-CREATED” it adds required associations to the route table. It also creates route propagations to the Inspection route table. This ensures that the traffic from VPCs will be sent to the centralized inspection VPC via transit gateway.
• The AWS Service Catalog portfolio with VPC product is created in the management account. Organizational sharing is enabled for this portfolio. It is accessible to newly created accounts as an imported portfolio. The VPC product can be launched in member accounts to create a VPC with private subnets and the automatic creation of an attachment to the centralized transit gateway in AWS Transit Gateway.

These components are integrated so that any traffic coming from VPCs is routed to AWS Network Firewall first. The traffic is inspected before it goes to its destination, which could be another VPC, on-premises network, or internet through the egress VPC. Likewise, traffic coming from the internet to a VPC through the ingress VPC is sent to AWS Network Firewall for inspection before it goes through the transit gateway to the destination VPC.

This architecture provides the following benefits:

• Centralized firewall and transit gateway reduces complexity and creates a scalable architecture across multiple VPCs without the cost of setting up and configuring firewall endpoints in each VPC.
• AWS Network Firewall setup in a Multi-AZ configuration helps create a highly available architecture.
• Centralized governance of networking resources in a single AWS account (the networking account).
• AWS Control Tower lifecycle events extend the network security to new accounts and VPCs in an automated way.
• AWS Service Catalog provides a consistent mechanism for deploying a preapproved configuration of VPCs that interconnect with the transit gateway for internal and external connectivity needs. This promotes standardization and centralized governance while allowing application developers to quickly deploy approved VPC configurations that meet compliance requirements.

Deploy the solution

1. In your AWS Control Tower environment, identify the networking account that will hold the central transit gateway and firewall.
2. In the networking account, create a transit gateway. Clear the Default route table association and Default route table propagation check boxes. Select the Auto accept shared attachments check box. Make a note of the transit gateway ID for later use.

Figure 2: Create a central transit gateway in AWS Transit Gateway

3. In the networking account, open the Network Manager console, create a global network, and then register your transit gateway with this global network. Choose the global network and then enable CloudWatch Logs Insights.

Figure 3: Enable CloudWatch Logs Insights in Network Manager

This allows events from AWS Transit Gateway such as attachment creation or deletion and route table changes to be sent as events to CloudWatch Events.

4. In the networking account, create two transit gateway route tables: Spoke VPC route table for associating with VPCs and Firewall route table for associating with the inspection VPC that contains AWS Network Firewall. Record the route table IDs for later use.

Figure 4: Spoke VPC route table and Firewall route table in AWS Transit Gateway

5. Use this CloudFormation template to deploy the AWS Network Firewall Deployment Automations for AWS Transit Gateway solution in the networking account. CloudFormation stacks are deployed using the console as explained in the documentation through console or CLI.
6. Using the AWS Control Tower management account, open the AWS Resource Access Manager console. On the Settings page, select the Enable sharing with AWS Organizations check box.

Figure 5: Enable sharing in AWS Organizations check box

7. In the AWS Control Tower management account, use this CloudFormation template to deploy a solution that provides AWS Control Tower integration with AWS Network Firewall. The CloudFormation stack creation presents with the screen shown below requiring input parameters for the deployment.

Figure 6: AWS CloudFormation Stack Input parameters

The input parameters required are explained below

Centralized Networking resources

NetworkingAccountId – AWS Account ID of the networking account in your multi-account environment.

TGWId – Identifier of the centralized transit gateway created in step 2.

SpokeVPCRouteTable – identifier of the transit gateway route table used for associating spoke VPCs. This is created in step 2.

FirewallRouteTable – identifier of the transit gateway route table to which the inspection VPC is associated. This is created in step 2.

Portfolio Information

Portfolio Name – Name of the AWS Service Catalog Portfolio consisting of a custom VPC Product. This name will be visible in AWS Service Catalog console of individual accounts. You can use default value of “Service Catalog VPC Reference Architecture”

Portfolio Provider – User-friendly name of the provider of the AWS Service Catalog portfolio. This will be visible in AWS Service Catalog console of individual accounts. You can use default value of “IT Services”

Portfolio Description – User-friendly description of the AWS Service Catalog portfolio. This will be visible in the AWS Service Catalog console of individual accounts. You can use the default value.

AWS Service Catalog IAM Settings

LaunchRoleName – This is the name of the AWS Service Catalog launch constraint role. If you have one in your environment, you can specify that or leave the field blank. When this is left blank, CloudFormation will create a new one.

LinkedRole1 – Name of the role which can execute products in this portfolio. Optional field.

LinkedRole2 – Name of the role which can execute products in this portfolio. Optional field.

CreateEndUsers – Select “Yes” to create the ServiceCatalogEndUsers IAM group. Select “No” if you already have this IAM group in your AWS environment. Default value “Yes”.

8. After it’s deployed, open the AWS Service Catalog console. Expand Administration, choose Portfolios, and then choose the VPC Reference Architecture portfolio. Share the portfolio with AWS Organizations.

Figure 7: Sharing an AWS Service Catalog portfolio

How it works

Figure 8 shows the sequence of events when the cloud administrator creates a new account in AWS Control Tower and an application developer launches the VPC product.

Figure 8: Sequence of events

A new account is created in AWS Control Tower

When you create an account in AWS Control Tower through Account Factory:

1. The CreateManagedAccount lifecycle event triggers the NFW-CT-Integration-Lifecycle Lambda function.
2. The Lambda function executes a stack set in the management account
   1. A stack instance is deployed in the new member account that creates the AWS Service Catalog launch role, SCLaunchRole. This makes it possible for you to use AWS Service Catalog launch constraints to allow end users to launch the VPC product without requiring direct IAM permissions to the VPC and other networking resources.
3. The Lambda function assumes the AWSControlTowerExecution role in the networking account
   1. It then shares the transit gateway to the member account using AWS Resource Access Manager.

Application developer launches the AWS Service Catalog VPC product

An application developer operating in the new member account wants to deploy a VPC for setting up an application environment.

4. The developer navigates to AWS Service Catalog, deploys the VPC product, and provides the details of the transit gateway.
5. This creates a VPC in that account with two private subnets. It creates an attachment to the transit gateway and updates the route tables to set a default route to the transit gateway.
6. As soon as the attachment is created, a CloudWatch event is triggered.
   1. An SNS topic receives the event, and triggers the NFW-ControlTower-Attachment-LifeCycle Lambda function. This function associates the attachment with the Spoke VPC route table and creates a propagation in the Firewall route table.
7. The transit gateway route tables are updated so traffic can be routed through AWS Network Firewall.

When these steps are complete, any traffic sent from the VPC is first routed to the inspection VPC, where it is inspected by AWS Network Firewall and then routed back to its eventual destination.

Cleanup

Follow these steps to remove the resources deployed by this solution. These steps will not remove the VPCs created by this solution.

1. In the member accounts, remove any VPC products launched through the AWS Service Catalog console.
2. In the AWS Control Tower management account, remove the StackSet instances for the NFW-ControlTower-SCLaunchRoleStackSet stack set.
3. In the AWS Control Tower management account, delete the CloudFormation stack that the CloudFormation template deployed for integration with AWS Network Firewall.
4. In the AWS Control Tower networking account, delete the CloudFormation stack that was deployed for AWS Network Firewall Deployment Automations for AWS Transit Gateway.

Considerations

Although the architecture presented in this blog post provides a mechanism to extend the agility and governance aspects of AWS Control Tower to network security, it’s important to apply and adapt it to the specific requirements of your environment. Consider the following:

• If you want to use your own third-party firewalls, use Gateway Load Balancer in the inspection VPC.
• Although this architecture is designed to inspect either North-South or East-West traffic, you can tailor the routing configurations to inspect only the required traffic paths.
• Create VPCs using the AWS Service Catalog product. Existing VPCs or VPCs created outside of AWS Service Catalog are not configured to take advantage of the automation. They will require manual reconfiguration to take advantage of the centralized network firewall.
• In addition to Network Firewall and AWS Transit Gateway, this automation uses AWS Lambda, Amazon SNS, Amazon CloudWatch Events, and AWS Service Catalog, which incur charges. Although the manner in which this solution uses these services keeps the cost to a minimum, you should evaluate the pricing for these services.
• Transit Gateway Network Manager sends events to CloudWatch Events in the us-west-2 AWS Region. Make sure that you have not disabled the Region or have service control policies that prevent you from using that Region.

Conclusion

The solution presented in this blog post shows one method for using AWS Control Tower and AWS Service Catalog to provide a self-service approach to network security in multi-account environments. Using those services with AWS Network Firewall ensures a secure, highly available, and scalable network security posture as your AWS Control Tower environment expands. By using a centralized deployment of AWS Network Firewall, administrators can ensure traffic from multiple VPCs throughout different AWS Control Tower accounts is inspected in a manner consistent with your enterprise network security policies.

About the authors