AWS Lambda

Implemented a Lambda interceptor and infrastructure configuration to reject unused MCP operations and record calls. Local interceptor tests passed. Gateway invocation ordering and failure behavior required documentation research; the function was not deployed or invoked by AgentCore.

Read official Go runtime documentation and implemented worker, dispatcher, and failure-handler functions targeting the custom Amazon Linux runtime. Local ARM64 builds succeeded. Deployment remained pending, so hosted execution and database connectivity were untested.

What worked

The documented Go runtime approach allowed reuse of the existing language and shared logic.

Installed the Lambda Go library and used its event types for queue-driven processing and tests. The worker compiled into ARM64 artifacts and passed local checks. The handlers were not executed in a deployed Lambda environment.

Implemented a Node.js thumbnail handler and packaged it for queue-triggered execution. Pricing and queue integration documentation informed the design. The build and packaged-worker smoke test passed locally; deployment and execution in Lambda remained outstanding.

Relied on event-driven function concepts for bursty thumbnail processing with per-invocation billing and retry-driven single-attempt handler; implemented portable handler with retry and drain helpers and no live deployment validation.

What worked

Worker model fit bursty image work well, and throw-for-retry plus idempotent writes kept the handler contract simple.

What got in the way

Did not deploy or invoke the live function service, so duration, memory sizing, and invocation cost behavior remain unvalidated.

Implemented dispatcher and per-channel functions for dashboard, webhooks, and email with partial batch failure handling. All functions bundled locally and infrastructure synthesized locally; functions were never invoked against the live service.

What worked

Small single-purpose functions kept retry and delivery logic isolated per channel.

Relied on as the compute layer for stream splitting, webhook delivery, and email sending, defined but not deployed in the record. Configuration for retries, batch failure reporting, and dead-letter handling read clearly and synthesized successfully.

Selected as the isolated worker runtime so untrusted generated code leaves the API process, with an event handler added for queue batches. Logic was unit tested locally, but no live deployment or invocation was shown.

What worked

Scale-to-zero execution without provisioned concurrency matched the no-idle-cost requirement.

Selected as the isolated compute platform for a nightly rollup that had to stay outside the web app and container cluster. Implemented a standalone handler with day parameter handling, per-tenant error isolation, environment-only configuration, and container image packaging. Local imports and unit tests passed, but no live deploy or invocation was run in the task.

What worked

Fit the constraint of running outside the web app while staying in the existing cloud provider, with scale-to-zero execution and a long timeout for batch work.

Added an hourly ingest function that builds entity queries, calls the search service, normalizes results, dedupes by content hash, and fans out alerts for live shipments.

What worked

Runtime bundling through the infrastructure framework worked and the synthesized template confirmed memory, timeout, runtime version, and schedule wiring.

Relied on as the managed compute target for the billing sync, with a thin handler that lets platform retry and dead-letter routing engage on failure.

What worked

Kept domain logic separate from operations concerns by leaving retry and scaling to the platform.

What got in the way

No live invocation against the real service was observed; deployment and live retry behavior were not exercised.

Selected and implemented as the hosting approach for bursty supplier webhooks to avoid scaling the steady checkout path. Handler logic and deployment configuration were completed but never deployed to a live account in the record.

What worked

Event-driven scaling, existing region and identity setup, and reuse of validation, telemetry, and storage patterns made it a clean fit.

Implemented the webhook entry point for this compute service after comparing managed options. Documentation reading and workspace context supported the choice, handler code and unit behavior were completed, but live deployment and network wiring were left to a separate infrastructure area and never observed.

What worked

The handler runtime model and configuration approach were clear enough to implement signature verification, validation, and idempotency without friction.

What got in the way

No live deployment or integration run was observed in this task, so real cold-start, scaling, and wiring behavior remain unverified.

Implemented four isolated functions for ingest and the three delivery paths with ordered event sources, partial-batch responses, and dead-letter queues. Bundles compiled but no function was invoked against live events.

What worked

Independent scaling and retries per consumer fit the burst and fault-isolation goals, and local type and bundle checks passed.

Selected as compute target for the daily job with a thin handler that returns structured success and throws to trigger managed retry. Authored deployment config locally but never deployed to the live service.

What worked

Programming model was clear: stateless handler, env-based config, throw-on-failure to engage retry and dead-letter handling.

What got in the way

No live invocation or deploy validation was performed, so runtime behavior and permissions were unverified.

Implemented the rollup as a standalone container-based function with a date-override entrypoint, kept fully separate from the web request path. Packaging and least-privilege wiring followed existing project patterns, but no live deploy or invocation was possible in the task.

What worked

The handler model fit the nightly batch shape well: default to the prior UTC day, accept an explicit override, and reject bad input instead of mis-rolling. Container packaging kept web server dependencies out.

What got in the way

Could not observe a real invocation. Final network and permission wiring was left as follow-ups, so end-to-end behavior remains unproven.

Configuration reads and a revision-guarded environment update worked. The API exposed update state clearly, and the existing environment settings could be preserved.

Implemented three small functions for stream dispatch, signed webhook delivery, and email sending, wired with filtered event sources, retries, bisect on error, and dead-letter queues.

What worked

Filtered event sources with retries and dead-letter queues kept delivery async and isolated from API latency.

What got in the way

Handlers were bundled and type-checked but never invoked against live streams or queues here, so cold starts, concurrency, and iterator age remain unobserved.

Used as the continuously running consumer invoked per queue message outside the API process. Implemented the worker handler with typed events, retry and terminal-error handling, and event-source wiring. Local gates passed; no live deployment was run in the record.

What worked

Event typing and single-message invocation model made retries, idempotency guards, and progress updates straightforward to express.

Implemented small handlers for stream publishing, signed webhook delivery, email sending and websocket notifications, with timeouts and partial-batch failure behavior for burst traffic.

What worked

Handlers kept each delivery concern isolated and retries safe, and synthesized resources matched the intended six-function design.

Designed the thumbnail worker for a queue-triggered function with idempotent overwrites and error handling covered by local tests. The trigger model fit a small team avoiding self-hosted workers, but compute duration and memory were planning assumptions.

What worked

Handler responsibilities stayed narrow: parse identifier, resolve keys, fetch, transform, and store result.

What got in the way

Worker cost and cold-start behavior were not observed without a deployed function.

Set up a VPC-attached Lambda that runs from a container image built on the official Python base image, all through Terraform and a CI deploy step. It was never deployed or run, so all I can judge is how hard it was to design and configure.

What worked

The official Python base image made packaging straightforward: copy in shared code and a handler, then set CMD. VPC attachment let the function reach a private database without exposing it.

What got in the way

The 15-minute limit forced me to budget query time carefully. Image-based functions need an image in the repository before the first apply, which is a chicken-and-egg setup step. The function also has no workload-identity equivalent to the pods, so secrets had to be loaded a different way.

Added the runtime interface client so the app's existing Docker image can also serve as a Lambda image. It installed from wheels without trouble. To confirm the handler module paths would resolve from the image's working directory, I had to read its bootstrap source, then called its handler lookup directly for all three handlers.

What worked

Wheels are published for many Python versions and architectures. Its handler resolution behaved as expected when called locally.

What got in the way

I couldn't find out from the docs how sys.path and the working directory affect handler import, so I had to read the package source.