Explain how you would manage and deploy changes to hundreds of AWS Lambda functions across multiple environments. Consider aspects such as version control, testing, and CI/CD practices.

Official answer

Inventory functions by application and owner, including runtimes, dependencies, triggers, permissions and data contracts. Use version-controlled infrastructure as code and a repository layout that matches ownership; neither one repository per function nor a particular branching model is universally required.

Build each changed application once with locked dependencies and record the artifact digest. Run unit tests, contract tests, dependency/security checks and isolated cloud integration tests for actual triggers and permissions. Promote the same artifact through environments with reviewed, environment-specific configuration.

Use separate account/role boundaries where appropriate, short-lived deployment credentials and narrowly scoped deployment permissions. Validate changes to IAM, networking and event sources as well as code. A configuration-only change can be as consequential as a code change.

Publish a function version, test it, and route eligible clients through an alias. Use bounded canary/linear rollouts with alarms and validation hooks where supported. Stage releases by application/dependency rather than updating hundreds of unrelated functions simultaneously. Preserve compatibility with both versions during the overlap.

A published version freezes code and most function configuration, but does not freeze external database schemas, secret values or IAM policies. An alias rollback affects routing; it does not undo prior side effects or data migrations. Retain artifacts and rehearse rollback/reconciliation. Track rollout health, errors, latency, drift and recovery time, with a clear owner for failures.

Function versions, weighted aliases, cloud testing