VPC Endpoints and Security

Beyond the principle of least privilege, there are additional use cases for VPC endpoints. For some customers, security and compliance impose strict requirements on resources with access to the Internet. VPC endpoints allow access to public AWS APIs without requiring access to the Internet. VPC endpoints also allow you to define granular access control to services between VPCs or accounts without allowing the broad access provided by VPC peering. The principle of least privilege and controlling Internet access is covered in more detail in Chapter 15, “Risk and Compliance.” Reducing the number of instances or subnets that have Internet access can make security operations simpler, avoiding the complexity involved with NAT and routing policies and reducing the scope of certain audits and compliance checks.

Services such as Amazon Simple Storage Service (Amazon S3) allow more granular access when they are accessed over VPC endpoints using bucket policies and endpoint policies. It is possible to limit Amazon S3 bucket access to specific VPC endpoints, which can be configured for specific subnets and instances through routing and security groups.

It is also possible to reduce or eliminate the need for an AWS Direct Connect public Virtual Interface (VIF) if all of the AWS Cloud services that you need to access are available through VPC endpoints. This is another method to reduce public exposure. Details on how to access endpoints over AWS Direct Connect are provided later in this chapter.

VPC Endpoint Policy

VPC endpoints may support a VPC endpoint policy. A VPC endpoint policy is an AWS Identity and Access Management (IAM) resource policy that you attach to an endpoint when you create or modify the endpoint. If you do not attach a policy when you create an endpoint, AWS attaches a default policy for you that allows full access to the service. An endpoint policy does not override or replace IAM user policies or service-specific policies (such as Amazon S3 bucket policies). It is a separate policy for controlling access from the endpoint to the specified service.

Gateway VPC Endpoints

A gateway VPC endpoint is a gateway that serves as a target for a route in your route table for traffic destined to an AWS Cloud service. This type of endpoint supports Amazon S3 and Amazon DynamoDB. Gateway VPC endpoints use routes and prefix lists to route privately to AWS Cloud services. Instances using gateway VPC endpoints will resolve the service’s Domain Name System (DNS) to a public address. The route to those public addresses uses the gateway VPC endpoint to access the service.

Interface VPC Endpoints

Interface VPC endpoints (powered by AWS PrivateLink) are implemented as special elastic network interfaces in Amazon VPC. When you create an interface VPC endpoint, AWS generates endpoint network interfaces in the subnets that you specify. Each interface VPC endpoint is specific to a single VPC and uses IPv4 addresses from the local subnets. When you create an interface VPC endpoint, AWS generates endpoint-specific DNS hostnames that you can use to communicate with the service. For AWS services and AWS Marketplace partner services, you can optionally enable private DNS for the endpoint. This option associates a private hosted zone with your VPC. The hosted zone contains a record set for the default DNS name for the service, which resolves to the private IP addresses of the endpoint network interfaces in your VPC. This enables you to make requests to the service using its default DNS hostname instead of the endpoint-specific DNS hostnames.

AWS PrivateLink

AWS PrivateLink is a type of interface VPC endpoint for AWS in addition to customer and partner services. AWS provides access to services such as the Amazon EC2 API and Elastic Load Balancing API with AWS PrivateLink. AWS PrivateLink is a newer and different way to access AWS Cloud services compared to gateway VPC endpoints.

AWS PrivateLink also enables building your own VPC endpoint services. AWS PrivateLink customers and service providers can create private endpoints to resources or services in their own VPC. You can access services in another VPC or account, including service providers and partners that support AWS PrivateLink. Each AWS PrivateLink connection is a relationship between a service consumer and a service provider. Example use cases for AWS PrivateLink include accessing a shared enterprise-provided API across many VPCs or accessing a Software as a Service (SaaS) logging provider’s services with a private connection.

Amazon S3 Endpoints

An Amazon S3 endpoint allows private access to Amazon S3 from your VPC. As shown in Figure 3.1, instances in subnet 2 can access Amazon S3 through the VPC endpoint.

When you create an Amazon S3 endpoint, a prefix list and a VPC endpoint are created in your VPC. The prefix list is the collection of IP addresses that Amazon S3 uses. It is formatted as pl-xxxxxxxx and becomes an available option in both subnet routing tables and security groups.

