An AWS production readiness review checks whether your architecture, deployment process and operating model are ready to support real customers before launch. It helps founders, CTOs and engineering teams identify practical risks in security, reliability, observability, recovery, performance, cost and day-to-day ownership.
Launching an application on AWS is not the same as being ready to operate it in production. A workload can deploy successfully and still have a single point of failure, an untested backup, unclear incident ownership, unsafe release process or no useful alert when customers are affected.
That is why a production readiness review should end with more than a list of suggestions. It should give your team a clear decision: what must be fixed before launch, what can be accepted temporarily, who owns each action and how the platform will be operated afterwards.
Preparing to launch or scale on AWS? CloudQube can review your architecture, deployment workflow and operating controls, then provide a prioritised remediation plan. Book an AWS cloud consultation.
What is an AWS production readiness review?
An AWS production readiness review is a technical and operational review completed before an application, major release or migrated workload is exposed to production traffic. It is designed to answer one question:
Can this team operate this workload reliably, securely and economically when real users depend on it?
The review should be tailored to the workload. A small SaaS application, a public API, an internal platform and a data-intensive service will not have identical requirements. The reviewer should assess the actual architecture, deployment process, dependencies, data flows and support model rather than apply a generic checklist without context.
The review can draw on the AWS Well-Architected Framework to evaluate architecture and identify improvements. AWS also recommends Operational Readiness Reviews (ORRs) to check whether a team can operate a workload before it reaches general availability and periodically afterwards. AWS describes an ORR as a checklist-based review that can cover architecture, operations, event management, release quality, security and governance. A consultancy’s production readiness review can use similar principles, but the phrase does not identify one standard AWS certification or fixed AWS service. Agree the assessment scope and evidence with the reviewer before work begins.
When should you arrange an AWS production readiness review?
The best time is early enough to fix material risks without delaying a launch. Common trigger points include:
Before the first production launch
New teams often focus on making the application work and leave production operations until the final week. A review exposes missing controls while there is still time to improve the foundation.
Before a major traffic or customer increase
A platform that worked for a small test group may behave differently under sustained load. Review capacity assumptions, scaling limits, database connections, queues, third-party dependencies and support coverage before the next growth stage.
Before migrating from a hosting provider to AWS
Migration is a good opportunity to correct inherited risks, but only if discovery and design happen before the cutover. Use the AWS migration checklist for startups alongside a workload-specific readiness review.
Before signing an important customer or contract
Enterprise customers may expect evidence of access control, recovery, monitoring, change management and incident response. A review helps you close gaps before they become sales blockers.
After a serious incident or repeated operational failure
An outage, data-loss event, security finding or failed deployment should trigger a review of the controls that failed or proved insufficient. The aim is to reduce the chance of recurrence and update the operating process where needed.
Periodically after launch
Review readiness again when the architecture, team, customer requirements, traffic or recovery expectations change. AWS recommends running operational readiness reviews throughout a workload’s lifecycle, so the checklist can reflect new risks and lessons from incidents.
AWS production readiness checklist
Use the following checklist as a starting point. Each item should be supported by evidence, such as an architecture diagram, configuration, test result, runbook or owner-confirmed process.
| Review area | Questions to answer | Evidence or output |
|---|---|---|
| Architecture and scope | What is launching, and which services, teams and vendors does it depend on? | Current architecture and dependency map |
| Accounts and environments | Are development, staging and production separated appropriately? | Account and environment model |
| Identity and access | Who can access production, and are permissions limited and reviewed? | IAM review, role map and access process |
| Network exposure | Which resources are public, private or reachable only through controlled paths? | VPC, subnet, security group and ingress review |
| Data protection | Is sensitive data encrypted, retained and accessed appropriately? | Data-flow and encryption review |
| Reliability | What happens when an instance, Availability Zone, dependency or deployment fails? | Failure-mode and resilience findings |
| Backup and recovery | Are backups available, protected and restored in a test? | Restore evidence, RPO and RTO decisions |
| Deployment | Can the team release safely, verify changes and roll back? | Pipeline, approval and rollback evidence |
| Observability | Can the team identify customer impact and investigate the cause? | Dashboards, logs, traces, alerts and owners |
| Performance | Has the workload been tested against realistic traffic and data volume? | Load-test results and capacity assumptions |
| Cost control | Are resources tagged, budgets visible and abnormal spend detectable? | Cost ownership and alerting plan |
| Operations | Who responds to incidents, maintains the platform and approves changes? | Runbooks, rota and escalation path |
1. Architecture, boundaries and dependencies
Start with a current architecture diagram rather than an old design document. Identify the application components, data stores, queues, external APIs, DNS, identity providers, payment services and other dependencies that can affect availability.
Check whether production is separated from development and testing, whether critical resources have clear ownership and whether the team understands the path of a customer request through the platform. A dependency that is not shown is often a dependency that is not monitored or tested.
For broader design guidance, see CloudQube’s AWS cloud architecture service and high-availability architecture guide.
2. Identity, access and security controls
Review how engineers, applications and third-party services authenticate to AWS and production systems. The review should cover least-privilege permissions, privileged access, multi-factor authentication, key rotation, secrets storage, emergency access and access removal.
Also check public exposure. Security groups, load balancers, storage buckets, administrative endpoints and database access should be intentionally configured and reviewed. Logging alone is not a substitute for preventing unnecessary access.
This section should produce specific actions rather than a vague instruction to “improve security”. For example, identify an over-permissioned role, an exposed management port, an unrotated key or a secret stored in a repository.
3. Reliability, failure handling and recovery
Production readiness is demonstrated when the team knows how the system behaves under failure. Review single points of failure, health checks, load balancing, auto scaling, database resilience, queue behaviour, dependency timeouts and graceful degradation.
Assess backups by restoring them and checking that the data is usable and the recovery time is acceptable. A successful backup job alone does not show whether recovery will work. AWS recommends periodic recovery tests to check data integrity and whether restoration meets the workload’s recovery point objective (RPO) and recovery time objective (RTO). RPO describes how much data loss the business can tolerate; RTO describes how quickly service should be restored.
The AWS reliability pillar covers the ability of a workload to perform its intended function consistently and to be operated and tested throughout its lifecycle. See AWS guidance on periodic recovery testing for restore checks. AWS Resilience Hub is another official AWS service that can help teams assess and improve application resilience against defined goals.
4. Deployment, change management and rollback
A production-ready deployment process should make the safe path the easiest path. Review:
Source control and protected branches
Automated tests and quality gates
Infrastructure changes managed through reviewable code
Environment-specific configuration and secrets
Database migration safety
Approval requirements for high-risk changes
Progressive delivery, feature flags or staged releases where appropriate
Health checks after deployment
A tested rollback or forward-fix procedure
Evaluate whether the pipeline helps the team identify a bad release quickly and restore a healthy service without improvising during an incident. CloudQube’s DevOps and automation service covers CI/CD, Infrastructure as Code and deployment implementation.
5. Monitoring, logging, tracing and alerting
Monitoring should show whether the service is healthy. Observability should help the team understand why it is not healthy.
At minimum, define the signals that matter to customers and operators: availability, latency, error rate, throughput, saturation, queue depth, database health, failed jobs and dependency failures. Centralise logs where appropriate, retain them for a useful period and make sure they can be correlated with deployments and requests.
Alerts should have an owner, a severity, a meaningful threshold and an action. An alert that nobody understands or responds to is noise, not operational protection. Link important alerts to runbooks so the on-call engineer knows what to check first.
6. Performance, capacity and scaling
Review realistic workload assumptions rather than relying on a single successful test. Consider normal traffic, peak traffic, background jobs, large payloads, database growth, concurrent users, connection pools, third-party rate limits and regional dependencies.
Document how the platform scales and where scaling stops. For example, an auto-scaling application tier may still be constrained by a database connection limit, a queue consumer, a storage throughput limit or an external API quota.
If a load test is required, define the success criteria first. A useful test should tell the team how latency, error rates, resource utilisation and recovery behave under a specific traffic pattern.
7. Cost ownership and operational economics
Production readiness also includes financial control. Review resource ownership, tagging, environment schedules, data-transfer assumptions, storage retention, log volume, idle resources and scaling policies.
Set a baseline for expected spend and identify who reviews it. Budgets and alerts are helpful, but they should be supported by an explanation of the architecture choices that drive cost. CloudQube’s AWS cost optimisation guide covers practical controls for rightsizing, storage, data transfer and visibility.
What should the review deliver?
A useful AWS production readiness review should leave the team with artefacts that can be acted on immediately:
Executive summary: the launch recommendation in plain language.
Architecture and dependency map: the system as it actually operates.
Prioritised risk register: each finding includes evidence, impact, owner and recommended action.
Go-live conditions: blockers that must be resolved before production and risks that require explicit acceptance.
Remediation backlog: practical tasks grouped by urgency and effort.
Operational runbook list: the procedures needed for deployment, rollback, incident response, backup restoration and common failures.
Improvement roadmap: recommended actions sequenced by risk, dependency and team capacity.
The report should distinguish between a critical launch blocker, a high-priority improvement and a longer-term optimisation. Treating every finding as equally urgent makes it harder for the team to act.
How much does an AWS production readiness review cost?
There is no responsible single price for every review. The cost depends on the number of workloads, AWS accounts, environments, regions, data stores, integrations and operational processes that need to be assessed.
The scope also changes if you need only an assessment or want the same partner to implement the remediation. Before accepting a proposal, ask whether it includes:
A discovery call and evidence request
Architecture and configuration review
Security and access review
Reliability, backup and recovery checks
Deployment and observability review
A written risk register and launch recommendation
A remediation roadmap
Optional implementation and post-launch support
CloudQube can discuss the review scope in a 30-minute infrastructure consultation based on your launch date, workload complexity and engineering capacity.
AWS Well-Architected review vs production readiness review
The two activities overlap, but they answer slightly different questions.
An AWS Well-Architected review evaluates architectural decisions against AWS best practices and the framework’s pillars. AWS describes the process as a constructive conversation rather than an audit. A production readiness review uses relevant architecture principles but adds a time-bound go-live decision, operational ownership, evidence, runbooks, deployment controls and remediation priorities.
You may need both. A Well-Architected review can improve the design, while a production readiness review checks whether the specific team and workload are prepared to operate the design in real conditions.
Common mistakes that reduce production readiness
Treating a checklist as proof
A completed checkbox does not prove that a restore works, an alert reaches the right person or a rollback is safe. Ask for evidence where the risk justifies it.
Reviewing only the application code
Production risk also exists in IAM, networking, DNS, data retention, CI/CD, third-party services, access processes and incident response.
Testing only the happy path
Include failed deployments, unavailable dependencies, expired credentials, full disks, slow databases, lost connections, queue backlogs and unexpected traffic. The exact tests should match the workload.
Leaving ownership unclear
“The engineering team will handle it” is not an operating model. Name the person or team responsible for each control, escalation and decision.
Fixing everything at once
Prioritise risks by customer impact, likelihood, recoverability and effort. A focused remediation plan is more useful than an unranked list of dozens of recommendations.
Frequently asked questions
Is an AWS production readiness review only for large companies?
No. Smaller teams often benefit because they have fewer people to share on-call, security and infrastructure responsibilities. A review can be scaled to the actual workload rather than applying enterprise processes unnecessarily.
How long does an AWS production readiness review take?
The time depends on the number of workloads, environments, dependencies and evidence available. A focused application review is faster than a review covering multiple accounts, regions and business-critical platforms. The scope should be agreed before work begins.
Do we need to provide AWS administrator access?
Not necessarily. A review can begin with architecture diagrams, read-only evidence, deployment documentation, monitoring views, recovery tests and a guided technical discussion. If direct access is considered, use the minimum permissions and access period required.
Can CloudQube implement the issues found?
Yes. CloudQube can help with AWS architecture, security controls, CI/CD, Infrastructure as Code, monitoring, managed infrastructure and platform operations. The review can be kept independent from implementation, or the remediation work can be planned as a separate delivery phase.
Is a production readiness review a guarantee that there will be no outage?
No. No review can remove every operational risk. Its purpose is to make important risks visible, improve the team’s ability to prevent and recover from incidents, and ensure that launch decisions are based on evidence rather than assumptions.
What is the difference between a production readiness review and a cloud architecture assessment?
A cloud architecture assessment focuses mainly on design decisions, constraints and improvement options. A production readiness review is narrower in timing and more operational: it asks whether the specific workload, release process and support model are ready for production now.
Final decision: is your AWS platform ready?
An AWS production readiness review gives you a structured way to answer that question before customers, revenue or internal teams depend on the platform. It connects architecture with security, deployment, monitoring, recovery, cost control and ownership.
If your team is preparing a launch, migrating a critical workload or scaling faster than its operating model can support, CloudQube can assess the current environment and turn the findings into an implementation-ready plan.
Schedule a 30-minute consultation with CloudQube to discuss your AWS production readiness, launch risks and next steps.