AWS Managed Services vs Self-Managed - a decision framework

“Managed” in the AWS ecosystem means Amazon takes responsibility for a defined operational layer - patching, high availability, backups, scaling. You configure and use. AWS maintains.

Sounds brilliant. The problem is that the boundary of responsibility (Shared Responsibility Model) runs differently for each service, and managed costs aren’t always lower than self-managed.

What AWS means by “managed”

AWS splits responsibility into layers. The more managed the service, the less you control - but also the less you need to maintain.

Key observation: there is no binary “managed vs unmanaged”. It’s a spectrum. EKS is a managed control plane, but worker nodes are still your EC2 instances (unless you use Fargate). RDS is a managed database, but you’re still responsible for query optimisation, schema design, and backup retention policy.

Decision table: managed vs self-managed by service

The following tables cover the most common architectural decisions during AWS migrations.

Databases

When managed wins: Team of ≤5 engineers, no dedicated DBA, standard OLTP workload, need for audit-compliant backups.

When self-managed wins: Heavy OLAP workload requiring tuning, exotic PostgreSQL extensions, workload requiring control over WAL shipping, budget below $500/mo for the database.

Containers and orchestration

When Fargate wins: Simple microservices without special networking requirements, teams without Kubernetes experience, workload with predictable load.

When self-managed EKS wins: GPU workload, need for Spot Instances with Karpenter, custom networking (service mesh, eBPF), need to optimise costs below $100/mo per service.

Queues and event processing

When managed wins: Almost always for standard event-driven patterns. SQS/SNS/EventBridge are amongst the cheapest and most reliable AWS services.

When self-managed wins: Event streaming requiring ordering and replay (Kafka), integration with existing on-premise ecosystem, specific protocols (AMQP with RabbitMQ).

Hidden costs of managed services

Managed doesn’t mean cheap. Three traps we see most often:

1. Data transfer through NAT Gateway

Managed services (RDS, ElastiCache, OpenSearch) placed in private subnets require a NAT Gateway to communicate with other AWS services outside the VPC. NAT cost: $0.045/GB + $0.045/h.

For a workload processing 500 GB/mo through NAT, that’s an additional $45/mo - often more than the service itself on a lower pricing tier.

Solution: VPC Endpoints (Gateway Endpoints for S3/DynamoDB - free, Interface Endpoints for the rest - $0.01/GB). Details in our NAT Gateway cost runbook.

2. Forgotten snapshot charges

RDS automated backups cost $0 until you exceed the database volume. But manual snapshots (created before maintenance, during testing) remain forever and cost $0.095/GB/mo.

Typical scenario: a team creates 3-4 snapshots “just in case” with every release. A 200 GB database × 4 snapshots = 800 GB × $0.095 = $76/mo for forgotten snapshots.

3. Multi-AZ premium you don’t need

RDS Multi-AZ doubles the instance cost. For development or staging environments, that’s money thrown away. And default AWS tutorials always enable Multi-AZ.

Check: do your dev/staging databases truly need 99.95% SLA?

When self-managed wins - scenarios from practice

Scenario 1: Startup with 3 engineers and a $2,000/mo budget

Paradoxically, for very small teams EC2 + Docker Compose can be simpler to get going than full orchestration with managed services.

Why? Because ECS/Fargate requires understanding task definitions, service discovery, IAM roles for tasks, ALB target groups, CloudWatch log groups. For 2-3 containers, that’s more complexity than docker-compose on a single EC2.

But here’s the thing: running production on bare EC2 isn’t a good use of cloud-native capabilities. No autoscaling, no automatic failover, no layer separation. It’s a “get started” solution - not a target architecture. If the team lacks the expertise to move from Docker Compose to ECS/Fargate, that’s a signal it’s worth engaging an external DevOps team to set up the architecture properly from the start - the consultancy cost pays for itself in avoided scaling headaches.

Transition point: When you exceed 5 services or need autoscaling, it’s time for managed.

Scenario 2: AI/ML workload with GPUs

For high volumes (50,000+ requests per month), self-hosted inference on EKS with Karpenter and Spot GPU instances can be 60-70% cheaper than SageMaker.

But for lower volumes - Bedrock wins financially. You pay per token with no fixed GPU instance costs. The break-even point for self-hosted inference only kicks in with predictable, continuous load where the GPU instance is utilised >60% of the time.

# Monthly cost comparison (us-east-1, August 2026)
# Break-even: ~50K+ requests/mo with average context size

# SageMaker ml.g5.xlarge (1x A10G, 24GB VRAM):
#   On-Demand: $1.006/h × 730h = $734/mo (fixed cost regardless of traffic)

