AWS Site-to-Site VPN: Connecting On-Prem to a VPC, Hands-On (BGP, HA, Tunnels)

Quick take: An AWS Site-to-Site VPN is one managed VPN connection made of exactly two IPsec tunnels that runs an encrypted link between your data centre and AWS over the public internet. You describe your on-prem device to AWS as a Customer Gateway (CGW) — its public IP and BGP ASN — and AWS terminates the tunnels on either a Virtual Private Gateway (VGW), which serves one VPC, or a Transit Gateway (TGW) attachment, which serves many. Getting a tunnel to say UP is an IKE/IPsec parameter-matching exercise; getting traffic to flow is a routing exercise — BGP (or static routes) plus route propagation into the VPC route table, plus security groups and NACLs that permit the on-prem CIDR. Those are two different problems, and conflating them is why “the tunnel is up but nothing works” is the single most common hybrid-networking ticket.

You have an application in a VPC and a database — or an Active Directory, or a licence server, or a mainframe — still sitting in a data centre, and the two need to talk privately. Sending that traffic across the open internet in plaintext is a non-starter, and provisioning a Direct Connect circuit takes weeks and a cross-connect order. What you want is an encrypted link you can stand up this afternoon, that survives an AWS maintenance event without dropping the connection, that fails over automatically, and that you can prove is healthy from a dashboard. That is exactly what Site-to-Site VPN is for: IPsec over the internet, two tunnels for high availability, BGP for automatic failover, billed by the hour with no upfront commitment.

The trap is that a Site-to-Site VPN looks simple — the console has a “Create VPN Connection” button and a “Download Configuration” file for your specific device — and then bites you on the details. The tunnel refuses to come up because one Diffie-Hellman group doesn’t match, or a corporate firewall silently drops UDP 4500. The tunnel comes up but no packets cross because you never propagated the routes, or the security group has no inbound rule for the on-prem subnet. Large file transfers hang while pings succeed, because nobody clamped the TCP MSS for the reduced tunnel MTU. BGP won’t establish because the APIPA addresses or the ASN are wrong. Every one of these is a five-minute fix once you know where to look, and a lost afternoon if you don’t.

This article builds the mental model and then builds the connection. You will learn every moving part — CGW, VGW, TGW attachment, the two tunnels and how HA actually works (active/active vs active/standby, different endpoints, different AZs), the full IKEv1/IKEv2 and IPsec phase-1/phase-2 parameter set and every tunnel option (DPD, DH groups, rekey, replay window, startup action), static vs dynamic (BGP) routing and route propagation, accelerated VPN via Global Accelerator, migrating a VGW to a TGW without touching your on-prem device, when to reach for Direct Connect instead (and VPN-over-DX to encrypt it), the separate Client VPN product for remote users, and the CloudWatch TunnelState telemetry that tells you it is all working. Then you build the whole thing hands-on against a simulated on-premises — a second VPC running strongSwan on an EC2 instance as the customer gateway — bring both tunnels UP, establish BGP, ping across, verify the propagated routes, all with aws ec2 CLI and Terraform, and tear it down before the hourly meter runs up a bill. This maps directly to the networking domains of SAA-C03 and the Advanced Networking – Specialty (ANS-C01) exam, both of which lean hard on the tunnel/HA/BGP model.

What problem this solves

The core problem is private, encrypted, resilient connectivity between an on-premises network and a VPC, stood up in hours, not weeks. Plenty of workloads are genuinely hybrid: a lift-and-shift app in AWS that still calls an on-prem Oracle database; a domain-joined fleet that needs a line of sight to on-prem Active Directory and DNS; a batch job in the VPC that pulls from an on-prem SFTP; a monitoring stack in AWS scraping data-centre hosts. All of them need the two networks to route to each other over a private, encrypted path — and none of them can wait a month for a circuit.

What breaks without it is ugly. Teams “temporarily” expose the on-prem service to the internet behind an allow-list of AWS NAT IPs — until the NAT IPs change, or a wider CIDR gets pasted in, and now the database is one misconfiguration from public. Or they try to peer the networks with overlapping RFC 1918 space (10.0.0.0/16 on both sides) and discover routing simply cannot disambiguate. Or they stand up a single tunnel, it works in the demo, and three weeks later an AWS endpoint goes into maintenance and the whole hybrid link drops because nobody configured the second tunnel. The failure modes are exactly the ones the internet and a lack of redundancy hand you: eavesdropping risk, silent partitions, and single points of failure.

Who hits this: any organisation mid-migration (which is most of them), anyone running hybrid Active Directory, anyone with a data-residency reason to keep a system of record on-prem while the front end lives in AWS, any DR design that replicates between a data centre and AWS, and any multi-account landing zone that terminates a data-centre link centrally and fans it out over a Transit Gateway. Site-to-Site VPN is the AWS-native answer, and the table below frames the whole field before we go deep.

Learning objectives

By the end of this article you can:

• Explain the full anatomy of a Site-to-Site VPN — Customer Gateway, VPN connection, two tunnels, and the AWS-side termination on a VGW versus a Transit Gateway — and choose the right termination for a given design.
• State exactly why every connection has two tunnels, how HA works (different endpoints in different AZs, active/active vs active/standby), and how to make failover automatic.
• Enumerate the IKEv1/IKEv2 and IPsec phase-1/phase-2 parameters (DH groups, encryption, integrity, lifetimes, PFS) and every tunnel option (DPD, rekey, replay window, startup action, inside CIDR), and read a device’s IKE log to spot a mismatch.
• Choose between static and dynamic (BGP) routing, wire up route propagation, and get the ASN and APIPA tunnel-inside addresses right so BGP establishes.
• Decide between VPN, Direct Connect, and VPN-over-DX, know when accelerated VPN (Global Accelerator) helps, migrate a VGW to a TGW without re-touching the on-prem device, and place the separate Client VPN product correctly.
• Monitor tunnels with CloudWatch (TunnelState, TunnelDataIn/Out) and describe-vpn-connections telemetry, and diagnose failures with a symptom→cause→fix playbook.
• Build, verify, and tear down a full VPN against a simulated on-prem (strongSwan on EC2) with aws ec2 CLI and Terraform, including bringing both tunnels UP and establishing BGP.

Prerequisites & where this fits

