Update TrendAI Cloud One File Storage Security to Trend AI Vision One File Security Storage using update tool

Views:

This guide walks you through updating your AWS account from TrendAI™ Cloud One File Storage Security (C1FSS) to Trend AI Vision One™ File Security Storage (V1FSS). The update is coexistence-based and zero-downtime: the tool stands up V1FSS alongside your existing C1FSS, confirms the new scanning works, and then decommissions C1FSS one region at a time, so your buckets are never left unprotected.

At a glance:

Dry run: run previews every change without touching anything.
Execute: run --execute deploys V1FSS beside C1FSS (both scan in parallel).
Verify & tear down, per region: prove V1FSS works, then delete that region's C1FSS.

You can back out anytime before teardown with rollback.

Prerequisites

A Trend AI Vision One™ API key with the Operator role (or a custom role with equivalent permissions and scope). The tool uses it to enable File Security and deploy the CAM template into your AWS account.
AWS credentials for the account where C1FSS is deployed, able to both deploy the Trend AI Vision One™ CAM connector / File Security Storage feature stacks and run the update's own discover/teardown/verify actions. An administrator-equivalent role is simplest; for a scoped policy, refer to AWS required permissions.
Access to AWS CloudShell (recommended). It supplies AWS credentials ambiently, so there's no local setup. To run elsewhere, see the CloudShell FAQ.

Run the update

Open CloudShell and set your API key.

In the AWS account where C1FSS is deployed, open CloudShell and set:
export V1_API_KEY="your-vision-one-api-key"
Download the tool and do a dry run.
```
curl -sSL https://v1-file-security-storage.s3.amazonaws.com/aws/tools/v1fss-migrate.zip \
  -o v1fss-migrate.zip
unzip -q v1fss-migrate.zip
python3 -m v1fss_migrate run
```
Every mutating step is dry-run by default: nothing is created, changed, or deleted. This prints the discovered C1FSS stacks, the buckets they scan, and the exact actions the tool would take, walking through preflight → discover → onboard → sync → enable → verify.
Review the plan, then execute.
```
python3 -m v1fss_migrate resume --run-id <run-id> --execute
```
Each run gets a run-id (printed at the start and checkpointed to ~/.v1fss-migrate/state-<run-id>.json). If CloudShell's idle timeout interrupts you, resume without repeating completed phases:
```
python3 -m v1fss_migrate resume --run-id <run-id> --execute
```
During run --execute you may be asked two questions (both need an interactive terminal, CloudShell counts):
- SWP instance selection: if your tenant has more than one Server & Workload Protection instance, onboard pauses and lists them to pick by number. Skip the prompt with --workload-instance-id <id> (find it in the Trend AI Vision One™ console under Server & Workload Protection).
- Verify bucket: verify runs once per region and asks for a bucket that is not protected by C1FSS and located in that region, so it can prove V1FSS scans it there. Enter a bucket name, or leave it blank to skip that region's verification (skipping is fine; see the verify FAQ). A bucket that is C1FSS-protected, or in a different region, is rejected on the spot and re-asked.

Verify and tear down, one region at a time.

After step 3, every region has already run verify (passing, or marked skipped if you left the prompt blank), so all regions are teardown-ready. Teardown is gated on V1FSS having confirmed your buckets protected, not on verify.

Note

Verify is optional. Run it standalone only to get an explicit end-to-end scan proof for a region, or to re-verify a region whose verify failed. Use a bucket that is not under C1FSS and located in --regions's region:

python3 -m v1fss_migrate verify \
  --run-id <run-id> --regions us-east-1 \
  --verify-bucket <bucket-not-under-c1fss> --execute

Tear down the region's C1FSS stacks:

python3 -m v1fss_migrate teardown \
  --run-id <run-id> --regions us-east-1 --execute

Teardown is gated per region. It deletes a region's C1FSS stacks once that region's verify has passed or was skipped; a verify that actually ran and failed blocks that region until you fix the cause and re-run it. Either way, teardown only ever deletes stacks for buckets V1FSS confirmed as protected, and one region's status never blocks another. (After run --execute, the tool prints the exact teardown … --execute command for you to copy.)

