CloudNetworking.io
AWS Networking • Site-to-Site VPN Fundamentals

AWS Site-to-Site VPN explained in simple terms

AWS Site-to-Site VPN is a managed service that creates an encrypted connection between your on-premises network and AWS. It is one of the most common ways to extend a private corporate network into the cloud without exposing internal traffic directly to the public internet.

This guide explains Site-to-Site VPN in practical language, including components, two-tunnel redundancy, routing options, monitoring, logs, and where it fits in real hybrid cloud architecture.

Learn how AWS Site-to-Site VPN works with tunnels, routing, and hybrid connectivity.

What An encrypted connection between AWS and your on-premises or remote network.
Why It securely extends private connectivity into AWS.
When Use it when AWS must communicate with offices, branches, or data centers.
Where It connects a customer gateway device to a virtual private gateway or transit gateway.
Who Cloud, DevOps, network, and enterprise platform teams use it.
How By building two encrypted VPN tunnels and routing traffic through them.

What is AWS Site-to-Site VPN?

AWS Site-to-Site VPN is a service that lets your VPC or Transit Gateway communicate securely with your remote network through encrypted IPsec tunnels. On the AWS side, the connection terminates on either a virtual private gateway or a transit gateway. On your side, it terminates on a customer gateway device that you own or manage. :contentReference[oaicite:1]{index=1}

A Site-to-Site VPN connection is made up of several parts: the AWS-side gateway, the customer gateway resource in AWS, the customer gateway device on your network, and the VPN connection itself. AWS documents that each VPN connection provides two VPN tunnels for redundancy. :contentReference[oaicite:2]{index=2}

Real-life example

Think of your corporate office and your AWS network as two secure buildings. Site-to-Site VPN is like building two guarded underground tunnels between them so staff and data can move privately and safely between both locations.

Why is Site-to-Site VPN important?

Site-to-Site VPN matters because many organizations need AWS to work as an extension of their existing network instead of as a completely isolated environment. It is often used when applications in AWS need to talk to on-premises systems, internal tools, office networks, or legacy enterprise infrastructure. :contentReference[oaicite:3]{index=3}

  • Creates encrypted private connectivity between AWS and on-premises networks
  • Helps support hybrid cloud environments
  • Can be used with a VPC or a Transit Gateway target
  • Provides two tunnels for higher availability
  • Works well as a starting point before moving to Direct Connect
Site-to-Site VPN is often the fastest way to establish secure hybrid connectivity when an organization needs AWS to integrate with existing private infrastructure.

When do you use Site-to-Site VPN?

You use Site-to-Site VPN when your AWS environment needs to communicate with a remote private network. That remote network might be a head office, a branch office, a co-location environment, or a traditional on-premises data center. AWS also supports using a Transit Gateway target so the VPN can connect into a larger hub-and-spoke architecture. :contentReference[oaicite:4]{index=4}

Common use cases include:

  • Connecting AWS to a corporate data center
  • Allowing AWS-hosted applications to reach internal business systems
  • Supporting disaster recovery or backup architectures
  • Extending branch office connectivity into AWS
  • Using Transit Gateway for centralized hybrid routing

Where does Site-to-Site VPN fit in AWS architecture?

Site-to-Site VPN sits between AWS and your external private network. It is not a replacement for an Internet Gateway, NAT Gateway, or VPC Peering. Instead, it is the encrypted bridge between AWS and remote infrastructure outside AWS. AWS documents that the AWS-side endpoint can be a virtual private gateway or a transit gateway. :contentReference[oaicite:5]{index=5}

  1. You define a customer gateway in AWS
  2. You choose a target gateway type such as virtual private gateway or transit gateway
  3. You create the VPN connection
  4. AWS provides two tunnels with configuration details
  5. You configure your customer gateway device
  6. You update routing so traffic flows through the VPN

Core components of a Site-to-Site VPN connection

Customer gateway device

This is the physical or software VPN appliance on your side of the connection. It must be configured to match the AWS VPN settings. AWS specifically notes that this is the device you or your network team own and manage. :contentReference[oaicite:6]{index=6}

Customer gateway

In AWS, the customer gateway resource represents your external device and contains information such as the public IP address or certificate details used for the VPN connection. :contentReference[oaicite:7]{index=7}

Virtual private gateway or Transit Gateway

On the AWS side, the VPN can terminate on a virtual private gateway attached to a VPC or on a transit gateway for larger centralized designs. AWS supports both models. :contentReference[oaicite:8]{index=8}

VPN connection

The VPN connection ties everything together and gives you the tunnel endpoints, tunnel options, and routing behavior needed to pass traffic securely. :contentReference[oaicite:9]{index=9}

How does Site-to-Site VPN work?

Site-to-Site VPN works by creating encrypted IPsec tunnels between AWS and your customer gateway device. By default, your customer gateway device initiates the tunnel by generating traffic and starting IKE negotiation, although AWS documents that tunnel initiation behavior can be configured so AWS initiates or restarts IKE instead. :contentReference[oaicite:10]{index=10}

Once the tunnels are established, traffic is routed through them based on your VPN routing configuration. AWS supports both static routing and dynamic routing using BGP depending on your design and device capabilities. :contentReference[oaicite:11]{index=11}

A VPN tunnel being present is not enough on its own. Routing on both the AWS side and the customer gateway side must also be configured correctly, or traffic will fail.

Why are there two VPN tunnels?

