If you restrict yourself to only the set of AWS functionality that is common to all hosting providers, you can do that.
But not only is that very hard to do, it basically negates the premise of AWS in general. There are also lots of areas that you can’t do this, such as IAM and network rules, so you have to build an abstraction on top of it that’ll work with open source tools on a separate host.
Premise of AWS for me: reasonably priced (not cheap!) linux VM, close to the backbone, essentially total control of the VM, easy provisioning of new disk storage when required (i.e. EC2 with a smidgeon of EBS)
The rest of it? I think I understand why some systems need/want it, but no thanks.
At the scale $EMPLOYER works at, AWS built in services are key. Things like DynamoDB global tables are extremely hard to run on your own, and things similar to AuroraDB and Kinesis can be run on your own but they take up a lot of personnel hours better spent focusing on product. We could probably eliminate those services and self-run, but it would be an extremely unwise usage of company time and money.
But we also run services in multiple continents with the need to handle clients doing silly things like getting into airplanes and flying into another continent. Your situation might not benefit as much from AWS specific services, so YMMV.
But not only is that very hard to do, it basically negates the premise of AWS in general. There are also lots of areas that you can’t do this, such as IAM and network rules, so you have to build an abstraction on top of it that’ll work with open source tools on a separate host.