Ref: https://learn.cantrill.io/courses/1820301/lectures/41301496

• Summary:
• Contents:

Site-to-Site VPN - Key Concepts

• 🔧  Create and manage IPsec VPN in AWS, i.e. a logical connection between a VPC and an on-premises NW, encrypted in transit using IPsec
  • Generally connection runs over public internet
    • …but can also run on top of Direct Connect (DX)
  • Allows hybrid networking (AWS↔on-prem NW, or AWS↔different cloud)
• Important components
  • Virtual Private Gateway (VGW)
    • Logical GW object (can be a target in a route table)
    • Associated to a single VPC
    • ❗ Does not (currently) support IPv6
    • 💡 Similar to IGW → lives between VPC and AWS public zone, regionally resilient…
  • Customer Gateway (CGW) → Can refer to both:
    1. Physical on-prem router which VPN connects to
    2. Logical piece of configuration in AWS (which represents the physical router)
  • VPN connection
    • ❗ Always between one VGW and one CGW
    • Stores configuration
• Features
  • Can be fully HA (if you design & implement it correctly - check section notes)
  • Direct Connect (DX) integration
    • Can be used as backup/failover for DX
    • Can be used on top of DX → adds extra layer of encryption to DX
  • Billing:
    • Base hourly rate
    • Data transfer charge for data leaving AWS ($/GB)
    • Uses on-prem ISP connection → can impact data caps on the on-prem internet plan

VPNs Pros and Cons

• Benefits:
  • 👍 Fast to provision (less than an hour)
    • No HW setup needed, all SW configuration
    • Direct Connect (DX), in contrast, takes a long time to provision
  • 👍 More cost-effective than DX
  • 👍 IPsec widely supported across routers & network HW
• Limitations:
  • 👎 Speed Limitations → One VPN connection has maximum throughput = 1.25Gbps!!
    • ❗ This is AWS limit, but on-prem routers could have even lower throughput!
    • Overhead for encrypting/decrypting traffic is significant at high speeds
    • A VGW also has combined throughput cap = 1.25Gbps (across all VPN connections)
  • 👎 Latency considerations (VPNs usually over public internet)
    • Path inconsistency & variability… → not ideal for latency-sensitive apps

Site-to-Site VPN - Architecture

Simple implementation (partially HA)

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/1900-HYBRID_ENVIRONMENTS_AND_MIGRATION/00_LEARNINGAIDS/AWS-Site-2-SiteVPN-1.png

• Steps to establish VPN:
  1. Gather all required information
     • VPC CIDR, on-prem NW CIDR, and on-prem router's IP
  2. Create VGW & attach to VPC
     • VGW has TWO physical endpoints in different AZs, each with public IP → HA
  3. Create CGW logical object in AWS (has on-prem router's public IP)
  4. Create VPN connection
     • Link VGW and CGW
     • IPsec VPN tunnel created between each VGW endpoint and on-prem router
       • 2 encrypted VPN tunnels → if one fails, other still up (VPN still works)
         • 💡 If more than 2 tunnels are desired, can create more VPN connections, or more VGWs
• ‼️ The single on-prem router presents a single point of failure!!
  • If router fails, VPN also fails → architecture is partially HA, NOT fully HA!
    • HA on AWS side, but single point of failure on customer side

Fully HA implementation

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/1900-HYBRID_ENVIRONMENTS_AND_MIGRATION/00_LEARNINGAIDS/AWS-Site-2-SiteVPN-2.png

• Add a second on-prem router → if one fails, other still up → HA on customer side
  • 💡 Ideally, put second router in different building
  • Create a new VPN connection with second CGW → 2 different VPN connections
    • ❗ Does NOT use previous VGW endpoints, creates new VGW endpoints!
    • New set of VPN tunnels created between VGW and second router