Category: Zero Trust Architecture

Resource Gateway

Also known as: VPC Lattice Resource Gateway

Simply put

A Resource Gateway is an Amazon Web Services networking construct in VPC Lattice that serves as the entry point for inbound traffic into the VPC where a given resource resides. It is deployed across multiple Availability Zones, and a VPC must have a resource gateway to receive this traffic. It is a network ingress mechanism rather than an identity or access-control component.

Formal definition

In AWS VPC Lattice, a Resource Gateway is the point of ingress that receives traffic into the VPC hosting a resource, spanning multiple Availability Zones per the AWS documentation. It is a network-level construct for directing inbound traffic to resources within a VPC; the official AWS documentation describes it strictly in terms of traffic ingress and Availability Zone coverage. Based on the available evidence, the Resource Gateway does not itself perform authentication, token validation, identity provider delegation, or runtime authorization enforcement (no PEP/PDP/PIP function is attributed to it in the source material). Any such access-control decisions would be handled by separate mechanisms and are out of scope for this construct as documented. Note: cross-region access patterns involving resource gateways appear only in community-authored material (AWS re:Post) and are not asserted here as an officially documented capability.

Why it matters

The Resource Gateway matters primarily as a network topology construct: within AWS VPC Lattice, a VPC must have a resource gateway in order to receive inbound traffic to the resources it hosts. For architects and network engineers building connectivity between VPCs and service networks, understanding that this construct is the mandated point of ingress is essential to designing reachable, highly available resource access paths. Because it spans multiple Availability Zones per the AWS documentation, it also factors into resilience planning for how traffic enters a VPC.

Equally important for an IAM audience is what the Resource Gateway is not. Despite the word 'gateway,' which in other contexts (such as API gateways) often implies inline security enforcement, the AWS documentation describes this construct strictly in terms of traffic ingress and Availability Zone coverage. It is not an identity or access-control component: the available evidence attributes no authentication, token validation, identity provider delegation, or runtime authorization (PEP/PDP/PIP) function to it. Security architects should not assume that placing a resource behind a Resource Gateway provides any access-control guarantees on its own.

Any authentication or authorization decisions governing access to resources reachable through a Resource Gateway must be implemented by separate mechanisms and are out of scope for this construct as documented. Treating the Resource Gateway as a network enabler rather than a policy enforcement point avoids a common and consequential design error, conflating reachability with authorization.

Who it's relevant to

Network and Cloud Architects

Those designing AWS VPC Lattice connectivity need to know that a VPC must have a resource gateway to receive inbound traffic to its resources, and that the construct spans multiple Availability Zones. It is central to planning reachable, resilient ingress paths, but it is a networking element, not a security control.

Security Architects and IAM Engineers

This group should understand the Resource Gateway primarily to avoid misclassifying it. The available evidence attributes no authentication, token validation, identity provider delegation, or PEP/PDP/PIP enforcement to it. Access-control decisions for resources reachable through it must be enforced by separate, dedicated mechanisms.

Cloud Operations and Reliability Engineers

Because the construct spans multiple Availability Zones and is a required ingress point for a VPC's resources, operations teams should account for it in availability, connectivity, and inventory planning. Tooling such as Datadog exposes it as a discrete VPC Lattice resource type for monitoring and asset tracking.

Inside Resource Gateway

Network Ingress Point

The Resource Gateway is fundamentally a network-layer ingress construct that provides an entry point into a VPC or set of resources. Its role is to route or expose network connectivity, not to perform identity operations.

VPC / Subnet Association

A Resource Gateway is deployed in association with a VPC and specific subnets, defining where in the network topology the ingress point resides. This placement governs which resources become reachable through it.

Security Group Association

Security groups can be attached to control which traffic is permitted to reach the gateway at the network level. This is L3/L4 traffic filtering, not authentication or authorization of a principal's identity.

IP Address Type Configuration

The gateway is configured with an IP address type (for example IPv4 or dual-stack, depending on the deployment), determining the addressing scheme available to connecting clients.

Resource Reachability Scope

The gateway defines the set of resources that become reachable through the ingress path. It governs network reachability rather than making per-request access decisions about who may use those resources.

Common questions

