AWS just released flat-rate plans for CloudFront and related services, wrapping together WAF, Route53, CloudFront Function, logging, and more. Sounds tempting, especially with a free tier. You can read more about AWS's announcement on their blog. Is it really worth it?
AWS has announced four pricing tiers: Free, Pro ($15/month), Business ($200/month), and Premium ($1,000/month). Of course, each has different capabilities and limits included.
I had thought about creating a big table to compare what's available, but it quickly got too complicated. You can check out AWS's non-marketing comparison of features by pricing tiers in their documentation. I do want to call out a few things that are included and excluded from some of the lower tiers. I'm not going to focus as much on the Business and Premium tiers because, of course, they have the best features, and at those price points, you've already shown some willingness to get them. It's the lower tiers where you miss out on some valuable features that aren't expensive, and those are the tiers where small creators and companies are going to focus.
One interesting thing included in the free tier is WAF rules. In the free tier, you get 5; in the pro tier, you get 25. Those rules usually cost $1 per month. That's already making the pro price tag appealing. Include the WordPress/PHP/SQL DB security rules in the pro and above tiers, and that looks like a good deal. But what are you giving up?
On the free and pro tier plans, you don't have access to private VPC origins. Instead, your origins, the systems CloudFront is connecting to, must be in a public VPC or generally accessible to the internet. If you want access to your site or application via the CDN, you probably don't want other public paths available to the system. You can use security groups and Origin Access Control (OAC) to limit access to only CloudFront, but not having the system publicly addressable is better. Additionally, you'll probably also have to pay for public IPv4 addresses from AWS. It's not a massive cost, but it can add up over time.
You also can't use custom origin request or response header policies in the free or pro tier plans. The default request policies are fine for most cases, but the response header policies matter for security headers such as Content Security Policy (CSP) and Cross-Origin Resource Sharing (CORS). Most modern websites and applications should have CSP and CORS headers configured.
One CloudFront feature I was surprised to see available only in the premium tier is CloudFront origin groups, which provide origin failover to enable high availability. You configure multiple origins that can return the same content into a group with primary and secondary origins. When the primary origin returns specific errors, CloudFront retrieves the content from the secondary origin. I remember the us-east-1 outage in December 2021; my client experienced a major P1 incident, with most of their applications returning errors. The issue most users encountered was that S3 couldn't return the assets needed to load the web frontends, though other issues users didn't see also existed. CloudFront origin groups can fix that. I even wrote a blog post about addressing that for my site (Building a Resilient Static Website on AWS). It's not that complicated and is within reach of smaller businesses and creators who want to ensure there is at least a friendly error message for users visiting their site during an AWS outage.
AWS Hero Yan Cui wrote a post on LinkedIn discussing this new flat-rate pricing, including highlighting concerns with it. He pointed out that the marketing material references "serverless edge compute," but that is misleading. Only CloudFront functions are included in the flat-rate pricing plans; Lambda@Edge functions are not. That's a significant difference in capabilities. If I'm reading the documentation right, you can't even use Lambda@Edge functions with these flat-rate plans. He also calls out the language around not incurring overage charges, noting that, instead, performance may be reduced, such as throttling or requiring you to change your pricing structure. Yan extrapolates on that last point, plainly calling out the trade-off: If you're below your quota, you may be wasting money, but if you're above your quota, you risk throttling and/or losing your pricing structure.
What's more important to you? Stable pricing or availability and elasticity? One of the main selling points of the major cloud providers is availability and elasticity. If price were the only concern, you could probably host your site or application elsewhere much more cheaply. Traditional hosting and data center companies still exist, and you can still host applications on a server running in your home or business. Both will have a much more consistent pricing structure, but will lack the availability and elasticity of the cloud.
I understand AWS wanting to offer consistent pricing if that's what customers are asking for, but this whole thing stinks of Azure's tendency to lock features behind tiers across its services. I hope that's not the direction AWS is heading. I appreciate the true building-block approach that AWS provides.
If these flat-rate plans provide what you and your use case need, and the consistent pricing is a big selling point for you, then by all means use them. AWS capabilities are solid regardless of how you pay for them, but if you need flexibility and availability and can handle some bill fluctuation, stick with pay-as-you-go pricing for CloudFront.
Top comments (0)