RDS & Aurora via SDK Best Practices
This is the checklist to run before and after building on RDS and Aurora from the SDK. Each item is a rule stated positively with a one-line rationale.
Busque em todas as páginas da documentação
This is the checklist to run before and after building on RDS and Aurora from the SDK. Each item is a rule stated positively with a one-line rationale.
Work top to bottom - the groups run roughly in dependency order, from provisioning outward to connections and cost. Most rules apply whether you provision from the SDK or from IaC, and whether the engine is standard RDS or Aurora.
StorageEncrypted=True at create time - you cannot enable it in place later without a snapshot-copy-restore.db_instance_available or db_cluster_available; the endpoint is unusable while creating.CreateDBCluster for storage, then CreateDBInstance per node - the first becomes the writer.maxWaitTime times out before the database is ready.Provision with encryption and managed credentials in one call.
# --- Python (boto3) ---
rds.create_db_instance(
DBInstanceIdentifier="app-db", Engine="postgres",
DBInstanceClass="db.t3.medium", AllocatedStorage=50,
MultiAZ=True, StorageEncrypted=True,
MasterUsername="appuser", ManageMasterUserPassword=True,
)// --- TypeScript (AWS SDK v3) ---
import { CreateDBInstanceCommand } from "@aws-sdk/client-rds";
await rds.send(new CreateDBInstanceCommand({
DBInstanceIdentifier: "app-db", Engine: "postgres",
DBInstanceClass: "db.t3.medium", AllocatedStorage: 50,
MultiAZ: true, StorageEncrypted: true,
MasterUsername: "appuser", ManageMasterUserPassword: true,
}));ManageMasterUserPassword so RDS stores and rotates it in Secrets Manager, or use IAM database authentication.DBSubnetGroupName and keep PubliclyAccessible false.RequireTLS=True on any RDS Proxy in front.rds, rds-data, and secretsmanager:GetSecretValue permissions each principal needs.BackupRetentionPeriod above 0 turns on daily backups plus point-in-time recovery.PreferredBackupWindow during low-traffic hours so backups do not compete with peak load.CopyDBSnapshot to a second region (with a destination-region KMS key) survives a regional event.Enable retention and checkpoint before a release.
# --- Python (boto3) ---
rds.modify_db_instance(
DBInstanceIdentifier="app-db",
BackupRetentionPeriod=7, PreferredBackupWindow="03:00-04:00",
ApplyImmediately=True,
)
rds.create_db_snapshot(DBInstanceIdentifier="app-db", DBSnapshotIdentifier="app-db-pre-release")// --- TypeScript (AWS SDK v3) ---
import { ModifyDBInstanceCommand, CreateDBSnapshotCommand } from "@aws-sdk/client-rds";
await rds.send(new ModifyDBInstanceCommand({
DBInstanceIdentifier: "app-db",
BackupRetentionPeriod: 7, PreferredBackupWindow: "03:00-04:00",
ApplyImmediately: true,
}));
await rds.send(new CreateDBSnapshotCommand({ DBInstanceIdentifier: "app-db", DBSnapshotIdentifier: "app-db-pre-release" }));CreateDBInstanceReadReplica (RDS) or extra reader instances (Aurora) offload read-heavy traffic.FailoverDBCluster (or RebootDBInstance with ForceFailover) in a maintenance window.Add a reader and route reads to the reader endpoint.
# --- Python (boto3) ---
rds.create_db_instance(
DBInstanceIdentifier="app-aurora-reader-2", DBClusterIdentifier="app-aurora",
Engine="aurora-postgresql", DBInstanceClass="db.r6g.large",
)
cl = rds.describe_db_clusters(DBClusterIdentifier="app-aurora")["DBClusters"][0]
print("reads ->", cl["ReaderEndpoint"], " writes ->", cl["Endpoint"])// --- TypeScript (AWS SDK v3) ---
import { CreateDBInstanceCommand, DescribeDBClustersCommand } from "@aws-sdk/client-rds";
await rds.send(new CreateDBInstanceCommand({
DBInstanceIdentifier: "app-aurora-reader-2", DBClusterIdentifier: "app-aurora",
Engine: "aurora-postgresql", DBInstanceClass: "db.r6g.large",
}));
const dc = await rds.send(new DescribeDBClustersCommand({ DBClusterIdentifier: "app-aurora" }));
console.log("reads ->", dc.DBClusters![0].ReaderEndpoint, " writes ->", dc.DBClusters![0].Endpoint);psycopg2 / pg); the SDK only manages infrastructure.ExecuteStatement runs SQL over HTTPS with no connection - ideal for high-fan-out Lambda.Point the driver at the proxy endpoint, not the database.
# --- Python (boto3) ---
# Create the pool once (control plane); drivers then connect to the proxy endpoint.
rds.create_db_proxy(
DBProxyName="app-proxy", EngineFamily="POSTGRESQL",
Auth=[{"AuthScheme": "SECRETS",
"SecretArn": "arn:aws:secretsmanager:us-east-1:111122223333:secret:app-db-abc"}],
RoleArn="arn:aws:iam::111122223333:role/rds-proxy-secrets-role",
VpcSubnetIds=["subnet-aaa", "subnet-bbb"], RequireTLS=True,
)// --- TypeScript (AWS SDK v3) ---
import { CreateDBProxyCommand } from "@aws-sdk/client-rds";
// Create the pool once (control plane); drivers then connect to the proxy endpoint.
await rds.send(new CreateDBProxyCommand({
DBProxyName: "app-proxy", EngineFamily: "POSTGRESQL",
Auth: [{ AuthScheme: "SECRETS",
SecretArn: "arn:aws:secretsmanager:us-east-1:111122223333:secret:app-db-abc" }],
RoleArn: "arn:aws:iam::111122223333:role/rds-proxy-secrets-role",
VpcSubnetIds: ["subnet-aaa", "subnet-bbb"], RequireTLS: true,
}));DBInstanceClass to real CPU and memory use; oversized instances waste money idle.ApplyImmediately false for changes that can wait, to avoid surprise downtime.Separating the planes: the SDK provisions and manages the database, and your app queries it with a driver (except through the Aurora Data API). Once you know which plane a task is on, the right API - control-plane rds call or data-plane driver - is obvious.
Never store it in code. Use ManageMasterUserPassword so RDS keeps and rotates the credential in Secrets Manager, or use IAM database authentication for short-lived tokens. Your app reads the secret at connect time.
No. Automated backups are deleted with the instance, aside from an optional final snapshot. For anything you must keep, take a manual snapshot, which persists independently until you delete it, and copy it cross-region for disaster recovery.
Not with Multi-AZ - its standby serves no reads. Add RDS read replicas or Aurora reader instances and route read-only queries to the reader endpoint, reserving the writer for writes and read-after-write.
Use RDS Proxy to pool connections for driver-based apps under connection pressure. Use the Aurora Data API to run SQL over HTTPS with no connections at all, which suits high-fan-out serverless callers on Aurora. Both address connection exhaustion from opposite directions.
Provisioning is asynchronous and the resource is still creating. Wait on db_instance_available or db_cluster_available before reading the endpoint, and give the waiter a generous timeout because Multi-AZ and large storage take longer.
Not in place. Encryption at rest is a create-time choice. To encrypt an existing unencrypted database, snapshot it, copy the snapshot with encryption enabled, and restore into a new encrypted database.
Connect to cluster (writer/reader) endpoints rather than instance DNS so they repoint automatically, front the database with RDS Proxy to smooth the connection blip, and rehearse failover with FailoverDBCluster in a maintenance window.
Consider Aurora Serverless v2, which scales capacity automatically and bills for what spiky or unpredictable workloads actually consume. For steady, forecastable load, a right-sized provisioned instance is usually cheaper.
Mostly yes. Encryption, private networking, managed credentials, backups and retention, Multi-AZ and replicas, and tagging are architectural habits that hold whether you provision from the SDK or from CloudFormation, CDK, or Terraform.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última atualização: 23 de jul. de 2026