Private S3 Origins on Tencent Cloud CDN: Signed Back-to-Origin Route
The documented route for keeping your data on AWS China S3 while serving through Tencent Cloud CDN — the edge signs every origin fetch with AWS credentials, so the bucket stays private and no data migration is required.
When CloudFront leaves the AWS China partition in May 2027, every exit falls into one of two families: move the data, or keep the data and change the delivery layer. Our field-tested Alibaba Cloud exit covers the first family end to end — objects migrate from S3 to OSS, and a same-vendor private origin serves them. This piece covers the second family, and specifically its strongest documented form on Tencent Cloud CDN: a private S3 bucket, kept exactly where it is, fronted by a CDN that signs every origin fetch with AWS credentials.
No data migration. No public-read bucket. That combination is what makes the route worth writing down.
Why this route exists
For most of the China CDN market, “private origin” means private storage we also sell you. Alibaba Cloud’s private-bucket back-to-origin signs fetches only for its own OSS. That coupling is why a fully private cross-vendor setup usually forces a data migration.
Tencent Cloud CDN documents the exception: its third-party object-storage origin accepts AWS S3, and its private-storage origin authentication holds an AWS-style credential pair that the edge uses to sign origin requests. In other words, the signing happens at the CDN edge, in the AWS signature family, against a bucket you still own on AWS. The bucket can stay dark to the internet while the CDN keeps serving it.
For teams whose constraint is “the data must stay on AWS China,” this is the route that preserves both the constraint and the security posture.
The route, stage by stage
| Stage | What you do | What to watch |
|---|---|---|
| 1 — Domain onboarding | Add the accelerated domain; prove ownership with the TXT record the CDN asks for; add the CNAME it assigns | The verification record lives at the parent zone — check where your provider expects it before assuming failure |
| 2 — Origin wiring | Origin type: third-party object storage, provider AWS S3; origin address: the bucket’s regional endpoint; HTTPS back-to-origin; origin Host defaults to the bucket address | The bucket’s virtual-hosted endpoint must be what the edge sends as Host, or S3 resolves the wrong bucket |
| 3 — Credentials | Create a dedicated IAM user with exactly s3:GetObject on that bucket; enter its key pair and the bucket’s region into the private-storage origin authentication settings | Scope is your only safety property — never reuse broader keys for convenience |
| 4 — Edge HTTPS | Issue a certificate by DNS-01 validation against your zone, upload it, enable the HTTPS redirect | Routine on any vendor; budget an hour |
| 5 — Cache and refresh | Set long TTLs by file type, keep HTML short, and wire the refresh workflow into your deploy pipeline | Refresh quotas differ per vendor; check them before your first incident, not during |
Every stage is reversible on its own, and the whole route goes live or stays dark with a single DNS change — the same property that makes the migration route safe to rehearse.
The verification gate
A documented signing capability is a claim; your account is the test bench. Before any cutover, run the route through one honest gate:
- Enable authentication on a test domain pointing at your real bucket — not a sandbox replica, since endpoints and partitions behave differently.
- Force a cache revalidation so the next request is a fresh origin fetch, not an edge hit. Cached objects will happily serve while the signing path is broken; only a forced miss exercises it.
- Confirm the authorized fetch succeeds with the bucket private — the response should come from your origin, with the origin’s own headers visible.
- Confirm what happens while authentication is enabled generally — how the origin responds to the signed requests during that window is part of the route’s behavior, not an anomaly to overlook.
- Keep rollback one DNS change away until the gate has passed under your traffic shape.
If the gate passes, you have a fully private cross-vendor delivery stack with zero data movement. If it does not, you have learned it in a rehearsal instead of a production incident — and the public-read-plus-protections shape, or the migration route, remain the fallbacks.
Choosing between the two families
The decision is really one question: must the data stay on AWS China?
- If yes, this route — verified through the gate — is the strongest documented shape, because the bucket stays private and nothing moves.
- If no, the migration route gives you same-vendor private origin with a single provider accountable for storage and delivery, at traffic economics that usually favor the destination’s own storage (see the cost table in our Alibaba Cloud exit piece).
- Either way, the CDN-front stage is common to both: put the new edge in front of the untouched origin first, then decide how far along the route you need to go.
We maintain the same neutrality here as across our China cloud work: AWS’s own migration guide names its Marketplace China CDN options, Alibaba Cloud and Tencent Cloud each carry different trade-offs, and the choice belongs to your constraints — our job is to describe the routes precisely enough that you can test them.
Sources
- AWS CloudFront China discontinuation notice — https://www.amazonaws.cn/en/cloudfront/features/
- AWS CloudFront China migration guide — https://www.amazonaws.cn/en/cloudfront/migration-guide/
- Tencent Cloud CDN domain configuration (AddCdnDomain) — https://cloud.tencent.com/document/product/228/41123
- Tencent Cloud CDN data structures (Origin, private-storage origin authentication) — https://cloud.tencent.com/document/product/228/30987
- Tencent Cloud CDN origin configuration guide — https://cloud.tencent.com/document/product/228/41334
- Tencent Cloud CDN cache purge and push — https://cloud.tencent.com/document/product/228/37870
Frequently asked questions
Does this route require migrating my data out of AWS?
No. The defining property of the route is that objects stay in the S3 bucket; only the delivery layer changes. Compare with the migration route in our Alibaba Cloud exit piece, where the data itself moves to OSS.
What AWS credentials should the CDN hold?
A dedicated IAM user with a single permission — s3:GetObject scoped to that one bucket — and nothing else. Never account-level keys, and never keys that also work for other buckets or services. The credential grants read access to whatever it can read, so its scope is your security boundary.
Can the bucket stay private the whole time?
That is the documented purpose of the private-storage origin feature: the CDN edge presents AWS-signed requests on every origin fetch, so the bucket never needs public-read. The signing method follows the AWS signature family the storage accepts.
What should I verify before trusting this route in production?
Treat the documented capability as a hypothesis your own account must confirm: enable authentication on a test domain, force a cache revalidation against your real origin endpoints, and confirm an authorized fetch succeeds with the bucket private — before any DNS cutover. Also confirm what happens to requests while authentication is enabled, and keep the rollback a single DNS change away.
How does this compare with the Alibaba Cloud route?
They answer different constraints. Alibaba Cloud's private back-to-origin is same-vendor — it signs fetches for its own object storage, which is why our field-tested exit moves the data to OSS. Tencent Cloud documents signing for third-party S3 origins, which keeps data in place. Which one fits depends on whether your data must stay on AWS, and both belong in the evaluation after CloudFront China retires.
Insights
Other similar insights
Part of the China cloud cluster — every guide in the cluster, one page.