You should be solid on core AWS networking: what a VPC, subnet, route table, and CIDR are, and how a subnet’s route table decides where its traffic goes. If any of that is fuzzy, read AWS VPC From Scratch: Subnets, Route Tables and the Internet Gateway and AWS VPC, Subnets and Security Groups Explained first — a VPN sits directly on top of those and assumes them. You will also lean on security groups and NACLs to permit the on-prem traffic once it arrives, covered in AWS Security Groups and NACLs: A Deep-Dive Troubleshooting Guide. You need the AWS CLI v2 configured (aws configure), permission to create VPC, VPN, and (for the lab) EC2 resources, and a passing familiarity with IPsec and BGP — this article defines what you need as it goes, so you do not have to be a network engineer.

Concretely, before you start you want the following in place — the on-prem side is the half AWS cannot do for you:

Where this fits: a Site-to-Site VPN is the pragmatic hybrid edge. For a single VPC, you terminate it on a Virtual Private Gateway. The moment you have several VPCs or accounts, you terminate it on a Transit Gateway instead and let the hub fan the data-centre link out to every spoke — that hub is built in AWS Transit Gateway: A Hub-and-Spoke Multi-VPC Network, Hands-On, and the VPN is its on-ramp. For connecting VPCs to each other rather than to on-prem you would reach for AWS VPC Peering: Setup, Routing and Limits; for reaching AWS services privately without any routing at all, AWS PrivateLink and VPC Endpoints: Interface vs Gateway. The AZs your two tunnel endpoints land in come from AWS Regions and Availability Zones Explained. When a hybrid path misbehaves in ways that span services, work through a broader VPC connectivity troubleshooting playbook alongside the one in this article.

Core concepts

A Site-to-Site VPN is a managed IPsec service. You do not run or patch a VPN concentrator on the AWS side — you create a VPN connection, and AWS provisions the tunnels and hands you a device-specific configuration file. Everything else is either a resource that describes an endpoint or a routing decision.

The Customer Gateway (CGW) is an AWS resource that represents your on-prem device inside AWS. It is just metadata: the device’s public IP address (the internet-routable address the tunnels terminate on — if the device sits behind NAT, this is the NAT device’s public IP) and a BGP ASN (used for dynamic routing; for static routing you still supply one but it is unused). Since 2019 a CGW can instead reference an ACM Private CA certificate for authentication rather than a static IP, which is how you support devices with dynamic public IPs. The CGW does not configure your router — you still apply the downloaded config to the physical device yourself.

The AWS side of the tunnels terminates on one of two things. A Virtual Private Gateway (VGW) is a managed VPN concentrator attached to exactly one VPC. It has an Amazon-side ASN (default 64512) and is the classic single-VPC termination. Alternatively, you terminate the VPN on a Transit Gateway (TGW) as a VPN attachment — do this when the VPN must reach many VPCs, when you want ECMP across multiple tunnels for aggregate bandwidth beyond one tunnel’s ceiling, or when you want accelerated VPN. One VGW = one VPC; one TGW = a hub that can front dozens.

A VPN connection is the logical link, and it is always two IPsec tunnels. This is not optional and not configurable — you get two, terminating on two different AWS endpoint public IPs in two different Availability Zones, precisely so that an endpoint failure or an AWS maintenance event on one does not take your connectivity down. Your on-prem device should be configured for both. Each tunnel independently negotiates IKE (Internet Key Exchange) to build a secure channel and then IPsec to encrypt data, using a pre-shared key (PSK) or certificate, and each has a tunnel-inside CIDR — a /30 from the 169.254.0.0/16 (APIPA) range — that carries the BGP peering session.

The last piece is routing, and it is where most people trip. A tunnel being UP means IKE/IPsec succeeded; it says nothing about whether packets flow. For packets to flow, the VPC must know to send on-prem-bound traffic to the gateway, and the gateway must know the on-prem prefixes. With static routing you type the on-prem CIDRs onto the VPN connection. With dynamic (BGP) routing, your device and AWS exchange prefixes automatically over the tunnel-inside addresses. Either way, you turn on route propagation on the VPC route table so those routes appear automatically with the gateway as target — otherwise the tunnel is a road with no signposts.

The two problems you are always solving are liveness (is the tunnel up?) and reachability (does traffic flow?), and they fail independently:

The components: Customer Gateway, VGW, and Transit Gateway

Customer Gateway (CGW)

The CGW is the smallest resource in the system and the one people misconfigure first. It carries the on-prem device’s public IP (the address AWS will send tunnel packets to) and its BGP ASN. The single most common error: the device is behind a NAT firewall, and you enter the device’s private or interface IP instead of the NAT device’s public IP. AWS must be able to reach the outside address, and the device must use NAT Traversal (NAT-T) — which is why the tunnel needs UDP 4500 open in addition to UDP 500 for IKE.

A CGW is cheap (free — you pay for the VPN connection, not the CGW) and reusable: one CGW record can back multiple VPN connections if the same on-prem device fronts several links.

Virtual Private Gateway (VGW)

The VGW is the AWS-managed VPN (and Direct Connect) concentrator for one VPC. You create it with an Amazon-side ASN (default 64512; you can set your own private ASN, but you cannot change it after creation), attach it to a VPC, and then create VPN connections that terminate on it. Its defining limitations are the reason Transit Gateway exists: it serves a single VPC, and for a VGW a given traffic flow uses one tunnel at a time (so a single flow is capped at roughly one tunnel’s throughput, ~1.25 Gbps), with the second tunnel there for redundancy rather than aggregate bandwidth.

Terminating on a Transit Gateway instead

When you attach the VPN to a Transit Gateway, the same two tunnels land on a regional hub that can route to many VPCs and other attachments transitively. Two concrete wins: ECMP — the TGW can equal-cost-multipath across the tunnels (and across multiple VPN connections) so you scale aggregate bandwidth by adding tunnels instead of being stuck at one tunnel’s ceiling — and accelerated VPN, which is only available on a TGW. The trade is a little more cost and the association/propagation model to reason about. The rule of thumb:

And the feature-by-feature comparison you will be asked about in an exam and in a design review:

The two tunnels and high availability

Every Site-to-Site VPN connection is two tunnels, full stop. AWS provisions them on two separate endpoint public IPs, each hosted in a different Availability Zone in the region, and publishes each endpoint’s IP, a unique pre-shared key, and a tunnel-inside /30 in the configuration file. The whole point is that AWS periodically performs maintenance on tunnel endpoints (you get notified), and during that window that tunnel is torn down and rebuilt — so if you only ever configured tunnel 1, your “working” VPN drops the day AWS touches endpoint 1. Configure both.

How the two tunnels behave depends on the AWS side and your routing:

