Don't Put All Your Code in One Account: Multi-Account Deployments with AWS CodePipeline

... or how to turn your single account AWS Code Pipeline into a multi-account one.

Recently I had an opportunity to improve the security posture of an application landscape which went to production in a bit of a rush so certain compromises were made on the way. Now that the applications have been running in a stable manner for some time, the time has come to make some security improvements.

Current Stage

In the current stage, multiple applications are running in the same AWS account together with all the other components such as the whole deployment pipeline, ECR repository, S3 buckets with artifacts and so on.

There are multiple ways how to improve the security posture of this landscape.

In this post I will focus on one of the best practices in the Security Pillar of the AWS Well Architected Framework - SEC01-BP01 Separate workloads using accounts which says:

Establish common guardrails and isolation between environments (such as production, development, and test) and workloads through a multi-account strategy. Account-level separation is strongly recommended, as it provides a strong isolation boundary for security, billing, and access.

Desired outcome: An account structure that isolates cloud operations, unrelated workloads, and environments into separate accounts, increasing security across the cloud infrastructure.

Common anti-patterns: Placing multiple unrelated workloads with different data sensitivity levels into the same account.

... the anti-pattern being exactly our case.

Approach

I took the following steps to follow the AWS best practices and to improve the security posture of the workloads:

1. Establish a new AWS Organization and setup Organization Units as per the AWS Best Practices for OUs, such as: Infrastructure, Workloads, etc.
2. Create a separate AWS account for each application and its stage
3. Create a separate AWS account for the CI/CD tooling, ECR, Artifacts and other shared services
4. Create a separate AWS account for VPCs and Subnets, possibly a Transit Gateway and a VPN for on-premise connectivity, to control the networking layer from one place. Share the subnets to the application accounts using the AWS Resource Access Manager
5. Modify the AWS CodePipelines to deploy the application into a different account

While the steps 1 thru 3 are quite straight forward, I will focus more on the step 4 and 5.

Subnet sharing

There are multiple benefits of the shared subnets model compared to proliferation of individual VPC and subnets in each application account. These bring value from both security and operational perspective:

• Centralized Network Security Controls: A dedicated networking team owns and manages networking components such as route tables or NACLs in one place. Application teams can't accidentally (or intentionally) misconfigure network boundaries, reducing the blast radius of a misconfiguration. Furthermore, Service Control Policies can enforce restrictions on creation of VPC, Internet Gateways, etc., in the application accounts.
• Consistent Compliance Posture: Security baselines (e.g., flow logs enabled, subnet routing) are enforced at the network account level. You don't need to audit each application account independently — the network is already compliant by design.
• Exclusive Control Over External Connectivity: Only the central networking team can establish connections between the shared VPCs and the outside world — whether that's Transit Gateway attachments, VPC peering, Site-to-Site VPN, or Direct Connect. Application teams are not able to create unapproved network paths, backdoor connections, or unauthorized peering arrangements. This ensures all traffic entering or leaving the environment flows only through approved ingress/egress points, which is critical for meeting data sovereignty and compliance and lowers the risk of data exfiltration.

AWS Code Pipeline Necessary Modifications

The existing CI/CD components had to be

Code Pipeline IAM Role

Code Deploy Stage IAM Role

ECR Policy

ECR KMS Policy

Final Picture

Below is a (simplified) diagram of what the final solution looks like. Better, isn't it?