7 Hard Lessons From 50+ AWS Cloud Migrations

Jerzy Kopaczewski — Sat, 01 Aug 2026 09:40:10 +0000

Every AWS migration starts with the same optimism: "We'll move everything in 6 weeks, save 40% on infra, and never think about servers again."

Then reality hits.

I've delivered 50+ AWS migrations over the past 5 years - from 3-person startups on Heroku to 200-person companies running bare metal in colocation. The technology isn't what trips people up. It's the decisions made (or not made) in the first two weeks that determine whether a migration finishes on time or drags on for months.

Here are the patterns I keep seeing.

1. You don't have a migration strategy. You have a vague plan to "move stuff."

AWS defines 7 migration strategies (the 7Rs): Retire, Retain, Rehost, Relocate, Replatform, Refactor, Repurchase. Most teams I work with initially want to "just move to AWS" without deciding which strategy applies to which workload.

The result: everything gets treated as lift-and-shift (rehost), even applications that should be retired or replaced with SaaS. Three months later you're running the same inefficient architecture on EC2 instead of your old servers, paying more, and wondering what went wrong.

What works: Spend 3-5 days classifying every workload into a strategy before touching any infrastructure. In a typical 20-app portfolio, I usually see:

3-4 applications that should be retired (nobody uses them)
5-7 that can be rehosted (internal tools, legacy systems with short remaining lifespan)
5-8 that benefit from replatforming (swap self-hosted DB for RDS, cron for Lambda)
2-3 that genuinely need re-architecting (your core product)

This classification saves months of work on things that shouldn't exist in the first place.

2. Data transfer costs are invisible until the first bill arrives

Here's the conversation I have on almost every project:

"Why is our AWS bill $3,000/month higher than the estimate?"
"Your applications talk to services still running on-premise. Every API call crosses the internet. That's egress at $0.09/GB."

Cross-AZ traffic ($0.01/GB each direction), NAT Gateway processing ($0.045/GB), and egress to the internet - these costs don't show up in the AWS pricing calculator because they depend on traffic patterns you haven't measured yet.

What works: During your PoC phase, run actual traffic through the target architecture for 1-2 weeks. Measure real egress. Then multiply by 12. If the number surprises you, architect around it:

VPC endpoints for S3 and DynamoDB (eliminates NAT Gateway charges for AWS service traffic)
Keep services that talk to each other frequently in the same AZ
If you're communicating with on-premise systems, calculate whether AWS Direct Connect ($200-500/month) pays for itself vs. internet egress

I wrote a detailed cost breakdown for each AWS component if you want to model this before starting.

3. "We'll fix security later" is the most expensive sentence in cloud

I've seen teams deploy production workloads with:

Security groups open to 0.0.0.0/0 on all ports
IAM policies with "Effect": "Allow", "Action": "*", "Resource": "*"
Unencrypted RDS instances storing PII
No CloudTrail, no GuardDuty, no audit trail

They always plan to "tighten it up after migration." They never do - until an auditor or a breach forces the issue. Retrofitting security is 3-5x more expensive than building it correctly from day one, because by then you have applications depending on the misconfiguration.

What works: Define your security baseline before migrating the first workload:

# Terraform - enforce encryption on all RDS instances
resource "aws_db_instance" "main" {
  # ...
  storage_encrypted = true
  kms_key_id        = aws_kms_key.rds.arn

  # Never do this in production:
  # publicly_accessible = true
  publicly_accessible = false
}

Enable CloudTrail, GuardDuty, and Security Hub on day one. They cost almost nothing compared to the alternative.

4. Big-bang migrations always fail in the same way

Team decides to migrate everything over a single weekend. Friday evening: "Here we go." Saturday 3 AM: the database migration hangs at 73%. Sunday: half the team is debugging DNS while the other half discovers that the payment service depends on an internal API that hasn't been migrated yet. Monday: rollback.

I've watched this happen three times. The problem isn't technical competence - it's blast radius. When everything moves at once, a single failure cascades through dependencies you didn't map.

What works: Migrate in waves:

Wave 0: Non-critical internal tools (low risk, builds team confidence)
Wave 1: Stateless services (API gateways, frontend)
Wave 2: Stateful services (databases, queues)
Wave 3: Core business logic (payment, auth)

Each wave has a defined rollback plan. Each wave reveals patterns you'll reuse in the next. The total calendar time is longer, but the actual time-to-completion is shorter because you're not spending weekends recovering from cascading failures.

5. You're treating AWS like a data centre

The classic anti-pattern: team migrates to AWS, deploys everything on oversized EC2 instances that run 24/7, never configures auto-scaling, and ends up paying more than on-premise.

Congratulations - you've built a very expensive data centre with a nicer console.

What works:

Right-size from day one. Start with the smallest instance that passes your load tests, not the largest that "feels safe."
Schedule non-production environments. Dev and staging don't need to run at 3 AM. Shutting them down outside business hours saves 65%.
Use Savings Plans for baseline load. If you know you'll always need at least 10 vCPUs of Fargate, buy a Compute Savings Plan for that baseline. You'll save 30-40% vs. on-demand.
Auto-scale everything. ECS services, EC2 Auto Scaling Groups, RDS read replicas. If it can scale, it should.