If your C1FSS is deployed in a VPC, teardown takes noticeably longer. Deleting a VPC-attached scanner (or storage) Lambda waits on AWS network-interface (ENI) cleanup, which routinely runs 10–40 minutes per stack, vs. a minute or two for a non-VPC stack. Stacks delete in parallel (so the phase is bounded by the slowest one, not the sum), and each delete waits up to 1 hour by default; raise it with --teardown-timeout <seconds> if needed. This is expected; let it run. See the teardown FAQ.

If C1FSS spans more than one region, repeat both commands for each remaining region:

python3 -m v1fss_migrate verify \
  --run-id <run-id> --regions us-west-2 \
  --verify-bucket <another-bucket-not-under-c1fss> --execute

python3 -m v1fss_migrate teardown \
  --run-id <run-id> --regions us-west-2 --execute

Each teardown asks you to type DELETE C1FSS to confirm the permanent deletion of that region's C1FSS stacks. Pass --yes to skip the prompt when running non-interactively.

Once every region is torn down, the update is complete: V1FSS is scanning your buckets and C1FSS is decommissioned.

What is not updated

The tool carries over settings that have a direct V1FSS equivalent: SSE-KMS key ARNs, scan-result tag format, scanner ephemeral storage size, VPC subnets/security groups/proxy, promote/quarantine destination buckets, and (with a warning) an IAM permissions boundary. Everything else is either dropped with an explicit onboard warning or isn't discovered at all. Review this before relying on full parity:

Account-Scanner topology: not supported. discover aborts immediately if it finds one; update that account with the manual runbook instead.
Org (CAM organizational) accounts: not supported, even if you haven't updated C1FSS on that account yet. Their CAM connector stacks are pushed by a StackSet from your org's management account, not created or updated per account.
C1 settings with no V1 equivalent (logged as "NOT carried over" during onboard): ReportObjectKey, ScanOnGetObject, ExclusiveBucketList, EnableCrossAccountScanning, AdditionalIAMPolicies, ObjectFilterPrefix, ObjectCreatedEventFilter. The object-key prefix filter is never carried over even if only one C1 bucket sets it; V1FSS's equivalent is account-wide, not per-bucket, so applying it would wrongly narrow scanning on every other bucket that never had the filter under C1.
Promote/quarantine in copy mode: V1FSS's post-scan action only moves a scanned object; there's no copy-mode equivalent. If your C1 plugin runs PromoteMode/QuarantineMode = copy (the original object stays in the source bucket), onboard logs a WARNING: after cutover the source object is deleted, not kept. Confirm this is acceptable before tearing down C1.
Plugin object ACLs: the C1 plugin re-applies a custom ACL on the object it moves; V1FSS's action does not, so a plugin ACL setting can't be carried over (onboard logs a WARNING when one is found).
Conflicting per-region values: if two or more C1 stacks in the same region report different VPC subnets/security groups/proxy, or different regions report different IAM permissions boundaries, none of the conflicting values are carried over (onboard logs a WARNING naming the affected region(s)); set them manually on the connector stack afterward.
Conflicting scan-result tag formats: the scan-result tag format (Separated tags / Merged tag / No tag) is account-wide in V1FSS, so unlike the values above it can't simply be dropped when C1 stacks disagree. If your C1 stacks use different tag formats across regions, onboard picks the majority format, applies it account-wide, and logs a WARNING listing the formats found and the one chosen. Buckets whose C1 stack used a different format will be tagged in the chosen format after cutover, a change from their C1 behavior. Set FileSecurityStorageScanResultTagFormat on the connector stack afterward if you need a different one.
IAM permissions boundary: carried over by default, but flagged as a WARNING: C1 and V1 use different CFN resources/IAM roles, so a boundary that worked for C1 may block V1's deploy. Pass --skip-permission-boundary to leave it out.

Troubleshooting & FAQ

Can I run it outside AWS CloudShell?