# EKS + Spot g5.xlarge:
#   Spot price avg: $0.35/h × 730h = $255/mo
#   + EKS cluster fee: $73/mo
#   = $328/mo (55% cheaper, but requires an ops team)

# Bedrock (Claude 3.5 Haiku):
#   50K requests × 2K tokens input × $0.0008/1K = $80/mo
#   (no fixed costs, ideal for low volumes)

Conclusion: Bedrock for prototypes and low volumes. EKS + Spot GPU only when workload is predictable, continuous, and exceeds 50K requests per month. SageMaker sits in the middle - more convenient than raw EKS, pricier than Bedrock.

Self-managed trade-off: You manage node draining, graceful shutdown, and fallback to On-Demand. Requires Karpenter + proper interruption handling configuration.

Scenario 3: Regulatory requirements and configuration audit - the nuance

A common myth: “RDS doesn’t meet NIS2/DORA/FCA requirements because I don’t control the configuration”. In reality, AWS holds SOC 2, ISO 27001 certifications and is compliant with DORA and NIS2 requirements at the infrastructure level. RDS Parameter Groups are versioned in Terraform/CloudFormation, visible in AWS Config, and auditable via AWS CloudTrail.

Self-managed PostgreSQL with postgresql.conf in Git is not more compliant than RDS - quite the opposite, because you lose automatic encryption, certificate management, and built-in access auditing.

The only real scenario where self-managed has a regulatory advantage: when the organisation requires full isolation (dedicated hosts, custom HSM integration) or uses PostgreSQL parameters unavailable in RDS Parameter Groups (e.g. shared_preload_libraries with non-standard extensions).

When managed wins - scenarios from practice

Scenario 1: Team of 10-20, fast delivery is the priority

Every hour spent patching PostgreSQL, configuring Patroni, or debugging replication lag is an hour not spent on the product. For a team without a dedicated SRE/DBA, managed services buy engineering time.

Estimate: maintaining self-managed PostgreSQL HA costs ~8-12h/mo of an engineer (patching, monitoring, incident response, upgrades). At a rate of £100/h = £800-1,200/mo in hidden costs.

RDS Multi-AZ at ~$700/mo is cheaper than those hidden hours.

Scenario 2: Lift-and-shift migration with a hard deadline

When migrating under time pressure (hosting contract ending, end-of-support) - managed services let you move workload without redesigning:

1. EC2 + PostgreSQL on-premise → RDS (schema dump + DMS CDC)
2. VM with application → ECS Fargate (containerisation + task definition)
3. NFS share → EFS (mount point compatibility)

Zero application changes. Deadline met. Optimisation - later.

We describe the full process in our AWS migration guide.

Scenario 3: 99.99% SLA requirement

Building multi-region database failover with RPO < 1s yourself is a months-long project. Aurora Global Database does it out of the box. For workload requiring the highest availability, managed is the only sensible option (unless you have a team of 5+ SREs).

Decision framework - 5 questions before choosing

Before deciding on managed or self-managed for a specific service, answer these questions:

1. Do you have a dedicated ops/SRE team? If not → managed.
2. Does the workload require non-standard configuration unavailable in managed? (specialist DB extensions, kernel parameters, unusual networking) If yes → self-managed.
3. What’s your budget vs. cost of an engineer? If managed costs less than 10h/mo of an engineer → managed.
4. Do regulations require full isolation or non-standard parameters? If RDS + AWS Config + CloudTrail satisfies audit requirements (and in 95% of cases it does) → managed. If you need dedicated hosts or non-standard shared_preload_libraries → self-managed.
5. Are you planning a multi-cloud or exit strategy? If yes → self-managed (Kubernetes, PostgreSQL) gives portability. Managed = vendor lock-in.

Evolution path: from self-managed to managed (and back)

The typical path of a maturing organisation looks like this:

Phase 1 (startup): Docker Compose on EC2
  ↓ growth to 5+ services
Phase 2 (growth): ECS Fargate + RDS
  ↓ growth to 20+ services, need for optimisation
Phase 3 (scale): EKS + Karpenter + RDS (or Aurora)
  ↓ specialisation, demanding workload
Phase 4 (optimise): Mix - managed where it makes sense,
  self-managed where you need control/savings

There’s no single “correct” answer. There’s an answer that’s correct for your stage, team, and budget.

Our perspective

At Devopsity we manage client infrastructure on both models. We help choose, implement, and - most importantly - optimise costs regardless of the path taken.

If you’re facing the “managed or self-managed” decision and need an outside perspective - book a free consultation. We’ll walk through your workload and propose an architecture that balances cost, control, and engineering time.

Summary

Key principle: managed services buy engineering time at the cost of control and flexibility. Self-managed buys control at the cost of engineering time. Choose based on which you have more of - people or budget.