# Network Architecture for Complex Organizations

> Chapter 5 of the Courseiva AWS-SAP-C02 curriculum — https://courseiva.com/learn/aws-sap-c02/network-architecture-for-complex-organizations

**Official objective:** 2.2 — Define network infrastructure for complex, multi-account organizations

## Introduction

If you get the network architecture wrong in a large organisation, you risk data breaches, unusably slow applications, and audit failures that can cost millions. Network architecture for complex, multi-account organisations is the blueprint that lets thousands of employees, dozens of business units, and countless cloud services talk to each other securely and efficiently — all while keeping the bad guys out and the auditors happy. For the SAP-C02 exam, mastering this means you can design the backbone that holds an entire enterprise's cloud infrastructure together.

## The Corporate Campus Mailroom Analogy

A sprawling corporate campus with dozens of separate buildings, each belonging to a different department that must share resources while maintaining strict security.

The mailroom sits at the campus entrance, receiving all packages and letters. This is your internet gateway. Each building has its own internal mail system for local deliveries — that is a subnet or virtual private cloud (VPC). Some departments, like Finance and HR, are in separate wings with their own locked entrances and dedicated mail slots: these are separate AWS accounts with their own virtual networks.

To send a confidential document from Finance to Legal, you don't hand it to the public postal service. Instead, a private courier drives directly between the two buildings using a secure, dedicated road — this is a VPC peering connection or AWS Transit Gateway, allowing direct, secure communication without traversing the public internet.

The campus also has a shared resource centre — like a printing hub or a server room — that all buildings can access, but only through approved, audited pathways. This mirrors shared services VPCs or AWS PrivateLink, where resources like databases or directory services are placed in a central account and accessed privately by other accounts.

Finally, the security team monitors every route, logs every delivery, and can block any unauthorised path in real time. This is like AWS Network Firewall, security groups, and network access control lists (ACLs) working together to enforce the organisation's networking policies across the entire multi-account landscape.

## Core explanation

Network architecture for complex, multi-account organisations is about designing the connectivity, security, and management of networks when an organisation uses many AWS accounts at once. A single VPC (Virtual Private Cloud) — your logically isolated section of the AWS cloud — is simple. But enterprises often have dozens or hundreds of accounts: one for development, one for production, one for each business unit, one for security logging, and so on. Each account contains one or more VPCs. The challenge is connecting them correctly.

**Why multiple accounts?**

Organisations use multiple AWS accounts for three main reasons:
- Security isolation: A mistake in a development account shouldn't affect your production systems that handle customer data.
- Administrative boundaries: Different teams manage their own resources without stepping on each other's toes.
- Cost tracking: Each account's bill is separate, making it easy to see which department is spending what.

But this creates a problem: how do services in different accounts (like a web server in one account and a database in another) communicate? You can't just let them talk over the public internet — that's slow and insecure. You need private, fast, and auditable connections.

**Core building blocks**

Here are the key components you need to understand:

- VPC (Virtual Private Cloud): A logically isolated section of AWS where you launch your resources. Think of it as your own private data centre inside AWS.
- Subnet: A range of IP addresses within your VPC. You put resources in subnets to organise them (e.g., a public subnet for web servers, a private subnet for databases).
- Internet Gateway: A gateway that allows resources in public subnets to reach the internet.
- NAT Gateway / NAT Instance: Network Address Translation — allows resources in private subnets to initiate outbound traffic to the internet (e.g., to download software updates) while preventing the internet from initiating connections to them.

**Connecting multiple VPCs across accounts**

There are several ways to connect VPCs across different accounts:

