Site-to-Site VPN and Direct Connect

Most companies don’t move everything to the cloud at once. Their data centre or office still needs to reach servers in AWS privately. An AWS Site-to-Site VPN does that over the internet with encrypted IPsec tunnels, in minutes; Direct Connect does it over private fibre when you need more bandwidth and steadier latency.

You’ll build a pretend office network (a second VPC with a Libreswan VPN device), connect it to saat-vpc, bring a tunnel up and ping a private server across it. Then you’ll fix the two problems that cause most “the VPN is down” tickets: a key mismatch and a missing return route.

TimeYou needBy the end you can
100 minutes (VPN connection, two small instances and an Elastic IP for about an hour and a half)saat-vpc with saat-rt-private and saat-app-sg, saat-ec2-ssm-profile, your laptop signed in as saat-admin. Site-to-Site VPN is not available on the AWS Free plan. Cost: about USD 0.25 (VPN USD 0.05 an hour, instances and the Elastic IP).Create a customer gateway, virtual private gateway and VPN connection, configure an IPsec device, check tunnel telemetry, route traffic with propagation, and troubleshoot authentication and routing failures.

What it is, in one line

An AWS Site-to-Site VPN is an encrypted IPsec connection between your own network device and AWS, giving private access to VPCs over the internet.

In Simple Words

A sealed courier bag between two offices

Two branch offices send documents to each other through the public post. To keep them private, each envelope goes into a sealed bag that only the other office can open, because both offices share the same secret code. That bag is the IPsec tunnel, and the code is the pre-shared key.

The post office gives you two routes for every bag, in case one road is blocked. Those are AWS’s two tunnels.

And the reply must know the way home. If the receiving office doesn’t know where the sender lives, the answer never comes back. That is the return route.

Engineer's View

How Site-to-Site VPN really works

Three AWS objects make a VPN: a customer gateway (the public IP and BGP ASN of your device), a virtual private gateway attached to the VPC (or a Transit Gateway for many VPCs), and the VPN connection, which always has two tunnels terminating in different Availability Zones. Each tunnel has its own outside IP, pre-shared key and inside /30 addresses.

Tunnels use IKEv1 or IKEv2 with AES and SHA-2 options; traffic is ESP, carried in UDP 4500 when NAT is involved, as it is here because the device sits behind an Elastic IP. Routing is static (you list the office CIDRs) or dynamic with BGP, which is preferred in production because failover between tunnels is automatic. VPC route tables learn VPN routes through route propagation or static routes pointing at the gateway.

Each standard tunnel carries up to about 1.25 Gbps. Direct Connect provides dedicated 1 to 100 Gbps private links through a partner location, often with a VPN as backup. Monitor tunnels with the TunnelState CloudWatch metric and VGW telemetry.

How it works, step by step

Here is the path of one ping from the office.

1The office device builds a tunnel

cgw01 runs Libreswan. It contacts the AWS tunnel endpoint on UDP 500 and 4500, both sides prove they know the pre-shared key, and an encrypted tunnel comes up.

AWS Site-to-Site VPN flow: office device, IPsec tunnel, virtual private gateway, private server

2Traffic for 10.20.0.0/16 enters the tunnel

The tunnel’s policy says “office 10.40.0.0/16 to AWS 10.20.0.0/16”. A ping from cgw01 to target01 is encrypted and sent to AWS.

3The VPC routes the reply back

target01 answers 10.40.1.x. saat-rt-private must know that 10.40.0.0/16 lives behind the virtual private gateway; propagation adds that route automatically.

4Choose the right connection

VPN isn’t the only option:

Site-to-Site VPN vs Direct Connect vs Transit Gateway: speed, setup time and cost

Many companies start with a VPN for weeks while a Direct Connect link is ordered, then keep the VPN as a backup path.

✅ Checkpoint: You can name the three VPN objects, why there are two tunnels, what the pre-shared key does, and why the return route matters.

Hands-on lab: an AWS Site-to-Site VPN from a simulated office

Sign in and load saat-vpc:

cd C:\aws-lab
aws login --profile saat-admin
$env:AWS_PROFILE = 'saat-admin'
$v = Get-Content C:\aws-lab\saat-vpc.json | ConvertFrom-Json
$base = aws ssm get-parameter --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 --query Parameter.Value --output text

1Build the “office” network and its VPN device

Paste this whole block. The office uses 10.40.0.0/16, which doesn’t overlap saat-vpc:

