Six months ago I left the following comment about this.

> I miss EC2 Classic :/. It always feels like the entire world of VPCs must have come from the armies of network engineers who felt like if the world didn't support all of the complexity they had designed to fix a problem EC2 no longer had--the tyranny of cables and hubs and devices acting as routers--that maybe they would be out of a job or something, and so rather than design hierarchical security groups Amazon just brought back in every feature of network administration I had been happily prepared to never have to think about ever[] again :(.

There were some responses:

https://news.ycombinator.com/item?id=25988915

Honestly and likely overly-frankly, I have absolutely nothing positive to say about VPC or any of the engineers who worked on or with it: it seems like it is uninspired and creates complexity out of whole cloth with absolutely no benefits I have ever heard of to redeem its existence. For a long time, instances could not have multiple security groups, which limited the mechanism... but that was fixed long ago; security groups should simply have been made hierarchical instead of forcing everyone to think about network layout and address space limitations as part of manually laid-out networking in what should be a purely cloud resource capable of infinite extension... all of that networking equipment and subnet numbering exists in the real world to solve problems virtual hardware does not and should not have. EC2 Classic was "fun" to work with and yet had no limits... VPC is "work" and offers nothing in return.

Creating completely private networks in a public cloud, and also being able to link these networks across the WAN to other private networks in different regions seems the opposite of nothing to offer IMO.

This is a common error of conflating the name of something with a property that that name typically has.

The "RFC 1918 private range" is "private".

A publicly routeable range that is firewalled off is "private".

There is no practical difference in the level of privacy. There's a difference in naming only.

And of course, there is one other difference: The RFC1918 range is worse, because it can never be routed. You have no choice in the matter, it's not an option.

So you have two kinds of "private networking":

- Private by choice.

- Private with no choice.

Which do you prefer? To have choices, or to have those choices taken away from you?

The default VPC setup in each region just has a two public subnet configuration by default. You boot up an EC2 instance and it has a public IP address reachable from the internet (if you open up the security group) and a private IP address.

If you want a totally private subnet to put your back end app servers on so they are not routable from the world as an extra layer of safety, then you can do that too. Or, if you'd like to boot up EC2 instances with only non-routable IP addresses for security, yet be able to have the instances reach out to the world, you can create private subnets and then route the traffic out of NAT Gateways.

VPC's offer the best of both worlds, rather easily too once you wrap your head around how all of the VPC objects and software defined networking work.

> [...] route the traffic out of NAT Gateways.

Which is AWS's way of printing money. Straight up, no lie.

Instead with the advent of IPv6 and everything getting a publicly routable IP address anyway, you no longer can rely on a machine having a "private" IP address.

I recently stood up infrastructure where each machine in the VPC got a public IPv4 and IPv6, and used security groups to set up permissions for what systems can access what other systems.

This way I protect the instances, and don't pay the NAT Gateway fee because the public IP is a 1:1 NAT and doesn't cost anything.

You don't need nat gateways and I suspect most folks don't use them or are even aware they exist. The default setup gives you hosts with public ips directly reachable over the public internet, and no nat gateways or fees required.

It's not really any safer though. If I want to say that server A and B can connect to each other and connect out to the outside world, and the outside world can connect in to A but not to B, I should be able to just do that, without having to give each server multiple addresses. Addressing should be decoupled from access control.

AWS security groups allow rules to either be IP CIDR based or you can have rules that refer to other security groups, ignoring the IP addresses.

Every time you write “subnet” you’re affirming saurik’s original post about the (needless) complexity of network hardware administration being brought to the cloud.

Just because the network is virtual and in a data center you don't own doesn't mean standard networking principals go out the window, you still have to setup the network as you see fit.

Maybe folks are just annoyed at the complexity and want something more plug and play which is understandable. The default vpc usually is fine enough for most everyone out of the box.

Wherever compliance is concerned, I prefer private with no choice.

I too prefer to paint myself into corners irreversibly for the benefit of auditors with no technical understanding and no skin in the game.

A company where I used to work still had those as of early 2020. The reason was technical debt, system being treated as a "black box" since the people who built it left many years ago, etc.

In addition, that product didn't exactly make big bucks for the company so there was not much incentive to improve things.

Hi, we have some customers left running things on our EC2 classic shard at Heroku. Mostly related to having dependence on customers doing things to migrate them cleanly.

How is that dependent on your customers – doesn't Heroku, like, fully abstract the EC2 backend so that the Heroku customer doesn't even have to know it's on EC2?

We have an ssl endpoint product that’s stuck in classic And requires our customers to make a DNS change to fix/migrate.

Small company, legacy systems, priorities lie elsewhere. That's pretty much it.