Attach the virtual private gateway the newly created amazon vpc

Thispaperhas beenarchived

Customers are responsible for making their own independent assessment of the
information in this document. This document: (a) is for informational purposes only, (b) represents current AWS product offerings and practices, which are subject to change without notice, and (c) does not create any commitments or assurances from AWS and its

affiliates, suppliers or licensors. AWS products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.

Whitepapers &Guidespage:

https://aws.amazon.com/whitepapers

Securely Access Services Over AWS PrivateLink

Introduction .......................................................................................................................... 5 What Is AWS PrivateLink? ............................................................................................... 6 Why use AWS PrivateLink? ............................................................................................. 6 What are VPC Endpoints? .................................................................................................. 7 Interface endpoints........................................................................................................... 8 Gateway endpoints .......................................................................................................... 8 How does AWS PrivateLink work? ..................................................................................... 9 Creating Highly-Available Endpoint Services ................................................................... 10 Endpoint-Specific Regional DNS Hostname ................................................................. 10 Zonal-specific DNS Hostname ...................................................................................... 11 Private DNS Hostname .................................................................................................. 11 Private IP Address of the Endpoint Network Interface ................................................. 11 Deploying AWS PrivateLink .............................................................................................. 12 AWS PrivateLink Considerations................................................................................... 12 AWS PrivateLink Configuration ..................................................................................... 15 Use-Case Examples .......................................................................................................... 15 Private Access to SaaS Applications ............................................................................ 15 Shared Services ............................................................................................................. 16 Hybrid Services .............................................................................................................. 18 Presenting Microservices ............................................................................................... 19 Inter-Region Endpoint Services ..................................................................................... 21 Inter-Region Access to Endpoint Services .................................................................... 23 Conclusion ......................................................................................................................... 24 Contributors ....................................................................................................................... 24 Further Reading ................................................................................................................. 25 Document Revisions ......................................................................................................... 25

Securely Access Services Over AWS PrivateLink

Amazon Virtual Private Cloud (Amazon VPC) gives AWS customers the ability to define a virtual private network within the AWS Cloud. Customers can build services securely within an Amazon VPC and provide access to these services internally and externally using traditional methods such as an internet gateway, VPC peering, network address translation (NAT), a virtual private network (VPN), and AWS Direct Connect. This whitepaper presents how AWS PrivateLink keeps network traffic private and allows connectivity from Amazon VPCs to services and data hosted on AWS in a secure and scalable manner.

Amazon Web Services Securely Access Services Over AWS PrivateLink

Figure 1: Traditional access from an Amazon VPC

AWS PrivateLink provides secure, private connectivity between Amazon VPCs, AWS services, and on-premises applications on the AWS network. As a result, customers can simply and securely access services on AWS using Amazon’s private network, powering connectivity to AWS services through interface Amazon VPC endpoints. Refer to Figure 2 for Amazon VPC-to-VPC connectivity using AWS PrivateLink.

Figure 2: Amazon VPC-to-VPC connectivity with AWS PrivateLink

6

Simplify Network Management

AWS PrivateLink helps avoid both (1) security policies that limit benefits of internet gateways and (2) complex networking across a large number of Amazon VPCs. AWS PrivateLink is easy to use and manage because it removes the need to whitelist public IPs and manage internet connectivity with internet gateways, NAT gateways, or firewall proxies.

What are VPC Endpoints?

A VPC endpoint enables customers to privately connect to supported AWS services and VPC endpoint services powered by AWS PrivateLink. Amazon VPC instances do not require public IP addresses to communicate with resources of the service. Traffic between an Amazon VPC and a service does not leave the Amazon network.

VPC endpoints are virtual devices. They are horizontally scaled, redundant, and highly available Amazon VPC components that allow communication between instances in an Amazon VPC and services without imposing availability risks or bandwidth constraints on network traffic. There are two types of VPC endpoints: (1) interface endpoints and (2) gateway endpoints.

Interface endpoints

More information about gateway endpoints is in the

Instances in an Amazon VPC do not require public IP addresses to communicate with VPC endpoints, as interface endpoints use local IP addresses within the consumer Amazon VPC. Gateway endpoints are destinations that are reachable from within an Amazon VPC through prefix-lists within the Amazon VPC’s route table. Refer to Figure 3 showing connectivity to AWS services using VPC endpoints.

How does AWS PrivateLink work?

Amazon Web Services Securely Access Services Over AWS PrivateLink

Figure 4: Detailed Amazon VPC-to-VPC connectivity with AWS PrivateLink

When an interface endpoint is created, endpoint-specific Domain Name System (DNS) hostnames are generated that can be used to communicate with the service. After creating the endpoint, requests can be submitted to the provider’s service through one of the following methods:

Amazon Web Services Securely Access Services Over AWS PrivateLink

endpoint identifier, service identifier, the region, and vpce.amazonaws.com in its name;

vpce-0fe5b17a0707d6abc-29p5708s-us-east-1a.ec2.us-east-

1.vpce.amazonaws.co

The private IP address of the endpoint network interface in the VPC is directly reachable to access the service in and across Availability Zones, in the same way the zonal-specific DNS hostname is.

