[enz]

As long as the business logic remains agnostic, the most essential part is okay (for a lot of projects, at least). You talk only about EC2 and Lambda, so I assume you use a "standard" database and you are not using a proprietary one such as Dynamo. (So you are able to change from AWS RDS PostgreSQL to Heroku PostgreSQL for example.)

Typically, I organize my layers of code as such:

Business Logic, Core < Handlers < Front (HTTP routing, sessions/token stuff, ...).

The dependency can only go from the right to the left, so the BL code never gets touched when I decide to add/replace a handler or a frontend.

When you are on AWS Lambda, you code the Front: a glue between your Handlers and the AWS Lambda platform. So the rest of the project can be updated as-is in an ideal case. When you change your cloud provider, you have to rewrite the Front part again. But the layers underneath will be unchanged.

Of course, this is pure theory. In practice, some cases may require you to break this one-way chain for performance or scalability reasons...

[IceandFire]

> Business Logic, Core < Handlers < Front (HTTP routing, sessions/token stuff, ...). I use the similar logic. But you have presented it perfectly. In one of the project we had to use NoSQL database in crunch time situation so had to go with Dynamo.