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.