$office = aws ec2 create-vpc --cidr-block 10.40.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=saat-office},{Key=course,Value=saatvedha-aws},{Key=lesson,Value=37}]' --query Vpc.VpcId --output text
$osub = aws ec2 create-subnet --vpc-id $office --cidr-block 10.40.1.0/24 --availability-zone ap-south-1a --query Subnet.SubnetId --output text
$oigw = aws ec2 create-internet-gateway --query InternetGateway.InternetGatewayId --output text
aws ec2 attach-internet-gateway --internet-gateway-id $oigw --vpc-id $office
$ort = aws ec2 create-route-table --vpc-id $office --query RouteTable.RouteTableId --output text
aws ec2 create-route --route-table-id $ort --destination-cidr-block 0.0.0.0/0 --gateway-id $oigw | Out-Null
aws ec2 associate-route-table --route-table-id $ort --subnet-id $osub | Out-Null
$osg = aws ec2 create-security-group --group-name saat-office-cgw-sg --description "Office VPN device" --vpc-id $office --query GroupId --output text
[IO.File]::WriteAllText('C:\aws-lab\cgw-userdata.sh', "#!/bin/bash`ndnf install -y libreswan`nsystemctl enable ipsec`n")
$cgw = aws ec2 run-instances --image-id $base --instance-type t3.micro --subnet-id $osub --security-group-ids $osg --associate-public-ip-address --iam-instance-profile Name=saat-ec2-ssm-profile --metadata-options HttpTokens=required --user-data file://cgw-userdata.sh --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=cgw01},{Key=course,Value=saatvedha-aws},{Key=lesson,Value=37}]' --query "Instances[0].InstanceId" --output text
$eipAlloc, $eip = (aws ec2 allocate-address --domain vpc --tag-specifications 'ResourceType=elastic-ip,Tags=[{Key=course,Value=saatvedha-aws},{Key=lesson,Value=37}]' --query "[AllocationId,PublicIp]" --output text) -split '\s+'
aws ec2 wait instance-running --instance-ids $cgw
aws ec2 associate-address --instance-id $cgw --allocation-id $eipAlloc | Out-Null
aws ec2 modify-instance-attribute --instance-id $cgw --no-source-dest-check
$tgt = aws ec2 run-instances --image-id $base --instance-type t3.micro --subnet-id $v.PrivateA --security-group-ids $v.AppSg --metadata-options HttpTokens=required --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=target01},{Key=course,Value=saatvedha-aws},{Key=lesson,Value=37}]' --query "Instances[0].InstanceId" --output text
$tip = aws ec2 describe-instances --instance-ids $tgt --query "Reservations[0].Instances[0].PrivateIpAddress" --output text
aws ec2 authorize-security-group-ingress --group-id $v.AppSg --ip-permissions "IpProtocol=icmp,FromPort=-1,ToPort=-1,IpRanges=[{CidrIp=10.40.0.0/16,Description=lab37-office}]" | Out-Null
"office device $eip, target $tip"

You should see something like this:

office device 13.234.77.120, target 10.20.11.84

cgw01 plays the office router. It reaches Systems Manager over the internet through the office’s internet gateway, so you can configure it without SSH. target01 is an ordinary private server in saat-vpc with no internet access at all.

2Create the AWS side of the VPN

Paste this whole block (the VPN takes 5 to 10 minutes to become available):

$cgwId = aws ec2 create-customer-gateway --type ipsec.1 --public-ip $eip --bgp-asn 65000 --tag-specifications 'ResourceType=customer-gateway,Tags=[{Key=Name,Value=saat-office-cgw},{Key=course,Value=saatvedha-aws}]' --query CustomerGateway.CustomerGatewayId --output text
$vgw = aws ec2 create-vpn-gateway --type ipsec.1 --tag-specifications 'ResourceType=vpn-gateway,Tags=[{Key=Name,Value=saat-vgw},{Key=course,Value=saatvedha-aws}]' --query VpnGateway.VpnGatewayId --output text
aws ec2 attach-vpn-gateway --vpn-gateway-id $vgw --vpc-id $v.VpcId | Out-Null
do { Start-Sleep 10; $att = aws ec2 describe-vpn-gateways --vpn-gateway-ids $vgw --query "VpnGateways[0].VpcAttachments[0].State" --output text } until ($att -eq 'attached')
aws ec2 enable-vgw-route-propagation --route-table-id $v.RtPrivate --gateway-id $vgw
$vpn = aws ec2 create-vpn-connection --type ipsec.1 --customer-gateway-id $cgwId --vpn-gateway-id $vgw --options StaticRoutesOnly=true --tag-specifications 'ResourceType=vpn-connection,Tags=[{Key=Name,Value=saat-office-vpn},{Key=course,Value=saatvedha-aws}]' --query VpnConnection.VpnConnectionId --output text
aws ec2 wait vpn-connection-available --vpn-connection-ids $vpn
aws ec2 create-vpn-connection-route --vpn-connection-id $vpn --destination-cidr-block 10.40.0.0/16
$t1ip, $psk = (aws ec2 describe-vpn-connections --vpn-connection-ids $vpn --query "VpnConnections[0].Options.TunnelOptions[0].[OutsideIpAddress,PreSharedKey]" --output text) -split '\s+'
aws ec2 authorize-security-group-ingress --group-id $osg --protocol udp --port 500 --cidr "$t1ip/32" | Out-Null
aws ec2 authorize-security-group-ingress --group-id $osg --protocol udp --port 4500 --cidr "$t1ip/32" | Out-Null
aws ec2 describe-vpn-connections --vpn-connection-ids $vpn --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status]" --output text