To make failover automatic and fast you run BGP on both tunnels. When a tunnel dies, BGP withdraws its advertised routes within seconds (tuned by Dead Peer Detection), and traffic moves to the surviving tunnel with no human involved. With static routing there is no such withdrawal signal for the tunnel itself — AWS does monitor tunnel liveness and will steer static traffic to the healthy tunnel, but BGP is cleaner and is what you want in production.

Because both tunnels are usually up, you often want to prefer one deterministically to avoid asymmetric routing (traffic out on tunnel 1, back on tunnel 2), which complicates stateful firewalls on-prem. You steer preference with standard BGP knobs:

Note the ceilings that shape HA and scale: each tunnel is roughly 1.25 Gbps and about 140,000 packets per second; a VGW does not aggregate the two; to go faster you move to a TGW with ECMP and add tunnels/connections. And every tunnel’s MTU is 1500 bytes (no jumbo frames over VPN — unlike Direct Connect), which is the root of the MSS-clamping story later.

The hard limits and quotas you design against — memorise the ones in bold, they show up in exams and in capacity conversations:

IKE and IPsec: phase-1 and phase-2 parameters

A tunnel comes up in two negotiations. Phase 1 (IKE) builds an authenticated, encrypted control channel between the two peers — they agree on an encryption algorithm, an integrity/hash algorithm, a Diffie-Hellman group (the key-exchange strength), a lifetime, and authenticate each other with the pre-shared key (or certificate). Phase 2 (IPsec) then negotiates the security association that actually encrypts your data packets — its own encryption, integrity, optional Perfect Forward Secrecy (PFS) DH group, and a shorter lifetime. Both peers must offer at least one matching proposal in each phase or the tunnel never comes up; the classic log line is NO_PROPOSAL_CHOSEN.

AWS supports both IKEv1 and IKEv2. Prefer IKEv2 wherever the device supports it — it uses fewer messages, rekeys more gracefully, supports asymmetric authentication, and is required for some newer features. Fall back to IKEv1 only for legacy hardware.

The phase-1 (IKE) parameters AWS will negotiate — you can restrict the allowed sets per tunnel to force strong crypto:

The phase-2 (IPsec) parameters — the ones that protect your actual traffic:

Beyond crypto, each tunnel has a set of tunnel options that govern liveness, rekey, and addressing. These are the knobs in modify-vpn-tunnel-options and the tunnel1_*/tunnel2_* Terraform arguments:

Two of these deserve emphasis. Dead Peer Detection (DPD) is how a peer notices the other has gone silent; when it fires, DPDTimeoutAction=clear tears the IKE session down (the default), restart makes AWS re-initiate, and none leaves it. Pair a sensible DPD timeout with BGP and failover is quick and clean. StartupAction matters when your device is behind NAT and cannot be reached to initiate — set it to start (with IKEv2) so AWS initiates the negotiation outbound to your device.

One more consequence of IPsec that you must plan for is MTU overhead. The tunnel MTU is 1500 bytes, but the IPsec (and NAT-T) headers eat into that, so the usable payload for the inner packet is smaller — and a full-size TCP segment with the “don’t fragment” bit set gets silently dropped rather than fragmented. That is why MSS clamping is mandatory over VPN. The rough byte math (why 1379 is the number AWS recommends):

Static vs dynamic (BGP) routing

Getting a tunnel UP is necessary but not sufficient — you now have to make each side learn the other’s networks. There are two ways.

Static routing. You type your on-prem CIDR(s) onto the VPN connection (--options StaticRoutesOnly=true and one or more create-vpn-connection-route calls). AWS installs those as static routes toward the VGW/TGW, and on the on-prem device you point the VPC CIDR down the tunnel. Simple, no BGP to debug, and the right choice for devices that do not speak BGP. The cost: no automatic failover awareness at the routing layer (AWS still fails traffic to the healthy tunnel, but there is no route withdrawal to lean on) and manual edits every time a subnet changes.

Dynamic routing (BGP). Your device and AWS run BGP over each tunnel’s inside /30, exchanging prefixes automatically. AWS advertises the VPC CIDR (via the VGW/TGW), and your device advertises the on-prem prefixes. This gives you automatic failover (a dead tunnel withdraws its routes in seconds) and automatic propagation of new subnets. It is the production default whenever the device supports it.

Whichever you choose, the routes only help if the VPC route table actually carries them. That is route propagation: on the route table, enable propagation for the VGW (or add routes pointing at the TGW), and the static/BGP routes appear automatically with the gateway as target. Skip this and you get the canonical symptom — tunnel UP, AcceptedRouteCount climbing, and still no connectivity, because the instances’ subnet has no route back to on-prem.

Finally, BGP has two fiddly addressing details that cause most “BGP won’t establish” tickets:

Accelerated VPN, migration, and the alternatives

Accelerated Site-to-Site VPN

An accelerated VPN puts your tunnel endpoints behind AWS Global Accelerator anycast IPs, so your on-prem traffic enters the AWS global network at the nearest edge location and rides the AWS backbone to the region, instead of traversing the public internet the whole way. That cuts jitter and latency variance for geographically distant sites. Constraints: you enable it at creation only (--options EnableAcceleration=true), it is TGW-only (not available on a VGW), and it uses two accelerators (one per tunnel). It costs more (Global Accelerator hourly + data-transfer-premium per GB) — worth it for latency-sensitive, distant, or jitter-prone links; unnecessary for a well-connected data centre in the same metro as the region.

Migrating a VGW to a Transit Gateway

You will outgrow a VGW. The clean migration is modify-vpn-connection to change the connection’s target gateway from the VGW to a TGW: this keeps the same tunnel endpoint IPs and pre-shared keys, so your on-prem device configuration does not change — only the AWS-side termination moves. Do it during a maintenance window; there is a brief re-establishment.

If you would rather not move the connection, the alternative is to build a new VPN attachment on the TGW (new tunnels, new endpoint IPs, new PSKs — your on-prem device does change) and cut over. Prefer modify-vpn-connection precisely because it spares the on-prem side.

VPN vs Direct Connect vs VPN-over-DX

A VPN runs over the public internet; Direct Connect (DX) is a dedicated private circuit into AWS. They solve overlapping problems with very different trade-offs, and the exam loves the combination:

The pattern in mature designs: DX for the primary, high-bandwidth private path, and a Site-to-Site VPN as the encrypted backup (or VPN-over-DX when compliance requires the DX traffic itself be encrypted, since plain DX is not). A VPN stood up in an hour is also the perfect DR pre-stage while a DX circuit is still being provisioned.

