AWS CLI vs Terraform

Parsivex remediation scripts come in two formats: AWS CLI commands you can run immediately from a terminal, and Terraform HCL snippets for resources managed in your infrastructure-as-code. This article helps you choose the right format and apply Terraform changes safely.

When to use AWS CLI

Use the AWS CLI script when:

• You manage the resource manually in the AWS Console or CLI (not in Terraform)
• You need a one-off fix right now without opening a pull request
• The operation is simple and self-contained (stop an instance, release an Elastic IP, delete an orphaned volume)
• A dry-run command is available and you want to preview the target resources first

CLI scripts are copy-paste ready. Configure your AWS credentials (or assume the same role Parsivex uses), set the correct region, and run the command.

When to use Terraform

Use the Terraform snippet when:

• The resource is already defined in your Terraform state
• You want the change tracked in version control and applied through your normal terraform plan / terraform apply workflow
• You are removing a resource from management without deleting the code immediately
• You are adding or updating lifecycle rules on an aws_s3_bucket_lifecycle_configuration resource

Terraform snippets from Parsivex are starting points — paste them into the appropriate .tf file, adjust resource names to match your modules, and run terraform plan before applying.

Terraform removed blocks for deletion

For resources you want to destroy but keep out of state cleanly, Parsivex Terraform scripts may suggest a removed block (Terraform 1.7+):

removed {
  from = aws_eip.example

  lifecycle {
    destroy = true
  }
}

Use destroy = true when you are sure the resource should be deleted (for example, an unused Elastic IP). Use destroy = false when you are refactoring Terraform but keeping the AWS resource.

Always run terraform plan and review the destroy actions before terraform apply.

S3 lifecycle in Terraform

For S3 findings, Terraform scripts show how to add or update rules on aws_s3_bucket_lifecycle_configuration. Unlike the CLI approach, Terraform manages lifecycle rules incrementally through state — it does not blindly replace the entire bucket configuration on every apply.

Still follow the safety guidance in Running scripts safely:

• Review existing rules in your .tf files and in AWS before merging
• Do not duplicate rules that already exist
• Plan in a non-production workspace first when possible

Scripts contain real resource IDs

Every remediation script — CLI or Terraform — is filled with identifiers from your scan: instance IDs, volume IDs, bucket names, allocation IDs, and ARNs.

Public Parsivex report links never include remediation data. If you export a PDF or copy a script, treat it as confidential — it lists your live AWS resource IDs.

Mixing CLI and Terraform

It is fine to use both formats in the same account:

• Fix an orphaned EBS volume with CLI today
• Add S3 lifecycle rules through Terraform in your next IaC PR

Avoid applying CLI changes to resources that Terraform also manages — drift causes the next terraform plan to fight your manual changes. Prefer Terraform for anything already in your state file.

Related articles

• Remediation scripts overview — Where scripts appear in Parsivex
• Running scripts safely — Warnings, dry-run, and S3 lifecycle pre-checks
• Infrastructure-as-code setup — Connecting Parsivex when you manage AWS with Terraform or CloudFormation