If all your services deploy together, share a database, and cannot function independently, congratulations. You built a monolith with network latency.
I have seen this pattern more than once. Someone reads the microservices chapter of a software architecture book, gets excited, and spends six months breaking a perfectly functional monolith into 14 services that all call each other synchronously over HTTP. Nothing can handle a request without calling three other services first, they all sit on a single database, and deploying one without the others breaks everything. You have added steps to the monolith and raised the AWS bill.
The entire point of microservices is independent deployability. Service A can ship a new feature without coordinating with Service B. Without that, you have a distributed system with all the downsides and none of the benefits.
A shared database couples your services at the data layer. Change a column name and watch five services explode. With synchronous HTTP calls for every operation, one service going down can leave the entire system returning 500s. You added a network boundary to what used to be a function call.
Coordinated deployments couple the services through their deployment schedule. You are just doing it with Kubernetes instead of a single JAR file.
With microservices, each service owns its data. Communication leans asynchronous (events, queues) where it can; synchronous calls get timeouts and circuit breakers. You should be able to deploy any service without breaking the others, and each team should be able to build without coordinating daily with other teams.
If that does not describe your system, you do not have microservices, and that is fine. A well-structured monolith is a perfectly valid architecture, and it is simpler to develop, deploy and debug.
Stop copying Netflix's architecture when you do not have Netflix's problems. Ship the monolith and make money with it. If parts of the system later need to scale independently, refactor them then.