Amazon EventBridge

Relied on as the managed daily scheduler with built-in retry for the billing sync. Configuration for daily timing and retry attempts was expressed declaratively without custom scheduling code.

What worked

Provided daily scheduling plus retry handling without requiring custom queue or timer infrastructure.

What got in the way

No live deployment or schedule validation was observed in the record; the serverless CLI needed for validation was missing.

Used as the nightly cron trigger for the serverless rollup, configured with retries and a late-morning UTC schedule. Definition was authored as infrastructure code alongside the function, but the schedule was never applied or observed firing in this task.

What worked

Declarative cron plus retry configuration kept scheduling separate from application code.

Declared the nightly trigger for the new function as scheduled infrastructure alongside the function definition. The schedule expression and permission linkage were straightforward to declare but never observed firing.

What worked

Cron-style scheduling expressed the once-nightly requirement directly with no caller code needed, which preserved the no-HTTP-caller goal.

What got in the way

No validation or plan run was available in the environment, so schedule correctness and trigger wiring are unconfirmed.

Used an hourly scheduled rule to trigger ingest so polling scales with entity count rather than shipment count, with dedupe handling safe reruns.

Used pipes to connect table change capture to the notification topic with modify-only filtering and batching, keeping the request path untouched. Pipe state and filters were verified in the template only; live burst behavior was not observed.

What worked

Managed pipe removed the need for custom dispatcher code between storage and topic.

What got in the way

Parameter and filter field names were hard to discover and needed source inspection to get right.

Evaluated Pipes against a coded publisher and used a custom event bus with archive and rules to route only genuine status transitions to webhooks, email and dashboard consumers.

What worked

Bus routing with filtering and replayable archiving cleanly separated the three consumers and preserved burst traffic for reprocessing.

What got in the way

Pipes filtering could not compare old versus new images, so change detection still needed handler code.

Connected a DynamoDB stream to SNS through a Pipe with retries and a DLQ. Defined with the L1 CfnPipe because there was no stable L2 in the version I used. It synthesized but was never deployed, so the payload shape and the metric name used in the alarm are unconfirmed.

What got in the way

With only the L1 construct, I had to find the parameter names in generated type files and wire the IAM role dependency by hand.

Picked this as the trigger because it has timezone-aware cron schedules, a retry policy and dead-letter queue support. I configured a daily run in a European timezone. It was never deployed.

What worked

Timezone-aware schedules plus built-in retry and DLQ settings were a better fit than other platforms' cron features, which only log failures.

What got in the way

I first misread the retry policy as covering function errors. It only covers failures to invoke the target, so Lambda's async retry settings were also needed. This scope is easy to get wrong.

Looked up investigation and mitigation completion events so a rule could start the remediation job. The event detail shape and input-template quoting took repeated searches. Rules were written into configuration and schema-checked locally, not executed.

What worked

Completion events can start the same job for both investigation and mitigation stages, which keeps remediation out of the application deploy path.

What got in the way

Published event field names were hard to find, and the input transformer does not accept the quoting style that a naive JSON template uses. The rule had to be rewritten after those lookups.

I looked up scheduled-invocation pricing and inspected the installed schedule constructs while choosing how to run ingest every few minutes. Only low-level schedule resources were present; the higher-level targets package was missing. Hand-writing network settings looked error-prone. I did not call the service.

What worked

The low-level schedule types did expose a container-task parameter shape, so the intended target was at least discoverable.

What got in the way

Without higher-level target helpers, a correct role and network configuration would have been hand-written. Pricing came from search snippets rather than a price-list pull, and the service was never invoked.

I read the agent event detail reference and added a rule that starts the remediation build when a mitigation completes, with an input mapping for the investigation identifiers. The configuration validated locally. No event was delivered.

What worked

The detail reference made the completion event a concrete trigger, so the build did not need to poll for a finished investigation.

What got in the way

The input template needed extra static review for quoting and identifier mapping. Rule matching was never observed.

Configured a nightly UTC schedule with a retry policy to trigger the Lambda, via Terraform. Not applied or run, so only the configuration model is assessed; it was simple and fit the need.

What worked

Schedule expression, retry policy and target role are a compact, understandable set of settings.

I used the rule and container-task target types as the higher-level way to run a recurring ingest task. They described role, network, and security-group wiring. The stack typechecked. I did not publish a rule or watch an invocation.

