Secure access to services and applications in AWS whilst reducing risk 

“The network is hostile: The network should be treated as compromised and therefore hostile, this means you need to remove trust from the network” NCSC Zero Trust introduction. 

Providing access to your APIs or SaaS solution might be an easy task. However, attempts at making it secure, reliable, and scalable could increase the complexity and operational overhead if not done correctly. 

VPC Peering is an anti-pattern for exposing your services due to the following: 

• Overlapping VPC CIDRs can’t be guaranteed if you’re providing a service to clients outside your organisation. 
• Can’t easily protect other resources within your VPC, this requires configuration of routing tables, security groups and network access controls (NACls). 
• Doesn’t scale easily, you will need to configure VPC Peering, SGs, RTs, NACLs for every new client being onboarded/offboarded. 
• Doesn’t configure DNS for the client side. 
• You can't enable flow logs for VPCs that are peered with your VPC unless the peer VPC is in your account, due to flow log limitations.  

The only advantage that VPC Peering has over AWS VPC Endpoint Service (PrivateLink) is the fact that the former works between different regions while PrivateLink is limited to the same region only (at the time of writing this article).  


AWS PrivateLink routes the network traffic between the two VPCs without the need for firewall rules, routing tables or Internet gateway. All network traffic between the two VPCs travels through the AWS Network. This not only simplifies the management of the network but also eliminates the risk of brute force and distributed denial of dervice (DDoS) attacks by limiting the attack surface. 

How AWS PrivateLink differs from other cloud service providers’ solutions? 

The combination of AWS VPC Endpoint Service and Route53 beats Azure Private Link and GCP Private Service Connect when using a publicly verifiable domain. AWS PrivateLink integrates with Route53 on both the Endpoint Service side (Service Provider) and the Endpoint side (consumer) such that a verifiable domain can be configured as part of the Endpoint Service for the customer to access once the endpoint has been approved. 

AWS Intercepts the DNS requests on the consumer side and resolves them to the IP addresses of the Elastic Network Interfaces (ENIs) injected by the endpoint into the subnets. This DNS resolution requires zero configuration on the consumer’s Route53, once enabled. It happens automatically once the provider approves the connection, and the consumer enables private DNS. 

The DNS resolution is static, meaning that it won’t resolve to any overlapping public DNS records or private DNS record in the consumer’s private hosted zone, if manually created - making it virtually unbreakable. 

Furthermore, using a wildcard domain and TLS Cert (if required) with PrivateLink is supported. This means that you can setup the Network Load Balancer with a wildcard certificate and the endpoint service with the wildcard domain which would allow you to provide access to your service using a different subdomain via the endpoints to the consumer. The use of private DNS will only work if the consumer’s VPC has both `Enable DNS Support` and `Enable DNS Hostnames` configured. Understandably, the use of Wildcard certificates might not be permitted in certain highly regulated organisations. 

As always, the configuration of these components should be done using Infrastructure as Code. There is, however, a limitation currently with AWS PrivateLink and PrivateDNS in that the customer needs to enable the PrivateDNS option after gaining the approval for the PrivateLink connection on the service provider side, it can’t be enabled during initial setup if the Endpoint service is configured to require approval.  

This can be automated using a simple Lambda function to monitor for the approval of the connection and enables PrivateDNS option on the Endpoint. 

 

AWS KMS Threat Model Read more