Answers to the questions practitioners most commonly ask about Resource Gateway.

Does an AWS Resource Gateway authenticate callers or validate tokens?

No. In its AWS VPC Lattice context, a Resource Gateway is a network ingress point that defines where traffic enters to reach resources within a resource configuration. It does not perform authentication, token validation, or identity verification. Those functions belong to separate mechanisms such as IAM auth policies, application-layer PEPs, or an identity provider, not to the gateway construct itself. Treating it as an authentication component conflates network reachability with identity verification.

Is a Resource Gateway a policy enforcement point (PEP) that makes authorization decisions?

Not in the runtime PDP/PEP sense used in access control architectures. The Resource Gateway governs network ingress for a resource configuration; it is not documented as a component that evaluates identity attributes, consults a PIP, or renders allow/deny authorization decisions per request. Authorization enforcement in AWS is handled by distinct services and policy constructs. Avoid attributing generic API-gateway PEP behavior to it unless your own architecture explicitly layers such controls on top.

Where does a Resource Gateway fit relative to authentication and authorization controls in a deployment?

It sits at the network layer as an ingress point, upstream of the identification, authentication, and authorization steps that your application or platform enforces. In most deployments you would still place separate controls, for example an IdP for authentication and IAM or application policy for authorization, behind or alongside the gateway. Confirm the exact placement against your architecture, since the gateway does not supply these controls itself.

What should I use to enforce access control if the Resource Gateway does not do it?

Depending on your configuration, access enforcement typically comes from mechanisms outside the gateway: IAM policies, service-level auth policies, an application-layer PEP, or an identity provider integration for authentication. Design these explicitly rather than assuming the gateway provides them. Validate the specific capabilities against current AWS documentation for the service you are using.

How do I verify what a Resource Gateway actually supports before relying on a capability?

Consult the official AWS user guide for the specific service the Resource Gateway belongs to rather than community blog posts, which may describe unsupported or unofficial behavior. Capabilities such as cross-region support should be confirmed against documented, supported features. If a capability is not stated in official documentation, treat it as unverified for production planning.

Should a Resource Gateway be treated as part of a Zero Trust architecture?

That categorization is not established by AWS material and should be treated as an architectural interpretation rather than a documented property of the construct. A Resource Gateway provides network ingress; whether it participates in a Zero Trust design depends on the other identity, authentication, and authorization controls you deploy around it. Do not assume Zero Trust properties from the gateway alone.

Common misconceptions

A Resource Gateway authenticates users or validates presented tokens, acting like a Policy Enforcement Point (PEP) or API gateway.

Per AWS documentation, the Resource Gateway is a network ingress construct only. It does not perform authentication, token validation, or runtime authorization. Those functions must be provided by separate services (for example an IdP for authentication and a PDP/PEP for authorization) and are out of scope for the gateway itself.

The Resource Gateway delegates authentication to an identity provider and enforces identity-based policy.

There is no AWS documentation supporting IdP delegation or identity-based enforcement by the Resource Gateway. It operates at the network layer and does not define or enforce identity authentication or authorization behavior.

Cross-region operation is a documented, supported capability of the Resource Gateway.

Cross-region support is not confirmed by the official AWS user guide; such claims appear only in community/blog sources. Practitioners should verify current supported regions and topologies against official AWS documentation before relying on this behavior.

Best practices

Treat the Resource Gateway strictly as a network ingress point; layer authentication (via an IdP) and authorization (via a PDP/PEP) as separate, dedicated components rather than expecting the gateway to provide them.

Scope reachability tightly by configuring associated subnets and security groups to expose only the resources that must be reachable through the gateway, applying least-privilege at the network layer.

Confirm the IP address type (for example IPv4 or dual-stack) matches your client connectivity requirements before deployment to avoid reachability gaps.

Verify any cross-region or advanced topology assumptions directly against the current official AWS user guide, since some claimed capabilities are only documented in unofficial sources.

Document the boundary of responsibility clearly in your architecture: record which component handles identification, authentication, and authorization, since the Resource Gateway handles none of these.

Pair network-level controls on the gateway with runtime access enforcement elsewhere so that reaching the ingress point does not by itself grant access to underlying resources.