Running scripts safely

How to review warnings, use dry-run commands, test in non-production, and avoid destructive mistakes — especially with S3 lifecycle scripts.

Last updated July 4, 2026

Remediation scripts can stop instances, delete volumes, release IPs, and rewrite S3 bucket policies. Parsivex includes safety warnings with every script, but you are responsible for reviewing them before running any command in your AWS account. Follow this checklist every time.

1. Read warnings before the code block

Every script in the Fix it panel shows a Warnings section above the code block — the same order as in this help article. Warnings are not optional context; they flag irreversible actions, maintenance windows, and data-loss risks.

Before copying a script:

Expand the Fix it → panel on the finding
Read every bullet in the Warnings box
Confirm the resource IDs match what you expect
Only then copy and run the command

If a warning says to verify the resource is unused, verify it — check CloudWatch metrics, instance tags, and downstream dependencies first.

2. Use dry-run variants where provided

Many AWS CLI scripts include a companion dry-run command. Parsivex shows it in a separate block below the main script, with its own Copy dry run button.

Dry-run commands typically use read-only APIs:

Action script	Typical dry-run
`stop-instances`	`describe-instances`
`delete-volume`	`describe-volumes`
`release-address`	`describe-addresses`

Run the dry-run first to confirm the command targets the correct resources. Dry-run output is not available for every operation — Terraform snippets and some write-only APIs have no safe preview.

3. Test in non-production first

If your AWS organization has separate accounts or environments:

Run scripts in a development or staging account before production
For shared resources (VPC endpoints, NAT gateways), confirm no production traffic depends on the target
Schedule destructive changes during a maintenance window when teams are available to roll back

Parsivex scans one connected account at a time. Make sure you are running commands in the same account and region as the finding.

4. Back up before destructive operations

Some scripts delete data that cannot be recovered without a backup:

Operation	Backup step
Delete EBS volume	Create a snapshot first, or confirm an existing snapshot covers the data
Delete EBS snapshot	Verify no AMIs or volumes depend on the snapshot
Terminate EC2 instance	Snapshot attached volumes; export instance metadata if needed for audit
Delete load balancer	Confirm DNS records and target groups are updated
S3 lifecycle changes	Export current lifecycle config (see below)

Parsivex warnings call out snapshot requirements where relevant, but your compliance and recovery requirements may need additional steps.

5. S3 lifecycle scripts replace existing configuration

S3 lifecycle commands replace your entire bucket lifecycle config

AWS put-bucket-lifecycle-configuration replaces the full lifecycle configuration on a bucket. Any existing rules — transitions, expirations, abort-incomplete-multipart rules you added manually or via another tool — will be removed unless you merge them into the new JSON before applying.

Always run the pre-check command first. Parsivex S3 lifecycle scripts include a get-bucket-lifecycle-configuration command as the dry-run / pre-check step. Review the output. If rules already exist, merge the new rule with your existing rules in the lifecycle JSON before running put-bucket-lifecycle-configuration.

This applies to findings such as:

S3 wrong storage class — Intelligent-Tiering transition rules
S3 incomplete multipart uploads — AbortIncompleteMultipartUpload rules

The in-app Warnings box repeats this message on every S3 lifecycle script. Do not skip the pre-check even if you believe the bucket has no lifecycle rules — verify with the get command.

S3 lifecycle safe workflow

Copy and run the pre-check (get-bucket-lifecycle-configuration)
If output is empty, the bucket has no rules — the provided script is safe to apply as-is
If rules exist, copy the existing Rules array and merge the new rule from the Parsivex script into that array
Update the put-bucket-lifecycle-configuration command with the merged JSON
Apply during a low-traffic window and monitor storage class transitions

Scripts contain real resource IDs from your scan. Treat copied commands like credentials:

Do not paste them in public tickets, chat channels, or shared documents
Do not include them in screenshots sent outside your organization
Public Parsivex report links never include scripts — do not paste scripts into public channels

See AWS CLI vs Terraform for guidance on managing scripts in version control.

Quick safety checklist

Before running any remediation script:

Read all warnings in the Fix it panel
Run the dry-run / pre-check command when available
Confirm resource IDs match the finding you are fixing
For S3 lifecycle: run get-bucket-lifecycle-configuration and merge existing rules
Back up or snapshot data before delete operations
Test in non-production when possible
Run during a maintenance window for production resources

Remediation scripts overview — Where scripts appear and plan requirements
AWS CLI vs Terraform — Choosing the right script format
Reports and sharing — Why public reports strip scripts