You should see something like this (both tunnels down until the device is configured):

13.126.10.21    DOWN
65.0.33.48      DOWN

The pre-shared key is now in a PowerShell variable. Treat it like a password: in production it lives in Secrets Manager, and you’d never paste it into chat or a ticket.

3Configure the office device and bring up tunnel 1

Paste this whole block. It defines a helper that writes the Libreswan config to cgw01 and restarts it:

function Send-VpnConfig([string]$Key) {
  $conf = @"
conn aws-tunnel1
    authby=secret
    auto=start
    ikev2=insist
    left=%defaultroute
    leftid=$eip
    right=$t1ip
    type=tunnel
    ikelifetime=8h
    salifetime=1h
    ike=aes256-sha2_256;dh14
    esp=aes256-sha2_256;dh14
    leftsubnet=10.40.0.0/16
    rightsubnet=10.20.0.0/16
    dpddelay=10
    dpdtimeout=30
    dpdaction=restart
"@
  $secret = @"
$eip $t1ip : PSK "$Key"
"@
  $b64c = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes(($conf -replace "`r`n", "`n")))
  $b64s = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes(($secret -replace "`r`n", "`n")))
  @{ commands = @("echo $b64c | base64 -d > /etc/ipsec.d/aws.conf", "echo $b64s | base64 -d > /etc/ipsec.d/aws.secrets", "chmod 600 /etc/ipsec.d/aws.secrets", "systemctl restart ipsec", "sleep 20", "ipsec trafficstatus") } | ConvertTo-Json | Set-Content vpn-params.json
  $cmd = aws ssm send-command --document-name AWS-RunShellScript --instance-ids $cgw --parameters file://vpn-params.json --query Command.CommandId --output text
  Start-Sleep 40
  aws ssm get-command-invocation --command-id $cmd --instance-id $cgw --query StandardOutputContent --output text
}
Send-VpnConfig -Key $psk

You should see something like this:

006 #2: "aws-tunnel1", type=ESP, add_time=1760982345, inBytes=0, outBytes=0, maxBytes=2^63B, id='13.126.10.21'

The config says: authenticate with the shared secret using IKEv2, identify as the Elastic IP, and send traffic between 10.40.0.0/16 and 10.20.0.0/16 through the tunnel. The files travel base64-encoded so no quotes get mangled on the way.

AWS Site-to-Site VPN lab output: tunnel status and ping across the VPN
Tunnel status and a ping across the VPN. Something like this.

4Ping across the VPN

Paste this whole block:

Start-Sleep 60
aws ec2 describe-vpn-connections --vpn-connection-ids $vpn --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status]" --output text
@{ commands = @("ping -c 3 -W 2 $tip") } | ConvertTo-Json | Set-Content ping-params.json
$cmd = aws ssm send-command --document-name AWS-RunShellScript --instance-ids $cgw --parameters file://ping-params.json --query Command.CommandId --output text
Start-Sleep 15
aws ssm get-command-invocation --command-id $cmd --instance-id $cgw --query StandardOutputContent --output text

You should see something like this:

13.126.10.21    UP
65.0.33.48      DOWN
PING 10.20.11.84 (10.20.11.84) 56(84) bytes of data.
64 bytes from 10.20.11.84: icmp_seq=1 ttl=127 time=3.21 ms
64 bytes from 10.20.11.84: icmp_seq=2 ttl=127 time=2.98 ms
64 bytes from 10.20.11.84: icmp_seq=3 ttl=127 time=3.05 ms