- VPC Peering: A direct, private connection between two VPCs. It uses no internet, no gateways — just AWS's private backbone. But it is a one-to-one connection. If you have 10 VPCs, you need a messy mesh of peering connections.
- AWS Transit Gateway: A central hub that connects many VPCs, VPNs, and on-premises networks. Instead of 90 individual connections for 10 VPCs, you connect each VPC once to the Transit Gateway. This is the enterprise standard.
- AWS PrivateLink: Allows you to expose a service in one VPC to other VPCs (or on-premises) as if it were inside their own VPC, without going through the public internet. Great for shared services like a central directory or a database.
- VPN (Virtual Private Network): An encrypted connection over the internet from your on-premises network to your AWS VPCs. Used to extend your corporate network into the cloud.
- Direct Connect: A dedicated, private physical fibre connection from your office or data centre to AWS. Faster and more reliable than a VPN, but more expensive and takes weeks to set up.

**How it works in practice**

Imagine a company with three AWS accounts: Production, Development, and Shared Services. The Shared Services account hosts a central Active Directory (user authentication) and a logging server. The Production account hosts the customer-facing website. The Development account hosts a test version of the website.

You create a Transit Gateway in the Shared Services account. Then you attach the VPC from each account to the Transit Gateway. Now, traffic can flow: the Production web server can reach the central database (also in Production), and it can also authenticate users against the Active Directory in Shared Services — all via private IP addresses, over the Transit Gateway. The Development team can do the same, but their traffic never touches the Production VPC unless you explicitly allow it with route tables.

**Security and routing**

You control traffic using:
- Route tables: Tell each subnet or VPC how to send packets. For example, you add a route in the Production VPC's route table: "All traffic destined for 10.0.0.0/8 (the shared services range) should go via the Transit Gateway."
- Security Groups: Stateful firewalls attached to resources like EC2 instances. They allow or deny traffic based on IP addresses, protocols, and ports.
- Network ACLs: Stateless firewalls attached to subnets. They evaluate traffic entering and leaving a subnet.
- Resource Access Manager (RAM): Allows you to share resources like Transit Gateways or PrivateLink endpoints across accounts without having to manually configure them in each account.

**What this replaces**

Before cloud, organisations had physical networks with cables, switches, and routers in data centres. If you needed to connect two departments, you ran physical cables and configured hardware. Changing anything took weeks. This architecture replaces all of that with software-defined networking: you create, connect, and secure networks in minutes, all through code or the AWS Management Console. It also replaces the need for complex VPN meshes between offices by centralising connectivity through a Transit Gateway.

## Real-world context

A real-world IT professional, let's call her Priya, is a cloud architect at a large retail company. The company has three physical stores, a central warehouse, and a growing online business. They already have an on-premises data centre with legacy applications. The board has mandated that all new applications must run in AWS, and the existing data centre must connect to the cloud securely.

Priya's first task is to design the network for the AWS side. She knows they will need at least four AWS accounts: Production, Development, Data Analytics, and Security. Each account will have its own VPC. She also needs to connect the on-premises data centre to AWS so that inventory databases can sync with the cloud-based ordering system.

Step-by-step, here is what Priya does:

1. **Create a Transit Gateway in the Security account.** This centralises all routing. She attaches each VPC to the Transit Gateway using Resource Access Manager, so the other accounts don't need their own Transit Gateways.

2. **Set up Direct Connect.** Priya works with a telecom provider to install a dedicated fibre line from the data centre to an AWS Direct Connect location. She then creates a Virtual Private Gateway on the AWS side and connects it to the Transit Gateway. Now, the on-premises network can reach any VPC in any account through the Transit Gateway.

3. **Design the shared services VPC.** In the Security account, she creates a VPC with an AWS Managed Microsoft Active Directory (for user logins) and a central logging server. She uses PrivateLink to expose the Active Directory as an endpoint service. Other accounts subscribe to this endpoint, so their EC2 instances can authenticate users without the traffic ever leaving the AWS network.

4. **Implement network segmentation.** In the Production VPC, she creates multiple subnets: a public subnet for a load balancer, a private subnet for application servers, and a data subnet for databases. She uses Security Groups to allow traffic only on specific ports: the load balancer can talk to the app servers on port 443, the app servers can talk to the database on port 3306 (MySQL), and nothing else.

