# Weekly AWS Lambda health and security audit report > Every Monday at 8am, get a plain-English audit of every Lambda function in your account written to a Google Doc, with the top three fixes in Slack. - Workflow type: agent - Services: AWS Lambda, Google Docs, Slack Bot - Categories: Engineering, Operations - Published: 2026-07-17 ## What it does - Runs every Monday morning and walks through every Lambda function in your AWS account and region. - Judges each function against a health and security checklist: aging runtimes, missing tags, overly open access, publicly-invokable URLs, and aliases that were never locked to a real version. - Writes a full audit report to a fresh Google Doc, grouped by severity so the scary items are at the top. - Posts a Slack message with a link to the doc and the three fixes worth tackling this week. ## What you'll need - An AWS account connection with read access to Lambda functions, policies, and aliases. - A Google account so the workflow can create a new Google Doc each week for the report. - A Slack workspace and a channel where the weekly summary should land. ## Prompt 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. ## How to customize - Change the schedule if weekly is too much or too little (biweekly, first Monday of the month, month-end review). - Adjust what counts as a finding: promote any public function URL to high severity, ignore missing tags on legacy accounts, or add your own house rules (max timeout, minimum memory, runtime allowlist). - Point the Slack summary at a different channel, or send it as a DM to your security lead instead of a broadcast. ## FAQ ### Will this change any of my Lambda settings? No. The workflow only reads configuration, policies, and aliases. It never modifies functions, permissions, or code. ### What kinds of things does it flag? Runtimes AWS is about to retire, functions missing environment or ownership tags, resource-based policies that grant access to any principal, aliases still pointing at the rolling $LATEST version, and function URLs exposed to the internet with no auth in front. ### Where does the full report live? In a new Google Doc created fresh each Monday, so you build up a historical trail week over week. The Slack message links straight to it. ### Does this cover every AWS region? It scans the region tied to your AWS connection. If you run Lambda in multiple regions, set up a copy of the workflow per region so nothing gets missed. ### How large an account can it handle? Accounts with a few hundred functions run comfortably in minutes. Lambda's read APIs are free, so there is no meaningful AWS cost from running this every week. Use this prompt in General Input: https://www.generalinput.com/prompts/weekly-aws-lambda-health-and-security-audit-report