Gateway Endpoints – Designing Networks for Complex Organizations – SAP-C02 Study Guide

Gateway Endpoints

A gateway endpoint is the first type of endpoint that launched on AWS, and it has been supporting connectivity to only two AWS services ever since: Amazon S3 and Amazon DynamoDB.

A gateway endpoint is a routable object that you must add to your VPC or subnet route table to be able to leverage it, like an internet or NAT gateway on AWS. On top of that, you can specify custom access permissions for your gateway endpoint by attaching endpoint policies to it.

See an example of this Figure 2.15:

Figure 2.15: VPC gateway endpoint

You can attach several AWS gateway endpoints to any VPC. You will separate gateway endpoints, one for each service (S3 or DynamoDB) that you want to access, and then if you require different access permissions for different groups of resources, you may even have different gateway endpoints for the same service within the same VPC. If you use multiple endpoints for the same service in the one VPC, you will need to set different routes to use each of these endpoints in different route tables (for each service, you can only have a single route in every route table).

The following current limitations are worth noting:

  • Cross-region is not supported. Gateway endpoints can only be used to reach out to AWS services in the same region as the VPC where they are set.
  • Endpoint connections do not extend beyond the boundaries of a VPC. You cannot leverage the gateway endpoint defined in your VPC to access a service behind
  • that endpoint from another VPC or from your on-premises environment, whichever network topology you may have (VPC peering, Transit Gateway, VPN, DX, and so on).

Before moving on to the next section, consider the two key aspects: resiliency and cost.

Additional Considerations

There are a few attention points when using private endpoints. You want to be mindful of resiliency and cost aspects.

AZs

Services offered by third-party providers, whether in your own organization or beyond, may not always be available in each AZ within a given AWS region.

An interface endpoint is mapped to an AZ upon creation. Therefore, it is important, especially for third-party services, to validate in which AZs they are available and to use AZ identifiers (IDs) to identify AZs uniquely and consistently across accounts. Remember the difference between the following:

  • An AZ name (for example, eu-west-1a) that does not necessarily map to the same AZ in two different AWS accounts
  • An AZ ID (for example, euw1-az1) that always refers to the same AZ across all AWS accounts

So first, you must use AZ IDs to make sure that you deploy endpoints in the right AZs where the service is also available. Secondly, it is recommended as a best practice to always deploy endpoints in at least two AZs for HA purposes.