OK. Slightly - slightly - less half-baked thoughts about devops.
At the time of the Agile Manifesto, Agile's big competitor was the Rational Unified Process (RUP). It was a process that was tailorable to any situation. But it required tailoring to any given situation.
The intro to XP Explained was a breath of fresh air because it sharply limited its scope: small teams, requirements in flux. Then it said, prescriptively: such teams should do these N things, learn to do them really well, and leave all the "well, we're special because..." for later.
Devops-in-practice, it seems to this newbie, has zoomed right past the limited scope and "just do this" of XP and even Scrum-of-that-time to the infinite-but-required tailorability of RUP. For example, we're on AWS. Like skazillions of other smallish companies, the potential cost of lockin to AWS is of no concern to us. And yet I have a lot of trouble finding tooling that doesn't want to inflict on me the option of customizing it to N other cloud vendors. That imposes learning and deciding costs on me that I do not want. And that I believe many other people do not want.
AWS itself is so sprawling that it's just as bad for those who stick to its tools. You must learn enough to make choices that benefit you little (but leave the possibility that choosing wrong could have big costs). You really ought to learn enough to be competent to handle N different kinds of operation scenarios - some of them very complicated - in order to safely handle your single simple scenario.
We handle relatively few (measured in the millions per year, not per day), relatively heavyweight transactions. It's a constant struggle (one for which I am ill-prepared) to keep things simple. I think there's an unexploited market niche. An "X is to today's devops as XP was to RUP".
One solution (which we are taking) is to hire a consultant who's deeply experienced in N scenarios - including one like yours - to give you the answers. Perhaps that's the only solution, like this could have been a universe in which the only solution was to hire the RUP consultant to tailor the process to you. I hope that's not the case.
I think you're conflating loads of things here!
AWS is 'devops' in the same way that junit is 'agile', which is to say that it's a tool used by people, and some of those people have brought into a culture (devops, agile). Which is also to say that not all have.
It seems to me that there are three key problems you raise here:
None of these are about devops. Devops is simply saying we should break down the barriers between dev and ops. It doesn't say that devs have to manage their own operations (which seems to be where you are) although this is a direction that some people go in when embracing this idea. Some, but not all.
If you're using tools which are abstractions on AWS, but whose abstractions add too much complexity (supporting other vendors), then don't use them. Just use the AWS toolchain. Yes, AWS has a lot of stuff, as the problems it's trying to solve are many and varied. If you don't need all those things, then either limit yourself to a subset (very sensible - it's like deciding not to use 70% of the language features when programming in Scala!) or pick a simpler platform.
As to operations, managing IT operations is a much bigger space than that of custom software development. Last time I looked at the industry stats for example, spend on operations represented 70% of the total spend on IT, with software development being in the 30%. There are lots of things that operations people have to worry about that devs don't know about - this is stuff I had to learn too coming from a more dev-y background. I know enough to be a conscious incompetent, not that much more.
As someone who has had a foot in both camps for the last 15 years or so (dev and ops), I have become increasingly unconvinced that most developers can keep up with the state of the art for their chosen software platform and also get good enough at operations to run them well, all at the same time, unless they are using a platform of some sort. Both spaces are moving too quickly. If you really want to have the same team run operations and delivery, then you have two choices - pick a higher-level abstraction platform for your software delivery like Heroku, or a hosted Kubernetes (where you effectively outsource most of the ops work), or hire a specialist (or two). I find it surprising how many developers who go on about craftsmanship (this isn't aimed at you, but a trend I have seen!) who are then willing to disregard the importance of people with deep knowledge and expertise in sectors outside their own!