93 lines
4.1 KiB
Markdown
93 lines
4.1 KiB
Markdown
---
|
|
title: CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
|
type: cloud-learning
|
|
source-type: video
|
|
category: DevOps & SRE/01_AWS-Landing-Zone
|
|
tags:
|
|
- AWS
|
|
- RDS
|
|
- Aurora
|
|
- PostgreSQL
|
|
- CTP
|
|
date-added: 2026-04-14
|
|
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 66_ Exposing the differences between PostgreSQL RDS and Aurora.mp4
|
|
audio-source: ""
|
|
status: summarized (Gemini 摘要)
|
|
---
|
|
|
|
# CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
|
|
|
|
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 66_ Exposing the differences between PostgreSQL RDS and Aurora.mp4`
|
|
|
|
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
|
|
|
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
|
|
|
---
|
|
|
|
## 摘要
|
|
|
|
> ## RDS vs. Aurora: Key Differences
|
|
|
|
Greg Klau presented a detailed comparison of PostgreSQL on Amazon RDS and Aurora, focusing on performance, cost, and use cases. The session covered choosing between the two, running blue-green and cross-region operations, monitoring, and network performance tweaks for high availability.
|
|
|
|
### Key Differences and Considerations
|
|
|
|
* **Minimum Size and Cost:** RDS offers smaller, cheaper instances suitable for small databases, while Aurora has a higher minimum size and cost due to its architecture.
|
|
* **Maximum Size and Performance:** Aurora scales to larger databases and offers better IO performance, making it suitable for databases exceeding 10-20 terabytes.
|
|
* **Auto Scaling:** Aurora offers auto-scaling (Serverless v2) but with limitations on instance shapes, versions, and regions.
|
|
* **Recovery Time Objective (RTO):** Aurora boasts a 30-second RTO, compared to RDS's two minutes in the event of an AZ failure.
|
|
* **Storage Flexibility:** RDS provides more storage options (GP2, GP3, provisioned IOPS, magnetic), while Aurora charges per IO.
|
|
* *With RDS, you get to choose multiple different storage mechanisms.*
|
|
* *Aurora IO is generally unbounded because they're motivated to give you as much IO as you can consume because they're charging you per IO.*
|
|
|
|
### Architectural Comparison
|
|
|
|
* **RDS:** Uses compute with attached storage (EBS). Multi-AZ setup involves another compute and storage node for failover. Replication across regions is asynchronous.
|
|
* **Aurora:** Employs six EBS volumes across three availability zones, managed by Amazon. Adding compute uses the same cluster volume, avoiding data replication for read replicas. Aurora Global allows multi-region setups with asynchronous replication.
|
|
* *With Aurora, you get six EBS volumes. They're spread across three availability zones.*
|
|
* **Endpoints:** RDS has one endpoint per cluster, while Aurora has separate writer and reader endpoints.
|
|
|
|
### Database Switchover and Failover
|
|
|
|
* **RDS:** Requires blocking access, forcing a new primary, destroying the old cluster, and rebuilding it as a standby.
|
|
* **Aurora:** Allows clean, managed switchovers using Aurora Global, without re-replication. Failover involves promoting a secondary region and re-adding the failed region as a new global cluster after it recovers.
|
|
|
|
### Blue-Green Deployments (Aurora MySQL Only)
|
|
|
|
* Aurora MySQL supports blue-green deployments for major version upgrades, creating a duplicate environment for testing before switching over. This involves logical replication to a green environment, with guardrails to prevent data loss.
|
|
|
|
### Monitoring
|
|
|
|
* Both RDS and Aurora offer monitoring options via CloudWatch, Grafana, and Performance Insights. Performance Insights provides a view of database load, query performance, and wait times.
|
|
* Aurora utilizes free local storage (ephemeral SSD) for temporary work, which is fixed per instance type. RDS uses EBS for temporary storage.
|
|
|
|
### High Availability Performance Tweaks
|
|
|
|
* Lower DNS time to live (TTL) to one second for faster failover.
|
|
* Adjust TCP Keep-Alive settings to detect database failures quickly.
|
|
* Use JDBC connection string overloading with reader and writer endpoints for resilience.
|
|
|
|
|
|
---
|
|
|
|
## 关键概念
|
|
|
|
-
|
|
|
|
---
|
|
|
|
## 行动项
|
|
|
|
-
|
|
|
|
---
|
|
|
|
## 相关视频
|
|
|
|
> 配对视频笔记链接（生成后填入）
|
|
|
|
---
|
|
|
|
*最后更新: 2026-04-14*
|