Ref: https://learn.cantrill.io/courses/1820301/lectures/41301431
DEMO: https://learn.cantrill.io/courses/1820301/lectures/41301432
Aurora Serverless - Key Concepts
- 💡 Serverless product → similar to AWS Fargate for ECS
- Aurora Provisioned → customers provision DB instances of a certain size and manage them
- 🔧 Aurora Serverless → no need to statically provision nor manage DB instances
- Removes some admin overhead
- Closer to DBaaS
- 💡 reminder: RDS & Aurora Provisioned are DBSERVER-aaS
- Consumption billing on a per-second basis
- Aurora Serverless clusters use Aurora Capacity Units (ACUs)
- An ACU represents a certain amount of compute & corresponding amount of memory
- Customers set Cluster MIN & MAX values for ACUs
- Cluster scales (adds/removes capacity) based on load, within the min-max range
- ‼️ Aurora Serverless v1 has been DISCONTINUED! Serverless v2 is the current model!
- Serverless v2 offers following improvements over v1:
- Granular, continuous scaling: Scales in 0.5 ACU increments, responding almost instantly to changes in load
- Always on: Unlike v1, it does not pause when idle, meaning no cold starts
- Supports Multi-AZ deployments: Ensures HA and DR
- RRs and global DBs: can add Aurora Replicas and use Aurora Global Databases
- Supports connection pooling and bursting: Handles thousands of concurrent connections more efficiently
Aurora Serverless v1 - Architecture
- 💡 I gotta rewrite this section for Aurora Serverless v2… Adrian's lecture is very outdated, referencing only Aurora Serverless v1…
Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/1300-RELATIONAL_DATABASE_SERVICE(RDS)/00_LEARNINGAIDS/AuroraServerless-1.png
- Same storage volumes as in Provisioned clusters
- Same resilience (6 storage nodes across AZs)
- ‼️ Volumes are however accessed by ACUs!! (not by provisioned servers/instances)
- Serverless v1 uses Aurora Cluster Units (ACUs) to connect to storage volumes
- ‼️ Do NOT confuse with Aurora Capacity Units, which are also abbreviated with ACU! 🤦
- Aurora Cluster Units (ACUs) characteristics:
- Allocated from a warm pool managed by AWS, shared across many AWS customers
- Stateless
- No local storage → can be quickly allocated to a Serverless cluster when required
- Once allocated, ACUs have access to cluster storage (in the same way a provisioned instance would have)
- 🔧 Number and size of ACUs constantly changing to accommodate load → dynamic nature
- If load surpasses what allocated ACUs can handle → more ACUs are allocated to cluster
- …until reaching MAX set by customer! MAX is never surpassed.
- If load is less than what allocation handles → unused ACUs deallocated from cluster
- …but never deallocating less than the MIN set by customer!
- Possible to set MIN=0 in v1 → Cluster will be paused → Billed only for consumed storage
- ‼️ With Serverless v2, this is no longer the case! MIN > 0 always, and there will always be some capacity used!
- Connections to Serverless clusters done via an AWS-managed shared proxy fleet
- Transparent for customers
- Apps connect to proxy fleet instances, who broker a connection between app and ACUs
- Fluid scaling
- App is not directly connected to the compute resource that provides the ACUs
- IN/OUT scaling without app disruptions
- 💡 Customers are only required to set MIN & MAX capacity for ACUs, they don't need to worry about connecting to ACUs
/00_LEARNINGAIDS/AuroraServerless-1.png){kind=link}