This 1000%. It was amazing how much more comfortable I was with my suite of VPS's when I moved them from AWS to Digital Ocean! I always describe on-boarding with AWS as "drinking from a firehouse". There is so much to understand and it is hard to tell what you should actually care about. DO, on the other hand, has a much simpler set of services that seem much more applicable to 'non-enterprise' usage. (Plus the documentation for DO is great!)

I have a recruitment problem. If I tell recruits “We use AWS”, they’ll be happy the be waterboarded when trying to do something, they’ll have the feeling of being in connection with the rest of the world, preparing their resume for the future.

If I tell them “I have Digital Ocean, I maintain the load balancer myself, the database myself, ELK myself, and you’ll be expert in Postgres, Ansible, Nginx and Debian”, I sound like an old fart.

The future for them in AWS is a click-on-the-button deployment and they’ll master nothing.

Amazon tried to emulate Digital Ocean with Lightsail.

It does feel a bit like a Cinderella service however. The versions of the managed databases you can connect are sometimes several years old.

I had this feeling when I first started with AWS years ago. It was hard to find a good overview and all of the Amazon doc on individual services seemed to start in the middle. So, a lot of my initial understanding came through intuition, and trial and error.

For many scenarios, you can completely ignore IAM, but it's definitely not advisable.

On the VPC side, it's actually fairly straightforward, but you may need to come up to speed a bit on some networking concepts if (like me) that's not your background. Nothing too onerous though, especially if you have some technical background.

There are also some gotchas that allow you to too easily do things like create security groups or other resources outside the correct VPC. If you overlook that, you're in for some brick wall head-banging 'til you figure it out.

But how can we trust the DIY stuff meet compliance and hold the right security bar? It’s much easier to do with AWS.

Or maybe as a startup, to-C website you don’t really care

I think the complexity can lead to its own set of security risks, as people just keep opening permissions wider until things connect.

That's actually a really good point. Out of the box, it's hard to screw up because things are pretty locked down. It's really in attempting to open things up that the security risk comes in if people aren't explicitly aware of exactly what they're opening.

EDIT: and this isn't necessarily difficult to grok. A lot of what you'll use from the network side is security groups, and they are straightforward. /EDIT

There are also actually some bad patterns in the AWS Console UI that don't help here. For instance, despite all the warnings they place on S3 buckets about making things public, they still allow you to appear to change subobjects to private. In a traditional hierarchical directory structure, the more granular subobject settings would override, but not so with S3. If you didn't know that, then you've just shot yourself in the foot.

Great and interesting point. I believe the solution is to have “security by default” Infra-as-code construct and some static analyzer

When I am helping out people new to AWS, this is where 90% of the problems are. It suggests to me that they are lacking sensible defaults, when so many people have trouble and I just recommend connecting Beanstalk to RDS. I think some meta recipes that give you a set up where this is already secure and working make sense.

I built a tool for deploying web apps on AWS.. https://github.com/keybittech/awayto If you look at the deployment script app/bin/data/deploy, you can break things down into manageable pieces and understand what's going on probably within a day or two given you have some baseline understanding of frameworks and APIs.

But, I totally agree that the underlying nuance is a lot to take on when you start getting into X is required for Z which connects to A, yadda yadda.

That being said, if you choose a service and invest the time to understand it, you are availing yourself to a very wide world of technology "at your fingertips." You can most certainly say the same for DIY, just different shades of what you want to be responsible for I guess.

Sounds about right based on my experience with AWS for past 8 years. Does anyone (besides AWS/TF/Pulumi, for whom it’s not their core product) attempt to solve the networking and IAM? These two areas, esp AWS networking, despite being fundamental building blocks, just never get coverage.

I know I’m being a beggar and beggars can’t be choosers, however, I believe that there are folks here who could solve this problem and make a nice living off of it. Hope someone reads this comment and builds something to address this.

There's definitely something to this... but I think in practice most projects end up needing some amount of customization in their networking even if it's 90% "standard". In attempting to provide this, you might end up just gradually recreating TF/Pulumi anyway.

You can do a lot with EB for simplistic projects. But yes without that you are in for a world of pain using anything else