Migration guide · From AWS S3
Migrate from AWS S3 to SIAX Object Storage
The S3 API has become an industry standard, and that's good news for anyone who wants to move away from it. Our object storage speaks the same protocol with signature v4, which means your SDKs, tools and libraries work unchanged — you swap endpoint and keys, not code.
The reason to move is usually the traffic. Storage is cheap everywhere; it's outbound data that costs money at AWS, and for anything that serves files to end users, the egress line quickly outgrows the storage line. Our object storage costs 25 kr per 100 GB per month, with all data in the EU.
The copying itself is a solved problem — rclone does the job and there's nothing to invent. The work lies elsewhere: IAM roles have no equivalent and must be replaced by key pairs and bucket policies, and every place in the code that generates presigned URLs has to be rewritten since the signature is tied to endpoint and region. Plan for that and the migration is undramatic. Don't, and you'll find out on cutover day.
Time required
An afternoon for a bucket of a few hundred GB with a normal object count. Copying is rarely the problem — it's the rewrite of access and presigned flows that takes time, typically one to three days of development work depending on how many places in the code talk to S3. Archived objects in Glacier add days of waiting time.
Downtime
None if you run dual writes during the overlap: write to both targets, read from S3, and switch reads once the delta sync has caught up. Without dual writes you need a write window in read-only mode during the final sync — from a few minutes to an hour depending on how much has changed since the bulk copy. The CDN switch has its own tail governed by TTL.
Lands in
How to do it
- 1
Inventory buckets by object count, not just volume
Read off size, object count, storage class and versioning per bucket with aws s3 ls --summarize or Storage Lens. Object count drives the time more than the terabytes: ten million small files takes longer than five terabytes in large blocks. Also note what writes to each bucket — that list determines what the cutover has to look like.
- 2
Create buckets and keys with us and set up rclone
Set up matching buckets and a key pair per application, not one shared key for everything. Configure an rclone remote of type s3 against our endpoint and set region and addressing style as we specify. Test with a handful of files and verify content-type and other metadata carry over before you unleash the full copy.
- 3
Run the bulk copy
rclone copy s3:bucket siax:bucket --transfers 32 --checkers 64 --fast-list is a reasonable starting point; turn up the parallelism until throughput plateaus. Run it from an instance in the same AWS region as the bucket to cut the time — you're paying the AWS egress cost either way. Objects in Glacier or Deep Archive have to be restored first, which takes hours to days.
- 4
Verify before you trust the copy
rclone check --one-way compares size and checksum per object. Also compare the total object count between source and target, and spot-check content-type, cache-control and other headers the application actually reads. A copy that looks right in bytes but has lost metadata produces errors that only show up in the browser.
- 5
Rewrite access — this is the real work
IAM doesn't exist with us: roles, instance profiles, AssumeRole and condition-based policies are replaced by key pairs and bucket policies. Go through every place that generates presigned URLs and repoint endpoint, region and signature configuration, since the signature is tied to all three. Update the CORS rules and test uploads from the browser, not just from the server.
- 6
Cut over with dual writes and keep a way back
Have the application write to both targets during the overlap and keep reading from S3 until the delta sync has caught up. Then switch reads, run a final rclone sync and repoint the CDN or CloudFront distribution. Set up an independent backup of the bucket (19 kr/100 GB) — replication between two systems isn't the same as backup — and keep the S3 bucket read-only for at least 30 days before setting a lifecycle rule that deletes.
What's actually tricky
- IAM doesn't come along, and it's more work than it sounds. Roles on EC2 and ECS instances, AssumeRole across accounts, tag-based conditions and OIDC federation from CI are replaced by static key pairs. Applications that never had to handle a secret now have to, which affects the deploy flow, not just the code.
- Presigned URLs have to be regenerated everywhere. The signature is bound to endpoint, region and key, so backend, batch jobs and any mobile clients all have to repoint and be tested. Links already sent out with long validity stop working at the cutover — plan for that if you email download links.
- Objects in Glacier and Deep Archive can't be copied directly. They have to be restored first, which costs money and takes anywhere from a few hours to several days depending on retrieval tier. For archive-heavy accounts, this step often ends up governing the whole timeline.
- Leaving AWS costs egress: roughly 0.09 USD per GB above the free tier of around 100 GB per month, so in the range of 450 USD for 5 TB as a one-off cost. Since 2024 AWS offers fee-free egress for customers leaving the platform entirely, but it requires applying through support and doesn't apply to partial moves. Check the terms before you budget.
- The standard tools copy the current version of each object — not version history, not object ACLs, not lifecycle rules, and not replication. S3 event notifications that trigger Lambda have no direct equivalent and have to be rebuilt on the application side. If you have Object Lock in compliance mode for regulatory reasons: check that with us before you plan the move, not after.
Cost example
500 GB stored and 200 GB of outbound traffic per month on S3 Standard: roughly 0.023 USD/GB for storage and roughly 0.09 USD/GB for traffic above the free tier, plus request costs — roughly 300-350 kr/mo. AWS pricing differs between regions and changes continuously, so calculate from your own bill. The same 500 GB with us costs 125 kr/mo (25 kr per 100 GB). On top of that comes the one-off cost of reading data out of S3, about 45 USD for 500 GB unless you qualify for fee-free egress. At this profile, the move pays for itself in a couple of months. If you're heavy on storage and light on traffic, it takes longer and the gain is smaller — worth calculating before you decide.
Frequently asked questions
- Do we have to switch SDKs or rewrite the code?
- No. The API is S3-compatible with signature v4, so the same SDK works — you change endpoint, region and possibly addressing style. Test multipart uploads and CORS separately, that's where differences tend to show up.
- Does version history come along?
- No. rclone and aws s3 sync copy the current version of each object. If you need the history preserved, that's a separate project: either copy every version explicitly as separate objects, or keep the S3 bucket read-only as an archive.
- What does it cost to move data out of AWS?
- Roughly 0.09 USD per GB above the free tier, so in the range of 90 USD per terabyte. Since 2024 AWS offers fee-free egress for customers leaving the platform entirely, in line with the EU Data Act, but it requires applying through support and approval. Budget for the cost and treat the fee-free path as a bonus if granted.
- Can we keep some buckets on S3?
- Yes. Many start with the traffic-heavy buckets where the egress cost makes the most difference, and leave archive data sitting in Glacier until it gets purged anyway. Hybrid is often the right answer for the first year.
- What do we do about S3 event notifications and Lambda triggers?
- They have to be rebuilt. The usual pattern is that the application writing the object also puts the job on a queue, instead of relying on storage to generate the event. It becomes more explicit and easier to debug, but it's a rewrite and needs to go in the timeline.
- Do you have ISO 27001 or SOC 2?
- No, we have neither ISO 27001, SOC 2 nor PCI-DSS. We can show GDPR compliance, data processing agreements, and that all data is stored within the EU, and we run open source all the way through so you can audit the implementation. If you have a hard certification requirement in a procurement process, AWS is a better answer than us on that specific point, and it's more honest to say so directly.
