[alex-mohr]

> if the goal was to simplify things, then I'm not sure how successful they were at that.

Maybe if they have other goals that are tradeoffs vs. simplicity, then it's more understandable?

What if another goal is allowing enterprise customers to recreate a virtual enterprise network? Or a virtual data center network? Those are much more complex than a client TCP stack.

The defaults are simple for simple uses. And yes, for those complex cases, you'd need AWS specific product knowledge, but most of the underlying concepts are shared in common with other clouds and on prem networks. Like learning your Nth programming language.

[saurik]

AWS used to be not only sane but elegant: every instance had an entirely-arbitrary internal/private IP address, some could optionally have a second public address, and which instances (including external IP addresses) could talk to which other instances was entirely and solely defined by security groups (as well as, of course, any OS-level firewalls that you'd generally disable), which were pretty much just flexible and reusable firewall rules where the concept of a "security group" replaced entirely the concept of a "subnet", which became an obsolete legacy concept.

They needed to support multiple adapters per instance, which they later added (maybe with a separate security group per adapter, which they might support now but I don't know off-hand); and they also needed hierarchical security group inheritance (the same way traditional subnets can nest into each other), which they didn't add but I guess you can now simulate them (though this sucks and I think is part of the downfall of the elegant stack) using multiple non-hierarchical security groups (which was not supported originally: security groups were permanently fixed in a one-to-one relationship with an instance).

This original elegant cloud-first model of instances and groups made network engineering pleasant for once... even fun! I remember thinking how great it was that all of my arcane physical networking and routing knowledge might soon be obsolete: that I could now think in terms of the abstractions of instances and how they talk to each other, drawing abstract circles around them without having to think about limited address spaces, and that they would assuredly fix the only two shortcomings of the original model...

...but then the network engineers showed up in force and ruined it all. There is simply no good reason for all of this VPC IP-address subnet focused insanity once you go cloud: they are just re-instating all of the frustrating limitations that come up when doing real world network engineering, presumably because they weren't willing to throw away their knowledge and realize all of that stuff is obsolete.

Like, seriously: we want to be able to replicate some enterprise network? That's madness, and it makes it all worse for everyone that this is even a supported goal. This is all virtualized networking: we don't need to be thinking in terms of subnets and gateways, we don't need to be manually configuring our egress... if you have a ton of hubs and routers and have to run cable all over the place, it makes sense, but this is the cloud!

And so now we all actually had to brush off all of that networking knowledge I was happy to give up as Amazon deprecated and fully removed "EC2 Classic" and have forced us all into this VPC insanity; and maybe if you never really tried to grok how AWS worked 15 years ago when it wasn't pretending to be a pile of legacy networking equipment you just shrug and accept that this somehow is all necessary, but it really isn't.

[marcus0x62]

>...but then the network engineers showed up in force and ruined it all.

I've never met a single network engineer who had anything good to say about any of the cloud networking environments. I have met a bunch of network engineers who were told by management "go recreate our data center network in the 'cloud'. We're moving everything there over the next 18 months. No, we aren't going to re-factor any of our apps in the process."

That's why all these kludges exist in AWS and other public cloud environments.

[ecshafer]

On the flip side, the unnecessary AWS complexity is a great make work program for developers. You now need an army of developers (and AWS "architects") to make a truly complex behemoth that fully replicates the insanity of a 50 year old enterprise system. A system of such complexity no single person can understand it all, all changes take days to weeks to make, and its behind black boxes everywhere. That's progress.

[arianvanp]

They recently launched https://aws.amazon.com/vpc/lattice/ which basically feels like EC2-classic emulation layer on top of VPC. which is a funny full circle but it works.

[lenkite]

What they need to make are standards. Then it becomes technical knowledge for civilisation and not just single-company product knowledge. It would be great if cloud companies made cloud networking standards. I mean big competitors used to collaborate and make standards before but all that has petered out over the last couple of decades.

[irrational]

I thought the other goal was to make it easy to get in but very difficult to leave so you are practically forced to keep using their services. Customer capture.