In the previous page, we explored the cloud service model spectrum—IaaS, PaaS, and SaaS. But there's a crucial category of cloud offerings that doesn't fit neatly into this traditional classification: Managed Services.

Managed services are pre-built, fully-operated components that handle specific infrastructure or application needs. They sit somewhere between IaaS and PaaS—you're not managing bare VMs, but you're also not deploying application code. Instead, you're consuming specialized services: databases, message queues, caches, AI/ML endpoints, and dozens of other building blocks.

Understanding managed services is essential because they're the primary way modern architectures are assembled. Rather than building everything from scratch, cloud-native systems compose managed services like LEGO blocks, with custom code handling only the unique business logic.

A managed service is a cloud offering where the provider handles the operational aspects of a specific technology or capability, while you consume it through an API, console, or SDK.

The key characteristic is operational abstraction. You don't manage servers, patching, scaling, backups, or failover—the cloud provider does. You configure and consume the service; they operate it.

The Managed Service Value Proposition:

Consider running a PostgreSQL database. In a self-managed model (on IaaS), you would:

1. Provision VMs with appropriate specifications
2. Install and configure PostgreSQL
3. Set up replication for high availability
4. Configure automated backups and test recovery
5. Implement monitoring and alerting
6. Apply security patches regularly
7. Plan and execute version upgrades
8. Handle failover when instances fail
9. Scale storage and compute as data grows
10. Manage connection pooling and performance tuning

With a managed database service (like AWS RDS, Azure Database for PostgreSQL, or Google Cloud SQL), you:

1. Click a button, select PostgreSQL, choose a size
2. Connect and use

The provider handles everything else.

Cloud providers offer managed services across virtually every infrastructure and application category. Let's examine the major categories with examples from AWS, Azure, and Google Cloud:

Not all managed services are managed equally. Different services offer different levels of abstraction, with corresponding tradeoffs in control in visibility.

How it works: You specify the capacity you need (instance sizes, storage, throughput), and the service provisions dedicated resources. You pay for provisioned capacity whether you use it or not.

Examples:

• AWS RDS (specific instance sizes)
• Azure Cosmos DB (provisioned throughput mode)
• AWS ElastiCache (specific node configurations)

Characteristics:

• Predictable performance (dedicated resources)
• Predictable costs (based on provisioned capacity)
• Requires capacity planning
• Risk of over-provisioning (waste) or under-provisioning (performance issues)
• Often offers reserved pricing for long-term commitments

How it works: The service automatically scales based on actual usage. You pay only for what you consume—requests, storage, compute time.

Examples:

• AWS Lambda (per-invocation)
• DynamoDB (on-demand mode)
• Azure Cosmos DB (serverless mode)
• Google BigQuery (per-query)

Characteristics:

• True pay-per-use economics
• Automatic scaling to zero (no idle costs)
• No capacity planning required
• Potential for cost surprises at high scale
• May have cold start or latency implications
• Often has hard limits on concurrent usage

How it works: Combines provisioned baseline with automatic scaling or burst capacity.

Examples:

• DynamoDB (provisioned with auto-scaling)
• AWS Aurora Serverless v2 (minimum and maximum capacity)
• Azure SQL Database (serverless tier with auto-pause)

Characteristics:

• Balance of predictability and flexibility
• Minimum baseline capacity provides consistent performance
• Burst capacity handles peaks without manual intervention
• More complex pricing models
• Useful for workloads with predictable baselines but variable peaks

Every managed service comes with quotas and limits. Architects must understand these constraints:

Soft Limits (Can be increased):

• Account-level resource counts (e.g., max RDS instances per region)
• API rate limits (e.g., requests per second)
• Storage quotas

Hard Limits (Architectural constraints):

• Maximum item size in DynamoDB (400KB)
• Maximum message size in SQS (256KB)
• Lambda function timeout (15 minutes)
• Maximum connections per database instance

Why this matters: Hard limits often drive architectural decisions. If your service generates 1MB items, DynamoDB isn't suitable—not because of performance or cost, but because of a hard limit. Understanding these limits before designing is essential.

Understanding managed service pricing is essential for both cost optimization and architectural decisions. Let's examine common pricing models and hidden cost factors.

Let's examine the real cost components of a managed database like AWS RDS:

Direct Costs:

• Instance Hours: $0.016/hour for db.t3.micro to $6.67/hour for db.r5.24xlarge
• Storage: $0.115/GB-month for General Purpose SSD
• Backup Storage: Free up to total allocated storage, then $0.095/GB-month
• I/O (for some storage types): $0.10 per 1 million requests

Hidden Costs:

• Multi-AZ: Effectively doubles instance cost for failover capability
• Read Replicas: Each replica is an additional instance charge
• Data Transfer: Free within AZ, $0.01/GB cross-AZ, $0.09/GB to internet
• Encrypted Storage: Additional KMS costs for key operations
• Performance Insights: Free for 7-day retention, $0.02/vCPU-hour for longer
• Extended Support: Pay extra for older database versions past standard support

