Microservices on AWS and Azure: what each piece does and how they fit together

One big app versus many small jobs#

The traditional way is a monolith. One codebase, one deployment, one database. It is simple at the start. Then a one-line change to the checkout page needs the whole application tested and released, one slow report drags down the login screen, and scaling means cloning the entire thing.

Microservices split that into small services that each do one job and own their own data. Cloud platforms make this practical because every job in the stack has a managed service built for it. Here is the map for AWS and Azure, and how the pieces connect.

The stack, layer by layer#

• DNS and edge: Resolves the domain, caches content, absorbs attacks. AWS: Route 53, CloudFront. Azure: Azure DNS, Front Door.
• API gateway: Single front door: routing, throttling, auth checks. AWS: API Gateway. Azure: API Management.
• Identity: Who is the user, and what may they do. AWS: Cognito. Azure: Entra ID.
• Compute: Runs the business logic of each service. AWS: Lambda, ECS/Fargate, EKS. Azure: Functions, Container Apps, AKS.
• Messaging and events: Lets services talk without waiting on each other. AWS: SQS, SNS, EventBridge. Azure: Service Bus, Event Grid.
• Data: Each service keeps its own state. AWS: DynamoDB, RDS/Aurora, S3. Azure: Cosmos DB, Azure SQL, Blob Storage.
• Secrets: Keeps keys and connection strings out of code. AWS: Secrets Manager. Azure: Key Vault.
• Observability: Logs, metrics, traces, alerts. AWS: CloudWatch, X-Ray. Azure: Azure Monitor, Application Insights.

How a request flows through it#

Take a customer placing an order.

1. DNS and the edge send the browser to the nearest point of presence. Static content is served from cache and never reaches your code.
2. Identity issues the user a token at sign-in. The API gateway checks that token, applies rate limits, and routes POST /orders to the right service.
3. The orders service runs in compute, as a function or a container. It reads its secrets from the vault and writes the order to its own database.
4. It then publishes an OrderPlaced event to the messaging layer. It does not call anyone directly.
5. Payments, inventory, and email services each subscribe to that event and do their own work at their own pace. If email is down, the queue holds the message until it recovers. The order still succeeds.
6. Observability follows the request across every hop with a shared trace ID, so one slow service is easy to find.

The pattern to remember: synchronous at the front (gateway to service), asynchronous in the middle (events and queues), private at the back (one data store per service).

Why modular beats the traditional way#

• Independent deployment. Ship the orders service on a Tuesday afternoon without retesting payroll.
• Independent scaling. Scale the busy service, not the whole application. Pay for what is actually under load.
• Contained failure. A broken email service stops emails, not checkouts. Queues and retries absorb the gap.
• Right tool per job. A document store for the catalogue, a relational database for finance, object storage for files.
• Smaller blast radius for change and for attackers. Each service gets its own identity and least-privilege access, so one compromise does not hand over everything.
• Teams move on their own. Clear service boundaries mean fewer merge conflicts and fewer meetings.

The honest trade-off#

Modularity is not free. You trade one big thing for many small things, which means more networking, more deployments, more places for latency to hide, and data that is eventually consistent rather than instantly consistent. Without good observability and automation (infrastructure as code, CI/CD) it turns into a distributed mess faster than any monolith could. For a small app with one team, a well-structured monolith is still a perfectly good start.

Where to begin#

Pick one function that hurts to release or scale, such as image processing, notifications, or reporting. Carve it out behind the gateway, give it its own data store, and connect it with a queue. Once that works, the pattern repeats.

References#

Sources and further reading for the claims above.

• AWS, What are microservices?
• Microsoft Learn, Microservices architecture style
• Microsoft Learn, Choose between Azure messaging services
• AWS Well-Architected Framework
• Azure Well-Architected Framework