5. **Enable traffic inspection.** The company's security policy requires inspecting all traffic between VPCs for malware. Priya sets up an AWS Network Firewall in the Security account's Transit Gateway. All traffic passing through the Transit Gateway is forced to go through the firewall for inspection before reaching its destination. She also configures VPC Flow Logs to capture metadata about every packet, which feeds into a security information and event management (SIEM) tool for analysis.

6. **Add a VPN backup.** In case the Direct Connect line goes down, Priya sets up a site-to-site VPN from the on-premises firewall to the Transit Gateway. If Direct Connect fails, traffic automatically fails over to the VPN with little interruption.

7. **Create a network baseline.** Priya uses AWS CloudFormation to template the entire network setup — VPCs, subnets, route tables, Transit Gateway attachments, firewall rules. This makes it reproducible and auditable. She stores the templates in a code repository, so every change is tracked.

Priya's design means the online store can scale globally, the warehouse can sync inventory in real time, and the security team has full visibility into every packet crossing the network. When a new project starts, the team creates a new AWS account, and Priya simply attaches its VPC to the existing Transit Gateway — no manual cabling or weeks of waiting. This is what a real IT professional does: designs for scale, security, and operational efficiency using the building blocks we have discussed.

## Exam focus

The SAP-C02 exam tests 'Network Architecture for Complex Organizations' heavily. Expect to see several scenario-based questions where you must choose between VPC Peering, Transit Gateway, PrivateLink, or VPN. The exam is not about memorising definitions — it's about applying them to a business problem.

**Question types that appear:**

- Centralised vs. decentralised connectivity: Which service should you use to connect 20 VPCs across 5 accounts? The correct answer is almost always Transit Gateway. VPC Peering does not scale — you would need 190 peering connections for 20 VPCs. Transit Gateway needs only 20 attachments.
- Connectivity to on-premises: Given a need for consistent latency, high bandwidth, and private connectivity, choose Direct Connect over VPN. If the scenario says "cost-sensitive" and "moderate security", VPN might be acceptable.
- Service exposure: When a company wants to expose a shared service (like a database or an Active Directory) to multiple accounts without making it internet-accessible, the answer is PrivateLink. The trap answer is VPC Peering, because with Peering, the service is still in the provider's VPC and accessible only if you manage complex route tables. PrivateLink makes the service appear inside the consumer's VPC.
- Traffic inspection: Where to place a firewall for inspecting traffic between VPCs? Correct: Attach a Network Firewall to the Transit Gateway and force all transit traffic through it. Or use a centralised egress VPC with a firewall appliance.

**Exam traps to watch for:**

- The 'Transit Gateway is not needed' trap: A question might describe only 2-3 VPCs. Do not automatically choose VPC Peering just because it's simpler. If the scenario says 'future growth to 20 VPCs' or 'centralised security inspection required', Transit Gateway is still correct.
- The 'Direct Connect is always best' trap: Direct Connect is fast and private but expensive and takes weeks to provision. If the scenario says 'quick setup' or 'low cost', VPN is the right choice.
- The 'PrivateLink only for AWS services' trap: PrivateLink can expose any service running on an internal Network Load Balancer, not just AWS-managed services. Do not limit it to AWS services.
- The 'Internet Gateway for private subnets' trap: Resources in private subnets cannot have a direct route to the internet gateway. They need a NAT Gateway or a NAT instance in a public subnet to reach the internet for outbound requests.

**Key definitions to memorise:**

- Stateful vs. Stateless: Security Groups are stateful (if you allow inbound traffic, the response is automatically allowed outbound). Network ACLs are stateless (you must define both inbound and outbound rules separately).
- Route propagation: When using a Transit Gateway or a Virtual Private Gateway, route tables can automatically learn routes from connected networks.
- Edge associations: A Transit Gateway can have an 'association' with a Direct Connect Gateway, enabling on-premises networks to reach all attached VPCs through a single connection.

