Hacker News new | ask | show | jobs
by brickteacup 1050 days ago
Not to mention the absurd fact that accessing (IPv4) AWS APIs from a private subnet requires paying for either a NAT gateway or an interface endpoint (we got bitten by sending a ton of Kinesis traffic through a NAT gateway once)
4 comments

This is one thing Google Cloud does well - traffic to Google services bypasses NAT gateway, even over IPv4.

I was curious how they do this, so I set up a service on Google Cloud Run that just echo'd the user's public IP address. When curl'd over IPv4, it said I was coming from a unique local (i.e. private) IPv6 address. The private IPv4 address of my server was embedded in the address, along with some other random-looking bits that probably identified my VPC somehow. So they must have been doing some sort of stateless IPv4 to IPv6 translation behind the scenes.

It was a clever solution that takes advantage of the fact that all of Google's API endpoints are dual-stack, even though (at the time) they didn't support IPv6 on customer VMs. The problem AWS currently has is not all of their internal endpoints are dual-stack, so even using IPv6 can't save you from cloud NAT costs when accessing AWS services.

Our network is completely software defined, so we just fake it to the VM and make it look like it's talking right to the service, and do all the routing via magic.
Honestly, I really like that the AWS implementation is not magic. AWS is the only one of the big 3 cloud providers where I can reasonably assume I get what it says on the lid, and that it works with the pieces it advertises working with (whereas other cloud providers tend to be more nebulous in their documentation).

GCP especially takes a lot more trial and error building systems that compose a bunch of different primitives. That the API is awful doesn't help either.

I agree with this, having built large dev platforms on both. GCP in my experience takes 2-5x the engineering effort, to deal with "GCPisms" and the terrible documentation. AWS is simpler and does what it says most of the time.
This is very cool.

Have quite a bit of experience with AWS and Azure, and only recently learning about GCP, it’s very clear that Google nailed Some of GCP’s core cloud engineering concepts and got them exactly right.

Although unfortunately they will never reach the size of AWS or (maybe Azure? It’s hard to tell Azure’s market size as they don’t disclose it.)

I know Google’s load balancers use BGP. So a load balancer will have a single IP address, but you don’t talk directly to that IP. Google’s servers take over as traffic is being routed.
The problem AWS has is the design of VPC internals.

As the first hyperscaler, they gotta pay the legacy tax.

AWS didn't start with "VPC", and people who still had access to the much-easier-to-conceptualize EC2 Classic only got forced off recently; Amazon VPC wasn't actually launched publicly until after Google Cloud.
Another dead simple solution would be if AWS would provide us a simple subdomain (such as myapp.xxxx.aws-hosting.com), no need to meddle with IPs at all in that case. Google Cloud already does this with xyz.appspot.com subdomains, same with Github Pages as they provide you xyz.github.io subdomain for your app.
I wonder if someone at AWS noticed that the interface endpoint pricing was offensive for accessing S3 and therefore created the free “VPC Endpoint for Amazon S3.”

I would find it rather surprising if the actual cost to Amazon of connecting a VPC to S3 were substantially lower than the cost of connecting a VPC to any other AWS service.

Yeah, the endpoints bother me. I get charging for IPv4 space but they shouldn’t charge you for calling their APIs, especially since it’s one ENI per endpoint so I have a few VPCs which have half the allocated addresses used by endpoints (the old trade off between multi AZ reliability and the cost of allocating redundancy).