Cloud Deployment Acceptance Pack

A reusable acceptance pack for proving artifact identity, infrastructure change, production behavior, security controls, rollback, recovery, and operating ownership...

trigger="A new cloud workload, material infrastructure change, platform migration, security control change, or delivery partner handoff needs a repeatable production acceptance decision." owner="The workload owner who accepts business and service behavior, paired with the platform owner who accepts operability and recovery. Security, data, and compliance owners approve only the controls in their remit." timebox="Prepare the pack during delivery. Run the final review within two working days of the candidate release, followed by an evidence window sized to the workload risk and traffic pattern." participants={["Workload owner", "Platform or SRE", "Application engineering", "Security", "Data owner", "Product", "Support or operations", "Delivery partner", "Finance or FinOps when cost changes materially"]} prerequisites={[ "A named release candidate, change scope, target environment, accountable owners, and business journey affected by the change.", "Access to deployment history, infrastructure definition, observability, security findings, dependency inventory, backup status, and recovery procedures.", "Agreed service, security, data, cost, and recovery thresholds with a stop condition for the release." ]} outputs={[ "One traceable release manifest covering application, configuration, infrastructure, data migration, and dependency versions.", "A reviewed infrastructure change preview and drift record.", "Pre-deployment, deployment, post-deployment, rollback, and recovery evidence.", "An operational acceptance record with remaining risks, expiry dates, owners, and follow-up tasks.", "A reusable pack template that the pipeline can populate for later releases." ]} doneWhen={[ "The reviewer can identify exactly what changed and reproduce the deployment from controlled source.", "Pre-production used the same deployment path and proved the release-specific rollback or safe recovery path.", "Production business and service signals remain inside agreed thresholds for the acceptance window.", "Security, data, cost, support, and recovery evidence is linked rather than asserted.", "The acceptance decision and every residual risk have a named owner and retained record." ]} />

Acceptance is an evidence decision

A successful pipeline run proves that automation completed its configured steps. It does not prove that the business journey works, that an infrastructure replacement was intended, that permissions are appropriately narrow, that a migration preserved data, or that recovery will finish inside the agreed limit.

The acceptance pack connects one release identity to evidence from build, infrastructure, deployment, production, security, data, cost, and recovery. It should be small enough to review and structured enough for automation. A folder of screenshots and chat approvals is not a pack because a later operator cannot establish what those artifacts belong to.

Define the release boundary first. Include application artifacts, container digests, functions, infrastructure modules, configuration, feature flags, database migrations, policies, secrets references, scheduled jobs, event schemas, and third-party dependency changes. If one item can change production behavior, it belongs in the manifest even when another team owns it.

Define the acceptance contract

Write the business journey affected, expected result, release window, exposure plan, evidence window, service thresholds, security controls, data checks, cost guardrails, recovery objective, and acceptance authority. Separate a deploy approval from final acceptance. Approval permits bounded exposure. Acceptance follows observed evidence.

Specify stop conditions as machine-readable signals where possible. Examples include error rate, latency, queue age, failed business transactions, authentication failures, authorization denials, data mismatch, saturation, cost anomaly, or a security alert. Give every signal a threshold, evaluation interval, action, and owner.

State what rollback means. An application artifact might be reversible. A database migration, external side effect, or destructive infrastructure replacement may require roll-forward, isolation, restore, or reconciliation. “Rollback available” without a release-specific procedure is not evidence.

Use a risk tier to scale the pack. A documentation-only configuration label does not need the same recovery rehearsal as an identity-policy change. Do not waive artifact identity, change traceability, or ownership at any tier.

Assemble the release manifest

Generate the manifest from the delivery system, not from memory. It should contain source revision, build identifier, artifact digests, infrastructure revision, configuration version, schema migration identifiers, dependency lock, environment, build time, signer or workload identity, test summary, vulnerability scan reference, and deployment record.

Treat mutable tags such as latest as labels, not identities. Retain the digest or immutable version actually deployed. Store the manifest with the release record and expose the current production version to operators.

Include provenance for artifacts created outside the primary pipeline. If a vendor image, manual package, or emergency script enters the release, record who supplied it, how integrity was checked, what review occurred, and when it should be replaced by a governed build.

Do not put secret values in the manifest. Record secret identifiers and versions where safe. Prove that runtime access retrieves the intended reference and that rotation does not require rebuilding the artifact unless that is an explicit design choice.

Review the infrastructure change preview

Generate a plan or change set from the exact infrastructure revision and target environment. Classify every action as create, in-place update, replacement, deletion, permission expansion, network exposure, or data movement.

AWS recommends testing deployment procedures in pre-production, using drift detection, and reviewing CloudFormation change sets so intended stack updates match the actions CloudFormation will take in its deployment testing guidance. Apply the same control to other infrastructure systems: preview first, bind the preview to the reviewed revision, and invalidate it when inputs change.

Review replacements and deletions line by line. Determine whether a resource contains state, identity, network addressing, audit history, or an external reference. Check retention, snapshot, replacement order, and dependency behavior. A replacement that is safe in a test account can break production integrations that depend on a stable endpoint.