3 packets transmitted, 3 received, 0% packet loss, time 2003ms

The “office” reached a private server that has no internet access at all, through the tunnel. Tunnel 2 is DOWN because the lab configures only one; in production a single DOWN tunnel is an alert, because you’ve lost your redundancy.

Site-to-Site VPN connection with tunnel 1 UP and tunnel 2 DOWN in the VPC console
The VPN connection in the VPC console: tunnel 1 UP, tunnel 2 DOWN because this lab configures only one.

✅ Checkpoint: Tunnel 1 shows UP, tunnel 2 DOWN, and cgw01 pings target01 with 0% loss. Keep everything for the break lab.

Break It, Then Fix It

The two causes behind most VPN tickets: the tunnel never comes up, or it’s up but nothing gets through.

1Break it: the wrong pre-shared key

Send the device a key with one character changed, then read its log:

Send-VpnConfig -Key ($psk.Substring(0, $psk.Length - 1) + 'x') | Out-Null
@{ commands = @("journalctl -u ipsec --since -3min --no-pager | grep -i authentication | tail -2") } | ConvertTo-Json | Set-Content log-params.json
$cmd = aws ssm send-command --document-name AWS-RunShellScript --instance-ids $cgw --parameters file://log-params.json --query Command.CommandId --output text
Start-Sleep 15
aws ssm get-command-invocation --command-id $cmd --instance-id $cgw --query StandardOutputContent --output text

You should see something like this:

Oct 20 22:14:31 ip-10-40-1-25 pluto[2214]: "aws-tunnel1" #3: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED

Both sides must hold exactly the same key for that tunnel. A copied key with a trailing space, or the key for tunnel 2 used on tunnel 1, gives this same result: the tunnel never comes up, and AWS telemetry just says DOWN. Fix: copy the exact key for that tunnel again:

Send-VpnConfig -Key $psk

You should see the tunnel established again:

006 #2: "aws-tunnel1", type=ESP, add_time=1760982901, inBytes=0, outBytes=0, maxBytes=2^63B, id='13.126.10.21'

2Break it: no route back to the office

Turn off route propagation on saat-rt-private, then ping again:

aws ec2 disable-vgw-route-propagation --route-table-id $v.RtPrivate --gateway-id $vgw
Start-Sleep 20
$cmd = aws ssm send-command --document-name AWS-RunShellScript --instance-ids $cgw --parameters file://ping-params.json --query Command.CommandId --output text
Start-Sleep 15
aws ssm get-command-invocation --command-id $cmd --instance-id $cgw --query StandardOutputContent --output text | Select-Object -Last 1

You should see this:

3 packets transmitted, 0 received, 100% packet loss, time 2047ms
VPN problems: pre-shared key mismatch and missing return route
Both problems and their fixes. Something like this.

The tunnel is still UP and the pings arrive at target01, but the replies have nowhere to go: saat-rt-private has no route for 10.40.0.0/16. Network teams point at AWS and AWS teams point at the network; the route table settles it. Fix: turn propagation back on (or add a static route to the gateway), and check effective routes:

aws ec2 enable-vgw-route-propagation --route-table-id $v.RtPrivate --gateway-id $vgw
Start-Sleep 20
aws ec2 describe-route-tables --route-table-ids $v.RtPrivate --query "RouteTables[0].Routes[?DestinationCidrBlock=='10.40.0.0/16'].[GatewayId,Origin,State]" --output text
$cmd = aws ssm send-command --document-name AWS-RunShellScript --instance-ids $cgw --parameters file://ping-params.json --query Command.CommandId --output text
Start-Sleep 15
aws ssm get-command-invocation --command-id $cmd --instance-id $cgw --query StandardOutputContent --output text | Select-Object -Last 1

You should see something like this:

vgw-0a1b2c3d4e5f60091    EnableVgwRoutePropagation       active
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Now clean up everything. The order matters: VPN first, then the gateway, then the office network:

