Where MODP3072 Goes in an AWS Site-to-Site VPN
MODP3072 is IANA group 15, but the group belongs to a phase. Map the requirement to Phase 1 or Phase 2 DH lists before you edit a tunnel.
Someone sends you a requirement that reads IKEv2, ESP and MODP3072, and the console has no field with that name. The mistake is to go looking for one. IKEv2 is a negotiation version, ESP is the protocol that carries your protected traffic, and MODP3072 is a key-exchange group, which is IANA group 15. Those three facts live in three different places, and the group appears twice.
The phrase is not a single setting
Translate the requirement into option lists before touching anything. The table below is the whole crosswalk.
| Agreed requirement | AWS option to review | Still a separate decision |
|---|---|---|
| IKEv2 | Allowed IKE versions | Encryption, integrity, key-exchange choices |
| MODP3072 for the IKE exchange | Phase 1 DH groups, group 15 | Phase 2 key-exchange and PFS policy |
| MODP3072 for the protected-traffic exchange | Phase 2 DH groups, group 15 | The initial IKE exchange group |
| A named encryption algorithm | That phase's encryption list | Integrity and DH-group agreement |
MODP3072 is group 15, and AWS currently accepts 15 in both the Phase 1 and the Phase 2 DH-group lists. Accepting it in both places is not the same as requiring it in both, and it certainly does not mean your partner meant both.
Phase 1 and Phase 2 negotiate different things
Phase 1 builds the IKE security association: how the two gateways authenticate, agree on keys and protect their own conversation. Phase 2 builds the CHILD SA that carries your actual traffic, and its key exchange can be fresh rather than inherited.
That split is why a partner saying perfect forward secrecy matters. PFS is a Phase 2 property, and a group in the Phase 1 list does not deliver it. Ask which exchange each requirement applies to, along with the encryption mode, whether integrity is provided by an AEAD cipher, and the rekey expectations on both sides.
Do not infer a complete acceptable suite from the word AES or from one DH number. A policy assembled from two halves of two conversations is how a tunnel ends up proposing something neither team agreed to.
An allowed list is not a negotiation result
The option lists describe what each side is willing to accept. They do not report what was chosen. Read the actual selected IKE and CHILD-SA proposals for a fresh connection, then confirm the requirement is satisfied rather than merely permitted. A strong option sitting in a list proves only that it was available.
Watch the renewal too. The first IKEv2 CHILD SA and a later PFS-bearing CHILD exchange can expose different compatibility conditions, because the second exchange creates fresh keying material with the PFS group in play. If your acceptance test only covers the first minute of a tunnel, it has not tested the part your partner cares about.
The AWS tunnel-options reference lists Phase 1 and Phase 2 independently, which is the structure worth internalising before the next requirement lands.
Change the tunnel you actually mean
A Site-to-Site VPN connection has two tunnels with their own options and their own state. Match the AWS tunnel's outside address to the customer-gateway peer before you review or edit anything, and do not assume one save updates both.
An approved change needs the customer-gateway side prepared for the same policy and a window for the interruption the selected tunnel will take. If the peer is not ready for group 15 at the phase you are changing, the tunnel will simply stop coming up, and the console will not tell you which side refused.
Record the agreed policy as phase, protocol version, encryption, integrity and DH group, then confirm it at the exchanges it is supposed to protect. Routing, traffic selectors and application permissions stay separate; this mapping is not a full gateway configuration, and it is not a recommendation to enable extra algorithms for variety.