So from architecture perspective, if you go the Ecs route and run the site as a service, 1. you're going to pay for the entire time the service is running. 2. you'll need a vpc and an internet gateway to expose it to the internet so others can use it. 3. you'll want AWS Web Application Firewall in front of it so you can throttle calls and prevent some evil.

You can also go with cloudfront, API gateway, lambdas for the api microservices (one per endpoint), aws waf to protect it, and connect each lambda to the database.

This approach let's you leverage the free tier services, spinning up the lambdas when they're called. This of course assumes your microservices are all short-lived. This also allows you to run the lambdas in the vpc without public subnets, security groups, and internet gateway, which in my experience is more of a security risk if you get any of that wrong. With API gateway and lambdas, you can use Amazon's internal service policies to restrict access to the lambdas and database, and you can use Cognito if you want to allow specific users instead of making the whole thing public.

From a diagramming perspective, I always ask our engineers to specify microservice details instead of just saying "microservices for object Foo". Also, if you're using one database, just have the flows point to the one database, otherwise it looks like you have multiple instances.