Mis notas sobre AWS VPC EndPoints |

Introducción

A continuación incluyo mis notas sobre VPC EndPoints en AWS para tener centralizada la información que es de mas interés para mis proyectos y servicios. Remarcar que tener un concreto marco de trabajo con este servicio es vital por motivos de configuración a nivel de comunicaciones, seguridad y finops.

¿Para que nos sirve este tipo de servicio? (Definiciones)

A VPC endpoint allows you to privately connect your VPC to supported AWS services. It doesn’t require you to deploy an internet gateway, network address translation (NAT) device, Virtual Private Network (VPN) connection, or AWS Direct Connect connection. Endpoints are virtual devices that are horizontally scaled, redundant, and highly available VPC components. VPC endpoints allow communication between instances in your VPC and services, without imposing availability risks or bandwidth constraints on your network traffic.
A VPC endpoint enables workloads in an Amazon VPC to connect to supported public AWS services or third-party applications over the AWS network. This approach is used for workloads that should not communicate over public networks.

Tipos de Endpoint

There are three types of VPC endpoints: gateway load balancer endpoints, gateway endpoints, and interface endpoints.

Gateway Load Balancer EndPoints

A Gateway Load Balancer endpoint, allows you to intercept traffic and route it to a network or security service that you’ve configured using a Gateway Load Balancer. Gateway load balancers enable you to deploy, scale, and manage virtual appliances, such as firewalls, intrusion detection and prevention systems, and deep packet inspection systems.

Introducing AWS Gateway Load Balancer: Supported architecture patterns

Gateway EndPoints

Gateway endpoint, allows you to provide access to Amazon Simple Storage Service (S3) and Amazon DynamoDB. You can configure resource policies on both the gateway endpoint and the AWS resource that the endpoint provides access to. A VPC endpoint policy is an AWS Identity and Access Management (AWS IAM) resource policy that you can attach to an endpoint. It is a separate policy for controlling access from the endpoint to the specified service. This enables granular access control and private network connectivity from within a VPC. For example, you could create a policy that restricts access to a specific DynamoDB table. This policy would only allow certain users or groups to access the table through a VPC endpoint.

Interface endpoint supports a growing list of AWS services. Consult our documentation to find AWS services compatible with interface endpoints powered by AWS PrivateLink.

Interface EndPoints

an Interface endpoint, allows you to connect to services powered by AWS PrivateLink. This includes a large number of AWS services. It also can also include services hosted by other AWS customers, and AWS Partner Network (APN) partners in their own VPCs. By using AWS partner services through AWS PrivateLink, you no longer have to rely on access to the public internet. Data transfer charges for traffic from Amazon EC2 to the internet vary based on volume. After the first 1 GB / month ($0.00 per GB), transfers are charged at a rate of $ 0.09/GB (for AWS US-East 1 Virginia). Like gateway endpoints, interface endpoints can be secured using resource policies on the endpoint itself, and the resource that the endpoint provides access to. Interface endpoints allow the use of security groups to restrict access to the endpoint.

Arquitecturas con VPC Endpoints

An organization’s existing network design may influence where VPC Endpoints are deployed. In larger multi-account AWS environments, network design can vary considerably. Consider an organization that has built a hub-and-spoke network with AWS Transit Gateway. VPCs have been provisioned into multiple AWS accounts, perhaps to facilitate network isolation or to enable delegated network administration.

Arquitecturas Distribuidas

For distributed architectures, you can build a “shared services” VPC, which provides centralized access to shared services required by workloads in each of the VPCs. These shared services may include resources such as directory services or VPC endpoints. Sharing resources from a central location instead of building them in each VPC may reduce administrative overhead and cost.

Instead of centralizing VPC endpoint deployment, a network designer may choose to deploy endpoints within a spoke VPC to ensure it is proximate to a single workload that will use the endpoint.

Arquitecturas Centralizadas