**What is NOT tested:**

- Deep hands-on configuration of individual routers or switches (this is not a networking exam).
- On-premises routing protocols like OSPF or BGP in detail — you just need to know they exist and that BGP is used for route exchange between Direct Connect and Transit Gateway.

Focus your study time on understanding when to use each connectivity option and the scaling implications. Practise with sample questions that give you a company size and a list of requirements, and force yourself to pick the best network design.

## Step by step

1. **Plan your account structure** — Decide how many AWS accounts you need and what each will contain. Common patterns: separate accounts for Production, Development, Shared Services, Security, and Logging. This creates clear boundaries and simplifies cost tracking. Plan which VPCs and subnets each account will host.
2. **Create a Transit Gateway in the shared services or security account** — The Transit Gateway acts as the central routing hub. Create it in an account that can be shared via Resource Access Manager (RAM). Then share the Transit Gateway with all other accounts that need to connect their VPCs.
3. **Attach each VPC to the Transit Gateway** — In each account, create a Transit Gateway Attachment from the VPC to the shared Transit Gateway. This is like plugging each building into the campus's central road network. You control which subnets in each VPC can reach the Transit Gateway by configuring route tables.
4. **Configure route tables for traffic flow** — In each VPC's route tables, add routes that direct traffic destined for other VPCs or the shared services VPC to the Transit Gateway. Without these routes, traffic has no path. Similarly, configure the Transit Gateway's route table to know which VPC each IP range belongs to.
5. **Set up PrivateLink for shared services** — In the shared services VPC, create an internal Network Load Balancer for each shared service (e.g., Active Directory, logging API). Then create a VPC Endpoint Service (PrivateLink) and share it with consumer accounts via RAM. Consumers create VPC Endpoints in their own VPCs to access the service privately.
6. **Establish on-premises connectivity** — Decide between Direct Connect (dedicated fibre) or VPN (over the internet). Create a Virtual Private Gateway or Transit Gateway attachment to the Direct Connect Gateway. Then ensure the on-premises network advertises its IP ranges via BGP so that AWS knows where to send traffic.
7. **Implement security and monitoring** — Attach a Network Firewall to the Transit Gateway to inspect inter-VPC traffic. Enable VPC Flow Logs on all subnets. Set up Security Groups and Network ACLs on each resource and subnet. Create an AWS CloudTrail trail in the security account to log all API calls for auditing.

## Comparisons

### VPC Peering vs Transit Gateway

**VPC Peering:**
- Direct one-to-one connection between two VPCs only.
- Does not support transitive routing (cannot route through a third VPC).
- Scales poorly — for 10 VPCs you need 45 peering connections.

**Transit Gateway:**
- Hub-and-spoke central hub connecting many VPCs and on-premises networks.
- Supports transitive routing: traffic can go from VPC A through the hub to VPC C.
- Scales elegantly — each VPC connects once to the central hub.

### Direct Connect vs Site-to-Site VPN

**Direct Connect:**
- Dedicated physical fibre line: low latency, consistent bandwidth.
- Takes weeks to provision due to carrier setup.
- More expensive due to monthly port charges and carrier fees.

**Site-to-Site VPN:**
- Encrypted tunnel over the public internet: latency varies with internet conditions.
- Can be set up in minutes or hours using existing internet connections.
- Lower cost — only pay for data transfer out of AWS (no port fees).

### Security Group vs Network ACL

**Security Group:**
- Stateful firewall attached to resources (e.g., EC2 instances).
- Rules are evaluated as a whole; the last rule in the list does not override earlier rules.
- Only supports allow rules (no explicit deny).

**Network ACL:**
- Stateless firewall attached to subnets.
- Rules are evaluated in order from lowest number to highest; the first matching rule applies.
- Supports both allow and deny rules.

