Closing a cloud account, subscription or project removes the resources inside it, but the things pointing at it from outside (DNS records, trust policies, role bindings, bucket names, integrations and stored credentials) survive and can be claimed or abused. Decommissioning is usually driven by cost or a project ending, so it is run by whoever is tidying up, without a security checklist. This guide is an end-to-end runbook for retiring a whole AWS account, Google Cloud project or Microsoft Azure subscription, and for the large resources inside it: what each provider actually does when you close one, the order of operations, how to verify nothing is left behind, and how to roll back. It is for cloud platform, security and FinOps teams. It builds on the Cloud Landing Zone Security Guide (which covers the quarantine area in the hierarchy), the Server and Application Decommissioning Checklist (single systems) and the NHI Offboarding and Decommissioning Guide (machine identities). Providers are listed alphabetically.
Key takeaways
- Closing is not instant deletion. AWS keeps a closed account reopenable for a 90-day post-closure period, Google Cloud holds a shut-down project in DELETE_REQUESTED for 30 days, and Azure deletes a cancelled subscription automatically after 90 days.
- Clean the outside before the inside. Remove DNS records, cross-account trust, external role bindings and third-party integrations that point at the account before you close it; closure does not remove them.
- Some names are gone for good, others are up for grabs. AWS account IDs and Google Cloud project IDs are never reused, but a deleted S3 bucket name or Azure App Service hostname can be re-created by someone else.
- Quarantine before you close. Move the account into a suspended or decommissioned area with deny-all guardrails for a soak period, so anything still depending on it fails loudly while you can still reverse.
- Keep evidence and a record. Export logs, the resource inventory and the approvals before closure; the account's own logs may disappear with it.
What each provider does when you close
The provider side of closure differs in timing, reversibility and what lingers. The table summarises each provider's documentation as of November 2026.
| Item | AWS account | Google Cloud project | Microsoft Azure subscription |
|---|---|---|---|
| Action and who can do it | Close account; member accounts from the Organizations management account (console or CloseAccount API) | Shut down project; needs resourcemanager.projects.delete | Cancel subscription; needs Subscription Owner without a condition |
| Immediately after | Access only by reopening the account | Billing and resource usage stop; project unusable; linked billing account disconnected | Billing stops; VMs deallocated, temporary IP addresses freed, storage read-only |
| Recovery window | 90-day post-closure period; reopening restarts charges for remaining services | 30 days in DELETE_REQUESTED; owners can restore; billing must be relinked manually | Pay-as-you-go can be reactivated in the portal; other types through Azure Support (confirm the window with support) |
| Final deletion | After 90 days AWS deletes content and resources, except CloudTrail trails | Project and its data permanently deleted after 30 days | Data deleted 30 to 90 days after cancellation; subscription deleted automatically after 90 days; manual Delete available after 3 days (customer-led) once resources are removed |
| Identifier reuse | Account ID never reused; root email and account alias cannot be reused unless the alias is deleted first | Project ID cannot be reused, including after deletion | Hostnames of deleted resources can be re-created by others (see DNS below) |
| What lingers | User-created CloudTrail trails keep delivering unless deleted; Marketplace subscriptions not cancelled automatically; Reserved Instances and Savings Plans keep invoicing until they expire; closed member accounts count against the organisation's account quota until permanently closed at the end of the post-closure period | Soft-deleted projects count against quota until fully deleted; role bindings for deleted service accounts persist up to 60 days with a deleted: prefix | Custom roles listing the subscription in AssignableScopes need updating |
Two provider-specific traps deserve a line each. On AWS, if the root user's email uses a domain registered through Route 53 in the same account, AWS warns that closing the account suspends the domain and breaks email to the root address; transfer the domain or change the root email first. If the account is managed by AWS Control Tower, unmanage it before closing. See the AWS Control Tower Guide.
What survives outside the account
Most decommissioning risk sits outside the thing being closed. Inventory these dependencies before you start; each row is a way a retired account can still be used against you.
| Left behind | Why it matters | How to find it | Action |
|---|---|---|---|
| DNS records (CNAME, A, alias, MX, NS delegations) | A record pointing at a deleted resource's hostname or IP lets someone who claims that name serve content or receive mail on your domain (T1584.001) | Export every zone; match targets against the account's endpoints, IPs and hostnames | Delete or repoint records before deleting resources. See the Subdomain Takeover and Dangling DNS Guide |
| Storage bucket names | AWS warns that after a bucket in the shared global namespace is deleted, another AWS account can create one with the same name and receive requests meant for yours | List buckets and search code, configs and partner integrations for their names | Where anything may still call the bucket, empty it, keep it and block requests rather than delete |
| Cross-account trust | Roles, key policies and resource policies in other accounts that trust this account, and roles in this account that third parties assume | Search policies across the estate for the account ID, project number or subscription and tenant IDs; use access analysis tools | Remove trust statements and external IDs; notify third parties |
| Role bindings for the account's identities elsewhere | Service accounts, managed identities or roles from this account granted access in other projects, subscriptions or SaaS tools | Search IAM policies and SaaS integrations for identities from this account | Remove bindings; in Google Cloud, deleted service account bindings show a deleted: prefix until purged |
| Credentials stored elsewhere | Access keys, service account keys, connection strings and tokens for this account in CI/CD, secrets managers, laptops and partner systems | Secrets inventory and scanning; CloudTrail, Cloud Audit Logs or Activity log for the last callers | Revoke, then delete the stored copies |
| Federation and SSO assignments | Permission sets, enterprise applications and group mappings that still grant access | Identity provider and IAM Identity Center or Entra assignments | Remove assignments and the groups created only for this account |
| Log, backup and data copies | Logs, snapshots and replicas exported to central accounts keep data alive under retention rules | Central logging and backup inventories | Retain or delete per the Data Retention and Disposal Policy Template |
| Commercial commitments and marketplace subscriptions | Charges continue and vendor tenants keep data or access | Billing console and procurement records | Cancel or transfer before closure |
A staged decommissioning runbook
- Decide and record: open a decommission record with the account, project or subscription ID, owner, data classification, reason, approvals and the target closure date. Confirm no legal hold applies to the data.
- Inventory: list resources in every region, including hidden or global resources, using the provider's resource inventory (AWS Resource Explorer or Config, Google Cloud Asset Inventory, Azure Resource Graph). Record public endpoints, DNS names, IPs and bucket names.
- Map inbound and outbound dependencies: work through the table above. Ask the owners of connected systems and check recent audit logs for who still calls the account.
- Preserve: export the audit logs, configuration snapshots and the inventory to a central, retained location; back up any data that must be kept; record the evidence location in the decommission record.
- Clean the outside: remove or repoint DNS records, delete cross-account trust and external role bindings, remove federation assignments, and cancel or transfer domains, marketplace subscriptions and commitments.
- Revoke credentials: deactivate access keys and service account keys, disable service accounts and app credentials, and remove their stored copies. Disable first, delete after the soak; Google recommends disabling service accounts you are unsure about because they can be re-enabled.
- Quarantine: move the account into the suspended or decommissioned organisational unit, folder or management group, where a deny-all guardrail stops new activity. Set a soak period, for example 14 to 30 days (an NHI Mgmt Group recommendation), and watch for errors elsewhere and access attempts here.
- Delete resources deliberately: delete resources that do not need to survive, keeping buckets whose names must not be re-registered. Azure requires all resources to be deleted before a subscription can be deleted manually.
- Close: close the AWS account, shut down the Google Cloud project or cancel the Azure subscription, after the provider-specific checks above.
- Verify and sign off: run the checks in the next section, then close the record with evidence. Diary the end of the recovery window as the last point of no return.
Rollback
Every step before closure is reversible: move the account out of quarantine, re-enable disabled identities and restore DNS. After closure, use the provider's recovery window: reopen the AWS account, restore the Google Cloud project and relink billing, or reactivate the Azure subscription. Recovery is not perfect: Google notes some services can take up to 36 hours to resume after a restore, and deleted DNS names or bucket names may already have been taken. That is why the soak period comes before closure.
Verification: proving nothing is left behind
- DNS: no record in any zone resolves to a hostname, IP or endpoint that belonged to the account. Microsoft documents a Get-DanglingDnsRecords tool for Azure, and Defender for App Service alerts when an App Service is removed without its custom domain.
- Policies: a search of IAM, key and resource policies across the estate finds no reference to the account ID, project or subscription.
- Identities: no active key, service account, app registration or SSO assignment for the account remains; the last-used dates of revoked credentials show no attempts after revocation, or the attempts are investigated.
- Billing: no charges after the closure date other than documented commitments and the final bill.
- Inventory: the account is marked retired in the CMDB with the evidence location, and tags on remaining shared resources no longer reference it. See the Asset Inventory and CMDB Security Guide.
Decommissioning large resources inside a live account
The same outside-first rule applies when you retire a workload but keep the account. For each internet-facing resource, remove DNS before deleting the resource, and consider Azure DNS alias records, which become empty when the target is deleted, or the App Service domain verification TXT record (asuid), which stops another subscription validating your custom domain. For storage, AWS documents an account regional namespace for general purpose buckets: names created there can never be re-created by another account, which removes the bucket name reuse risk for new buckets. Use resource tags with an expiry date to find candidates; see the Cloud Resource Tagging Standard Template.
Where identity fits
A retired account is often where the oldest, least-watched credentials live: access keys created years ago, service account keys exported to build servers, and app registrations nobody owns. Treat credential revocation as the critical path, not a clean-up step, and record every revoked identity in the decommission record. Watch the audit trail of the quarantined account: any attempt to use a revoked credential during the soak tells you a dependency was missed, or that the credential had leaked. The OWASP NHI Top 10 NHI1 Improper Offboarding Guide covers the identity side in depth.
Choosing an approach
| Situation | Recommended approach |
|---|---|
| Sandbox or short-lived test account with no external references | Automated decommission on expiry: inventory, revoke, close; short soak of a few days |
| Production workload being retired | Full runbook with owner sign-off, 30-day quarantine soak and DNS verification |
| Account with public endpoints, custom domains or widely shared bucket names | Keep the names: retain empty buckets with access blocked and repoint DNS before any deletion |
| Divestment or transfer to another organisation | Transfer the account rather than close it; remove your federation, trust and central logging links, and rotate every credential before handover. See the Vendor Offboarding and Termination Guide for the contract side |
| Small organisation with a handful of accounts | A spreadsheet checklist and a single named approver is enough; the order of operations still matters |
| Large estate with frequent closures | Automate the inventory and dependency search; check AWS closure quotas and Google Cloud project quotas, as closed accounts and pending projects still count for a period |
Detection and measurement
- Dangling references at closure: DNS records, policies or bindings found pointing at closed accounts in periodic scans. Target zero.
- Post-revocation use attempts: count of denied calls with credentials revoked during decommissioning; each one is a missed dependency or a leak.
- Runbook completion: share of closures with a complete decommission record and evidence.
- Orphaned accounts: accounts, projects or subscriptions with no owner or no activity in 90 days that are not yet in the decommission pipeline.
- Spend after closure: charges after the closure date that are not documented commitments.
Framework mapping
| Activity | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | MITRE ATT&CK |
|---|---|---|---|
| Lifecycle management of accounts and their contents | ID.AM-08 | CM-8 System Component Inventory | None |
| Revoking identities and credentials | PR.AA-01 | AC-2 Account Management | T1078.004 Cloud Accounts |
| Removing DNS and external references | ID.AM-08 | CM-8 | T1584.001 Domains |
| Data retention, export and deletion | PR.DS-01 | SI-12 Information Management and Retention, MP-6 Media Sanitization | None |
| Ending third-party integrations | GV.SC-10 | AC-2 | None |
Common failure patterns
- Deleting the resource, keeping the record: the CNAME outlives the App Service or bucket and becomes a takeover target.
- Deleting a bucket that others still call: the name is re-registered and starts receiving your partners' uploads or your application's reads.
- Closing first, cleaning later: once the account is closed, its logs and inventory are hard to reach, so dependencies are never found.
- Revoking nothing because "the account is gone": keys and tokens for the account stay in CI/CD and partner systems, and access works again if the account is reopened.
- Forgetting the commercial tail: marketplace subscriptions, domains and commitments keep billing or keep vendor access after closure.
- No owner for the decision: accounts sit in a suspended area for years because nobody will approve the final step.
Practitioner checklist
- Open a decommission record with owner, approvals, data classification and legal hold check.
- Inventory resources in every region, including global, hidden and public-facing resources.
- Search the whole estate for DNS records, policies and bindings that reference the account.
- Export logs, configuration and inventory to a retained central location before anything is deleted.
- Remove DNS, trust, bindings, federation, domains and marketplace subscriptions before closure.
- Disable credentials first, delete them after the soak, and remove stored copies.
- Quarantine the account behind deny-all guardrails for a soak period and watch for use attempts.
- Keep bucket names that may still be called; empty and block them instead of deleting.
- Close, verify against the checks above, and diary the end of the provider's recovery window.
Standards and references
- AWS: Closing an AWS account
- AWS: Quotas for AWS Organizations
- AWS: Closing a member account in your organization
- AWS: General purpose bucket naming rules
- Google Cloud: Shut down and restore projects
- Google Cloud: Delete and undelete service accounts
- Microsoft Learn: Cancel and delete your Azure subscription
- Microsoft Learn: Prevent dangling DNS entries and avoid subdomain takeover
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Cloud Landing Zone Security Guide · NHI Offboarding and Decommissioning Guide · Server and Application Decommissioning Checklist · Subdomain Takeover and Dangling DNS Guide · Cloud Resource Tagging Standard Template