Best European Alternatives to AWS CloudFront

Why people leave AWS CloudFront

Begin with the awkward part, because most comparison pages skip it. CloudFront includes a permanent free allowance of one terabyte of data transfer out and ten million requests every month. A site that stays under that pays nothing at all, and the same terabyte on Bunny.net costs about ten dollars. Below the threshold, "a European CDN is cheaper" is simply false.

Above it the arithmetic reverses hard. The next nine terabytes cost $0.085 per gigabyte in Europe, with HTTPS requests at $0.0120 per ten thousand, and there are now flat-rate plans as well — Free, Pro at $15 a month, Business at $200 and Premium at $1,000, with no overage charges. At $0.085 you are paying roughly eight and a half times Bunny.net's published rate for the same bytes.

But the real reason to read this page is not the bill. It is that swapping CloudFront for a European CDN, on its own, changes nothing about jurisdiction. If your origin is an S3 bucket and a load balancer, then Amazon Web Services, Inc. still holds the objects, the database and the logs. You will have moved the cache and kept the company.

• The CDN is the part that is easiest to leave and matters least CloudFront is a cache in front of something. If that something stays in AWS, a European CDN adds a European hop to an American estate and answers no question a data protection assessment actually asks. This is the one move in the directory that is most often done for the wrong reason, and doing it alone is best described as decoration.
• A global service administered from Northern Virginia CloudFront is presented as region-free, and the administration is not. AWS documentation is explicit that a certificate used between viewers and CloudFront must be requested or imported in the US East (N. Virginia) Region. The control plane for the thing terminating TLS in Frankfurt lives in us-east-1, which is a useful reminder of where the product is actually operated from.
• Past the free terabyte, the rate is the expensive one At $0.085 per gigabyte in Europe for the tier above the free allowance, a site delivering ten terabytes a month pays several hundred dollars for delivery alone. The flat-rate plans cap that with no overage charges, which is a genuine improvement, and Premium at $1,000 a month is still a long way from a cent a gigabyte. CloudFront is cheap at the bottom and expensive in the middle.
• The distribution is wired into the account, not to the site Origin access controls that only permit CloudFront to read the bucket, functions running at the edge, certificates that live in ACM, firewall rules created at global scope, log delivery into S3 and metrics into CloudWatch: none of that is CDN configuration in the ordinary sense. It is AWS configuration, and it is why a CloudFront migration touches more teams than anybody estimates.

What you have to replace, not just match

Decide first whether you are replacing a CDN or beginning to leave a cloud, because the two projects have almost nothing in common.

If it is the CDN alone, the job is delivery, certificates, cache behaviours and any edge functions, and every provider here can absorb that within a week. If it is the estate, the order matters: origin storage, then compute, then the cache in front of them, because moving the cache first means running a European CDN in front of an American bucket and paying egress to Amazon for the privilege.

Two providers here can take the origin as well as the cache. Bunny.net has Edge Storage, which holds the files on the same network that serves them. Gcore has object storage, virtual machines and Kubernetes in EU regions. KeyCDN and Myra Security are delivery and protection respectively, and both assume your origin already lives somewhere you are happy with.

The alternatives compared

How each alternative compares to AWS CloudFront

What actually breaks when you switch

Bucket access is the first thing to break and the easiest to break badly. Origin access control means the bucket answers only to CloudFront, so a new provider gets 403s until you change the policy — and the careless version of that change makes the bucket world-readable. Use a signed arrangement or a dedicated credential, and check the bucket from an unauthenticated client before you move any traffic.

Signed URLs and edge functions are the second. Anything issuing CloudFront signed URLs or cookies has to be reissued in another provider's scheme, which usually means changing application code rather than configuration. CloudFront Functions and Lambda@Edge do not run anywhere else; Gcore's runtime takes the simple ones and the rest need rewriting.

And watch the egress you did not plan for. A CDN outside AWS pulls from an AWS origin over the internet, and Amazon charges standard data transfer out for every cache miss. With a high hit ratio it is negligible; with frequent purges or a long tail of rarely requested objects it can wipe out the saving entirely. Measure your hit ratio first, because that single number decides whether this move is worth making before the origin moves.

Is a European CDN actually cheaper than CloudFront?

It depends which side of one terabyte you are on, and the honest answer surprises people. CloudFront includes a terabyte of data transfer out and ten million requests every month at no charge, forever, not as a twelve-month trial. A brochure site, a documentation portal or a small application never leaves that allowance and therefore never pays anything.

Bunny.net charges a cent a gigabyte, so that same terabyte costs about ten dollars. Cheaper than free does not exist, and any page telling you otherwise has not read the pricing.

Cross the threshold and it inverts immediately. The next nine terabytes are $0.085 per gigabyte in Europe, so ten terabytes a month costs several hundred dollars where Bunny.net would charge under a hundred. The flat-rate plans change the shape of the bill rather than the rate: Business at $200 with no overage charges is a reasonable deal against a variable AWS invoice and a poor one against a European metered provider.

Does moving off CloudFront solve my GDPR problem?

Only if the origin moves with it. CloudFront caches and delivers what something else produces, and that something else is usually an S3 bucket, an Application Load Balancer or an API Gateway. Those belong to Amazon Web Services, Inc. of Seattle, and a US disclosure order reaches the company that holds them whichever network fronts them.

What a European CDN does change is who terminates TLS and who holds the request logs — which visitor loaded which page, from which address, at what time. That is a real category of personal data and moving it to a European operator is a real improvement. It is just not the same as leaving.

The version of this that works is sequenced: move the objects to European storage, move the compute, then put a European CDN in front of both. Done in that order it is a genuine migration. Done in reverse it is a European cache in front of an American origin, with cross-provider egress charges as the reward.

What is actually tying us to CloudFront?

Rarely the caching. It is the integrations either side of it. Origin access control means the S3 bucket only answers to CloudFront and has to be reopened carefully. Certificates live in ACM and must have been issued in the N. Virginia region. Firewall rules attached to the distribution are created at global scope. Logs land in S3 and metrics in CloudWatch, and somebody's alerting depends on both.

Then there is edge code. CloudFront Functions and Lambda@Edge do request rewriting, authentication and header manipulation for a lot of estates, and neither runs anywhere else. Gcore's edge runtime covers the common patterns; anything using the AWS SDK inside a Lambda@Edge function is a rewrite.

Count those five things honestly before scheduling anything. The delivery cutover is a day; the integration work is the project.

Should we leave the CDN first or the origin first?

The origin, almost always. Objects and compute are the slow, expensive, risky part, and once they have moved the CDN decision becomes trivial — you point a European provider at a European origin and the whole path is under one law.

Doing the CDN first has a specific cost beyond being ineffective: your new CDN pulls from S3 across the public internet, and AWS bills egress for every cache miss. A cold cache after a purge becomes a bill from the provider you were trying to leave.

The exception is when the CDN is the only part of the estate that handles visitor data and everything else is already European. In that case the cache is the whole problem, and moving it is the whole fix.

Which one to pick

If you are under a terabyte a month and nobody has asked a hard question about visitor logs, stay. CloudFront is free at that size, and moving to a metered European provider to make a point costs money and achieves very little.

If you are genuinely leaving AWS, do the origin first and let the CDN follow. Gcore is the only supplier here that can take compute, storage and delivery together, and Bunny.net is the cheap answer when the origin is files rather than an application.

If your site already runs in Europe and CloudFront is the last American component in the path, KeyCDN finishes the job for four cents a gigabyte and no cloud account.

And if the requirement came from a regulator rather than a finance team, Myra Security is the entry that survives the audit — but recognise that you are buying a security supplier, not a cheaper cache.