Multi-region and multi-account network design. It is the blueprint for connecting different cloud environments — spread across multiple geographic locations and separate organisational accounts — so they work as one secure, fast, and reliable system. For the ANS-C01 exam, understanding this is critical because half the questions test how you combine performance, resilience, and cost when linking networks across the globe.
Jump to a section
A simple way to picture Multi-Region and Multi-Account Network Design
64 franchise locations across the US and Europe. Each one is its own legally separate business (an "account") with its own bank account and staff, but they all share the same menu, recipes, and brand. Some locations are in the same city (a "region"), while others are in different countries (separate "regions"). The headquarters needs to ensure that a customer in London can order the same burger as a customer in New York, even though each franchise operates independently.
Now, imagine headquarters rolls out a new secret sauce. They can't just call every single franchise individually — that would take forever. Instead, they have a central recipe database (like a "resource" in the cloud) that every franchise automatically pulls from. When the head chef updates the recipe in one place, each franchise's kitchen gets the update within minutes. This is exactly like using a centralised network configuration that synchronises across multiple accounts and regions.
But there's a catch: the London franchise has stricter local food safety laws (like data residency rules). So headquarters allows London to have a slightly different inventory system that still connects back to the central database — just with a filtered path. This mirrors how you design network paths in a multi-region setup: you create connections (like "Transit Gateways") between regions, but you also apply rules so that certain data never leaves a specific geographic area. The entire system is designed so that if one franchise has a power outage, the others keep serving customers seamlessly, which is exactly the resilience goal of a multi-region network.
Let's start with the core idea: a "region" is a physical location where a cloud provider (like Amazon Web Services) has a cluster of data centres. A "multi-region" setup means you have resources running in two or more of these geographic areas. An "account" is a separate container for billing and permissions — like having a separate credit card and set of keys for each project or department. "Multi-account" means you use multiple such containers to organise your workloads, often for security or cost tracking reasons.
The main problem this design solves is distance. If all your applications run in one region, customers on the other side of the world experience slow loading times — because data has to travel thousands of miles through undersea cables and internet routers. Also, if that single region suffers a natural disaster or a power failure, your entire service goes down. By spreading resources across regions, you reduce latency for global users and create a safety net: if one region fails, traffic is rerouted to another.
Similarly, using multiple accounts instead of one giant account prevents a single user error — like accidentally deleting a vital database — from taking down everything. Each account acts as a blast radius containment zone. For example, you might have one account for development, one for testing, and one for production. If a developer misconfigures a firewall in the development account, it won't affect the live customer-facing system.
Now, how do you actually connect these regions and accounts? The key building blocks are:
Virtual Private Cloud (VPC): This is a private, isolated section within a cloud region where you launch your resources (servers, databases, etc.). Think of it as your own fenced-off plot of land in the cloud.
VPC Peering: A direct, private network connection between two VPCs. It allows them to communicate as if they were on the same local network, but it does not work across accounts without extra steps and does not support transitive routing (VPC A can talk to VPC B, but not to VPC C through VPC B unless all pairs are connected).
Transit Gateway (TGW): A central hub that connects multiple VPCs and on-premises networks together. It acts like a central exchange — every VPC connects once to the TGW, and the TGW knows how to route traffic between all of them. This is much simpler than creating dozens of VPC peering connections.
VPN Connection: An encrypted tunnel over the public internet that connects your on-premises data centre to your cloud VPC. It is slower but cheaper than a dedicated physical connection.
Direct Connect: A dedicated physical fibre-optic line from your data centre to the cloud provider. It is faster, more reliable, and more expensive than VPN.
Route Tables: These are like signposts inside each VPC that tell network traffic which path to take (e.g., "traffic for 10.0.0.0/16 goes to the Transit Gateway").
IAM Roles (Identity and Access Management): Permissions that allow one account to access resources in another account. For example, a role in the production account can be assumed by a service in the logging account to pull log data.
To design a multi-region architecture, you need to decide how data flows between regions. You might choose to replicate data (copy it from one region to another) for disaster recovery, or you might have customers in Europe using a European region and customers in Asia using an Asian region, with no cross-region data movement unless necessary. The latter is called "active-active" — both regions are serving traffic simultaneously. The former is "active-passive" — one region actively handles traffic, and the other region is on standby with a copy of the data.
Cost is a huge factor. Cross-region data transfer is expensive — the cloud provider charges for every gigabyte that leaves a region. So you must design your network to minimise unnecessary cross-region traffic. For instance, you can use caching services (like Amazon CloudFront or ElastiCache) to store frequently accessed data closer to users, reducing the need to fetch data from a distant region.
Resilience comes from diversity. You should spread your resources across at least two Availability Zones (isolated data centres within a region) and two regions. Use health checks and DNS routing (like Amazon Route 53) to automatically redirect traffic away from a failed region. This is called "failover" — manually or automatically switching to a backup system.
Finally, multi-account design involves setting up a central networking account that manages shared resources like the Transit Gateway and Direct Connect connections. Other accounts (like the development account) then attach to this central network. This avoids duplicating expensive resources and keeps security tight because the networking team controls the core connectivity.
To summarise the architectures: you can have one account in one region (simple but fragile), multiple accounts in one region (better security isolation, still no regional resilience), or multiple accounts across multiple regions (best for performance, resilience, and compliance). The ANS-C01 exam will ask you to choose the correct design for a given scenario based on the trade-offs between speed, uptime, and budget.
Assess Requirements
First, gather the business needs: how many regions are required for performance and disaster recovery? How many accounts are needed for security isolation (e.g., separate accounts for dev, test, prod)? Also determine compliance needs like data residency in the EU.
Design Account Structure
Create a multi-account strategy using AWS Organizations. Designate one account as the central networking account to host shared resources like Direct Connect and Transit Gateway. This keeps management clean and prevents conflicts.
Select Regions and Deploy VPCs
Choose regions based on customer location and compliance. In each region, deploy VPCs for each environment (dev, prod, etc.). Each VPC must have non-overlapping CIDR blocks (IP address ranges) to allow future peering.
Set Up Central Connectivity (Transit Gateway)
In the central networking account, create a Transit Gateway. Use AWS RAM to share it with the other accounts. Then attach each VPC to the Transit Gateway. Configure route tables in the Transit Gateway and in each VPC to enable routing between VPCs and to on-premises.
Connect to On-Premises and Other Regions
Create a Direct Connect or VPN connection from your on-premises data centre to the central networking account. For multi-region connectivity, create inter-region peering between Transit Gateways in different regions. This enables traffic to flow from on-premises to any VPC in any region.
Implement Security and Monitoring
Apply security groups and network ACLs to control traffic between VPCs. Set up VPC Flow Logs to record network traffic. Use CloudWatch to monitor cross-region traffic costs and latency. Configure Route 53 health checks for automatic failover.
Imagine you work for "GlobalShop", an e-commerce company that sells products worldwide. GlobalShop started with one account and one region (US-East). As the business grew, they opened offices in London and Sydney. Customers in those regions complained that the website was slow. Also, the CEO worried that a single hurricane in Virginia could stop all sales worldwide.
Your job as a network engineer is to design a multi-region and multi-account network. Here is what you actually do, step by step:
You start by creating new AWS accounts: one for the networking team (the "Network Account"), one for production workloads, one for development, and one for security logging. Each account has its own billing and admin control.
You decide to deploy infrastructure in three regions: us-east-1 (Virginia), eu-west-2 (London), and ap-southeast-2 (Sydney). In each region, you create a VPC for each environment: a production VPC and a development VPC.
You log into the Network Account and create a Transit Gateway. Then you share that Transit Gateway with the other accounts using AWS Resource Access Manager (RAM). This allows each account to attach its VPCs to the same central hub.
You set up a VPN connection from the London office to the eu-west-2 VPC, and from the Sydney office to the ap-southeast-2 VPC. These connections allow on-premises staff to securely access cloud resources.
You configure route tables in each VPC to send traffic destined for other regions through the Transit Gateway. Then you set up inter-region VPC peering between the Transit Gateways in different regions. Now, a server in London can communicate with a server in Sydney using private IP addresses.
For disaster recovery, you replicate the production database from us-east-1 to eu-west-2 using AWS Database Migration Service. You also store a backup of the web server application code in an S3 bucket that is replicated across all three regions.
You create a Route 53 DNS configuration with a latency-based routing policy. When a user in France types www.globalshop.com, Route 53 automatically sends them to the London region, because the measured latency to London is lower than to Virginia or Sydney. If the London region goes down, Route 53 detects the health check failure and reroutes traffic to Virginia.
To control costs, you analyse the traffic logs. You notice that the development environment is sending large amounts of test data from Sydney to Virginia, incurring high cross-region charges. You implement a network ACL to block unnecessary inter-region traffic from development VPCs, and you schedule the data replication to happen only during off-peak hours.
Finally, you set up CloudWatch alarms to monitor network throughput and latency between regions. You also create a dashboard in the centralized logging account that shows the health of all cross-region links.
By the end, GlobalShop customers get a fast experience because they are served from the nearest region. The business is resilient: if one region fails, traffic seamlessly shifts. And the company saves money because they only replicate critical data, not everything.
The ANS-C01 exam (exam code ANS-C01) tests multi-region and multi-account design heavily. Expect at least 10-15 questions on this topic. The exam loves scenario-based questions where you must choose the optimal design based on performance, resilience, and cost. Here are the key patterns:
Trap patterns you must avoid:
The exam will present a scenario with a single region and ask whether you should add a second region for disaster recovery. The trap is that if the application is in a single Availability Zone (AZ), the cheaper, faster fix is to make it multi-AZ within the same region — not add a whole new region. Only choose multi-region when the requirement explicitly says "disaster recovery from a regional failure" or "geographic latency improvement."
Another trap involves VPC Peering vs Transit Gateway. The exam will describe a scenario with 10 VPCs across multiple accounts. The wrong answer will suggest using VPC Peering for all pairs, which would require 45 connections and doesn't support transitive routing. The correct answer is usually Transit Gateway or a Transit VPC solution.
Connectivity between regions: The exam tests that you cannot directly peer two VPCs in different regions using standard VPC Peering (you need inter-region VPC Peering, which works but is expensive). They also test that Transit Gateway can do inter-region peering, which is their preferred method.
Multi-account network management: Look for questions about "centralized vs decentralized" network management. The correct answer is usually centralized — using a shared services account or a dedicated networking account. The exam also loves testing IAM cross-account roles (using a role in Account A that allows access from Account B).
Concepts to memorise:
Transit Gateway: Hub-and-spoke model for connecting many VPCs and on-premises networks. Supports transitive routing.
VPN CloudHub: A design where multiple VPN connections terminate at the same Virtual Private Gateway (VGW) to allow sites to communicate via the cloud.
VPC Endpoints: Allows private access to AWS services (like S3 or DynamoDB) without crossing the public internet or needing a NAT gateway.
Route 53 Routing Policies: Latency-based, geolocation, geonearby, weighted, failover — know exactly which policy fits each business need.
Direct Connect Gateway: Allows you to connect multiple VPCs in different regions to a single Direct Connect connection.
AWS Resource Access Manager (RAM): Used to share Transit Gateways, subnets, and other resources across accounts.
AWS Organizations: The tool for centrally managing multiple accounts. You must know how to use Service Control Policies (SCPs) to restrict what member accounts can do.
Question types:
Multiple choice: Given a business requirement (lowest cost, highest availability, etc.), select the correct architecture diagram.
Multiple response: Choose which two design choices improve resilience (e.g., deploy across two regions AND use an active-active failover configuration).
Drag and drop: Place the networking components (Transit Gateway, VPC, VPN, Direct Connect) in the correct order on a diagram.
The exam writers love numbers: they will specify "3 VPCs in 2 accounts across 2 regions" and ask how many Transit Gateway attachments you need. The answer is 3 (one per VPC) if using a single Transit Gateway shared across accounts. They also test bandwidth limits: a single VPN tunnel is limited to ~1.25 Gbps; using multiple tunnels with ECMP (Equal Cost Multi Path) can increase throughput.
VPC Peering does not support transitive routing; use Transit Gateway when you need to connect more than two VPCs.
Multi-region design protects against regional failures, while multi-AZ protects against data centre failures within a single region.
Cross-region data transfer costs money; always optimise data flow to avoid unnecessary replication.
IAM cross-account roles are the secure way to allow resources in one AWS account to access resources in another.
Route 53 latency-based routing sends users to the region with the lowest network latency, improving performance for global customers.
A Transit Gateway can be shared across multiple AWS accounts using AWS Resource Access Manager (RAM), enabling a centralised networking model.
These come up on the exam all the time. Here's how to tell them apart.
VPC Peering
Direct one-to-one connection between two VPCs only
Non-transitive: cannot route through a third VPC
Best for small number of VPCs (2-3)
Transit Gateway
Hub-and-spoke model connecting many VPCs
Supports transitive routing (VPC A to VPC C via TGW)
Best for 4+ VPCs across multiple accounts
Active-Passive DR
One region handles all live traffic
Second region is standby with replicated data only
Lower cost because second region runs minimal compute
Active-Active DR
Both regions handle user traffic simultaneously
Requires data replication and conflict resolution
Higher cost but provides better performance for global users
Single Account Design
All resources in one AWS account
Simpler to manage, but no security isolation
One mistake can affect every workload
Multi-Account Design
Separate accounts for dev, test, prod, security
Better blast radius containment and cost tracking
Requires additional setup for cross-account networking
Direct Connect
Dedicated physical fibre connection
Consistent bandwidth and low latency
Higher monthly cost, longer setup time
VPN Connection
Encrypted tunnel over the public internet
Variable performance depending on internet conditions
Lower cost, can be set up quickly
Mistake
VPC Peering connections can be used to connect any number of VPCs in a mesh, and traffic can hop through multiple peered VPCs to reach its destination.
Correct
VPC Peering is non-transitive: if VPC A is peered with B, and B is peered with C, traffic cannot flow from A to C through B. You must peer A directly with C. For more than a few VPCs, use a Transit Gateway.
This is a common mistake because in real-world networking (like Ethernet switches), connections are typically transitive. Beginners assume cloud peering works the same way.
Mistake
Multi-region design always means every region must have a full copy of all data and applications.
Correct
Multi-region design can be active-passive (one region handles traffic, the other is standby with only data) or active-active (both regions handle traffic, but only critical data is replicated). Full replication is often too expensive and unnecessary.
Beginners think 'redundancy means everything duplicated'. In reality, cost constraints dictate that you only replicate what is essential for business continuity.
Mistake
Separate AWS accounts automatically allow resources in one account to communicate with resources in another account.
Correct
Accounts are fully isolated by default. To enable cross-account communication, you must explicitly grant permissions using IAM roles and configure networking components (like Transit Gateway sharing or VPC peering) between the accounts.
The word 'account' sounds like a user-level concept. People assume that just like having two email accounts allows you to send emails between them, two AWS accounts naturally can talk to each other. They ignore the security and billing isolation boundaries.
Mistake
A VPN connection between on-premises and cloud is always the best choice because it is cheaper than Direct Connect.
Correct
VPN is cheaper in upfront cost but suffers from variable internet performance, potential packet loss, and bandwidth limits (typically up to 1.25 Gbps per tunnel). For large, steady-state data transfers or latency-sensitive workloads, Direct Connect is the better choice despite higher cost.
Beginners often optimise for first glance cost rather than total cost of ownership including downtime and performance penalties. They overlook that retransmissions on a slow VPN can waste money too.
Mistake
Using a single region with multiple Availability Zones gives the same resilience as using two different regions.
Correct
Multi-AZ protects against data centre failure (e.g., fire in one building), but not against regional failure (e.g., earthquake affecting the entire city). Multi-region provides geographic diversity, which is needed for true disaster recovery and lower latency for global users.
Both architectures involve redundant resources, so beginners confuse the scope of the redundancy. They see 'multiple locations' and assume it's the same level of protection.
Mistake
Once you create a Transit Gateway and attach all VPCs, all traffic between VPCs automatically flows through it with no extra configuration.
Correct
After attaching a VPC to a Transit Gateway, you must also update the route tables in the VPC and in the Transit Gateway to tell traffic where to go. Without explicit routes, the Transit Gateway will not forward traffic, and VPCs cannot reach each other.
Beginners think a Transit Gateway is a 'magic box' that auto-discovers routes. But cloud networking still requires explicit route definitions, similar to configuring a router in a physical office.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Using one account is simpler but risky: it lacks blast radius isolation. If someone accidentally deletes a resource or misconfigures a firewall, the entire environment can be affected. Multi-account design lets you separate workloads so a mistake in the development account does not harm the production system.
VPC Peering creates a direct one-to-one connection between two VPCs and is non-transitive (you cannot route through a third VPC). Transit Gateway acts as a central hub that can connect hundreds of VPCs and supports transitive routing, meaning traffic can flow from VPC A to VPC C through VPC B if the routes are configured.
Use Direct Connect when you need consistent, high-bandwidth connectivity with low latency, such as for large database migrations or real-time data streaming. Use VPN for smaller, bursty traffic or as a backup connection, because it is cheaper but relies on the public internet.
Yes, you can use inter-region VPC Peering or connect Transit Gateways in different regions through inter-region peering. Inter-region VPC Peering works and is supported, but Transit Gateway is more scalable for multiple connections.
Route 53 uses routing policies. For latency-based, it measures the network latency between the user's DNS resolver and each region, then sends traffic to the region with the lowest latency. For geolocation, it routes based on the user's physical location.
An IAM role is a set of permissions that can be assumed by users or services in another AWS account. You create a role in Account A and grant trust permissions to Account B. Then a user in Account B can 'switch' to that role to access resources in Account A without sharing long-term credentials.
You've finished Multi-Region and Multi-Account Network Design. Continue through the ANS-C01 study guide to build a complete picture of the exam.
Done with this chapter?