How to Choose Managed Messaging for a Lift-and-Shift Migration #
Exam Context: AWS SAP-C02
Scenario Category: Migration
Decision Focus: Minimizing refactoring while reducing messaging and platform operational overhead
While preparing for the AWS SAP-C02, many candidates get confused by migration strategy selection when dealing with legacy message brokers. In the real world, this is fundamentally a decision about Protocol Compatibility vs. Managed Service Convenience vs. Total Cost of Ownership. Let’s drill into a simulated scenario.
The Scenario #
GlobalRetail Inc., a mid-sized e-commerce company, is migrating its on-premises order fulfillment platform to AWS Cloud. The current architecture consists of:
- Web Frontend Tier: Running on a cluster of virtual machines (VMs) handling customer-facing order submissions
- Message Broker Layer: RabbitMQ instances managing asynchronous communication between frontend and backend
- Backend Processing Tier: A self-managed Kubernetes cluster running containerized microservices that process, validate, and route orders to warehouse systems
The engineering leadership has established a firm constraint: minimize application code changes during the migration to reduce risk and accelerate time-to-market. The operations team is seeking to reduce infrastructure maintenance burden compared to the current on-premises model.
Key Requirements #
Design a cloud migration architecture that:
- Preserves existing application logic with minimal code refactoring
- Minimizes operational overhead compared to on-premises management
- Maintains compatibility with existing RabbitMQ and Kubernetes workloads
The Options: #
A) Create AMIs from Web server VMs, deploy an EC2 Auto Scaling Group behind an Application Load Balancer, replace RabbitMQ with Amazon MQ, and migrate the Kubernetes workload to Amazon EKS (Elastic Kubernetes Service).
B) Build a custom AWS Lambda runtime that emulates the Web server environment, expose it via Amazon API Gateway, replace RabbitMQ with Amazon MQ, and migrate the Kubernetes workload to Amazon EKS.
C) Create AMIs from Web server VMs, deploy an EC2 Auto Scaling Group behind an Application Load Balancer, replace RabbitMQ with Amazon MQ, and install self-managed Kubernetes on a separate EC2 instance fleet for the backend.
D) Create AMIs from Web server VMs, deploy an EC2 Auto Scaling Group behind an Application Load Balancer, replace RabbitMQ with Amazon SQS, and migrate the Kubernetes workload to Amazon EKS.
Correct Answer #
Option A — EC2 Auto Scaling + Amazon MQ + Amazon EKS.
Step-by-Step Winning Logic #
This solution represents the optimal balance across three dimensions:
1. Protocol Compatibility (Risk Mitigation)
- Amazon MQ provides native RabbitMQ support via the AMQP 0-9-1 protocol
- Existing application code using RabbitMQ client libraries requires zero modification
- Connection strings change, but the wire protocol and broker semantics remain identical
2. Managed Service Adoption (Operational Excellence)
- Amazon EKS eliminates control plane management (patching, etcd backups, HA configuration)
- Amazon MQ handles broker replication, automated failover, and security patching
- EC2 Auto Scaling with ALB provides familiar infrastructure patterns while adding cloud-native elasticity
3. Minimal Refactoring Alignment
- VM-to-AMI approach preserves existing OS configurations, dependencies, and runtime environments
- No application redesign required (unlike Lambda migration in Option B)
- No container orchestration reinvention needed (unlike self-managed K8s in Option C)
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
Why not Option B? — Lambda Custom Runtime Migration
- Technical Feasibility Risk: Web servers typically maintain stateful connections, session management, and long-running processes—anti-patterns for Lambda’s 15-minute execution limit
- Refactoring Burden: Converting VM-based web apps to Lambda requires extensive code restructuring (violates the “minimal changes” requirement)
- Hidden Complexity: Custom runtimes demand deep container expertise and introduce debugging challenges
- Cost Efficiency: For steady-state order processing workloads, Lambda can be 3-5x more expensive than right-sized EC2 instances with Reserved Instance pricing
Why not Option C? — Self-Managed Kubernetes on EC2
- Operational Overhead Paradox: Defeats the “minimize operations” goal by requiring:
- Manual Kubernetes version upgrades and CVE patching
- DIY control plane HA setup (minimum 3 master nodes)
- Custom monitoring, logging, and disaster recovery solutions
- Hidden Costs: Staffing requirements increase by 0.5-1.0 FTE for cluster operations
- Compliance Risk: Self-managed clusters lack built-in audit logging (AWS CloudTrail integration)
Why not Option D? — Amazon SQS Instead of Amazon MQ
- Breaking Protocol Compatibility: SQS uses a proprietary HTTP API, not AMQP/RabbitMQ protocols
- Application Refactoring Required: All message producer/consumer code must be rewritten to use AWS SDK
- Feature Gaps:
- No topic exchanges, header-based routing, or priority queues (core RabbitMQ features)
- Different dead-letter queue semantics
- No transactional message guarantees (RabbitMQ’s publisher confirms)
- Migration Risk: Introduces behavioral differences that require extensive integration testing
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TD
Users([E-Commerce Customers]) -->|HTTPS| ALB[Application Load Balancer]
ALB --> ASG[EC2 Auto Scaling Group
Web Frontend VMs
from AMI]
ASG -->|AMQP 0-9-1
RabbitMQ Protocol| MQ[Amazon MQ
RabbitMQ Broker
Active/Standby HA]
MQ -->|Message Delivery| EKS[Amazon EKS Cluster
Managed Control Plane]
EKS --> Pods[Order Processing
Containerized Services
on EKS Worker Nodes]
Pods -->|Write Results| Backend[(Warehouse
Integration Systems)]
style ASG fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:#fff
style MQ fill:#C925D1,stroke:#232F3E,stroke-width:2px,color:#fff
style EKS fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:#fff
style ALB fill:#8C4FFF,stroke:#232F3E,stroke-width:2px,color:#fff
Diagram Note: The solution maintains the original three-tier architecture while replacing on-premises components with AWS managed services that preserve protocol compatibility—ALB for load distribution, Amazon MQ for RabbitMQ workloads, and EKS for Kubernetes orchestration.
🔐 The Decision Matrix #
This matrix compares all options across cost, complexity, and operational impact, making the trade-offs explicit and the correct choice logically defensible.
At the professional level, the exam expects you to justify your choice by explicitly comparing cost, complexity, and operational impact.
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| A: EC2 ASG + MQ + EKS | Medium | $1,200-$1,800 | ✅ Zero protocol changes ✅ Managed K8s control plane ✅ Native RabbitMQ compatibility ✅ Predictable EC2 RI pricing |
⚠️ EKS control plane fee ($0.10/hr = $73/mo) ⚠️ Amazon MQ minimum 2-broker HA cost ($400-$700/mo) |
| B: Lambda + API Gateway + MQ + EKS | Very High | $900-$2,500 | ✅ Serverless scaling for web tier ✅ No OS patching for frontend |
❌ Massive code refactoring required ❌ Lambda cold starts impact UX ❌ Violates “minimal changes” constraint ❌ Cost unpredictability with traffic spikes |
| C: EC2 ASG + MQ + Self-Managed K8s | High | $1,400-$2,200 | ✅ Full Kubernetes control ✅ No EKS control plane fee |
❌ Requires 3+ master nodes for HA ❌ Manual version upgrades ❌ +20 hrs/month ops burden ❌ No managed backup/DR |
| D: EC2 ASG + SQS + EKS | Medium-High | $800-$1,200 | ✅ Lowest AWS service costs ✅ Infinite SQS scaling |
❌ Breaks AMQP compatibility ❌ Requires code changes in all producers/consumers ❌ Missing RabbitMQ exchange types ❌ 2-4 week refactoring sprint |
Cost Breakdown Notes:
- Amazon MQ (RabbitMQ): Active/Standby HA with
mq.m5.large= ~$350/mo per broker × 2 = $700/mo - Amazon EKS: Control plane = $73/mo + worker nodes (3×
m5.large= ~$300/mo) = $373/mo base - EC2 Auto Scaling (Web Tier): 3×
t3.mediumwith 1-year RI = ~$45/mo each = $135/mo - Self-Managed K8s: 3× master nodes (
t3.medium) + same worker nodes = +$135/mo vs. EKS
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
“For the AWS SAP-C02 exam, when you see:
- ‘Minimal application changes’ → Avoid solutions requiring protocol rewrites (e.g., SQS replacing RabbitMQ)
- ‘RabbitMQ + Kubernetes’ → Amazon MQ (RabbitMQ mode) + EKS is the canonical lift-and-shift pattern
- ‘Reduce operational overhead’ → Favor managed services (EKS > self-managed K8s, Amazon MQ > EC2-hosted brokers)
Key Exam Trap: Option D is tempting because SQS is cheaper and simpler than Amazon MQ, but protocol compatibility trumps cost in “minimal refactoring” scenarios.”
Real World #
In production environments, we would:
-
Conduct a Protocol Audit:
- Map all RabbitMQ features actually used (exchanges, bindings, dead-letter exchanges)
- If only using simple queues → SQS migration might be viable with 2-week sprint
- If using advanced routing → Amazon MQ is non-negotiable
-
Phase the Migration:
- Phase 1: Move to Amazon MQ + self-managed K8s on EKS worker nodes (validate message broker)
- Phase 2: Migrate to full EKS-managed Kubernetes (reduce blast radius)
-
Optimize for FinOps:
- Use Amazon MQ single-instance brokers in dev/staging (50% cost reduction)
- Implement EKS Fargate for batch jobs to avoid idle worker node costs
- Evaluate EventBridge as a future replacement for simple pub/sub patterns (lower cost than Amazon MQ for event-driven architectures)
-
Build Observability First:
- Integrate Amazon MQ metrics with CloudWatch before go-live
- Deploy Prometheus + Grafana for EKS workload monitoring
- Set up AWS X-Ray tracing across the entire order processing chain
-
Disaster Recovery Considerations:
- Amazon MQ’s automated backups only retain 7 days — implement custom S3 archival for long-term message audit trails
- Test EKS cluster recreation from GitOps manifests (don’t rely solely on console configurations)
The Hidden Trade-off: While Option A is correct for the exam, real-world architects must later address:
- Amazon MQ Cost Scaling: At 10+ brokers, self-managed RabbitMQ on EC2 with reserved capacity becomes cheaper
- Kubernetes Version Drift: EKS lags 3-6 months behind upstream Kubernetes releases — acceptable for most enterprises, but critical for cutting-edge users