Managed Database Operations on AWS (2026): RDS/Aurora Buyer Guide for In-House vs MSP
Quick summary: For a fintech SaaS (6 prod databases, ~$14k/mo RDS line), scoping in-house DBA for schema + MSP for 24/7 paging cut on-call from 22 to 9 hrs/mo. Aurora Serverless v2 min ACU tuning handled tier-2 first.
Key Takeaways
- For a fintech SaaS (6 prod databases, ~$14k/mo RDS line), scoping in-house DBA for schema + MSP for 24/7 paging cut on-call from 22 to 9 hrs/mo
- Aurora Serverless v2 min ACU tuning handled tier-2 first
- RDS Blue/Green Deployments block writes on both blue and green until replication catches up, then promote green with zero data loss design (RDS FAQ)
- This post is the managed database operations buyer guide: who runs what on RDS/Aurora, when AWS-managed automation suffices, and when a partner MSP earns its fee
- It is separate from RDS vs Aurora engine selection, Postgres cost tuning, and generic MSP scope
Table of Contents
Aurora Serverless v2 platform version v3 supports scaling from 0 to 256 ACUs (each ACU ≈ 2 GiB memory plus proportional CPU/network) with 0.5 ACU increments (AWS What’s New — Serverless v2 performance). RDS Blue/Green Deployments block writes on both blue and green until replication catches up, then promote green with zero data loss design (RDS FAQ). Aurora PostgreSQL Limitless adds sharded, reference, and standard table types for OLTP scale-out (Limitless architecture docs).
This post is the managed database operations buyer guide: who runs what on RDS/Aurora, when AWS-managed automation suffices, and when a partner MSP earns its fee. It is separate from RDS vs Aurora engine selection, Postgres cost tuning, and generic MSP scope.
Artifacts: ops scope RACI, patching window worksheet CSV.
Three operating models
| Model | You operate | AWS operates | Best when |
|---|---|---|---|
| AWS-managed RDS/Aurora | Schema, queries, capacity settings | Engine patch, Multi-AZ failover, automated backup | Default for most teams |
| In-house DBA + AWS | Tuning, migrations, on-call (business hours) | Infrastructure layer above | 3–8 instances, strong platform team |
| Partner MSP overlay | App schema ownership (sometimes) | Per SOW: paging, upgrades, DR drills | 24/7 tier-0 you cannot staff |
Opinionated take: AWS already “manages” the database engine. Paying an MSP to watch automated patching is weak ROI unless they bring Blue/Green major upgrades, restore testing, and app-aware runbooks.
AWS-managed primitives: know what you already bought
| Feature | Ops value | You still own |
|---|---|---|
| Automated backups + PITR | Snapshot schedule | Restore drill, RPO proof |
| Multi-AZ / Aurora storage | Failover | Connection retry, RDS Proxy |
| Performance Insights | Wait event visibility | SQL/index remediation |
| RDS Proxy | Pooling, faster failover | Auth via Secrets Manager |
| Blue/Green Deployments | Major version staging | Switchover window + app retry |
| Aurora Serverless v2 | ACU autoscale | Min/max ACU policy |
| Aurora Limitless | Shard routing | Shard key + colocation design |
Aurora Serverless v2 capacity policy
Monitor ServerlessDatabaseCapacity and ACUUtilization in CloudWatch (Serverless v2 scaling guide):
- Set min ACU to hold working set in buffer pool for tier-0
- Set max ACU high enough for spike headroom (256 ACU ceiling on v3)
- Auto-pause to 0 ACU: dev/test only unless cold-start acceptable
Aurora Limitless: when to escalate
Use Limitless when (architecture docs):
- Table is very large or grows faster than single-instance headroom
- Workload has a natural shard key (tenant_id, region_id)
- Collocated joins on shard key are common
When NOT Limitless: < 1 TB OLTP, ad hoc cross-shard joins, or team without shard-key discipline: stay on standard Aurora.
RDS Blue/Green major upgrade playbook
- Create Blue/Green deployment from production (blue)
- Patch/upgrade green staging
- Load test green with read-only or canary traffic where supported
- Switchover: writes blocked until sync complete
- Keep blue for rollback window per your runbook
Schedule using patching-window-worksheet.csv: score patch_risk_score before picking Sunday 04:00 UTC for tier-0.
MSP SOW: normalize before signing
| SOW line | Ask |
|---|---|
| Major version upgrades | Blue/Green included? Rollback owner? |
| Aurora Limitless | Shard design in scope? |
| Restore testing | Quarterly proof or ticket-only? |
| Sev1 response | Minutes, not “best effort” |
| ElastiCache / Redis | Same SLA as RDS? Often excluded |
Fill ops-scope-raci.md and attach to procurement.
What to do this week
- Inventory every production DB and fill patching-window-worksheet.csv.
- Mark tier-0 instances and define who pages at 3 a.m. (internal vs MSP).
- Review Aurora Serverless v2 min/max ACU and disable auto-pause on latency-sensitive tiers.
- Schedule one PITR restore drill to a scratch instance (not just snapshot existence).
- If MSP quote in flight, map SOW lines to RACI R/A columns.
What this post doesn’t cover
- Engine selection (RDS vs Aurora vs DynamoDB): RDS vs Aurora guide
- Database migration cutover (DMS): migration service engagement
- Full MSP RFP process: evaluate AWS MSP
- NoSQL / DynamoDB ops model: different automation surface
We have not benchmarked Aurora I/O-Optimized vs standard storage for every worksheet row; add your I/O profile before storage mode changes.
Related: RDS consulting · Managed services
Frequently asked questions
When should we hire an MSP for database operations instead of hiring a DBA?
When should we NOT enable Aurora Serverless v2 auto-pause in production?
When should we NOT adopt Aurora Limitless?
What breaks during RDS Blue/Green switchover?
How does this differ from RDS vs Aurora engine selection?
What could go wrong comparing MSP database quotes?
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
