# Fastly Object Storage can now pull S3-compatible data server-side instead of routing it through your client Fastly’s new Direct Fetch path lets a client point Object Storage at a remote S3-compatible object and have Fastly fetch it directly. The migration data no longer has to flow down to the application and back up again, reducing client bandwidth and making large object moves easier to automate. The interesting change is architectural rather than another storage feature: migration becomes a server-to-server transfer initiated through an S3-compatible PutObject or UploadPart call, with range and multipart support for large objects. - Status: Active - Published: 2026-09-10T22:27:49+12:00 - Updated: 2026-09-10T22:27:49+12:00 - Categories: Cloud & Infrastructure, Edge & CDN, Databases & Storage - Tags: Amazon S3, cloud migration, Fastly, object storage, S3-compatible storage - Canonical HTML: https://beyondthe.news/dossiers/fastly-object-storage-direct-fetch-s3-migration ## What changed Fastly introduced Direct Fetch for Object Storage in September 2026. Instead of downloading a source object to the client and uploading it again, a client sends a normal `PutObject` or `UploadPart` request with an empty payload and supplies the remote object URL in the `fastly-object-storage-source-url` header. Fastly's Object Storage service then fetches the source directly and writes it to the destination. Range requests are supported, allowing multipart uploads to be assembled from sections of a remote object. Because the source can be a pre-signed S3-compatible URL, private data can be moved without giving Fastly a long-lived credential for the source account. ## Why it matters Large storage migrations are often constrained less by API syntax than by where the bytes travel. Client-mediated copies consume application bandwidth, double-hop through migration workers and create more moving parts for retry and capacity planning. Direct Fetch moves the bulk data path to Fastly's infrastructure while keeping the initiating request S3-compatible. That can simplify one-time migrations, background copy jobs and selective object movement from existing S3-compatible providers. ## The client initiates the copy but does not carry the object bytes A Direct Fetch request uses `PutObject` or `UploadPart` with the remote URL in a Fastly-specific header. Object Storage retrieves the data itself and returns the normal operation response after writing the destination. ## Multipart and range migration are supported When a request includes a Range header, Fastly asks the source for the same byte range. That lets migration tooling split large objects into parts and use multipart upload semantics without first materializing the complete object locally. ## Pre-signed URLs keep source credentials short-lived A source URL can be pre-signed by an S3-compatible provider. This allows Fastly to fetch a private object without receiving the customer's long-lived access key, although the URL itself remains a sensitive capability until it expires. ## Key details - Direct Fetch transfers a remote object directly into Fastly Object Storage without first downloading it to the client. - The API uses `PutObject` or `UploadPart` with `fastly-object-storage-source-url`. - The upload body is empty because Fastly fetches the object from the supplied source URL. - Range requests are propagated to the source and can be used with multipart uploads. - The source can be another S3-compatible storage provider. - Pre-signed URLs can provide temporary access to private source objects. - Fastly says the design reduces transfer time and client bandwidth for migrations. ## Builder takeaways - For large migrations, benchmark server-side Direct Fetch against existing client-side copy workers before provisioning more migration compute or egress bandwidth. - Use short-lived pre-signed source URLs instead of embedding long-lived source-storage credentials in migration workers. - Design retries around destination idempotency and multipart state; moving the data plane server-side does not remove the need for resumable migration bookkeeping. - Verify source-provider range-request and URL-expiry behavior before relying on multipart copies for very large objects. - Treat generated pre-signed URLs as secrets until they expire. ## What to watch - Pricing and egress economics for large cross-provider migrations. - Additional supported source-authentication mechanisms beyond pre-signed URLs. - Operational limits for object size, concurrency and source timeouts. - Whether Direct Fetch gains bulk-manifest or migration-job orchestration above the per-object API. ## Uncertainties - Actual performance and cost depend on the source provider, regions, object sizes and egress charges. - Direct Fetch simplifies the byte path but migration tooling still needs inventory, verification, retry and reconciliation logic. - A pre-signed URL grants temporary source access and must be protected appropriately. ## Sources - [Direct Fetch for Fastly Object Storage](https://www.fastly.com/documentation/guides/platform/object-storage/direct-fetch-for-object-storage/) — Fastly · primary documentation. Primary implementation documentation for server-side fetch, PutObject/UploadPart behavior and range support. - [Accelerate Migrations: Introducing Direct Fetch for Fastly Object Storage](https://www.fastly.com/blog) — Fastly · primary announcement · 2026-09-08T00:00:00+12:00. Fastly's launch material framing Direct Fetch as a migration path from S3-compatible sources.