Hacker News new | ask | show | jobs
by kbolino 300 days ago
The problem is that VPC endpoints aren't free.

They should be, of course, at least when the destination is an AWS service in the same region.

[edit: I'm speaking about interface endpoints, but S3 and DynamoDB can use gateway endpoints, which are free to the same region]

2 comments

Gateway endpoints are free. Network endpoints (which are basically AWS-managed ENIs that can tunnel through VPC boundaries) are not free.

S3 can use either, and we recommend establishing VPC Gateway endpoints by default whenever you need S3 access.

(Disclaimer: I work for AWS, opinions are my own.)

That's fascinating! I hadn't found that in the documentation; everything seems to steer people towards PrivateLink, not gateway endpoints.

Would you recommend using VPC Gateway even on a public VPC that has an Internet gateway (note: not a NAT gateway)? Or only on a private VPC or one with a NAT gateway?

I recommend S3 Gateways for all VPCs that need to access S3, even those that already have routes to the Internet. Plus they eliminate the need for NAT Gateway traversal for requests that originate from private subnets.
> I recommend S3 Gateways for all VPCs that need to access S3, even those that already have routes to the Internet.

Fascinating. What's the advantage of doing that?

It's a much more direct/efficient connection from the EC2 instance to the S3 storage servers through the virtual network layer. It reduces the network path/length through the AWS network _and_ removes the number of virtual network functions/servers (ala "LB") that your connections will traverse.
That's helpful to know, thank you! I'll take a look at that and see if it improves S3 performance.
> everything seems to steer people towards PrivateLink, not gateway endpoints

Gateway endpoints only work for some things.

Privatelink endpoints can be of type gateway or interface. Only gateway is free and only S3 and dynamodb supports it.
Fair point, and valid for S3 (the topic at hand) and DynamoDB.

Other AWS services, though, don't support gateway endpoints.

https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-e...

~~I get the impression there are several others, too, but that one is of especial interest to me~~ Wowzers, they really are much better now:

  aws --region us-east-1 ec2 describe-vpc-endpoint-services | jq '.ServiceNames|length'
  459
If you're saying "other services should offer VPC Endpoints," I am 100% on-board. One should never have to traverse the Internet to contact any AWS control plane
Those are VPC endpoints, not gateway endpoints.
Both interface endpoints and gateway endpoints are also called VPC endpoints. The former get distinct IP addresses in your VPC subnets while the latter get distinct entries in your VPC routing tables. They are even created with the same API call: https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_C...
Well yeah that's the point....why route through the public internet.
I doubt the traffic ever actually leaves AWS. Assuming it does make it all the way out to their edge routers, the destination ASN will still be one of their own. Not that the pricing will reflect this, of course.

The other problem with (interface) VPC endpoints is that they eat up IP addresses. Every service/region permutation needs a separate IP address drawn from your subnets. Immaterial if you're using IPv6, but can be quite limiting if you're using IPv4.

Sounds like a good reason to use IPv6.
There were still a couple of services/features that choked on IPv6 last time I looked (1.5-2 years ago) but it works with most things and they do seem to be making progress on the others.
I don’t know any software that doesn’t work with IPv6 as of 2021.

Just some internet services that haven’t upgraded. (But fixed by NAT.)

There's a matrix provided by Amazon themselves listing the level of IPv6 support in their various services: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su...