This is false (and wrong). As a software engineer, you must understand and own what you do end-to-end, including:
* how to write your code
* software/hardware that your code relies on (databases, k8s, aws, whatever)
* protocols your software uses for communication
* 3rd party libraries that your software depends on
* how to build and deploy your software and environment for it (bare metal, clouds, mobile app stores - whatever necessary)
* setup testing + write tests for all of the above
* setup monitoring + monitor all of the above
at any company, at any scale.
> I've been painfully aware of spreading myself too thin trying to handle both feature development, CI/CD maintenance and DevOps-related tasks ensuring our cloud-based environments are deployed to and operate smoothly.
Reduce complexity.
As for reducing complexity, what are you suggesting exactly? Most of the actual complexity I have to deal with is in our codebase to build the core application (which can run almost anywhere), which is independent of any issues with CI/CD and DevOps/cloud deployment. They're not complex, they're just frustrating.
Getting an EV sports car is like being a kid again. But you can still commute in it. How great is that!
Having said that, you are wrong in thinking you can learn something that'll last more than 5 years. It's possible but the field isn't about doing the same thing for a long period of time. The job description is better put as "quick learning capability". Which you said yourself; you need to adapt as time goes on. That doesn't necessarily mean AWS. It means Java WebFlux, in your case. AWS and k8s are, each, huge huge topics. They can each employ a team. You shouldn't dive deep into it unless you want to change career paths. AWS to become a cloud architect or k8s to become whatever-cool-name-that-hat-has. You can't be top gun Java dev and cloud architect. It's too much. Select few gurus could exist that excelt in both. But it's simply too much information to keep up with and not a realistic job description/requirement.
Bottom line is you need to continue to adapt in your field of choice (Java or AWS or k8s) and turn your critical eye to your own company. Something there sounds off. The DevOps guy should be the one to tell you lambdas can be written in Java. And the vprnd should be the one to choose Java, seeing as most of the company already knows Java. The architect can give you guidelines how to design your implementation to be compatible to cloud architecture. And you can just learn a few basics about AWS lambdas to be able to debug.
Anyway, sounds like a midlife crisis. Hang in there. I got myself a sports car.