--- title: Microservices vs Monolith on AWS: Architecture Decision Guide description: July 2026 decision guide: monolith → modular monolith → microservices on AWS, covering team size, platform tax (VPC Lattice/mesh), and a checklist before you split for the org chart. url: https://www.joinhorizon.co/blog/microservices-vs-monolith-on-aws-architecture-decision-guide/ datePublished: 2026-02-15T00:00:00.000Z dateModified: 2026-10-28T00:00:00.000Z author: palaniappan-p category: Cloud Architecture tags: architecture, microservices, aws, serverless, devops --- # Microservices vs Monolith on AWS: Architecture Decision Guide > July 2026 decision guide: monolith → modular monolith → microservices on AWS, covering team size, platform tax (VPC Lattice/mesh), and a checklist before you split for the org chart. The microservices vs monolith debate still gets settled for the wrong reasons, such as copying FAANG topology onto a five-person team. For [application modernization](https://www.joinhorizon.co/services/aws-application-modernization/), the useful path is **monolith → modular monolith → extract only when a module needs independent scale, deploy, or data ownership**. As of **July 19, 2026**, if you split for political reasons alone, budget **VPC Lattice or service-mesh tax**. East-west connectivity is not “one more security group” past a few dozen services. > **Reproduce this:** Decision checklist: [`examples/architecture-blog-2026/architecture/monolith-vs-microservices-decision.md`](https://www.joinhorizon.co/examples/architecture-blog-2026/architecture/monolith-vs-microservices-decision.md) ## Defining the options ### Monolith A single deployable unit containing all application functionality: ``` Single Application ├── User Management ├── Order Processing ├── Payment Handling ├── Notification Service ├── Reporting └── Single Database ``` **Deployment:** One build, one deploy, one process. **On AWS:** ECS/Fargate running a single container, or EC2 running a single application process. One [RDS](https://www.joinhorizon.co/blog/aws-rds-vs-aurora-when-to-use-which-database/) database. ### Modular monolith A monolith with well-defined internal module boundaries: ``` Single Application ├── modules/ │ ├── users/ (controllers, services, models) │ ├── orders/ (controllers, services, models) │ ├── payments/ (controllers, services, models) │ └── notifications/ (controllers, services, models) └── Single Database (with schema-per-module) ``` **Deployment:** Still one deployable unit, but internally organized for potential future decomposition. **On AWS:** Same as monolith, but internal code structure enables extracting modules into services later. ### Microservices Multiple independently deployable services, each with its own data store: ``` User Service → Users Database Order Service → Orders Database Payment Service → Payments Database Notification Service → Notification Queue ↕ (API calls, events, messages) ``` **Deployment:** Each service has its own build, deploy, and scaling pipeline. **On AWS:** Multiple [ECS services](https://www.joinhorizon.co/blog/aws-ecs-vs-eks-container-orchestration-decision-guide/) or [Lambda functions](https://www.joinhorizon.co/services/aws-serverless/), each with its own data store ([DynamoDB](https://www.joinhorizon.co/blog/dynamodb-single-table-design-patterns-for-saas/), RDS, or S3), communicating via API calls, [EventBridge](https://www.joinhorizon.co/blog/aws-eventbridge-event-driven-architecture-patterns/), SQS, or SNS. ## The decision framework ### Team size is the primary factor | Team Size | Recommended Architecture | Rationale | | --------------- | ------------------------------------------- | ------------------------------------------------------- | | 1-5 engineers | Monolith or modular monolith | Microservices overhead exceeds any benefit | | 5-15 engineers | Modular monolith or selective microservices | Extract high-value services only | | 15-50 engineers | Microservices for independent team domains | Conway's Law: architecture should match team structure | | 50+ engineers | Microservices with platform team | Dedicated infrastructure team to manage complexity | **Why team size matters:** Microservices redistribute complexity from the codebase to the infrastructure instead of reducing it. Debugging a bug across 15 services with distributed tracing is harder than debugging a monolith with a stack trace. The benefit of microservices is organizational: independent teams can deploy independently. If you do not have independent teams, you do not need independent services. ### When to stay monolithic - **Early-stage product:** you are iterating on product-market fit. Refactoring across service boundaries is 10x harder than refactoring within a monolith. - **Small team:** under 5 engineers, the operational overhead of multiple services, databases, and CI/CD pipelines slows you down. - **Uncertain domain boundaries:** if you do not know where the natural service boundaries are, do not guess. Build a monolith, observe the usage patterns, and decompose when boundaries become clear. - **Simple domain:** CRUD applications with straightforward data models do not benefit from service decomposition. ### When to adopt microservices - **Independent scaling requirements:** one component needs 100x the compute of another (e.g., video transcoding vs user authentication). - **Independent deployment velocity:** teams need to deploy their components without coordinating with other teams. - **Technology diversity:** different components benefit from different languages, frameworks, or data stores (ML in Python, API in Node.js, batch processing in Java). - **Fault isolation:** a failure in one component must not cascade to others (payment processing must not be affected by a reporting bug). - **Organizational structure:** multiple teams own different business domains and need autonomous delivery. ## Architecture comparison on AWS ### Monolith on AWS ![Architecture diagram of CloudFront, a load balancer, one ECS service, and one RDS database](../../assets/images/blog/microservices-vs-monolith-on-aws-architecture-decision-guide-mono.webp) _Figure: the monolith in the article. One ECS service sits behind one load balancer and one database. One pipeline is enough. No prices are shown. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/microservices-vs-monolith-on-aws-architecture-decision-guide/mono.drawio)._ ``` CloudFront → ALB → ECS/Fargate (single service) → RDS (single database) ``` **Infrastructure:** - 1 ECS service with auto-scaling - 1 RDS instance (Multi-AZ for production) - 1 ALB - 1 CI/CD pipeline **Cost (typical startup):** $300-$800/month - ECS/Fargate: $150-$400 - RDS: $100-$300 - ALB: $20-$50 - Other: $30-$50 **Operational complexity:** Low. One service to monitor, one database to back up, one pipeline to maintain. ### Microservices on AWS ![Architecture diagram of a load balancer fanning out to three ECS services](../../assets/images/blog/microservices-vs-monolith-on-aws-architecture-decision-guide-micro.webp) _Figure: microservices in the article. The load balancer fronts more than one service, and each service keeps its own data. API Gateway, EventBridge, and a queue are other edges in the article's sketch, not required on every service. No prices are shown. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/microservices-vs-monolith-on-aws-architecture-decision-guide/micro.drawio)._ ``` CloudFront → ALB → ECS Service A → DynamoDB → ECS Service B → RDS → ECS Service C → DynamoDB API Gateway → Lambda Service D → DynamoDB EventBridge → Lambda Service E → SQS → Lambda Service F → S3 ``` **Infrastructure:** - 5+ ECS services or Lambda functions, each with auto-scaling - 3+ databases (DynamoDB tables, RDS instances) - 1-2 ALBs + API Gateway - EventBridge, SQS, SNS for inter-service communication - 5+ CI/CD pipelines - Distributed tracing (X-Ray) - Service mesh or API gateway for service-to-service communication **Cost (same application as microservices):** $800-$3,000/month - Multiple ECS services: $400-$1,500 - Multiple databases: $200-$800 - Messaging (EventBridge, SQS): $50-$200 - ALB + API Gateway: $50-$150 - Monitoring (X-Ray, CloudWatch): $50-$150 - Other: $50-$200 **Operational complexity:** High. Multiple services to monitor, multiple databases to back up, multiple pipelines to maintain, distributed debugging, inter-service communication failures. ### Serverless microservices on AWS ``` API Gateway → Lambda A → DynamoDB → Lambda B → DynamoDB → Lambda C → DynamoDB EventBridge → Lambda D → SQS → Lambda E → S3 Step Functions → Lambda F → Lambda G → SNS ``` **Advantages over container-based microservices:** - No ECS cluster management - Per-request pricing (cost scales linearly with usage) - Automatic scaling (no capacity planning) - Simpler CI/CD (deploy individual functions) **Disadvantages:** - Cold starts affect latency - 15-minute execution limit on classic Lambda and sync invokes (90 minutes on LMI async/ESM as of 9 Sep 2026) - Debugging distributed Lambda functions is harder than debugging containers - Vendor lock-in deeper than containers **Cost (same application, serverless):** $50-$500/month at moderate traffic - Lambda: $20-$200 (pay-per-request) - DynamoDB: $20-$200 (on-demand) - API Gateway: $10-$50 - EventBridge, SQS: $5-$30 - Other: $5-$20 Serverless microservices are much cheaper at low-to-moderate traffic because you pay nothing when idle. At very high traffic (millions of requests per hour), container-based microservices may be cheaper due to more efficient compute pricing. ## The modular monolith: simplicity now, a path to microservices later The modular monolith is the most underrated architecture pattern. It gives you monolith simplicity now and a clear path to microservices later: **Implementation:** 1. **Module boundaries:** organize code into modules by business domain (users, orders, payments) 2. **Module interfaces:** modules communicate through defined interfaces, not by reaching into each other's code 3. **Module databases:** each module owns its database schema (separate schemas within the same RDS instance) 4. **No circular dependencies:** Module A can call Module B, but Module B cannot call Module A without going through an event **Extraction path:** When a module needs to become a service (independent scaling, different deployment cadence), extract it: ``` Before: Monolith → [Users module, Orders module, Payments module] → Single DB After: Monolith → [Users module, Orders module] → DB Schema A Payment Service (extracted) → DB Schema B EventBridge connecting them ``` It is much easier to extract a well-defined module from a monolith into a service than to merge poorly separated microservices back into a coherent system. Start modular, decompose selectively. ## Selective decomposition Instead of migrating entirely to microservices, extract only the components that benefit from independence: ### Good extraction candidates - **Compute-intensive tasks:** image processing, video transcoding, ML inference. Extract to Lambda or Fargate with independent scaling - **Third-party integrations:** payment gateways, email providers, SMS. Extract to isolate failure and rate limits - **Event consumers:** analytics, notifications, audit logging. Extract as [EventBridge](https://www.joinhorizon.co/blog/aws-eventbridge-event-driven-architecture-patterns/) consumers that process events asynchronously - **Batch processing:** report generation, data exports, ETL. Extract to [Step Functions](https://www.joinhorizon.co/blog/aws-step-functions-workflow-orchestration-patterns/) workflows ### Poor extraction candidates - **Tightly coupled CRUD:** if two modules share the same database tables and queries join across them, extracting one creates a distributed join problem - **Synchronous chains:** if Service A always calls Service B, which always calls Service C, you have a distributed monolith with extra latency - **Low-traffic modules:** modules that handle 10 requests per day do not benefit from independent scaling ## Operational requirements by architecture | Capability | Monolith | Modular Monolith | Microservices | | ------------------------------------------------------------------------------------------------ | ---------------------- | ----------------------------- | -------------------------------- | | CI/CD pipelines | 1 | 1 | 5-20+ | | Database management | 1 database | 1 database (multiple schemas) | 5-20+ data stores | | Monitoring | Single APM setup | Single APM setup | Distributed tracing required | | Debugging | Stack traces | Stack traces | Correlation IDs across services | | [Disaster recovery](https://www.joinhorizon.co/blog/aws-disaster-recovery-strategies-pilot-light-warm-standby-multi-site/) | One recovery plan | One recovery plan | Per-service recovery plans | | Team coordination | High (shared codebase) | Moderate (module interfaces) | Low (API contracts) | | Deployment risk | All-or-nothing | All-or-nothing | Per-service (lower blast radius) | | [DevOps maturity](https://www.joinhorizon.co/services/devops-pipeline-setup/) needed | Basic | Basic | Advanced | ## Common mistakes ### Mistake 1: Premature microservices The most common mistake is decomposing into microservices before understanding the domain. The result is services with the wrong boundaries, excessive inter-service communication, and distributed data consistency problems that would not exist in a monolith. **Rule of thumb:** If you have not built the monolith first, you do not know where the service boundaries should be. ### Mistake 2: Distributed monolith Microservices that must be deployed together, share a database, or fail together are a distributed monolith. You get microservices complexity without microservices benefits. **Test:** Can each service be deployed independently without coordinating with other services? If not, you have a distributed monolith. ### Mistake 3: Ignoring data ownership The hardest part of microservices is data decomposition. If two services share a database, changes to one service's schema can break the other. Each service must own its data exclusively, communicating through APIs or events and never through shared database access. ### Mistake 4: Over-engineering communication Simple HTTP/REST calls between services are fine for synchronous request-response patterns. You do not need Kafka, gRPC, or service mesh on day one. Start with HTTP calls and SQS/EventBridge for async, and add complexity only when you hit specific performance or reliability problems. ## What this post does not cover - **Event-driven patterns in depth:** see [EventBridge patterns](https://www.joinhorizon.co/blog/aws-eventbridge-event-driven-architecture-patterns/). - **Service mesh bake-offs** (Istio vs App Mesh vs Lattice): budget them only after the checklist passes. - **Org-design / team topology:** consulting beyond the architecture implication. ## What to do this week 1. Name one module that truly needs independent deploy or scale; if you cannot, stay modular monolith. 2. Run the [decision checklist](https://www.joinhorizon.co/examples/architecture-blog-2026/architecture/monolith-vs-microservices-decision.md). 3. Exhaust [scale-in-place](https://www.joinhorizon.co/blog/aws-legacy-monolith-scale-in-place-before-decomposition-2026/) before extracting. [Architecture review](https://www.joinhorizon.co/services/aws-architecture-review/) · [Contact us](https://www.joinhorizon.co/contact-us/) --- *Source: https://www.joinhorizon.co/blog/microservices-vs-monolith-on-aws-architecture-decision-guide/*