Documentation / Operations

Uninstall

Remove an OBSESC deployment from your AWS account: what deleting the stack removes, what it deliberately leaves behind, and how to clean up the rest.

OBSESC runs entirely in your AWS account, so uninstalling means deleting the CloudFormation stack and cleaning up what it deliberately leaves behind. Your raw events in S3 are never deleted by the stack, and they stay readable without OBSESC.

Before you start

Decide what happens to your raw events. They’re standard Parquet with Iceberg metadata, and Athena, Trino, Spark or DuckDB can read them without OBSESC. You can keep the bucket as an archive, or empty and delete it yourself at the end.
Stop your shippers or point them somewhere else, so they aren’t retrying against a node that’s about to disappear.
Give the node a few minutes after the shippers stop, so it commits everything it has accepted to S3.
Export anything else you need. Anything stored only on the node’s volumes, including the navigation tier and anomaly records, is removed with the stack.

If you run a multi-node deployment, contact us before you start.

1. Delete the stack

STACK=my-obsesc
aws cloudformation delete-stack --stack-name "$STACK"
aws cloudformation wait stack-delete-complete --stack-name "$STACK"

Deleting the stack removes:

the node instance and its root volume
the stack’s WAL, summary and anomaly volumes, including the navigation tier
the security groups, IAM role and instance profile
the snapshot lifecycle policy and its role
the optional UI load balancer, target groups, listeners and DNS record, if you enabled them

It keeps:

Resource	Why	What to do
The raw events S3 bucket	If the stack created it, it has a `Retain` deletion policy. If you brought your own, the stack never managed it	Keep it as an archive, or empty and delete it yourself
EBS snapshots	Snapshots already taken, both the daily ones and any you took by hand, aren’t deleted with the policy	Delete them when you no longer need them (below)
Volumes you created yourself, for example during a restore	The stack doesn’t own them	Delete them (below)
Your KMS key, Secrets Manager secrets, SSM parameters, certificates and identity provider configuration	You supplied these as parameters, so the stack doesn’t own them	Remove them if nothing else uses them

2. Clean up what’s left

Leftover data volumes

OBSESC data volumes are tagged Project=<stack-name>. A volume in the available state is detached and still costs money:

aws ec2 describe-volumes \
  --filters "Name=tag:Project,Values=$STACK" "Name=status,Values=available" \
  --query 'Volumes[].{id:VolumeId,size:Size,purpose:Tags[?Key==`obsesc-purpose`]|[0].Value,created:CreateTime}' \
  --output table

Before you delete a volume tagged obsesc-purpose=wal, make sure its node had committed everything to S3. A WAL volume from a node that stopped unexpectedly can hold events that never reached S3. Then delete:

aws ec2 delete-volume --volume-id <vol-id>

Snapshots

aws ec2 describe-snapshots --owner-ids self --filters "Name=tag:Project,Values=$STACK" \
  --query 'Snapshots[].{id:SnapshotId,when:StartTime,purpose:Tags[?Key==`obsesc-purpose`]|[0].Value}' --output table
aws ec2 delete-snapshot --snapshot-id <snap-id>

The raw events bucket (optional)

Only do this if you’re sure you don’t want the data. Deleting the bucket is permanent. If you enabled S3 Object Lock, objects can’t be deleted until their retention period ends; in compliance mode, not even by the root user. OBSESC also keeps its own metadata, such as the Iceberg catalog, under other prefixes in the same bucket. If the bucket holds nothing else, you can empty and delete it in the S3 console, or with:

aws s3 rm s3://my-obsesc-bucket --recursive
aws s3api delete-bucket --bucket my-obsesc-bucket

3. Cancel the subscription

To stop the subscription, cancel it in the AWS Marketplace console under Manage subscriptions.