AWS Database Services

Databases store and manage data. In traditional on-premises environments, you install database software on servers, configure storage, set up backups, and manage patching—all yourself. AWS database services are managed services that offload these administrative tasks to AWS. You get a database endpoint and credentials, and AWS handles the underlying infrastructure. This allows you to focus on application development rather than database administration.

The CLF-C02 exam expects you to know the main categories of databases: relational (SQL) and non-relational (NoSQL). Within relational, Amazon RDS is the primary service. For non-relational, Amazon DynamoDB is the key service. There are also specialized services: Amazon Redshift for data warehousing, Amazon ElastiCache for caching, Amazon Neptune for graph databases, and Amazon DocumentDB for MongoDB-compatible document databases.

All AWS database services are launched as database instances (for RDS) or tables (for DynamoDB). You define the configuration via the AWS Management Console, CLI, or SDK. Behind the scenes, AWS provisions compute and storage resources, installs the database engine, sets up networking, and enables monitoring.

Amazon RDS supports multiple database engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon Aurora. Aurora is a MySQL/PostgreSQL-compatible engine designed by AWS for higher performance and availability. RDS automates: - Backups: Automated daily backups with point-in-time recovery up to 35 days. - Patching: Automatic minor version updates. - Replication: Multi-AZ deployments for high availability (synchronous standby replica in another Availability Zone). - Scaling: You can scale compute (CPU/RAM) and storage independently, but with some downtime for compute changes.

Amazon DynamoDB is a key-value and document database that delivers single-digit millisecond performance at any scale. It is fully managed and serverless—you don't provision servers. You create tables, define a primary key, and optionally secondary indexes. DynamoDB automatically distributes data across partitions based on the partition key. It supports: - On-demand capacity: Pay per request, ideal for unpredictable workloads. - Provisioned capacity: Specify read/write capacity units, with auto-scaling options. - Global tables: Multi-region replication for low-latency access worldwide. - DAX (DynamoDB Accelerator): In-memory cache for microsecond read latency.

Amazon Redshift is a petabyte-scale data warehouse. It uses columnar storage and massively parallel processing (MPP) to run complex analytical queries. It is not for transactional workloads. Redshift clusters consist of a leader node (coordinates queries) and compute nodes (store and process data). You can pause, resize, and use concurrency scaling.

Amazon ElastiCache provides managed Redis or Memcached. It is an in-memory cache that sits in front of a database (like RDS) to reduce read latency and offload read traffic. It is not a primary database; it stores temporary data that can be regenerated.

Amazon Neptune is a graph database for highly connected data like social networks, recommendation engines, and fraud detection. It supports property graph and RDF models.

Amazon DocumentDB is a MongoDB-compatible document database. It is useful when you need to migrate MongoDB workloads to AWS without changing code.

RDS: - Instance types: Standard (e.g., db.m5, db.t3), Memory Optimized (e.g., db.r5), Burstable (db.t3 - for dev/test). - Storage: General Purpose SSD (gp2/gp3), Provisioned IOPS (io1/io2), Magnetic (deprecated). - Multi-AZ: Synchronous standby replica in another AZ for high availability. - Read Replicas: Asynchronous copies for read scaling (up to 15 for Aurora, 5 for others). - Pricing: Pay per instance hour + storage + I/O. Reserved instances offer discounts.

DynamoDB: - Capacity modes: On-demand (pay per request) or Provisioned (pay for reserved capacity). - Read/Write Capacity Units: 1 RCU = 1 strongly consistent read per second for items up to 4 KB; 1 WCU = 1 write per second for items up to 1 KB. - DAX: Additional cost for in-memory cache nodes. - Global tables: Replication cost across regions.

Redshift: - Node types: Dense Compute (dc2) for high performance, Dense Storage (ds2) for large data volumes, RA3 with managed storage. - Pricing: Per node hour plus storage. Reserved instances available. - Concurrency Scaling: Additional clusters for burst capacity.

ElastiCache: - Node types: Similar to EC2 instance types (e.g., cache.m5, cache.r5). - Pricing: Per node hour.

On-premises: You buy servers, install database software, configure storage, manage backups, apply patches, set up replication, and monitor performance. This requires DBA expertise and capital expenditure.

AWS Managed: You choose a service and configuration. AWS handles OS patching, database patching, backup automation, hardware maintenance, and replication (if Multi-AZ). You pay as you go. The trade-off is less control over the underlying environment (e.g., you cannot modify OS parameters).

A common exam question asks: "Which AWS service is best for storing user session data?" Many candidates choose RDS because they think relational is always better. But session data is typically key-value (session ID -> session state), requires low latency, and does not need complex queries. DynamoDB is the better choice. Conversely, for a financial ledger with strict consistency and joins, RDS is correct.

aws dynamodb create-table \
    --table-name Users \
    --attribute-definitions AttributeName=UserId,AttributeType=S \
    --key-schema AttributeName=UserId,KeyType=HASH \
    --billing-mode PAY_PER_REQUEST

This creates a table with a partition key (UserId) and on-demand billing. No servers to manage.

Aurora Serverless is an on-demand, auto-scaling configuration for Amazon Aurora. It starts up, shuts down, and scales based on application demand. It is useful for intermittent or unpredictable workloads. Behind the scenes, AWS uses a fleet of instances that are pooled. You pay only for the capacity consumed (ACU - Aurora Capacity Units).

An online retailer uses Amazon RDS with MySQL to store customer accounts, product inventory, and order history. The database handles complex queries like "show all orders from last month with total over $100". As traffic grows, read-heavy pages (product details) slow down. The team adds an ElastiCache Redis cluster in front of RDS. Product details are cached with a TTL of 5 minutes. This reduces database load by 70%. Cost: RDS instance (db.r5.large, ~$200/month), ElastiCache (cache.r5.large, ~$150/month). Without caching, they would need larger RDS instances or read replicas, costing more. Misconfiguration: Setting TTL too long causes stale prices; too short reduces cache hit rate. The team monitors cache hit ratio via CloudWatch and adjusts TTL accordingly.

A mobile game stores player scores in DynamoDB. The table has partition key = game_id, sort key = player_id. Scores are updated frequently. The leaderboard query is: "top 100 players by score". To support this, the team creates a Global Secondary Index (GSI) on score attribute with descending order. DynamoDB automatically maintains the index. The game uses on-demand capacity because traffic spikes during tournaments. Cost: During normal load, ~$50/month; during tournament, ~$500/month due to high writes. Without GSI, scanning the entire table would be slow and expensive. Misconfiguration: Choosing provisioned capacity with insufficient WCUs causes throttling and failed writes. The team sets CloudWatch alarms on ThrottledRequests.

A marketing analytics company ingests billions of ad impressions daily into Amazon Redshift. They use a ds2.xlarge cluster with 10 nodes. Data is loaded via COPY command from S3. Analysts run complex queries across dimensions (user, campaign, time). Redshift's columnar storage and compression reduce storage costs. The team uses workload management (WLM) to prioritize queries. Cost: ~$2,000/month for cluster, plus S3 storage. Misconfiguration: Not distributing data properly (e.g., using EVEN distribution for a table joined on a key) leads to data skew and slow queries. The team uses KEY distribution on join keys. Also, forgetting to vacuum and analyze after large deletes degrades performance.