Client VPN is a different product

Do not confuse Site-to-Site VPN with AWS Client VPN. Client VPN is an OpenVPN-based, managed remote-access service for individual users (laptops) to reach a VPC — mutual-TLS or SAML/federated auth, a client software endpoint, priced per endpoint-hour and per connection-hour. It connects people, not sites; Site-to-Site connects networks. If the requirement is “our developers need to reach private resources from home,” that is Client VPN; “our data centre needs to reach the VPC,” that is Site-to-Site.

Monitoring: CloudWatch tunnel metrics

You must be able to answer “is it up right now?” from a dashboard, not by SSH-ing to a router. AWS publishes per-tunnel metrics in the AWS/VPN namespace, dimensioned by VpnId and TunnelIpAddress. The one you alarm on is TunnelState: for a single tunnel it is 1 (UP) or 0 (DOWN); aggregated across a connection it reflects how many tunnels are up. A production alarm fires when TunnelState < 1 for either tunnel, so a silent failover to a single tunnel pages you — before the second one dies and takes the link down.

Alongside CloudWatch, describe-vpn-connections returns VgwTelemetry per tunnel — the operational source of truth when debugging:

For deeper forensics, enable Site-to-Site VPN logging (IKE/tunnel activity to CloudWatch Logs) on each tunnel — it captures the phase-1/phase-2 negotiation messages so you can see exactly which proposal was rejected. If you also front the VPN with a Transit Gateway, its Flow Logs give you per-flow accept/reject records.

Architecture at a glance

The diagram below is the connection you build in this article, drawn left-to-right as the actual packet path. On the left, your on-prem edge device — represented in AWS as a Customer Gateway (203.0.113.5, ASN 65000) — negotiates IKEv2 + IPsec and opens two tunnels to two different AWS endpoint IPs in two AZs, each with its own 169.254.x.x/30 inside CIDR. The tunnels terminate on a Virtual Private Gateway (or a Transit Gateway attachment) with Amazon-side ASN 64512; BGP over the inside addresses exchanges routes, and route propagation drops the on-prem prefixes into the VPC route table so the private subnet (10.0.1.0/24) can reply. On the right, CloudWatch watches TunnelState and a security group / NACL must permit the on-prem CIDR for traffic to actually reach the instance. Each numbered badge marks a place a real outage bites; the legend narrates each as symptom · confirm · fix.

Real-world scenario

Meridian Logistics, a fictional but representative Indian freight company, ran a 20-year-old transport-management system (TMS) on Oracle in a Chennai data centre and was building a new customer-facing tracking portal in AWS Mumbai (ap-south-1). The portal needed to query the TMS in real time, and the security team was categorical: no database port would ever face the internet. Direct Connect was the eventual plan, but the cross-connect quote was eight weeks out, and the portal launch was in three. They needed private, encrypted connectivity now.

They stood up a Site-to-Site VPN in an afternoon. The Chennai firewall (a Fortinet pair behind a NAT) became the Customer Gateway — and here they hit the first classic wall: they entered the firewall’s LAN interface IP instead of the NAT public IP, and no tunnel came up until they fixed the CGW address and opened UDP 500/4500 and ESP outbound on the corporate firewall. With that corrected, both tunnels negotiated IKEv2 with AES256-GCM and DH group 20. They chose BGP: the firewall advertised the on-prem 172.16.0.0/16 and AWS advertised the VPC 10.20.0.0/16, and they enabled route propagation on the portal’s private-subnet route table. Ping worked — then large API responses from the TMS started hanging. Small queries fine, big result sets dead. Classic MSS/MTU: the 1500-byte tunnel plus IPsec overhead meant full-size segments with DF set were being dropped. They clamped TCP MSS to 1379 on the Fortinet, and the hangs vanished.

The launch went out on the VPN. Two things then proved the design. First, an AWS tunnel-endpoint maintenance notification arrived a month later; because both tunnels were up and BGP was running on both, endpoint 1 going into maintenance shifted all traffic to tunnel 2 in seconds — the on-call engineer only knew because the TunnelState < 1 CloudWatch alarm paged them, exactly as intended. Second, when the Direct Connect circuit was finally delivered, they did not rebuild anything: they used modify-vpn-connection to move nothing (the VPN stayed as the encrypted backup) and instead made DX primary, keeping the Site-to-Site VPN as the encrypted failover path — plain DX being unencrypted, the compliance team liked having the IPsec option in their pocket.

The numbers told the story. The VPN cost roughly ₹3,600/month in connection-hours plus a few hundred rupees of data processing — a rounding error against the portal’s revenue, and a fraction of the DX port they were waiting on. When they later consolidated three more VPCs (analytics, DR, and a partner-integration VPC) that all needed the same TMS, they migrated the VPN termination from the VGW to a Transit Gateway with modify-vpn-connection — same tunnels, same PSKs, zero change on the Fortinet — and let the hub fan the one data-centre link out to all four VPCs. The networking lead’s one-line justification to the CFO: “We shipped a private, encrypted, auto-failover hybrid link in an afternoon for the price of a team lunch, and it scaled to four VPCs without a truck roll to Chennai.”

Advantages and disadvantages

When the advantages win: you need encrypted hybrid connectivity fast, your bandwidth needs are within a couple of tunnels, and you value HA and low cost — the overwhelming majority of hybrid use cases, plus every DR/backup path. When the disadvantages bite hardest: sustained multi-gigabit, latency-critical, or jitter-sensitive workloads where the public internet’s variability is unacceptable — there, Direct Connect (optionally with VPN-over-DX for encryption) is the right tool, with a Site-to-Site VPN riding shotgun as the encrypted failover.

Hands-on lab

You will build a complete, working Site-to-Site VPN — but instead of a real data centre, you will simulate on-prem with a second VPC running strongSwan on a t3.micro EC2 instance acting as the Customer Gateway. This is the standard AWS test pattern: it exercises the exact same AWS resources (aws_customer_gateway, aws_vpn_gateway, aws_vpn_connection), real IKE/IPsec, and real BGP, without a physical router. You will bring both tunnels UP, establish BGP, ping across, verify propagated routes, and tear it down.

⚠️ Cost warning. A Site-to-Site VPN connection bills per connection-hour (~$0.05/hr in most regions → ~₹4.2/hr) the moment it exists, whether or not a tunnel is up, plus data processing. Two t3.micro instances are free-tier-eligible or a few rupees. A two-hour lab is ~₹10; forgetting to delete the VPN connection is ~₹3,000/month. Do the teardown.