Reservation Discounts:

• 1-year reserved instance: ~30% discount
• 3-year reserved instance: ~50% discount
• But: Locks you into specific configuration and region

When comparing managed services to self-managed alternatives, consider the full picture:

Managed Service Costs:

• Service pricing (direct cloud costs)
• Integration development (connecting to your application)
• Training (learning the service's specific behaviors)

Self-Managed Costs:

• IaaS compute/storage for running the software
• Engineering time for installation and configuration
• Ongoing engineering time for operations (patching, monitoring, scaling)
• On-call burden and incident response
• Training (often more extensive than for managed services)
• Risk of downtime and data loss from operational errors

The break-even calculation: If a managed database costs $500/month extra versus self-managed, and your engineers cost $80/hour burdened, the managed service saves money if operations require more than 6 hours/month. Most databases require significantly more than 6 hours of operational attention monthly.

Not every managed service is appropriate for every use case. Use this framework to evaluate whether a specific managed service fits your needs:

While managed services are generally beneficial, they can be misused. Recognize these anti-patterns:

The Problem: Using every available managed service creates a complex web of dependencies, each with its own learning curve, failure modes, and billing model.

Signs:

• 30+ distinct services in your architecture diagram
• No single engineer understands the full system
• Troubleshooting requires consulting documentation for 5+ services
• Monthly bills have hundreds of line items

The Fix: Standardize on a smaller set of services. Resist adding new services unless they provide significant value over existing ones. Prefer multi-purpose services over single-purpose tools.

The Problem: Deep integration with proprietary managed services makes migration painful or impossible.

Signs:

• Business logic embedded in Step Functions state machines
• Data models designed around DynamoDB's specific limitations
• All event handling through platform-specific EventBridge rules

The Fix: Design abstraction layers for services you might replace. Use managed services for what they're good at (operations) while keeping business logic in portable code. Consider open-source compatible managed services (Managed Kafka vs proprietary alternatives).

The Problem: Forcing managed services to handle use cases they weren't designed for.

Signs:

• Complex workarounds to bypass service limitations
• Performance issues despite appropriate sizing
• 'Fighting the service' in architecture reviews

The Fix: Accept that managed services are opinionated. If your use case doesn't fit, consider self-managed alternatives or redesigning the feature. Square pegs don't fit in round holes.

The Problem: Assuming managed services never fail because 'the provider handles reliability.'

Signs:

• No retry logic for service calls
• No circuit breakers for downstream dependencies
• No degraded-mode behavior when services are unavailable
• Surprise when major outages affect your system

The Fix: Design for failure. Every managed service can have outages. Implement timeouts, retries, circuit breakers, and graceful degradation. Your SLA cannot exceed your weakest dependency.

Let's examine how managed services compose into real architectures through a practical example.

Requirement: Build a system that ingests clickstream data from web applications, enriches it with user profile information, and makes it available for real-time dashboards and batch analytics.

Architecture using AWS Managed Services:

[Web Apps] → [Kinesis Data Streams] → [Lambda (enrichment)] → [S3]
                      ↓                         ↓                ↓
                   [firehose]            [DynamoDB lookup]   [Athena queries]
                      ↓                                          ↓
              [OpenSearch] ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← [QuickSight]
                      ↑
              [Real-time dashboards]

Managed Services Used:

1. Kinesis Data Streams — Ingests millions of events per second with automatic scaling
2. Lambda — Processes each event, enriching with profile data
3. DynamoDB — Stores user profiles for low-latency enrichment lookups
4. Kinesis Data Firehose — Batches events to S3 and OpenSearch
5. S3 — Stores raw and enriched events for batch processing
6. Athena — SQL queries directly on S3 data
7. OpenSearch Service — Real-time search and dashboards
8. QuickSight — Business intelligence dashboards

What you DON'T manage:

• No Kafka clusters to operate
• No Elasticsearch cluster maintenance
• No server provisioning or scaling
• No batch job infrastructure
• No data warehouse sizing

What you DO manage:

• Lambda function code (business logic)
• DynamoDB table design and capacity
• S3 bucket policies and lifecycle rules
• Athena query optimization
• Dashboard creation and maintenance
• IAM permissions and security configuration
• Cost monitoring and optimization

The same pattern on Azure:

• Kinesis → Event Hubs
• Lambda → Azure Functions
• DynamoDB → Cosmos DB
• S3 → Blob Storage
• Athena → Data Lake Analytics / Synapse Analytics
• OpenSearch → Azure Cognitive Search
• QuickSight → Power BI Embedded

The pattern is portable even if specific services differ. Understanding managed service categories lets you translate architectures across clouds.

We've explored managed services in depth. Let's consolidate the key takeaways:

What's next:

With a solid understanding of managed services, we'll explore Cloud-Native Design—the architectural principles and patterns specifically suited to cloud environments, including scalability patterns, statelessness, and the unique characteristics of cloud-native applications.