The VPC endpoint uses the format of vpce-xxxxxxxx, and it appears as a route destination in your route tables. The subnets that you select when you create the Amazon S3 endpoint will receive a new route for the prefix list directed toward the new gateway VPC endpoint. Table 3.1 shows a sample routing table using gateway VPC endpoints.

You can create multiple endpoints in the same VPC. This is used to apply different endpoint policies to allow different access. Because each route table may contain only a single prefix list, you are limited to one endpoint per subnet. If instances in the subnet require different Amazon S3 access policies, consider alternative subnet designs that achieve your desired policy or control outcomes.

The Amazon S3 endpoint uses DNS to direct traffic to the endpoint. You must enable DNS resolution in your VPC.

Amazon DynamoDB Endpoints

Amazon DynamoDB endpoints are very similar to Amazon S3 endpoints. Because Amazon DynamoDB uses gateway VPC endpoints, they use the same concepts of prefix lists and route tables to direct traffic to Amazon DynamoDB.

Like VPC endpoints for Amazon S3, VPC endpoints for Amazon DynamoDB support endpoint policies. An endpoint policy can restrict access to operations such as writes or access to specific tables.

There are some service-specific limitations that endpoints impose that, while out of the scope of this exam, may be important for design. One example is that you cannot access Amazon DynamoDB Streams through an endpoint.

Accessing Gateway Endpoints Over Remote Networks

Gateway VPC endpoints use AWS route table entries and DNS to route traffic privately to AWS Cloud services. These mechanisms only work within a VPC and prevent access to gateway endpoints from outside the VPC. Connections that originate from Amazon VPN or AWS Direct Connect through a Virtual Private Gateway (VGW) cannot directly access gateway endpoints. You also cannot access a gateway endpoint over VPC peering.

In order to overcome transitive routing limitations, you can modify DNS resolution and use a proxy fleet to reach VPC endpoints. Figure 3.2 shows a DNS-based proxy solution that directs traffic from a corporate network to a VPC endpoint for Amazon S3.

Core components of the solution are Elastic Load Balancing, a proxy farm, and the corporate DNS. The corporate DNS is configured to direct Amazon S3 requests to the CNAME of the load balancer. In this scenario, the destination IP address is a load balancer interface in the VPC. This configuration resolves the transitive routing scenario. The load balancer forwards the traffic to an Auto Scaling group of proxy instances. The proxy instances are placed in a subnet with access to an Amazon S3 endpoint. The proxies can be configured with an additional policy to allow or disallow certain requests, which can augment the level of control that the endpoint policy and Amazon S3 bucket policy provide.

This solution applies to both Amazon S3 and Amazon DynamoDB. The solution will work for VPN and AWS Direct Connect traffic sources.

Securing Gateway VPC Endpoints

VPC endpoint policies can limit what resources, such as buckets or tables, are accessible using the endpoint. When using endpoints for Amazon S3, bucket policies can allow incoming requests from either public connections or specific Amazon S3 endpoints.

Inside the VPC, you can control endpoint access by limiting the subnets with routes to the VPC endpoint. To provide granular access per instance, you can specify the prefix list in an outbound security group rule. The prefix list is not available in a network Access Control List (ACL).

Interface VPC Endpoints

Interface VPC endpoints allow you to access specific AWS Cloud services. This access method is also called AWS PrivateLink for AWS Services. In Figure 3.3, instances in subnet 1 can communicate with Amazon Kinesis through the interface VPC endpoint. Instances in subnet 2 communicate over the Internet through an Internet gateway.

The following are some considerations that you should take into account when accessing services over an interface VPC endpoint.

• You can access a VPC endpoint from AWS Direct Connect; however, you cannot access a VPC endpoint from across an AWS managed VPN connection or a VPC peering connection.
• For each AWS Cloud service, you can create one interface endpoint in each Availability Zone within your VPC.
• AWS Cloud services may not be available in all Availability Zones through an interface endpoint.
• Each endpoint can support a bandwidth of up to 10 Gbps per Availability Zone. Additional capacity may be added automatically based on your usage.
• Endpoints support IPv4 traffic only.
• AWS Cloud services cannot initiate requests to resources in your VPC through the endpoint. An endpoint can only return responses to traffic initiated from resources in the VPC.

