How Reply Automates Amazon Bedrock Model Lifecycle Tracking in Production
A serverless approach to monitoring foundation model lifecycle, anticipating end-of-life events, and avoiding production disruptions — without maintaining any infrastructure. By Yassine Boujelbene, Yuvaraj Kesavan and Maelle Toy-Riont--Le Dosseur
The Problem No One Talks About Until It Hurts
In 2025, AWS deprecated several Claude 2 variants on Amazon Bedrock. Teams without automated tracking had to react under pressure — scrambling to identify which workloads were affected, find replacement models, and re-test before the retirement deadline.
This is not a rare event. It is the normal operating rhythm of a managed AI platform.
With over 100 foundation models available on Amazon Bedrock — spanning text generation, embeddings, image synthesis, and multimodal tasks — each following its own lifecycle from launch to retirement, the risk of being caught off guard is permanent. The question is not if a model you depend on will be deprecated, but when, and whether you will have enough lead time to migrate gracefully.
Manual tracking does not scale. Checking the AWS documentation weekly across dozens of models and providers is error-prone and time-consuming. What teams need is automated, structured, always-current visibility — directly inside their existing AWS observability stack.
What We Built
Reply designed a fully serverless solution that automatically monitors the lifecycle of every foundation model available on Amazon Bedrock, detects models approaching end-of-life up to 90 days in advance, and surfaces everything in a dedicated Amazon CloudWatch dashboard — with zero infrastructure to provision or maintain.
The solution runs on a weekly schedule and requires no human intervention once deployed.
Architecture Overview
The solution is built entirely on managed AWS services:
- Amazon EventBridge schedules weekly execution via a cron expression
- AWS Lambda scrapes the Amazon Bedrock documentation and extracts structured lifecycle data for every model
- Amazon CloudWatch Logs stores the structured JSON records, queryable via Logs Insights
- Amazon CloudWatch Metrics tracks operational metrics via the Embedded Metric Format (EMF)
- Amazon CloudWatch Dashboard provides visual monitoring across the full model catalog
- AWS X-Ray provides distributed tracing for debugging and performance monitoring
The entire infrastructure is defined as code via Terraform, making it reproducible across environments in minutes.
The Data Collection Strategy
Why Not Use the Native API?
Amazon Bedrock exposes a
ListFoundationModels API that returns the lifecycle status of each model (modelLifecycle.status). We evaluated it and ruled it out as the primary source for one reason: it does not return the data that actually matters for operational planning.Specifically, the API does not provide:
- EOL dates (when a model will be retired)
- Legacy transition dates (when a model moves from active to legacy)
That information only exists in the official Amazon Bedrock HTML documentation. So we scrape it.
A Two-Source Scraping Strategy
The solution combines two documentation pages:
- The model lifecycle page (
model-lifecycle.html) — contains lifecycle status, legacy dates, EOL dates, and replacement model recommendations for models that are legacy or approaching retirement - The model cards index (
model-cards.html) — links to individual model card pages, each containing model IDs, input/output modalities, and availability information for active models
Records from both sources are merged by
model_id to produce a single complete record per model.Resilience to Page Structure Changes
AWS reorganizes its documentation periodically — column order changes, tables are split or merged, new columns are added. A position-based parser would silently break.
Our parser identifies columns by header name rather than position. Every time the Lambda runs, it logs the full table structure it finds — type, column count, and header list — directly to CloudWatch Logs. If AWS changes the page structure, the anomaly is visible immediately in the logs, before it affects data quality.
This is exactly what happened recently: AWS moved active model information from a single supported-models page to individual model card pages. Because our parser logs table structures on every run, the change was detected immediately and the scraper was updated.
The Data Model
Every model record is normalized to a consistent JSON schema and logged as a structured event to CloudWatch Logs:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"scraped_at": "2026-01-07T22:00:00+00:00",
"cloud_provider": "aws",
"service": "bedrock",
"model_name": "Claude 3 Sonnet",
"model_id": "anthropic.claude-3-sonnet-20240229-v1:0",
"model_provider": "Anthropic",
"lifecycle_status": "legacy",
"category": "text",
"input_modalities": ["Text", "Image"],
"output_modalities": ["Text"],
"streaming_supported": true,
"supports_fine_tuning": true,
"supports_tool_calling": true,
"launch_date": "2024-02-29T00:00:00Z",
"legacy_date": "2024-11-21T00:00:00Z",
"eol_date": "2025-07-21T00:00:00Z",
"has_replacement": true,
"replacement_model_id": "anthropic.claude-3-5-sonnet-20241022-v2:0"
}
This normalized format is directly queryable via CloudWatch Logs Insights and drives all dashboard widgets.
Observability with AWS Lambda Powertools
The Lambda function uses AWS Lambda Powertools for production-grade observability with minimal boilerplate. Three decorators activate structured logging, EMF metrics, and X-Ray tracing simultaneously:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
from aws_lambda_powertools import Logger, Metrics, Tracer
from aws_lambda_powertools.metrics import MetricUnit
logger = Logger()
tracer = Tracer()
metrics = Metrics(namespace="BedrockModelLifecycleTracker")
def lambda_handler(event, context):
models = scraper.scrape_models()
for model in models:
logger.info("bedrock_model_lifecycle", extra={"model": model})
metrics.add_metric(
name="ModelsApproachingEOL90Days",
unit=MetricUnit.Count,
value=approaching_eol_count
)
EMF embeds metrics directly inside CloudWatch log events — no separate
PutMetricData API calls. Five metrics are published on every run:| Metric | Description |
|---|---|
| ModelsScraped | Total models collected |
| ActiveModels | Models with lifecycle_status = active |
| LegacyModels | Models with lifecycle_status = legacy |
| EOLModels | Models with lifecycle_status = eol |
| ModelsApproachingEOL90Days | Models reaching EOL within 90 days |
Handling Deduplication in Logs Insights
The Lambda runs weekly, so 30 days of logs contain four records per model. Without deduplication, every dashboard query would return duplicate rows.
CloudWatch Logs Insights has supported the
dedup command since June 2023. One line solves it:1
2
3
4
5
fields model.model_id, model.model_name, model.eol_date, model.replacement_model_id, model.lifecycle_status
| filter @message like /bedrock_model_lifecycle/
| filter model.lifecycle_status != "active"
| sort model.eol_date asc
| dedup model.model_id
dedup keeps the most recent entry per model_id, so every query always reflects current state regardless of how many weeks of history are in the log group.What the Dashboard Shows
The CloudWatch dashboard is deployed automatically and gives immediate visibility across four areas:
Operational metrics (single-value widgets, updated on every Lambda run):
- Total models tracked, active count, legacy count, EOL count, models approaching EOL in 90 days
- Model count trend over time (time series)
End-of-life tracking (table):
- Every non-active model with its EOL date, legacy date, and recommended replacement model ID — sorted by urgency
Model capabilities (table):
- Per-model: category, fine-tuning support, tool calling support, streaming support
Distribution (pie charts):
- Models by provider (Anthropic, Amazon, Meta, Mistral, Cohere, etc.)
- Models by category (text, embedding, image, audio, multimodal)
No queries to write, no log diving — the information is there every time someone opens the dashboard.
Dashboard Overview: Operational metrics and EOL models
Active models capabilities and providers
Proactive Alerting
Beyond the dashboard, CloudWatch Alarms provide proactive notification before issues reach production.
The most actionable alarm triggers when any model is detected within 90 days of end-of-life:
1
2
3
4
5
6
7
8
9
aws cloudwatch put-metric-alarm \
--alarm-name bedrock-models-approaching-eol \
--metric-name ModelsApproachingEOL90Days \
--namespace BedrockModelLifecycleTracker \
--statistic Maximum \
--period 86400 \
--evaluation-periods 1 \
--threshold 0 \
--comparison-operator GreaterThanThreshold
Combined with an SNS topic, this alarm routes to email, Slack, or any webhook — giving teams actionable lead time rather than a retrospective incident.
Results
Once deployed, the solution delivers:
- 90-day advance warning on model retirements, with the recommended successor visible in the same dashboard row
- Full catalog coverage — every foundation model on Amazon Bedrock tracked automatically, updated weekly
- Unified operational view — five key metrics, provider distribution, model capabilities, all in one CloudWatch dashboard
- Historical record — weekly snapshots create an exploitable audit trail of model catalog evolution
- Serverless economics — no servers to manage, billed strictly on usage, maintenance-free after initial deployment
Use Cases Beyond EOL Monitoring
Migration planning: The approaching-EOL widget gives a 90-day window with replacement model IDs already surfaced. Engineering teams can plan and test migrations without urgency.
Compliance and audit: Active model inventories are queryable on demand via Logs Insights, ready to feed compliance documentation or change management processes.
Cost optimization: The capabilities view lets teams match models to workload requirements. If a use case does not require fine-tuning or multimodal input, the dashboard makes it easy to identify simpler, cheaper alternatives.
What's Next
The architecture is deliberately extensible. The natural next steps we are exploring:
- Richer notifications: SNS webhooks routing to Slack or Microsoft Teams to alert product teams alongside ops teams
- CI/CD integration: Triggering an automated migration PR in GitHub Actions or AWS CodePipeline when a model used in production transitions to legacy status
- Multi-cloud coverage: Extending the same pattern to Azure OpenAI and Google Vertex AI for unified model lifecycle governance across providers
- Impact analysis: Cross-referencing lifecycle data with Amazon Bedrock invocation logs to identify exactly which workloads are exposed to EOL risk
Conclusion
This solution addresses a straightforward operational gap: teams using Amazon Bedrock in production need automated, structured visibility into model lifecycle events — and they need it early enough to act without pressure.
Built entirely on AWS managed services — Lambda, EventBridge, CloudWatch — it requires no infrastructure to maintain, deploys in minutes via Terraform, and integrates naturally into an existing AWS observability stack.
Developed by Reply as part of its AWS partnership, the solution is a concrete example of how serverless patterns enable robust operational tooling with minimal complexity.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article