Observe with CloudWatch, Review with Well-Architected

Lantern is live: the site on CloudFront, RSVPs on Lambda and DynamoDB, events in RDS. On the old server, “monitoring” meant a volunteer noticing that the site was down. This lesson gives Lantern eyes, with Amazon CloudWatch, and then steps back to review the whole design with the AWS Well-Architected Framework.

Metrics: what is happening

AWS services publish metrics to CloudWatch automatically. Each lives in a namespace and has dimensions, such as AWS/Lambda with FunctionName=lantern-rsvp. The handful that matter most for Lantern:

Logs: why it happened

Anything a Lambda function writes to stdout lands in CloudWatch Logs, in the log group /aws/lambda/lantern-rsvp. Switch the function’s log format to JSON in its logging configuration, log objects rather than sentences, and you can query them later with CloudWatch Logs Insights:

fields @timestamp, level, message, eventId
| filter level = "ERROR"
| sort @timestamp desc
| limit 20

aws logs put-retention-policy \
  --log-group-name /aws/lambda/lantern-rsvp --retention-in-days 30

Alarms: tell a human

A metric nobody looks at is trivia. An alarm watches one metric against a threshold and changes state when it is crossed, notifying an Amazon SNS topic that emails the maintainers:

aws cloudwatch put-metric-alarm --alarm-name lantern-rsvp-errors \
  --namespace AWS/Lambda --metric-name Errors \
  --dimensions Name=FunctionName,Value=lantern-rsvp \
  --statistic Sum --period 300 --evaluation-periods 1 \
  --threshold 5 --comparison-operator GreaterThanOrEqualToThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:eu-west-1:111122223333:lantern-alerts

Five errors in five minutes pages someone; an idle night, with no data at all, does not. Lantern starts with three alarms: Lambda errors, API Gateway 5xx responses, and DynamoDB throttles. Fewer, meaningful alarms beat many noisy ones that people learn to ignore.

The Well-Architected review

The AWS Well-Architected Framework is AWS’s checklist of design questions, grouped into six pillars. The free AWS Well-Architected Tool in the console walks you through them. Here is Lantern’s first review, one finding per pillar:

Cost optimisation as a habit

Cost runs through every lesson in this course; here it is as a checklist to run on every account:

1. Delete what is idle. Old instances, unattached EBS volumes, unused Elastic IPs, forgotten NAT gateways.
2. Right-size. Use metrics, not guesses, to choose instance and function sizes.
3. Use the right pricing model. Savings Plans for the steady baseline, Spot for interruptible batch, serverless for spiky work.
4. Let data age out. S3 lifecycle rules and log retention periods.
5. Keep traffic local. Gateway endpoints for S3 and DynamoDB; CloudFront in front of anything public.
6. Tag and look. Tag every resource project=lantern, activate the tag for cost allocation, and open AWS Cost Explorer monthly. Your budget alert from lesson three is the safety net, not the plan.

That is the whole move. Lantern went from one fragile server to a set of managed pieces, each with an owner, a permission boundary, an alarm and a price you can explain. You can now set up an account safely, read and write IAM policies, pick the right core services, and ship and run a real workload, with cost and security designed in rather than bolted on.