A customer gateway is the remote endpoint that represents the non-AWS side of a VPN connection. It identifies the peer network and its public address so the cloud provider can establish and maintain the tunnel. In practice, it is the anchor point for routing into the external environment.
What a customer gateway represents
A customer gateway is the customer-side endpoint of a site-to-site VPN. It identifies the external network, anchors the public-facing peer address, and gives the cloud service a concrete target for tunnel establishment and maintenance.
That makes it less about a device model and more about a trust boundary: the cloud side needs a stable, known counterpart before it can route traffic into the remote environment.
Why customer gateways matter in VPN design
In practical network design, the customer gateway is the object that ties the remote network to the VPN relationship. It is the reference point for the peer address, routing attachment, and configuration consistency needed for the tunnel to come up and stay usable.
Because the gateway represents the non-cloud side, any change to the peer address, edge router, or upstream path can affect tunnel stability. That is why it is often treated as an administrative object with operational significance, not just a label.
How customer gateways fit into routing and connectivity
A customer gateway supports the exchange of reachability information between the cloud environment and the remote network. In most deployments, it sits alongside a virtual private gateway, transit gateway, or similar cloud-side termination point, with the two ends defining the path for encrypted traffic.
The concept also helps separate external network identity from internal routing details. The cloud provider does not need to know the full topology of the remote site to establish the tunnel, but it does need the correct endpoint and a stable expectation of where traffic should be sent.
In that sense, the customer gateway is a control plane object for connectivity, while the VPN tunnel itself is the data plane relationship it enables.
Common implementation and operational considerations
Customer gateways are usually most important when teams are standardizing remote connectivity across multiple sites, partners, or hybrid environments. The gateway definition must stay aligned with the real-world network edge, especially when public IPs, routing devices, or upstream carriers change.
Misalignment here can produce symptoms that look like generic VPN failure, but the root cause is often simpler: the cloud still points to the wrong peer, or the remote side no longer matches the recorded endpoint.
For that reason, the term is most useful when engineers are reasoning about tunnel setup, change management, and the boundary between the provider network and the customer network.
Risk and Threat Considerations
A customer gateway can become a failure point when the recorded peer address, routing edge, or tunnel configuration drifts from the actual remote environment. That can break connectivity, create hard-to-diagnose outages, or leave teams believing a tunnel is healthy when the real path is not what they expect.
Failure mechanism: The cloud side depends on a correct and stable remote endpoint, so address changes, edge device replacement, or configuration drift can prevent the VPN from establishing or maintaining trust in the peer.
Impact: The result can be loss of connectivity, interrupted access to private services, and exposure to routing mistakes that complicate recovery and change verification.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | A customer gateway defines the remote side of a network boundary that the VPN must protect. |
| AC-4 — Information Flow Enforcement | The gateway affects what traffic may flow between cloud and external networks. | |
| Recommendation — Protect the VPN boundary with SC-7 controls that validate and restrict traffic across the customer edge. Enforce AC-4 policy so only approved flows traverse the customer gateway path. | ||
| NIST Zero Trust (SP 800-207) | 3.0 — Zero Trust Architecture Principles | The gateway sits at a trust boundary where remote connectivity should be continuously verified. |
| Recommendation — Apply zero trust principles to treat the customer gateway as an untrusted boundary until traffic is explicitly authorized. | ||
Practitioner Guidance
What to watch for: Treat the customer gateway as a managed connectivity object, not a one-time setup value. When the upstream network changes, review the peer address, routing assumptions, and tunnel status together so the recorded endpoint still matches the real perimeter.
Practitioner takeaway: Most customer-gateway problems are lifecycle problems, not tunnel-protocol problems, so accurate change control is usually the fastest way to keep hybrid connectivity reliable.
Related resources from NHI Mgmt Group
- What is the difference between keeping AI gateway analytics in customer-owned object storage and running a managed logging database in the provider cloud?
- What breaks when AI usage is not attributed by team, workload, or customer at the gateway layer?
- How should security teams govern partner API access at the gateway?
- What is the difference between a managed gateway and a reverse proxy in front of a gateway?
