Retire Source Cloud Resources Without Losing Recovery Evidence

Build a per-resource retirement manifest that separates migration acceptance, recoverable retained artifacts, irreversible deletion and observed billing closure.

1. Decide what retirement must preserve

The application has moved. Traffic reaches the target, the migration dashboard is green, and somebody asks when the old bill will stop. Deleting the old environment is not the next automatic step. It is a separate change with three different outcomes: the source no longer serves the workload, retained evidence still supports the agreed recovery path, and financial records explain which costs actually ended.

This playbook produces a versioned, per-resource retirement manifest. Each row has an owner, a disposition, a specific authorization, an observed outcome and a financial follow-up. A retained snapshot is not a failed retirement. An unexplained database dependency is not permission to delete it. An accepted deletion request is not evidence that billing has ended.

Use this after a migration's application and data acceptance gates, not instead of them. The enterprise database migration guide owns write authority, cutover and business reconciliation. The migration overlap budget owns overlap economics. Here, those records become inputs to an independently authorized retirement procedure.

AWS-specific examples cover EC2 instances, ordinary RDS DB instances, retained storage and customer-managed KMS key dependencies. Aurora clusters, account closure, cryptographic destruction, legal retention decisions and other providers' deletion commands are outside scope. For a non-AWS source, obtain that provider's current service behavior and contract terms before adapting the procedure. No AWS operation, restore exercise, customer outcome or bill reduction was executed while preparing this educational playbook.

Owner, input, output, gate: the migration lead records the workload boundary, accepted target and proposed retirement window. The output is a change record with explicit exclusions. Hold if cutover acceptance, write authority or the accountable source owner is unresolved.

2. Assign authority before assembling a delete list

The service owner accepts business operation on the target. The database owner accepts the recovery data and its limitations. The security or records owner determines retention obligations and access boundaries. The platform operator proposes and executes resource changes. The financial owner reconciles remaining charges and contractual obligations. One person can hold several roles in a small team, but the record must still distinguish their decisions.

Use a named authorizer separate from the executor for irreversible actions where your change process requires separation. A ticket saying “migration complete” does not authorize every resource discovered later. New resources, changed snapshots, newly discovered consumers and expired windows require a revised authorization, not a larger interpretation of the original one.

The lead assembles five inputs:

• Accepted cutover record, including the last source-write boundary and unresolved exceptions.
• Resource inventory tied to actual account or subscription, Region, resource identifier and controlling deployment.
• Dependency evidence for applications, scheduled jobs, integrations, monitoring and recovery.
• Retention and restore packet identifying artifacts, permissions and the approved recovery environment.
• Contract and billing packet covering avoidable usage, retained storage, commitments, licenses and cancellation terms.

Store full identifiers and sensitive evidence in the customer's controlled system. A public enquiry or an article download is not the place for database exports, credentials, private invoices or contracts. Sanitized references are enough for a discussion with Ampity.

Output and gate: the lead assigns an owner and evidence location to every input. Missing ownership is HOLD. Permission to inspect a resource is not permission to alter or delete it.

3. Freeze an inventory that includes controllers and consumers

Give the inventory a version, capture time and scope. Record resources across every relevant account and Region, including shared services outside the original migration project's tags. Trace ownership through deployment repositories, infrastructure state and service controllers. Tags are useful hints, not proof that an untagged resource is unrelated.

For each proposed retirement, ask what creates it, what consumes it, what it consumes, and what must remain for recovery. A source web node may look idle while a controller recreates it after termination. A database may have no application sessions during a short observation window but still support a month-end export. A source bucket may feed an AI retrieval index or document-processing queue that was not included in the application cutover. Those consumers need evidence-based dispositions, not an assumption that AI components migrated with the UI.

Combine configuration inspection, owner confirmation and appropriately authorized telemetry. Identify observation coverage and blind spots. A seven-day sample does not establish that a monthly job is absent. Agree a representative observation window with the service owner or explicitly test the exceptional schedule using an approved method. Keep a dependency UNKNOWN until it is resolved or retained with a named risk acceptance.

EC2 termination guidance explains that an Auto Scaling group or EC2 Fleet can replace a manually terminated instance. Review the actual controller before changing its members. Do not delete a shared controller merely to prevent one unwanted replacement.

Owner and gate: the operator supplies a dependency map and controller revision for each row. The service owner signs off the consumer disposition. An unidentified consumer, controller or shared boundary blocks irreversible action on that row, but need not block an independent, fully understood resource.

4. Separate traffic, recovery and financial states

Track the following state transitions independently. This is a decision view, not a command sequence. A resource may reach technical retirement while its contract remains payable.

