RDS, CloudWatch, shared responsibility and cost control

Three topics appear in nearly every entry-level cloud interview: what RDS does for you, how you would know a server is in trouble, and who is responsible for what. A fourth, cost, decides whether a manager trusts you with an account.

RDS: the managed database

RDS runs MySQL, PostgreSQL, MariaDB, SQL Server, Oracle or Aurora on hardware AWS maintains. You choose an engine, instance size and storage; AWS handles patching, automated daily backups with point-in-time restore, and failover if you enable Multi-AZ. Multi-AZ keeps a synchronous standby in another Availability Zone for availability; it is not for scaling reads. A read replica is a separate copy for read-heavy workloads and reporting. Place the instance in a private subnet with a security group that allows the database port only from the application's security group, never from 0.0.0.0/0. Worked example: an app on EC2 in sg-app needs PostgreSQL. The RDS security group gets one inbound rule: TCP 5432, source sg-app. That rule is the whole network design.

CloudWatch: metrics, logs and alarms

EC2, RDS and most services send metrics to CloudWatch automatically, such as CPUUtilization, FreeStorageSpace for RDS and DatabaseConnections. Memory and disk use inside an EC2 instance need the CloudWatch agent. An alarm watches one metric over a period and acts when a threshold is crossed. A practical starter set: CPU above 80 percent for 10 minutes, RDS free storage below 10 percent, and a status-check failure on any instance. Each alarm notifies an SNS topic that emails the on-call person. Application logs sent to CloudWatch Logs can be searched with Logs Insights.

Shared responsibility

AWS is responsible for security of the cloud: the buildings, hardware, network and the software that runs managed services. You are responsible for security in the cloud: your data, IAM users and keys, security group rules, operating system patches on EC2, encryption choices and application code. A quick test: if you could change it in the console, it is yours.

Keeping cost under control

• On-demand instances bill while running, so stop development servers at night. Stopped EC2 still pays for its disk.
• Data transfer out to the internet is charged; transfer in is usually free. Large downloads add up.
• Delete unattached EBS volumes, old snapshots and idle load balancers; they bill whether used or not.
• Set an AWS Budgets alert at a monthly figure you would be uncomfortable paying, and tag every resource with an owner.

Practice habit. Launch the smallest RDS instance, create an alarm on free storage, and trigger it by loading test data. Watch the email arrive, then delete the instance the same day. Repeat with an EC2 CPU alarm. Knowing an alarm actually fires is worth more than reading about ten of them.