Yes. CloudShell is recommended only because it supplies AWS credentials ambiently. Any host with Python 3, with boto3 library, AWS credentials for the C1FSS account (env vars, a named profile, or SSO), and export V1_API_KEY=… works the same. SSO/SAML sessions can expire mid-run; refresh them and resume --run-id <run-id> --execute.

What if my account spans multiple regions?

run scans all enabled regions by default and carries every region through onboard/sync/enable together. Only verify and teardown are per region (step 4), so you prove and cut over each region independently.

How do I resume an interrupted run?

Check where it stopped, then continue; completed phases are skipped:

python3 -m v1fss_migrate status --run-id <run-id>
python3 -m v1fss_migrate resume --run-id <run-id> --execute

Is there downtime during the switch?

No. Zero-downtime is the default. Enabling V1FSS merges an EventBridge notification alongside C1FSS's existing Lambda notification on the same bucket; C1FSS keeps scanning and tagging objects until its stack is torn down in the last step.

How do I back out (rollback)?

python3 -m v1fss_migrate rollback --run-id <run-id> --execute

Rollback reverses the V1FSS onboarding: it disables the V1 scanning it turned on (removing the EventBridge notification) and either deletes the V1 connector it created or restores it to its pre-update state. It never touches C1FSS (your C1 stacks, notifications, and promote/quarantine plugin stay intact throughout), so rollback simply returns you to "C1FSS only." It's only meaningful before teardown (deleting C1 stacks is irreversible), and it deliberately won't disable V1 in a region where teardown has already started (that would leave those buckets with neither C1 nor V1).

Do I have to run verify?

No. It is optional. Teardown only deletes a region's C1FSS stacks once V1FSS has confirmed its buckets protected, so cutover is safe without it. verify is an extra end-to-end proof: it uploads a clean and an EICAR object to a bucket not under C1FSS, in the region being verified, and checks the scan tags. If you skip it, teardown still proceeds but logs that the region is being decommissioned without that proof. A verify that runs and fails, though, does block that region's teardown. If verify can't upload its test object (Object Lock, a restrictive bucket policy, or a required KMS key the caller can't use), it reports that and skips: confirm scanning manually in the V1 console, or pick a different verify bucket. (EICAR is the standard anti-malware test string, not real malware.)

What happens to my promote/quarantine rules?

onboard reads your C1FSS promote/quarantine plugin configuration and maps it onto the equivalent V1FSS action parameters, so buckets keep the same clean/quarantine behavior after cutover. (Copy mode and object ACLs are exceptions: see "What isn't updated.")

How long does teardown take, and can a slow stack fail it?

Usually a couple of minutes per stack, but if your C1FSS is deployed in a VPC, expect it to take much longer. Deleting a VPC-attached scanner (or storage) Lambda is dominated by AWS network-interface (ENI) cleanup, which routinely runs 10–40 minutes per stack. Teardown deletes stacks in parallel (storage/plugin stacks first, then scanners), so the phase is bounded by the single slowest stack rather than the sum, and each delete waits up to 1 hour by default; raise it with --teardown-timeout <seconds> for an unusually slow stack. A stack that still doesn't finish is reported and the phase stops with the others already torn down; re-run the same teardown command to retry just that one.

What happens to my Scanner stacks at teardown?

A scanner bundled inside an All-in-One stack is removed by the parent stack's cascade delete. A standalone Scanner stack (split Storage + Scanner topology) is shared infrastructure (one scanner can serve several Storage stacks), so the tool auto-deletes it only when it can prove nothing else needs it: every Storage stack that points at it (matched on ScannerSQSURL → the scanner's ScannerQueueURL) is being torn down in this run, discovery covered your whole account (no --regions), and the scanner's SQS queue policy grants no other AWS accounts. If any of that can't be confirmed (most importantly a cross-account / central scanner serving Storage stacks this run can't see), the tool leaves the Scanner stack in place and logs a NOTE explaining exactly why (naming the other account IDs for the cross-account case), for you to delete manually once you've confirmed nothing else uses it.

Can I run individual phases?

Yes. preflight, discover, onboard, sync, enable, and verify each run standalone (same flags as run) if you prefer to go through the update manually.