Before we can talk about AWS Site-to-Site VPN, we need to understand what a VPN actually is and why connecting a private network to the cloud is a genuinely different problem than connecting a single laptop.

What Is a VPN?

A Virtual Private Network (VPN) creates an encrypted, private communication path across a public network like the internet. Encryption scrambles the data so that even if someone intercepts it along the way, they can’t read its actual contents without the correct key. Most people are familiar with a “client VPN,” which connects one device, like a laptop, to a private network. A “Site-to-Site VPN” is different — it connects two entire networks to each other, such as an office full of computers to an AWS Virtual Private Cloud (VPC), so that every device on both sides can reach the other side as if they were on the same local network.

What Is AWS Site-to-Site VPN?

AWS Site-to-Site VPN is a fully managed AWS service that creates a secure, encrypted connection between your on-premises network (such as an office or data center) and your Amazon VPC. “Fully managed” means AWS operates and maintains the AWS side of the connection, including automatic failover between redundant tunnels, so your team focuses on configuring your side of the network rather than building and babysitting VPN server software. A hospital network migrating patient record systems to AWS, for example, can use Site-to-Site VPN to let its on-premises clinical applications securely reach new cloud-hosted databases without ever exposing sensitive health data to the open internet in plaintext.

The Two Sides of Every Connection

Every AWS Site-to-Site VPN connection has two endpoints that must agree to talk to each other:

An AWS Site-to-Site VPN connection is built from a small, well-defined set of pieces that work together to form two redundant encrypted tunnels.

The Building Blocks

• Customer Gateway — a resource representing your on-premises VPN device, storing its public IP address and configuration details.
• Virtual Private Gateway — the AWS-side VPN endpoint attached directly to a specific VPC.
• Transit Gateway — an alternative AWS-side endpoint that can connect many VPCs and VPN connections through a single hub, useful for larger, more complex networks.
• VPN Connection — the logical resource tying a Customer Gateway to a Virtual Private Gateway or Transit Gateway, made up of two separate tunnels.
• Two Tunnels — every VPN connection is automatically built with two independent, redundant tunnels for high availability.
• Route Tables — control which traffic is sent over the VPN connection versus other paths, on both the AWS and on-premises sides.

flowchart LR
    subgraph OnPrem["Your On-Premises Network"]
        Office["Office Computers & Servers"]
        CGW["Customer Gateway Device"]
    end
    subgraph AWS["AWS Cloud"]
        VGW["Virtual Private Gateway"]
        subgraph VPC["Your VPC"]
            EC2["EC2 Instances"]
            RDS["RDS Database"]
        end
    end
    Office --> CGW
    CGW -->|"Tunnel 1 (encrypted)"| VGW
    CGW -->|"Tunnel 2 (encrypted, standby)"| VGW
    VGW --> EC2
    VGW --> RDS
        

Where Site-to-Site VPN Fits Inside AWS

AWS Site-to-Site VPN sits alongside AWS Direct Connect as one of the two primary ways to connect an external network to AWS. Direct Connect uses a dedicated, private physical network link, while Site-to-Site VPN uses encryption over the existing public internet. A common pattern for companies with strict uptime requirements is to run both simultaneously — Direct Connect as the primary path for speed and consistency, with Site-to-Site VPN as an automatic backup if the dedicated line ever experiences an outage.

What actually happens between the moment a packet leaves your office computer and the moment it safely arrives inside your VPC?

Step by Step: Establishing and Using a Tunnel

Why Two Tunnels Instead of One?

Every AWS Site-to-Site VPN connection is automatically built with two separate tunnels, each terminating on a different AWS endpoint. This isn’t optional redundancy you have to configure — it’s the default design, specifically so that if AWS needs to perform maintenance on one tunnel’s endpoint, or if that endpoint experiences an issue, traffic can continue flowing uninterrupted through the second tunnel.

A VPN connection isn’t a one-time setup and forget — it has an ongoing lifecycle of routing decisions and health monitoring.

Static vs. Dynamic Routing

