AWS Cloud
Deep dives into AWS networking and infrastructure — what a service actually is and isn't, the managed reality underneath, and where it fits against the alternatives. Honest expectations, real diagrams, every claim sourced.
Shaping the SD-WAN Fabric on AWS, Part A: The Regional Hub and Keeping Traffic Symmetric
One regional-hub design — where the SD-WAN appliance pair attaches, how it survives losing a node without becoming a single-flow bottleneck, and how every return packet finds its way back to the same firewall — built once on Transit Gateway and once on Cloud WAN, so you see the same design in two realizations (only the resource names change). The hub is a routing statement, not a product: active/active means both appliances advertise the same prefixes with the same AS-PATH so the fabric installs ECMP; active/standby is a longer AS-PATH. ECMP is per-flow, so '20 Gbps aggregate' never means 20 Gbps for one connection — a single flow pins to one Connect peer at ≤5 Gbps; size for flow count. Return-path symmetry is a per-attachment flag (TGW appliance mode / Cloud WAN NFG) and forgetting it is the classic silent asymmetric drop; GWLB is the other way to build the pair, with fail-open and rebalance defaults you must set on purpose. Part A of the design tier of the SD-WAN-on-AWS series; every number sourced against current AWS docs.
SD-WAN Meets AWS: Five Ways Into the Cloud, One Fabric Riding BGP
The AWS side of an SD-WAN rollout isn't one integration — it's five, and they look alike on a slide but diverge hard on bandwidth, encryption, and cost. What SD-WAN actually is beneath the marketing (a control/data-plane split that turns any transport into one encrypted overlay), the BGP every option rides (eBGP between your AS and AWS's, with ECMP across paths as the only way past a single tunnel's ceiling), and the complete map of the five doors: IPsec VPN → Transit Gateway (encryption built in, ~5 Gbps/tunnel), TGW Connect (GRE + BGP, 20 Gbps, trust the underlay), Cloud WAN Connect (global reach + segmentation, tunnel-less up to 100 Gbps/AZ), the vendor appliance on EC2 (full parity, but you run and scale it), and Direct Connect as the private underlay that carries the others rather than terminating anything itself. The real axis is encapsulation versus bandwidth. Article 1 of an SD-WAN-on-AWS series; every number sourced against current AWS docs.
IPv6 in AWS: It's Decided by Routing and Security Groups, Not the Address
Turning on IPv6 in AWS isn't 'IPv4 with longer addresses' — five reflexes break. There's no NAT and no private range, so a subnet is public or private purely by where you route ::/0 (::/0 → internet gateway is public-by-default; ::/0 → egress-only gateway is the outbound-only NAT stand-in that translates nothing); IPv6-only subnets still reach IPv4 via DNS64 + NAT64 (64:ff9b::/96, automatic on the NAT gateway); security groups are per-address-family, so your IPv4 rules do nothing for IPv6 and you fail open or closed; and the reason to do it now is cost — public IPv4 bills $0.005/hr since Feb 2024. Dual-stack to migrate, IPv6-only to stop paying. The whole model in one VPC diagram, then each break greyed-in. Every claim sourced.
AWS Firewall Manager: A Control Plane That Isn't a Firewall
It never inspects a packet — it's the service that stamps AWS WAF, Shield Advanced, security groups, Network Firewall, and DNS Firewall (plus Palo Alto / Fortinet) across every account in your organization and keeps them there. The three stores of truth it rides (Organizations owns membership, AWS Config owns detection, FMS owns intent), why the management account can't be the policy admin, every policy type and what it deploys, the Network Firewall building-blocks chain (IP sets to rule groups to firewall policy to the FMS wrapper to endpoints), scope-detect-remediate, the Config-everywhere cost that dwarfs the fee, and a full setup walkthrough. Every claim sourced.
AWS Owns One End: Building Direct Connect From the On-Prem Side
From the cross-connect patch outward — router, optics, VLANs, BGP, routing policy, encryption — Direct Connect is your build, and that's exactly where every bring-up fails. The demarcation at the cross-connect, dedicated vs hosted, standing up each VIF (VLAN / BGP / ASN / MD5), the 100-route limit and MTU traps, and resiliency (two locations, BFD, LAG) plus encryption (MACsec vs IPsec over a public VIF) — with verbatim Cisco IOS-XE and Juniper Junos config. Every claim sourced.
AWS Control Tower, End to End: The Managed Landing Zone and Where It Bites
One managed service wires AWS Organizations, IAM Identity Center, Config, CloudTrail and StackSets into a governed multi-account landing zone — here's every moving part, and the honest limits. The fixed account skeleton, the three kinds of control (preventive / detective / proactive), how accounts get vended, how drift is caught, Region governance and the 'opting out isn't blocking' misconception, what AWS Config actually costs, and when you outgrow it into Landing Zone Accelerator. Every claim sourced.
One Guarded Door: An F5 Egress Proxy in a Centralized Egress VPC
Send every account's outbound traffic through one inspected exit per region — an F5 BIG-IP behind a Gateway Load Balancer — across a multi-region, multi-account estate, with every traffic flow drawn out. The two insertion models (transparent GENEVE targets vs an explicit forward proxy), why appliance mode and 5-tuple preservation are the load-bearing settings, the honest F5-vs-Network-Firewall call, keeping egress regional, and the SCP that makes the guarded door the only door. Every claim sourced.
What AWS Cloud WAN Actually Is (and Isn't)
A design & decision deep dive into AWS Cloud WAN: the object model (global network vs. core network vs. core network edge), the managed-Transit-Gateway reality underneath, the single global policy with tag-based segmentation and native cross-region dynamic routing, and where it earns its keep versus where plain TGW is still the right call. Honest expectations — it adds one global policy, tag segmentation, and auto-meshed cross-region routing, but it does not delete your firewalls, replace MPLS/SD-WAN, or reduce attachment count — with real limits, pricing (~30% premium, $0.50/hr per CNE), and AWS-reference diagrams. Every claim sourced.
AWS Cloud WAN: The Core Network Policy, Section by Section
Article 2 of the AWS Cloud WAN series — a deep dive into the core network policy JSON document, the single artifact that IS the product. Every top-level section walked in order (eight of them, two required, including the new attachment-routing-policy-rules from 2025.11): where the network lives (Regions, ASNs, addressing), how segments wall traffic off (deny by default), how an attachment's own tags pick its segment, how segment actions move routes across boundaries, and what the 2025.11 routing-policy layer adds — with its sharp limits (BGP communities on VPN + Connect only, excluded on Direct Connect and TGW peering). Plus the version → change-set → live/rollback model that makes change management behave like git. Conceptual diagrams; every figure and number sourced.
AWS Cloud WAN: Segmentation Design From “What Must Never Happen”
Article 3 of the AWS Cloud WAN series — how to design segments as trust boundaries you'll actually defend, inside the hard limits AWS sets. Start from the question “what traffic must never happen?”, not the org chart: each plain-English “never” rule compiles to an isolated or unshared boundary. The two strategies (environment-based vs. application-based) and the middle path most teams land on; the hard 40-segments-per-core-network ceiling (not adjustable) and the easy-to-miss fact that every inspection Network Function Group quietly spends one of those 40; what the boundaries can and can't express (deny-by-default, isolate-attachments, bidirectional non-transitive sharing, attachment-routes-only); the segment connectivity matrix the policy is transcribed from; and the multi-account glue (acceptance, attachment-tag placement, RAM — with the us-west-2 home-Region vs. us-east-1 share-Region trap). Conceptual diagrams; every figure and number sourced.
AWS Cloud WAN: Attachment Policies & Tag-Based Automation
Fourth in the AWS Cloud WAN series. The segment matrix from Article 3 is just intent until something places each VPC, VPN, or peering into the right segment — that's the attachment policy. This sourced piece covers how an attachment's own tags (not the VPC's) drive placement, the full set of condition types, first-match rule evaluation, and the require-attachment-acceptance gate that keeps tag-based automation from becoming a security hole across hundreds of accounts.
AWS Cloud WAN: Attachment Types in Practice
Fifth in the AWS Cloud WAN series. Article 4 covered how attachments map to segments; this one covers what the attachments actually are — the five ways something connects to a Core Network Edge (VPC, Site-to-Site VPN, Connect/SD-WAN, Transit Gateway peering, Direct Connect gateway), what each is good at, the selection tradeoffs, and the two cross-cutting traps that bite regardless of type: asymmetric stateful inspection (appliance mode) and the per-account AZ-name shuffle (use AZ IDs). Every claim sourced to AWS docs.
AWS Cloud WAN: Hybrid Connectivity with Direct Connect
Sixth in the AWS Cloud WAN series. Hooking the cloud spine to your data centers is the part that bites. Direct Connect can now attach a gateway straight to the core network — but the routing is a BGP exercise, not a Cloud WAN one. Covers how routes flow both ways, why return traffic drifts asymmetric, the symmetry/failover tuning, the constraints that quietly reshape the design, and when to keep DX on a Transit Gateway instead — every claim sourced to AWS docs.
AWS Cloud WAN: Multi-Region Routing
Seventh in the AWS Cloud WAN series. List your Regions and AWS builds a resilient, full-mesh, dynamically-routed network across them with no manual peering — wonderful until traffic takes a path you didn't expect. This piece explains what's actually happening under the abstraction: how the Regional Core Network Edges auto-mesh over eBGP, how one segment spans Regions while routes stay local-preferred, the quiet default that governs exit points, the full best-path ladder (ending in a random tiebreak), and the multi-Region edge cases — random remote edges, per-edge DNS, and asymmetry-plus-inspection drops. Every claim sourced to AWS docs and networking blogs.
AWS Cloud WAN: Service Insertion & Network Function Groups
Eighth in the AWS Cloud WAN series. You've connected and segmented the network — now you need to inspect traffic between the parts. Service insertion, built on the Network Function Group, turns what used to be a static route per VPC into a single policy statement. Covers the construct, its two actions (send-via / send-to), single- vs dual-hop, the inspection-VPC topology (GWLB + firewall appliances), and the multi-region wrong-Region trap with the with-edge-overrides fix — every claim sourced to AWS docs and blogs.
AWS Cloud WAN: Centralized Egress and Ingress Inspection
Ninth in the AWS Cloud WAN series. The most common security design teams build on Cloud WAN is centralized internet egress: instead of a NAT gateway in every VPC, traffic funnels through a few inspected exit points. Covers the route design that pulls spoke traffic to the central VPC (the send-to default-route mechanic), where to place firewalls when Cloud WAN is global but NAT/firewalls are per-region (the cost-vs-latency call and the with-edge-overrides fix for the cross-region detour), and why ingress refuses to ride the same rails — every claim sourced to AWS docs and blogs.
AWS Cloud WAN: East-West Inspection Across Segments
Tenth in the AWS Cloud WAN series. North-south inspection guards the door between your network and the internet; east-west inspection guards the doors inside it — lateral traffic between VPCs and segments that policy says must cross a firewall even though it never leaves AWS. Covers send-via vs share, the automatic route symmetry plus the mandatory appliance-mode tax, intra-segment isolate-then-insert, single-hop vs dual-hop, vendor-agnostic appliances, and an honest word on cost. Every claim sourced to AWS docs and blogs.
AWS Cloud WAN: Migrating off Transit Gateway, Phase 1 — Federation
Eleventh in the AWS Cloud WAN series. Almost nobody builds Cloud WAN on a blank slate — you start with a working Transit Gateway mesh you can't take down. This sourced walkthrough shows how to slide a Cloud WAN core network in underneath that mesh as a dynamic global spine, run both side by side via TGW peering, and keep a rollback at every step — anchored on the one routing fact (static beats dynamic) that makes the cutover safe. Phase 2, the full cutover, is the next article.
AWS Cloud WAN: Migrating off Transit Gateway, Phase 2 — The Cutover
Twelfth in the AWS Cloud WAN series and the sequel to federation. Federation gave you global routing while every workload stayed on its old Transit Gateway; Phase 2 finishes the job — VPCs attach straight to the core network, Direct Connect moves to a native DXGW, and the TGWs come down, all reversible and one workload at a time. A sourced, practitioner-voiced walkthrough of the per-VPC cutover loop, the longest-prefix trick that drains traffic safely, the DX maintenance-window flip, decommissioning, and the honest cost accounting.
AWS Cloud WAN: Managing the Global Policy as Terraform Code
Thirteenth in the AWS Cloud WAN series. Because the entire global network is one declarative policy document, your Terraform is the network and a plan diff is the routing change you're about to make worldwide. Shows how to express the policy in HCL (the aws_networkmanager_core_network_policy_document data source over raw JSON, dynamic blocks for scale), the dummy-base-policy bootstrap, why routing tags must land on the attachment resource (never the VPC), how a terraform apply maps onto Cloud WAN's own version/change-set/rollback model and handles drift, and the two-workspace structure plus the AWS aws-ia module — every claim sourced.
AWS Cloud WAN: Multi-Account Infrastructure-as-Code
Fourteenth in the AWS Cloud WAN series, where the architecture meets the org chart. Shows how to split Cloud WAN by ownership — one networking team owns the core network and policy in a single Terraform workspace and shares it org-wide with AWS RAM (from us-east-1, not Oregon), while every workload account self-serves its own attachments and tags them so the central attachment policy files them into the right segment automatically; plus how to gate a one-line policy change in CI before it reroutes the whole global network. Every claim sourced to AWS docs and AWS's own Terraform module and blueprints.
AWS Cloud WAN: Observability & Troubleshooting
Fifteenth in the AWS Cloud WAN series, and the SRE's chapter. Cloud WAN gives you a centralized, 15-month view of network health — but its telemetry stops at aggregate counters, with no per-flow log like Transit Gateway's. Maps what each signal (CloudWatch metrics, EventBridge events, the route view) actually tells you, where you must reach for VPC flow logs to fill the 5-tuple gap, and a triage decision tree for the failures you'll really hit: missing route, asymmetric inspection, empty NFG, wrong-Region egress, stuck attachment. Every claim sourced to AWS docs.
AWS Cloud WAN: Cost Engineering
Sixteenth in the AWS Cloud WAN series. Cloud WAN's value is operational, not financial — for an equivalent topology it usually costs more than Transit Gateway. This piece makes that concrete: the four things you're billed for (CNE-hours, attachments, peering, $0.02/GB data processing), a worked ~$461.90/month bill where only $2 is data, who pays what across accounts, the federation double-domain charge, and a clean operator-driven test for when the premium earns its keep. Every figure is sourced to AWS's pricing page; the ~30% premium is flagged as a practitioner estimate, not an AWS number.
AWS Cloud WAN: The Reference Architecture
The capstone, seventeenth and last in the series. Sixteen articles built the pieces — concepts, policy, segmentation, attachments, hybrid, multi-Region routing, inspection, migration, IaC, observability, cost. This one assembles them into a single opinionated blueprint for a global, multi-Region, multi-account enterprise, and closes with the framework for whether to build it at all. Every choice traces back to the article that earned it; every number is sourced.
The Complete AWS Cloud WAN Reference Architecture
A companion to the series capstone, written for an architecture review board: a complete, internally-consistent blueprint for a global, multi-Region (us-east-1 / us-west-2 / eu-west-1), multi-account enterprise core network. Five segments with a full allow/blocked/inspected/isolated connectivity matrix; centralized egress (send-to NFG + edge-override for the region with no local stack) and ingress inspection; east-west send-via inspection with appliance-mode symmetry; native Direct Connect Gateway hybrid associated to all three Regions; and existing-Transit-Gateway federation. One master topology plus ten hop-by-hop traffic-flow diagrams in real AWS icons, each tracing the VPC route-table decision, the CNE segment lookup, the NFG redirect, appliance-mode AZ pinning, and the symmetric return. Every assertion traced to a fact id or AWS document.
No posts match — try a different keyword or clear the filters.