Skip to content
AP AWS Public Change Alerting

AWS RSS and Atom feeds to Slack

AWS announcements matched to configured services and risk phrases.

Watch the walkthrough Open GitHub

Each candidate names the source text that matched, the configured environments mapped to it, the Slack route, and the configuration release used to produce it.

Use

Send each team the AWS changes that match its configured stack.

A candidate names the announcement, matched service alias, risk phrase, configured environments, and Slack route. Operators verify applicability with their account tooling.

Input
Approved public AWS RSS and Atom feeds plus an immutable configuration and inventory release.
Output
A Slack review candidate with the source revision, matched text, service, risk type, Slack destination, mapped environments, and configuration release.
Boundary
Matches are potentially relevant. The service has no customer-account access and does not claim resource impact.

Architecture

From public feed to durable Slack delivery.

Lambda runs the workflow. S3 stores immutable releases and feed snapshots, DynamoDB owns source and delivery state, and SQS FIFO carries destination-ordered work.

AWS Public Change Alerting processing flow. Approved public feeds, immutable releases, and an exact application package produce route-scoped candidates. DynamoDB stores candidate and delivery state, SQS FIFO carries destination-grouped work, Slack receives messages, and the reconciler queues due work or writes delivery_unknown for expired leases.
The SVG is bound to its editable draw.io source by SHA-256. Scroll horizontally on smaller screens. Edit the draw.io source · Open the SVG export
  1. Acquire

    Fetch approved feeds with TLS, DNS and IP checks, redirect refusal, size limits, parser limits, and per-feed checkpoints.

  2. Match

    Normalize title and summary text, merge duplicate URLs across feeds, then apply service aliases, risk phrases, profiles, and routes.

  3. Persist

    Write route-scoped candidates and delivery requests before advancing the feed checkpoint.

  4. Deliver

    Queue due work by Slack destination. The worker paces requests and records Slack’s observed outcome.

  5. Recover

    Requeue due work and turn expired sending leases into delivery_unknown. Operator actions require the current state version.

Why delivery state lives in DynamoDB
Watcher stops
A saved pending_queue record lets the dispatcher finish the handoff. If the write never committed, the old checkpoint makes the next watcher run rebuild it.
Message returns
The worker reads DynamoDB first. A posted record suppresses another Slack call, including after SQS FIFO’s 5-minute send-deduplication window.
Slack says retry
For Slack 429, the worker saves the returned retry time, acknowledges the current message, and lets the dispatcher queue a later attempt.
Answer is lost
Slack may accept a request just before the worker times out. The record becomes delivery_unknown, and automatic delivery stops pending operator review.

3:41 walkthrough

Watch the deployed service and readiness review.

The video covers the Lambda workflow, live delivery, recovery, load testing, and lifecycle work. Its readiness summary starts at 2:54. Private account and Slack details are omitted.

Coverage
M1 delivery and recovery evidence, M2 lifecycle changes, and the accepted 2026-09-07 M3 readiness assessment.
Live results
4 runtime triggers enabled, 12 public-feed posts accepted by Slack, 2 recovery cases passed, 50 load messages created at 5 per minute, and alarm email receipt confirmed.
Scope
M3 passed for one reviewed environment and Slack destination at 300 delivery requests per hour.
Open MVP slides (PDF) Download MVP PowerPoint Download 1080p video Read the transcript Verify downloads

The walkthrough and downloads are copyright © 2026 Lila Brooks and licensed under Apache-2.0.

Readiness

How readiness was established.

On 7 September 2026, the owner accepted readiness for one persistent-dev deployment: one environment, one Slack destination, 4 feeds, 3 services, 4 risk rules, and a 300-delivery/hour arrival envelope.

Reuse checked evidence.

Earlier exercises covered matching, Slack and alarm receipt, a fixed 50-message load cohort, configuration rollback, and bounded database recovery. Changes since each evidence baseline received targeted checks.

Prove application rollback.

With the 4 durable executors stopped, all 5 Lambdas moved to the qualified predecessor and back. Each version produced the same 8 candidate identities from 240 items across 4 feeds. Read the L-54 record.

Restore and decide.

A reviewed plan restored normal controls. The scheduled window passed, all 28 alarms were healthy, Terraform reported no changes, and required CI passed.

Retain the limits.

Matching evidence remains thin, with 6 of 12 service and risk-type pairs carrying no historical positive. Slack outcomes can remain ambiguous. Recovery proved stopped restored-table binding and restart on primaries; live service on restored tables remains unproved. Another deployment or workload needs its own assessment.

Follow the evidence Read the final assessment
Readiness sequence: define scope, review earlier evidence, add the missing rollback proof, complete the assessment, and record the owner's scoped decision.
Open the readiness diagram

Contracts and tests

The repository checks its public contract.

Contract changes update schemas, examples, semantic validation, and regression tests together.