AWS states that each Site-to-Site VPN connection includes two tunnels, each with its own public IP address. This is a built-in resiliency feature. If one tunnel becomes unavailable, traffic can fail over to the other available tunnel for that VPN connection. :contentReference[oaicite:12]{index=12}

This is one of the most important design details for Site-to-Site VPN because it means your customer gateway should be configured to support both tunnels, not just one.

Simple memory trick

Do not think of Site-to-Site VPN as one pipe. Think of it as two secure pipes, where the second one is there to keep traffic moving when the first has a problem.

Static routing vs dynamic routing

Site-to-Site VPN can use either static routing or Border Gateway Protocol (BGP). Static routing means you manually define which remote CIDR blocks should use the VPN. Dynamic routing means BGP exchanges routes automatically between AWS and your customer gateway device. AWS supports both approaches depending on the tunnel and device setup. :contentReference[oaicite:13]{index=13}

  • Static routing: simpler, manual route management
  • BGP: more dynamic and scalable for larger environments

In enterprise environments, BGP is often preferred because route updates and failover behavior are easier to manage across changing network topologies.

Virtual private gateway vs Transit Gateway target

A Site-to-Site VPN can terminate on a virtual private gateway for a single VPC-oriented design or on a transit gateway for a more centralized multi-VPC architecture. AWS documents both options during VPN creation. :contentReference[oaicite:14]{index=14}

  • Virtual private gateway: better for simpler VPC-specific connectivity
  • Transit Gateway: better for larger hub-and-spoke hybrid networking

If your environment is expected to grow, Transit Gateway usually offers a cleaner model for scaling private connectivity across multiple AWS networks.

Real-world architecture example

Imagine a company running internal finance systems in its own data center while moving customer-facing services into AWS. The application in AWS still needs to reach internal APIs, database services, or authentication systems hosted on-premises. In that case, Site-to-Site VPN can securely connect the two environments and allow private communication without making internal systems public.

In a more advanced environment, multiple VPCs may already be attached to a Transit Gateway, and the Site-to-Site VPN connects the on-premises data center into that central routing hub.

Monitoring, metrics, and logs

AWS provides CloudWatch monitoring for Site-to-Site VPN tunnels and documents that tunnel metrics are automatically sent to CloudWatch. AWS also documents tunnel activity logging and Site-to-Site VPN logs that can be sent to CloudWatch Logs for retrospective analysis of connection status and activity. :contentReference[oaicite:15]{index=15}

CloudWatch metrics

CloudWatch receives Site-to-Site VPN tunnel metrics automatically as they become available. AWS also documents creating alarms from the CloudWatch console using the VPN Tunnel Metrics namespace, such as alarms on tunnel state. :contentReference[oaicite:16]{index=16}

CloudTrail

CloudTrail can be used to track API activity related to Site-to-Site VPN resources, such as creating or modifying VPN connections, changing tunnel options, or updating related AWS-side resources. AWS includes CloudTrail in its overall monitoring guidance for Site-to-Site VPN. :contentReference[oaicite:17]{index=17}

Site-to-Site VPN logs

AWS documents that Site-to-Site VPN logs can be sent to Amazon CloudWatch Logs for retrospective analysis of VPN connection status and activity over time. Tunnel activity logging can be enabled for new or existing connections. AWS also provides tunnel and BGP logging visibility in the console. :contentReference[oaicite:18]{index=18}

Where are the logs stored?

For Site-to-Site VPN logging, AWS documentation specifically points to Amazon CloudWatch Logs as the log destination for VPN logs. AWS also notes CloudWatch Logs resource policy considerations and recommends using log group names with the /aws/vendedlogs/ prefix to help avoid policy size issues when enabling logs at scale. :contentReference[oaicite:19]{index=19}

  • CloudWatch Logs: primary documented destination for Site-to-Site VPN logs
  • CloudWatch Metrics: for tunnel health and monitoring visibility
  • CloudTrail: for API and configuration change tracking
When troubleshooting, check both tunnel state metrics and CloudWatch Logs activity. A tunnel may exist but still fail to carry traffic because of routing, BGP, or customer gateway configuration issues.

Common mistakes

  • Configuring only one of the two AWS tunnels on the customer gateway device
  • Forgetting AWS-side or on-premises routing updates
  • Using the wrong target model for growth, such as choosing VGW when Transit Gateway would scale better
  • Ignoring BGP or static route mismatches
  • Not enabling logs and alarms until after an outage happens

Best practices

  • Configure and test both VPN tunnels
  • Use CloudWatch alarms for tunnel state monitoring
  • Enable Site-to-Site VPN logs in CloudWatch Logs for easier troubleshooting
  • Document routing clearly on both sides of the connection
  • Use Transit Gateway when hybrid connectivity must scale across multiple VPCs
  • Validate customer gateway device compatibility and settings carefully

Summary

AWS Site-to-Site VPN is the secure encrypted bridge between AWS and your remote private network. It uses two tunnels for resiliency, supports both virtual private gateway and transit gateway designs, and can use static or dynamic routing depending on your architecture. Once you understand its components, routing model, redundancy, monitoring, and log locations, it becomes much easier to design reliable hybrid connectivity between AWS and on-premises environments.

Learn more from AWS official documentation

For deeper technical details, refer to AWS Site-to-Site VPN overview , how Site-to-Site VPN works , CloudWatch monitoring for Site-to-Site VPN , and Site-to-Site VPN logs .