Vendor compatibility
AWS VPN post-quantum VPN support
AWS Site-to-Site VPN, including Virtual Private Gateway and Transit Gateway attachments, and the tunnel options exposed through the VPN connection API.
Last reviewed
1 compatibility record
Direct answer
AWS Site-to-Site VPN is a managed service, so the customer does not choose a software release — the capability is whatever the service exposes through its tunnel options at the time of configuration. Establish which key exchange methods the current tunnel options accept, and remember that the customer-managed peer at the other end of every AWS tunnel is a separate compatibility question with its own constraints.
Practical status
What this means in a real estate
A managed VPN service removes the upgrade problem and replaces it with a configuration-surface problem: whatever the service offers is what is available, on the service's timeline rather than the customer's. In practice this makes the AWS side of a hybrid estate the easier half to change and the harder half to influence. The binding constraint is almost always the customer-managed device terminating the other end of the tunnel.
What to establish about key exchange
Establish which IKEv2 key exchange methods the current Site-to-Site VPN tunnel options accept, and whether they can be set through the API, CloudFormation and Terraform as well as the console. Configuration that is console-only does not survive an infrastructure-as-code estate's review process.
Why authentication is a separate question
AWS Site-to-Site VPN tunnels authenticate with a preshared key or a certificate from AWS Private CA depending on configuration. Changing the key exchange method does not change that authentication, and post-quantum authentication would require separate certificate and signature algorithm support.
Products and versions
Compatibility records
Each record is scoped to a product and a version range. Key establishment and authentication are stated separately, because they migrate on different timelines through different mechanisms.
| Product | Key establishment |
|---|---|
| AWS Site-to-Site VPN (Virtual Private Gateway and Transit Gateway attachments) | Post-quantum key establishment: Unknown |
AWS Site-to-Site VPN (Virtual Private Gateway and Transit Gateway attachments)
Managed service, current tunnel optionsCapability is whatever the service's tunnel options currently accept. There is no customer-controlled software version, so the assessment question is about the configuration surface rather than about a release.
Migration implication: In hybrid estates the AWS side is rarely the blocker. Sequence the customer gateway migration first and treat the AWS tunnel option change as the confirming step.
Caveats
- Service capability cannot be advanced by the customer
- Modifying tunnel options triggers renegotiation, which is a production event
- Infrastructure-as-code definitions must be updated in step or the next apply reverts the change
Last reviewed · low confidence · 1 source
Prerequisites
Establish these before assessing migratability.
- Current tunnel options for every VPN connection, exported rather than assumed
- Whether connections are managed by Terraform, CloudFormation or manually
- The customer gateway device model and release at the other end of each tunnel
- Whether the attachment is to a Virtual Private Gateway or a Transit Gateway
Peer compatibility
A tunnel is governed by the weaker of its two peers.
- Every AWS tunnel has a customer gateway peer whose capability governs the result
- Tunnel options must be modified in coordination with the peer, not before it
- Both tunnels of a redundant pair need the same treatment to avoid asymmetric behaviour
Operational limitations
Constraints that shape the plan rather than block it.
- Capability is set by the service and cannot be advanced by the customer
- Modifying tunnel options causes a tunnel to renegotiate, which is a production event
- Infrastructure-as-code definitions must be updated in step or the change will be reverted by the next apply
Migration paths
The routes available when the current state is not the target.
- Update tunnel options through the estate's existing infrastructure-as-code path
- Migrate the customer gateway side first where it is the constraint
- Replace or upgrade the customer gateway device where it cannot support the target
- Defer and track where the service does not yet expose the required method
Verification requirements
What must be evidenced before a change is recorded as complete.
- Confirm the negotiated method from the customer gateway side, where the detail is visible
- Check tunnel status through the VPN connection API after the change
- Verify both tunnels of the connection, not only the active one
Sources
- 1. Site-to-Site VPN tunnel options(opens in a new tab)
Amazon Web Services · verified by PQVPN
Individual compatibility records carry their own sources, listed against each record in the compatibility matrix.
Need this mapped to your actual AWS VPN estate?
A readiness assessment establishes the exact release, licence and peer position for every gateway you run — and tells you which tunnels can move first.