AWS Site-to-Site VPN supports two ways of deciding which traffic goes over the tunnel. With static routing, you manually specify the exact address ranges that should be sent through the VPN, which works well for simple, stable networks. With dynamic routing, using the BGP (Border Gateway Protocol), both sides automatically exchange information about which networks are reachable, and routes adjust automatically if something changes — similar to two neighboring countries continuously updating each other’s border maps rather than relying on a printed map from years ago.

sequenceDiagram
    participant CGW as Customer Gateway
    participant VGW as Virtual Private Gateway
    participant VPC as VPC Resources

    CGW->>VGW: Initiate IKE negotiation
    VGW-->>CGW: Agree on encryption parameters
    CGW->>VGW: Establish IPsec Tunnel 1
    CGW->>VGW: Establish IPsec Tunnel 2 (standby)
    CGW->>VGW: Exchange routes via BGP (if dynamic)
    CGW->>VGW: Send encrypted data packet
    VGW->>VPC: Decrypt and deliver packet
        

Monitoring Tunnel State

Each tunnel continuously exchanges small “keepalive” messages to confirm the connection is still alive. If a tunnel stops responding, AWS marks it down and, where dynamic routing with BGP is used, automatically shifts traffic to the remaining healthy tunnel, often before a human would even notice a problem occurred.

Idle Tunnels and Reconnection

A tunnel that sits completely idle for an extended period can sometimes drop, similar to a phone call that disconnects after a long stretch of silence, because some network equipment along the path assumes an inactive connection is no longer needed. AWS Site-to-Site VPN supports configuring keepalive and DPD (Dead Peer Detection) settings specifically to prevent this, sending small heartbeat packets even during quiet periods so the tunnel stays established and ready the instant real traffic needs to flow through it.

Site-to-Site VPN solves real connectivity problems quickly, but it isn’t the right fit for every situation — knowing the trade-offs is exactly what interviewers look for.

The Core Trade-off: Speed of Setup vs. Guaranteed Performance

A dedicated Direct Connect link offers predictable, consistent bandwidth because it doesn’t share the public internet with anyone else, but it can take weeks or months to physically provision. Site-to-Site VPN trades that predictability for speed — you can be securely connected to AWS in a single afternoon, accepting that your performance will vary along with general internet conditions.

Because a Site-to-Site VPN tunnel is a specific technical construct, understanding its throughput characteristics helps you plan realistic expectations.

Throughput Per Tunnel

Each individual IPsec tunnel has a throughput ceiling, since encryption and decryption take processing time and a single tunnel is inherently a single network path. Think of a tunnel like one lane of highway traffic — a single lane can only move so many cars per minute no matter how wide the road looks on a map. To increase total throughput beyond a single tunnel’s limit, AWS supports Equal Cost Multi-Path (ECMP) routing, which allows traffic to be spread across both tunnels simultaneously, effectively adding a second lane running in parallel.

Scaling with AWS VPN Accelerator

For organizations connecting from locations geographically far from their target AWS Region, AWS offers accelerated Site-to-Site VPN connections that route traffic through the AWS global network as early as possible, similar to a package carrier that gets your shipment onto its own optimized delivery network at the nearest possible drop-off point rather than relying on unpredictable public roads for the entire journey.

A network connection that only works some of the time isn’t very useful — so redundancy is built into Site-to-Site VPN from the very beginning.

Built-In Tunnel Redundancy

Because every VPN connection automatically includes two tunnels terminating on different AWS endpoints, a single endpoint failure or scheduled maintenance event doesn’t take down your connectivity — traffic simply continues through the surviving tunnel. For even greater resilience, organizations can configure two separate Customer Gateway devices on their own side, so that even a failure of their own on-premises hardware doesn’t sever the connection entirely.

Durability vs. Availability

Similar to a load balancer, a VPN connection carries no persistent data of its own to keep durable — the focus is entirely on availability, meaning the encrypted path stays reachable and functional. AWS achieves this through automatic tunnel failover, and your own network design achieves it further through redundant on-premises hardware and, ideally, diverse internet service providers feeding your Customer Gateway devices.

Security is the entire reason Site-to-Site VPN exists, so it’s worth understanding exactly what protections it provides and what it doesn’t.

