Using a Secure Connection to private resources in AWS

Imagine you have some network resources you want to expose to your clients such as an HTTP API endpoint or more complex services or protocols. The obvious way to do this is to create a service and expose it to the outside world. But what if your clients have some strict requirements on how they can access your service? For example, they may not be able to access the public internet and require all connections to go through private or internal networks. In this post, I’ll explore some of the available options to implement this.

PrivateLink

AWS PrivateLink is a service that allows you to expose your AWS resources to your clients over private networks using a network load balancer. You create a network load balancer in your VPC which acts as the entry point for your clients and grant permissions to specific AWS accounts, IAM users, or IAM roles to access your service. The clients can then access your service from their private network.

Pay attention to the AWS PrivateLink Considerations and Prerequsites, the main points to take into account are as follows:

• Only TCP traffic is supported via a network load balancer. For more advanced communication requirements please see other options in this post.
• The endpoint service will only be available to clients in the region where you created it and for the configured subnet availability zones.
• Pricing for this service is per hour of interface endpoint being active and for GB processed. Pricing is different depending on region (you can see AWS PrivateLink pricing for details).
• There are some limitations regarding the number of endpoints per VPC/region,though  they can be increased up to a limit. There are also some limits regarding network bandwidth (again, see AWS PrivateLink quotas for details).

If you decide that AWS PrivateLink is the right option for you, the high-level process for sharing your service with clients using AWS PrivateLink is relatively simple:

• Create a network load balancer (or use an existing load balancer) for your service.
• Create a VPC endpoint service and connect it to your network load balancer.
• Grant permissions to your endpoint service for relevant AWS Accounts/IAM users/IAM roles.
• Provide your clients with the name of your service and the supported availability zones.
• Clients create VPC interface endpoints to connect to your endpoint service.
• Approve the connection request from your clients to your endpoint service.

VPC peering

VPC peering is a service that allows you to connect two AWS VPCs together and route traffic between them using private IP addresses. This connection is private, encrypted and isolated from the rest of the internet. This is a very good alternative in case AWS Private Link is not an option for you, however there are some very restrictive limitations for VPC peering which are worth exploring before considering this option:

• There are some hard quotas on the number of active or pending peering connections  ( you can see VPC Peering Connection Quotas for details).
• You cannot connect to or query the Amazon DNS server in a peer VPC.
• Unicast reverse path forwarding in VPC peering connections is not supported.
• You cannot create a VPC peering connection between VPCs that have matching or overlapping IP CIDR blocks, even if you only intend to use only non-overlapping CIDR blocks for the peering connection.
• See VPC Peering limitations for more details

If you decide to use VPC peering, the implementation is very simple and the high-level process is as follows:

• The owner of one side of the VPC peering connections sends a request to the other side to initiate a peering connection. The other side accepts this connection and the VPC peering connection is then active.
• Each side of the VPC peering connection needs to add a route to one or more of their VPC route tables to route to the IP address range of the other VPC.
• Each side should update their security group rules to ensure that traffic to and from the peer VPC is not restricted. If both VPCs are in the same region, you can reference a security group from the peer VPC.

Combining VPC peering with AWS PrivateLink

This might be a good option if you as a service provider want to expose your service to your clients using a simple AWS PrivateLink configuration, thus exposing it to a dedicated VPC. Your clients can then configure (or you can configure for them) a VPC peering connection which will allow them to access your service using some more complex routing configuration or security requirements on their side. Another advantage is that this can allow using cross-region access to your service from multiple regions where it may not be available via your AWS PrivateLink service endpoints.

AWS Transit Gateway

AWS Transit Gateway is the nuclear option. It’s a much more complex (and expensive) service to configure and manage compared to the previous options, but it allows much more configuration options and has fewer limitations. Transit Gateway allows connecting multiple AWS VPCs or on-premises networks together and route traffic between them using a private, encrypted and isolated connection. This is a very complex service with many configuration

options, so I won’t go into details here as the specific configuration is highly dependent on the specific requirements. For more details, see the AWS Transit Gateway documentation. Following are some example use cases where AWS Transit Gateway might be useful:

• Overcome some limitations of VPC Peering by attaching VPCs to the transit gateway.
• Support strict security requirements which may not be available using VPC Peering.
• Use AWS Direct Connect to connect directly over a standard Ethernet fiber-optic cable.
• Use AWS Site-to-Site VPN to connect to an on-premises network.

Summary

In this post, I explored some options available to expose your service to clients or provide a secure connection between private networks. Following table summarizes the options and when you should use each one: