Monitoring, Costs and Well-Architected Design

CloudWatch

• Metrics: CPU, network, request counts, database connections. Custom metrics from your app too.
• Logs: install the CloudWatch agent on EC2, or let Lambda and ECS send logs automatically. Set a retention period; the default "never expire" quietly grows your bill.
• Logs Insights queries logs:

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 50

• Alarms notify you (through SNS to email, Slack or a pager) when a metric crosses a threshold: ALB 5xx rate, RDS free storage, CPU credit balance, queue age.

Keeping costs under control

• Budgets with alerts at 50%, 80% and 100% of your expected spend.
• Cost Explorer by service and by tag to see what is growing.
• Tag every resource with project and environment so costs can be attributed.
• Delete what you do not use: unattached EBS volumes, old snapshots, idle load balancers, unused Elastic IPs and forgotten NAT gateways are the classic leaks.
• Right-size: if an instance averages 5% CPU, choose a smaller one.
• Savings Plans or reserved instances cut steady-state compute costs by 30 to 70% for a one- or three-year commitment.
• Watch data transfer out: serving large downloads directly from S3 or EC2 can cost more than the servers themselves; a CDN or an R2 bucket may be cheaper.

The Well-Architected Framework

AWS describes good cloud design with six pillars. Use them as a review checklist for any system:

Check yourself

• What default CloudWatch setting silently increases costs?
• Name four resources that commonly leak money.
• Which pillar asks what happens when an availability zone fails?