aws ec2 delete-vpn-connection --vpn-connection-id $vpn
aws ec2 wait vpn-connection-deleted --vpn-connection-ids $vpn
aws ec2 disable-vgw-route-propagation --route-table-id $v.RtPrivate --gateway-id $vgw
aws ec2 detach-vpn-gateway --vpn-gateway-id $vgw --vpc-id $v.VpcId
do { Start-Sleep 10; $att = aws ec2 describe-vpn-gateways --vpn-gateway-ids $vgw --query "VpnGateways[0].VpcAttachments[0].State" --output text } until ($att -eq 'detached')
aws ec2 delete-vpn-gateway --vpn-gateway-id $vgw
aws ec2 delete-customer-gateway --customer-gateway-id $cgwId
aws ec2 terminate-instances --instance-ids $cgw $tgt | Out-Null
aws ec2 wait instance-terminated --instance-ids $cgw $tgt
aws ec2 release-address --allocation-id $eipAlloc
aws ec2 revoke-security-group-ingress --group-id $v.AppSg --ip-permissions "IpProtocol=icmp,FromPort=-1,ToPort=-1,IpRanges=[{CidrIp=10.40.0.0/16}]" | Out-Null
aws ec2 delete-security-group --group-id $osg
aws ec2 detach-internet-gateway --internet-gateway-id $oigw --vpc-id $office
aws ec2 delete-internet-gateway --internet-gateway-id $oigw
aws ec2 delete-subnet --subnet-id $osub
aws ec2 delete-route-table --route-table-id $ort
aws ec2 delete-vpc --vpc-id $office
Remove-Item cgw-userdata.sh, vpn-params.json, ping-params.json, log-params.json
.\Find-Waste.ps1
.\Find-LabResources.ps1

✅ Checkpoint: You fixed a tunnel stuck on AUTHENTICATION_FAILED and a tunnel that was UP with no return route. The VPN, gateways, office VPC, instances and Elastic IP are all gone.

This happened at work

The VPN that was “up” during an outage

A logistics company connected its warehouse system to AWS with a Site-to-Site VPN. The firewall team configured only tunnel 1. For a year it worked, and the AWS console showed one tunnel UP and one DOWN, which nobody questioned.

During routine AWS maintenance on tunnel 1’s endpoint, AWS moved traffic to tunnel 2, as the documentation says it may. Tunnel 2 had never been configured. Warehouse scanners couldn’t reach the order system for 50 minutes, and the network team insisted the VPN was “up” because their firewall still showed the old session.

They configured both tunnels with BGP so failover is automatic, added CloudWatch alarms on TunnelState for each tunnel, and subscribed to AWS Health notifications for VPN maintenance. Later they added Direct Connect, keeping the VPN as backup.

Common mistakes and troubleshooting

MistakeWhat happensWhat to do
Configuring only one tunnelOutage during AWS maintenance or a zone issueConfigure both tunnels, ideally with BGP
Pre-shared key copied wrongly or for the wrong tunnelAUTHENTICATION_FAILED; tunnel DOWNCopy each tunnel’s exact key; store in Secrets Manager
No route back in the VPCTunnel UP, traffic one way onlyRoute propagation or static routes on every relevant route table
Overlapping CIDRs between office and VPCRouting can’t workPlan non-overlapping IP ranges (Lesson 8)
Firewall blocking UDP 500/4500 or ESPTunnel never establishesAllow them from the AWS tunnel outside IPs
No monitoring of tunnel stateFailures found by usersAlarm on TunnelState per tunnel

Interview questions

Click a question to open it. Each one is written the way an interviewer would ask it. Under it you will see why they ask it and one way you could answer, in your own words.

Fresher level

1. Can you explain in simple words what an AWS Site-to-Site VPN is?

Why they ask this: They want to know you understand how an office or data centre connects to AWS. Hybrid networking is common in almost every company.

How you might answer: A Site-to-Site VPN is an encrypted IPsec connection between a device in your office or data centre, called the customer gateway, and a virtual private gateway or Transit Gateway in AWS. Each connection has two tunnels for redundancy.

I explain it as a private, locked tunnel over the internet between your building and your VPC.

2. Why does AWS give you two tunnels for every VPN connection?

Why they ask this: They are checking that you understand resilience. Many people configure only one tunnel and get an outage during AWS maintenance.

How you might answer: The two tunnels end on different AWS endpoints in different zones. So if one is under maintenance or fails, the other can still carry traffic.

That’s why I always configure both tunnels on the customer device, not just one.

3. Your company is deciding between a VPN and Direct Connect. When would you recommend Direct Connect?

Why they ask this: They want to see that you can match the connection type to the need. Choosing wrong either wastes money or gives poor performance.

How you might answer: I’d recommend Direct Connect when we need high, steady bandwidth, consistent latency, or when we move a lot of data and transfer costs add up. A VPN is quick and cheap to set up, so it’s great to start with, and it’s often kept as a backup to Direct Connect.