Service providers that use zonal DNS hostnames to access the service can help achieve high availability by enabling cross-zone load balancing. Cross-zone load balancing enables the load balancer to distribute traffic across the registered targets in all enabled Availability Zones. Regional data transfer charges may apply to a service provider’s account when they enable cross-zone load balancing, as data could potentially transfer between Availability Zones.

endpoint. The DNS name resolution of the Endpoint Specific Regional DNS Hostname

will alternate between the two IP addresses.

When deploying an endpoint, customers should consider the following:

12

•Proxy Protocol v2 can be enabled on the load balancer and the client IP
addresses can be obtained from the Proxy Protocol header when IP addresses of the service consumers and their corresponding interface endpoint IDs are needed.

•Customers can create an Amazon Simple Notification Service (SNS) to receive alerts for specific events that occur on the endpoints that are attached or when they attempt to attach to their endpoint service. For example, one can receive an email when an endpoint request is accepted or rejected for the endpoint service.

Amazon Web Services

{

•Endpoint services cannot be tagged.

Thispaperhas beenarchived
•The private DNS of the end.

•Availability Zone names in a customer account might not map to the same locations as Availability Zone names in another account. For example, the Availability Zone US-EAST-1A might not be the same Availability Zone as US- EAST-1A for another account. An endpoint service gets configured in Availability Zones according to their mapping in a customer’s account.

•For low latency and fault tolerance, we recommend creating a Network Load Balancer with targets in each available Availability Zone of the AWS Region.

ure AWS PrivateLink can be found from the

Use-Case Examples

Follow the best practice of creating an AWS PrivateLink endpoint in each Availability Zone within the region that the service is deployed into. This provides a highly available and low-latency experience for service consumers.

Service consumers who are not already on AWS and want to access a SaaS service hosted on AWS can utilize AWS Direct Connect for private connectivity to the service provider. Customers can use an AWS Direct Connect connection to access service provider services hosted in AWS.

Amazon Web Services Securely Access Services Over AWS PrivateLink

interface VPC endpoint in their Amazon VPC and not over public facing AWS endpoints. See the following figure for an illustration.

16

A service consumer is the actor consuming the AWS PrivateLink endpoint service from the service provider. When a service consumer has been granted permission to consume the endpoint service, they create an interface endpoint in their VPC that connects to the endpoint service from the Shared Services VPC. As an architectural best practice to achieve low latency and high availability, we recommend creating an Interface VPC endpoint in each available Availability Zones supported by the endpoint service. Service consumer VPC instances can use a VPC’s available endpoints to access the endpoint service via one of the following ways: (1) the private endpoint- specific DNS hostnames that are generated for the interface VPC endpoints or (2) the Interface VPC endpoint’s IP addresses.

On-premises resources can also access AWS PrivateLink endpoint services over AWS Direct Connect. Create an Amazon VPC with up to 20 interface VPC endpoints and associate with the endpoint services from the Shared Services VPC. Terminate the

Figure 7: Shared Services VPC using AWS PrivateLink

Hybrid Services

Amazon Web Services Securely Access Services Over AWS PrivateLink

AWS PrivateLink is well suited for a microservices environment. Customers can give teams who own a particular service an Amazon VPC to develop and deploy their service in. Once they are ready to deploy the service for consumption by other services, they can create an endpoint service. For example, endpoint service may consist of a Network Load Balancer that can target Amazon Elastic Compute Cloud (Amazon EC2)

19

The architecture in Figure 9 shows microservices which are segmented into different Amazon VPCs, and potentially different service providers. Each of the consumers who have been granted access to the endpoint services would simply create interface VPC endpoints associated with the given endpoint service in their Amazon VPC for each of the microservices it wishes to consume. The service consumers will communicate with the AWS PrivateLink endpoints via endpoint-specific DNS hostnames that are generated when the endpoints are created in the Amazon VPCs of the service consumer.

The nature of a microservice is to have a call stack of various microservices throughout the lifecycle of a request. What is illustrated as a service consumer in Figure 9 can also become a service provider. The service consumer can aggregate what it needs from the services it consumed and present itself as a higher-level microservice.

Securely Access Services Over AWS PrivateLink

Figure 9: Presenting Microservices via AWS PrivateLink

21

Figure 10: Inter-Region Endpoint Services

As customers expand their global footprint by deploying workloads in multiple AWS regions across the globe, they will need to ensure that the services that depend on AWS PrivateLink endpoint services have connectivity from the region they are hosted in. Customers can leverage Inter-Region VPC Peering to enable services in another region to communicate with interface VPC endpoint terminating the endpoint service which directs traffic to the AWS PrivateLink endpoint service hosted in the remote region.

Inter-Region VPC Peering traffic is transported over Amazon’s network and ensures that your services communicate privately to the AWS PrivateLink endpoint service in the remote Region.

Securely Access Services Over AWS PrivateLink

Contributors to this document include:

•Ahsan Ali, Global Accounts Solutions Architect, Amazon Web Services

Amazon Web Services Securely Access Services Over AWS PrivateLink

•Ikenna Izugbokwe, Senior Solutions Architect, Amazon Web Services •Matt Lehwess, Principal Solutions Architect, Amazon Web Services •Tom Clavel, Senior Product Marketing Manager, Amazon Web Services •Puneet Konghot, Senior Product Manager, Amazon Web Services

June 3, 2021 Updates

November 2020Updates to Figures 6, 7, and 8 for clarity

January 2019		25