Cloudformation

I’m sure that there are many ways to accidentally spend more than intended using any cloud provider. Here I’ll explain how to easily do this using AWS’s Cloudformation and Cloudfront.

If you’re not familiar with it, Cloudformation is a way to describe your AWS infrastructure as code. You can use it to create stacks of resources whose deployment and removal can be reliably automated. If you’ve used Ansible, it would be like using the aws_* modules. If you haven’t used Ansible ignore that.

Cloudformation, Cloudfront, and certs

Among the many resources that can be created, creating a Cloudfront distribution via Cloudformation is powerful because Cloudfront requires a fair amount of configuration that can be automated using Cloudformation. One of the attributes that needs to be configured is the SSL certificate that will be used for users’ requests.

When a distribution is created, an SSL certificate can be used for a custom domain. Think example.com instead of sidnfhr148485.cloudfront.net. The certificate attributes are set in ViewerCertificate of the DistributionConfig object. In the ViewerCertificate object, there’s a mandatory attribute called SslSupportMethod. The ViewerCertificate API reference for CloudFront provides the values that may be used for SslSupportMethod:

• vip: The viewer displays a warning because there is a mismatch between the CloudFront domain name and the domain name in your SSL/TLS certificate.
• sni-only: CloudFront drops the connection with the browser without returning the object.

sni-only is referring to server name indication, a way of allowing a server to present multiple valid certificates on a single IP and port. You can read more about it on Wikipedia.

Choosing the proper SslSupportMethod for you

The values appear innocuous and at first glance, you might be inclined to use vip so you can provide some feedback to your users as to what went wrong. Unfortunately, there is a significant cost difference between the two that isn’t mentioned in the API reference. If you use vip and then look at your bill, you’ll see something like this:

$600.00 per month per custom SSL certificate
0.028 Mo
$16.94

Yes, a difference of a few characters can accidentally cost you $600 a month! Luckily it was caught quite early but it was still a ~$17 mistake.

All is not lost though. According to Can I use, 97.02% of global Internet users (July 2018) are using a browser that supports SNI. If you choose sni-only, you’re excluding less than 3% of potential users. At $600 a month, that doesn’t seem like an unreasonable choice for all but the largest of websites.

Billing alarms

This is probably a good time to suggest using billing alarms on AWS. If you don’t expect to be spending much per month, a low alarm (dollars or tens of dollars) can help catch errors like this very early in the development process. Even if you have a large budget, an alarm when you reach a percentage of that budget, say 25%, can be helpful for planning as well as identifying misconfigurations or unnecessary resource usage.

Summary

It’s easy to misconfigure something in the cloud and spend more than intended. Here you’ve seen how the value chosen for SslSupportMethod in the ViewerCertificate object for a Cloudfront distribution can result in a significant unintended cost. Using billing alarms can help identify this type of error early in development and help save your monthly budget.

If you have questions or comments about this post, please leave them below. If you’d like to know when other posts are available, please follow us on Twitter.