Recap Series
- Session 01: A Developer’s Roadmap to Architecting for Agents
- Session 02: Amazon Bedrock Data Automation
- Session 03: Multi-Agent on AgentCore
- Session 04: Building Agentic AI Nova Act and Strands Agents in Practice
- Session 04: Accelerating Migration Projects with Kiro using Spec-Driven Development
- Session 06: From "Matching" to "Understanding": Personalized AI Search Practice Driven by AgentCore Memory
- Session 07: Observe to Optimize – LLM Observability to AIOps Turning real-time insights into intelligent automation
- Session 08: Deploying TEAM and Building the Best Engineering Team
- Session 09: Five Hard Lessons from Five Years of So-Called Serverless Databases
- Session 14: What if AI does my job How Q Developer CLI and Kiro have changed my daily routine
- Session 16: Velocity with Vigilance: Security Essentials for Amazon Bedrock Agent Development
- Session 26: Run OSS LLMs on a Single H100 Smarter, Cheaper, Faster
- Session 28: A Modern Unified Metadata Architecture: New Approaches to Breaking Down Data Silos
- Session 29: Serverless MediaOps: Automating Video Workflows with AI on Amazon Web Services
- Session 30: Architecting for Efficiency and Reliability with Performance Testing at Scale
- Session 31: Connecting the World Through Open Source: Practical Journey of Technology, Community and Global Developer Relations
- Session 33: Building Streaming Iceberg Tables for Real-Time Logistics Analytics
- Session 34: Accelerating Large-Scale Robot Strategy Training: An Automated Closed-Loop Architecture Based on Kiro, Trainium, and EKS
- Session 35: From Vibe to Viable with spec driven development
- Session 36: Making Cloud Cost Analysis Smarter: Building FinOps Intelligent Agents with Strands and AgentCore
- Session 37: Transform Conversational Agentic AIOps for K8s Using CNCF Kagent, K8sGPT, and Nova Sonic
Session Notes
Five Hard Lessons from Five Years of So-Called Serverless Databases
- Serverless is not Serverless. Or Vice Versa? Introduction of serverless databases on Amazon Web Services
- Aurora Serverless v1 GA (2018-08)
- DynamoDB On-Demand (2018-11)
- Amazon Timestream (2020-09)
- Aurora Serverless v2 Preview (2020-12)
- Aurora Serverless v2 GA (2022-04)
- Redshift Serverless (2022-07)
- Amazon Neptune Serverless (2022-10)
- ElastiCache Serverless (2023-11)
- Amazon DSQL (2025-05)
- DocumentDB Serverless (2025-07) What about...
- Amazon S3
- Amazon SQS
- Amazon Route 53?
Storage is Underrated
- Aurora Serverless v2 scales instantly to support even the most demanding applications, delivering up to 90% cost savings compared to provisioning for peak capacity
- USD/Month
- 2022: 3336 CPU (RI), 1960 Storage (GP), 2274 Backup
- 2023: 4682 CPU (RI), 2387 Storage (GP), 3300 Backup
- 2024: 6006 CPU (RI), 2994 Storage (GP), 5840 Backup
- 2025: 6350 CPU (RI), 3755 Storage (GP), 6952 Backup
- Aurora Serverless: min 0.5 ACU
- Aurora Provisioned: db.r8g.large
- RDS for MySQL: 400 GB + db.r8g.large How Long?
- Aurora Serverless: 3-4 seconds
- Aurora Provisioned: 2-3 seconds
- RDS for MySQL: 4-5 minutes
Predicting Costs is More Challenging
- "If you do not know how your workload performs on a serverless DB, forecasting ACU by using the baseline of a provisioned cluster is entirely useless."
- "Aurora DSQL is now Generally Available. What’s it cost? Nobody knows, especially Amazon Web Services. You get charged per DPU, which equates in the documentation to 'screw you, benchmark your workloads and find out for yourself.' Of all the pricing strategies from which to choose, I didn’t expect Amazon Web Services to pick 'completely give up.' My Aurora customers are... displeased." Corey Quinn
Compatibility Might Be a Challenge
- Compatibility?
- Wire (or Client Protocol)
- SQL / Query Language
- Feature / Behavior
- Operational / Ecosystem
- Version
- DSQL, Dynamo DB, Aurora Serverless (*)
- Both "Serverless" databases
- Horizontal vs Vertical is the Question
- Elasticity is not serverless
- "If the database still doesn't scale down to the minimum capacity configured, then stop and restart the database to reclaim any memory fragments that might have built up over time. Stopping and starting a database results in downtime, so we recommend doing this sparingly." (Amazon Web Services doc)
- Leverage serverless database, work on elasticity, and understand what runs under the hood