Type something to search...
to navigateto selectESC to close

AWS production readiness review

44 checks across 8 areas, before your AI workload meets production traffic.

We review your AWS workload from the model layer down: quotas and fallbacks, agent permissions, access, backups, releases and on-call. Every check follows published AWS guidance, and every check ends in a rating.

You finish with a written report and an action plan that names what has to change before launch, in order.

  • 01

    Walk through the architecture

    Your team shows us what runs, what it depends on, and the traffic you are planning for.

  • 02

    Check the account

    With read-only access, we verify each check against what is deployed.

  • 03

    Rate every check

    You receive the report and the action plan, and we go through both with your team.

Tell us what you are launching

A rough shape is enough to start. We reply within two working days with how the review would apply to your setup.

The first conversation needs no access to your account.

What we check

The first two areas cover the model and agent layer of an AI product. The rest apply to any production workload on AWS. Each area follows the AWS guidance linked beside it.

01 Model layer For workloads calling Bedrock, SageMaker endpoints or another model API. Follows Well-Architected Generative AI Lens
  • Models called only from the backend, under a role scoped to the models in use
  • Model quotas cover projected peak requests and tokens per minute
  • Throttled calls back off, then fall back to a second model, a queue or a clear message
  • Prompts versioned and deployed through the same pipeline as code
  • An evaluation set runs before any prompt or model change ships
  • Input validation and output filtering on user-facing paths
  • A deliberate decision on model invocation logging and the user data it holds
02 Agents and tools Where a model calls tools or takes actions. Follows Well-Architected Agentic AI Lens
  • Each tool runs with only the permissions its actions need
  • Step limits and per-session token ceilings end runaway loops
  • Human confirmation before irreversible actions such as payments, emails or deletes
  • A trace of every reasoning step and tool call
03 Account and access Follows AWS Startup Security Baseline
  • Production in its own AWS account, apart from dev and staging
  • Root user protected by MFA, with no access keys
  • People sign in through IAM Identity Center or federated roles
  • Pipelines deploy through short-lived roles instead of stored keys
  • CloudTrail in every region, writing to a bucket workloads cannot delete from
  • GuardDuty findings routed to someone who reads them
04 Network and data Follows AWS Startup Security Baseline
  • Only intended entry points reachable from the internet
  • Secrets held in Secrets Manager or Parameter Store
  • Encryption at rest, and TLS on every public endpoint
  • Automated backups matched to your recovery point objective
  • A restore that has been carried out and timed
  • Deletion protection on production databases, versioning on critical buckets
05 Failure and recovery Follows AWS Operational Readiness Review
  • A failure model for each component and dependency
  • Survives the loss of an Availability Zone without manual changes
  • Timeouts and retries set deliberately on every client
  • Per-customer rate limits, so one tenant's surge stays with that tenant
  • Recovery time and recovery point objectives the architecture can meet
  • A runbook to restart the service from stopped
06 Release and change Follows AWS Operational Readiness Review
  • Production defined in Terraform, CDK or CloudFormation
  • Every production change approved by someone other than its author
  • A rollback path that has been used
  • Load tested at projected peak and at a single-customer surge
  • Staging built from the same infrastructure code as production
07 Monitoring and on-call Follows AWS Operational Readiness Review
  • Alarms on the error rates and latency customers feel
  • A synthetic check on the main user flow
  • A dashboard covering critical dependencies, including model latency and throttles
  • Alarms that reach a named person on a rota
  • Runbooks for the top failure modes
  • Centralised logs with a set retention
08 Spend at launch traffic Follows Well-Architected COST01-BP06
  • Cost per request or per conversation estimated at launch volume
  • Budget and anomaly alerts routed to a named person
  • Tags that split spend by environment and service
  • Per-customer token or request caps

How each check is rated

Every check lands in one of five ratings, so the report reads as a set of decisions for your team.

Ready
We have seen the evidence in the account or the repository: the config, the alarm, the restore record.
Blocker
Closes before launch traffic arrives.
Fix within 30 days
A real risk, and one the workload can carry at launch volume.
Accepted risk
Your team chooses to carry it, with a named owner and the reason written down.
Not applicable
Recorded with the reason, such as a workload with no agents.

What you walk away with

  • The readiness report. All 44 checks rated, with the evidence behind each rating and the failure model for your workload.
  • The action plan. Blockers first, each with the change that closes it, then the items to fix within 30 days.

Both are written for your engineers to act on, and both are yours to keep.

Tell us what you are launching