EC2 to Serverless Migration Services

Section 02

Technical Deep Dive

1. The Connection Exhaustion Trap

• Problem: Traditional apps open a DB connection pool on startup. Lambda functions scale to 1,000 concurrent executions instantly. 1,000 functions opening 10 connections each = 10,000 connections. Your RDS instance dies.
• Solution: Use RDS Proxy to pool connections or switch to DynamoDB (HTTP-based, connectionless).

2. Observability Costs (The Silent Killer)

• Risk: console.log is not free. CloudWatch Logs charges for ingestion and storage. A chatty loop in a Lambda function can generate terabytes of logs and a bill larger than the compute cost.
• Fix: Set log retention policies (don't keep debug logs forever) and use sampling for high-volume traces.

3. The "Lambda-lith" Pattern

• Strategy: Don't make every function a single operation (Nano-services). It's okay to run an entire Express.js or Flask app inside a single Lambda function.
• Benefit: Faster cold starts (one init), easier local testing, and simpler deployment. Break it apart only when specific endpoints need different scaling characteristics.

---

How to Choose an EC2 to Serverless Migration Partner

If you need hands-on refactoring and team upskilling: Slalom. They specialize in cloud-native engineering with practical training.

If you need high-performance serverless optimization: SoftServe. Proven track record in optimizing for cost and latency (FinTech use cases).

If you need strategic decomposition guidance: ThoughtWorks. They excel at evolutionary architecture for serverless migrations.

If you need managed operations: Rackspace. They provide ongoing operational support for serverless workloads.

If you have massive fleet refactoring needs: Accenture. Experience with enterprise-scale migrations (thousands of EC2 instances).

Red flags:

• Vendors who suggest migrating everything to Lambda (some workloads are better on Fargate/ECS)
• Not discussing RDS Proxy for database connection pooling
• Ignoring CloudWatch Logs costs (can exceed compute costs for chatty applications)
• No experience with cold start optimization techniques

---

Section 03

When to Hire EC2 to Serverless Migration Services

1. Event-Driven Workloads (File uploads, queue processing)

Your application processes files uploaded to S3, messages from SQS, or events from EventBridge. EC2 instances sit idle 90% of the time waiting for work.

Cost Impact: Paying for 24/7 EC2 ($500/month) vs Lambda that runs only on events ($20/month for 1M requests).

Trigger: CloudWatch metrics show <10% CPU utilization, workload is bursty (traffic spikes 10-100x unpredictably).

2. Unpredictable Traffic (Spiky, not constant)

Your traffic varies wildly (Black Friday spikes, irregular batch jobs). With EC2, you over-provision for peak load and waste money during troughs.

Lambda Benefit: Auto-scales from 0 to 10,000 concurrent executions in seconds. Pay only for actual execution time.

Trigger: Monthly AWS bill has 5x variance ($2K in January, $10K in November), auto-scaling groups constantly churning.

3. OS Patching Burden (Security overhead)

Your team spends 20+ hours/month patching EC2 OS, managing AMIs, and rotating instances. Every critical CVE triggers emergency maintenance.

Serverless Benefit: AWS manages OS/runtime patching. You never SSH into a server again.

Trigger: Sec audit findings for unpatched instances, team burning 1 FTE on infrastructure maintenance.

4. Cost Optimization Pressure (Need 60-80% savings)

CFO mandates cloud cost reduction. EC2 instances run 24/7 even though actual usage is <4 hours/day.

Serverless ROI: Typical savings of 60-80% for low-utilization workloads. Lambda charges per 100ms of execution vs EC2's per-hour billing.

Trigger: AWS bill >$50K/month with utilization <30%, FinOps team pressuring for optimization.

5. Microservices Learning Curve

Your team wants to adopt cloud-native patterns (event-driven, decoupled services) but lacks experience with containers, Kubernetes, or distributed systems.

Lambda Simplicity: No Docker, no orchestration, no service meshes. Just code + API Gateway + DynamoDB.

Trigger: Team attempted Kubernetes migration and failed (too complex), need simpler path to microservices.

---

Section 04

Total Cost of Ownership: EC2 vs Lambda

Hidden Costs to Consider:

• API Gateway can be expensive at scale: $3.50 per million requests. For high-throughput APIs (>10M req/month), use ALB with Lambda targets instead (70% cheaper).
• CloudWatch Logs ingestion: $0.50/GB. A chatty Lambda logging 1KB per invocation = $500/month for 1M invocations. Set aggressive log retention (7 days, not 30).
• VPC NAT Gateway: If Lambda needs internet access in VPC, NAT Gateway costs $32/mo + $0.045/GB. Use VPC Endpoints instead (90% cheaper).

Break-Even Analysis:

• Refactoring Cost: $100K-$500K (10-50 services migration)
• Annual Savings: $40K-$200K (60-80% cost reduction)
• Break-Even: 12-18 months

When NOT to use Lambda:

• Constant high-traffic APIs (>100 req/sec sustained) → Use Fargate instead
• Long-running jobs (>15 minutes) → Use Fargate or ECS
• GPU/ML workloads → Use EC2 with GPUs or SageMaker

---

Section 05

EC2 to Serverless Migration Roadmap

Phase 1: Target Workload Selection (Weeks 1-4)

Activities:

• Analyze EC2 utilization (CloudWatch metrics for CPU, network, requests/sec)
• Identify Lambda-appropriate workloads (event-driven, <15min execution, stateless)
• Calculate TCO (current EC2 cost vs projected Lambda cost)
• Prioritize: Start with low-risk, high-savings workloads (file processing, scheduled jobs)

Deliverables:

• Workload inventory with Lambda suitability score
• TCO comparison spreadsheet
• Migration priority matrix (risk vs ROI)

---

Phase 2: Pilot Migration (Months 2-3)

Activities:

• Migrate 1-2 services to Lambda (e.g., image resizing, report generation)
• Set up observability (X-Ray distributed tracing, CloudWatch dashboards)
• Implement RDS Proxy for database connection pooling
• Load testing (ensure performance parity with EC2)

Risks:

• Cold start latency (Java/C# can take 5-10 seconds on first invocation)
• Database connection exhaustion (1,000 concurrent Lambdas = 10,000 DB connections)

Deliverables:

• 2 services running on Lambda in production
• Performance comparison report (latency p50/p99)
• Cost validation (actual Lambda bill vs EC2 baseline)

Success Criteria:

• p99 latency <1 second (including cold starts)
• Cost savings >60%
• Zero database connection errors

---

Phase 3: Scale Migration (Months 4-10)

Activities:

• Migrate remaining 8-48 services using established patterns
• Implement API Gateway with request throttling and caching
• Set up Lambda Reserved Concurrency (prevent runaway costs)
• FinOps: CloudWatch Alarms for unexpected cost spikes

Risks:

• Distributed monolith (too many Lambda→Lambda sync calls create latency cascade)
• Cold start management for latency-sensitive APIs (use Provisioned Concurrency sparingly - expensive)

Deliverables:

• 80-100% of target workloads on serverless
• Cost optimization playbook (right-sizing memory, timeout tuning)
• Runbooks for common issues (throttling, timeout, cold start)

---

Phase 4: Decommission EC2 (Months 11-12)

Activities:

• Redirect 100% traffic to serverless stack
• Shut down EC2 instances
• Archive AMIs and configuration (compliance/rollback)
• Post-migration cost validation

Deliverables:

• EC2 fleet decommissioned
• Validated cost savings ($40K-$200K/year)
• 90-day hypercare support completed

---

Section 06

Post-Migration: Serverless Best Practices

Months 1-3: Cost Optimization

• Right-Size Memory: Lambda charges by GB-seconds. Test 512MB vs 1024MB vs 2048MB to find cost/performance sweet spot.
• Timeout Tuning: Don't set 15min timeout for functions that run in 10 seconds (wastes money on hung invocations).
• Reserved Concurrency: Set limits to prevent runaway costs from infinite loops or DDOS.

Months 4-6: Performance Tuning

• Cold Start Optimization: Use SnapStart (Java), keep dependencies minimal, don't import entire AWS SDK.
• Connection Pooling: Use RDS Proxy or external connection pools (redis-based) for DB-heavy functions.
• Async Invocations: Use SQS triggers instead of synchronous API Gateway for batch workloads (cheaper + more resilient).

Year 1+: Serverless Maturity

• Multi-Region: Deploy to 2+ regions with Route53 failover (99.99% availability).
• Observability: Invest in X-Ray tracing, structured logging (JSON), Metrics dashboards.
• FinOps Automation: Lambda cost anomaly detection, auto-scaling based on cost thresholds.

Warning: Keep EC2 AMIs and configs archived for 6-12 months. If Lambda migration fails catastrophically (rare but possible), you need rollback capability.

---

Section 07

Expanded FAQs

What is the difference between Lift & Shift and Cloud Native?

Answer: Lift & Shift moves VMs to EC2 "as-is" - fast deployment (weeks) but zero cost savings or agility gains. You still patch OS, manage servers. Cloud Native (Serverless) refactors apps to Lambda/Fargate - slower (months) but 60-80% cost savings and infinite scale. Only pursue if you have 12+ month timeline and budget for refactoring. For quick wins, do Lift & Shift first, then selectively refactor hot paths.

How much can we save with Serverless?

Answer: 40-70% for low-utilization workloads (<30% CPU). Real example: Customer had 20 EC2 instances ($6K/month). After migrating to Lambda, bill dropped to $1.2K/month (80% savings). WARNING: High-traffic constant workloads (>100 req/sec sustained) may cost MORE on Lambda due to API Gateway fees. Use TCO calculator and Fargate for sustained loads.

What is the biggest risk in serverless migration?

Answer: Database connection exhaustion. EC2 apps use connection pools (10-50 connections). Lambda scales to 1,000 concurrent executions instantly → 10,000 database connections → RDS dies. Solution: Use RDS Proxy ($15/month) to pool connections. Alternative: Move to DynamoDB (HTTP-based, connectionless). Budget 20% of effort on solving this.

How do we handle cold starts?

Answer: Acceptance (cheapest): Most workloads tolerate 500ms-2s cold start. Use async processing (SQS) for non-user-facing tasks. Provisioned Concurrency (expensive): Pre-warms functions ($0.015 per GB-hour). Only use for latency-critical user-facing APIs (<100ms SLA). Optimization: Use SnapStart (Java), minimize dependencies, keep functions <50MB. Reality Check: Cold starts affect 1-5% of invocations for typical workload.

How long does EC2 to serverless migration take?

Answer: 6-12 months for full migration. Pilot (2-3 months): Migrate 2 low-risk services. Scale (4-10 months): Migrate 80-100% of workloads. Decommission (11-12 months): Turn off EC2. Depends on: (1) Number of services (10 services = 6 months, 100 services = 24 months). (2) Database coupling (tight coupling = 2x longer). (3) Team serverless expertise (experienced = 0.7x, learning = 1.5x).

Lambda vs Fargate vs EC2: Which should we choose?

Answer: Lambda: Event-driven, <15min execution, unpredictable traffic. Best for: File processing, APIs with <100 req/sec, scheduled jobs. Fargate: Containers, long-running (hours/days), predictable traffic. Best for: Microservices, batch processing, constant-load APIs. EC2: Full control, GPUs, specialized hardware. Best for: ML training, HPC, legacy apps requiring OS customization. Decision: Start with Lambda for 80% of workloads, Fargate for remaining 20% that don't fit Lambda constraints.

---

Section 08

Risk Factors

The API Gateway Tax

API Gateway can be shockingly expensive at high scale ($3.50/million requests). If you have a high-throughput, low-compute API, the gateway costs might dwarf your compute savings. Consider Application Load Balancer (ALB) for Lambda triggers instead.

Cold Starts & Latency

Java and .NET functions can take seconds to initialize. For user-facing APIs, this is unacceptable. You must use SnapStart (Java), Provisioned Concurrency (money sink), or switch to Node.js/Go/Rust.

The 'Distributed Monolith'

Replacing every method call with a Lambda invocation creates a latency nightmare and a debugging hell. Do not map 1:1. Group cohesive logic into larger functions (Lambda-lith) or use Step Functions for orchestration.

---

Section 09

Feasibility Analysis

Ideal candidates

• Workloads are event-driven (file uploads, queue processing)
• Traffic is highly unpredictable/spiky
• You want to eliminate OS patching entirely

Break-even cost: $200k Talent risk: Medium. Requires a mindset shift from 'server' to 'event'.