Sign in Get started

Cloud Networking in Production · Capstone Case Studies

Capstone: A Network for a Growing Company

Twenty AWS accounts, two offices, a data centre and an Azure deployment on the way. Design the network so it can grow and stay secure.

Create a free account to save this page, take notes and track your progress. Sign in

Scenario

Example company: a fintech scale-up has grown from one AWS account to 20 (prod, staging and dev per product team), each with its own VPC built from a template: all of them 10.0.0.0/16. It has two offices on 192.168.0.0/16 ranges, a data centre for card processing, and has signed a customer requiring an Azure deployment.

Today: teams connect through public endpoints with IP allow-lists; each VPC has its own NAT gateways and internet gateways; DNS is public-only.

Requirements

  • Private connectivity between products, offices and the data centre, with segmentation (dev can't reach prod).
  • Centralised, inspected egress to the internet; partners allow-list a small, fixed set of IPs.
  • Private DNS that works across accounts, offices and Azure.
  • Room for 5× growth over three years.

Deliverables

  1. Address plan and how you get from today's overlapping VPCs to it.
  2. Connectivity design (accounts, offices, data centre, Azure).
  3. Egress and inspection design.
  4. DNS design.
  5. How teams get new networks safely and quickly.

Hints

  • Overlap blocks everything else; deal with it first, without a big-bang re-IP.
  • A hub with route-table segmentation scales better than a peering mesh.
  • Fixed egress IPs suggest centralised NAT.

Draft each deliverable before revealing the model answer and rubric.

Further reading: AWS Transit Gateway · Azure hub-spoke topology · Route 53 Resolver

Deliverables

Address plan and migration.

Model answer

  • Reserve 10.64.0.0/10 for AWS (per region a /12, per account a /16 or /20 from VPC IPAM pools by environment), 10.128.0.0/12 for Azure, and keep offices and the data centre in their own documented ranges.
  • New VPCs come only from IPAM. Existing 10.0.0.0/16 VPCs get a secondary CIDR from the plan; new subnets are created there and workloads move gradually (blue/green per service). Until a VPC is migrated, it reaches shared services through PrivateLink, which tolerates overlap.
  • Pods use 100.64.0.0/10 secondary ranges that are never routed outside their VPC.

Rubric

Full marks: a central plan covering all clouds and on-premises, IPAM enforcement, and an incremental migration (secondary CIDRs, PrivateLink bridge) rather than a big-bang re-IP.

Connectivity design.

Model answer

  • AWS: a Transit Gateway per region in a network account, shared with AWS RAM. Separate TGW route tables for prod, nonprod and shared: prod attachments propagate to prod and shared only, so dev can't route to prod.
  • Data centre: Direct Connect (two connections, two locations) to a Direct Connect gateway attached to the TGW, with Site-to-Site VPN as backup. Offices: VPN to the TGW (or SD-WAN).
  • Azure: a hub VNet (or Virtual WAN hub) with spokes per product; connect to AWS with site-to-site VPN between TGW and Azure VPN Gateway (or both clouds to the data centre over Direct Connect/ExpressRoute).

Rubric

Full marks: hub-and-spoke with route-table segmentation, redundant private links with VPN backup, and a clear Azure equivalent. Deduct for a full peering mesh or for flat routing between environments.

Egress and inspection design.

Model answer

An egress VPC in the network account with NAT gateways (Elastic IPs that partners allow-list) behind AWS Network Firewall (domain allow-lists, IDS rules). Spoke VPCs have no internet gateways for outbound traffic; their default route points to the TGW, which sends 0.0.0.0/0 to the inspection/egress VPC. Inbound internet traffic still terminates on public load balancers in each product account (behind WAF/CloudFront). S3 and DynamoDB use gateway endpoints locally; other AWS APIs use shared or local interface endpoints to avoid NAT costs.

Rubric

Full marks: centralised NAT with fixed IPs, inspection, no per-spoke internet egress, endpoints for cloud APIs. Mention the NAT port limits per destination and plan IP counts.

DNS design.

Model answer

  • Private hosted zones per product (payments.internal.example) shared to the accounts that need them; a central Route 53 Resolver in the network account with inbound endpoints (offices and Azure query AWS names) and outbound endpoints with forwarding rules shared via RAM (corp.example to office DNS, azure.example to Azure DNS Private Resolver).
  • Azure: Private DNS zones linked to the hub, DNS Private Resolver forwarding AWS zones to the AWS inbound endpoint.

Rubric

Full marks: private zones, bidirectional resolver endpoints with shared forwarding rules, and symmetrical Azure design.

How do teams get new networks safely and quickly?

Model answer

A Terraform module (or account-vending pipeline) that requests a range from IPAM, creates standard subnets across three zones, attaches to the right TGW route table by environment tag, associates DNS rules, enables flow logs and applies baseline security groups. Service control policies stop teams from creating internet gateways, peering connections or VPCs outside the module. Changes to shared network components go through the network team's review.

Rubric

Full marks: self-service through code with guardrails (IPAM, SCPs), not tickets; secure defaults built in.

Open in the app to mark lessons complete, take notes and track your progress.

Was this page helpful?