AWS PrivateLink for Customer and Partner Services

So far, this chapter has discussed how to access AWS Cloud services privately through VPC endpoints, but you may also want to access your own or someone else’s services privately. AWS PrivateLink allows you to access or share a service securely between VPCs or accounts using the Network Load Balancer to create VPC endpoint services. A VPC endpoint service is an interface VPC endpoint that you control and that keeps traffic within Amazon’s private network.

Customers can build microservices architectures and share applications between VPCs, though these use cases may create complex networking challenges that involve many VPCs, granular security requirements, and overlapping addresses. In addition, many hosted services and SaaS offerings are provided on AWS. It is possible to increase the security of accessing these services with the VPC endpoint service.

VPC endpoint service uses private and public DNS, Network Load Balancer, and elastic network interfaces to operate between VPCs. In Figure 3.4, VPC endpoint service is configured between a service provider and service consumer.

The provider has a service that is registered as something like vpce-svc-0569c51ce317ddfdb.us-east-2.vpce.amazonaws.com.

This name is associated with a Network Load Balancer in the provider’s VPC. The interfaces and IP addresses for this Network Load Balancer are in the consumer’s VPC. DNS will resolve vpce-svc-0569c51ce317ddfdb.us-east-2.vpce.amazonaws.com in the consumer VPC to the local IP addresses, which will forward the traffic to the provider’s Network Load Balancer in another VPC. It is recommended to treat this name in a similar manner as Elastic Load Balancing DNS names and to use an alias record to make the endpoint easier to use, such as vpce.example.com. The Network Load Balancer will perform source NAT using the source IP of the Network Load Balancer. The source NAT allows for providers to connect consumers with overlapping addresses. Providers can determine the source of traffic by enabling proxy protocol on the load balancer or by using application-level identification.

VPC endpoint service functionality is useful for connecting applications across VPCs. Use cases include shared services VPCs, connecting with business partners and customers, and enabling more granular access between applications in different VPCs. The shared services VPC concept is explained in greater depth in Chapter 16 on Scenarios and Reference Architectures.

Comparing AWS PrivateLink and VPC Peering

As discussed in Chapter 2 on Amazon VPC and Networking Fundamentals, VPC peering allows for two Amazon VPCs to communicate. Peering requires the requested VPC to accept the peering request and for both VPCs to configure routing over the peering connection in the applicable subnets.

VPC peering is appropriate when there are many resources that should communicate between the peered VPCs. If there is a high degree of inter-VPC communication and the security and trust levels are similar, VPC peering is a good choice for connectivity.

You can use AWS PrivateLink to simplify multi-VPC network configurations in a variety of scenarios. First, VPC peering allows access to the full VPC. To limit traffic across VPC peers, you can use route table entries and security groups. Even with the availability to reference security groups in a peered VPC in the same region, there is ample room for errors. Moreover, if you are providing a service to multiple VPCs, there are scalability challenges in managing the volume routes and security groups. If you only need to share one application, even across multiple VPCs, AWS PrivateLink significantly reduces overall complexity. AWS PrivateLink allows one-way access on a per-application basis, from the consumer to the provider, solving connectivity between multiple VPCs in a simple way.

Second, peering requires non-overlapping VPC Classless Inter-Domain Routing (CIDR) ranges. If multiple VPCs use a common IP range, then they cannot peer directly together. A hub VPC can peer with multiple spoke VPCs that use the same address range, but the hub will only be able to route any particular portion of the overlapping address range to a single peered VPC. AWS PrivateLink supports overlapping CIDR ranges by applying source NAT from the consumer to the provider of the AWS PrivateLink.

Third, there are scale limits associated with VPC peering. A VPC can only peer with 125 other VPCs. AWS PrivateLink scales to thousands of consumers per VPC. The amount of services provided by a single VPC is limited by the amount of Network Load Balancers supported. Providing services can be split into multiple VPCs if they do not have dependencies on each other.

