Let your support team run Lambda jobs without AWS access

Build me an internal console where my support and ops team can safely run backend jobs that live in AWS Lambda, without ever getting an AWS login. The AWS credentials belong to the app, not to the people using it. My team only ever sees a list of approved jobs and a form for each one.

The main screen is a catalog of saved jobs. A job is a pre-approved Lambda function wrapped in plain language: a name like Resend customer receipt or Rebuild account search index, a short description of what it does and when to use it, an input form, and a pinned version. Show the jobs as cards in a grid with a search box, and mark the sensitive ones with a clear badge. Clicking a job opens its run screen.

There is a separate admin screen where I set the catalog up. Use List Functions to show every Lambda function in the account so I can pick one, and Get Function Configuration to pull its details such as description, runtime, timeout and memory. When I pick a function, use List Versions By Function and List Aliases to show me the published versions and named aliases, and make me choose one to pin the job to. Store the qualifier with the job and always pass it when running, so the job can never hit the unpublished latest code. Show the pinned version prominently on the run screen so the person running it knows exactly what they are about to execute. On the same admin screen I define the input form: I add fields with a label, a key, a type such as text, number, checkbox or dropdown with fixed options, whether it is required, and optional help text. The app builds the request payload from those fields so my team never types raw JSON. I also mark here whether a job is sensitive.

On the run screen, the person fills in the form and gets two buttons. Test first runs a permissions and configuration check without executing anything, using Invoke with the DryRun invocation type, and reports back whether the app is allowed to run this function and version. Run executes it for real, using Invoke with the RequestResponse invocation type so the call is synchronous and we get the function's output back. Always send the pinned version or alias as the qualifier. Disable the Run button and show a spinner with the elapsed seconds while the call is in flight, because these jobs can take a while.

This next part is the most important behaviour in the whole app, so get it right. A Lambda that throws still comes back as HTTP 200 with an X-Amz-Function-Error header set to Handled or Unhandled. A tool that only checks the status code reports a broken job as a success, which is a well known and genuinely damaging bug in other internal tool builders. So do not decide success from the status code. On every run, read that header first. If it is present, treat the run as a failure: show a red failure state, pull the errorType, errorMessage and stack trace out of the returned payload, and show the error message as the headline with the trace collapsed underneath. Only treat the run as a success when the header is absent.

On success, render the function's returned payload inline as a readable result card, not a blob of JSON. Turn the returned object into labelled rows with the keys as human readable labels, format anything that looks like a timestamp, a currency amount or a URL appropriately, make URLs clickable, and render nested objects and arrays as indented sections or small tables. Keep a View raw response toggle for anyone who wants the underlying data, but the formatted card is what shows by default.

Every run, successful or failed, appends a row to a Google Sheets audit log using Append Values. Capture the timestamp, the name of the person who ran it as identified by the app, the job name, the underlying function name, the version or alias that was invoked, the input values they entered, the outcome as success or failure, the error message when there was one, and how long the run took. Include dry runs too, marked as a test, so the log shows the full picture. If the append fails, still show the run result but warn that the run was not logged.

Jobs marked sensitive also post a Slack notification with Send a Message to an engineering channel I configure, so the team sees privileged actions in real time. The message says who ran which job, against which version, with the key inputs and the outcome, and it uses a clear colour or emoji so failures stand out from successes in the channel. Only sensitive jobs post to Slack. Everything else is captured in the sheet.

Also give me a run history view inside the app showing recent runs with their job name, who ran them, version, outcome and duration, so someone can check whether a job has already been run today before running it again. Persist the job catalog, the form definitions, the pinned versions, the sensitive flags and the run history in the app's own storage. The catalog admin screen should only be reachable by me, while the run screens are open to the whole team.