Candidate → dependency-cleared

Evidence needed to advance: Exact identity, controller and consumer dispositions

What the gate does not prove: That its data is recoverable

Dependency-cleared → recovery-ready

Evidence needed to advance: Existing retained artifact and pre-deletion isolated restore validation accepted

What the gate does not prove: That deleting the source is authorized

Recovery-ready → authorized

Evidence needed to advance: Named action, scope, time window and last safe stopping point

What the gate does not prove: That the action succeeded

Authorized → technically retired

Evidence needed to advance: Operation result and subsequent state readback

What the gate does not prove: That all related charges stopped

Technically retired → financially reconciled

Evidence needed to advance: Billing evidence split into ended, retained, committed and unresolved costs

What the gate does not prove: That retained artifacts can now be deleted

Keep HOLD, retained by decision and failed action as distinct states. A hold needs an owner and next evidence task. A retention decision needs a purpose, cost owner and review date. A failed action needs incident or recovery handling. Combining them into a generic “pending” column hides the work that remains.

Output and gate: the lead approves the state definitions before execution. Reject any dashboard that marks the entire estate closed because all requested delete calls returned successfully.

*Retirement has separate evidence, authorization, technical and financial gates. Keep recovery artifacts and their access dependencies usable after source deletion. An unresolved resource remains on hold; retention expiry needs a separate review.*

5. Build a retained-artifact packet, not just a backup list

Choose artifacts according to the agreed recovery objective and records obligations. Possible components include a database recovery point, application build, infrastructure configuration, schema and migration history, non-secret deployment parameters, dependency versions, controlled credential-recovery procedure and business reconciliation evidence. A database snapshot alone does not reconstruct the application, its authorization or its external contracts.

For each artifact, record the precise identifier or version, capture boundary, storage location, custodian, access role, encryption dependency, expiry rule and purpose. Use checksums for exported files where appropriate. A checksum establishes integrity against that recorded file, not business completeness. For managed snapshots, retain the service identity and metadata rather than inventing a file checksum that you cannot obtain.

State what is deliberately absent. An export taken before final accepted writes cannot prove recovery of those later writes. A backup in the source account may remain dependent on that account's roles, keys and payment status. Decide whether those dependencies are acceptable before retiring source access or changing the account structure. Copying data to another location needs its own permissions, retention and verification, not an informal workaround.

Treat encryption as a retained dependency. AWS KMS guidance says scheduled deletion has a waiting period, but a key pending deletion cannot perform cryptographic operations. Waiting is therefore not equivalent to keeping a usable recovery key. Key deletion can make dependent encrypted data unrecoverable. Do not schedule it as incidental cleanup of retired compute. Keep key retirement outside this change, with a separate dependency and authorization review.

Owner and gate: the database and records owners accept the artifact packet and explicit gaps. Stop if the only recoverable copy, required key, access role or recovery instructions are about to disappear with the source resource.

6. Verify recovery without depending on the resource being retired

Run a separately approved isolated recovery exercise using the retained artifact and the intended recovery role. Define the target account, Region, network, engine and runtime compatibility, spending approval, application test fixtures and cleanup owner before creating resources. Prevent restored jobs from sending real notifications, charging customers, updating external systems or competing with production writers.

Identify the existing artifact that satisfies this pre-deletion gate. An RDS final snapshot requested during deletion cannot supply an earlier restore test. One option is a manual snapshot captured at the accepted source-write boundary, tested while source writes remain fenced. If the tested artifact is older, the database owner must resolve its data gap against the recovery objective before authorizing deletion. Keep that tested artifact until any new final snapshot has completed subsequent validation and separate retention approval permits replacement. An untested final-snapshot request does not supersede the recovery evidence.

The test must expose hidden dependencies. If restoring requires a file from the node proposed for termination, the recovery packet is incomplete. If the backup can be described but cannot be decrypted by the recovery path, metadata visibility has not proved recoverability. If the database starts but required application queries or reconciliation checks fail, a completed restore job is insufficient.

Record request and completion times, exact restored identity, permissions used, application checks, reconciliation results and exceptions. Compare observed recovery duration and data boundary with the agreed objectives. Do not convert one successful fixture into proof that every workload or historical backup is recoverable. Where lifecycle behavior matters, use the RDS snapshot lifecycle rehearsal for the exact engine cohort rather than assuming the restored version matches memory.

AWS Backup restore testing supports periodic restore exercises and optional validation. Its test resources have cleanup behavior and associated costs that must be understood. This playbook does not require that product or claim its job status establishes your application's correctness.

