Quick answer
Before a cloud workload goes live, require evidence that someone owns it, responders can access it safely, failures can be detected, expected demand can be handled, important data can be recovered, and unsuccessful deployments can be contained.
Use a launch review to record the requirement, accountable owner, evidence, validation result and unresolved risk. Treat missing essential controls as launch blockers; give acceptable follow-up improvements an owner and deadline. AWS recommends conducting operational-readiness reviews before general availability and revisiting them throughout the workload’s lifecycle. (docs.aws.amazon.com)
This checklist is a provider-neutral review template, with specific AWS and Google Cloud examples where their documentation supports the detail. It is not a certification or a substitute for workload-specific security, governance or service requirements.
1. Define launch blockers before reviewing the workload
Start by writing down what the service must do, which users it serves, what data it handles, and when support is available. Use those requirements to decide what must be demonstrated before launch.
For this review, use three outcomes:
- Pass: evidence shows that the agreed requirement is met.
- Blocker: the requirement is unmet or unverified, and the risk is unacceptable for this launch.
- Accepted follow-up: an authorized decision-maker accepts the remaining risk, with a mitigation, owner and due date.
A missing dashboard annotation might be a follow-up. An untested recovery path for irreplaceable customer data deserves a different decision. Classification depends on business impact, not how easy an item is to fix.
Keep the initial checklist focused. AWS describes an operational-readiness review as both a process and a checklist, incorporating technical requirements, operational procedures and lessons from incidents. (docs.aws.amazon.com)
Practical check: Replace “backups enabled” with “restore procedure validated against agreed recovery requirements.” Configuration is evidence of setup, not necessarily evidence of successful operation.
2. Assign owners and map critical dependencies
Identify who can authorize changes, troubleshoot failures and accept operational risk. AWS recommends recording ownership for workloads, accounts, infrastructure, platforms and applications in a discoverable register or resource metadata. (docs.aws.amazon.com)
Your review record should identify:
- The service owner and launch decision-maker.
- The primary responder and escalation route.
- Owners for application code, infrastructure, data and security controls.
- Who communicates with affected users.
- Who reviews spending and approves capacity changes.
One person may cover several roles in a small team. Record those responsibilities explicitly rather than implying that a larger support organization exists.
Then sketch the request path: DNS, TLS termination, application runtime, database, storage and external services. For each critical dependency, record its owner, access method and expected behavior during failure.
Validation: In an isolated test environment, make a dependency unavailable where safe. Check whether the application fails clearly, whether responders can identify the dependency, and whether the documented mitigation is usable.
Common mistake: Assigning ownership to “the platform team” without a reachable escalation route. Ask a reviewer unfamiliar with the service to find the responsible person using only the documentation.
3. Verify administration, workload identities and exposure
Review human access separately from application access. In AWS, official IAM guidance recommends temporary credentials through federation for people, IAM roles for workloads, and least-privilege permissions. It also recommends MFA where IAM users or root users are required. (aws.amazon.com)
Use these launch checks:
- Responders can sign in using their own approved identities.
- Deployment automation has a separate, scoped identity.
- The application can access only the resources its functions require.
- Secrets are referenced through the approved secret-management mechanism.
- Public and cross-account access are intentional and reviewed.
- Emergency access has a documented approval and audit procedure.
Where AWS IAM Access Analyzer supports the resource type, use its findings to review public or cross-account access and its policy validation to identify policy issues. These checks support review; they do not establish that every security requirement is satisfied. (aws.amazon.com)
Validation: Test both permission outcomes. A responder should be able to inspect the service through the intended role; an application identity should be denied an unrelated administrative action.
Common mistake: Treating a successful administrator login as proof that the on-call responder or deployment pipeline has the correct access.
4. Monitor user outcomes and test notification delivery
Begin with what users need to accomplish—not just whether a virtual machine is running.
Google’s SRE guidance identifies latency, traffic, errors and saturation as four core monitoring signals. It also distinguishes externally visible behavior from internal telemetry, which helps explain why a service is failing. (sre.google)
For a small web application, review:
- A safe external check of a critical user journey.
- Request volume, failures and latency for important endpoints.
- Resource saturation and dependency errors.
- Logs that let a responder follow a failed request.
- Alerts with a clear owner, escalation route and initial action.
Agree on the acceptable user-facing behavior before setting alert thresholds. Do not select arbitrary thresholds simply because a monitoring tool suggests defaults.
Test the notification path, not merely the alert configuration. Google Cloud Monitoring documents testing a notification channel by creating an alerting policy whose condition will be met; it does not provide a standalone notification-channel test option. (docs.cloud.google.com)
Validation: Generate a controlled test condition, confirm that the intended responder receives the notification, and open the linked troubleshooting procedure.
Common mistake: Paging on every unusual metric. Google’s guidance favors clear, actionable signals and warns that noisy paging can obscure real failures. (sre.google)
5. Check capacity, quotas and spending responsibility
Write down your demand assumptions, including uncertainty. If expected traffic is unknown, record that explicitly and choose a limited launch scope that the team can observe and control.
Test representative user behavior in an environment that closely matches production. AWS recommends validating scaling settings, base resources, quotas and resilience under load—not simply checking throughput on a smaller test system. (docs.aws.amazon.com)
Review ordinary demand, sudden increases and sustained load. Capture the application version, infrastructure configuration, test conditions and observed results. Do not translate a single successful test into an unsupported maximum-capacity claim.
Separately inspect applicable service quotas. AWS notes that quotas can be regional or global and can affect scaling events. It recommends reviewing them before production rollout and monitoring quota-related errors. (docs.aws.amazon.com)
Validation: Confirm that the intended scaling range fits the actual account and Region’s quotas. If an increase is necessary, require confirmation of the approved value rather than an outstanding request.
For spending, add a review question: Who will investigate unexpected usage and decide whether to scale, limit demand or change configuration? Record expected cost drivers without inventing a savings estimate or treating spending controls as a replacement for capacity planning.
6. Prove recovery against business requirements
Agree on recovery objectives before choosing the recovery procedure:
- Recovery time objective, or RTO: the maximum acceptable time between service interruption and restoration.
- Recovery point objective, or RPO: the acceptable age of the data recovery point, expressing tolerated data loss in time.
AWS recommends setting these objectives from business impact and technical constraints, including the recovery capabilities of dependencies. (docs.aws.amazon.com)
Inventory everything needed to resume service: important data, configuration, infrastructure definitions, secrets access and external dependencies.
Use a controlled rehearsal:
- Select a known recovery point.
- Restore into an isolated environment.
- Apply the intended access and configuration.
- Validate representative data and application behavior.
- Record elapsed time, recovered data state and manual steps.
- Compare the results with the agreed requirements.
For an Amazon RDS DB-instance snapshot restore, RDS creates a new instance rather than restoring into the existing one. Its documentation also identifies parameter-group and networking considerations: defaults may apply unless alternatives are selected. Include those settings in the procedure rather than assuming the restored instance matches production. (docs.aws.amazon.com)
Common mistake: Ending the rehearsal when the database becomes available. Require evidence that the application can use the recovered data.
Record temporary resources and an approved cleanup step so the rehearsal does not leave an unmanaged environment behind.
7. Rehearse deployment, stop conditions and reversal
A successful release job is not the final acceptance test. Define what must be true after deployment and what will stop further rollout.
AWS recommends integrating automated tests and rollback into deployment workflows, with predefined success and failure conditions. Its guidance includes testing application interactions and using monitoring to decide whether a change should be reversed. (docs.aws.amazon.com)
For the first production launch, record:
- The exact release artifact and reviewed configuration.
- Who can approve and perform deployment.
- The post-deployment checks.
- The observation period and stop conditions.
- The procedure for disabling exposure or returning to a safe state.
- Who verifies service health afterward.
Because this is the first launch, a previous production release may not exist. Define the safe fallback explicitly: for example, withdraw traffic or disable the new feature rather than claiming that an unproven rollback target is available.
If the release changes persistent data, require a separate compatibility review. Ask whether reverting the application also requires data repair or restoration; do not assume those are the same operation.
Validation: Rehearse the deployment and fallback in pre-production, then verify the critical user journey. Automate repeatable checks where practical, while keeping accountability clear for manual steps. (docs.aws.amazon.com)
8. Work through a small web application’s launch decision
Consider an illustrative, untested application with a managed runtime, an Amazon RDS database, object storage and an external email service. The table below is a review worksheet, not a report of actual results.
| Review area | Accountable role | Required evidence | Validation |
|---|---|---|---|
| Ownership | Service owner | Support coverage and escalation record | Reviewer finds the current responder |
| Dependencies | Application owner | Request-path diagram and failure behavior | Exercise email-service failure safely |
| Access | Security or platform owner | Human and workload access review | Approved actions succeed; unrelated actions are denied |
| Monitoring | Operations owner | User-journey check and alert routing | Test condition reaches the responder |
| Capacity | Platform owner | Load-test report and applicable quotas | Compare tested demand and scaling range with launch assumptions |
| Recovery | Data owner | Restore procedure and rehearsal record | Restored application passes data checks |
| Deployment | Release owner | Artifact, acceptance checks and fallback | Rehearse deployment and withdrawal |
| Spending | Service owner | Cost drivers and investigation responsibility | Confirm who handles unexpected usage |
Apply the decision rules to unresolved items:
- No recovery rehearsal for important customer data: treat as a blocker under this worksheet.
- Email outage prevents account creation: either address the dependency behavior or reduce launch scope; document the decision.
- Alert exists but delivery is unverified: require a notification test.
- A secondary dashboard lacks polish: potentially a follow-up if essential detection and diagnosis remain usable.
Finish with a signed decision recording launch scope, evidence, blockers and accepted follow-ups. Include an owner and due date for every deferred item.
A pass applies to the reviewed workload and launch conditions—not every future release. Revisit the checklist after significant changes and incidents, incorporating lessons into subsequent reviews as AWS recommends. (docs.aws.amazon.com)