Deploying to Amazon's cloud is a pain in the AWS younger devs won't tolerate

You say that. But, for the cheap web hosting I bought for a hobby project, the only options are the painfully slow web interface, or ftp. (And not even sftp/ftps. It's unencrypted. And I can't disable the FTP account, either. It's always on, FFS.) So I fired up ncftp and had to remember how to use it. It was like being hit by a cold shower. But it sounds like I got more hits than Corey. (Also, the web panel has an API which sounds like it will support git, when I get it sorted.) … * For example, I have an application from a place I've volunteered. I've got a big archive full of code and I have a backup of a database. The organization doesn't want to run it, which is great, because I would have to guess what to do with this stuff if they did. There's no documentation of what this does, how to install it, what's in the database, and for all I know, there may be components written by the original contractors which aren't in my big archive. I have no way of knowing whether this can run, even though theoretically I do have copies of the files concerned. … AWS specifially has been failing *a lot* for a cloud which claims to be bullet proof. I'm a Gen-er and largely with you. I've always hated the complexity in default AWS and haven't liked the party Azure has followed much better. As an actual fan of JS/TS, I've fought against undue complexity for over half my career. I've seen both spaghetti monoliths and microsecond jungles. … My biggest issue with pointing out Google as a positive is they're likely to just kill the product and workflow you've built on with the next update. I don't trust them. And good luck finding a real person when they disconnect your account from logging in. Lol how long did it take to figure out what region it was in? … One of the things that got me was how difficult it was to set up environments and systems, so that on the dashboard I could see resource usage and thus spend against Dev, Test and Prod(client 1), Prod(client 2)… I’m sure it is doable, as it s”assembler”, but… *"People who are trained up and accomplished at its configuration "* … " People who are trained up and accomplished at its configuration can make a good few quid on the job market." Except there's almost no useful training and experience is the way you learn things. Manuals are useless and/or hopelessy outdated, if they even exist. That applies also to enterprise users, which means that a simple migration project to AWS takes 18 months. With competent enterprise level machine room operators/developers, not just anyone. … AWS have always made life difficult and the security people have consistently put day1 startup mentally at a higher priority than customer success, pulling the wool over the eyes of senior management in the name of security. Whenever I see a message like 'unable to find a policy to allow this' all that I have ever wanted in the past 10 years is a simple button which says "Fix this" so that AWS can go away and create the IAM records it needs for me to continue. … No, speaking as a currently designated security troglodyte who’s spoken with some of the chief IAM architects, I would say legacy drift is not the big problem with IAM. The real problem is twofold. Firstly, the AWS APIs are all random SOAP-style verbs instead of REST and control plane and data actions are in the same service-url namespaces so nothing can be built around object or even object class permissions, only lists of actions that are unpredictably idempotent or mutating or data-exposing or control-plane-exposing. Secondly, the chief design requirement of IAM is performantly deterministic permission evaluation, not actual security or usability or least privilege. This leads to choices like making permissions a list of low-level API actions (because that’s where policies are evaluated), the boolean logic hell that is the deny sandwich and conditions, and strict character limits on policies such that you can’t explicitly list the actions for a single service like EC2 in a policy and are then forced to use wildcards and guess whether they’re restrictive enough and don’t open you up to the new surprise actions AWS adds without warning. The “fixes” they’ve added are just more layers of the same flawed design and implementation via permission boundaries and SCPs. So anyone used to sane CRUD permissions has to relearn everything and then discover that their basic security expectations and requirements are impossible to implement in any auditable way in AWS. No, it's nothing to do with that at all. … ~~victims~~ customers end up paying for stuff they didn't or can't use - and so the capacity can be sold to multiple customers. The bad consultancies like it as well, because it makes them irreplaceable and gives more scope for nickle-and-diming. So basically everyone who isn't already locked in, doesn't want to play there.