AWS PrivateLink has its own design considerations. AWS PrivateLink only allows the consumer to originate connections to the provider. If bidirectional communication is needed, VPC peering or a reciprocal AWS PrivateLink between the consumer and provider may be required. In addition, traffic to AWS PrivateLink is load balanced, and it inherits the design considerations of Network Load Balancer. For example, Network Load Balancer only supports Transmission Control Protocol (TCP) (more about Network Load Balancer design considerations are covered in Chapter 6 on Domain Name System and Load Balancing). In addition, connections from the consumer to the provider go through source NAT, which may prevent applications from identifying the consumer IP address. This behavior is different than the standard Network Load Balancer behavior, where the source IP is preserved.

AWS PrivateLink Service Provider Considerations

This section reviews what is involved with configuring the provider side of a VPC endpoint service (powered by AWS PrivateLink). You may choose to configure a provider endpoint to offer services publicly, to a business partner, or privately within a trusted set of accounts or VPCs.

The first step is to associate a Network Load Balancer with your service. You will need to select the Availability Zones applicable for your service. The Network Load Balancer is responsible for the load balancing, exposing a single address per Availability Zone, and performing source NAT on incoming connections.

You can create an endpoint service after the Network Load Balancer is configured. You will receive the DNS name of your endpoint after creating the endpoint, such as vpce-svc-0569c51ce317ddfdb.us-east-2.vpce.amazonaws.com. You will also receive the service name that consumers will reference, such as com.amazonaws.vpce.us-east-2 .vpce-svc-0569c51ce317ddfdb.

The consumer will receive multiple endpoint DNS names to allow for a regional name and names for each Availability Zone in which the service operates.

The next step is to allow access to the endpoint. You can whitelist IAM principals such as account or choose to offer the service to all AWS accounts.

AWS PrivateLink Service Consumer Considerations

To consume a VPC endpoint (powered by AWS PrivateLink), you can start by requesting access to a private service with the service name. You may also choose to consume available public endpoints from AWS Marketplace and AWS Cloud services. There may be multiple endpoints available, depending on the service and Availability Zones chosen.

There are multiple ways to reach a VPC endpoint. You may want to enable split-horizon DNS with the private DNS name, available for AWS Cloud services and AWS Marketplace endpoints. Split-horizon DNS configures a private hosted zone with the appropriate DNS entries to map the service name to the created endpoints. This will map a DNS entry such as api.example.com to vpce-svc-0569c51ce217fffdb.us-east-2.vpce.amazonaws.com. You may also choose to do this yourself or use your own DNS solution for your own endpoint services using Amazon Route 53 private hosted zones.

Each VPC endpoint will have both a regional DNS name and a DNS name for each Availability Zone. The consumer has the choice of using the services local to each Availability Zone to increase performance. If DNS is not supported or causes application issues, it is possible to hardcode endpoint IP addresses into applications. Similar to Elastic Load Balancing, you are not charged for traffic crossing Availability Zones.

Security of the VPC endpoint is the consumer’s responsibility. Traffic can only connect from the consumer to the provider. Only responses to connections originating from the consumer are possible.

Accessing a Shared Services VPC

There are multiple scenarios where you may need to access services that are in a different VPC. You can use interface VPC endpoints, for example, to access AWS Cloud services. You can also access services provided by third parties or partners. If your organization has common access requirements across many VPCs, it is helpful to centralize common or shared services. You can use AWS PrivateLink to access privately shared central services, which may be called “Services VPC,” “Shared Services VPC,” “Administrator VPC,” or similar names. These common resources may include authentication, provisioning, or security services.

Figure 3.5 illustrates what a shared services VPC may look like.

In Figure 3.5, there is a dedicated VPC for shared services. There are two instances running in two subnets that are targets for a Network Load Balancer. There is a single service in the shared services VPC in this example, but in practice there could be many other services. The service is shared to three consumer VPCs that have private access to the shared service. Each can use the VPC endpoint DNS name to access the service. This design pattern allows the organization to deploy and operate core services centrally, such as authentication, logging, monitoring, code pipeline tools, and other administrative and security services.