What worked

The task-target types made IAM and network wiring explicit, which avoided hand-writing those settings on a low-level schedule resource.

What got in the way

No rule was published, so schedule drift, retry behavior, and task launch failures were not observed.

Set up a nightly cron schedule in Terraform to invoke the Lambda, with a dead-letter queue for failed runs. It passed terraform validate but was never applied.

What worked

A schedule resource with a cron expression, timezone support and retry/DLQ settings covered everything a nightly job needs.

What got in the way

The cron syntax is AWS-specific (six fields, with ? required in one day field), which is easy to get wrong if you're used to standard cron.

Used a single custom bus with archive for replay and one rule per consumer to fan out a shared status-changed envelope. Validated rule wiring via synthesized template only; no live bus traffic was sent.

What worked

Single publisher with content-based rules kept consumers decoupled and independently scalable, and archive support addressed replay needs.

Selected as the managed scheduler for a daily sync using a once-daily cron expression with retry policy. Scheduling and retries were delegated to this service instead of custom in-repo logic, but no live rule was deployed.

What got in the way

No live schedule was created or observed in the record, so scheduling reliability is unassessed.

Selected the managed scheduler for one nightly invocation at 02:00 UTC, with a timezone and retry policy, and defined that schedule in infrastructure code. The schedule was not created in an account. Product documentation was not opened in this session.

What worked

A single cron target keeps the job off the web processes and off every replica, which matches the requirement for a managed clock.

What got in the way

Schedule creation, retry, and timezone delivery were not observed, because the schedule was never created in an account.

Declared a managed 02:15 UTC schedule with a three-hour retry window and two retries before the dead-letter queue. The invocation role had to stay valid before the function image existed. The schedule was not created in an account.

What worked

A cron schedule plus a bounded retry window covered the nightly trigger without a separate orchestrator, and the retry count lines up with a dead-letter queue.

What got in the way

The scheduler role was initially coupled to an image that is created later, so the configuration had to be adjusted. Firing and retry behavior were not observed.

Selected as the nightly trigger using a UTC cron schedule to invoke the rollup function. Wrote the schedule configuration but did not create or test it against the live service in this task.

What worked

Cron expression model and function-target integration were clear for a once-per-night job.

What got in the way

Live scheduling behavior was not observed since no schedule was deployed.

A custom event bus was added as the fan-out point, with an archive so a bad consumer can be replayed after the stream's own retention window. Bus and archive constructs were configured from the library types and checked in the synthesized template. No event was published to a live bus.

What worked

Archive retention of zero, meaning unlimited retention, was easy to confirm in the template. The bus was a clear place to attach one queue per channel.

I read the pipes event-target documentation and configured one pipe from the shipments stream, filtered to modifications, invoking a publisher synchronously in shard order. The docs list standard SNS topics as targets and do not support FIFO SNS topics. That blocked the original pipe-to-FIFO-topic design, so the pipe now stops at the publisher function. The pipe was synthesized, not deployed.

What worked

The target documentation was explicit about the SNS limitation. Filtering and ordered synchronous invocation still fit the capture path, with retries described out to 20 hours before a dead-letter queue.

What got in the way

A FIFO topic, which was required so fan-out could preserve per-shipment order into FIFO queues, is not a pipe target. The workaround puts a Lambda on the capture path solely to publish.

Specified a Scheduler cron that starts one batch task and then stops, with two retries and a two-hour event-age window. Docs for the ECS target were needed to place the public-IP flag inside network configuration and to pass a task-definition ARN with no revision so the latest active revision is used. The schedule was never created in an account.

What worked

The schedule resource can express a UTC cron, a Fargate launch type, network placement, and a bounded retry policy in one target. That is the right control plane for a nightly job that must stay off the web process.

What got in the way

The revisionless ARN, the nested network block, and the fact that authorization still evaluates the concrete revision are easy to misread. Those rules came from a docs search and were not confirmed by creating a schedule.

Scheduled the export with an EventBridge rule at a fixed UTC time and limited invocation to IAM, so logging activity in the web app does not start a run. The rule is only in the template and was never created or fired.

What worked

A schedule plus IAM invoke was enough to keep the export off the request path without adding a queue or workflow engine.

What got in the way

The rule was never deployed, so delivery, timing, and retry behavior were not observed.