Step 0 — variables and the two VPCs

You need an AWS VPC (the real cloud side, 10.10.0.0/16) and an “on-prem” VPC (192.168.0.0/16) whose EC2 instance runs strongSwan.

export AWS_DEFAULT_REGION=ap-south-1
# The AWS-side VPC (what we connect TO)
AWS_VPC=$(aws ec2 create-vpc --cidr-block 10.10.0.0/16 --query 'Vpc.VpcId' --output text \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=aws-vpc}]')
# The "on-prem" VPC (simulated data centre)
ONPREM_VPC=$(aws ec2 create-vpc --cidr-block 192.168.0.0/16 --query 'Vpc.VpcId' --output text \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=onprem-vpc}]')
echo "aws=$AWS_VPC onprem=$ONPREM_VPC"

Step 1 — subnets, an IGW for the on-prem CGW, and a test instance

The strongSwan box needs a public IP (it is the “internet-facing” on-prem router); the AWS side needs a private subnet with a test instance to ping.

# AWS-side private subnet + test instance subnet
AWS_SUBNET=$(aws ec2 create-subnet --vpc-id "$AWS_VPC" --cidr-block 10.10.1.0/24 \
  --availability-zone ap-south-1a --query 'Subnet.SubnetId' --output text)
# On-prem public subnet for the strongSwan CGW
ONPREM_SUBNET=$(aws ec2 create-subnet --vpc-id "$ONPREM_VPC" --cidr-block 192.168.1.0/24 \
  --availability-zone ap-south-1a --query 'Subnet.SubnetId' --output text)
# IGW so the strongSwan box has a public IP the VPN endpoints can reach
ONPREM_IGW=$(aws ec2 create-internet-gateway --query 'InternetGateway.InternetGatewayId' --output text)
aws ec2 attach-internet-gateway --vpc-id "$ONPREM_VPC" --internet-gateway-id "$ONPREM_IGW"
ONPREM_RT=$(aws ec2 describe-route-tables --filters "Name=vpc-id,Values=$ONPREM_VPC" \
  "Name=association.main,Values=true" --query 'RouteTables[0].RouteTableId' --output text)
aws ec2 create-route --route-table-id "$ONPREM_RT" --destination-cidr-block 0.0.0.0/0 --gateway-id "$ONPREM_IGW"

Launch the strongSwan instance (Amazon Linux 2023). Disable source/dest check — it forwards traffic for the 192.168.0.0/16 “LAN,” so it must not drop packets that aren’t addressed to itself:

SG=$(aws ec2 create-security-group --group-name onprem-cgw --description "strongSwan CGW" \
  --vpc-id "$ONPREM_VPC" --query 'GroupId' --output text)
# Allow IKE/IPsec from anywhere (lab), plus ICMP + SSH
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol udp --port 500  --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol udp --port 4500 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol icmp --port -1  --cidr 10.10.0.0/16
CGW_INSTANCE=$(aws ec2 run-instances --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --instance-type t3.micro --subnet-id "$ONPREM_SUBNET" --security-group-ids "$SG" \
  --associate-public-ip-address --query 'Instances[0].InstanceId' --output text)
aws ec2 modify-instance-attribute --instance-id "$CGW_INSTANCE" --no-source-dest-check
aws ec2 wait instance-running --instance-ids "$CGW_INSTANCE"
CGW_PUBLIC_IP=$(aws ec2 describe-instances --instance-ids "$CGW_INSTANCE" \
  --query 'Reservations[0].Instances[0].PublicIpAddress' --output text)
echo "strongSwan public IP (this is your CGW address) = $CGW_PUBLIC_IP"

Step 2 — the Customer Gateway and Virtual Private Gateway

# CGW: point it at the strongSwan public IP; ASN 65000 for BGP
CGW=$(aws ec2 create-customer-gateway --type ipsec.1 --public-ip "$CGW_PUBLIC_IP" \
  --bgp-asn 65000 --query 'CustomerGateway.CustomerGatewayId' --output text)
# VGW: Amazon side ASN 64512, attach to the AWS VPC
VGW=$(aws ec2 create-vpn-gateway --type ipsec.1 --amazon-side-asn 64512 \
  --query 'VpnGateway.VpnGatewayId' --output text)
aws ec2 attach-vpn-gateway --vpn-gateway-id "$VGW" --vpc-id "$AWS_VPC"

Step 3 — create the VPN connection (BGP) and read the tunnel details

VPN=$(aws ec2 create-vpn-connection --type ipsec.1 --customer-gateway-id "$CGW" \
  --vpn-gateway-id "$VGW" \
  --options '{"StaticRoutesOnly":false}' \
  --query 'VpnConnection.VpnConnectionId' --output text)
aws ec2 wait vpn-connection-available --vpn-connection-ids "$VPN"
# Pull the two tunnel outside IPs, PSKs and inside CIDRs (you feed these to strongSwan/FRR)
aws ec2 describe-vpn-connections --vpn-connection-ids "$VPN" \
  --query 'VpnConnections[0].Options.TunnelOptions[].{outside:OutsideIpAddress,inside:TunnelInsideCidr,psk:PreSharedKey}' \
  --output table

Expected: two rows, each with an OutsideIpAddress (the AWS endpoint), a TunnelInsideCidr (a 169.254.x.x/30), and a PreSharedKey. The describe-vpn-connections call also returns a full CustomerGatewayConfiguration XML blob — the “download configuration” — with everything strongSwan and the BGP daemon (FRR) need. Configure strongSwan (/etc/swanctl/swanctl.conf) with both tunnels (both outside IPs, both PSKs), IKEv2, and run FRR/bird BGP peering 169.254.x.1 (AWS) from your side 169.254.x.2, advertising 192.168.0.0/16.

Step 4 — enable route propagation on the AWS side

# Enable route propagation so the on-prem prefix (192.168.0.0/16) auto-appears in the AWS route table
AWS_RT=$(aws ec2 describe-route-tables --filters "Name=vpc-id,Values=$AWS_VPC" \
  "Name=association.main,Values=true" --query 'RouteTables[0].RouteTableId' --output text)
aws ec2 enable-vgw-route-propagation --route-table-id "$AWS_RT" --gateway-id "$VGW"

Step 5 — bring both tunnels UP and verify