Depending on organizational requirements, there could be multiple “services VPCs,” or they may be segmented further by function such as security, networking, administrative tools, incident response, and more. VPC endpoints offers greater scale and address flexibility than VPC peering. This model scales to thousands of consumer VPCs, and it allows for the consumer VPCs to have overlapping IP addresses. VPC endpoint connectivity originates from consumers toward the provider services. Provider services cannot initiate connections to the consumer resources. VPC peering or other connectivity methods are needed for provider-initiated communication.

Routing Across Peered VPCs

A common pattern to solve transitive routing scenarios is to use instances in each VPC to proxy or forward the traffic by providing a local network interface as the destination for remote networks. Inside a VPC, it is common for route tables to target firewalls, proxies, and caching servers to process or inspect network traffic.

This routing design changes when VPC peering is used. As typically defined in the route table, traffic destined to the remote VPC CIDR range uses the peering connection (pcx-xxxxxxxx) as its target. It is not possible to route traffic to a network interface in the peered VPC.

An example of this behavior would be a firewall in a shared services VPC. If all Internet-bound traffic must pass through the firewall, you would configure subnet route tables to forward Internet-bound traffic to the instance. If the firewall is in another VPC, you cannot configure a route to a network interface over VPC peering. To provide these types of architectures, there is a detailed review with approaches such as the transit VPC in Chapter 16 and other architectures reviewed later in this book. There are also routing options involving cross-account elastic network interfaces that provide a solution in limited scenarios, which is covered later in this chapter.

Resizing a VPC

One of the first design decisions that you must make when creating your VPCs on AWS is the IPv4 CIDR range. There are options for what address type you would like to use, including RFC1918 addresses, public addresses, and other addresses such as RFC6598. We recommend RFC1918 addresses when possible, but there are reasons to use other ranges. The second choice is how large the CIDR range should be.

Historically, AWS has recommended starting with a large CIDR range so that you avoid the work of redesigning connectivity associated with exhausting the available IPv4 addresses. Allocating large blocks of IPv4 addresses to multiple VPCs can be challenging if you are constrained on available IPv4 address space.

The resize VPC feature allows you to add up to five additional IPv4 CIDR ranges to your VPC. You can submit a request to increase the limit higher than five. This feature allows for IPv4 expansion in VPCs that have exhausted their addresses and reduces the design tradeoffs involved with starting with smaller CIDR ranges.

Resizing VPC Considerations

New VPC CIDR ranges cannot overlap with the existing CIDR range or the CIDR range of any current VPC peer. In addition, the new ranges must be more specific than any currently-defined static route in the VPC route tables. Dynamic routes propagated by the VGW do not cause a conflict, and any new CIDR ranges will be automatically preferred because they are local routes. There are also restrictions on which CIDR ranges can be defined, depending on the original CIDR range configured for the VPC.

Figure 3.6 illustrates the changes to the local routing table when you add a new CIDR range. A new local route was added in this case for 10.2.0.0/16. You must have space for additional route entries in your route tables, since new local routes are added. In addition, the VGW will begin advertising the new address range. You can define a new CIDR range ranging from a /16 to a /28. This means that you can effectively create ranges up to a /14 or /15 using individual /16 ranges. Advertisements from the VGW will not summarize contiguous address ranges.

Only new subnets can use the new address space; subnets created before the added CIDR ranges cannot use the new addresses.

IP Address Features

IP addresses are typically simple, but there are a few edge cases which you can control.

Cross-Account Network Interfaces

There are some network scenarios that benefit from extending a networking interface from an instance into another account. The cross-account network permission grants an AWS-authorized provider account permission to attach a customer network interface to an instance in the provider account. The provider account must be whitelisted by AWS to provide this functionality.

An example use case for this feature is Amazon Relational Database Service (Amazon RDS). Customers want to modify and control the elastic network interface of the Amazon RDS instances, but they should not have access to the instance itself. In the Amazon RDS scenario, the instance is in a VPC managed by AWS, and the elastic network interface is in the customer VPC.

This capability also allows customers to define VPC route table entries pointing to the elastic network interface of an instance in another account. This makes the elastic network interface capable of routing to an instance in another VPC or account.