Compare actual state with controlled definition. Record drift, its owner, and whether the release adopts, removes, or leaves it temporarily. Do not let an unrelated manual change become an invisible part of the release.

Verify identity, access, and trust boundaries

List every identity involved in build, deploy, runtime, operations, and emergency access. For each, record trusted principal, permitted action, resource scope, condition, credential form, expiry or rotation, and evidence source.

Review new wildcard permissions, cross-account trust, public endpoints, security-group changes, key policies, secret access, role assumption, and logging exclusions. Test denial as well as success. A policy can pass the happy path while granting broader access than the workload needs.

Use automated policy checks and cloud-native analyzers, but review business context that tools cannot infer. A public bucket finding is clear. An internal role that can approve refunds, export participant data, or change routing needs a product-specific judgement.

Confirm that delivery partners and support staff use named, attributable, time-bounded access where feasible. Record break-glass procedure, approval, alerting, session evidence, and removal. Production acceptance should not depend on a shared administrator credential.

Prove the release path in pre-production

Deploy the same artifact and infrastructure revision through the same automated path, policy gates, migration sequence, configuration mechanism, and validation steps intended for production. Differences in scale and data are expected. Differences in procedure should be named and justified.

Run pre-deployment checks for dependency availability, quota, free capacity, backup freshness, migration prerequisites, feature-state assumptions, and required operator coverage. Run functional, integration, security, regression, and load tests proportional to the change.

Execute the actual rollback or recovery path. Measure detection, decision, action, and restoration time separately. Confirm that the older application can read the changed schema, or that a compatible roll-forward exists. Restore one representative backup and validate the result at the application level.

AWS Well-Architected guidance recommends planning for unsuccessful changes, safe deployment strategies, automated testing, and rollback. The current Operational Excellence pillar treats recovery planning as part of deployment design, not an activity after failure.

Define the production exposure plan

Choose an exposure unit that limits business consequence and produces representative evidence. It may be traffic percentage, tenant cohort, region, organization, user role, worker partition, feature flag, or time window. A canary that receives only health-check traffic does not test the journey.

Record the starting exposure, observation duration, promotion steps, stop signals, rollback authority, and maximum time in an ambiguous state. Avoid promotions that require a meeting while the service is actively degrading. Give the on-call owner authority to stop or reverse the release inside the agreed rule.

Use independent signals. Infrastructure health can remain green while registrations fail, recommendations disappear, or payments remain pending. Observe technical signals, business completions, security events, data consistency, support contacts, and cost drivers.

CloudWatch alarms can stop a CodeDeploy deployment when an associated alarm activates, as described in the CodeDeploy monitoring documentation. Automation is useful only when the alarm measures the risk the release creates and missing telemetry fails safely.

Validate business and service behavior

Run synthetic and real-traffic checks for the critical journey. Verify start, completion, persistence, downstream projection, notification, and support visibility. Compare the candidate cohort with a stable cohort where the design allows it.

Check latency distribution, errors, saturation, queue age, retries, dependency failures, and resource health. Also check the count and value of business outcomes. A payment service can report low HTTP error rate while callbacks are delayed and registrations remain pending.

Test observability itself. Trigger one controlled event and prove it appears in logs, metrics, traces, dashboards, and alerts with a usable correlation identifier. Confirm that sensitive fields are redacted and that operators can reach the evidence under incident conditions.

Maintain an evidence window long enough to include scheduled work, cache expiry, autoscaling, asynchronous processing, reconciliation, and representative traffic. State which behaviors could not be observed and convert them into residual risks with expiry dates.

Verify data change and reconciliation

For every migration or data-path change, record source and target counts, accepted exclusions, checksum or invariant, rejection count, duplicate count, null or range checks, and business reconciliation. Test with representative volume and contention.

Use expand-and-contract changes where possible. Add compatible structures, backfill, dual-read or shadow-compare, move traffic, and remove old structures only after evidence. Make each phase independently observable and stoppable.

Do not declare a migration complete when the tool exits successfully. Validate application reads and writes, downstream consumers, indexes, caches, reports, exports, backups, and recovery. Preserve the mapping between old and new identifiers.

For event-driven changes, compare producer and consumer counts by partition and time window. Account for legitimate retries and duplicates. Measure oldest unprocessed age, dead-letter volume, schema rejection, and replay result.

Prove rollback, roll-forward, and isolation

Select the safe return path based on the change. Roll back traffic when the previous stack remains compatible. Roll forward when data or interface change cannot safely reverse. Isolate a failing capability when the rest of the product can continue. Invoke restore or continuity procedure when state has been lost or corrupted.

Record exact commands or automated actions, required permissions, decision authority, expected duration, validation, and abort condition. Avoid runbooks that say “restore service” without identifying the artifact, data point, routing action, and proof.