# Watch the tunnel telemetry — after strongSwan connects, Status flips to UP
aws ec2 describe-vpn-connections --vpn-connection-ids "$VPN" \
  --query 'VpnConnections[0].VgwTelemetry[].{ip:OutsideIpAddress,status:Status,routes:AcceptedRouteCount,msg:StatusMessage}' \
  --output table

Expected once strongSwan + BGP are up on both tunnels:

------------------------------------------------------------------
|                     DescribeVpnConnections                      |
+------------------+----------+----------+-------------------------+
|       ip         | status   | routes   |          msg            |
+------------------+----------+----------+-------------------------+
|  13.234.x.x      |  UP      |  1       |  IPSEC IS UP            |
|  15.206.y.y      |  UP      |  1       |  IPSEC IS UP            |
+------------------+----------+----------+-------------------------+

AcceptedRouteCount = 1 on each tunnel means BGP learned your 192.168.0.0/16. Now confirm the route landed in the AWS route table (propagation) and ping across:

# The propagated on-prem route should appear with the VGW as target
aws ec2 describe-route-tables --route-table-id "$AWS_RT" \
  --query 'RouteTables[0].Routes[?GatewayId==`'"$VGW"'`]' --output table
# From an instance in the AWS subnet, ping the strongSwan private IP (192.168.1.x)

Expected: a route 192.168.0.0/16 → <vgw-id> with Origin: EnableVgwRoutePropagation, and a successful ping from an AWS-side instance to the on-prem 192.168.x.x address. That end-to-end ping is the proof the VPN works.

Step 6 — teardown (do not skip)

# Delete the VPN connection FIRST — this stops the connection-hour meter
aws ec2 delete-vpn-connection --vpn-connection-id "$VPN"
aws ec2 detach-vpn-gateway --vpn-gateway-id "$VGW" --vpc-id "$AWS_VPC"
aws ec2 delete-vpn-gateway --vpn-gateway-id "$VGW"
aws ec2 delete-customer-gateway --customer-gateway-id "$CGW"
aws ec2 terminate-instances --instance-ids "$CGW_INSTANCE"
aws ec2 wait instance-terminated --instance-ids "$CGW_INSTANCE"
# then detach/delete IGW, delete subnets, SGs, and both VPCs
aws ec2 detach-internet-gateway --vpc-id "$ONPREM_VPC" --internet-gateway-id "$ONPREM_IGW"
aws ec2 delete-internet-gateway --internet-gateway-id "$ONPREM_IGW"

Command and Terraform reference

The aws ec2 verb set you use to operate a Site-to-Site VPN:

And the Terraform aws provider resources — where the VPN belongs in production:

A minimal Terraform for the VGW pattern with hardened tunnels and BGP:

resource "aws_customer_gateway" "onprem" {
  bgp_asn    = 65000
  ip_address = "203.0.113.5"   # the on-prem device's PUBLIC (NAT) IP
  type       = "ipsec.1"
  tags       = { Name = "chennai-dc" }
}

resource "aws_vpn_gateway" "vgw" {
  vpc_id          = aws_vpc.aws_side.id
  amazon_side_asn = 64512
  tags            = { Name = "aws-vgw" }
}

resource "aws_vpn_connection" "s2s" {
  customer_gateway_id = aws_customer_gateway.onprem.id
  vpn_gateway_id      = aws_vpn_gateway.vgw.id
  type                = "ipsec.1"
  static_routes_only  = false            # BGP

  # Harden BOTH tunnels: IKEv2 + strong crypto only
  tunnel1_ike_versions                 = ["ikev2"]
  tunnel1_phase1_dh_group_numbers      = [20, 21]
  tunnel1_phase2_dh_group_numbers      = [20, 21]
  tunnel1_phase1_encryption_algorithms = ["AES256-GCM-16"]
  tunnel1_phase2_encryption_algorithms = ["AES256-GCM-16"]
  tunnel1_startup_action               = "start"   # AWS initiates (device behind NAT)
  tunnel2_ike_versions                 = ["ikev2"]
  tunnel2_phase1_dh_group_numbers      = [20, 21]
  tunnel2_phase2_dh_group_numbers      = [20, 21]
  tunnel2_phase1_encryption_algorithms = ["AES256-GCM-16"]
  tunnel2_phase2_encryption_algorithms = ["AES256-GCM-16"]
  tunnel2_startup_action               = "start"
  tags = { Name = "chennai-to-aws" }
}

resource "aws_vpn_gateway_route_propagation" "prop" {
  vpn_gateway_id = aws_vpn_gateway.vgw.id
  route_table_id = aws_route_table.private.id   # the on-prem prefix auto-appears here
}

Common mistakes & troubleshooting

The playbook first — the failures you will actually hit, with the exact command or console path to confirm each and the fix. This is the section to bookmark. Note the split between liveness (tunnel DOWN) and reachability (tunnel UP, no traffic) — they are different problems.

A status / telemetry reference you will read constantly in describe-vpn-connections and IKE logs:

And a fast decision table for the two big failure classes, which are 90% of VPN tickets:

The three nastiest real failures deserve prose. First, “the tunnel is up but nothing works.” This is the defining VPN ticket, and it is almost always routing, not the tunnel: the tunnel says UP, so the network engineer stares at IKE for an hour, when the actual problem is that route propagation is off (or the route is in the wrong subnet’s table, or the security group has no inbound rule for the on-prem CIDR). Train yourself to split the diagnosis: Status=UP means stop looking at crypto and go check the VPC route table, then the SG, then the NACL. Second, the MTU/MSS black hole. Because the tunnel MTU is 1500 and IPsec adds overhead, a full-size TCP segment with the “don’t fragment” bit set gets silently dropped — so the handshake (small packets) succeeds and the data (big packets) vanishes. The tell is “ping works, SSH/TLS/large responses hang.” The fix is MSS clamping to 1379 bytes on the on-prem device; it is not optional over VPN. Third, the single-tunnel time bomb. Everything works in the demo because tunnel 1 is up, so nobody bothers with tunnel 2 — and weeks later an AWS endpoint maintenance event (which you were emailed about) tears tunnel 1 down and the entire hybrid link drops. Always configure both tunnels and alarm on TunnelState < 1 so a failover to one tunnel is a page, not an outage.

Best practices