Output and gate: the recovery owner issues an accepted test record, a limited acceptance with explicit residual risk, or HOLD. The operator records cleanup readback for the exercise itself. Rehearsal resources must not become the next unexplained cloud bill.

7. Authorize one disposition per resource

Choose retain, stop or quarantine under a service-specific plan, or delete. Do not pretend these have the same reversibility. A stopped machine can retain paid storage and may not preserve every runtime property. A quarantine rule can break an unnoticed consumer. A deleted resource may need reconstruction with a new identity, rather than a start command.

For EC2, termination is irreversible. Inspect each attached volume's DeleteOnTermination setting and preserve required data before approval; instance-store data is not a retained recovery artifact. The EC2 service documentation is the reference for the chosen path, not a generic bulk-delete script.

For an ordinary RDS DB instance, review deletion protection, final-snapshot choice, backup retention and replicas against RDS deletion guidance. Manual and final snapshots can remain; retained automated backups expire under their retention settings. Backups replicated to another Region remain even when same-Region automated-backup retention is not selected. Inventory those copies with their own retention and cost owners. Same-Region read replicas are promoted to standalone instances on source deletion. Cross-Region read-replica deletion behavior requires a separate service-specific review and is outside this procedure. Reserved DB obligations and retained backup charges remain separate financial questions.

For infrastructure-managed resources, inspect the proposed change and retained dependencies. CloudFormation's DeletionPolicy can retain supported resources or create snapshots, but does not govern physical-resource replacement during updates. A completed stack deletion does not mean retained resources vanished or stopped costing money. Review the specific update or deletion path and service behavior.

Authorization record: exact resource, exact action, artifact references, controller change, authorizer, executor, permitted window, abort trigger and recovery owner. Changing the action or resource invalidates that row's authorization until reviewed. Keep destructive commands out of reusable public templates: the approved operator supplies a service-specific procedure matched to actual identifiers.

8. Execute in bounded batches and read back the result

Start with an independently understood low-blast-radius resource. Reconfirm account, Region, identifier, inventory version and authorization window immediately before execution. Verify the target is still accepted and the retained recovery dependencies remain accessible. A green assessment from yesterday is not enough after a deployment, key-policy change or newly discovered consumer.

Capture the request identifier, operator, UTC time, relevant change revision and subsequent service state. Poll or inspect completion through the service's supported interface. A timeout is UNKNOWN until reconciled, not permission to repeat an irreversible action against a broader target. Check for controller recreation and unexpected activity after the change using the agreed observation window.

Suspend the remaining batch if production behavior changes, recovery access fails, the resource differs from inventory, or an unlisted consumer appears. Preserve observations before making another change. The last safe stopping point is often before deletion. After source termination or accepted target writes, recovery may mean restoring a new isolated resource and reconciling current data, not redirecting production to an old copy.

Owner and gate: the operator records actual outcomes and exceptions; the service owner accepts the post-change checks. Only completed readback permits “technically retired.” Failed or uncertain rows remain open with an incident owner and next action.

9. Reconcile billing without promising zero cost

The financial owner compares the authorized scope with subsequent usage and invoice evidence. Keep service usage dates, reporting timestamps and invoice periods distinct. Late-arriving information is an open reconciliation item. Do not invent a universal billing delay or declare savings from a single empty dashboard filter.

Split costs into four buckets: ended resource usage, deliberately retained resources, continuing commitments or contracts, and unexplained residuals. Inspect associated storage, snapshots, allocated addresses and service-managed resources across the scoped Regions. AWS's unexpected-charge guidance describes residual storage and address charges and warns about resources managed by other services. It is a troubleshooting starting point, not an exhaustive inventory.

Record the cost basis and currency used. Resource usage, amortized commitments, invoice cash and taxes are not interchangeable measures. Compare equivalent periods and document adjustments for workload movement or rate changes. For a source outside AWS, a provider's cancellation confirmation and actual contract terms may matter more than its resource dashboard. Deletion does not waive a notice period.

Output and gate: each row receives a financial disposition and an evidence reference. “No further resource usage observed in the reviewed period” is narrower and more defensible than “all costs eliminated.” Unexpected residuals need a named investigation owner. Retained storage remains an accepted cost with a review date, not a reason to delete the last recovery copy.

10. Use this synthetic manifest to expose unresolved work

The following fictional identifiers and dispositions illustrate the method. They are not AWS results, executable identifiers or approval to change any estate. “Accepted” here describes an invented scenario for teaching; a real run must replace it with observed evidence.

WEB-A

Proposed disposition: Terminate source web instance

