Weekly AWS Lambda health and security audit report

Every Monday at 8am, run a health and security audit across every AWS Lambda function in the connected account and region. This is a read-only audit: never modify any function, policy, or alias.

Step 1: Inventory. Use the AWS Lambda "List Functions" operation to pull every function in the account and region. Page through until you have them all before moving on.

Step 2: For each function, gather three more things from AWS Lambda before doing any analysis:

- "Get Function Configuration" for runtime, environment variables, tags, timeout, memory, and function URL config.

- "Get Policy" for the resource-based policy. AWS returns a 404 ResourceNotFoundException when no policy exists on a function; treat that as "no policy", not an error.

- "List Aliases" for every alias and the version each one points at.

Step 3: Judge each function against this checklist and decide what counts as a finding. Use your own judgement on wording, grouping, and severity - this is meant to read like an engineer wrote it, not a linter.

- Runtime nearing end of life or already deprecated (older nodejs, python, dotnet, ruby, java versions). Cross-reference the runtime string against AWS's public deprecation schedule.

- Missing environment or ownership tags. If the account uses conventions like env, owner, team, or cost-center, call out functions that are missing them.

- Resource-based policies that grant invoke (or any action) to a wildcard principal ("*" or "AWS: *") without a SourceAccount or SourceArn condition constraining who can actually call it.

- Aliases still pointing at $LATEST instead of a published version number. These defeat the purpose of aliases and make rollback impossible.

- Function URLs configured with AuthType NONE - publicly invokable over HTTPS with no auth in front. Flag every one of these; they deserve the highest severity unless the function is intentionally a public webhook receiver.

- Anything else you notice that looks risky and worth surfacing: unusually long timeouts on tiny handlers, huge memory on cold-invoked functions, functions with no code updates in years, obviously-leaky env var names. Trust your instincts.

Group findings by severity. Suggested buckets: High (public exposure via URL AuthType NONE, wildcard policies without conditions, deprecated runtimes still in prod), Medium (runtimes nearing EOL, aliases still on $LATEST), Low (missing tags, cleanup opportunities). Re-rank if your judgement disagrees - the checklist is a starting point, not a straitjacket.

Step 4: Create the report. Use Google Docs "Create Document" with a title like "AWS Lambda Weekly Audit - {ISO date}". Then use Google Docs "Batch Update Document" to populate it with:

- An intro paragraph naming the account, region, run date, and totals (functions scanned, total findings, breakdown by severity).

- One heading per severity level, in order High > Medium > Low. Skip a heading entirely if it has zero findings.

- Under each heading, one short section per finding, written in plain English. Each section names the function, describes what is wrong in a sentence or two, and suggests what fixing it looks like in concrete terms.

- A closing paragraph listing anything you considered flagging but decided not to, so the reader can sanity-check your judgement.

Reminder for Batch Update Document: it is atomic (one bad request fails the whole batch) and insert positions shift as you add content. If you build the batch incrementally with position-dependent inserts, order them from highest index to lowest, or write the whole doc in one pass using endOfSegmentLocation for appends.

Step 5: Post to Slack with the Slack Bot "Send a Message" operation. The message should include a one-line intro ("Lambda audit for {date}: {X} findings, {Y} high severity"), a link to the Google Doc, and a bulleted top-three list of what needs attention this week. Pick the three by highest severity first, breaking ties by blast radius: public exposure beats wildcard invoke beats deprecated-runtime-in-prod beats everything else.

If there are zero findings, still create the doc (a clean bill of health) and post a short "all clear" line to Slack so the team knows the audit ran.