Shutting down AWS or GCP: databases and logs to preserve first

What should you preserve before shutting down AWS or GCP?#

Before shutting down AWS or GCP, preserve anything that records how the company built, ran and supported its product: production and analytics databases, object storage, application logs, audit trails, infrastructure-as-code, CI/CD history and the billing record. Customer data inside those systems needs separate handling under customer contracts.

The order matters more than the tools. Cloud providers generally keep a closed account's resources only for a limited period before deleting them permanently, and the rules change, so check the provider's current documentation and treat closure as irreversible. Everything worth keeping should sit outside the account, in a format you can open without the provider, before anyone closes it.

The preserve-first checklist#

The preserve-first checklist runs in a fixed order, because each step protects the one after it. Write down each step's date and owner; if the records are later assessed for licensing or needed in a dispute, that log is the proof of what was kept and how.

• 1Freeze: stop automated deletion jobs, lifecycle rules and log expiry settings that could remove records during the wind-down.
• 2Secure access: confirm who holds root or organization admin credentials, multi-factor devices and billing access.
• 3Inventory: list every account, project, region, database, bucket, log group and key, including forgotten test environments.
• 4Classify: mark each item as company records, customer data under contract or disposable infrastructure.
• 5Export: copy company records to portable formats, such as SQL dumps, CSV or Parquet, and plain-text or JSON logs.
• 6Verify: open exports outside the cloud, compare row counts with the source and confirm encrypted files decrypt.
• 7Store: place the archive on company-controlled storage or encrypted drives with a named custodian.
• 8Delete: remove customer data as contracts require, then resources, then close the account.

Where the records live in each cloud#

Record types map to different services in each cloud, but the preservation goal is the same: get the data out in a form that does not need the provider to read it. Check each service's current export options in the provider's documentation before planning the work.

Why snapshots and backups are not enough#

Snapshots and backups are not enough because they are stored inside the provider, in a form you restore through the provider's own services, and those kept in the closing account go when the account goes. A database snapshot is a convenience for running systems, not an archive for a closing company; copying it to another account only moves the dependency.

Encryption adds a second trap. Data encrypted with keys held in the provider's key management service cannot be read once those keys are deleted, and key deletion is often scheduled as routine cleanup. Keep keys active until every export has been decrypted and opened outside the cloud.

Schema matters as much as rows. An export of tables with cryptic column names is hard to use a year later, so save the schema, the migration history and a short field dictionary with each database export.

Which logs are worth keeping?#

Logs worth keeping are the ones that record decisions and events, not routine traffic. Audit trails, deployment records and incident timelines are usually compact and explain how the system changed and who changed it.

Check retention obligations before deleting anything. Contracts, tax rules, pending disputes or a litigation hold may require certain records to be kept, and counsel should confirm what applies. Logs also hold personal data such as IP addresses and user IDs, and sometimes secrets; scanners such as TruffleHog look for credentials across logs and object stores and are worth running before an archive changes hands.

Customer data is not yours to keep by default#

Customer data in a SaaS production database is usually governed by the customer agreement and data processing terms, which may require the company to return or delete it at termination. Preserving the company's own records is not a license to keep customers' records.

Separate the two early. Company records, such as engineering history, support tickets, incident reports and internal operating metrics, may be preserved and later assessed. Customer content follows the contract: export it for customers who ask, delete it on schedule and keep a deletion record that names the date, the systems and the person responsible.

Illustrative: a scheduling software company winds down its cloud#

Illustrative: a fictional appointment scheduling software company is closing. Its product runs on AWS with an Aurora PostgreSQL database, S3 buckets for customer uploads and CloudWatch logs, while its analytics sit in a separate GCP project with BigQuery. The CTO is the last engineer still employed.

She disables lifecycle rules and log expiry first, then inventories both clouds and finds a forgotten staging account. Customer data is exported for customers who request it and deleted per contract, with a deletion log. Company records, including CloudTrail history, deployment history, error logs and internal BigQuery tables on support volumes, are exported to Parquet and text files on encrypted drives, then opened and checked on a separate laptop. Only then are keys scheduled for deletion and the accounts closed.

The archive is later assessed for licensing alongside the company's Jira and Zendesk history. Because the export log documents every step, the wind-down officer can show what was kept, what was deleted and why.

How SourceX approaches a cloud shutdown#

SourceX's view is that preservation comes before assessment. A fit check needs only metadata, such as which systems held records and for how long, so a company can preserve first and decide later without sharing files.

If a package proceeds, large archives stay in the company's own storage or ship on encrypted drives; SourceX never hosts multi-terabyte datasets. The Rights step of the SourceX five-step transaction separates company records from customer data under contract, and the SourceX Evidence Packet records provenance and the release authorization from whoever holds authority during the wind-down.