### Internet Gateway vs NAT Gateway

**Internet Gateway:**
- Allows resources with public IPs to communicate directly with the internet (bi-directional).
- Attached to a VPC, not a subnet.
- Required for any resource that needs to be reachable from the internet.

**NAT Gateway:**
- Allows resources in private subnets to initiate outbound internet traffic only.
- Placed in a public subnet; routes private subnet traffic through it.
- Resources behind it cannot be reached directly from the internet.

## Diagram

_A typical multi-account network architecture using a central Transit Gateway, Direct Connect/VPN for on-premises connectivity, and PrivateLink for shared services._

```mermaid
flowchart TD
    A[On-Premises Data Centre] -->|Direct Connect or VPN| B[AWS Transit Gateway]
    B --> C[Shared Services VPC (Security Account)]
    B --> D[Production VPC (Prod Account)]
    B --> E[Development VPC (Dev Account)]
    C --> F[PrivateLink Endpoint Service]
    D --> G[VPC Endpoint for PrivateLink]
    E --> H[VPC Endpoint for PrivateLink]
    F --> G
    F --> H
    A -->|Internet backup| I[Site-to-Site VPN]
    I --> B
```

## Common misconceptions

- **Misconception:** VPC Peering is the best way to connect any two VPCs in any situation. **Reality:** VPC Peering only works for a small number of VPCs. For 10+ VPCs, Transit Gateway is far easier to manage because it provides a central hub-and-spoke model instead of a messy mesh of peering connections. (Beginners see VPC Peering as the first option they learn and assume it scales. They don't realise that each peering is a separate manual setup and that transitive routing (routing through a third VPC) is not supported with Peering.)
- **Misconception:** PrivateLink only works with AWS-managed services like S3 or DynamoDB. **Reality:** PrivateLink can expose any service running on an internal Network Load Balancer, including custom applications or third-party software you run on EC2 instances. (AWS documentation often first introduces PrivateLink for services like S3 and DynamoDB, giving learners a narrow impression. The exam explicitly tests whether you know PrivateLink can be used for customer-owned services.)
- **Misconception:** Security Groups and Network ACLs do the same thing, so you only need one of them. **Reality:** Security Groups are stateful firewalls attached to resources (like an EC2 instance), while Network ACLs are stateless firewalls attached to subnets. You use both for defence in depth. Security Groups are evaluated first, then Network ACLs. (The names sound similar and both control traffic, so beginners assume redundancy. They don't grasp the stateful vs. stateless distinction or the fact that they operate at different layers of the network stack.)
- **Misconception:** Direct Connect is always the right choice for any on-premises to cloud connection because it's the fastest. **Reality:** Direct Connect is fast and private, but it takes weeks to set up, costs more, and requires a dedicated physical line. For many organisations, a site-to-site VPN over the internet is sufficient and more cost-effective. (The exam often presents Direct Connect as the premium option. Beginners overvalue it because it sounds more 'enterprise'. The exam wants you to evaluate trade-offs including time to deploy, cost, and bandwidth requirements.)
- **Misconception:** To give resources in a private subnet internet access, you attach an Internet Gateway directly to that subnet. **Reality:** An Internet Gateway is attached to the VPC as a whole, not to individual subnets. Resources in private subnets cannot use it directly. Instead, you place a NAT Gateway in a public subnet and route the private subnet's outbound traffic through it. (The name 'Internet Gateway' makes beginners think it's like a public Wi-Fi hotspot you can plug into anywhere. The routing mechanics (route tables directing traffic) are not intuitive to new learners.)

## Key takeaways

- Transit Gateway is the central hub for connecting multiple VPCs and on-premises networks in a scalable hub-and-spoke design, replacing the need for dozens of VPC Peering connections.
- PrivateLink exposes a service in one VPC to other VPCs as if it were native to their network, without traversing the internet, and works for both AWS-managed and custom services.
- Security Groups are stateful firewalls attached to resources, while Network ACLs are stateless firewalls attached to subnets — both are needed for defence in depth in a multi-account architecture.
- Direct Connect provides consistent, low-latency private connectivity to AWS but takes weeks to provision; VPNs are faster to set up and cheaper, but subject to internet variability.
- Resource Access Manager (RAM) allows you to share resources like Transit Gateways and PrivateLink endpoint services across accounts without manual duplication.
- Network Firewall can be attached to a Transit Gateway to inspect all traffic flowing between VPCs in a multi-account environment for security compliance.
- VPC Flow Logs capture metadata about IP traffic and are essential for troubleshooting connectivity issues and performing security audits across your multi-account network.
- Route tables in each VPC and subnet control where traffic flows; incorrect route tables are the most common source of connectivity failures in complex architectures.

## FAQ

**What is the difference between VPC Peering and Transit Gateway?**

VPC Peering connects two VPCs directly, without transitive routing (you cannot route through a third VPC). Transit Gateway acts as a central hub that can connect many VPCs and on-premises networks, allowing transitive routing and centralised security inspection.

**Can I use one Transit Gateway across multiple AWS accounts?**

Yes. You create the Transit Gateway in one account (the owner account) and share it with other accounts using AWS Resource Access Manager (RAM). Each account can then attach its VPCs to the shared Transit Gateway.

**What is PrivateLink and when should I use it?**

PrivateLink lets you expose a service in one VPC to other VPCs as if it were inside their own network, without using the internet. Use it for shared services like databases, directories, or APIs that multiple accounts need to access securely.

**Do I need both a Security Group and a Network ACL?**

Yes, for defence in depth. Security Groups are stateful and attached to resources; they allow or deny traffic based on rules. Network ACLs are stateless and attached to subnets; they provide an additional layer of filtering for all traffic entering or leaving a subnet.

**What is the difference between a NAT Gateway and an Internet Gateway?**

An Internet Gateway allows resources with public IP addresses to directly communicate with the internet. A NAT Gateway allows resources in private subnets to initiate outbound internet traffic (like downloading updates) while keeping them unreachable from the internet.

**How do I connect my company's office to AWS?**

You have two main options: a site-to-site VPN (encrypted tunnel over the internet, quick to set up, lower cost) or AWS Direct Connect (dedicated private fibre line, high bandwidth, low latency, but weeks to provision and more expensive). Choose based on your speed, reliability, and budget needs.

## Check your understanding

1. **Which AWS service should you use to connect 25 VPCs across 10 accounts in a scalable, hub-and-spoke design?**

   Answer: AWS Transit Gateway. It allows each VPC to connect once to a central hub, avoiding the complex mesh of hundreds of VPC Peering connections.

2. **You need to expose a custom internal application running on EC2 in one VPC to multiple other VPCs without making it internet-accessible. Which service should you use?**

   Answer: AWS PrivateLink. Create a Network Load Balancer in front of the application, then create a VPC Endpoint Service and share it with the other VPCs via Resource Access Manager.

3. **What is the key difference between Security Groups and Network ACLs in terms of statefulness?**

   Answer: Security Groups are stateful: if you allow inbound traffic, the response is automatically allowed outbound. Network ACLs are stateless: you must define separate rules for both inbound and outbound traffic.

4. **A company needs a dedicated, low-latency connection from its on-premises data centre to AWS but can wait several weeks for setup. Which connectivity option is best?**

   Answer: AWS Direct Connect. It provides a dedicated physical fibre line with consistent performance, but requires carrier provisioning that takes weeks.

5. **How do you provide outbound internet access to resources in a private subnet?**

   Answer: Place a NAT Gateway in a public subnet, and add a route in the private subnet's route table directing 0.0.0.0/0 traffic to the NAT Gateway. The NAT Gateway then forwards traffic to the Internet Gateway.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-sap-c02/network-architecture-for-complex-organizations