CloudAgent gives you AI agents that manage your cloud infrastructure. They handle tasks like security compliance, cost optimization, deployments, and monitoring. You remain in control as agents show you their plans, wait for your approval, then execute. Think of it as having a cloud operations team that works 24/7 without needing to hire an army of cloud experts.

How can AI agents be trusted with production cloud infrastructure?

You stay in control through approval workflows where every infrastructure change can require human approval before execution, custom security controls with granular access rules, complete audit trails of every action, self-hosted deployment options, and progressive trust models starting with read-only access.

How does it actually reduce costs?

CloudAgent agents delete unused resources, schedule non-production shutdowns, right-size infrastructure based on usage patterns, and recommend architectural optimizations. Early customers report 15-40% cost reduction within 90 days. Unlike dashboards, CloudAgent actually fixes the problems.

1. Assessment

Enumerate instances and attached EBS volumes
User: review and approve DeleteOnTermination changes

2. Configuration

Set DeleteOnTermination=true for approved mappings

3. Validation

Verify DeleteOnTermination persisted

1 Credits

Set DeleteOnTermination=true for attached EBS volumes so they are removed when i

Overview

Configure DeleteOnTermination=true for attached EBS volumes so they are removed when instances terminate. This plan will enumerate EC2 instances and their block-device mappings, surface risks and anomalies, guide you through selecting and approving exactly which mappings to change, execute the approved updates with safety controls (scheduling, concurrency, optional stop/start, and launch-template updates), and finally validate that the desired DeleteOnTermination setting persisted. Throughout the workflow the plan collects authoritative, timestamped API evidence and produces machine-readable artifacts for approval, execution, results, and verification so changes are auditable and repeatable.

Execution Details

Phase: Assessment — enumerate instances and attached volumes

Goal: Build an authoritative, machine-readable inventory of instances and every attached EBS mapping.
Key actions:
- List all EC2 instances and capture identifying/operational fields (InstanceId, state, type, AZ, platform, launch time, root device name) plus full tag sets.
- For each instance, collect BlockDeviceMappings and for each mapping record DeviceName, VolumeId (if present), current DeleteOnTermination flag, AttachTime and attachment status, and whether it’s the root device.
- For each VolumeId retrieve volume metadata (state, size, type, IOPS/throughput, encryption/KMS, snapshotId, create time, multi-attach and tags).
- Detect and record anomalies (missing VolumeId, mismatched states, inconsistent timestamps) and compute derived fields (ageDays, days-since-last-attach, recently-created within grace period).
- Capture per-call API metadata (request IDs, pagination tokens, timestamps) and record any API errors (AccessDenied, Throttling, NotFound) attached to relevant entries.
- Produce and persist a JSON inventory keyed by InstanceId that includes instance fields, mappings with EBS metadata and DeleteOnTermination, anomaly/risk flags, derived fields, and API evidence.
- Produce summary aggregates (counts by instance state, total attached GiB, mapping counts for DeleteOnTermination true/false, root vs data volumes, protective/ownerless volumes).

Outputs: machine-readable inventory artifact and human-readable summary.

Phase: User selection & approval — review and authorize changes

Goal: Present inventory, collect exact mappings to change, and capture constraints, scheduling, and approval metadata.
Key actions:
- Deliver inventory with per-mapping details (InstanceId, DeviceName, VolumeId, current DeleteOnTermination, root/data flag, tags, anomaly/risk evidence).
- Guide the user to select mappings to update using InstanceId+DeviceName or InstanceId+VolumeId pairs and collect per-item constraints (allow-root-change, exclude-data-volumes, protective-tag exclusions, maximum volume size, business rules).
- Collect execution preferences: change window (immediate or scheduled), stop-on-first-error vs continue-on-error, concurrency throttle, and whether to perform a live pre-change re-check.
- Collect notification and owner-acknowledgement preferences, rollback/safety preferences (revert behavior, pre-change tagging, preserve prior state), and any stop/start sequencing instructions.
- Require explicit acknowledgement of operational risk (irreversibility of DeleteOnTermination=true) and record approver identity and timestamp.
- Validate the user selections against the inventory (existence, matching VolumeId/DeviceName, mark no-ops where already true, flag changed mappings for reconfirmation).
- Persist a machine-readable approval artifact containing approver, timestamp, approved mappings, per-item constraints, scheduling, notification and rollback preferences, concurrency and error handling policies, and any conditional approvals.