2–5 years experience

4. The VPN tunnel shows UP, but your servers in AWS still can’t reach anything on-premises. What would you check?

Why they ask this: They want to see a logical troubleshooting order across both sides of the connection. An UP tunnel doesn’t mean traffic can flow.

How you might answer: First I’d check the VPC route tables, either route propagation or static routes pointing to the gateway, and the security groups and NACLs. Then I’d check the on-premises side: routes and firewall rules back to the VPC CIDR.

I’d also look for overlapping CIDRs, and check that the tunnel’s traffic selectors include the right ranges.

5. When setting up a VPN, would you choose static routing or BGP, and why?

Why they ask this: They want to see that you understand routing choices and their trade-offs. This affects how fast traffic fails over when a tunnel goes down.

How you might answer: I’d prefer BGP, because routes are learned automatically and failover between the two tunnels is faster and happens on its own. Static routing is simpler, so I’d use it for a small setup or when the device doesn’t support BGP.

6. How would you make sure you find out about a VPN problem before users call you?

Why they ask this: They are checking your monitoring habits. A half-down VPN can go unnoticed until the second tunnel fails too.

How you might answer: I’d watch the CloudWatch metrics TunnelState, TunnelDataIn and TunnelDataOut for each tunnel, with an alarm when any single tunnel goes down. I’d also follow AWS Health events for planned maintenance, and check the logs on our own device.

Senior level

7. A bank with two data centres and 30 VPCs asks you to design their hybrid connectivity. How would you approach it?

Why they ask this: They want to see architecture thinking around resilience, routing and security. Banks expect no single point of failure.

How you might answer: I’d use Transit Gateway as the hub, with redundant Direct Connect connections from both data centres through different locations, and Site-to-Site VPN over the internet as backup. Routing would use BGP with route policies.

I’d add centralized inspection, plan non-overlapping IP ranges with IPAM, and monitor every link.

8. Users say the VPN drops roughly every hour. How would you investigate that?

Why they ask this: They want to see deep troubleshooting skills. A regular pattern like this usually points to a specific setting, and they want to know if you can find it.

How you might answer: A drop every hour makes me think of rekeying, so I’d compare the phase 1 and phase 2 lifetimes on both sides, plus the DPD settings. I’d also check NAT timeouts on the firewall and read the logs around the time of each drop.

I’d see whether our device starts the rekey, and then align the lifetimes with the AWS defaults or the tunnel options.

Quick quiz

Q1. How many tunnels does every AWS VPN connection have?

  1. One
  2. Two
  3. Four
  4. It depends on bandwidth
Show answer

B — Two tunnels for redundancy.

Q2. What did AUTHENTICATION_FAILED mean in the device log?

  1. Wrong route
  2. Pre-shared key mismatch
  3. Wrong Region
  4. No internet
Show answer

B — Both sides must share the exact key.

Q3. Why did the ping fail while the tunnel was UP?

  1. The key was wrong
  2. The VPC route table had no route back to the office
  3. UDP 500 was blocked
  4. The VPN was deleted
Show answer

B — Route propagation was turned off.

Q4. Which routing type gives automatic failover between tunnels?

  1. Static
  2. BGP
  3. Neither
  4. Both equally
Show answer

B — BGP learns and withdraws routes automatically.

Q5. What is the main reason to choose Direct Connect?

  1. It is quicker to set up
  2. Dedicated bandwidth and steadier latency
  3. It needs no hardware
  4. It is encrypted by default
Show answer

B — Direct Connect uses private links; add MACsec or VPN for encryption.

Quick recap

  • A VPN needs a customer gateway, a virtual private gateway (or Transit Gateway) and a VPN connection.
  • Every connection has two tunnels; configure both in production.
  • Each tunnel has its own pre-shared key; a mismatch keeps it DOWN.
  • VPC route tables need routes back to on-premises, by propagation or static routes.
  • Direct Connect gives dedicated bandwidth; VPN is the quick start and the usual backup.

Next lesson

Lesson 38: Lambda for operations automation → You’ll write a Lambda function that stops untagged test servers every night, schedule it with EventBridge and debug it with logs.

Further reading: AWS Site-to-Site VPN

Want to go deeper into AWS Site-to-Site VPN? Read What is AWS Site-to-Site VPN? and Troubleshooting your customer gateway device. You can also see the full plan for this course on the AWS Cloud Administration course page.

Scroll to Top