Skip to main content

Deleting a deployment and clearing an account

For Owners and Operators (or a DeploymentOperator or AccountManager Role) removing a Studio deployment, then resetting the AWS account it lived in; Viewers can watch the jobs. Deleting is irreversible once the grace window has passed, so export anything you need from Studio first. Nothing here touches your DNS records, your private hosted zones or your Microsoft Entra tenant.

Before you delete a private deployment, disassociate your private hosted zone (or resolver rules) from its VPC. The association belongs to your zone's account: it does not stop the delete, and once the VPC is gone only the zone's account can see or remove it.

Delete a deployment​

  1. Open Fleet, click the deployment, click Delete in the header.
  2. Delete this deployment warns that this starts an irreversible teardown of the deployment's CloudFormation stacks, cancellable for a short grace window. Type the name the dialog shows (the deployment's app domain) and click Start teardown.
  3. The console opens the uninstall job in the Jobs view.

Refusals: already uninstalled; "Another job is already in flight for this deployment."; the name could not be confirmed; or the request could not be sent (nothing was applied). Delete is disabled while another job runs and without the DeploymentOperator permission.

Cancel during the grace window​

While the first step waits, a bar reads "Nothing has been deleted yet. Cancel now to keep <name>." Click Cancel teardown. Once the window has passed the bar refuses ("this teardown can no longer be cancelled from here"). The window is 30 seconds by default (engine setting ORG_DESTRUCTIVE_GRACE_SECONDS); the bar disappears when it has passed.

Read the teardown report​

The uninstall job runs nine steps: the grace window, scaling services to zero and draining Redis, then deleting the task-def stack, the compute stack, the private network (the routes stack, then the Transit Gateway attachment, which must be gone before the VPC can be deleted), the stateless stack, the edge stack (an existing public deployment only), the environment Lambdas and their network interfaces, and the core stack. Task definition revisions kept for restore points are deregistered too. Resources that hold data (tables, secrets, buckets, repositories, file systems) are retained rather than deleted. When the job deletes the core stack, the Jobs view adds What was retained: a table grouped by resource type, each row "<identifier> · <region>" with a note on its scope, or "Nothing is retained".

On success the deployment leaves the Fleet list; its Overview stays readable at its own address and reads Uninstalled. Its Endpoints group names the record that pointed at it: for a private deployment, "The app domain's record in your private DNS zone pointed at <target>, which no longer exists: remove the record."; for an existing public one, the CNAME points at a distribution that no longer exists, and CloudFront refuses a new install under the domain while it stands. A failed uninstall names what stopped it; stack_delete_failed, core_stack_blocked_by_lambda_enis, service_connect_namespace_delete_pending and redis_busy resume once the named resource is released (Failure codes). The VPC range stays held in the Address plan until the VPC is gone.

Clear the account​

Open Accounts, click the account, and find Clear account. It scans the account's first allowed region for every AlphaAgent resource still there and permanently deletes it: use it to reset an account before re-registering it, or to finish a teardown that did not complete.

  1. Click Scan for stray resources. Results list each resource as "<type>: <id>" under its region, or "No AlphaAgent resources found in this account/region." The scan includes Transit Gateway attachments of ours (shown as "<vpc id> -> <tgw id>"), our prefix lists and active task definition revisions. If some types could not be checked, the line "Could not check: <kinds>" asks you to re-run the CloudFormation template above, then scan again. With EnableApiWafPermissions left false, AWS::WAFv2::IPSet and AWS::WAFv2::WebACL are always on that line: without the opt-in the Organisation never created any, and re-running the template does not change it.
  2. Click Wipe N resource(s). The confirmation warns that every AlphaAgent resource in this account/region is deleted (every deployment's stacks, data and networking), irreversibly; the registration role and stack are preserved so Verify keeps working. Deployment records are marked uninstalled here too; if one is still running you must type the account id.
  3. Click Start clearing. The job runs on this page with the same parked-step card, failure card and timeline as a deployment job, and appears in job lists as Account wipe. Its nine steps mark deployments uninstalled, shut compute down, delete every stack, force-delete what did not delete, remove the CloudFront front door of an existing public deployment (skipped when the account does not allow us-east-1 and never had one), remove the remaining data, storage, logs and task definitions, remove networking (Transit Gateway attachments first, waiting until they are deleted), remove access roles except the registration role, and confirm everything is cleared. The staging bucket is emptied.

A wipe that finds resources still standing fails with wipe_leftovers, listing them. Redo re-runs the whole pass (every step is idempotent) and a second pass clears most leftovers; or Abandon, then scan and wipe again. A resource that survives twice is held by a bucket with Object Lock, a resource-level service control policy (SCP) or a cross-account share; lift that in the AWS console first.

Verify the account afterwards​

Click Verify again. Verify assumes the account's role, retries any CloudFront edge stacks still waiting on Lambda@Edge replica cleanup (skipped when the account does not allow us-east-1), confirms "Last Clear account left nothing behind" and releases removed deployments' VPC ranges. A clean account can take a new deployment (Accounts).

What you should see​

  • After a delete: an Uninstall job ending Succeeded, What was retained listing the data-bearing resources, the deployment gone from the Fleet list and its own page reading Uninstalled.
  • After a clear: an Account wipe job ending Succeeded, a scan that finds nothing, and Verify passing.

Notes​

  • What remains yours to remove: the app domain's DNS record; your private hosted zone's association with the deployment's VPC (disassociate it before the delete, or remove the stale association from your zone afterwards); the Enterprise Applications Microsoft created for the deployment's single sign-on (the console never removes them; delete them in the Entra admin center); the account's registration stack, if you also delete the account from Organisations (Accounts covers its staging bucket); and the retained data resources, once you no longer need their contents (Clear account removes them). Your Transit Gateway keeps no attachment of ours: the delete removes it, and your network team sees it as deleted.
  • Clear account works on the account's first allowed region only. The registration role and stack are preserved.
  • A deployment record leaves the Fleet list once uninstalled; its page stays readable at its address, and Audit keeps its history.
  • Lambda@Edge replicas are released by AWS after a distribution is deleted, so an edge stack can linger; Verify retries it each time.