How would your EC2 in private VPC subnet talk to an AWS managed services like S3 or DynamoDB?
Imagine you have an application running inside an EC2 instance which is inside a private subnet. Then how can it communicate with a managed service like S3?
It is technically not possible because resources inside private subnet can not talk to resources outside of its VPC and managed services can not be enclosed inside VPCs because they are managed services.
One typical way is to use NAT resources inside a public subnet with Internet Gateway. But that is not entirely private communication right?
This is where VPC endpoints come into pictures. VPC endpoints lets you communicate with AWS managed services bypassing public internet routing.
Wait but how?
Two ways.
- Gateway Endpoint
- Interface Endpoint
Gateway Endpoint
As we have discussed that a resource inside a private VPC subnet can not communicate with any resources outside of the VPC. And it is not possible to place an AWS managed service inside a user managed VPC. Therefore the communication between a private subnet resource and managed service becomes impossible.
But we are forgetting one thing here and that is, this separation is entirely logical not physical.
Meaning both the EC2 and the S3 resources are physically inside AWS infrastructure, therefore there can be a physical reachability between them, but just they are logically isolated.
Therefore we can play a simple trick and that is we can create a routing rule inside the route table of the private VPC subnet which leads to an interface directly connected to S3 for its public IP as destination.
Meaning when the EC2 will try to communicate with the public IP address of the S3 bucket, it will check the route table and the route table will point to a target resource which is directly connected to S3.
The gateway endpoint is free.
In simple terms EC2 -> route table -> S3 bucket.
Interface Endpoint
In gateway endpoint, there needs to be a routing rule for the destination public IP of S3 that leads to the resource.
But in interface endpoint, we create a resource that is inside the VPC and directly connected to the S3. Since this is inside the VPC, therefore resources inside the VPC can reach it directly without relying on the route table entries.
But the problem is now since we are creating and managing a new private resource there adds up a cost
Use-cases
Talking to AWS managed services from AWS resources
When we use gateway endpoints, we basically utilize the fact that both the source and destination are inside AWS infrastructure, just logically isolated. Therefore we add a logical rule inside the VPC route table that allows resources inside private VPC subnet to reach managed services outside of the VPC.
Therefore when the source itself is also an AWS resource then we should use gateway endpoint since the gateway endpoint is free.
Talking to AWS managed services from on-premise infrastructure.
We can use gateway endpoints to establish communication between private AWS resource and AWS managed resources because they both are inside the AWS infrastructure as we have discussed. But the same strategy can not be applied for on-premise infrastructure because on-premise infrastructure resources are physically separated from the AWS managed resources.
Therefore we can connect on-premise infrastructure resources to a VPC via direct connect or site-to-site VPN and once it is connected to the VPC, it can reach to any resources inside the VPC and thus it can also reach to an interface endpoint that leads to AWS managed resources
Conclusion
Private resources can use VPC endpoints to talk to AWS managed services without routing through the public internet
There can be two types of VPC endpoints: Gateway Endpoint and Interface Endpoint
Gateway Endpoint is free, Interface endpoint is not
Private resources inside AWS can use gateway endpoint but on-premise private resources need interface endpoint.
Top comments (0)