/amazon-opensearch-service

Amazon OpenSearch Serverless — Deprovision (Teardown)

Delete serverless resources in strict dependency order. Reversing the order fails, because a collection group cannot be deleted while it still has collections, and a security policy cannot be deleted while a collection it covers still exists.

The AWS MCP server is recommended for executing these teardown commands but is not required — all steps use standard AWS CLI syntax.

Order (MUST follow)

1. Delete collection(s)
2. Wait until each collection is fully gone
3. Delete the collection group (NextGen only)
4. Delete the security/data access policies

Destructive-action rule: before deleting anything below, list every resource that will be removed and get explicit user confirmation, because collection deletion (Step 1) is irreversible and destroys all indexed data.

Step 1: Delete collection(s)

aws opensearchserverless delete-collection --id <collection-id>

A collection MUST be ACTIVE (or FAILED) before it can be deleted. If delete returns ConflictException about status, the collection is still being created — wait and retry, because AOSS rejects deletes on collections mid-creation.

Step 2: Confirm deletion completed

aws opensearchserverless batch-get-collection --ids <id1> <id2>

Deletion is complete when EITHER the id appears in collectionErrorDetails with "errorCode":"NOT_FOUND" OR collectionDetails is empty. Do NOT poll for a DELETED status, because AOSS removes the collection entirely and returns NOT_FOUND rather than a terminal status.

Step 3: Delete the collection group (NextGen)

aws opensearchserverless delete-collection-group --id <group-id>

If this returns ValidationException ("has collections associated"), a collection in the group is still active or still deleting — delete/await remaining collections first, because a non-empty group cannot be removed.

Step 4: Delete policies

aws opensearchserverless delete-security-policy --type network    --name <name>-network
aws opensearchserverless delete-security-policy --type encryption --name <name>-encryption
aws opensearchserverless delete-access-policy   --type data       --name <name>-data

Security Considerations

• Verify a backup exists first, and that it is encrypted at rest. Collection deletion is irrecoverable — confirm a snapshot or exported copy exists before proceeding if the data may still be needed, because there is no undo. Ensure the backup itself is encrypted at rest (e.g., S3 server-side encryption with a customer-managed KMS key for a manual snapshot or export), because an unencrypted copy of sensitive data is a standing exposure risk even after the collection is deleted.
• Audit who initiated the teardown. Confirm AWS CloudTrail is enabled so the DeleteCollection/DeleteCollectionGroup/Delete*Policy calls are recorded with the caller identity and timestamp.
• Alert in real time on teardown calls. Beyond passive CloudTrail logging, configure an EventBridge rule (or a CloudTrail → CloudWatch metric filter) on DeleteCollection/DeleteCollectionGroup from unexpected principals that notifies via SNS, because an irreversible delete warrants immediate detection rather than after-the-fact log review. Encrypt the SNS topic with a customer-managed KMS key and restrict sns:Subscribe to authorized principals via a topic policy, because teardown alerts carry resource identifiers that should not reach unintended recipients.
• Use least-privilege, collection-scoped permissions. The caller SHOULD hold only the delete actions needed on the specific collection/group ARNs rather than aoss:* on all resources, because a broad teardown identity can remove unrelated production collections.
• Guard against accidental production teardown. Assume any collection is production unless its name/tags clearly indicate otherwise, and require explicit confirmation before deleting, because an accidental delete causes an outage and permanent data loss.