Routing network traffic between data centers over the internet? Web services within a data center interacting with traffic passing through the public internet – just to save a couple of hours or days of work? Both have been frowned upon for years, but such shortcuts are the new normal in the cloud world. So, are VPC Endpoints in AWS a solution?

Understanding the Use Case

In the following, we look at a solution relying on AWS S3, Lambda, and Dynamo DB services. The architecture in Figure 1 consists of an application running on an EC2 instance (i.e., a VM) alpha5 in subnet SN714. It accesses a lambda function lf6c, an S3 object storage s3delta and an AWS Dynamo database dy_epsilon (Figure 1). By default, lf_gamma, s3delta , and dy_epsilon are reachable publicly web services. As such, they are accessible from the internet. Traffic to and from them leaves the subnet and VPC and goes via the public internet to the AWS service endpoints / URLs for the S3 and Lambda services. To end this, VPC Endpoints in AWS are an option to keep this network traffic private. It is a scenario in which the EC2 instance acts as a service customer, whereas AWS acts as a service provider.

VPC Endpoints and Interfaces

VPC Endpoints come in different flavors. We look first at how they allow integration of AWS services, thereby avoiding traffic via the internet (Figure 2, A). For such scenarios, AWS offers two VPC Endpoint variants: gateway endpoints and interface endpoints (Figure 2, B).  

Gateway endpoints and interface endpoints achieve their aims differently:

• An interface endpoint means the AWS service gets a local IP address within the subnet. So, it looks (and can be reached, e.g., by EC2 instances) as any EC2 instance in this subnet.
• A gateway endpoint allows routing traffic within the AWS network from the subnet to the AWS endpoint with the help of a routing table.

Figure 2 illustrates the creation of a gateway endpoint (B), which requires selecting the VPC into which the gateway should be deployed (C) and the routing table (D), which ensures that the relevant traffic goes to the S3 endpoint just created. Usually, engineers do not have to worry about which option to choose because not many AWS services support gateway endpoints; most have (only) interface endpoints. The following Table 1 provides an overview.

Service	Interface Endpoint	Gateway Endpoint
S3	Available	Available
Dynamo DB	Not available	Available
Lambda	Available	Not available
Cassandra	Available	Not available
Sage Maker Studio	Available	Not available
Redshift	Available	Not available

By default, a VPC Endpoint allows traffic from everyone within the VPC to the resource. So, every user and application with access to the VPC can reach the VPC Endpoint (and the resource behind the VPC Endpoint) on the network layer. The access rights in the IAM solution can still prevent reading or writing the data. However, it is usually better to rely not only on one security mechanism – IAM – but on two, IAM and network security – and VPC Endpoints can be a solution for the latter.

The other way around …

We have now looked at how to access AWS services from your VPC securely. The scenario: an application on an EC2 instance that accesses AWS services such as Dynamo DB or Lambda Functions. But what about a scenario where an AWS Lambda function orchestrates a couple of legacy (micro-)services of applications running on EC2 instances? How can the AWS Lambda function invoke them without going through the internet and making the EC2 instance accessible from the internet

Specifically for Lambda Functions, AWS provides a solution. Engineers can “connect” AWS Lambda Functions with VPCs. Then, the Lambda Function accesses resources exactly like an EC2 instance in the VPC.

Without going into details, this aspect illustrates the importance of understanding the different scenarios of how applications and AWS services interact to implement a security posture – especially since not every AWS service might have such an elegant solution. The challenge grows further if you not only combine IaaS-workloads on EC2 with PaaS features like Dynamo DB and Lambda Function but if you also consider Web Services from external partners, customers, or suppliers.

AWS’s Ecosystem Spirit

The most frustrating experience when integrating software-as-a-service solutions into your company application landscape is how negligent software vendors are when it comes to securing the integration of their solution into company ecosystems. Thus, I was surprised when I looked at AWS’s VPC Endpoint concept. I was fascinated by two aspects:

• VPC Endpoints work not only for AWS-provided cloud-native services. You can also connect to VPC Endpoints of AWS Marketplace vendors – or any other AWS tenant. That helps integrate services hosted by vendors on the AWS cloud (Figure 4, left).
• Suppose you are a service provider. Your customers might expect from you the same level of security as AWS’s service. The good news is that everybody on AWS can provide VPC Endpoints. So, suppose you are a service provider. You can provide your services precisely with the same security mechanisms as AWS (Figure 4, right).

Do VPC Endpoints make a Difference?

VPC endpoints are like seat belts – if you use them, they reduce your risks. External attackers have a much smaller attack surface if you shield your interfaces, data, and service instances from the internet. No traffic via the internet makes interference with your traffic impossible. Suppose every (micro-)service and every S3 instance has internet connectivity because all invocations from your EC2 instances go via the internet. In such a case, every single IAM misconfiguration can cause a disaster. So, VPC Endpoints are a great innovation, such as seat belts. However, they are not the complete solution, especially since PaaS services are shaking corporate IT departments. Cloud-native PaaS services such as database-as-a-service (e.g., Dynamo DB) or middleware-as-a-services (e.g., AWS EventBrdige) change how IT organizations develop and operate applications. Database and middleware teams shrink or even disappear. The reason: application teams can use Dynamo DB or EventBridge without company-internal support. You click a button and get an instance – and always patched. Suddenly, hundreds of engineers create database instances, not frequently but maybe every quarter or so. Ensuring all configurations are correct becomes a nightmare. In this sense, VPC Endpoints can prevent exposing databases to the internet. However, they do not make detective and preventive controls obsolete. The challenge is the consistent, 100% correct usage and configuration of AWS components and VPC Endpoints by potentially hundreds of engineers in an IT department. The rule for such scenarios is sim