6. The PoC that wasn't

Some teams skip the Proof of Concept and go straight from assessment to building production infrastructure. Their reasoning: "We know what architecture we want, why prototype it first?"

Then they discover in month 3 that:

Aurora's connection limit doesn't work with their connection pooling approach
Cross-region latency breaks their real-time collaboration feature
The CI/CD pipeline takes 45 minutes because they chose the wrong build instance type

A 1-2 week PoC with your key workload would have surfaced all of these for the cost of a few hundred dollars in AWS charges.

What works: Build a throwaway prototype of your most complex workload. Not a production-ready environment - a minimal version that exercises the critical path: compute, database, networking, deployment. Measure performance. Measure cost. Then throw it away and build the real thing informed by actual data.

7. Nobody owns the cloud after migration

The migration team delivers, high-fives all around, and... who maintains this now?

If the answer is "we'll figure it out," you'll figure it out at 2 AM when the first production incident hits and nobody knows how to read CloudWatch dashboards or interpret ECS task failures.

What works: Define the operating model before migration:

Who gets paged when something breaks?
Who approves infrastructure changes?
Who reviews the AWS bill monthly?
Where are the runbooks for common failures?

The migration is a project. What comes after is an operating model. Plan for both.

The pattern underneath all of these

Every one of these mistakes comes from the same root cause: optimising for speed of starting over speed of finishing.

Teams that spend 1-2 weeks on assessment and PoC before writing any Terraform finish faster than teams that start building on day one. Counter-intuitive, but consistently true across every migration I've delivered.

If you're planning an AWS migration and want to avoid these patterns, I wrote a comprehensive guide covering the 7R strategies, AWS migration tools, real cost breakdowns and the full 6-phase process based on what actually works in practice.

I'm Jerzy, founder at Devopsity - we help companies migrate to AWS and build cloud-native infrastructure. If you're stuck mid-migration or evaluating whether to start one, I'm happy to chat.

I compared the real cost of running LLMs on AWS - here's when each option makes sense

Jerzy Kopaczewski — Mon, 20 Jul 2026 09:58:11 +0000

AWS gives you three ways to run LLM inference in production. I've deployed all three for clients and the decision always comes down to the same variables: volume, team size, and how much you value your weekends.

Here's the short version.

The three paths

Bedrock — Fully managed, pay-per-token. You call an API, you get tokens back. No GPUs, no cold starts, no 3am pages about OOM pods.

SageMaker Endpoints - Semi-managed. You bring your model (or a fine-tuned one), deploy it on dedicated instances, and handle autoscaling. Pay per hour whether you're serving requests or not.

Self-hosted on EKS — Full control. vLLM or TGI on GPU spot instances with Karpenter. Cheapest per token at scale, most operational overhead.

The cost crossover that matters

This is the table I keep coming back to with every client:

Volume	Bedrock (Haiku)	SageMaker (g5.xlarge)	EKS (g5.xlarge spot)
1K req/day	~$36/mo ✓	~$1,015/mo	~$674/mo
50K req/day	~$1,800/mo	~$1,015/mo	~$674/mo ✓
500K req/day	~$18,000/mo	~$6,090/mo	~$2,022/mo ✓

The crossover point where self-hosting beats Bedrock: 10,000–20,000 requests/day.

Below that, Bedrock wins on simplicity alone. Above it, you're leaving serious money on the table.

The hidden cost nobody models upfront

Teams prototype on Bedrock (smart move — it's the fastest path to production). But the cost curve isn't linear. At 10K requests/day it's cheap. At 50K it's "we need to talk to finance." At 500K it's a rearchitecture project.

The mistake is not choosing Bedrock at low volume. The mistake is not planning the exit path before you need it.

Quick decision framework

You should pick...	When...
Bedrock	No ML infra team, <50K req/day, need frontier models (Claude, Llama)
SageMaker	Fine-tuned models, predictable traffic, need dedicated VPC
EKS self-hosted	>100K req/day, open-source models, dedicated platform team

What I actually recommend

Use a hybrid. Most production systems I've deployed use:

Bedrock for complex reasoning and customer-facing chat (low volume, high quality)
Self-hosted vLLM on EKS for classification, extraction, and embeddings (high volume, cost-sensitive)

Route by task complexity. Best of both worlds.

The full breakdown

I wrote a detailed guide covering:

July 2026 pricing tables for all three options
Latency benchmarks (TTFT p50/p99)
Karpenter NodePool manifests for GPU spot instances
vLLM Kubernetes deployment YAML
SageMaker autoscaling configuration
Bedrock Guardrails for regulated workloads
eu-west-2 data residency considerations for UK organisations

👉 Full article: AWS Bedrock vs SageMaker vs Self-Hosted EKS — LLM Inference Cost, Latency & Architecture Compared

What's your setup? Are you running managed, self-hosted, or a mix? I'd be curious to hear where the cost crossover landed for your workloads.

DEV Community: Jerzy Kopaczewski