Cloud Account Cleanup
Deleting an environment removes Fractal Cloud from your cloud account and leaves your infrastructure running. That is deliberate: you can opt out of Fractal Cloud without an outage. It also means the resources — and their bill — are still there afterwards.
This page covers the other half: removing that infrastructure when you actually want it gone.
When you need this
You are leaving Fractal Cloud and want the account empty. Environment deletion stops the management layer, not the infrastructure. Your Live Systems keep serving traffic, which is the point — nothing goes down the moment you disconnect. When you have finished migrating away and want the resources removed, they have to be deleted deliberately. This is that step.
An initialization failed part-way and you want to retry from clean. Initialization is idempotent, but a run interrupted by a permissions gap or a quota limit can leave resources that block the retry — a VPC whose CIDR is now taken, a database subnet group whose subnets are gone, a resource group half-built. Emptying the account first makes the retry a fresh start rather than a reconciliation against wreckage.
These scripts delete infrastructure and its data. There is no undo, and no snapshot is taken. Always
do a --dry-run pass first and read what it lists.
What the scripts delete
Every resource Fractal Cloud creates is tagged at the moment it is created with a managed-by
marker. The cleanup scripts use that marker to decide what is theirs, so on AWS and Azure a customer
account holding your own workloads alongside Fractal's is safe to run against.
Two systems provision into your account, and they write different values:
| Marker | Written by | Covers |
|---|---|---|
managed-by = Fractal Cloud (AWS)managed-by = Fractal (Azure) | The environments service, during environment initialization | The Cloud Agent, its network, its database, its registry, its secrets |
managed-by = fractal-cloud | The Cloud Agents, on Live System resources | Everything your Live Systems provisioned |
The scripts match both, because an account you are emptying should keep neither.
Scope per cloud
| Cloud | Scope | Left alone |
|---|---|---|
| AWS | Resources tagged with either marker. Two exceptions AWS cannot tag at create time are matched by name: ECS task definition families fractal-* and IAM roles Fractal*. | Everything else in the account, plus each region's default VPC |
| Azure | Resource groups tagged with either marker. Deleting a resource group cascades to everything inside it. | Every other resource group in the subscription |
| GCP | The whole project. | The default VPC network, IAM service accounts, and the project itself |
GCP supports no labels at all on VPC networks, subnets, firewall rules, Cloud Routers or Serverless VPC Access connectors — and that is most of what environment initialization creates there. There is nothing to filter on, so the GCP script's scope is the project: every resource of a swept type goes, whoever created it.
Point it only at the project you nominated for Fractal Cloud. If that project also carries work of your own, do not run it — delete the resources by hand instead.
Getting the scripts
The three scripts, an AWS IAM policy covering exactly the permissions they need, and their tests live in the public samples repository:
github.com/Fractal-Cloud/fractal-ts-sdk-samples/tree/main/utilities/cleanup
git clone https://github.com/Fractal-Cloud/fractal-ts-sdk-samples.git
cd fractal-ts-sdk-samples/utilities/cleanup
Before you start
- AWS — AWS CLI v2 and
jq, with credentials for the target account (a profile or environment credentials). Attachfractal-cleanup-policy.jsonfrom the repository to the principal you run as; it grants read and delete across EC2, ECS, ELB, RDS, ECR, Secrets Manager, CloudWatch Logs, Resource Groups, IAM andtag:GetResources, and nothing else. - Azure — Azure CLI, authenticated, with Contributor or Owner on the subscription.
- GCP —
gcloudandjq, authenticated, with Editor or Owner on the project.
Delete the environment in Fractal Cloud before running a cleanup. If the agent is still running it will see its own resources disappear and try to reconcile them back.
Running it
Start with a dry run every time. It performs the same discovery and prints every deletion it would make without calling a single delete API.
AWS
# See what would go — no deletions
./fractal-aws-cleanup.sh --profile my-profile --dry-run
# Delete, after reviewing the dry run
./fractal-aws-cleanup.sh --profile my-profile
By default the script scans every enabled region, which is what you want when you do not know where
initialization got to. Narrow it with --region eu-west-1 when you do.
Confirmation asks you to type the account ID, not yes, so a script pointed at the wrong profile
stops at the prompt.
Azure
./fractal-azure-cleanup.sh --subscription <subscription-id> --dry-run
./fractal-azure-cleanup.sh --subscription <subscription-id>
Azure deletions are asynchronous. The script returns once each resource group deletion has been accepted; the groups take several more minutes to disappear.
GCP
./fractal-gcp-cleanup.sh --project <project-id> --dry-run
./fractal-gcp-cleanup.sh --project <project-id>
Read the dry-run output on GCP with more care than on the other two. Because the scope is the whole project, anything listed that you did not expect is something you are about to lose.
Options
| Flag | Clouds | Effect |
|---|---|---|
--dry-run | all | Discover and report, delete nothing |
--yes | all | Skip the confirmation prompt. For automation only |
--region | AWS | Limit to one region instead of every enabled region |
--report-dir <path> | all | Write the Markdown run report to a directory. Omitted, the report lives in a temp directory and is discarded |
Reading the report
Each run ends with a summary and a per-resource list:
- Deleted — the delete call succeeded.
- Already in progress — the resource was mid-deletion from an earlier run. Nothing to do.
- Not found — the resource disappeared between discovery and deletion, usually because deleting its parent took it with it. Not an error.
- Failed — the delete call was rejected. These are what to act on.
The script exits non-zero if anything failed, so it is safe to chain.
When something fails
DependencyViolation on a subnet or VPC (AWS). Something still holds a network interface in it.
The script drains the interfaces it can, but a resource created outside Fractal Cloud inside a
Fractal VPC will hold one. Find it in the console and remove it, then re-run.
A region timed out (AWS). RDS deletions dominate the teardown and a region with several
databases can outrun the 45-minute per-region budget. The report names the region; re-run with
--region <that-region> and it will pick up where it stopped.
DenyAssignmentAuthorizationFailed (Azure). A Databricks-managed resource group, protected by a
system deny assignment. It is removed when its parent workspace's resource group goes, and the
script already excludes it.
Permissions. The AWS script runs a preflight check and refuses to start when a required
permission is missing, rather than half-deleting and failing later with a confusing dependency
error. Grant what it names — fractal-cleanup-policy.json covers all of them — and re-run.
Cleanup is idempotent. Re-running after fixing a failure is always safe.
After cleanup
To start over, run environment initialization again. The account is empty, so it behaves exactly like a first-time setup.
To leave for good, see the permanent departure notes. If you want your Fractal definitions preserved as standard Infrastructure as Code first, see Terraform Extraction.