[gerbilly]

And this is why I hate having to deal with AWS. Learning this stuff isn't technical knowledge, it's product knowledge.

I read the TCP/IP illustrated series cover to cover and learned that stuff cold, and this was useful knowledge to me for decades.

However I always find myself resisting learning this AWS stuff, which is just as complex in its own way too. This diagram makes me feel that if the goal was to simplify things, then I'm not sure how successful they were at that.

[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.

[deathanatos]

> Learning this stuff isn't technical knowledge, it's product knowledge.

Not really, and mostly I think you're looking at it through the lens of a different field. TCP/IP is going to be the knowledge useful to your network programmer. One of my college courses was networking: we covered networks, subnets, route tables, routing protocols (such as RIP, OSPF, BGP), NAT, etc. We did all this on actual hardware, and the course was heavily sponsored by Cisco (so much that by the end of the semester, you were CCNA certified). In that vein, yes, I picked up a lot of "product knowledge" on how Cisco products behave, 95% of which I've probably forgotten. But that was to give us hands on experience, and the underlying concepts translate well into Azure, AWS, or GCP. These cloud VPCs are mostly virtual analogs to the real deal, much like how VMs are analogs to a real machine. If you understand a real machine, a VM (and associated resources like cloud disks or NICs) aren't going to be that mysterious.

In particular, NAT confuses the living daylights out of people. But, that's almost to be expected. More down to earth, many eng struggle with CIDR notation, or even — but this gets back to your stuff — TCP (e.g., they think that a send() will send the passed buffer as a unit, or that a recv() will always receive a full "message" of some sort; most eng struggle to understand the difference between connection timeouts and peer resets, and when one can happen and the other cannot).

The dark side of this coin is that I really wish I didn't need a lot of this knowledge; it is a lot of junk. IPv6 makes networks so big that a lot of network planning and subnet sizing and "will it have enough room to grow but also not exhaust the range?" just goes away. NAT can die in a cold icy hell. If I could never see another VPN in my life, that'd be cool. (Just use TLS, for the love of everything dear.) I could also do away with cloud firewalls using IP addresses as a form of auth, and delivering misleading errors when triggered. (Azure is horrid at this.)

(I do hope that most products are technically simple enough to not need much of this knowledge. If you do TLS, you shouldn't need to be doing VPCs, non-default route tables, network peering, etc. I'm in a field where we integrate with a lot of people who have no desire for technical simplicity.)

[oaiey]

I share this perspective. Most boxes in this diagram are AWS names for a thing existing in normal datacenter or TCP/IP networking. I am an old schooler who personally never worked a lot with AWS, but I think this is pretty clean.

[dasil003]

I think it's a boiling frog scenario. AWS's goal is marketshare, not simplicity. Like many professional software products, it started simple by necessity and then grew more complex over time. In AWS's case it ballooned pretty quickly due to the compelling nature of fully-managed on-demand infra services and the huge amount of resources Amazon poured into it.

The value add for not having to directly interact with hardware is still pretty high, but you definitely pay a price (in addition to the sticker price) for it in terms non-transferable vendor-specific knowledge.

[icedchai]

Yep, it would be nice if they had used standard terminology. Example: a "virtual router" that you could configure (with internet, NAT, connections to other VPCs, firewall rules, etc.) Instead, you have all sorts of one offs: "internet gateways", "NAT gateways", "egress only internet gateways", "transit gateways." We're going to wind up with a whole generation of engineers that only understand "cloud" and not how things actually work.

[mdaniel]

My suspicion is that they have distinct names/skus because (a) they're billed differently (b) they represent different security choices. If I grant a developer's account the ability to create "virtual router" entities, that means said developer can do all kinds of things I may not approve of. If I grant them only the ability to create "Internet gateway" entities, I know exactly what I'm getting into and (more or less) what I should expect the bill to be for that

I do agree with you that having a separate "egress-only Internet gateway" for IPv6 is dumb and confusing. I'm sure there's some number of pizzas which explains this Conway's Law instance

[qwertyuiop_]

Undifferentiated heavy lifting. Companies don't have to train their engineers and find talent that requires deep knowledge of tcp/ip and hardware routers and clean up the mess when they leave and maintain them. Offload all of the "undifferentiated" components to AWS and you focus on what you are good at, your business.

[smcleod]

Yep, welcome to the cloud (and SaaS in general).

The big 3 work very hard to make sure you’re learning their product so you can advocate for it (because it’s what you now live and breathe) and sell it to others.

Who needs a marketing team when you’re making everyone a “tech evangelist” for your product.

[paulddraper]

We've taken 90s LAN architectures and applied it to cloud infrastructure.

Why do I have a VPC? A NAT? IPv6 solves that.

"Security" but AWS EC2 security groups predate AWS VPCs.