• IPsec encryption — scrambles every packet traveling through the tunnel so it’s unreadable to anyone intercepting it along the way.
• Authentication via pre-shared keys or certificates — ensures both ends of the tunnel are actually who they claim to be before any data flows.
• Security groups and network ACLs — still apply inside your VPC even after traffic arrives through the VPN, providing an additional layer of control.
• Route table isolation — ensures only intentionally shared address ranges are reachable across the VPN, rather than exposing your entire network by accident.

A VPN tunnel that silently drops without anyone noticing can turn into a very confusing outage — so visibility into its state matters.

AWS Site-to-Site VPN integrates with Amazon CloudWatch, reporting metrics such as tunnel state (up or down), data in and out, and packet drop counts. Think of the tunnel state metric like a simple light switch indicator on a physical fuse box — a quick glance tells you immediately whether power (connectivity) is flowing, without needing to trace every wire individually. Teams commonly set a CloudWatch alarm specifically on tunnel state, so that if a tunnel goes down, someone is notified immediately even if the redundant second tunnel is quietly keeping traffic flowing in the background.

Site-to-Site VPN becomes far more powerful once it’s woven into a broader network architecture rather than treated as a single isolated link.

A common deployment pattern for organizations with many VPCs or many office locations uses AWS Transit Gateway as a central hub, attaching multiple VPN connections and multiple VPCs to it, so that any connected network can reach any other connected network through a single, manageable point rather than a tangled mesh of individual point-to-point connections. Teams often pair Site-to-Site VPN with AWS Direct Connect as well, using the VPN specifically as an automatic failover path that only becomes active if the primary dedicated connection experiences an outage.

Cost Considerations During Deployment

AWS Site-to-Site VPN bills based on the hours each VPN connection is active plus data transfer charges, similar to a subscription phone line that charges a base monthly fee plus usage-based charges for calls made. A common beginner mistake is creating a separate VPN connection per VPC without first considering whether a Transit Gateway hub-and-spoke design would consolidate connections and reduce both cost and management overhead.

Planning for Growth

A design that works perfectly for one office and one VPC can become unwieldy the moment a company opens a second location or spins up a third and fourth VPC. Before deploying, it’s worth sketching out not just today’s connectivity needs but a rough picture of where the network is headed over the next year or two — a company that already knows it will expand into new regions is usually better served starting with a Transit Gateway hub from day one, rather than retrofitting one later once dozens of point-to-point connections already exist and need to be untangled.

Choosing how to structure your VPN connectivity is itself a design decision, and a shortsighted choice early on can create real headaches later.

Good Patterns to Follow

• Use dynamic routing with BGP wherever your on-premises equipment supports it — it adapts automatically as your network changes.
• Treat Site-to-Site VPN as a natural backup for AWS Direct Connect rather than choosing only one or the other.
• Consolidate many connections through a Transit Gateway instead of building a point-to-point mesh.

Most Site-to-Site VPN problems in the real world trace back to a handful of avoidable configuration mistakes.

Seeing how real organizations actually use Site-to-Site VPN makes the abstract concepts click into place.

Across every one of these industries, the common thread is the same: the organization needed a secure bridge between infrastructure it already owns and the AWS resources it’s adopting, without waiting weeks for a physical connection or exposing sensitive traffic to the open internet along the way.

Site-to-Site VPN connects two entire networks together, such as an office and a VPC, so every device on both sides can communicate. Client VPN instead connects individual remote devices, like a single employee’s laptop, directly to AWS resources, without requiring an entire on-premises network on the other end.

You need a VPN-capable device on your side, often a firewall or router that supports IPsec, which can be either a physical appliance or a software-based virtual appliance. AWS provides sample configuration files for many common vendors to simplify the setup on your end.

Traffic automatically continues flowing through the remaining healthy tunnel, especially when dynamic routing with BGP is used, so a single tunnel outage typically doesn’t cause a visible disruption to applications relying on the connection.

It can for many use cases, particularly ones with moderate bandwidth needs and some tolerance for variable internet performance, but organizations with strict, consistent bandwidth and latency requirements typically still prefer Direct Connect, sometimes using VPN alongside it as a backup.

Yes, a VPN connection can attach directly to a Transit Gateway instead of a single VPC’s Virtual Private Gateway, which is the recommended approach for organizations connecting multiple VPCs or multiple on-premises locations to AWS at once.