• Always configure both tunnels and run BGP on both — the second tunnel is your HA, and AWS will perform endpoint maintenance on one of them. Configuring only one is the most common self-inflicted outage.
• Alarm on TunnelState (< 1 per tunnel = a tunnel down; < 2 on the connection = redundancy lost). A silent failover to a single tunnel must page you before the second tunnel dies.
• Prefer BGP over static routing wherever the device supports it — automatic failover and automatic propagation of new subnets are worth the extra setup.
• Clamp TCP MSS to 1379 on the on-prem device from day one. VPN MTU is 1500 with no jumbo; without clamping, large transfers black-hole.
• Prefer one tunnel deterministically (AS-path prepend / MED / local-pref) to keep flows symmetric and stateful on-prem firewalls happy.
• Restrict crypto to strong, modern algorithms (IKEv2, AES256-GCM, DH group ≥ 19/20, SHA2, PFS on) — but not so narrowly that you cause NO_PROPOSAL_CHOSEN; match the device’s real capability.
• Enable route propagation on every VPC route table that needs on-prem reachability — the number-one cause of “tunnel up, no traffic.”
• Terminate on a Transit Gateway the moment you have more than one VPC to reach, or need ECMP/accelerated VPN — and migrate an existing VGW with modify-vpn-connection so the on-prem device is untouched.
• Use StartupAction=start (with IKEv2) when the on-prem device is behind NAT and can’t be the initiator, so AWS brings the tunnel up outbound.
• Store PSKs in Secrets Manager, rotate them, and prefer certificate-based CGWs for devices with dynamic public IPs.
• Own the whole thing in Terraform — CGW, VGW/TGW, connection, tunnel options, and propagation — so tunnel crypto is reviewed in a PR, not clicked in the console.
• Enable Site-to-Site VPN logging to CloudWatch Logs on both tunnels so a future NO_PROPOSAL_CHOSEN shows you the exact rejected proposal instead of a guessing game.

Security notes

A Site-to-Site VPN is a security control — it encrypts traffic that would otherwise cross the internet in the clear — but it has its own hardening surface. The transport is IPsec, so choose modern crypto: IKEv2, AES-256-GCM (AEAD, encryption + integrity in one), DH group 19+/20+ for key exchange, SHA2 for integrity, and PFS enabled so a compromised key does not expose past sessions. Do not leave SHA1 or DH group 2 in the allowed set unless a legacy device forces it.

The pre-shared key is a long-lived secret: each tunnel has its own, and anyone who has it plus the endpoint IP can attempt to negotiate. Store PSKs in Secrets Manager or Parameter Store (SecureString), never in git or a wiki, rotate them (modify-vpn-tunnel-options sets a new PSK per tunnel, one at a time so the other stays up), and prefer certificate-based authentication (ACM Private CA on the CGW) for higher assurance and for devices whose public IP changes.

Remember that IPsec gets the traffic to the VPC — it does not authorize what it can reach. That is the job of the security groups and NACLs on the destination subnets: scope inbound rules to the specific on-prem CIDR and ports (never 0.0.0.0/0), and if you terminate on a Transit Gateway, use separate route tables / segmentation so the data-centre link cannot reach environments it has no business touching. Enable VPN logging and, on a TGW, Flow Logs for an audit trail, and record the VPN and route changes in CloudTrail. Finally, treat overlapping RFC 1918 space as a security issue as much as a routing one: NAT or re-IP so you always know exactly which host a packet is going to.

Cost & sizing

Site-to-Site VPN pricing has two parts: a connection-hour charge (~$0.05/hr, ~₹4.2/hr, ~₹3,000/month per connection in most regions — billed whenever the connection exists, tunnel up or not) and data transfer out at standard EC2 egress rates. There is no charge for the VGW or CGW themselves. If you terminate on a Transit Gateway, add the TGW attachment-hour (~$0.05/hr) and per-GB processing (~$0.02/GB). Accelerated VPN adds Global Accelerator hourly plus a data-transfer-premium per GB. Data coming in from on-prem is generally free; data going out to on-prem is the egress line to watch.

Sizing. A single VPN connection (two tunnels, one active per flow on a VGW) suits workloads up to roughly a tunnel’s throughput — plenty for AD/DNS, database queries, admin traffic, and most app integration. When you need more aggregate bandwidth, move to a TGW with ECMP and add tunnels/connections (each ~1.25 Gbps). When you need sustained multi-gigabit or guaranteed latency, that is the signal to provision Direct Connect and keep the VPN as the encrypted backup. Free-tier note: there is no free tier for the VPN connection-hour — an idle VPN connection is a real, recurring charge, which is exactly why the lab teardown deletes it first.

Interview & exam questions

Q1. Why does every Site-to-Site VPN connection have two tunnels? For high availability. AWS provisions two tunnels on two endpoint IPs in two different Availability Zones so that endpoint maintenance or a failure on one does not drop connectivity. You must configure both on your device; with BGP, failover between them is automatic. (SAA-C03, ANS-C01.)

Q2. What is the difference between a Customer Gateway and a Virtual Private Gateway? The CGW is an AWS resource that describes your on-prem device (its public IP and BGP ASN); the VGW is the AWS-managed VPN concentrator attached to your VPC that terminates the AWS side of the tunnels. The tunnels run between the two. (SAA-C03.)

Q3. When do you terminate a VPN on a Transit Gateway instead of a VGW? When the VPN must reach many VPCs (a VGW serves one), when you need ECMP across tunnels for aggregate bandwidth beyond ~1.25 Gbps, or when you want accelerated VPN — all TGW-only. A VGW is the simplest choice for a single VPC. (ANS-C01.)

Q4. Static vs dynamic routing — which and why? Dynamic (BGP) where the device supports it: it gives automatic failover (route withdrawal on a dead tunnel) and automatic propagation of new subnets. Static is for devices without BGP; you type the on-prem CIDRs and lose automatic failover at the routing layer. (SAA-C03, ANS-C01.)

Q5. “The tunnel is UP but no traffic flows.” What do you check? Routing, not the tunnel. Confirm route propagation is enabled (or a static/BGP route exists) so the on-prem CIDR points at the gateway in the right subnet’s route table, then confirm the security group permits the on-prem CIDR inbound and the NACL permits both directions. (SAA-C03.)

Q6. Large transfers hang while pings succeed. Cause and fix? MTU/MSS. The 1500-byte tunnel plus IPsec overhead causes full-size TCP segments with DF set to be dropped; small packets (pings, handshakes) pass. Fix by clamping TCP MSS to ~1379 bytes on the on-prem device. (ANS-C01.)