An organization may have centralized its network and chosen to leverage VPC sharing to enable multiple AWS accounts to create application resources. Such an approach allows aggregating Amazon EC2 instances, Amazon Relational Database Service (RDS) databases, and AWS Lambda functions into a shared, centrally managed network. With either pattern, establishing a granular set of controls to limit access to resources is critical to support organizational security and compliance objectives. At the same time, it helps maintain operational efficiency.

Some customers use centralized VPC endpoint architecture patterns. This is where the interface endpoints are all managed in a central hub VPC for accessing the service from multiple spoke VPCs. This architecture helps reduce the complexity and maintenance for multiple interface VPC endpoints across different VPCs. When using an S3 interface endpoint, you must consider the amount of network traffic that would flow through your network from spoke VPCs to hub VPC. If the network connectivity between spoke and hub VPCs are set up using transit gateway, or VPC peering, consider the data processing charges (currently $0.02/GB). If VPC peering is used, there is no charge for data transferred between VPCs in the same Availability Zone. However, data transferred between Availability Zones or between Regions will incur charges as defined in our documentation.

VPC Endpoint Strategy for Amazon S3

Amazon S3 can be accessed using an interface VPC endpoint powered by AWS PrivateLink or a gateway VPC endpoint.

Factors to consider as you choose one strategy over the other:

	Gateway EndPoint	Interface Endpoint
Cost	Gateway endpoints for S3 are offered at no cost and the routes are managed through route tables.	Interface endpoints are priced at $0.01/per AZ/per hour. Cost depends on the Region, check current pricing. Data transferred through the interface endpoint is charged at $0.01/per GB (depending on Region).
Access pattern	S3 access through gateway endpoints is supported only for resources in a specific VPC to which the endpoint is associated. S3 gateway endpoints do not currently support access from resources in a different Region, different VPC, or from an on-premises (non-AWS) environment.	Where access is from resources external to VPC, S3 interface endpoints access S3 in a secure way.
Architecture	If you chose a gateway endpoint, install a fleet of proxies in the VPC to address transitive routing.	In scenarios where you must access S3 buckets securely from on-premises or from across Regions, we recommend using an interface endpoint.
Bandwidth	Gateway endpoints are route table entries that route your traffic directly from the subnet where traffic is originating to the S3 service. Traffic does not flow through an intermediate device or instance. Hence, there is no throughput limit for the gateway endpoint itself. The initial setup for gateway endpoints consists in specifying the VPC route tables you would like to use to access the service. Route table entries for the destination (prefix list) and target (endpoint ID) are automatically added to the route tables.	When setting up an interface endpoint, choose multiple subnets across multiple Availability Zones to implement high availability. The number of ENIs should equal to number of subnets chosen. Interface endpoints offer a throughput of 10 Gbps per ENI with a burst capability of 40 Gbps. If your use case requires higher throughput, contact AWS Support.

Single VPC architecture

Using a single VPC, we can configure:

Gateway endpoints for VPC resources to access S3
VPC interface endpoint for on-premises resources to access S3

The following architecture shows the configuration on how both can be set up in a single VPC for access. This is useful when access from within AWS is limited to a single VPC while still enabling external (non-AWS) access.

DNS configured on-premises will point to the VPC interface endpoint IP addresses. It will forward all traffic from on-premises to S3 through the VPC interface endpoint. The route table configured in the subnet will ensure that any S3 traffic originating from the VPC will flow to S3 using gateway endpoints.

Multi-VPC centralized architecture

In a hub and spoke architecture that centralizes S3 access for multi-Region, cross-VPC, and on-premises workloads, we recommend using an interface endpoint in the hub VPC. The same pattern would also work in multi-account/multi-region design where multiple VPCs require access to centralized buckets.

Please note that when using a Transit Gateway and VPC Endpoint combination to route traffic to a service destination, cumulative inbound and outbound processing charges for Transit Gateway and VPC Endpoint may be incurred. Care should be taken to understand this cost implication. See AWS PrivateLink pricing and AWS Transit Gateway pricing.

In addition, firewall appliances that monitor east-west traffic will experience increased load with the Multi-VPC centralized architecture. It may be necessary to use the single VPC endpoint design to reduce impact to firewall appliances.

Links de Soporte

Enjoy!!!