Behavior
Six specification chapters and 26 accepted ADRs define allowed feeds, state ownership, ID fields, delivery outcomes, and operator recovery.
Shape and identity
Nine JSON Schemas reject unknown fields in owned objects. Semantic checks resolve cross-file references; tests recompute release, candidate, and request hashes from fixture bytes.
Local gate
make check runs format, lint, type, schema, reference, corpus, unit, integration, Terraform, and page-drift checks.

Slack message

Rendered from the canonical candidate.

The worker’s render_message output is checked against the fixture and this page.

View canonical message

Canonical renderer output

Potentially relevant AWS change candidate (medium priority)

Amazon EKS Kubernetes version 1.34 available

<https://aws.amazon.com/about-aws/whats-new/2026/example-eks-update/|View source>
Amazon EKS · service-version-update

Amazon EKS now supports Kubernetes version 1.34 in all configured Regions.

The announcement matched the Amazon EKS service definition and the configured service-version-update rule.

Potentially relevant: Acme (acme-prod), Globex (globex-prod), Globex (globex-staging)

Recommended review action: Review supported Kubernetes versions and plan required cluster upgrades.

2026-07-13T12:00:00Z · a9ba064df89aa4365e6fd3e4267c656678b6fcbf0605c2044d63f927ad88ee70

Accessible fallback text

Potentially relevant AWS change candidate (medium priority)
Amazon EKS Kubernetes version 1.34 available
Amazon EKS · service-version-update
Amazon EKS now supports Kubernetes version 1.34 in all configured Regions.
Source: https://aws.amazon.com/about-aws/whats-new/2026/example-eks-update/
Reason: The announcement matched the Amazon EKS service definition and the configured service-version-update rule.
Potentially relevant: Acme (acme-prod), Globex (globex-prod), Globex (globex-staging)
Recommended review action: Review supported Kubernetes versions and plan required cluster upgrades.
2026-07-13T12:00:00Z · a9ba064df89aa4365e6fd3e4267c656678b6fcbf0605c2044d63f927ad88ee70

Technical boundaries

Rules the runtime must preserve.

The accepted ADRs define scope, identity, state ownership, recovery, and Slack outcomes.

Scope
The runtime reads public feeds and static profiles. It has no customer-account credentials, resource discovery, telemetry, or remediation access. Matches remain potentially relevant until an operator checks the account. ADR-017
Identity and handoff
Candidate IDs bind the announcement revision, service, risk, route, audience, and release. DynamoDB stores every request and outcome; SQS FIFO carries destination-ordered work. ADR-002 ADR-007
Source-state lifecycle
Active feed checkpoints do not expire. Announcement history and response-page markers use a 730-day retention window based on their latest observation. Removed feeds require reviewed retirement and compaction plans; same-name restoration requires the original URL hash. ADR-025
Recovery evidence
Both primary tables use 35-day point-in-time recovery and deletion protection. Preflight tables disable deletion protection for reviewed teardown. A CloudTrail-only role supplies digest-bound request evidence when DynamoDB omits its restore summary; that evidence does not establish table contents by itself. L-41’s dev recovery proof is complete, and all four disposable restore tables were deleted and confirmed absent. ADR-027 ADR-028
Unknown Slack outcome
An expired send lease becomes delivery_unknown and receives no automatic retry. The controlled exercise proved the transition with zero additional Slack calls; it did not prove that a naturally expired network attempt sent nothing. An operator checks Slack before closure or one audited replay; an inconclusive search leaves the record unchanged. ADR-004
Read the ADR index Read the specification

Status

Scoped readiness passed. Dev remains supervised.

D0, M1, M2, and M3 are complete. Dev is parked between live tests; the M4 short-window proof passed, and unattended use remains gated.

Milestone history
D0 · Closed One real public AWS announcement passed through the deployed service to Slack, and DynamoDB recorded posted.
M1 · Closed Scheduled delivery, both recovery cases, the fixed 50-message load run, and alarm-email receipt passed in dev. All 12 public-feed posts reached Slack.
M2 · Closed Retention, retirement, saved-response replay, and named recovery repairs were completed. The repository includes separate operator controls for retained-source replay, delivery replay, DLQ movement, package retirement, and configuration-release retirement.
M3 · Passed The owner accepted readiness on 2026-09-07 for the exact dev deployment and its 300-delivery/hour arrival envelope. Read the evidence and limits.
M4 · Proof passed Fixed observation, early parking, and deadline cleanup after loss of the local waiter passed on 2026-09-08. Unattended use remains outside this result.
Read the live-window runbook Read the M4 evidence

Reference

Read the file that owns each claim.

GOAL.md tracks status. The numbered specification defines behavior. ADRs record tradeoffs. Schemas and tests enforce file shapes and IDs.

Open the repository Read the goal Browse contracts