{"id":300,"date":"2026-04-13T13:39:39","date_gmt":"2026-04-13T13:39:39","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-site-to-site-vpn-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-content-delivery\/"},"modified":"2026-04-13T13:39:39","modified_gmt":"2026-04-13T13:39:39","slug":"aws-site-to-site-vpn-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-content-delivery","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-site-to-site-vpn-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-and-content-delivery\/","title":{"rendered":"AWS Site-to-Site VPN Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking and content delivery"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking and content delivery<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>AWS Site-to-Site VPN is an AWS managed networking service that creates encrypted IPsec tunnels between your on-premises network (or another network) and your Amazon VPC or AWS Transit Gateway. It\u2019s commonly used to extend private network connectivity into AWS without using the public internet in cleartext.<\/p>\n\n\n\n<p>In simple terms: you configure a VPN device (your router\/firewall, or a software VPN appliance) to connect to AWS, and AWS provisions two redundant VPN tunnels. Your workloads in AWS can then communicate with your on-premises workloads using private IP addresses over encrypted tunnels.<\/p>\n\n\n\n<p>Technically, AWS Site-to-Site VPN terminates on either a <strong>virtual private gateway (VGW)<\/strong> attached to a single VPC or a <strong>transit gateway (TGW)<\/strong> for hub-and-spoke\/multi-VPC connectivity. It supports <strong>dynamic routing using BGP<\/strong> or <strong>static routing<\/strong>, and uses standard <strong>IPsec\/IKE<\/strong> to establish secure tunnels over the internet.<\/p>\n\n\n\n<p>It solves the problem of securely connecting private networks across locations\u2014hybrid cloud connectivity\u2014without requiring dedicated circuits (like AWS Direct Connect), and without exposing internal traffic unencrypted.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is AWS Site-to-Site VPN?<\/h2>\n\n\n\n<p><strong>Official purpose:<\/strong> AWS Site-to-Site VPN provides secure, encrypted connectivity between your network and AWS over an IPsec VPN connection. It\u2019s part of AWS\u2019s hybrid connectivity portfolio under <strong>Networking and content delivery<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create <strong>IPsec tunnels<\/strong> between your customer gateway and AWS.<\/li>\n<li>Use <strong>two tunnels per VPN connection<\/strong> for redundancy.<\/li>\n<li>Support <strong>dynamic routing (BGP)<\/strong> or <strong>static routes<\/strong> (depending on your setup).<\/li>\n<li>Terminate VPNs on:<\/li>\n<li><strong>Virtual Private Gateway (VGW)<\/strong> for a single VPC, or<\/li>\n<li><strong>Transit Gateway (TGW)<\/strong> for scalable hub-and-spoke architectures.<\/li>\n<li>Optionally enable <strong>VPN acceleration<\/strong> (feature availability and mechanics can change; verify in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (key terms you\u2019ll see in AWS)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Customer gateway (CGW):<\/strong> The on-premises VPN endpoint definition in AWS (public IP address and routing type\/ASN). This represents your device, even if that device is a software appliance.<\/li>\n<li><strong>Customer gateway device:<\/strong> The actual router\/firewall\/VPN appliance on your side.<\/li>\n<li><strong>VPN connection:<\/strong> The AWS resource that includes two IPsec tunnels and routing configuration.<\/li>\n<li><strong>Tunnel endpoints:<\/strong> AWS-provided public IP addresses for each tunnel.<\/li>\n<li><strong>Virtual private gateway (VGW):<\/strong> AWS-side VPN endpoint attached to a VPC.<\/li>\n<li><strong>Transit gateway (TGW):<\/strong> AWS hub for connecting multiple VPCs and on-premises networks (VPN and\/or Direct Connect).<\/li>\n<li><strong>Route tables and route propagation:<\/strong> How traffic learns to use the VPN path.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Managed network connectivity service (control plane managed by AWS).<\/li>\n<li>Data plane runs over the public internet but is <strong>encrypted with IPsec<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (regional\/account)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Site-to-Site VPN is a Regional service<\/strong> in practice: you create VPN connections in a specific AWS Region and attach them to VGW\/TGW resources in that Region.<\/li>\n<li>Resources are scoped to your <strong>AWS account<\/strong> and <strong>Region<\/strong> (like VPCs and Transit Gateways).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the AWS ecosystem<\/h3>\n\n\n\n<p>AWS Site-to-Site VPN commonly integrates with:\n&#8211; <strong>Amazon VPC<\/strong> (subnets, route tables, security groups, NACLs)\n&#8211; <strong>AWS Transit Gateway<\/strong> (centralized routing across many VPCs)\n&#8211; <strong>AWS Direct Connect<\/strong> (often paired as backup connectivity)\n&#8211; <strong>AWS Network Manager<\/strong> (visibility\/monitoring of global networks; verify exact supported resource views in docs)\n&#8211; <strong>Amazon CloudWatch<\/strong> (metrics\/alarms for tunnel state and throughput)\n&#8211; <strong>AWS CloudTrail<\/strong> (audit logging for API actions on VPN resources)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use AWS Site-to-Site VPN?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster hybrid adoption:<\/strong> Connect to AWS quickly without waiting for dedicated circuits.<\/li>\n<li><strong>Lower upfront cost:<\/strong> No physical circuit or colocation requirement.<\/li>\n<li><strong>Incremental migration:<\/strong> Extend on-prem networks to AWS during phased migration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Encrypted in transit:<\/strong> IPsec encryption protects traffic over the internet.<\/li>\n<li><strong>Private addressing end-to-end:<\/strong> Applications can communicate using RFC1918 IPs (your internal IP ranges).<\/li>\n<li><strong>Redundant tunnels:<\/strong> Each VPN connection includes two tunnels to support high availability designs.<\/li>\n<li><strong>Routing flexibility:<\/strong> Use BGP for dynamic routing or static routes for simpler environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed AWS endpoint:<\/strong> AWS manages the VPN endpoint on its side (VGW\/TGW).<\/li>\n<li><strong>Standard protocols:<\/strong> Works with many existing network devices and SD-WAN platforms.<\/li>\n<li><strong>Automation-friendly:<\/strong> Build and manage using AWS Console, AWS CLI, IaC (CloudFormation\/Terraform).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Traffic encryption:<\/strong> Helps meet security requirements for data in transit.<\/li>\n<li><strong>Auditable changes:<\/strong> Resource changes are logged via CloudTrail.<\/li>\n<li><strong>Segmentation:<\/strong> Use VPC route tables, TGW route tables, and security groups to enforce network boundaries.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>TGW integration:<\/strong> Scale to many VPCs and many remote sites with centralized routing.<\/li>\n<li><strong>Active\/active possibilities:<\/strong> With BGP and appropriate settings, you can use multiple tunnels and Equal-Cost Multi-Path (ECMP) in some designs (verify current constraints by gateway type in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose AWS Site-to-Site VPN<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need <strong>quick, encrypted hybrid connectivity<\/strong>.<\/li>\n<li>You need <strong>backup connectivity<\/strong> for Direct Connect.<\/li>\n<li>You have moderate bandwidth requirements and can tolerate internet variability.<\/li>\n<li>You need to connect a branch office, datacenter, or partner network.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You require <strong>consistent low-latency and high-throughput<\/strong> connectivity with strict SLAs: consider <strong>AWS Direct Connect<\/strong>.<\/li>\n<li>You need <strong>user-to-VPC<\/strong> remote access for individuals: consider <strong>AWS Client VPN<\/strong> instead.<\/li>\n<li>You need <strong>VPC-to-VPC<\/strong> connectivity only within AWS: consider <strong>VPC Peering<\/strong> or <strong>Transit Gateway<\/strong> (without VPN).<\/li>\n<li>Your environment requires complex L7 security inspection inline: you may need additional network security appliances and architecture work.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is AWS Site-to-Site VPN used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Finance and insurance (encrypted hybrid connectivity, regulated environments)<\/li>\n<li>Healthcare (secure connectivity for clinical systems; compliance-driven)<\/li>\n<li>Retail (store\/branch connectivity)<\/li>\n<li>Manufacturing (plant\/OT integration with cloud analytics)<\/li>\n<li>SaaS\/tech (hybrid builds, migrations, DR connectivity)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Network engineering teams (routing, IPsec, BGP)<\/li>\n<li>Cloud platform teams (landing zones, shared connectivity)<\/li>\n<li>Security engineering teams (segmentation, encryption requirements)<\/li>\n<li>DevOps\/SRE (hybrid monitoring, reliability, incident response)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hybrid web applications (app tier in AWS, database on-prem temporarily)<\/li>\n<li>Data transfer pipelines (on-prem data to AWS analytics)<\/li>\n<li>Identity and directory integration (AD\/LDAP connectivity)<\/li>\n<li>Backup and disaster recovery (replication from on-prem to AWS)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single VPC hybrid extension using <strong>VGW<\/strong><\/li>\n<li>Multi-VPC hub-and-spoke using <strong>Transit Gateway<\/strong><\/li>\n<li>Dual connectivity: <strong>Direct Connect + VPN backup<\/strong><\/li>\n<li>Multi-site connectivity: many branches into a TGW<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test:<\/strong> quick connectivity to test hybrid patterns without long procurement.<\/li>\n<li><strong>Production:<\/strong> commonly used as:<\/li>\n<li>primary connectivity for smaller sites, or<\/li>\n<li>secondary\/backup path for critical sites with Direct Connect.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where AWS Site-to-Site VPN is commonly used.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Hybrid application migration (lift-and-shift)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need AWS compute to access on-prem databases while migrating.<\/li>\n<li><strong>Why this service fits:<\/strong> Encrypted connectivity with private routing; quick to set up.<\/li>\n<li><strong>Example scenario:<\/strong> Move application servers to EC2, keep Oracle on-prem until cutover.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Direct Connect backup (resiliency)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Dedicated circuits can fail; you need failover connectivity.<\/li>\n<li><strong>Why this service fits:<\/strong> VPN can act as a secondary path when Direct Connect is down.<\/li>\n<li><strong>Example scenario:<\/strong> Dual-homed site uses Direct Connect for normal operations and AWS Site-to-Site VPN for failover.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Branch office to AWS (no datacenter)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Small branch needs access to workloads in AWS without MPLS.<\/li>\n<li><strong>Why this service fits:<\/strong> Uses internet + IPsec; compatible with many branch routers\/SD-WAN.<\/li>\n<li><strong>Example scenario:<\/strong> Retail stores connect to a TGW in the nearest Region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Disaster recovery networking<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need private network reachability for DR tests and failover.<\/li>\n<li><strong>Why this service fits:<\/strong> Create VPN to DR VPC; keep it warm for replication and drills.<\/li>\n<li><strong>Example scenario:<\/strong> On-prem VMware replication targets EC2\/EBS-backed appliances in AWS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Secure ingestion to AWS analytics<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Send logs\/metrics\/data from on-prem securely to AWS.<\/li>\n<li><strong>Why this service fits:<\/strong> Encrypted tunnels; controlled routing; avoids exposing ingestion endpoints publicly.<\/li>\n<li><strong>Example scenario:<\/strong> Industrial telemetry flows to Amazon Kinesis endpoints via private routing and NAT\/egress patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Partner network connectivity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Connect a partner environment to a shared services VPC.<\/li>\n<li><strong>Why this service fits:<\/strong> Standard IPsec; route-level control; separate VPNs per partner.<\/li>\n<li><strong>Example scenario:<\/strong> B2B integration where partner sends data to internal APIs in AWS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Centralized inspection VPC (with TGW)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Multiple VPCs need consistent egress and inspection policies.<\/li>\n<li><strong>Why this service fits:<\/strong> VPN into TGW enables centralized routing; combine with inspection VPC architecture.<\/li>\n<li><strong>Example scenario:<\/strong> Remote datacenters connect via VPN to TGW; traffic routed through a firewall VPC.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Temporary connectivity during datacenter move<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need a bridge while moving infrastructure and changing IP ranges.<\/li>\n<li><strong>Why this service fits:<\/strong> Quick to spin up and tear down; static routes possible.<\/li>\n<li><strong>Example scenario:<\/strong> Month-long transition connectivity for cutover weekends.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Hybrid identity services (AD\/LDAP, RADIUS)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> AWS workloads need to authenticate against on-prem identity.<\/li>\n<li><strong>Why this service fits:<\/strong> Private IP connectivity reduces exposure; stable routing.<\/li>\n<li><strong>Example scenario:<\/strong> EC2 domain-joined servers use on-prem domain controllers during migration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Multi-site connectivity consolidation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Many sites connect to multiple VPCs; routing becomes hard.<\/li>\n<li><strong>Why this service fits:<\/strong> Use TGW to simplify into hub-and-spoke; manage routes centrally.<\/li>\n<li><strong>Example scenario:<\/strong> 20 branches connect to a TGW; shared services VPC provides DNS, logging, patching.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Secure admin plane access (private tooling)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Admin tools must reach instances without exposing SSH\/RDP to internet.<\/li>\n<li><strong>Why this service fits:<\/strong> VPN provides a private path from corporate network to private subnets.<\/li>\n<li><strong>Example scenario:<\/strong> Bastion hosts removed; admins connect through corporate VPN device to AWS private IPs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Lab environments and training<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Need to teach IPsec\/BGP hybrid networking with minimal hardware.<\/li>\n<li><strong>Why this service fits:<\/strong> Can be simulated using a software VPN appliance on EC2 as a customer gateway.<\/li>\n<li><strong>Example scenario:<\/strong> Training lab uses strongSwan on Linux to establish tunnels to a VPC.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Managed IPsec VPN (two redundant tunnels)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provisions an IPsec VPN connection with <strong>two tunnels<\/strong> to AWS-managed endpoints.<\/li>\n<li><strong>Why it matters:<\/strong> Redundancy is built in; you can design for failover.<\/li>\n<li><strong>Practical benefit:<\/strong> Higher availability than a single tunnel.<\/li>\n<li><strong>Caveats:<\/strong> You still must configure your customer gateway to use both tunnels; active\/active vs active\/standby depends on routing mode and device capability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Termination on Virtual Private Gateway (VGW) or Transit Gateway (TGW)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you terminate VPN on a VPC (VGW) or a centralized router (TGW).<\/li>\n<li><strong>Why it matters:<\/strong> Determines scalability and route management model.<\/li>\n<li><strong>Practical benefit:<\/strong> TGW supports multi-VPC connectivity patterns.<\/li>\n<li><strong>Caveats:<\/strong> TGW introduces its own routing concepts (TGW route tables, attachments) and costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dynamic routing with BGP<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Exchanges routes using BGP between your customer gateway and AWS.<\/li>\n<li><strong>Why it matters:<\/strong> Enables route failover and simplifies operations as networks change.<\/li>\n<li><strong>Practical benefit:<\/strong> Automatic routing updates; supports more resilient designs.<\/li>\n<li><strong>Caveats:<\/strong> Requires BGP-capable device and correct ASN\/peering setup.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Static routing (no BGP)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> You manually define remote network prefixes reachable via the VPN.<\/li>\n<li><strong>Why it matters:<\/strong> Simple for small networks or where BGP isn\u2019t available.<\/li>\n<li><strong>Practical benefit:<\/strong> Lower complexity.<\/li>\n<li><strong>Caveats:<\/strong> Manual updates required; failover behavior is more limited than well-designed BGP.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tunnel options (IKE\/IPsec parameters)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> AWS provides tunnel configuration details (public endpoint IPs, pre-shared keys, encryption\/authentication settings, inside tunnel addresses for route-based designs).<\/li>\n<li><strong>Why it matters:<\/strong> Interoperability depends on matching parameters between AWS and your device.<\/li>\n<li><strong>Practical benefit:<\/strong> AWS generates vendor-specific configuration templates for many devices.<\/li>\n<li><strong>Caveats:<\/strong> Your security policy may require specific ciphers; verify what your device supports and what AWS currently offers (cipher suites evolve\u2014verify in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">VPN acceleration (optional)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides an option intended to improve performance by leveraging AWS global edge networking for VPN traffic.<\/li>\n<li><strong>Why it matters:<\/strong> Can reduce latency variation for some geographies.<\/li>\n<li><strong>Practical benefit:<\/strong> Better user experience and potentially higher throughput consistency.<\/li>\n<li><strong>Caveats:<\/strong> Additional costs and constraints may apply; availability and implementation details can change\u2014<strong>verify in official docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integration with VPC routing (route tables, propagation)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets your VPC route tables direct traffic for on-prem prefixes toward the VGW\/TGW.<\/li>\n<li><strong>Why it matters:<\/strong> Routing determines what traffic uses the VPN.<\/li>\n<li><strong>Practical benefit:<\/strong> Fine-grained control by subnet and route table.<\/li>\n<li><strong>Caveats:<\/strong> Misconfigured routes are the #1 cause of \u201cVPN is up but traffic doesn\u2019t flow.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring via CloudWatch (tunnel telemetry\/metrics)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Publishes metrics such as tunnel state and data transfer (exact metric names and availability can vary by gateway type\u2014verify in docs).<\/li>\n<li><strong>Why it matters:<\/strong> Enables alerting and operational visibility.<\/li>\n<li><strong>Practical benefit:<\/strong> Trigger alarms when a tunnel goes down or throughput drops.<\/li>\n<li><strong>Caveats:<\/strong> CloudWatch metrics won\u2019t replace device-side IPsec logs; keep logs on your customer gateway device for deep troubleshooting.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Auditing via CloudTrail<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Records API calls for creating\/modifying\/deleting VPN resources.<\/li>\n<li><strong>Why it matters:<\/strong> Governance and security auditing.<\/li>\n<li><strong>Practical benefit:<\/strong> Trace changes during incidents and reviews.<\/li>\n<li><strong>Caveats:<\/strong> CloudTrail logs control plane actions, not packet-level events.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>AWS Site-to-Site VPN is built around an AWS-managed termination point (VGW or TGW) and your customer gateway device. The control plane creates and manages VPN resources; the data plane uses IPsec tunnels over the internet.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Data flow (typical)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>A workload in a VPC sends traffic to an on-premises prefix.<\/li>\n<li>The VPC route table matches that prefix and forwards traffic to the VGW (or to TGW, then to VPN attachment).<\/li>\n<li>AWS encrypts traffic into IPsec and sends it to your customer gateway\u2019s public IP over the internet.<\/li>\n<li>Your customer gateway decrypts and routes it internally.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Control flow (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You define:<\/li>\n<li>Customer gateway (public IP, ASN if BGP)<\/li>\n<li>Gateway (VGW\/TGW)<\/li>\n<li>VPN connection (routing mode, tunnel options)<\/li>\n<li>AWS generates tunnel configuration details.<\/li>\n<li>You apply compatible configuration to your device.<\/li>\n<li>Tunnels establish using IKE and IPsec negotiation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Amazon VPC:<\/strong> subnets, route tables, NACLs, security groups.<\/li>\n<li><strong>AWS Transit Gateway:<\/strong> route tables, VPN attachments, multi-VPC routing.<\/li>\n<li><strong>AWS Direct Connect:<\/strong> use VPN as backup; may also run VPN over DX in some designs (verify best practices for your environment).<\/li>\n<li><strong>AWS Network Manager:<\/strong> visualize and monitor network topology (verify exact supported views and metrics in docs).<\/li>\n<li><strong>CloudWatch + CloudTrail:<\/strong> monitoring and auditing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VPCs, route tables, and gateway resources are mandatory dependencies.<\/li>\n<li>Customer gateway device must be reachable on the internet (public IP) and allow UDP 500\/4500 and ESP as required.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Uses <strong>pre-shared keys (PSK)<\/strong> or device-supported methods as provided by AWS configuration templates.<\/li>\n<li>Negotiation is via <strong>IKE<\/strong>; data encryption via <strong>IPsec ESP<\/strong>.<\/li>\n<li>Access to create\/modify VPN resources is governed by <strong>IAM<\/strong> permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Routing is based on:<\/li>\n<li>VPC route tables (and optionally TGW route tables)<\/li>\n<li>VPN static routes or BGP-learned routes<\/li>\n<li>Security enforcement occurs at:<\/li>\n<li>Security groups (stateful)<\/li>\n<li>Network ACLs (stateless)<\/li>\n<li>On-prem firewalls<\/li>\n<li>Optional inspection VPC appliances<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>CloudWatch<\/strong> alarms for tunnel down conditions.<\/li>\n<li>Use <strong>CloudTrail<\/strong> for change history (who changed what).<\/li>\n<li>Rely on <strong>customer gateway device logs<\/strong> for detailed IKE\/IPsec negotiation issues.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Simple architecture diagram<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  OnPrem[On-prem network\\n(Customer Gateway Device)] -- \"IPsec (2 tunnels)\\nOver Internet\" --&gt; AWSGW[VGW or TGW]\n  AWSGW --&gt; VPC[VPC Subnets\\n(Private workloads)]\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Production-style architecture diagram (hybrid, multi-VPC, centralized routing)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Branches[\"On-prem \/ Branch Sites\"]\n    B1[Site A\\nRouter\/Firewall]\n    B2[Site B\\nRouter\/Firewall]\n  end\n\n  Internet[(Internet)]\n\n  subgraph AWSRegion[\"AWS Region\"]\n    TGW[AWS Transit Gateway]\n    RT[TGW Route Tables]\n    VPC1[Shared Services VPC\\nDNS \/ Logging]\n    VPC2[App VPC]\n    VPC3[Inspection VPC\\nFirewall Appliances]\n    CW[CloudWatch Alarms]\n    CT[CloudTrail]\n  end\n\n  B1 -- \"IPsec VPN (2 tunnels)\" --&gt; Internet --&gt; TGW\n  B2 -- \"IPsec VPN (2 tunnels)\" --&gt; Internet --&gt; TGW\n\n  TGW &lt;--&gt; RT\n  TGW --&gt; VPC3 --&gt; VPC1\n  TGW --&gt; VPC3 --&gt; VPC2\n\n  TGW -.metrics.-&gt; CW\n  TGW -.API audit.-&gt; CT\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">AWS account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An AWS account with access to <strong>Amazon VPC<\/strong> and <strong>AWS Site-to-Site VPN<\/strong>.<\/li>\n<li>A billing method configured (VPN has hourly charges; data transfer charges may apply).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM<\/h3>\n\n\n\n<p>Minimum permissions (conceptual; scope as needed):\n&#8211; <code>ec2:CreateVpnConnection<\/code>, <code>ec2:DeleteVpnConnection<\/code>\n&#8211; <code>ec2:CreateCustomerGateway<\/code>, <code>ec2:DeleteCustomerGateway<\/code>\n&#8211; <code>ec2:CreateVpnGateway<\/code>, <code>ec2:AttachVpnGateway<\/code>, <code>ec2:DetachVpnGateway<\/code>, <code>ec2:DeleteVpnGateway<\/code>\n&#8211; <code>ec2:CreateRoute<\/code>, <code>ec2:ReplaceRoute<\/code>, <code>ec2:EnableVgwRoutePropagation<\/code>\n&#8211; <code>ec2:Describe*<\/code><\/p>\n\n\n\n<p>For production, use least privilege with scoped resource ARNs and conditions where possible.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Console (sufficient for this lab)<\/li>\n<li>Optional: AWS CLI v2 for verification\/automation<br\/>\n  https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Site-to-Site VPN is available in many Regions, but confirm your target Region supports all needed features (especially acceleration) in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VPN-related quotas exist (e.g., number of VPN connections per gateway). Quotas can change. Check:\n  https:\/\/docs.aws.amazon.com\/vpc\/latest\/userguide\/amazon-vpc-limits.html<br\/>\n  and Service Quotas console.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/resources<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A VPC with subnets and route tables.<\/li>\n<li>An internet-reachable public IP on your customer gateway device (for this lab, we\u2019ll use an Elastic IP on an EC2 instance).<\/li>\n<li>Non-overlapping CIDR blocks between on-prem and VPC networks.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>AWS Site-to-Site VPN pricing is <strong>usage-based<\/strong>. Exact prices vary by Region and can change, so use official sources for current rates.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing references<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Site-to-Site VPN Pricing: https:\/\/aws.amazon.com\/vpn\/pricing\/<\/li>\n<li>AWS Pricing Calculator: https:\/\/calculator.aws\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (typical)<\/h3>\n\n\n\n<p>Common cost components include:\n&#8211; <strong>Hourly charge per VPN connection<\/strong> (a VPN connection includes two tunnels).\n&#8211; <strong>Data transfer charges<\/strong>:\n  &#8211; Data transfer out from AWS to the internet is typically charged.\n  &#8211; Data transfer within AWS or in-to-AWS may have different pricing rules. Always validate with AWS Data Transfer pricing: https:\/\/aws.amazon.com\/ec2\/pricing\/on-demand\/#Data_Transfer\n&#8211; <strong>Optional acceleration feature charges<\/strong> (if enabled): may add hourly and\/or data processing charges (verify current model on pricing page).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>AWS Site-to-Site VPN is generally <strong>not free-tier eligible<\/strong> in the way some always-free services are. Verify current free tier conditions (if any) on the pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Number of VPN connections (each includes two tunnels).<\/li>\n<li>Hours running (24\/7 vs part-time dev).<\/li>\n<li>Data volume and direction (especially egress from AWS).<\/li>\n<li>Use of Transit Gateway (TGW has its own hourly and data processing charges).<\/li>\n<li>Additional infrastructure you run for the customer gateway (in this lab: EC2 instances, EIPs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Elastic IP charges<\/strong> (especially if allocated and unused).<\/li>\n<li><strong>NAT Gateway charges<\/strong> if you introduce NAT for private subnet egress.<\/li>\n<li><strong>Transit Gateway costs<\/strong> if you choose TGW instead of VGW.<\/li>\n<li><strong>Operational cost<\/strong>: managing device configuration, key rotation, monitoring, incident response.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization tips<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>one VPN connection per site<\/strong> with proper routing instead of many ad-hoc VPNs.<\/li>\n<li>Use <strong>Transit Gateway<\/strong> thoughtfully\u2014great for scale, but it adds cost. For single-VPC\/simple needs, VGW may be cheaper.<\/li>\n<li>Set up CloudWatch alarms to detect tunnel down early and reduce troubleshooting time.<\/li>\n<li>For dev\/test, schedule teardown when not needed (but note that repeated changes can increase operational overhead).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (how to think about it)<\/h3>\n\n\n\n<p>A minimal lab often includes:\n&#8211; 1 VPN connection (hourly)\n&#8211; 1\u20132 EC2 instances (customer gateway + test host)\n&#8211; 1 Elastic IP\n&#8211; Small data transfer for testing<\/p>\n\n\n\n<p>Because hourly prices vary by Region and can change, calculate by entering:\n&#8211; VPN connection hours (e.g., 10 hours)\n&#8211; EC2 instance hours (e.g., 10 hours each)\n&#8211; Estimated GB transferred out of AWS<\/p>\n\n\n\n<p>Use the AWS Pricing Calculator to get an accurate, Region-specific estimate.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, consider:\n&#8211; Multiple sites (each with a VPN connection)\n&#8211; 24\/7 operation\n&#8211; Higher data volumes (egress charges can dominate)\n&#8211; Transit Gateway hourly + processing charges (if used)\n&#8211; Direct Connect (if used) plus VPN backup<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab creates a real AWS Site-to-Site VPN between:\n&#8211; A VPC that represents \u201cAWS workloads\u201d (with a VGW), and\n&#8211; A second VPC that represents an \u201con-premises network\u201d (with an EC2-based customer gateway running strongSwan).<\/p>\n\n\n\n<p>This is a common training pattern because it\u2019s fully self-contained in AWS, but exercises real IPsec tunnel establishment.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Establish an AWS Site-to-Site VPN connection (two tunnels) between a VPC and a simulated on-prem network, then verify private IP connectivity between hosts over the VPN.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will build:\n&#8211; <strong>AWS VPC (<code>aws-vpc<\/code>)<\/strong>: <code>10.0.0.0\/16<\/code>\n  &#8211; Private subnet with a test EC2 instance\n  &#8211; Virtual Private Gateway (VGW) attached\n&#8211; <strong>On-prem VPC (<code>onprem-vpc<\/code>)<\/strong>: <code>10.1.0.0\/16<\/code>\n  &#8211; Public subnet with a <strong>strongSwan VPN router<\/strong> EC2 instance + Elastic IP\n  &#8211; Private subnet with a test EC2 instance (no public IP)\n&#8211; <strong>AWS Site-to-Site VPN<\/strong>\n  &#8211; Customer Gateway (CGW) points to the strongSwan router Elastic IP\n  &#8211; VPN connection uses static routing (simpler for labs)<\/p>\n\n\n\n<p>Expected outcome:\n&#8211; VPN tunnels show <strong>UP<\/strong> (after configuration).\n&#8211; You can <strong>ping<\/strong> from the AWS private instance to the on-prem private instance using private IPs.<\/p>\n\n\n\n<blockquote>\n<p>Notes before you start:\n&#8211; This lab incurs cost (VPN hourly, EC2, EIP, and possible data transfer).\n&#8211; IPsec configuration is sensitive. Follow the steps carefully and use the downloaded AWS configuration to avoid mismatched parameters.\n&#8211; Vendor-specific parameters evolve. If something doesn\u2019t match your downloaded configuration, prefer the downloaded values.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create the two VPCs and subnets<\/h3>\n\n\n\n<p>Create two VPCs with non-overlapping CIDRs.<\/p>\n\n\n\n<p>1) Create <strong>aws-vpc<\/strong>\n&#8211; CIDR: <code>10.0.0.0\/16<\/code>\n&#8211; Subnets:\n  &#8211; <code>aws-private-subnet<\/code> (e.g., <code>10.0.1.0\/24<\/code>) in one AZ<\/p>\n\n\n\n<p>2) Create <strong>onprem-vpc<\/strong>\n&#8211; CIDR: <code>10.1.0.0\/16<\/code>\n&#8211; Subnets:\n  &#8211; <code>onprem-public-subnet<\/code> (e.g., <code>10.1.1.0\/24<\/code>)\n  &#8211; <code>onprem-private-subnet<\/code> (e.g., <code>10.1.2.0\/24<\/code>)<\/p>\n\n\n\n<p>3) Create and attach an <strong>Internet Gateway (IGW)<\/strong> to <code>onprem-vpc<\/code>.<\/p>\n\n\n\n<p>4) Create route tables:\n&#8211; <code>onprem-public-rt<\/code>: default route <code>0.0.0.0\/0<\/code> -&gt; IGW\n&#8211; <code>onprem-private-rt<\/code>: no default internet route (yet)<\/p>\n\n\n\n<p>Associate:\n&#8211; <code>onprem-public-subnet<\/code> -&gt; <code>onprem-public-rt<\/code>\n&#8211; <code>onprem-private-subnet<\/code> -&gt; <code>onprem-private-rt<\/code><\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have two VPCs. The on-prem public subnet has internet access via IGW.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Launch EC2 instances (strongSwan router + test hosts)<\/h3>\n\n\n\n<p>You will deploy three instances:\n1) <code>cgw-router<\/code> (strongSwan) in <code>onprem-public-subnet<\/code> with Elastic IP<br\/>\n2) <code>onprem-host<\/code> in <code>onprem-private-subnet<\/code> with no public IP<br\/>\n3) <code>aws-host<\/code> in <code>aws-private-subnet<\/code> (you can give it a temporary public IP for setup, or use SSM; for simplicity, a public IP is okay for a lab but lock down SSH)<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">2A) Security groups<\/h4>\n\n\n\n<p>Create security groups:<\/p>\n\n\n\n<p><strong>SG: <code>cgw-router-sg<\/code><\/strong> (attached to <code>cgw-router<\/code>)\n&#8211; Inbound:\n  &#8211; UDP 500 from <code>0.0.0.0\/0<\/code> (IKE)\n  &#8211; UDP 4500 from <code>0.0.0.0\/0<\/code> (NAT-T)\n  &#8211; ESP (IP protocol 50) from <code>0.0.0.0\/0<\/code> (if your environment requires it; some NAT paths rely on UDP encapsulation)\n  &#8211; SSH (TCP 22) from <em>your IP only<\/em>\n&#8211; Outbound: allow all (for simplicity)<\/p>\n\n\n\n<p><strong>SG: <code>onprem-host-sg<\/code><\/strong>\n&#8211; Inbound:\n  &#8211; ICMP from <code>10.0.0.0\/16<\/code>\n  &#8211; SSH from <code>10.1.0.0\/16<\/code> (or from <code>cgw-router<\/code> SG)\n&#8211; Outbound: allow all<\/p>\n\n\n\n<p><strong>SG: <code>aws-host-sg<\/code><\/strong>\n&#8211; Inbound:\n  &#8211; ICMP from <code>10.1.0.0\/16<\/code>\n  &#8211; SSH from <em>your IP only<\/em> (or from a bastion\/SSM)\n&#8211; Outbound: allow all<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">2B) Launch instances<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Launch <code>cgw-router<\/code>:<\/li>\n<li>Subnet: <code>onprem-public-subnet<\/code><\/li>\n<li>Auto-assign public IPv4: <strong>Disable<\/strong> (we\u2019ll attach an Elastic IP instead for stability)<\/li>\n<li>Security group: <code>cgw-router-sg<\/code><\/li>\n<li>OS: Ubuntu LTS (commonly used in VPN appliance labs)<\/li>\n<li>\n<p>Allocate and associate an <strong>Elastic IP<\/strong> to <code>cgw-router<\/code>.<\/p>\n<\/li>\n<li>\n<p>Launch <code>onprem-host<\/code>:<\/p>\n<\/li>\n<li>Subnet: <code>onprem-private-subnet<\/code><\/li>\n<li>Auto-assign public IPv4: disabled<\/li>\n<li>\n<p>Security group: <code>onprem-host-sg<\/code><\/p>\n<\/li>\n<li>\n<p>Launch <code>aws-host<\/code>:<\/p>\n<\/li>\n<li>Subnet: <code>aws-private-subnet<\/code><\/li>\n<li>Security group: <code>aws-host-sg<\/code><\/li>\n<li>For easy access, you may temporarily place it in a public subnet or assign a public IP; for best practice, use AWS Systems Manager Session Manager (requires additional setup). Keep the lab focused; choose what you can operate safely.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">2C) Disable source\/destination check on <code>cgw-router<\/code><\/h4>\n\n\n\n<p>Because <code>cgw-router<\/code> will route traffic between subnets and the VPN, disable source\/dest check:\n&#8211; EC2 Console \u2192 Instances \u2192 <code>cgw-router<\/code> \u2192 Networking \u2192 <strong>Change source\/destination check<\/strong> \u2192 Disable<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Instances are running; the router has a stable Elastic IP; router is allowed to forward traffic.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Configure on-prem VPC routing to use the router<\/h3>\n\n\n\n<p>You need the on-prem private subnet to route AWS VPC traffic to the VPN router instance.<\/p>\n\n\n\n<p>1) In <code>onprem-private-rt<\/code>, add route:\n&#8211; Destination: <code>10.0.0.0\/16<\/code> (AWS VPC CIDR)\n&#8211; Target: <strong><code>cgw-router<\/code> instance<\/strong> (instance target in route table)<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Traffic from <code>onprem-host<\/code> to <code>10.0.0.0\/16<\/code> will be sent to <code>cgw-router<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a Virtual Private Gateway (VGW) and attach it to aws-vpc<\/h3>\n\n\n\n<p>1) VPC Console \u2192 <strong>Virtual private gateways<\/strong> \u2192 Create VGW:\n&#8211; Name: <code>aws-vgw<\/code>\n&#8211; ASN: leave default unless you need a specific value (BGP-related; static routing doesn\u2019t require it)<\/p>\n\n\n\n<p>2) Attach VGW to <code>aws-vpc<\/code>.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> VGW exists and is attached to your VPC.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create the Customer Gateway (CGW)<\/h3>\n\n\n\n<p>1) VPC Console \u2192 <strong>Customer Gateways<\/strong> \u2192 Create customer gateway:\n&#8211; Name: <code>onprem-cgw<\/code>\n&#8211; Routing: <strong>Static<\/strong> (for this lab)\n&#8211; IP address: Elastic IP of <code>cgw-router<\/code><\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Customer gateway resource represents your strongSwan router.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create the VPN connection (static routes)<\/h3>\n\n\n\n<p>1) VPC Console \u2192 <strong>Site-to-Site VPN connections<\/strong> \u2192 Create VPN connection\n&#8211; Name: <code>lab-s2s-vpn<\/code>\n&#8211; Target gateway type: <strong>Virtual private gateway<\/strong>\n&#8211; Virtual private gateway: <code>aws-vgw<\/code>\n&#8211; Customer gateway: existing <code>onprem-cgw<\/code>\n&#8211; Routing options: <strong>Static<\/strong>\n&#8211; Static IP prefixes: add <code>10.1.0.0\/16<\/code> (on-prem CIDR)<\/p>\n\n\n\n<p>2) After creation, select the VPN connection and <strong>Download configuration<\/strong>.\n&#8211; Vendor: if \u201cstrongSwan\u201d is available, choose it; otherwise select a \u201cGeneric\u201d option and adapt.\n&#8211; Keep this file secure; it contains tunnel details and pre-shared keys.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> VPN connection exists with two tunnels in \u201cDOWN\u201d state until strongSwan is configured.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Update aws-vpc route table to send on-prem traffic to VGW<\/h3>\n\n\n\n<p>In the route table associated with <code>aws-private-subnet<\/code>, add:\n&#8211; Destination: <code>10.1.0.0\/16<\/code>\n&#8211; Target: <code>aws-vgw<\/code><\/p>\n\n\n\n<p>If your route table supports <strong>route propagation<\/strong>, you can also enable propagation from the VGW; for a lab, a manual route is explicit and easier to reason about.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> AWS instances know to route on-prem traffic to the VGW.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Configure strongSwan on the customer gateway router<\/h3>\n\n\n\n<p>SSH to <code>cgw-router<\/code> using its Elastic IP.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">8A) Install strongSwan and enable forwarding<\/h4>\n\n\n\n<p>Ubuntu example:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo apt-get update\nsudo apt-get install -y strongswan strongswan-pki\n\n# Enable IPv4 forwarding\necho \"net.ipv4.ip_forward=1\" | sudo tee \/etc\/sysctl.d\/99-ipsec.conf\nsudo sysctl -p \/etc\/sysctl.d\/99-ipsec.conf\n<\/code><\/pre>\n\n\n\n<p>Allow forwarding in the instance firewall if you use UFW; if not using UFW, skip:<\/p>\n\n\n\n<pre><code class=\"language-bash\"># If UFW is enabled:\nsudo ufw allow 500\/udp\nsudo ufw allow 4500\/udp\nsudo ufw allow OpenSSH\nsudo ufw disable  # For labs, you can disable to reduce variables; for production, configure it properly.\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">8B) Apply AWS tunnel configuration<\/h4>\n\n\n\n<p>Use the downloaded VPN configuration from AWS as the source of truth.<\/p>\n\n\n\n<p>You must locate (per tunnel):\n&#8211; AWS tunnel endpoint public IP (two values)\n&#8211; Pre-shared keys (two values)\n&#8211; IKE version and encryption\/authentication algorithms\n&#8211; Any required lifetimes\/DPD settings\n&#8211; (If using route-based VTI) inside tunnel IP addressing and marks<\/p>\n\n\n\n<p>Because these values are generated per VPN, do <strong>not<\/strong> blindly copy parameters from a blog post. Use your downloaded configuration.<\/p>\n\n\n\n<p>A common strongSwan layout is:\n&#8211; <code>\/etc\/ipsec.conf<\/code>\n&#8211; <code>\/etc\/ipsec.secrets<\/code><\/p>\n\n\n\n<p>Below is a <strong>template<\/strong> that you should adapt to match your downloaded config. If your AWS download provides a strongSwan-ready config, use it directly.<\/p>\n\n\n\n<p><strong>\/etc\/ipsec.conf (template \u2013 adjust to your downloaded config)<\/strong><\/p>\n\n\n\n<pre><code class=\"language-conf\">config setup\n  charondebug=\"ike 1, knl 1, cfg 0\"\n\nconn %default\n  keyexchange=ikev2\n  type=tunnel\n  authby=psk\n  dpdaction=restart\n  dpddelay=10s\n  dpdtimeout=30s\n  rekey=yes\n  keyingtries=%forever\n\n  # Local (customer gateway)\n  left=%defaultroute\n  leftid=&lt;CGW_PUBLIC_IP&gt;\n\n  # For route-based\/VTI setups, many templates use 0.0.0.0\/0 selectors\n  leftsubnet=0.0.0.0\/0\n  rightsubnet=0.0.0.0\/0\n\nconn tunnel1\n  right=&lt;AWS_TUNNEL1_PUBLIC_IP&gt;\n  auto=start\n  ike=&lt;MATCH_DOWNLOADED_IKE_PARAMS&gt;\n  esp=&lt;MATCH_DOWNLOADED_ESP_PARAMS&gt;\n\nconn tunnel2\n  right=&lt;AWS_TUNNEL2_PUBLIC_IP&gt;\n  auto=start\n  ike=&lt;MATCH_DOWNLOADED_IKE_PARAMS&gt;\n  esp=&lt;MATCH_DOWNLOADED_ESP_PARAMS&gt;\n<\/code><\/pre>\n\n\n\n<p><strong>\/etc\/ipsec.secrets (template)<\/strong><\/p>\n\n\n\n<pre><code class=\"language-conf\">&lt;CGW_PUBLIC_IP&gt; &lt;AWS_TUNNEL1_PUBLIC_IP&gt; : PSK \"&lt;TUNNEL1_PSK&gt;\"\n&lt;CGW_PUBLIC_IP&gt; &lt;AWS_TUNNEL2_PUBLIC_IP&gt; : PSK \"&lt;TUNNEL2_PSK&gt;\"\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>If your downloaded config specifies IKEv1, set <code>keyexchange=ikev1<\/code>. If it specifies particular proposals (AES\/SHA\/DH groups), match them exactly.<\/p>\n<\/blockquote>\n\n\n\n<h4 class=\"wp-block-heading\">8C) (Optional but common) Route-based VTI interface setup<\/h4>\n\n\n\n<p>Many modern AWS Site-to-Site VPN device configs use route-based VPN with VTIs. AWS often provides a sample up\/down script for Linux-based devices.<\/p>\n\n\n\n<p>If your downloaded strongSwan config includes VTI instructions, follow it. If it does not, consult AWS documentation for Linux customer gateway examples and ensure you understand how marks, VTIs, and routes are applied.<\/p>\n\n\n\n<p>A common pattern is:\n&#8211; Create <code>vti0<\/code> for tunnel1 and <code>vti1<\/code> for tunnel2\n&#8211; Assign inside tunnel IPs (169.254.x.x\/30 pairs)\n&#8211; Add routes to AWS CIDR via the VTI\n&#8211; Disable policy enforcement on the VTI interface (<code>disable_policy=1<\/code>) so the kernel routes correctly<\/p>\n\n\n\n<p>Because inside IPs and marks are generated per tunnel, <strong>use your downloaded config<\/strong>.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">8D) Restart strongSwan<\/h4>\n\n\n\n<pre><code class=\"language-bash\">sudo systemctl restart strongswan\nsudo systemctl status strongswan --no-pager\n<\/code><\/pre>\n\n\n\n<p>Check status:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo ipsec statusall\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> strongSwan attempts to bring up both tunnels. Within a few minutes, the AWS console should show tunnels as <strong>UP<\/strong> if parameters match and security groups\/routes allow negotiation.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Verify tunnel status in AWS<\/h3>\n\n\n\n<p>In the AWS Console:\n&#8211; VPC \u2192 Site-to-Site VPN connections \u2192 <code>lab-s2s-vpn<\/code>\n&#8211; Check both tunnels<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> At least one tunnel shows <strong>UP<\/strong>. Ideally both show <strong>UP<\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Test private connectivity end-to-end<\/h3>\n\n\n\n<p>You want to test:\n&#8211; <code>aws-host<\/code> (10.0.x.x) \u2192 <code>onprem-host<\/code> (10.1.x.x)\n&#8211; Optionally, the reverse direction as well<\/p>\n\n\n\n<p>From <code>aws-host<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ping -c 4 &lt;ONPREM_HOST_PRIVATE_IP&gt;\n<\/code><\/pre>\n\n\n\n<p>From <code>onprem-host<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ping -c 4 &lt;AWS_HOST_PRIVATE_IP&gt;\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Pings succeed. If not, see Troubleshooting.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<p>1) <strong>Tunnels are UP<\/strong>\n&#8211; AWS Console shows tunnel(s) UP.\n&#8211; On <code>cgw-router<\/code>, <code>sudo ipsec statusall<\/code> shows established SAs.<\/p>\n\n\n\n<p>2) <strong>Routes are correct<\/strong>\n&#8211; <code>aws-private-subnet<\/code> route table has <code>10.1.0.0\/16 -&gt; VGW<\/code>\n&#8211; VPN connection has static route <code>10.1.0.0\/16<\/code>\n&#8211; <code>onprem-private-rt<\/code> routes <code>10.0.0.0\/16 -&gt; cgw-router<\/code><\/p>\n\n\n\n<p>3) <strong>Security groups\/NACLs allow traffic<\/strong>\n&#8211; ICMP allowed between CIDRs (for ping)\n&#8211; UDP 500\/4500 allowed to <code>cgw-router<\/code><\/p>\n\n\n\n<p>4) <strong>Forwarding is enabled<\/strong>\n&#8211; <code>net.ipv4.ip_forward=1<\/code> on <code>cgw-router<\/code>\n&#8211; Source\/dest check disabled on <code>cgw-router<\/code><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and realistic fixes:<\/p>\n\n\n\n<p><strong>Issue: Tunnels stay DOWN<\/strong>\n&#8211; Verify <code>cgw-router-sg<\/code> allows UDP 500 and 4500 inbound.\n&#8211; Verify you used the correct Elastic IP as the Customer Gateway IP.\n&#8211; Confirm your <code>leftid<\/code>\/<code>right<\/code>\/PSKs match the downloaded config exactly.\n&#8211; Check strongSwan logs:\n  <code>bash\n  sudo journalctl -u strongswan --no-pager | tail -200<\/code>\n&#8211; Confirm time sync (clock skew can break IKE). Ensure NTP is working.<\/p>\n\n\n\n<p><strong>Issue: Tunnel is UP but ping fails<\/strong>\n&#8211; Route tables missing:\n  &#8211; AWS route table missing <code>10.1.0.0\/16 -&gt; VGW<\/code>\n  &#8211; onprem-private-rt missing <code>10.0.0.0\/16 -&gt; cgw-router<\/code>\n&#8211; Linux forwarding not enabled on <code>cgw-router<\/code>.\n&#8211; Source\/dest check not disabled on <code>cgw-router<\/code>.\n&#8211; Security group doesn\u2019t allow ICMP (or test TCP 22\/80 instead).\n&#8211; NACLs blocking traffic (less common in labs, but possible).<\/p>\n\n\n\n<p><strong>Issue: Only one tunnel is UP<\/strong>\n&#8211; This can be normal if your device is only configured for one tunnel or routing prefers one.\n&#8211; Ensure both tunnels are configured and allowed through security group.\n&#8211; For active\/active, typically you need BGP and device support (verify for your design).<\/p>\n\n\n\n<p><strong>Issue: StrongSwan proposals don\u2019t match<\/strong>\n&#8211; AWS config specifies exact IKE\/ESP proposals; strongSwan must match.\n&#8211; Don\u2019t reuse generic AES\/SHA\/DH settings\u2014copy from the downloaded config.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete resources in roughly this order:<\/p>\n\n\n\n<p>1) Delete VPN connection <code>lab-s2s-vpn<\/code>\n2) Delete Customer Gateway <code>onprem-cgw<\/code>\n3) Detach and delete Virtual Private Gateway <code>aws-vgw<\/code>\n4) Terminate EC2 instances: <code>cgw-router<\/code>, <code>onprem-host<\/code>, <code>aws-host<\/code>\n5) Release Elastic IP (after instance termination)\n6) Delete route table entries you created\n7) Delete subnets and VPCs (<code>aws-vpc<\/code>, <code>onprem-vpc<\/code>)\n8) Delete security groups created for the lab<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>Transit Gateway<\/strong> for multi-VPC, multi-site architectures to simplify routing and segmentation.<\/li>\n<li>Design for <strong>failure domains<\/strong>:<\/li>\n<li>Use both tunnels.<\/li>\n<li>Consider separate customer gateway devices (or separate ISPs) for higher resilience.<\/li>\n<li>Avoid overlapping CIDRs; plan IP addressing early.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Restrict who can create\/modify VPN resources with least-privilege IAM.<\/li>\n<li>Require MFA and use roles with session-based access for admins.<\/li>\n<li>Use CloudTrail and centralized logging accounts to audit changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Right-size connectivity:<\/li>\n<li>Single-VPC needs may not require TGW.<\/li>\n<li>Avoid leaving dev VPNs running 24\/7.<\/li>\n<li>Monitor data transfer out; design data flows to minimize egress.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use BGP for better failover and potential multi-tunnel utilization (device-dependent).<\/li>\n<li>Place VPN endpoints in the Region closest to your on-prem site to reduce latency.<\/li>\n<li>If considering acceleration, test and validate improvements versus added cost (verify current behavior in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use redundant customer gateways (separate devices\/links) for critical systems.<\/li>\n<li>Implement CloudWatch alarms on tunnel status.<\/li>\n<li>Document runbooks for tunnel failure, rekey events, and routing changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep device configuration under version control (securely), with change review.<\/li>\n<li>Standardize naming\/tagging: environment, site, owner, cost center.<\/li>\n<li>Rotate keys and review cipher policies periodically (based on security requirements).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Tag VPN resources: <code>Environment<\/code>, <code>Owner<\/code>, <code>Application<\/code>, <code>CostCenter<\/code>, <code>Site<\/code>.<\/li>\n<li>Use consistent names: <code>vpn-prod-siteA<\/code>, <code>cgw-siteA-fw1<\/code>, <code>tgw-prod-core<\/code>.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS resource access is governed by <strong>IAM<\/strong>:<\/li>\n<li>Use role-based access and least privilege.<\/li>\n<li>Restrict actions like <code>CreateVpnConnection<\/code> and <code>ModifyVpnConnectionOptions<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data is encrypted in transit using <strong>IPsec<\/strong>.<\/li>\n<li>Your actual encryption strength depends on negotiated ciphers and DH groups.<\/li>\n<li>Align VPN cryptography with your organization\u2019s security baseline; confirm AWS-supported proposals in current documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The customer gateway device must be reachable on the public internet (public IP).<\/li>\n<li>Ensure perimeter controls allow only necessary protocols:<\/li>\n<li>UDP 500 (IKE)<\/li>\n<li>UDP 4500 (NAT-T)<\/li>\n<li>ESP (protocol 50) if required by your setup<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling (PSKs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Pre-shared keys are sensitive secrets.<\/li>\n<li>Store PSKs securely (secret managers, encrypted vaults); do not paste into tickets or chat.<\/li>\n<li>Rotate PSKs according to your policy; ensure change windows and rollback plans.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CloudTrail:<\/strong> audit VPN resource changes.<\/li>\n<li><strong>Device logs:<\/strong> maintain IKE\/IPsec logs on customer gateway for forensics.<\/li>\n<li><strong>CloudWatch:<\/strong> alarm on tunnel down and anomalous throughput.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Many compliance frameworks require encryption in transit; IPsec supports that requirement.<\/li>\n<li>Compliance also requires access control and audit trails\u2014use IAM + CloudTrail.<\/li>\n<li>Verify whether your compliance needs require dedicated connectivity (Direct Connect) or specific cryptographic modules (this is environment-specific).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Allowing UDP 500\/4500 from everywhere without additional controls in production.<\/li>\n<li>Reusing PSKs across environments.<\/li>\n<li>Not segmenting routes (advertising overly broad prefixes).<\/li>\n<li>Missing monitoring\u2014tunnel down goes unnoticed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>restricted firewall rules<\/strong> (limit IKE\/NAT-T sources when possible).<\/li>\n<li>Prefer <strong>BGP with proper filtering<\/strong> to control route propagation.<\/li>\n<li>Use separate VPNs for separate trust zones (prod vs dev) and segment with TGW route tables.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>Limits and exact numbers change. Always confirm in official docs and Service Quotas.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ constraints (common)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Internet-based VPN performance is variable (latency\/jitter\/packet loss depend on internet path).<\/li>\n<li>Some advanced routing behaviors require BGP and compatible devices.<\/li>\n<li>Troubleshooting often requires coordinating logs\/telemetry from both AWS and the customer gateway device.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits on:<\/li>\n<li>VPN connections per VGW\/TGW<\/li>\n<li>Routes per VPN (static) and route table capacities<\/li>\n<li>Check Service Quotas and VPC limits documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VPN resources are created per Region; cross-Region connectivity requires separate design (e.g., TGW peering, Cloud WAN, or separate VPNs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data transfer out of AWS can be a major cost driver.<\/li>\n<li>Transit Gateway adds hourly and per-GB processing costs.<\/li>\n<li>Acceleration (if enabled) may add additional hourly\/data charges.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not all devices support the same IKE\/IPsec proposals.<\/li>\n<li>NAT in front of the customer gateway can complicate negotiation (NAT-T).<\/li>\n<li>MTU\/MSS issues can cause \u201cit connects but apps are slow.\u201d TCP MSS clamping is often required on some devices\u2014verify with your vendor and AWS guidance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u201cTunnel UP but no traffic\u201d is almost always routing\/security group\/NACL\/source-dest-check related.<\/li>\n<li>Overlapping CIDRs prevent routing and may require NAT or readdressing (complex).<\/li>\n<li>Rekey events can briefly disrupt traffic if device behavior differs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Moving from VGW to TGW-based VPN changes routing model and may require downtime\/careful cutover.<\/li>\n<li>Adding sites later may require redesign if you started with point-to-point VGW patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some vendors require policy-based selectors; AWS commonly uses route-based constructs. Use AWS-provided vendor templates whenever possible.<\/li>\n<li>SD-WAN platforms may abstract IPsec details; ensure they still match AWS parameters.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>AWS Site-to-Site VPN is one option among several hybrid and intra-cloud connectivity approaches.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>AWS Site-to-Site VPN<\/strong><\/td>\n<td>Hybrid connectivity over internet<\/td>\n<td>Fast to deploy, encrypted, managed AWS endpoint, two tunnels<\/td>\n<td>Variable internet performance, device config complexity<\/td>\n<td>Quick hybrid connectivity, branch connectivity, DX backup<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Direct Connect<\/strong><\/td>\n<td>Dedicated private connectivity<\/td>\n<td>Predictable performance, lower latency variability, private circuit<\/td>\n<td>Lead time, cost, colocation\/partner dependency<\/td>\n<td>Mission-critical connectivity, consistent throughput\/latency<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Client VPN<\/strong><\/td>\n<td>Remote user access<\/td>\n<td>Managed client VPN for users<\/td>\n<td>Not meant for site routers; user\/device management<\/td>\n<td>Workforce access to VPC\/private apps<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Transit Gateway (without VPN)<\/strong><\/td>\n<td>VPC-to-VPC routing<\/td>\n<td>Scalable hub routing inside AWS<\/td>\n<td>Doesn\u2019t connect on-prem by itself<\/td>\n<td>Multi-VPC architecture within AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>VPC Peering<\/strong><\/td>\n<td>Simple VPC-to-VPC connectivity<\/td>\n<td>Low latency, simple<\/td>\n<td>Non-transitive, route limits, scaling complexity<\/td>\n<td>Small number of VPCs needing direct connectivity<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed IPsec on EC2<\/strong><\/td>\n<td>Custom VPN needs<\/td>\n<td>Full control<\/td>\n<td>You manage availability, scaling, patching<\/td>\n<td>Niche cases where managed VPN doesn\u2019t fit<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure VPN Gateway<\/strong><\/td>\n<td>Hybrid to Azure<\/td>\n<td>Similar managed model<\/td>\n<td>Cloud-specific<\/td>\n<td>If your workloads are in Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud VPN<\/strong><\/td>\n<td>Hybrid to GCP<\/td>\n<td>Similar managed model<\/td>\n<td>Cloud-specific<\/td>\n<td>If your workloads are in GCP<\/td>\n<\/tr>\n<tr>\n<td><strong>Third-party SD-WAN<\/strong><\/td>\n<td>Many sites, advanced routing\/policy<\/td>\n<td>Central policy, app-aware routing<\/td>\n<td>Cost\/complexity, vendor lock-in<\/td>\n<td>Large branch networks with advanced needs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Retail chain with hundreds of stores<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Stores need secure access to centrally hosted applications in AWS, plus segmented access to payment systems. MPLS is expensive and slow to expand.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Transit Gateway in primary Region<\/li>\n<li>Site-to-Site VPN from each store SD-WAN\/router into TGW (two tunnels per connection)<\/li>\n<li>TGW route tables segment:<ul>\n<li>Store-to-app routes<\/li>\n<li>Store-to-payment routes (restricted)<\/li>\n<\/ul>\n<\/li>\n<li>Centralized inspection VPC with firewalls for egress control<\/li>\n<li>CloudWatch alarms on tunnel state, Network Manager for visibility (verify features)<\/li>\n<li><strong>Why AWS Site-to-Site VPN was chosen:<\/strong><\/li>\n<li>Fast rollout to many sites using existing internet links<\/li>\n<li>Standard IPsec compatibility with branch routers<\/li>\n<li>Works well as an overlay even when some sites later adopt Direct Connect through hubs<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Rapid onboarding of stores<\/li>\n<li>Encrypted connectivity and consistent segmentation<\/li>\n<li>Centralized operations and alerting<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Hybrid SaaS migration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup has a legacy on-prem database and wants to move app servers to AWS quickly without exposing the database publicly.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Single VPC with VGW<\/li>\n<li>One AWS Site-to-Site VPN to the office firewall<\/li>\n<li>App servers in private subnets; database remains on-prem temporarily<\/li>\n<li><strong>Why AWS Site-to-Site VPN was chosen:<\/strong><\/li>\n<li>Low operational overhead compared to building VPN appliances<\/li>\n<li>Enough bandwidth and security for phased migration<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Private connectivity for app-to-db<\/li>\n<li>Faster migration without re-architecting networking upfront<\/li>\n<li>Simple rollback path during cutover<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) Is AWS Site-to-Site VPN the same as AWS Client VPN?<\/h3>\n\n\n\n<p>No. <strong>AWS Site-to-Site VPN<\/strong> connects networks (site routers\/firewalls) to AWS. <strong>AWS Client VPN<\/strong> connects individual users\/devices to AWS.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Does one VPN connection include two tunnels?<\/h3>\n\n\n\n<p>Yes. A standard AWS Site-to-Site VPN connection includes <strong>two tunnels<\/strong> for redundancy.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Can I use BGP with AWS Site-to-Site VPN?<\/h3>\n\n\n\n<p>Yes, dynamic routing with <strong>BGP<\/strong> is supported when you select dynamic routing and configure ASNs appropriately.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) Should I choose static routes or BGP?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Choose <strong>BGP<\/strong> for resilience and easier route management at scale.<\/li>\n<li>Choose <strong>static<\/strong> for small\/simple networks or where BGP is not possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Does AWS manage my on-prem device?<\/h3>\n\n\n\n<p>No. AWS manages the AWS endpoint (VGW\/TGW side). You manage the customer gateway device configuration and operations.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) Can I connect multiple VPCs to one on-prem network?<\/h3>\n\n\n\n<p>Yes\u2014best done using <strong>AWS Transit Gateway<\/strong> (hub-and-spoke). With VGW, it\u2019s more limited and often becomes complex.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) Can I use AWS Site-to-Site VPN as backup for Direct Connect?<\/h3>\n\n\n\n<p>Yes. This is a common design pattern for resiliency.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) Why are my tunnels UP but traffic doesn\u2019t flow?<\/h3>\n\n\n\n<p>Common causes:\n&#8211; Missing routes (VPC route table \/ on-prem routes)\n&#8211; Security groups\/NACLs blocking traffic\n&#8211; Source\/destination check not disabled on a routing instance\n&#8211; Overlapping CIDRs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) Do I need an internet gateway in my VPC to use Site-to-Site VPN?<\/h3>\n\n\n\n<p>Not for the VPC\u2019s private subnets to use the VPN. But your on-prem customer gateway must have internet reachability to establish tunnels to AWS public endpoints.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) How do I monitor tunnel health?<\/h3>\n\n\n\n<p>Use <strong>CloudWatch metrics\/alarms<\/strong> for tunnel state and throughput, and monitor customer gateway device logs for IKE\/IPsec events.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) Are VPN tunnels encrypted end-to-end?<\/h3>\n\n\n\n<p>Traffic between gateways is encrypted with IPsec. Inside your networks (within VPC or within on-prem), traffic is routed normally unless you add additional encryption.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) Can I restrict which subnets can use the VPN?<\/h3>\n\n\n\n<p>Yes. Use VPC route tables (associate only certain subnets) and security groups\/NACLs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) What happens during rekeying?<\/h3>\n\n\n\n<p>IPsec rekeys are normal. Some devices handle them differently and may cause brief disruption; test under load and follow AWS\/vendor recommended settings.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) Can I use the same customer gateway for multiple VPN connections?<\/h3>\n\n\n\n<p>Yes, you can define multiple VPN connections to the same customer gateway device if needed, but consider operational complexity and routing design.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) Is AWS Site-to-Site VPN suitable for high-throughput, low-latency applications?<\/h3>\n\n\n\n<p>Sometimes, but the internet path is variable. For strict performance requirements, consider <strong>AWS Direct Connect<\/strong>, or test acceleration options (verify current performance guidance in official docs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">16) Can I connect to a Transit Gateway instead of a VPC?<\/h3>\n\n\n\n<p>Yes. AWS Site-to-Site VPN can terminate on a <strong>Transit Gateway<\/strong> VPN attachment (recommended for multi-VPC architectures).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">17) Do I need to open inbound ports to my on-prem network?<\/h3>\n\n\n\n<p>Your customer gateway must accept IKE\/IPsec negotiation from AWS tunnel endpoints. That usually means allowing UDP 500\/4500 (and sometimes ESP) to the gateway.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn AWS Site-to-Site VPN<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>AWS Site-to-Site VPN User Guide<\/td>\n<td>Primary, authoritative reference for concepts, configuration, and operations: https:\/\/docs.aws.amazon.com\/vpn\/latest\/s2svpn\/what-is-vpn.html<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Amazon VPC User Guide (VGW\/VPN sections)<\/td>\n<td>Explains VPC routing, gateways, and hybrid networking: https:\/\/docs.aws.amazon.com\/vpc\/latest\/userguide\/<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>AWS Transit Gateway documentation<\/td>\n<td>Required if you terminate VPN on TGW: https:\/\/docs.aws.amazon.com\/vpc\/latest\/tgw\/what-is-transit-gateway.html<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>AWS VPN Pricing<\/td>\n<td>Current pricing dimensions and Region-specific info: https:\/\/aws.amazon.com\/vpn\/pricing\/<\/td>\n<\/tr>\n<tr>\n<td>Official calculator<\/td>\n<td>AWS Pricing Calculator<\/td>\n<td>Build realistic cost estimates: https:\/\/calculator.aws\/<\/td>\n<\/tr>\n<tr>\n<td>Official quotas<\/td>\n<td>Amazon VPC limits \/ Service Quotas<\/td>\n<td>Understand quotas and request increases: https:\/\/docs.aws.amazon.com\/vpc\/latest\/userguide\/amazon-vpc-limits.html<\/td>\n<\/tr>\n<tr>\n<td>Official monitoring<\/td>\n<td>Amazon CloudWatch<\/td>\n<td>Metrics and alarms for VPN tunnel telemetry (verify specific metrics in docs): https:\/\/docs.aws.amazon.com\/AmazonCloudWatch\/latest\/monitoring\/WhatIsCloudWatch.html<\/td>\n<\/tr>\n<tr>\n<td>Official audit logging<\/td>\n<td>AWS CloudTrail<\/td>\n<td>Track control-plane changes to VPN resources: https:\/\/docs.aws.amazon.com\/awscloudtrail\/latest\/userguide\/cloudtrail-user-guide.html<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>AWS Architecture Center<\/td>\n<td>Patterns for hybrid networking and multi-VPC design: https:\/\/aws.amazon.com\/architecture\/<\/td>\n<\/tr>\n<tr>\n<td>Reference architectures<\/td>\n<td>AWS Prescriptive Guidance (Networking)<\/td>\n<td>Practical guidance for enterprise networking patterns: https:\/\/docs.aws.amazon.com\/prescriptive-guidance\/latest\/networking\/<\/td>\n<\/tr>\n<tr>\n<td>Workshops\/labs<\/td>\n<td>AWS Workshops (search for networking\/VPN\/TGW)<\/td>\n<td>Hands-on labs; content varies over time: https:\/\/workshops.aws\/<\/td>\n<\/tr>\n<tr>\n<td>Videos<\/td>\n<td>AWS YouTube channel<\/td>\n<td>Talks and re:Invent sessions on hybrid networking: https:\/\/www.youtube.com\/@AmazonWebServices<\/td>\n<\/tr>\n<tr>\n<td>Community (highly used)<\/td>\n<td>strongSwan Documentation<\/td>\n<td>Device-side implementation details for Linux VPN endpoints: https:\/\/docs.strongswan.org\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>DevOpsSchool.com<\/strong>\n&#8211; Suitable audience: DevOps engineers, SREs, cloud engineers, platform teams\n&#8211; Likely learning focus: AWS operations, DevOps tooling, cloud networking fundamentals\n&#8211; Mode: check website\n&#8211; Website: https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>ScmGalaxy.com<\/strong>\n&#8211; Suitable audience: Developers, DevOps beginners, build\/release engineers\n&#8211; Likely learning focus: SCM, CI\/CD, DevOps foundations that complement cloud networking\n&#8211; Mode: check website\n&#8211; Website: https:\/\/www.scmgalaxy.com\/<\/p>\n<\/li>\n<li>\n<p><strong>CLoudOpsNow.in<\/strong>\n&#8211; Suitable audience: CloudOps engineers, operations teams, junior-to-mid cloud practitioners\n&#8211; Likely learning focus: Cloud operations, monitoring, reliability, and cloud infrastructure practices\n&#8211; Mode: check website\n&#8211; Website: https:\/\/www.cloudopsnow.in\/<\/p>\n<\/li>\n<li>\n<p><strong>SreSchool.com<\/strong>\n&#8211; Suitable audience: SREs, production engineering, reliability-focused teams\n&#8211; Likely learning focus: Reliability engineering, observability, incident response practices relevant to hybrid connectivity\n&#8211; Mode: check website\n&#8211; Website: https:\/\/www.sreschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>AiOpsSchool.com<\/strong>\n&#8211; Suitable audience: Operations teams adopting AIOps, monitoring and automation practitioners\n&#8211; Likely learning focus: AIOps concepts, automation, operational analytics that can complement network monitoring\n&#8211; Mode: check website\n&#8211; Website: https:\/\/www.aiopsschool.com\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>RajeshKumar.xyz<\/strong>\n&#8211; Likely specialization: DevOps and cloud training content (verify exact offerings on site)\n&#8211; Suitable audience: Beginners to practitioners seeking practical guidance\n&#8211; Website: https:\/\/rajeshkumar.xyz\/<\/p>\n<\/li>\n<li>\n<p><strong>devopstrainer.in<\/strong>\n&#8211; Likely specialization: DevOps tooling and cloud-oriented training (verify exact offerings on site)\n&#8211; Suitable audience: DevOps engineers and cloud learners\n&#8211; Website: https:\/\/www.devopstrainer.in\/<\/p>\n<\/li>\n<li>\n<p><strong>devopsfreelancer.com<\/strong>\n&#8211; Likely specialization: DevOps consulting\/training style resources (verify exact offerings on site)\n&#8211; Suitable audience: Teams or individuals looking for practical implementation help\n&#8211; Website: https:\/\/www.devopsfreelancer.com\/<\/p>\n<\/li>\n<li>\n<p><strong>devopssupport.in<\/strong>\n&#8211; Likely specialization: DevOps support and training resources (verify exact offerings on site)\n&#8211; Suitable audience: Operations and DevOps teams needing hands-on support\n&#8211; Website: https:\/\/www.devopssupport.in\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>cotocus.com<\/strong>\n&#8211; Likely service area: Cloud and DevOps consulting (verify service catalog on site)\n&#8211; Where they may help: Cloud migration planning, infrastructure automation, operations setup\n&#8211; Consulting use case examples:\n  &#8211; Hybrid connectivity planning (VPN\/DX) and routing design review\n  &#8211; VPC\/TGW architecture and segmentation guidance\n  &#8211; Cost optimization for network egress and connectivity\n&#8211; Website: https:\/\/cotocus.com\/<\/p>\n<\/li>\n<li>\n<p><strong>DevOpsSchool.com<\/strong>\n&#8211; Likely service area: DevOps and cloud consulting\/training services (verify on site)\n&#8211; Where they may help: Training + implementation support for cloud infrastructure and operations\n&#8211; Consulting use case examples:\n  &#8211; Building standardized connectivity patterns across environments\n  &#8211; Implementing monitoring\/alerting for VPN tunnel health\n  &#8211; Creating runbooks and operational readiness for hybrid networks\n&#8211; Website: https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>DEVOPSCONSULTING.IN<\/strong>\n&#8211; Likely service area: DevOps consulting services (verify on site)\n&#8211; Where they may help: DevOps transformation, cloud operations, automation\n&#8211; Consulting use case examples:\n  &#8211; Infrastructure-as-code patterns for networking resources\n  &#8211; Security reviews for hybrid connectivity and IAM boundaries\n  &#8211; Production readiness checks for VPN-based connectivity\n&#8211; Website: https:\/\/www.devopsconsulting.in\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before AWS Site-to-Site VPN<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Networking fundamentals:<\/li>\n<li>IPv4 addressing, CIDR, routing, NAT<\/li>\n<li>TCP\/UDP basics, MTU\/MSS<\/li>\n<li>Security fundamentals:<\/li>\n<li>Encryption in transit, key exchange basics<\/li>\n<li>AWS fundamentals:<\/li>\n<li>VPCs, subnets, route tables, security groups, NACLs<\/li>\n<li>IAM and CloudTrail basics<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after AWS Site-to-Site VPN<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Transit Gateway deep dive (route tables, segmentation)<\/li>\n<li>AWS Direct Connect and resilient hybrid architectures<\/li>\n<li>Network security patterns:<\/li>\n<li>Inspection VPC, centralized egress, firewall appliances<\/li>\n<li>Observability:<\/li>\n<li>CloudWatch alarms, logs strategy, incident response runbooks<\/li>\n<li>Infrastructure as Code:<\/li>\n<li>CloudFormation\/Terraform for reproducible networking<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Network Engineer<\/li>\n<li>Solutions Architect<\/li>\n<li>Platform Engineer<\/li>\n<li>SRE \/ Production Engineer<\/li>\n<li>Security Engineer (network\/security boundary designs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>AWS certifications change over time; verify current paths on AWS Training &amp; Certification.\nRelevant tracks often include:\n&#8211; AWS Certified Solutions Architect (Associate\/Professional)\n&#8211; AWS Certified Advanced Networking \u2013 Specialty (if available; verify current status)\nOfficial portal: https:\/\/aws.amazon.com\/certification\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a TGW hub-and-spoke with two VPCs and one VPN site; implement segmentation with TGW route tables.<\/li>\n<li>Implement VPN + Direct Connect backup design (simulate DX routing logic with lab constructs; validate failover behavior carefully).<\/li>\n<li>Create CloudWatch alarms and an operational dashboard for tunnel state and traffic metrics.<\/li>\n<li>Write Terraform to deploy VGW\/TGW VPN patterns with consistent tagging and naming.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Site-to-Site VPN:<\/strong> Managed AWS service that provides IPsec VPN tunnels between your network and AWS.<\/li>\n<li><strong>IPsec:<\/strong> Suite of protocols for encrypting and authenticating IP packets.<\/li>\n<li><strong>IKE (Internet Key Exchange):<\/strong> Protocol used to set up security associations for IPsec.<\/li>\n<li><strong>Tunnel:<\/strong> Encrypted path between two VPN endpoints.<\/li>\n<li><strong>VGW (Virtual Private Gateway):<\/strong> AWS-managed VPN endpoint for a single VPC.<\/li>\n<li><strong>TGW (Transit Gateway):<\/strong> AWS-managed hub router for connecting VPCs and on-prem networks.<\/li>\n<li><strong>Customer Gateway (CGW):<\/strong> AWS resource representing your on-prem VPN endpoint (public IP, ASN).<\/li>\n<li><strong>BGP:<\/strong> Dynamic routing protocol used to exchange routes and enable resilient routing.<\/li>\n<li><strong>Static routes:<\/strong> Manually configured network prefixes for routing over the VPN.<\/li>\n<li><strong>Route table:<\/strong> Set of routing rules that determines where network traffic is directed.<\/li>\n<li><strong>Security group:<\/strong> Stateful virtual firewall attached to ENIs\/instances in a VPC.<\/li>\n<li><strong>Network ACL (NACL):<\/strong> Stateless subnet-level firewall.<\/li>\n<li><strong>Elastic IP (EIP):<\/strong> Static public IPv4 address in AWS.<\/li>\n<li><strong>Source\/destination check:<\/strong> EC2 feature that must be disabled on instances that forward traffic like routers.<\/li>\n<li><strong>CIDR:<\/strong> Notation for IP prefixes (e.g., 10.0.0.0\/16).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>AWS Site-to-Site VPN (AWS) is a managed <strong>Networking and content delivery<\/strong> service that provides <strong>encrypted IPsec connectivity<\/strong> between your on-premises network (customer gateway) and AWS (VGW or TGW). It matters because it enables fast, secure hybrid networking with built-in redundancy (two tunnels per connection) and flexible routing (static or BGP).<\/p>\n\n\n\n<p>Cost is primarily driven by <strong>VPN connection hours<\/strong>, <strong>data transfer<\/strong>, and (in scaled designs) <strong>Transit Gateway<\/strong> charges. Security outcomes depend on correct IPsec parameters, strict IAM control, secure PSK handling, and careful routing\/segmentation.<\/p>\n\n\n\n<p>Use AWS Site-to-Site VPN when you need quick hybrid connectivity, branch connectivity, or a backup path for Direct Connect. For strict performance requirements, evaluate Direct Connect and test designs under realistic traffic. Next, deepen your skills by learning Transit Gateway routing and building standardized, monitored hybrid patterns using IaC.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking and content delivery<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,36],"tags":[],"class_list":["post-300","post","type-post","status-publish","format-standard","hentry","category-aws","category-networking-and-content-delivery"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/300","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=300"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/300\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=300"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=300"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=300"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}