Private S3-compatible buckets — from Amazon or CDB — can be used as a CDN resource origin. For CDB Object Storage, select a Storage and Bucket; access keys are not entered, and egress to the CDN is not billed. For Amazon and other S3-compatible storage, CDN servers authenticate with AWS Signature V4, which requires an Access Key ID, Secret Access Key, Hostname, and Region. Origin groups support multiple origins with individual authentication settings per origin, and an optional Host header override per origin.
Authentication data
The required authentication data is available in the S3 storage account.
Get the Access Key ID and Secret Access Key as described in Amazon's Managing access keys guide. Use the AWS region where the bucket is located.
On the S3 storage tab, select CDB, then choose a Storage and Bucket. Create storage and Create bucket are available in those lists. Only Standard storage is supported. Access keys are not entered.
Caution
Amazon and Other origins still require keys. CDB does not store a secret key after it is shown, so copy it when a key is created outside the CDB origin picker.
Configure a private bucket as an origin
These steps add the private origin during CDN resource creation. To create the group first, open CDN > Origin groups and click Add origin group. Fill in the same S3 form, from storage type through Host header, and click Add group. Attach the saved group on the CDN resource as described in Origin group attachment. The last two steps below apply only during CDN resource creation.
1
Add an origin
Go to the CDN resource creation page and select the Specify content origin option in the Origin section. Click Add origin.
2
Select the S3 storage type
Select the S3 storage tab. Under Choose S3 storage, select CDB, Amazon, or Other.
3
Enter authentication data
Specify the storage details for the selected type:
For CDB: Storage and Bucket
For Amazon: Access Key ID, Secret access key, and AWS region
For Other: Hostname, Access Key ID, Secret access key, and Region (optional)
Enter the Bucket name. CDN servers use this value only when calculating the AWS Signature V4 Authorization header for the private origin. The CDN does not automatically add the value from this field to the request URL sent to the origin.
If the origin requires the bucket name in the request URL, check the S3 or storage provider documentation to determine whether the bucket must be included in the origin hostname or the request path.
Origin hostname: Include the bucket in the hostname: my-bucket.s3.amazonaws.com or my-bucket.luxembourg-2.storage.gcore.dev. No rewrite rule is required.
Path: To keep the bucket name out of end-user URLs, such as https://my.domain.com/content.png, add a Rewrite rule that prepends it to requests sent to the origin. The rule /(.*) /my-bucket/$1 transforms the end-user request into an origin request for /my-bucket/content.png.
5
Configure the Host header
Optional: enter the storage hostname in the Host header override field for this origin. When left empty, the Host header configured in the resource settings applies to all origins. When set, it overrides the global value for this specific origin. A per-origin value is required when multiple origins point to different buckets that each need a unique hostname.
The Host header format depends on the storage provider:
For CDB Object Storage: my-bucket.luxembourg-2.storage.gcore.dev
For most other providers (including Amazon): my-bucket.s3.us-east-1.amazonaws.com
ℹ️
Specifying the bucket in the Host header restricts CDN access to that bucket only, preventing unintended access to other data in the storage account.
The form looks like this when S3 storage and Other are selected:
6
Add other origins
To add more origins to the group, click + Add origin again and repeat the S3 storage, authentication, bucket addressing, and Host header steps. Each origin can have different credentials and a separate Host header override.
7
Set the resource Host header
During CDN resource creation, if the per-origin Host header override is not used, open Host header in the resource HTTP headers settings and enter the storage hostname for the selected provider: my-bucket.luxembourg-2.storage.gcore.dev for CDB Object Storage, or my-bucket.s3.us-east-1.amazonaws.com for Amazon S3. Click Save changes.
Origin credentials can be rotated without recreating the origin group. Create a replacement storage key, update the origin, confirm the CDN can read a private object with the new key, and then delete the old key.
1. Go to CDN > Origin groups.
2. Click the origin group.
3. Click the pencil icon next to Access Key ID and Secret access key, because saved values are masked.
4. Enter the new values.
5. Click Save changes.
6. Request an object that exists only in the private bucket through the CDN resource. A successful response shows that the new key works.
7. Delete the old storage key. For CDB Object Storage, delete it in Key deletion. For Amazon, delete the previous key in Managing access keys.
Create an origin group with a private S3 source, then replace the access keys on that source without recreating the group.
Each S3 source uses origin_types3 and a config object. Set s3_type to other for CDB Object Storage, or amazon for AWS S3. The origin groups reference lists every field. A 201 response returns the origin group ID. Response bodies mask s3_access_key_id and s3_secret_access_key as *****.
CDN uses the bucket name only when calculating the AWS Signature V4 Authorization header. The bucket name is not added to the origin request URL. When the storage requires the bucket in the URL, include it in the hostname, or add a rewrite rule that prepends the bucket path.
Create an S3 origin
Create the origin group for CDB Object Storage or for Amazon S3. host_header_override sets the Host header for that source only.
s3_storage_hostname is required for s3_typeother.
Parameter
Required
Description
s3_type
Yes
other for CDB Object Storage
s3_storage_hostname
Yes
Storage hostname, such as luxembourg-2.storage.gcore.dev
s3_region
No
Storage region, such as s-ed1
s3_bucket_name
Yes
Bucket name used in the signature
s3_access_key_id
Yes
Access key ID for the private bucket
s3_secret_access_key
Yes
Secret access key for the private bucket
host_header_override
No
Host header for this source, such as my-bucket.luxembourg-2.storage.gcore.dev
Send sources with the new access key and secret, and include host_header_override again so the Host header set at creation stays on the source. The origin group ID comes from the create response.
A masked key in the response shows that the new values were stored. Request an object that exists only in the private bucket through the CDN resource. A successful response shows that the new key works.
Delete the old storage key after that request succeeds. For CDB Object Storage, delete it in Key deletion. For Amazon, delete the previous key in Managing access keys.
Declare a private S3 origin on an origin group with the Terraform provider v2. Access keys are write-only: Terraform sends them on apply and leaves them out of state.
Create an origin group
One S3 source creates the group. Set s3_credentials_version before the first apply so Terraform sends the access keys.
s3_type is other. s3_storage_hostname is the storage address, and host_header_override sets the Host header for this source.
Terraform sends new access keys only when s3_credentials_version changes. Update the key variables, increment the version, and run terraform apply. Keep host_header_override on the source so the Host header stays.
After apply, request an object that exists only in the private bucket through the CDN resource. A successful response shows that the new key works. Delete the old storage key after that request succeeds. For CDB Object Storage, delete it in Key deletion. For Amazon, delete the previous key in Managing access keys.
Delete the origin group
Remove the resource block. The next terraform apply deletes the origin group. Delete the group after the CDN resource no longer uses it.
Troubleshooting Amazon S3 (403 Forbidden for HEAD requests)
If an Amazon S3 origin serves GET requests successfully but returns 403 Forbidden for HEAD requests, check the permissions and request configuration. The mismatch typically has one of four causes:
Restricted object-level permissions: The bucket or IAM policy permits public read access, but the object's Access Control List (ACL) denies access to the IAM user or role — AWS S3 returns 403 for HEAD in this case.
Different policies in effect: The IAM identity making the HEAD request lacks s3:GetObjectAttributes or equivalent metadata-read permissions, causing AWS S3 to return 403 for HEAD while GET succeeds under a broader policy.
Incorrect parameters in presigned URLs: A presigned URL generated with mismatched parameters (access key, secret access key, bucket name, or object key) causes AWS to return 403. The parameters must be consistent for both HEAD and GET requests.
Different owners for bucket and object: When the bucket and object belong to different AWS accounts and the object owner hasn't granted the necessary permissions to the bucket owner, AWS returns 403 for HEAD and 200 for GET.
To resolve the issue, modify the bucket policy, IAM permissions, or the object's ACL as required.