What all in on AWS looks like when you are a regulated bank

Burning the boats

Capital One started its move to AWS in 2012 and spent roughly eight years dismantling its own infrastructure: eight on-premises data centers closed, nearly 2,000 applications running in the cloud (about 80 percent of them rebuilt from scratch rather than lifted and shifted), and an 11,000-person technology organization retrained around it. By 2020 the company described itself as all in, with no data centers left to fall back to. That is a rare posture for any Fortune 500 company and nearly unheard of for a heavily regulated bank, where examiners expect provable control over every workload and every network path.

The public window into how they made that governable is Cloud Custodian. Capital One built it internally, open sourced it in 2016, and donated it to the CNCF in August 2020. It is a rules engine: you write policies in a simple declarative language (encrypt this, tag that, terminate anything out of compliance) and the engine enforces them continuously across every account. The lesson generalizes beyond the tool. At bank scale, governance cannot be a human reviewing consoles; it has to be policy as code running against the entire estate, with the network itself structured so that the compliant path is the only path that exists.

Capital One has not published a wiring diagram of its internal network, so this study does not pretend to draw one. What it walks instead is the architecture AWS documents for exactly this shape of company: hundreds of accounts under one organization, a central network team, hybrid links back to legacy data centers during a multi-year migration, and a requirement that no application team can route around the controls. That reference design is the multi-account hub and spoke, and it is the backbone of three ANS-C01 tasks.

From eight data centers to a policy-governed landing zoneFullscreen

TraceClose the data centers, rebuild the apps in the cloudPolicy-as-code enforced continuously across every account

Follow a packet through the hub

Start with the account layout, because in this pattern the org chart is the topology. Every workload lives in its own AWS account with its own spoke VPC, carved from a non-overlapping IP plan. A dedicated network services account owns the Transit Gateway, and AWS Resource Access Manager shares it to the organization so spoke accounts can attach their VPCs without ever touching the hub's configuration. The whitepaper is explicit about why: attachments are self-service, but route tables stay under the network team's control. Spoke VPCs get no internet gateways and no NAT gateways of their own; their route tables carry one interesting route, a default pointing at the Transit Gateway attachment.

Now trace a request from the legacy data center to a production workload, the daily reality of an eight-year migration. The packet leaves the on-premises router through a Direct Connect transit VIF into a Direct Connect gateway, which is associated with the Transit Gateway. BGP has already advertised the spoke CIDRs outbound and the data center prefixes inbound, so when the packet arrives at the hub, the route table associated with the hybrid attachment resolves 10.1.0.0/16 to the prod VPC attachment and delivers it. No VPN overlay, no transit VPC full of third-party routers to patch; the hub is a managed regional router that scales to thousands of attachments.

Internet egress runs the same logic in reverse. A dev workload calls an external API; its subnet route table hands the packet to the Transit Gateway, and the route table associated with spoke attachments carries a default route pointing at a central egress VPC in the network services account. There the packet passes through AWS Network Firewall for inspection, gets translated by a NAT gateway, and exits through the only internet gateway in the entire spoke estate. One choke point means one place to log flows, enforce domain allowlists, and show an auditor exactly how every workload reaches the internet.

Segmentation is the quiet superpower. A Transit Gateway holds multiple route tables, and each attachment is associated with exactly one, so prod attachments can use a table that simply never learns dev routes. Isolation becomes a routing-domain decision made once in the hub account instead of a security-group hope repeated in hundreds of spokes. One Transit Gateway per Region is the norm (it is highly available by design), with inter-Region peering to extend the hub globally, and Organizations SCPs plus policy-as-code tooling in the management account keep spoke teams from quietly attaching an internet gateway and undoing the whole design.

Multi-account hub and spoke: one Transit Gateway, three spokes, one way outFullscreen

TraceOn-prem to prod over Direct ConnectDev workload reaches an external API through central inspection and the one IGW

What this teaches for the exam

Task 1.6 is about choosing connectivity patterns across many accounts, Regions, and VPCs, and this architecture is the default answer the exam wants you to reason from. VPC peering is non-transitive and collapses into a full mesh past a handful of VPCs; a transit VPC of appliances is legacy; PrivateLink is for exposing a single service, not a routing domain. When the scenario says dozens of accounts, shared hybrid connectivity, and centralized control, the answer is a Transit Gateway hub, and the follow-up trap is IP planning: hub and spoke only works cleanly when spoke CIDRs do not overlap, so allocate ranges up front.

Task 2.2 is the implementation detail this study walked. Know the mechanics cold: the Transit Gateway lives in a network account and is shared through AWS RAM within the Organization; spokes create attachments to it; association determines which route table an attachment consults, while propagation determines which tables learn the attachment's routes. Hybrid connectivity arrives as a Direct Connect gateway association on a transit VIF or as a VPN attachment, both exchanging routes over BGP. When connectivity fails after a change, Route Analyzer and Reachability Analyzer are the exam's expected diagnostic tools, and both exist precisely because hub-and-spoke route tables are where misconfigurations hide.

Task 4.1 asks you to meet security and compliance requirements with network features, and the regulated-bank framing is the whole point. Centralized egress with Network Firewall inspection, spoke VPCs stripped of internet gateways, flow logs at one choke point, and route tables that make prod-to-dev traffic unroutable are all network features doing compliance work. Capital One's broader lesson caps it: controls that scale are automated, not manual. When an exam scenario mentions auditors, regulated data, or preventing teams from bypassing inspection, look for the answer that removes the non-compliant path structurally (no IGW, segmented route tables, SCPs) rather than the one that adds another review step.

TGW route domains: association vs propagation, hybrid attachments, and diagnosticsFullscreen

TraceAssociation: the prod attachment consults only the prod route table (which never learns dev routes)Propagation: on-prem prefixes learned through the hybrid attachment into the prod table