Hacker News Reader

Comment by jwlake | Hacker News Reader

I run quite a few small production aws accounts for clients and this is a big increase to their bill. If you use a lot of t4g.nano instances, the IPs are more than the machines. I think the large customers that are 99% of the revenue won't care, but the bottom 50% of customers will notice.

View on HN

Most customers will have very few public IPs. If your architecture is based around dozens (or even more) of public IPv4 addresses then you need to rethink your design because cost isn’t the only risk you’re exposing.

I am pretty sure that the default VPC assigns public IPs (and a default route to the IGW) so if you grew organically without some kind of plan I can see many startups having tons of ephemeral addresses or EIPs.

Also I just did a cleanup recently myself of this and migrated an account to a hub/spoke security VPC with transit gateway. AWS makes it real pain for running instances to migrate to private IP only. You have to play games with adding a second NIC/EIP to workaround this.

AWS really need to deprecate the default VPC. Experienced engineers know to avoid it and novices are encouraged to design things badly because of it.

There should be a “wizard” type walkthrough to guide novices through creating their first VPC (they’d generally be managing AWS via “clickops” so a wizard type UI would work here).

You should try the latest VPC creation wizard. It collects all the required information and then creates what you need.

The biggest complaint I have with it is that it doesn’t write ID values to well known SSM parameters within the region.

I disagree. AWS should make it easier to just use routed IPv6, which makes the default VPC much more usable.

And then just use one of the zero-trust overlays to secure communications between nodes.

Hahahaha, you are giving the average AWS customer way too much credit.

Now that you mention this, it's interesting for me to consider in retrospect. At least one prior employer had me architect solutions that were designed around scaling up using very small instances in large numbers during peak load.

In theory those are deployed in the private address space behind a load balancer, but getting any actual information on the production deployment was like pulling teeth.

I've seen a similar setup ~12 years ago: a very elastic setup on AWS following load changes.

At peak times, the clusters had substantially more than 1k API instances running together; none of the the API instances ever had a public address, and not for cost reasons.

Everything was on EC2, behind a bastion; you had to jump through two jump hosts to SSH to particular boxes (containers were not a thing yet). Everything ran on private networks. Everything was exposed through load balancers (HAProxy) via 2 or 3 public IPv4 addresses; I think one of them was only to interact with an off-AWS third-party service over the public internet.

Yes, it was a startup, just very technically-minded.

Reply on news.ycombinator.com