Skip to content

Latest commit

 

History

History

RDS-Aurora

README.md

RDS / Aurora

Jump to

See also kyhau/aws-notebook/Databases.

Rotate RDS database credentials automatically

(1) A typical AWS documented approach - using an appropriate retry strategy mentioned in

  • AWS Blog - How to implement single-user secret rotation using Amazon RDS admin credentials, AWS, 2024-05-21
  • AWS Blog - Rotate Amazon RDS database credentials automatically with AWS Secrets Manager, AWS, 2018-04-05
  • AWS prescriptive guidance - Rotate database credentials without restarting containers

When the secret rotates, open database connections are not dropped. While rotation is happening, there is a short period of time between when the password in the database changes and when the secret is updated. During this time, there is a low risk of the database denying calls that use the rotated credentials. You can mitigate this risk with an appropriate retry strategy. After rotation, new connections use the new credentials.

(2) Alternatively, here is another approach - blue/green strategy

This approach ensures that it never rotates the password of the user currently being used by the container, minimizing disruptions to the system’s functionality.

See https://sitereliabilityengineering.in/seamless-rds-secret-rotation-and-ecs-task-update-no-code-change-dea851210a7d

PostgreSQL

  • Mpartman - Modern partition manager for PostgreSQL (Mpartman)

MySQL

  • For RDS MySQL insert/delete event -> Lambda processing events

    1. Enable query logging with custom parameter group (for MySQL it should be the Audit Log, see MySQL database log files)
    2. Then, publish logs to CloudWatch Logs (see Publishing MySQL logs to CloudWatch Logs)
    3. Then, create CloudWatch Logs Subscription Filters with Lambda for processing the log group entries.

  • Local write forwarding with Amazon Aurora, AWS, 2023-07-31

    • can now issue transactions containing both reads and writes on Aurora read replicas and the writes will be automatically forwarded to the single writer instance for execution.
    • makes it simple to scale read workloads which require "read after write" consistency, without the need to maintain complex application logic that separates reads from writes

Aurora Serverless

  1. Performance / throughput

    Instead of provisioning and managing database servers, you specify Aurora capacity units (ACUs). Each ACU is a combination of approximately 2 gigabytes (GB) of memory, corresponding CPU, and networking. Database storage automatically scales from 10 gibibytes (GiB) to 128 tebibytes (TiB), the same as storage in a standard Aurora DB cluster.

    See https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html

RDS Proxy

Traps

  1. Ref: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-rds-dbcluster.html

After you restore a DB cluster with a SnapshotIdentifier property, you must specify the same SnapshotIdentifier property for any future updates to the DB cluster. When you specify this property for an update, the DB cluster is not restored from the DB cluster snapshot again, and the data in the database is not changed. However, if you don't specify the SnapshotIdentifier property, an empty DB cluster is created, and the original DB cluster is deleted. If you specify a property that is different from the previous snapshot restore property, a new DB cluster is restored from the specified SnapshotIdentifier property, and the original DB cluster is deleted.