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.
\nAWS 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:
| Service | \nMetric | \nTells you | \n
|---|---|---|
| Lambda | \nErrors, Throttles, Duration | \nFailures, capacity limits hit, slowness | \n
| API Gateway | \n5xx, 4xx, Latency | \nWhat users actually experienced | \n
| DynamoDB | \nThrottledRequests | \nRequests the table refused | \n
| CloudFront | \n5xxErrorRate, CacheHitRate (an additional metric you turn on) | \nEdge health and how well caching works | \n
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\n| filter level = "ERROR"\n| sort @timestamp desc\n| limit 20aws logs put-retention-policy \\\n --log-group-name /aws/lambda/lantern-rsvp --retention-in-days 30A 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:
\naws cloudwatch put-metric-alarm --alarm-name lantern-rsvp-errors \\\n --namespace AWS/Lambda --metric-name Errors \\\n --dimensions Name=FunctionName,Value=lantern-rsvp \\\n --statistic Sum --period 300 --evaluation-periods 1 \\\n --threshold 5 --comparison-operator GreaterThanOrEqualToThreshold \\\n --treat-missing-data notBreaching \\\n --alarm-actions arn:aws:sns:eu-west-1:111122223333:lantern-alertsFive 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.
\nThe 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:
\n| Pillar | \nLantern finding | \nAction | \n
|---|---|---|
| Operational excellence | \nDeploys are a sequence of manual commands | \nScript them; then infrastructure as code | \n
| Security | \nOne volunteer still uses an IAM user | \nMove everyone to IAM Identity Center | \n
| Reliability | \nRDS is Multi-AZ; RSVP table has no point-in-time recovery | \nTurn PITR on | \n
| Performance efficiency | \nRSVP function at 128 MB takes 900 ms | \nTest 512 MB; often faster and similar cost | \n
| Cost optimization | \nMigration EC2 instance idle since cut-over | \nSnapshot and terminate it | \n
| Sustainability | \nFunction runs on x86 | \nSwitch to arm64 (Graviton) | \n
Cost runs through every lesson in this course; here it is as a checklist to run on every account:
\nproject=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.
\n","toc":[{"id":"sec-1","text":"Metrics: what is happening","level":2},{"id":"sec-2","text":"Logs: why it happened","level":2},{"id":"sec-3","text":"Alarms: tell a human","level":2},{"id":"sec-4","text":"The Well-Architected review","level":2},{"id":"sec-5","text":"Cost optimisation as a habit","level":2}],"takeaways":["CloudWatch collects metrics, logs and alarms for AWS services automatically; Lambda writes to the /aws/lambda/Lantern’s maintainers want to hear about RSVP failures before users complain. What should they set up?
","options":[{"text":"A CloudWatch dashboard that someone checks every Friday.","why":"Dashboards are good for looking around, but nobody watches them at 9 p.m. on festival night."},{"text":"A log group with a longer retention period.","why":"Keeping logs longer helps investigation afterwards. It does not tell anyone that something is failing now."},{"text":"An AWS Budgets alert on the Lambda service.","why":"A budget tracks spend, not errors. A broken function can fail cheaply for days."},{"text":"A CloudWatch alarm on the function’sErrors metric that notifies an SNS topic with the maintainers’ email.","why":"Correct. An alarm turns a metric into a notification, so a spike in errors reaches a person within minutes."}],"answer":3},{"q":"Six months in, CloudWatch is a surprisingly large line on Lantern’s bill. Which change most likely helps?
","options":[{"text":"Set a retention period on log groups and stop logging full request bodies.","why":"Correct. Log groups never expire data by default, and ingestion and storage are charged per gigabyte."},{"text":"Turn off the default Lambda metrics.","why":"The standard Lambda metrics are published automatically and are not what makes the bill grow."},{"text":"Delete the alarms, since each one costs money.","why":"Alarms have a small monthly cost and catch real problems. Removing them saves little and loses visibility."}],"answer":0},{"q":"In a Well-Architected review, the finding “the old migration EC2 instance is still running, three weeks after cut-over” belongs mainly to which pillar?
","options":[{"text":"Performance efficiency","why":"Nothing is slow; the instance is simply not needed. Performance efficiency is about using resources effectively for the load."},{"text":"Reliability","why":"An idle server does not affect whether the site recovers from failures."},{"text":"Operational excellence","why":"Better operations would have caught it, but the direct impact is money spent for nothing."},{"text":"Cost optimization","why":"Correct. Paying for idle resources is the textbook cost finding, and the fix is to snapshot what you need and terminate the instance."}],"answer":3},{"q":"Why tag every Lantern resource with project=lantern and activate that tag for cost allocation?
Finish two commands from Lantern’s launch checklist. Step 1 sets a 30-day retention period on the RSVP function’s log group. Step 2 creates an alarm on the Lambda metric that counts failed invocations, and sends notifications to the lantern-alerts topic in the notification service that emails the maintainers.
put-: one sets a retention policy, the other a metric alarm.","The Lambda metric for failed invocations is a plural noun with a capital letter.","Alarm actions point at a topic in Amazon Simple Notification Service; look at the service part of the ARN."],"explanation":"aws logs put-retention-policy sets how long CloudWatch Logs keeps the log group’s data; without it, logs never expire and storage keeps growing on the bill. aws cloudwatch put-metric-alarm creates or updates an alarm. The Errors metric in the AWS/Lambda namespace counts invocations that ended in an error, and summing it over a 300-second period gives errors per five minutes. The alarm action is an Amazon SNS topic ARN (arn:aws:sns:...); subscribers to that topic, such as the maintainers’ email addresses, receive the notification when the alarm changes to the ALARM state.