Building a Landing zone with AWS Control Tower (part 3)

In the previous post, I demonstrated three foundational AWS accounts (Management, Log Archive, and Audit), baseline resources, and possible customizations, which are frequently implemented on projects. In this part, we will look at the Infrastructure Organizational Unit and possible use cases for it.

Let’s get back to the following schema from the previous post and break the Infrastructure OU down:

Centralized backups

Having a copy of the backup in a different location is necessary for a disaster recovery process when we lose access to the whole AWS region. Copying backups to another AWS account can protect us from unauthorized access when an intruder gets admin access to an account and removes data with backups. AWS has already automated many such things via the AWS Backup service and Backup policies.

With Backup policies, we can centrally configure Backup plans and target accounts can not change those plans directly. The backup policy contains a schedule, lifecycle (retention policy), copy action (if we need to copy the backup to another AWS account/region), and selections (which resources we need to backup).

Cross-account backup copy configuration is demonstrated in a separate article.

DevOps account

CI/CD tools (e.g. Jenkins, GitLab, CodePipeline, etc.) and artifact storages (ECR, Artifactory, Nexus, etc.) can be deployed in the isolated AWS account. Access to the tools can be configured via SSO. Applications can be deployed to different target accounts from one place.

Shared services

Such an account can have tools for monitoring and logging, for example, storing application logs from different environments in the central OpenSearch cluster or sending metrics to the central Prometheus.

The support team has access to monitoring tools in the “Shared account” instead of having access to workload accounts.

Network account

Centralized networking is the most popular among companies, which implement Landing Zone.

A dedicated “network team” can manage IPAM to plan, track, and monitor IP addresses for your AWS workloads; configure a Firewall to filter traffic; manage DNS; attach VPCs to the central Transit Gateway; use Client VPN to provide connectivity to private networks, etc.

Central Transit Gateway can be deployed as a part of Network Orchestration for AWS Transit Gateway

Network Orchestration for AWS Transit Gateway

Formerly known as Serverless Transit Network Orchestrator (STNO)

The network team can use a frontend to monitor and approve new VPC attachments:

The solution follows the hub-spoke deployment model and uses the given workflow:

1. An Amazon EventBridge rule monitors specific VPC and subnet tag changes.
2. An EventBridge rule in the spoke account sends the tags to the EventBridge bus in the hub account.
3. The rules associated with the EventBridge bus invoke an AWS Lambda function to start the solution workflow.
4. AWS Step Functions (solution state machine) processes network requests from the spoke accounts.
5. The state machine workflow attaches a VPC to the transit gateway.
6. The state machine workflow updates the VPC route table associated with the tagged subnet.
7. The state machine workflow updates the transit gateway route table with association and propagation changes.
8. (Optional) The state machine workflow updates the attachment name with the VPC name and the Organizational Unit (OU) name for the spoke account (retrieved from the Org Management account).
9. The solution updates Amazon DynamoDB with the information extracted from the event and resources created, updated, or deleted in the workflow.

Centralized Firewall

If you need a traffic inspection using the centralized firewall, you can deploy it to the dedicated Network account.

Here is an AWS Blog post about different models of configuring networks in a multi-account AWS environment. For example, this one covers the inspection for North-South internet-bound traffic from AWS Transit Gateway attachments. For this model, we also have a dedicated, central egress VPC with a NAT gateway configured in a public subnet with access to IGW.

or another scheme, built with Palo Alto Next-Generation Firewall, which I demonstrated in my previous post:

As a result, you can limit networking configuration capabilities for member accounts, attach all VPC to the central Transit Gateway, attach on-premises resources via site-to-site VPN to the central Transit Gateway, inspect all traffic centrally on the firewall, and decide whether to allow it or reject. In this case, you will have quite a secure environment and centralized management, suitable for modern compliance standards.

Conclusion

In this post, I demonstrated possible options for AWS accounts within an Infrastructure OU, which may contain your shared services and networking accounts, in particular Centralized Backups, DevOps tooling, Shared services for monitoring and logging, Networking with automation, and Firewalls.