
Moving a bucket from Amazon S3 to AIOZ Storage does not require rewriting your application code. AIOZ's own documentation covers exactly one migration path, rclone, and it works because both S3 and AIOZ Storage sit behind the same type = s3 remote in rclone's config format. This article walks through the actual config diff, the sync command, and the one gotcha AIOZ's docs call out by name.
TL;DR:
provider = AWS, one for AIOZ Storage with provider = Other.rclone sync to copy the bucket over, then rclone check to verify it landed intact.--ignore-size.Yes, and AIOZ's documentation treats it as a config change rather than a data-format change. Both remotes use rclone's s3 type, meaning rclone talks to AIOZ Storage the same way it talks to any S3-compatible target, just with different credentials and a different endpoint. There is no proprietary AIOZ migration tool involved, and no aws s3 sync path documented either; rclone is the one path AIOZ actually walks through.
Two things. First, rclone itself, installed and configured with your existing Amazon S3 credentials (rclone config file will tell you where its config lives, typically ~/.config/rclone/rclone.conf). Second, an AIOZ Storage access grant with S3 credentials: generate one from your AIOZ Storage account (choose the "S3 Credentials" type when creating it), and you get back an Access Key, Secret Key, and endpoint to use as the destination. AIOZ Storage's access grant system covers what that credential actually is under the hood, but for this migration you mainly need the three values it hands back.
Open your rclone config file and add (or confirm you already have) a source remote for S3:
[s3]
type = s3
provider = AWS
access_key_id = <your-s3-access-key-id>
secret_access_key = <your-s3-secret-access-key-id>
region = <your-s3-region>
endpoint = <your-s3-endpoint>Then add a destination remote for AIOZ Storage:
[aioz-storage]
type = s3
provider = Other
access_key_id = <your-aioz-storage-access-key-id>
secret_access_key = <your-aioz-storage-secret-access-key>
endpoint = <your-aioz-storage-endpoint>Look closely at what actually changes between the two blocks. type = s3 stays identical on both, which is the whole reason this migration doesn't need a different tool. provider flips from AWS to Other. AIOZ's remote drops the region field entirely, since it isn't a region-partitioned service the way S3 is. Everything else is just different credentials and a different endpoint value, which you fill in from the access grant you generated in the previous step. AIOZ's migration guide leaves the endpoint as a placeholder, but its own SDK documentation confirms the actual value: https://s3.aiozstorage.network.
With both remotes configured, the sync itself is one command:
rclone sync --progress s3:your-bucket aioz-storage:your-bucketThat copies everything from your S3 bucket into the matching AIOZ Storage bucket, printing progress as it goes. Once it finishes, don't just trust that it worked: run a check pass to confirm the data landed intact.
rclone check --progress s3:your-bucket aioz-storage:your-bucketOnly after that check comes back clean should you update your application's endpoint, region, and credentials to point at AIOZ Storage instead of S3, since your code is talking to an S3-compatible API either way and doesn't need any other change.
AIOZ's migration guide names exactly one error to watch for: corrupted on transfer: sizes differ. When that happens, rerun the sync with --ignore-size appended:
rclone sync --progress s3:your-bucket aioz-storage:your-bucket --ignore-sizeAIOZ's documentation doesn't explain why file sizes might be reported differently between the two sides, but rclone's own flag reference at least clarifies what the workaround actually does: --ignore-size tells rclone to skip using size as a comparison signal and fall back to modification time or checksum instead, so treat it as a real change to how rclone verifies a match, not a blind bypass. What the guide does not cover at all: object ACLs, versioning, or lifecycle rules. If your S3 bucket leans on any of those, verify separately whether AIOZ Storage has an equivalent before you cut over, since the migration guide itself is silent on all three.
Do I need to change my application code to migrate from S3 to AIOZ Storage?
No. Both are S3-compatible under rclone's s3 remote type, so the migration is a credentials and endpoint change, not a code or data-format change.
What rclone command migrates data from S3 to AIOZ Storage?rclone sync --progress s3:your-bucket aioz-storage:your-bucket, using a source remote configured with provider = AWS and a destination remote configured with provider = Other.
What does the "corrupted on transfer: sizes differ" error mean during migration?
AIOZ's documentation doesn't explain the cause, only the fix: rerun the sync with the --ignore-size flag appended.
How do I verify my S3 to AIOZ Storage migration completed correctly?
Run rclone check --progress s3:your-bucket aioz-storage:your-bucket after the sync finishes, and don't cut your application over until that check passes clean.
What credentials do I need for the AIOZ Storage side of the migration?
An access grant generated with the "S3 Credentials" type, which returns an Access Key, Secret Key, and endpoint you plug into your rclone destination remote.
Does the migration guide cover S3 features like versioning or lifecycle rules?
No. AIOZ's migration documentation covers object data transfer only; it doesn't address ACLs, versioning, or lifecycle policies, so verify those separately if your bucket depends on them.

AI agent sandboxes need external storage for files that outlive the sandbox. Real providers like Modal and E2B mount S3-compatible buckets, AIOZ Storage included.

AIOZ storage can back LangGraph's S3 checkpoint offload tier, but not the whole backend. Here is the real DynamoDB-plus-S3 setup and its credential gap.

AIOZ storage for AI datasets means S3-compatible buckets for training data and model outputs, no native versioning or lifecycle policies. Here is the honest scope.

AIOZ storage for AI workloads means S3-compatible object storage for datasets, checkpoints, and model outputs. No vector database. Here is what is real.

Add AIOZ storage team members through the dashboard's 3-step wizard: name and password, per-bucket permissions, and a one-time credential download.

No Postman collection to import. AIOZ Storage docs show building raw S3 requests by hand, authenticated with AWS Signature and your access grant keys.