S3 Transfer Acceleration: What It Is, Speed Test, Pricing, Enabling It for CLI, sync and Python, vs CloudFront, and Why It Is Not Faster

Amazon S3 Transfer Acceleration speeds up long-distance uploads and downloads by sending your data to the nearest CloudFront edge location and carrying it to the bucket's Region over AWS's own network instead of the public internet. You turn it on per bucket (Properties, Transfer acceleration, or aws s3api put-bucket-accelerate-configuration --accelerate-configuration Status=Enabled), then send requests to BUCKET.s3-accelerate.amazonaws.com: in the CLI with aws configure set default.s3.use_accelerate_endpoint true, in boto3 with Config(s3={"use_accelerate_endpoint": True}). It costs $0.04 per GB through edges in the US, Europe and Japan and $0.08 per GB elsewhere, on top of normal S3 charges, and AWS does not charge the acceleration fee when it does not make the transfer faster. Use the official Speed Comparison tool before relying on it. When it seems not to work, the cause is usually one of: requests still going to the normal endpoint, a bucket name with a period, a bucket in a Region without acceleration (15 Regions support it), less than 20 minutes since enabling, or a network that is already fast and close. Below: setup for console, CLI, sync and Python, the speed test, pricing examples, Transfer Acceleration vs CloudFront, DataSync and Global Accelerator, and every reason it is not faster.

The shop's photographer in Sydney uploaded product shoots, 30 GB at a time, to a bucket in Europe (London). The uploads crawled and often failed overnight. Jake turned on Transfer Acceleration, ran the same upload, and saw no difference at all. The feature was working; his command was still talking to the normal S3 endpoint.

New to S3? The cards below cover S3 itself, bucket naming, large uploads and data transfer pricing.

What is S3 Transfer Acceleration?

What is S3 Transfer Acceleration in AWS, in plain terms? Normally, an upload from Sydney to a London bucket crosses the public internet the whole way, through dozens of networks, any of which can be slow or drop packets. With acceleration, your upload only travels the short hop to the nearest of AWS's edge locations (the same ones CloudFront uses), and from there it rides AWS's private backbone to London. The longer and messier the public route, the bigger the gain.

Where it helps most:

• Users uploading from around the world to one central bucket (photographers, customers, field teams).
• Regular gigabytes-to-terabytes transfers across continents.
• Fast connections that never reach their full speed to a distant S3 Region.

Where it does little: uploads to a bucket in your own country or nearby, slow last-mile connections (a weak home line stays weak), and traffic that is already inside AWS (EC2 to S3 in the same Region). Our S3 explainer covers how buckets and Regions work.

It is also a per-bucket, per-request choice. Turning it on for a bucket does not force anyone to use it: each client decides whether to send a given request to the accelerate endpoint or the normal one. That makes it low-risk to enable, since nothing changes for existing applications until you point a client at the new endpoint. You can therefore try it with one uploader for a week, compare, and only then roll it out to everyone else.

Jake: "So it doesn't make the internet faster, it makes the route shorter?"

Ethan: "Right. Only the first hop is the public internet. The rest is AWS's own network."

Why long-distance S3 uploads are slow in the first place

It helps to know what acceleration fixes and what it cannot. An upload is a conversation: your computer sends a batch of data, waits for the other side to confirm it, then sends more. Over a long distance, every confirmation takes a long round trip (Sydney to London is roughly a third of a second there and back), so a single connection spends much of its time waiting. Worse, the public internet drops packets now and then, and each loss makes the connection slow down and build up speed again. The result is a 1 Gbps office line that uploads to a distant Region at a fraction of that.

Acceleration attacks both problems: the slow, lossy part of the journey shrinks to the short hop to a nearby edge, and the long part runs over AWS's own network, which is far more consistent. What it cannot fix:

• A slow local connection: if your upload speed is 20 Mbps, no route makes it 100.
• Wi-Fi or VPN trouble: a weak Wi-Fi signal or a VPN that sends everything through a distant office adds its own delay before the internet even starts.
• The computer itself: a busy disk, antivirus scanning every file as it is read, or a laptop going to sleep halfway through.
• Thousands of tiny files: each file is a separate request with its own overhead; parallel uploads (below) help far more than acceleration here.

A quick self-check: upload one large file and time it, then upload a folder of the same total size made of small files. If the large file is fast and the folder is slow, the bottleneck is per-request overhead, and more parallel requests are the fix. If both are slow and the bucket is far away, acceleration is a good bet.

What happens to one accelerated upload, step by step

1. Your client looks up the accelerate host name, shop-photos-london.s3-accelerate.amazonaws.com. DNS answers with the address of an edge location close to you, Sydney for the photographer.
2. The client connects to that edge over the short public route and sends the request, signed with your credentials exactly as it would be for the normal endpoint.
3. The edge forwards the data to the bucket's Region over AWS's network, using connections that are already open and tuned for long distances, so there is no slow start for each part.
4. S3 in London stores the object and checks permissions as usual; policies, encryption and versioning work the same as for any upload.
5. The response travels back the same way, and for multipart uploads this repeats for every part, in parallel.

Nothing about the object itself changes: once stored, it is a normal object in a normal bucket, readable through either endpoint. That is also why you can switch acceleration on for uploads only, and keep reading through the normal endpoint or CloudFront.

The Speed Comparison tool: test before you pay

AWS publishes a free S3 Transfer Acceleration Speed Comparison page (search for it, or open it from the S3 console's Transfer acceleration settings). Open it from the computer and network that will do the real uploads; it uploads a test file with multipart upload to several Regions, with and without acceleration, and shows the percentage difference for each.

1. Run it from the real location: the photographer's studio, not your office.
2. Look at your bucket's Region in the results, not the best number on the page.
3. Run it twice, at a busy and a quiet time; internet routes vary through the day.
4. Decide: double-digit percentage gains to a distant Region usually justify it; single digits or negative results mean it will not help that route.

Read the results with a little care. The tool measures a single test file at one moment, so treat small differences as noise and look for a clear, repeatable gap. Results also vary by browser and by whatever else is using the connection; close other uploads and streaming while it runs. And if the tool shows acceleration slower than the normal route to your Region, believe it: some routes are already well connected, and the fee would buy nothing.

For Jake's Sydney-to-London route, the tool showed a large gain to eu-west-2. The feature was right for the job; the remaining problem was the endpoint.

Enable Transfer Acceleration on a bucket

In the console: open the bucket, Properties, Transfer acceleration, Edit, Enable, Save changes. The same section then shows the bucket's Accelerated endpoint. From the CLI:

aws s3api put-bucket-accelerate-configuration --bucket shop-photos-london \
  --accelerate-configuration Status=Enabled

aws s3api get-bucket-accelerate-configuration --bucket shop-photos-london
# { "Status": "Enabled" }

Requirements to know before you enable it:

• Bucket name: must be DNS-compliant with no periods. shop.photos cannot be accelerated; shop-photos can. Our bucket naming guide covers the rules. There is no rename, so a dotted bucket means a new bucket and a copy.
• Region: the bucket must be in one of the supported Regions (list below).
• Permissions: s3:PutAccelerateConfiguration to turn it on; normal object permissions to use it.
• Timing: after enabling, it can take up to 20 minutes before transfers actually speed up.

Suspending it (Status=Suspended) makes the accelerate endpoint stop working for that bucket, so anything still pointed at it will fail rather than fall back.

Use it with the AWS CLI and aws s3 sync

Enabling acceleration does nothing on its own. Your requests must go to the accelerate endpoint. The CLI can do that for every command, or per command:

# every s3 and s3api command in this profile
aws configure set default.s3.use_accelerate_endpoint true
aws s3 sync "D:\Shoots\2026-10-18" s3://shop-photos-london/shoots/2026-10-18/

# or one command only
aws s3 cp big-shoot.zip s3://shop-photos-london/shoots/ --endpoint-url https://s3-accelerate.amazonaws.com

Better still, keep a separate profile for accelerated uploads, so other commands keep using normal endpoints:

# ~/.aws/config
[profile fast-upload]
region = eu-west-2
s3 =
    use_accelerate_endpoint = true
    max_concurrent_requests = 20

aws s3 sync "D:\Shoots\2026-10-18" s3://shop-photos-london/shoots/2026-10-18/ --profile fast-upload

Bucket-level operations such as listing all buckets, creating or deleting a bucket are not available on the accelerate endpoint; the CLI sends those to the normal endpoint automatically. Combine acceleration with more parallel requests for the best result on big folders; our sync guide explains how sync decides what to send.

Jake: "That's it? One config line and the same sync command?"

Ethan: "That's it. The 30 GB shoot went up in a third of the time."

Multipart settings matter as much as acceleration

Large files are uploaded in parts, several at a time, and the part settings decide how well a fast route is used. The CLI's defaults (8 MB parts, 10 parallel requests) are tuned for a typical connection, not for a 30 GB shoot over a long distance:

aws configure set profile.fast-upload.s3.multipart_threshold 64MB
aws configure set profile.fast-upload.s3.multipart_chunksize 64MB
aws configure set profile.fast-upload.s3.max_concurrent_requests 20

• More concurrent requests keep more data in flight, which hides the long round trips. Raise it until speed stops improving; too many on a modest line just makes parts compete.
• Bigger parts cut per-request overhead for very large files. A multipart upload can have up to 10,000 parts, so for the biggest files the part size has to grow anyway.
• Retries are per part: if one part fails, only that part is sent again, which is why multipart uploads survive flaky connections far better than single-request uploads.

Combine both: acceleration shortens the bad part of the route, and parallel parts fill the good part. For the photographer, 20 concurrent requests with 64 MB parts through the accelerate endpoint was the combination that turned failures into reliable overnight uploads. Abandoned multipart uploads leave stored parts behind that you still pay for, so add a lifecycle rule to abort incomplete multipart uploads after a few days.

Use it from Python (boto3) and other SDKs

import boto3
from botocore.config import Config

s3 = boto3.client("s3", region_name="eu-west-2", config=Config(s3={"use_accelerate_endpoint": True}))
s3.upload_file("big-shoot.zip", "shop-photos-london", "shoots/big-shoot.zip")

If your app runs in the same Region as the bucket (a Lambda function or EC2 instance next to it), leave acceleration off for that client; you would pay the fee for no gain. Turn it on in the clients your distant users touch. Presigned URLs created with this client point at the accelerate endpoint too, which is how you give browser uploads from distant customers the same benefit. The Java SDK has .accelerate(true) on the client builder and .NET has UseAccelerateEndpoint = true. Our boto3 upload guide covers multipart settings, which matter just as much for large files.

In JavaScript with the AWS SDK v3, pass useAccelerateEndpoint: true when you create the S3Client; the same client then signs and sends requests to the accelerate host, including presigned URLs made with it. A practical pattern in any language is two clients side by side: an accelerated one for the long-distance transfers your users make, and a normal one for everything else (listing buckets, server-side copies, work from inside AWS). That keeps the fee on the traffic that benefits from it, and avoids sending bucket-level operations to an endpoint that does not support them.

For transfers with the boto3 transfer manager, the same TransferConfig settings as the CLI apply (multipart_chunksize, max_concurrency), so tune them together with the accelerate setting rather than one at a time.

Faster uploads from customers' browsers

If distant customers upload through your website (photos for a review, documents for an order), you can give them acceleration without them installing anything. Your server creates a presigned URL with an accelerate-enabled client, and the browser sends the file straight to S3 through the nearest edge:

import boto3
from botocore.config import Config

s3 = boto3.client("s3", region_name="eu-west-2",
                  config=Config(s3={"use_accelerate_endpoint": True}, signature_version="s3v4"))
url = s3.generate_presigned_url("put_object",
        Params={"Bucket": "shop-photos-london", "Key": "reviews/c-778/photo1.jpg", "ContentType": "image/jpeg"},
        ExpiresIn=900)

Three details make it work in the browser. The bucket needs a CORS rule that allows PUT from your site's origin, since the browser now talks to S3 directly. The browser must send the same Content-Type the URL was signed with, or the signature fails. And for large files, sign each part of a multipart upload separately so the browser can send parts in parallel and retry a failed part without starting over. The presigned URL carries the accelerate host name, so customers get the faster route automatically; your server never touches the file, which also keeps your server's bandwidth bill flat.

Uploading big folders from a Windows PC

The photographer works on Windows, like many people with big uploads, and a few Windows habits matter as much as any S3 setting:

• Quote paths with spaces in the CLI: aws s3 sync "D:\Shoots\2026-10-18" s3://.... Backslashes are fine in the local path; the S3 side always uses forward slashes.
• Stop the PC sleeping during long uploads (Settings, System, Power), or run the upload from a machine that stays on. An upload interrupted by sleep is simply resumed by running the same sync again, but it loses the night.
• Exclude the upload folder from real-time antivirus scanning during the transfer if your security policy allows it; scanning every file as the CLI reads it can halve throughput on folders of many files.
• Graphical tools: rclone supports the accelerate endpoint with its --s3-use-accelerate-endpoint option and shows progress clearly; desktop clients such as Cyberduck can also be pointed at the accelerate host name. Whatever the tool, check it is really using the accelerate endpoint, which is the most common reason "acceleration did nothing".

Jake: "The upload stopped at 3 a.m. again."

Ethan: "Windows sleep settings, not S3. Set the studio PC to stay awake on mains power, and rerun the sync; it skips what's already there."

Transfer Acceleration pricing, with examples

• Accelerated through edges in the United States, Europe and Japan: $0.04 per GB.
• Accelerated through all other edge locations: $0.08 per GB.
• Charged on top of normal S3 request and data transfer charges.
• Not charged for a transfer that acceleration did not make faster.

Worked examples for your own budget:

• The Sydney photographer: 30 GB a week through an Australian edge at $0.08 = $2.40 a week, about $10 a month, for uploads that now finish overnight instead of failing.
• A European agency uploading 500 GB a month to a US bucket through European edges: 500 × $0.04 = $20 a month.
• Downloads through the accelerate endpoint add the acceleration fee to the normal data transfer out charge; for downloads to many users, CloudFront is usually cheaper and faster (see comparison).

Our data transfer pricing map lists the base transfer charges this adds to. You can see what you paid in Cost Explorer by filtering S3 usage types for acceleration, which tells you whether a quiet bucket is still sending traffic through the edge.

Jake: "Ten dollars a month for the photographer. Is that worth it?"

Ethan: "Compared with a failed overnight upload and a reshoot schedule slipping? Easily. And if a week isn't faster, we don't pay the fee."

S3 Transfer Acceleration not working (or not faster)

Work down this list; the first item is the cause most of the time:

1. Requests still go to the normal endpoint. Check that the CLI profile has use_accelerate_endpoint, the SDK client has the setting, or URLs use s3-accelerate.amazonaws.com. Enabling the bucket alone changes nothing.
2. "Transfer Acceleration is not configured on this bucket" (an InvalidRequest error): the bucket is not enabled, or you are pointing at a different bucket than you think.
3. The bucket name contains a period: acceleration is not supported for it, and requests fail. Copy the data to a new bucket without dots.
4. The bucket's Region is not supported: see the list below; a bucket in another Region cannot be accelerated.
5. Less than 20 minutes since enabling: wait and test again.
6. Path-style requests: acceleration works only with virtual-hosted style URLs (bucket.s3-accelerate.amazonaws.com); old code or tools that use s3.amazonaws.com/bucket style bypass it.
7. The route is already short or the bottleneck is local: same-country uploads or a slow home line will not improve; the Speed Comparison tool shows this.
8. Cross-Region copies (S3 to S3) are not accelerated; acceleration is for traffic between your clients and the bucket. Our PermanentRedirect guide touches on the copy rules.

Measure the gain on your own route

The Speed Comparison tool is a good first look; your real files are the final word. A simple, fair test from the machine that will do the uploads:

1. Pick a test set that looks like real work: one large file and one folder of typical files, a few gigabytes in total.
2. Upload it to a test prefix without acceleration and note the time (the CLI prints the speed as it goes; Measure-Command in PowerShell or time on Linux gives the total).
3. Delete the test objects, then upload the same set through the accelerate endpoint with --endpoint-url https://s3-accelerate.amazonaws.com, with the same concurrency settings.
4. Repeat both at a different time of day.
5. Compare megabytes per second, not just whether it "felt faster".

If acceleration wins clearly on both runs, switch the real uploads over. If the gain is small, spend the effort on concurrency and part size instead, which are free. Afterwards, Cost Explorer filtered to S3 with usage types grouped shows the acceleration charges, so you can confirm the fee matches what you expected and that nothing else has started using the accelerate endpoint by accident.

Transfer Acceleration vs CloudFront, DataSync and Global Accelerator

"Transfer Acceleration vs CloudFront" in one line: acceleration speeds up getting your data into one bucket from far away; CloudFront speeds up giving the same data to many people. If your users mostly download, put CloudFront in front of the bucket; if they mostly upload from far away, accelerate the bucket; plenty of sites you know do both.

Jake: "Could we just use CloudFront for the photographer's uploads?"

Ethan: "You can send uploads through CloudFront, but it's built for serving. For one person pushing big files to one bucket, acceleration is the simpler fit. Our CloudFront explainer covers the second job.

Three common setups, with rough numbers

1. One remote creator, one central bucket. The shop's photographer: 30 GB a week from Sydney to London. Acceleration plus tuned multipart settings turned unreliable overnight uploads into a few hours, for about $10 a month in fees. Nothing else needed changing; this is the textbook case.

2. Customers worldwide uploading through an app. A marketplace where sellers in Asia, the Americas and Europe upload product photos to one bucket in the US. Presigned URLs from an accelerated client give every seller the short route, and the fee is only charged on uploads it actually speeds up. With 200 GB of uploads a month, half through US and European edges and half elsewhere, the cost is about 100 × $0.04 + 100 × $0.08 = $12 a month. The sellers in the US barely notice a difference; the sellers in Asia notice a lot, and those are the ones who used to abandon slow uploads.

3. A branch office backing up nightly. An office in Singapore sends 50 GB of backups each night to a bucket in Ireland. Acceleration helps, at about 50 × 30 × $0.08 = $120 a month. Here the alternatives deserve a look: a bucket in Singapore with replication to Ireland moves the long leg inside AWS without an acceleration fee (replication transfer between Regions is billed per GB instead), and DataSync adds scheduling and verification. The cheapest answer depends on the exact Regions, so price both before committing.

The pattern across all three: acceleration is cheapest and simplest when the uploaders are people or small sites far from the bucket; when one fixed site sends a lot every day, compare it with replication and DataSync.

The extra cost of each option, side by side

The last row is the one people skip: tuning concurrency and part size costs nothing and often closes much of the gap on its own. Acceleration then handles what tuning cannot, the long and unreliable public route.

Does Transfer Acceleration speed up downloads?

Yes, for downloads that go through the accelerate endpoint: a GET from Sydney for an object in London takes the same short-hop route in reverse. The fee applies per GB in that direction too, on top of normal data transfer out. It suits one person pulling large files from a distant bucket, such as an editor in Australia downloading raw footage from a London archive.

For downloads by many people, CloudFront is the better tool almost every time. It caches files at the edge, so the second and later downloads of the same file never cross the world again, and its per-GB price for delivery to users is typically lower than S3 transfer out plus acceleration. A common setup uses both on one bucket: acceleration for the few uploaders far away, CloudFront for the many viewers everywhere.

Other ways to move very large data across the world

Acceleration is ideal for regular uploads from people and small offices. For bigger or different jobs, other options fit better:

• AWS Snowball Edge devices: for tens or hundreds of terabytes, shipping a storage device is often faster than any network. You copy data onto it locally, send it back, and AWS loads it into your bucket.
• AWS DataSync: for scheduled, verified transfers from file servers or other clouds, with an agent near your data and automatic retries.
• AWS Direct Connect: a private network connection for an office or data center that moves data to AWS every day; a long-term commitment, not a quick fix.
• A nearby bucket plus replication: upload to a bucket in the Region closest to the uploader (fast, no acceleration fee), and let S3 Cross-Region Replication copy objects to the main bucket. Replication Time Control adds a time guarantee for most objects, at extra cost.

A rough guide: a few to a few hundred gigabytes a week from people far away, acceleration; a one-time move of tens of terabytes, a Snowball device; a standing pipeline from a data center, DataSync or Direct Connect; uploaders in several continents feeding one bucket, nearby buckets with replication can beat everything else.

Limits and things it does not do

• No VPC endpoint route: traffic from inside a VPC through an S3 gateway endpoint uses the normal Regional endpoint, so workloads in AWS should not use acceleration anyway.
• Bucket-level calls (create, delete, list buckets) are not served by the accelerate endpoint.
• Server-side copies between buckets are not accelerated.
• Bucket names with periods and buckets in unsupported Regions cannot be accelerated.
• Security is unchanged: the same IAM policies, bucket policies, encryption and TLS apply on the accelerate endpoint as on the normal one.

One limit catches office networks in particular: firewalls and proxies that allow only certain host names. If the normal S3 host is on the allow list but s3-accelerate.amazonaws.com (and the dual-stack variant, if you use IPv6) is not, accelerated uploads fail with connection or DNS errors while normal uploads work. Ask the network team to allow the accelerate host names before rolling acceleration out to staff.

Turning it on with CloudFormation or Terraform

If your buckets are defined in code, enable acceleration there rather than in the console, so it survives the next deployment:

# CloudFormation
PhotosBucket:
  Type: AWS::S3::Bucket
  Properties:
    BucketName: shop-photos-london
    AccelerateConfiguration:
      AccelerationStatus: Enabled

# Terraform
resource "aws_s3_bucket_accelerate_configuration" "photos" {
  bucket = aws_s3_bucket.photos.id
  status = "Enabled"
}

Remember that the setting only prepares the bucket. The clients still need the accelerate endpoint, so put the client configuration (the CLI profile, the SDK setting) in the same change, or document it next to the bucket definition, so nobody enables the bucket and wonders why nothing changed, exactly as Jake did on day one. In the AWS CDK, the bucket construct has a transfer acceleration option that does the same. Whichever tool you use, add an output or a comment with the accelerated endpoint's host name, since that is the value clients need, and add a lifecycle rule for incomplete multipart uploads in the same template, because accelerated buckets are usually the ones receiving large uploads that sometimes stop halfway.

Error messages you might see

• "S3 Transfer Acceleration is not configured on this bucket": acceleration is off for that bucket, or the request names a different bucket than you think. Check with get-bucket-accelerate-configuration.
• "S3 Transfer Acceleration is not supported for buckets with periods (.) in their names": the name rules it out; copy the data to a new bucket without dots.
• AccessDenied on enabling: your identity lacks s3:PutAccelerateConfiguration on the bucket.
• Connection or DNS errors only on the accelerate host: a firewall, proxy or private DNS setup does not allow s3-accelerate.amazonaws.com.
• Uploads succeed but are no faster: the client is still using the normal endpoint, or the route is already short; see the checklist above.
• Errors after suspending: clients still configured for the accelerate endpoint fail once acceleration is suspended; switch them back to the normal endpoint first.

A setup checklist

1. Run the Speed Comparison tool from the real upload location, for your bucket's Region.
2. Check the bucket: a supported Region and no periods in the name.
3. Enable acceleration on the bucket (console, CLI or infrastructure code) and wait 20 minutes.
4. Configure the clients: a dedicated CLI profile or SDK client with the accelerate endpoint, plus tuned part size and concurrency.
5. Allow the accelerate host in office firewalls and proxies.
6. Measure one real upload with and without it, and keep acceleration only where it wins.
7. Add the housekeeping: a lifecycle rule to abort incomplete multipart uploads, and a look at the acceleration line in Cost Explorer after the first month.

Uploads slow even close to the bucket?

If uploads are slow from somewhere near the bucket, or from inside AWS, acceleration is the wrong tool; the cause is local. The usual suspects:

• A single-threaded client: a script that uploads one file at a time with put_object leaves most of the bandwidth idle. Use the transfer manager (upload_file, aws s3 cp) or run uploads in parallel.
• The instance's own network limit: small EC2 instances have modest bandwidth; a larger or network-optimized size raises the ceiling for heavy transfers.
• A NAT gateway in the path: traffic from private subnets to S3 through a NAT gateway is slower and costs per GB; an S3 gateway endpoint sends it directly, for free.
• KMS limits: with SSE-KMS, every object needs a KMS call, and very high upload rates can hit KMS request quotas; S3 Bucket Keys cut those calls sharply.
• 503 Slow Down responses: very high request rates to one prefix are throttled; spread keys across prefixes, as our Slow Down guide explains.

Fix these first, then measure again; acceleration only belongs in the picture once the remaining delay is the distance itself.

Regions that support Transfer Acceleration

Your users can be anywhere in the world; it is your bucket's Region that has to be on this list:

If your bucket lives in a Region that is not listed, you have three choices: upload to a bucket in a supported Region and replicate to the final one, use DataSync for scheduled bulk transfers, or improve the client side (more parallel requests, a better connection). Check your bucket's Region with aws s3api get-bucket-location --bucket NAME.

Frequently asked questions

The photographer's weekly 30 GB now uploads through the Sydney edge with a dedicated "fast-upload" CLI profile, in about a third of the old time and without overnight failures. It adds roughly ten dollars a month to the bill, and the rest of the shop's S3 traffic, all within Europe, stays on the normal endpoints where acceleration would not help.

Two smaller changes came out of the same week. The studio PC now stays awake on mains power, which ended the 3 a.m. stops that had nothing to do with S3, and the bucket has a lifecycle rule that clears out incomplete multipart uploads after three days, which removed a few gigabytes of forgotten parts from the bill. When the shop later opened a seller portal for overseas suppliers, the same bucket setting and an accelerated presigned-URL client gave those suppliers fast uploads on the first day.

Revision note. Written October 20, 2026, with the 15 supported Regions of that day.