Q7. How is Site-to-Site VPN different from Client VPN? Site-to-Site connects an entire network (data centre) to a VPC over IPsec (two tunnels, router-to-router). Client VPN is OpenVPN-based remote access for individual users/devices with TLS/AD/SAML auth and a client app. Different products, different use cases. (SAA-C03.)

Q8. VPN vs Direct Connect, and what is VPN-over-DX? VPN is encrypted, over the public internet, minutes to set up, cheap, variable latency. DX is a private dedicated circuit, consistent high bandwidth, weeks to provision, expensive, and not encrypted by default. VPN-over-DX runs IPsec over a DX public VIF to get both a private path and encryption. (ANS-C01.)

Q9. What are phase 1 and phase 2 in IPsec? Phase 1 (IKE) authenticates the peers and builds the secure control channel (agreeing DH group, encryption, integrity, lifetime, PSK/cert). Phase 2 (IPsec) negotiates the SA that encrypts the actual data (its own encryption, integrity, optional PFS, shorter lifetime). Both need a matching proposal or the tunnel fails with NO_PROPOSAL_CHOSEN. (ANS-C01, SCS-C02.)

Q10. Your device is behind NAT. What must you get right? Set the CGW IpAddress to the NAT device’s public IP (not the device’s private IP), ensure NAT-T works by opening UDP 4500 (and 500), and consider StartupAction=start so AWS initiates the tunnel outbound since the device may not be reachable to initiate. (ANS-C01.)

Q11. How do you monitor VPN health, and what do you alarm on? CloudWatch AWS/VPN metrics — primarily TunnelState (1 = UP, 0 = DOWN per tunnel). Alarm on TunnelState < 1 per tunnel so a failover to a single tunnel pages you; use describe-vpn-connections VgwTelemetry (Status, AcceptedRouteCount) for live detail. (SOA-C02, ANS-C01.)

Q12. How do you migrate a VGW-terminated VPN to a Transit Gateway with minimal disruption? Use modify-vpn-connection to change the connection’s target gateway from the VGW to the TGW. It keeps the same tunnel endpoint IPs and pre-shared keys, so the on-prem device configuration does not change — only the AWS-side termination moves, during a brief re-establishment. (ANS-C01.)

Quick check

1. How many tunnels does a Site-to-Site VPN connection always have, and why?
2. You created the CGW with your firewall’s LAN IP and the tunnel won’t come up. What’s wrong?
3. The tunnel is UP but you can’t reach the VPC from on-prem. Name the two most likely causes.
4. Pings work but large file transfers hang. What’s the fix?
5. Which termination — VGW or TGW — do you need for ECMP and accelerated VPN?

Answers

1. Two, terminating on two endpoint IPs in two AZs, for high availability against endpoint maintenance/failure — configure both.
2. The CGW must carry the device’s public (NAT) IP, not its private/LAN IP; AWS can’t reach a private address. Fix the CGW address and ensure NAT-T (UDP 4500) is open.
3. Route propagation is off / no route to on-prem in the VPC route table, and/or the security group/NACL doesn’t permit the on-prem CIDR. (BGP not exchanging routes — AcceptedRouteCount=0 — is a close third.)
4. Clamp TCP MSS to ~1379 bytes on the on-prem device — the 1500-byte tunnel plus IPsec overhead is dropping full-size segments (MTU/MSS black hole).
5. A Transit Gateway — ECMP across tunnels and accelerated VPN are TGW-only; a VGW serves one VPC with one active tunnel per flow.

Glossary

• Site-to-Site VPN — A managed AWS IPsec VPN connecting an on-prem network to a VPC, made of two tunnels.
• Customer Gateway (CGW) — An AWS resource describing your on-prem device: its public IP (or certificate) and BGP ASN.
• Virtual Private Gateway (VGW) — The AWS-managed VPN/DX concentrator attached to a single VPC; has an Amazon-side ASN (default 64512).
• Transit Gateway (TGW) VPN attachment — Terminating the VPN on a regional hub to reach many VPCs, enable ECMP, or use accelerated VPN.
• Tunnel — One IPsec tunnel to one AWS endpoint IP; every connection has exactly two.
• IKE (phase 1) — Internet Key Exchange; authenticates peers and builds the secure control channel (IKEv1 or IKEv2).
• IPsec (phase 2) — Negotiates the security association that encrypts the actual data packets.
• Diffie-Hellman (DH) group — The key-exchange strength; higher numbers are stronger (AWS supports 2, 14–24).
• PFS (Perfect Forward Secrecy) — Fresh DH key exchange per phase-2 SA so one compromised key doesn’t expose past traffic.
• Pre-shared key (PSK) — The per-tunnel secret used to authenticate phase 1 (alternative: certificate).
• BGP — Border Gateway Protocol; the dynamic routing protocol that exchanges prefixes and enables automatic failover.
• Tunnel-inside CIDR (APIPA) — A 169.254.x.x/30 per tunnel carrying the BGP peering session.
• ASN — Autonomous System Number; the on-prem side is on the CGW, the AWS side on the VGW/TGW.
• Route propagation — Auto-injecting VPN (static or BGP) routes into a VPC route table with the gateway as target.
• DPD (Dead Peer Detection) — The mechanism a peer uses to notice the other has gone silent and tear down/restart the SA.
• NAT-T — NAT Traversal; encapsulates IPsec in UDP 4500 so tunnels survive a NAT in the path.
• MSS clamping — Reducing the TCP maximum segment size (to ~1379) so segments fit the tunnel MTU without being dropped.
• Accelerated VPN — A TGW-only option that routes tunnel traffic over the AWS backbone via Global Accelerator for lower jitter.
• TunnelState — The CloudWatch AWS/VPN metric: 1 = UP, 0 = DOWN per tunnel; the thing you alarm on.

Next steps

• Scale the hybrid edge to many VPCs by terminating the VPN on a hub — AWS Transit Gateway: A Hub-and-Spoke Multi-VPC Network, Hands-On.
• Connect VPCs to each other (a different problem from on-prem) — AWS VPC Peering: Setup, Routing and Limits.
• Reach AWS services privately without routing at all — AWS PrivateLink and VPC Endpoints: Interface vs Gateway.
• Permit the traffic once it arrives — AWS Security Groups and NACLs: A Deep-Dive Troubleshooting Guide.
• Ground the addressing and AZ placement your tunnels depend on — AWS VPC From Scratch: Subnets, Route Tables and the Internet Gateway and AWS Regions and Availability Zones Explained. For a broader cross-service hybrid connectivity troubleshooting playbook, work through the VPC connectivity troubleshooting guide alongside this article.