AWS Lambda deployment control room with instant rollback

Build me a deployment control room for my AWS Lambda functions. It exists to answer one question fast, under pressure, without a terminal: what version is production actually running right now, and how do I put it back. Keep the whole app focused on seeing current state and reversing a bad deploy. It is not a CI pipeline and it should not depend on GitHub or any source control system.

The main screen is a board with one row per Lambda function. Load the functions with List Functions on AWS Lambda, and for each function load its aliases with List Aliases so the environment pointers, for example prod and staging, sit side by side in the same row as columns. For each alias show the published version number it currently points at, the description of that version, and when that version last shipped. Read the per alias detail with Get Alias, and get the shipped timestamp, description, runtime and state of the pointed-at version with Get Function Configuration scoped through the Qualifier parameter so it returns the aliased version rather than the mutable draft. Use List Versions By Function to build the version picker for each function, newest published version first, each entry showing its number, description and last modified time so the person choosing a rollback target can recognise the version they want.

Next to each alias, show the health numbers that tell the person deciding whether the version that is live is actually misbehaving. Use Get Metric Statistics on Amazon CloudWatch against the AWS/Lambda namespace for the Errors and Invocations metrics, dimensioned by FunctionName, and where the metrics are published per alias also by the Resource dimension so the numbers reflect the aliased traffic. Fetch two windows for each: the last hour and the last 24 hours. Display error count, invocation count and the error rate for both windows in the row, and make a row stand out visually when the last hour error rate is meaningfully worse than the 24 hour rate, since that gap is the signature of a bad deploy that just went out. Include a manual refresh so someone watching a rollout can pull fresh numbers on demand, and show when the numbers were last fetched.

From any row I can do three things. First, roll back instantly: pick an earlier published version from the picker and repoint the alias to it with Update Alias. Second, publish: cut a new immutable version from the function's current code with Publish Version, and then optionally point an alias at it. Third, start a canary: use Update Alias with its routing configuration to give the alias weighted routing that sends a small percentage of traffic, for example 5 or 10 percent, to the new version while the rest stays on the trusted one. Once a canary is live the row must show the split plainly, for example 90 percent on version 41 and 10 percent on version 42, with controls to dial that percentage up as the error numbers hold steady, dial it back down as they worsen, promote the new version to 100 percent, or abort by returning the alias to the trusted version alone. Also offer Create Alias on any function that does not yet have an alias for an environment, so a function can be brought into the board without leaving it.

Rollbacks and canary changes require a typed reason and a confirmation step. The confirmation must restate exactly what is about to happen in plain words before anything is applied, naming the function, the alias, the version it is moving from and the version it is moving to, including the traffic split when routing is involved. After the change succeeds, post to Slack with Send a Message on Slack Bot, in a channel I configure, naming the function, the alias, the version it moved from and to, the traffic split if any, who did it and the reason they typed. That channel is the deployment audit trail, so the message should read cleanly on its own without anyone opening the app. Keep the same records in an in-app history view, newest first, filterable by function, so the recent change log is visible right where the decision gets made.

Bake in these guardrails. A rollback target must be a real published version number, never $LATEST, since $LATEST is the mutable draft pointer and cannot be a trusted rollback target. Never offer it in a version picker and reject it if it somehow arrives. Weighted routing on an alias can only split traffic between exactly two versions, so the canary controls must enforce two versions at a time and refuse anything else, and the percentage sent to the new version must stay between 0 and 100. Do not offer a canary on an alias that has no published version to fall back to.

Two technical details to handle. Publish Version is asynchronous, so after publishing, poll Get Function Configuration for the new version until State reads Active and LastUpdateStatus reads Successful before showing it as shippable or letting anyone point an alias at it. Show that wait honestly in the interface rather than pretending the version is ready. Also, when a function is addressed by full ARN or by a name carrying a qualifier, the colons must be URL encoded in the request path, otherwise the calls fail.

On design: this gets opened when something is wrong, so favour density and legibility over decoration. The current version, its age and the last hour error numbers are the most important things on the screen. Destructive and traffic-shifting actions should be reachable in one click from the row but never fire without the reason and confirmation step. If a function has many aliases beyond the environment ones, keep the row readable by featuring the environment aliases and tucking the rest behind an expander.