A monolith is not a bad word. Plenty of healthy businesses run on one. The problem starts when a single deploy takes a weekend, one bad commit takes down the whole app, and scaling the checkout means scaling the admin panel and the reporting engine along with it. At that point the architecture is actively slowing the business down.

Breaking a legacy monolith into microservices on AWS is one of the highest-value modernization moves available, and also one of the easiest to get wrong. The teams that succeed do not rewrite. They extract services incrementally, keep the monolith running the whole time, and let the new architecture grow around the old one.

This guide covers when decomposition is worth it, the strangler fig pattern that makes it safe, how to pick boundaries by domain, containerizing with App2Container, choosing between ECS, EKS, and Lambda, splitting the database, and how AWS Transform now automates containerization during the move.

1Is Your Monolith Actually the Problem?

Before any extraction, be honest about the symptoms. Microservices fix specific problems and create new ones. Decompose when you see:

• Coupled scaling - one hot path forces you to scale the entire app, wasting compute on everything else.
• Deploy fear - releases are batched and risky because everything ships together.
• Team contention - multiple teams stepping on each other in one codebase.
• Mixed reliability needs - a best-effort report and a revenue-critical checkout sharing the same fate.

If you do not have these problems, a well-structured modular monolith on ECS may be the cheaper, saner answer. Microservices are a tool, not a trophy. Decompose only the parts where independent scaling and deployment genuinely move the business.

2The Strangler Fig Pattern

Named after a vine that grows around a tree until the tree is gone, the strangler fig pattern is the safe way to retire a monolith. Instead of a big-bang rewrite, you put a routing layer in front of the monolith and incrementally peel off functions into new services:

1. Put a facade in front of the monolith (Application Load Balancer, API Gateway, or AWS Migration Hub Refactor Spaces).
2. Pick one well-bounded capability and build it as a new service.
3. Route just that capability's traffic to the new service; the rest keeps hitting the monolith.
4. Repeat, capability by capability, validating as you go.
5. When nothing routes to the monolith anymore, retire it.

The win is that the system stays in production the entire time. There is no flag day, every step is reversible, and you can stop at any point with a working system. AWS Migration Hub Refactor Spaces was built to manage exactly this facade-and-routing setup.

3Find Boundaries by Domain, Not by Code

The most common decomposition mistake is splitting along technical layers (a service for the UI, a service for the data access) instead of business domains. Good service boundaries follow business capabilities: Orders, Payments, Inventory, Notifications. Each owns its data and its logic.

A practical way to find them is event storming with the people who know the business: map the events the system produces (OrderPlaced, PaymentCaptured, ItemShipped), then cluster them into bounded contexts. Those clusters become your first candidate services.

Extract the easy, loosely coupled capabilities first. Notifications and reporting are classic starting points because they read more than they write and rarely sit in the critical path. Save the tightly coupled core (often Orders or Billing) for last, once your patterns and tooling are proven.

4Containerize First with App2Container

Many teams containerize the monolith before splitting it. Running the existing app in a container on AWS is a quick win that standardizes deployment and gives you a stable base to extract from. AWS App2Container (A2C) is the tool for this:

• A CLI that inspects a running Java or .NET application and detects its dependencies.
• Generates Docker images plus ECS task definitions or EKS manifests and CI/CD artifacts.
• Deploys to Amazon ECS or Amazon EKS without code changes.

5ECS vs EKS vs Lambda

AWS gives you three main homes for microservices. The right answer is usually a mix, chosen per service rather than for the whole system:

A sensible default: ECS on Fargate for steady request/response services, Lambda for event handlers and glue logic, and EKS only when you have a real reason for Kubernetes. Avoid adopting EKS for the resume; the operational tax is real.

6A Strangler Fig Architecture on AWS

Here is what an in-progress decomposition looks like. A routing facade sends extracted capabilities to new services while everything else still flows to the monolith:

As each capability moves, the dashed line to the monolith carries less traffic. The migration is done when that line carries none and the monolith can be switched off.

7Decomposing the Database

The database is the hardest part and the reason many decompositions stall. A shared database quietly re-couples your services, so the goal is database-per-service, but you get there gradually:

• Phase 1: Extract services that still read from the shared database. Fast, but not true isolation.
• Phase 2: Give each service its own schema or database. Use change data capture (AWS DMS) to keep data in sync during the cutover.
• Phase 3: Replace cross-service transactions with the saga pattern and event-driven updates, since you can no longer rely on a single database transaction.

This is also a natural moment to escape expensive legacy database licenses by moving to managed engines. Our guide to migrating legacy databases to Amazon Aurora covers the DMS and schema conversion workflow in depth.

8AWS Transform: Containerize During Migration

Historically you faced a choice: rehost quickly to hit a deadline, or take the slow road to replatform into containers. AWS Transform now collapses that into one step.

For monolith decomposition specifically, AWS engineers at re:Invent 2025 also shared patterns for decomposing tightly coupled monoliths and rethinking service-to-service communication in serverless architectures.

❓ Frequently Asked Questions

9Why Lushbinary for Your Decomposition

Decomposition is a design problem before it is a coding problem. Lushbinary helps you decide what to extract, in what order, and what to leave alone, then does the engineering: setting up the routing facade, containerizing with App2Container or AWS Transform, choosing ECS, EKS, or Lambda per service, and splitting the database safely with change data capture. We keep your system in production the entire time.

The result is an architecture where teams ship independently, the revenue-critical paths scale on their own, and the next change does not require holding your breath.

Sources

• Containerize during migration with AWS Transform
• Modernizing a legacy monolith with Amazon EKS Windows containers
• What is AWS App2Container?
• re:Invent 2025 CNS362: serverless mission-critical applications

Content was rephrased for compliance with licensing restrictions. Service capabilities and customer results sourced from official AWS documentation and blog posts as of June 2026. Architecture recommendations are general guidance and should be validated against your specific workloads.