Turning up Security on Database Services Part 2

​

Amazon Aurora — Overview

• Compute (instances) is separated from a distributed, shared storage layer.
• Replication is performed at the storage-segment level rather than at the database instance level.
• Aurora divides data into 10 GB segments and replicates each segment six ways across three Availability Zones (AZs) for high durability.
• Aurora supports many read replicas (commonly up to 15 readers for read scaling, depending on engine and version).

​

Authentication and credential management

• Native database credentials (username/password).
• IAM database authentication (where supported by the engine and client).
• Integration with AWS Secrets Manager for secure storage, retrieval, and rotation of credentials.

• Prefer Secrets Manager with RDS rotation for applications.
• Use IAM authentication where supported to avoid long-lived DB credentials.
• Ensure applications retrieve secrets securely (via SDKs/roles) and that secrets are never embedded in source code or environment variables without protection.

aws rds create-db-cluster \
  --db-cluster-identifier my-aurora-cluster \
  --engine aurora-postgresql \
  --master-username masteruser \
  --master-user-password 'YourSecurePassword!' \
  --kms-key-id arn:aws:kms:us-east-1:123456789012:key/abcd-1234-efgh-5678

​

Networking and connectivity

• Launch instances into specific subnets (private subnets are recommended for databases).
• Use security groups to permit traffic only from required application servers or services.
• Network ACLs apply at the subnet level and should be considered for defense in depth.
• Public accessibility can be enabled or disabled per cluster/instance; production databases should default to not publicly accessible.

• Place Aurora clusters in private subnets.
• Co-locate application tiers in the same VPC and use security groups to allow only necessary ports/protocols.
• Use NAT gateways or NAT instances for outbound access from private subnets when required.

​

VPC endpoints and PrivateLink

• Private connectivity to the Aurora control plane and related AWS services without traversing the public internet.
• Apply endpoint policies and security-group rules to limit what resources can access the endpoint.

​

Monitoring, auditing, and detection

• Amazon CloudWatch metrics and alarms for health and performance.
• AWS CloudTrail for control-plane auditing (create/delete/modify).
• Enhanced Monitoring for OS-level metrics (RDS process, CPU, memory).
• Performance Insights for query-level performance analysis and bottlenecks.
• Aurora Database Activity Streams for near-real-time activity streaming to SIEMs or analytics.

• Streams database activity in near–real-time for ingestion into downstream monitoring, SIEM, or analytics platforms.
• Useful for compliance or detecting anomalous SQL activity.

​

Encryption — at rest and in transit

• Enable encryption-at-rest by selecting a KMS CMK when creating the cluster.
• Require TLS/SSL for client connections; configure libraries to validate server certificates.
• Use Secrets Manager to store credentials and ensure applications retrieve secrets securely and over TLS.

​

Aurora Serverless

• Serverless v1 — can pause during inactivity and scales in Aurora Capacity Units (ACUs).
• Serverless v2 — provides more granular, near-instant scaling without pausing.

​

RDS Proxy — connection pooling and resiliency

• Reduces the total number of direct connections to the database by pooling.
• Improves failover behavior by holding pooled connections and retrying clients.
• Integrates with AWS Secrets Manager to retrieve and rotate credentials.
• Supports IAM authentication and exposes CloudWatch metrics and logs for observability.

• Configure RDS Proxy to use Secrets Manager; grant the proxy an IAM role or policy that allows secret retrieval.
• Use security groups to allow only application subnets or security groups to connect to the proxy endpoint.
• Ensure the proxy can reach the DB by allowing outbound from the proxy security group to the DB security group.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-db-secret"
    }
  ]
}

• Enable enhanced logging selectively — it can be helpful for debugging but may impact performance.
• Monitor CloudWatch metrics exposed by RDS Proxy for connection counts, failovers, and latency.

• Serverless functions or microservices with spiky connection patterns.
• Applications that need better failover handling without significant application changes.
• Centralized credential management using Secrets Manager.

​

Final summary — security checklist for Aurora & RDS Proxy

• Architecture: Aurora uses storage-layer replication (10 GB segments, 6-way replication across 3 AZs) for durability and read scaling.
• Authentication: Use IAM and Secrets Manager for short-lived credentials and automated rotation; fall back to native DB users where appropriate.
• Network: Place databases in private subnets, strictly limit access via security groups, and leverage interface VPC endpoints for private service connectivity.
• Monitoring & audit: Enable CloudWatch, CloudTrail, Enhanced Monitoring, Performance Insights, and Activity Streams as appropriate for detection and compliance.
• Encryption: Use KMS CMKs for encryption-at-rest and require TLS for in-transit encryption.
• RDS Proxy: Use for connection pooling, improved failover behavior, and centralized Secrets Manager integration when application patterns stress direct DB connections.

​

Links and references

• Amazon Aurora documentation: https://docs.aws.amazon.com/aurora/latest/userguide/
• Amazon RDS documentation: https://docs.aws.amazon.com/rds/
• AWS Secrets Manager: https://docs.aws.amazon.com/secretsmanager/
• AWS KMS: https://docs.aws.amazon.com/kms/