Rehearse under degraded conditions. Assume the primary operator is unavailable, a dashboard is misleading, the latest backup is incomplete, or an external dependency remains down. Confirm that the procedure does not require the same failed component to recover itself.

AWS recommends frequent, small, reversible changes because smaller scope makes unintended consequences easier to identify and remediation faster. See the small reversible changes guidance. When a change cannot be reversed, reduce exposure and strengthen isolation, roll-forward, and continuity evidence.

Check cost and capacity consequences

Estimate the steady-state and peak effect of the release. Include new resources, data transfer, logs, metrics, traces, storage growth, retained parallel environment, third-party calls, and operational work. Confirm budget alarms and cost allocation dimensions.

Observe actual usage through the evidence window. Normalize comparisons for traffic and scheduled activity. A canary might look inexpensive because it has not reached scale. A caching change might appear cheaper before expiry causes origin load.

Check quota and scaling behavior. Record account and regional limits, reserved capacity, concurrency, database connections, queue throughput, IP address availability, and external-provider limits. Test the path that requests or provisions more capacity.

Do not accept a cost reduction that removes recovery capacity, audit evidence, security visibility, or required performance. Record the trade-off and owner when temporary parallel capacity is retained for rollback.

Prepare operations and support

Name the service owner, on-call route, escalation contacts, provider contacts, runbooks, dashboards, alert destinations, status-page rule, support script, and known limitations. Confirm access before release.

Create product-safe operator actions for retry, reconcile, isolate, refund, reprocess, or correct as relevant. Direct database changes should be an emergency exception with approval and retained evidence, not the normal support path.

Update dependency and ownership records. Add renewal, certificate, domain, quota, deprecation, and key-rotation dates to an owned schedule. Handovers fail when operational time is not represented in the release.

Run one tabletop scenario tied to the change. Start with the alert, ask the on-call person to identify the version and impact, choose a safe action, communicate, recover, reconcile, and close with evidence.

Assemble the acceptance record

The record should link, not duplicate, the following:

| Evidence group | Minimum content | | --- | --- | | identity | release manifest and current production version | | scope | approved change and infrastructure preview | | quality | automated tests and targeted manual evidence | | security | policy, vulnerability, exposure, and exception results | | data | migration, consistency, backup, and restore results | | production | business, service, dependency, and security signals | | recovery | rollback, roll-forward, isolation, or restore rehearsal | | operations | owner, on-call, dashboards, alerts, runbooks, support | | economics | expected and observed cost or capacity effect | | decision | accept, return, isolate, or time-bound exception |

Exceptions need consequence, compensating control, owner, due date, and recheck. Do not use “accepted with risk” as a permanent status. Expired exceptions should alert and block a later material release when appropriate.

The final decision should name the reviewer and timestamp, release identity, evidence window, accepted scope, exclusions, residual risks, follow-up tasks, and next review trigger.

Acceptance checklist

"The manifest identifies application, configuration, infrastructure, data, policy, and dependency versions.", "The infrastructure preview is bound to the reviewed revision and every replacement or deletion is explained.", "Drift is recorded with an owner and treatment.", "Build, deployment, runtime, support, and emergency identities have reviewed trust and resource scope.", "Pre-production uses the production deployment path and has proved the release-specific safe return path.", "Production exposure is bounded by cohort, traffic, region, organization, feature, or time.", "Stop signals cover business behavior as well as technical health.", "Data changes reconcile at the application and downstream-consumer level.", "Backups are recent and at least one representative restore has been validated.", "Current production version, correlation evidence, dashboards, alerts, runbooks, and owners are accessible.", "Cost, quota, scaling, and retained rollback capacity have been reviewed.", "The decision record names accepted scope, evidence window, residual risks, tasks, owners, and expiry dates." ]} />

Failure and return conditions

Return the release when its artifact cannot be traced to controlled source, the infrastructure preview changed after review, an intended data replacement lacks recovery evidence, or the production journey cannot be distinguished from the stable cohort.

Stop exposure when a business, service, security, data, or cost threshold crosses its rule. Roll back only when the previous state remains safe and compatible. Otherwise isolate, roll forward, reconcile, or invoke recovery according to the rehearsed path.

Do not accept a release because a maintenance window is closing or a delivery milestone is due. Retain the candidate and evidence, address the failed gate, then repeat only the affected checks plus any checks invalidated by the change.

A good acceptance pack shortens the review because the evidence is produced by the delivery path. It does not add a document-writing phase after engineering is finished.

Make the pack part of the platform

Automate manifest generation, policy checks, test links, change previews, deployment records, alarm state, production version, evidence-window summary, and task creation. Keep human judgement for business acceptance, unusual permission, destructive change, residual risk, and exceptions.

Review which parts of the pack found real defects. Remove evidence that no reviewer uses and strengthen weak gates that repeatedly miss incidents. Track change failure, detection time, recovery time, exception age, manual intervention, and reconciliation discrepancy without turning the review into an individual performance score.

The next action is to select one representative production release and assemble the pack from existing evidence. The missing sections reveal which controls the delivery platform should produce automatically.