Required evidence: Controller revision C7, accepted target checks, retained build and configuration

Illustrative decision: Authorized within named window; not yet executed

DB-A

Proposed disposition: Delete source ordinary RDS instance

Required evidence: Accepted source-write boundary, existing SNAP-A and pre-deletion restore test R4

Illustrative decision: HOLD: month-end export consumer unresolved

SNAP-A

Proposed disposition: Retain existing manual database snapshot

Required evidence: Capture boundary, custodian, expiry decision, pre-deletion restore record R4

Illustrative decision: Retain with financial owner and review date

KEY-A

Proposed disposition: Retain encryption dependency

Required evidence: SNAP-A dependency and approved recovery-role access

Illustrative decision: Excluded from deletion scope

ADDR-A

Proposed disposition: Release unused allocated address

Required evidence: WEB-A completion and no remaining consumer

Illustrative decision: Blocked until WEB-A readback

CONTRACT-A

Proposed disposition: Close commercial obligation if permitted

Required evidence: Supplier terms and cancellation acknowledgement

Illustrative decision: Finance review, not a resource delete action

WEB-A's authorization cannot be reused for DB-A. ADDR-A cannot be released merely because WEB-A was approved. SNAP-A and KEY-A intentionally survive technical retirement. The estate is not fully closed while DB-A remains on hold and CONTRACT-A remains unresolved.

In this fictional case, R4 tests the already existing SNAP-A, not a future final snapshot. Any final snapshot later created during an authorized DB-A deletion needs its own observed identity and subsequent validation before it can replace SNAP-A as the relied-upon artifact. R4 proves neither that a future snapshot exists nor that it is recoverable.

For a real execution, duplicate a row packet using these labelled fields. Keep linked technical and financial records instead of an unreadably wide spreadsheet.

11. Handle failures without inventing a rollback

Restore requires a retiring source file or role

Immediate containment: Hold source deletion

Recovery or next evidence: Recovery owner repairs and retests the packet

Required key is pending deletion or inaccessible

Immediate containment: Stop dependent cleanup; involve security owner

Recovery or next evidence: Review authorized cancellation or access recovery before the deadline; never assume a deleted key can be restored

A scheduled consumer wakes up after quarantine

Immediate containment: Suspend batch and preserve logs

Recovery or next evidence: Service owner assesses impact; restore connectivity only under the approved plan

Controller recreates a resource

Immediate containment: Stop repeated member deletion

Recovery or next evidence: Operator resolves controller intent and shared dependencies

Deletion response times out

Immediate containment: Mark outcome UNKNOWN

Recovery or next evidence: Reconcile exact resource state before retrying

Unexpected writes appear on the source

Immediate containment: Freeze retirement and escalate data integrity

Recovery or next evidence: Database owner determines write authority and reconciliation, not blind traffic reversal

A bill continues after resource deletion

Immediate containment: Keep finance closure open

Recovery or next evidence: Classify retained usage, contractual charges, timing or unexplained residuals

Reversal is action-specific. Re-enabling an authorized reversible rule is different from recovering a terminated instance. Recreating a resource may change its address, identity and access policy. The recovery plan must identify these consequences before deletion, not discover them during an incident.

12. Accept closure and schedule the retained estate's next review

The lead closes only the authorized scope. These acceptance criteria form the reusable closure checklist. Record a dated evidence reference and accountable owner beside each result; an unresolved mandatory criterion prevents full closure:

• PASS: target acceptance and write authority remain valid for this scope.
• PASS: every candidate has an exact identity, controller and consumer disposition.
• PASS: required recovery artifacts have accepted isolated test evidence and usable dependencies.
• PASS: each irreversible action had current, resource-specific authorization.
• PASS: action results were read back, and no unexplained controller recreation or consumer failure remains.
• PASS or explicitly open: financial evidence separates ended usage, retention costs, commitments and residual investigations.
• PASS: retained artifacts and supporting keys or roles have custodians, review dates and separately controlled eventual deletion.
• HOLD: any required identity, recovery result, ownership or authorization remains UNKNOWN.

Partial closure is acceptable when the boundary is explicit. List unresolved rows, owner and next decision date; do not hide them behind a whole-project completion badge. Financial reconciliation can remain open after technical retirement, with a named follow-up. Retention expiry triggers a new review, not silent deletion based on an old migration ticket.

If you need help applying this to a migration, discuss the specific unresolved boundary with Ampity's AWS consulting and migration team. Share a sanitized resource category and the decision you cannot yet defend. The useful deliverable is an owned retirement and recovery packet, not a larger delete list.