Outputs: approval artifact, brief approval summary (approved/skipped/deferred counts).

Phase: Configuration — apply DeleteOnTermination=true to approved mappings

Goal: Safely apply the approved DeleteOnTermination changes and record full audit evidence.
Key actions:
- Load approval artifact and latest inventory, derive definitive set of mappings to act on.
- Perform live pre-change verification per mapping (confirm instance/volume existence, current mapping, and current DeleteOnTermination); record API request IDs and timestamps.
- Skip and record any mapping that no longer qualifies (attachment changed, instance terminated, protective tag added) with reason and timestamp.
- Enforce scheduling: run only inside the approved change window or queue/schedule otherwise; honor concurrency throttle and error-handling preference.
- Where required and approved, stop instances before change and restart after (follow user stop/start instructions); otherwise skip mappings that require a stop if disallowed.
- Prepare and apply the update to set DeleteOnTermination=true for each mapping. If necessary and approved, update launch templates or instance attributes so future launches inherit the setting; record prior and updated template JSON.
- Capture and persist raw API responses for every update (success/failure, request IDs, timestamps) and record per-mapping change logs (InstanceId, DeviceName, VolumeId, previous vs new value, API metadata, stop/start actions, approver reference).
- On failures capture full error details and remediation guidance, and proceed according to stop-on-first-error or continue-on-error preference.
- Optionally send pre/post-change notifications and record delivery/acknowledgement status.
- Produce and persist a machine-readable change-result artifact listing per mapping outcome (updated/skipped/failed), previous/new DeleteOnTermination values, API metadata, stop/start actions, and remediation recommendations.

Outputs: change-result artifact and persisted change logs for auditing.

Phase: Validation — verify changes persisted and produce verification report

Goal: Confirm DeleteOnTermination==true persisted for updated mappings, detect mismatches, and provide remediation guidance.
Key actions:
- Load change-result artifact and drive verification checks for reported updated, skipped, and failed mappings.
- Re-read instance block-device mappings and confirm DeleteOnTermination==true for each updated mapping; capture verification API request IDs and timestamps.
- For skipped/failed mappings re-check current state and record exact reasons with API evidence.
- When intended settings did not persist, produce a field-level diff between intended and actual state, capture any API errors and recommended remediation (reapply, stop-and-retry, update launch template, escalate).
- Verify that any launch-template or attribute updates intended to affect future instances were applied; include diffs and API evidence if mismatched.
- Compare pre-change inventory to post-change inventory to surface any unintended changes and flag unexpected differences with evidence.
- Produce and persist a consolidated, machine-readable verification report with per-mapping pass/fail status, API metadata, remediation steps, and summary totals (verified, skipped, failed).
- Link verification report to the approval and change-result artifacts for a complete audit trail and mark workflow state as completed or requires manual remediation based on outcomes.

Outputs: verification report, linked audit artifacts, and clear next steps for any remaining remediation.

Artifacts produced and tracked throughout:

Inventory artifact (authoritative instance + mapping data with API evidence)
Approval artifact (approved mappings, constraints, scheduling, approver identity)
Change-result artifact (per-mapping outcomes and raw API responses)
Change logs (per-update audit entries)
Verification report (post-change validation, diffs, remediation)

Risk controls and safety features summarized:

Root vs data volume risk flags and per-item allow-root-change gates
Protective-tag exclusions and owner acknowledgement workflows
Live pre-change verification and optional instance stop/start sequencing
Scheduling windows, concurrency throttles, and error-handling policies
Full capture of API request IDs, timestamps and raw responses for auditability
Conditional approvals and gated execution until conditions are satisfied

Next steps for an operator:

Review the inventory and approve mappings with the required constraints and scheduling preferences.
Confirm notification, rollback, and stop/start policies.
Execute or schedule the configuration phase and monitor the produced artifacts.
Review the verification report and perform any required manual remediation.