Use your own Amazon CloudFront account as a site's CDN

What connecting it does for you

Connecting your own AWS account lets you put a site on your CDN instead of ours. The zone, the traffic and the bill are on your account, and you can still purge the cache and change the CDN's settings from inside your Zinn® dashboard — no switching between panels.

Before you start

An AWS account. Create an IAM user for this connection whose policy allows CloudFront read access and cloudfront:CreateInvalidation, which is what purging the cache needs.

To serve your own domain, CloudFront also needs a certificate for it in AWS Certificate Manager in the us-east-1 region. Certificates in any other region are invisible to CloudFront, whichever region you otherwise work in.

1. Create the key at AWS

In the AWS console open IAM → Users, choose the user this connection should act as (create a dedicated one — never use your root account), open its Security credentials tab and, under Access keys, choose Create access key. Pick Other as the use case, continue, and choose Create access key. Copy the Access key ID and the Secret access key — AWS shows the secret once. Each IAM user can hold two keys at a time.

2. Connect it here

Open Integrations in your dashboard and choose Connect an account. Pick Your own CDN as the group and Amazon CloudFront as the account, fill in Access key ID and Secret access key, and press Connect account.

We test what you paste before anything is saved. A key that does not work is never stored, and the answer says what was wrong with it. A key that works is kept encrypted in our secrets vault — never in our database — and is never shown again, not even to you.

What happens next

• Open a site's CDN tab. Under Where this site is served from, this account

appears as a destination. Choose it and confirm; we build the site's configuration on your account, check it, and only then move the site across, so the site stays up during the move.

• From the same tab you can purge the site's cache and change its CDN settings on your

account.

• When you connect, we check what the key can do: list your zones or properties, read one in

detail, purge the cache, change settings and — where the vendor has them — geographic rules. The checklist beside the connection shows which of those we could confirm, so a missing permission is visible before you move a site onto the account.

• Deploy a site to your own CDN account covers moving a site between accounts in detail.

If it does not connect

Your domain cannot be attached. There is no certificate for it in us-east-1. Request one in AWS Certificate Manager in that region, then try again.

Purging fails. The user's policy lacks cloudfront:CreateInvalidation. Add it; the key does not change.

It says the key was rejected. Almost always one of three things: a space or a line break copied with it, a key that has expired, or a key that was revoked or regenerated after you copied it. Create a fresh one and paste it again.

It connects, but something later fails. The key authenticates but lacks a permission the action needs. Create a new key with the permissions listed above, then disconnect the old connection and connect the new key.

Disconnecting

Open Integrations, find the account and press Disconnect. That deletes the stored key at once. Anything that was using it stops at its next action, and the screens that depended on it say so rather than failing quietly.

Disconnecting does not undo what was already done — records, deployments or settings we changed on your account stay as they are. If you think the key itself may have leaked, also revoke it at the vendor; disconnecting removes our copy, not theirs.