Deploy Static AWS S3 Application with CloudFront as CDN using Terraform
In this post, I will discuss how to deploy an S3 static website using Terraform.
Prerequisites
You need to have or register a personal domain, here’s the AWS official doc for registering a domain on Route53 Registrar.
In my case, I’ve created a domain called demo-apps.link
, and the following is the relative hosted zone
Then, you should create a certificate for your domain. You can create it easily using AWS ACM. In the following step, you’ll need to retrieve the certificate arn.
As usual, you can find the complete repository here, in my Github profile.
Template
The stack is composed of different files organized by resources types:
— providers.tf
— variables.tf
— s3.tf
— cloudfront.tf
— route53.tf
providers.tf
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.0"
}
}
}
provider "aws" {
region = "eu-west-1"
}
It specifies a configuration for controlling AWS resources in the eu-west-1
region using the aws
provider.
The version is set to >4.0
in the required_providers
block, which states that this Terraform configuration needs the HashiCorp AWS provider. This guarantees that the setup is compliant with the AWS provider’s version4.x
.
The area where resources will be provisioned is specified in the provider block’s configuration for the aws
provider.
These code chunks work together to create a Terraform configuration that can be used to control AWS resources in the eu-west-1
region using the provided AWS provider version.
variables.tf
variable "domain_name" {
type = string
description = "The domain name for the website."
}
variable "bucket_name" {
type = string
description = "The name of the bucket without the www. prefix. Normally domain_name."
}
variable "acm_certificate_arn" {
type = string
description = "ARN of the acm certificate."
}
variable "route53_zone_id" {
type = string
description = "ID of the route53 zone."
}
When installing a website on AWS infrastructure utilizing Amazon S3 and Amazon Route 53, these Terraform variables are probably utilized. A summary of each variable is provided below:
domain-name
: A string variable that encapsulates the website’s domain name. This variable is probably used to set up the website’s DNS records.
bucket_name
is a string variable that identifies the Amazon S3 bucket used to store website content.
ACM (AWS Certificate Manager) certificates have an ARN (Amazon Resource Name), which is represented by the string variable acm_certificate_arn
. Most likely, this option is used to set up SSL/TLS for the website.
route53_zone_id
: A string variable that holds the ID of the zone that is hosted by Amazon Route 53 and is charge of managing the website’s DNS records. The website’s DNS entries are probably created and configured using this variable.
You can use the file called terraform.tfvars
to pass values to the variables listed above.
domain_name = "YOUR DOMAIN NAME"
bucket_name = "YOUR DOMAIN NAME"
acm_certificate_arn = "YOUR ACM CERTIFICATE ARN"
route53_zone_id = "YOUR ROUTE53 HOSTED ZONE ID"
You can find the domain name and route53_zone_id in the hosted zone inside the Route53 console…
…and the certificate arn in the ACM dashboard.
s3.tf
resource "aws_s3_bucket" "bucket" {
bucket = var.bucket_name
}
resource "aws_s3_bucket_acl" "bucket-acl" {
bucket = aws_s3_bucket.bucket.bucket
acl = "public-read"
}
resource "aws_s3_bucket_versioning" "versioning_example" {
bucket = aws_s3_bucket.bucket.bucket
versioning_configuration {
status = "Enabled"
}
}
resource "aws_s3_bucket_cors_configuration" "example" {
bucket = aws_s3_bucket.bucket.bucket
cors_rule {
allowed_headers = ["Authorization", "Content-Length"]
allowed_methods = ["GET", "POST"]
allowed_origins = ["https://${var.domain_name}"]
max_age_seconds = 3000
}
}
resource "aws_s3_bucket_policy" "bucket-policy" {
bucket = aws_s3_bucket.bucket.bucket
policy = data.aws_iam_policy_document.iam-policy-1.json
}
data "aws_iam_policy_document" "iam-policy-1" {
statement {
sid = "AllowPublicRead"
effect = "Allow"
resources = [
"arn:aws:s3:::${var.domain_name}",
"arn:aws:s3:::${var.domain_name}/*",
]
actions = ["S3:GetObject"]
principals {
type = "*"
identifiers = ["*"]
}
}
}
resource "aws_s3_bucket_website_configuration" "bucket" {
bucket = aws_s3_bucket.bucket.bucket
index_document {
suffix = "index.html"
}
error_document {
key = "404.html"
}
}
Using a variable called bucket_name
to specify the bucket name, the first resource block constructs the S3 bucket itself.
The bucket’s access control list (ACL) is changed to public-read
in the second resource block, allowing anyone to view its contents.
You can maintain different versions of files in the bucket thanks to the third resource block, which enables versioning for the bucket.
The bucket’s Cross-Origin Resource Sharing (CORS) configuration, which determines which domains are permitted access to the bucket’s contents, is done in the fourth resource block.
The bucket policy is established in the fifth resource block, granting public read access to the bucket and its contents. An IAM policy document that is defined in the data
block below is used to define the policy.
An IAM policy document that grants public read access to the bucket and its contents is defined in the data
block.
The S3 bucket is set up as a website in the last resource block by supplying the index document (in this case, index.html
) and the error document (in this case, 404.htlm
). By using its endpoint URL, the bucket can now be accessed like a website.
CloudFront.tf
resource "aws_cloudfront_distribution" "s3_distribution" {
origin {
domain_name = aws_s3_bucket_website_configuration.bucket.website_endpoint
origin_id = "${var.bucket_name}"
custom_origin_config {
http_port = 80
https_port = 443
origin_protocol_policy = "http-only"
origin_ssl_protocols = ["TLSv1", "TLSv1.1", "TLSv1.2"]
}
}
enabled = true
is_ipv6_enabled = true
default_root_object = "index.html"
aliases = ["${var.domain_name}"]
custom_error_response {
error_caching_min_ttl = 0
error_code = 404
response_code = 200
response_page_path = "/404.html"
}
default_cache_behavior {
allowed_methods = ["GET", "HEAD"]
cached_methods = ["GET", "HEAD"]
target_origin_id = "${var.bucket_name}"
forwarded_values {
query_string = false
cookies {
forward = "none"
}
}
viewer_protocol_policy = "redirect-to-https"
min_ttl = 31536000
default_ttl = 31536000
max_ttl = 31536000
compress = true
}
restrictions {
geo_restriction {
restriction_type = "none"
}
}
viewer_certificate {
acm_certificate_arn = var.acm_certificate_arn
ssl_support_method = "sni-only"
minimum_protocol_version = "TLSv1.1_2016"
}
}
The goal of this distribution is to use a globally dispersed network of edge points to provide material from the S3 bucket across the internet.
The following configuration options are defined in the code for the CloudFront distribution:
origin
: This block defines the S3 bucket origin for the distribution, along with the origin ID, domain name, and any special configuration options for the origin, such as the HTTP and HTTPS ports to use, the origin protocol policy, and the supported SSL protocols.
enabled
: The CloudFront distribution is made possible by this parameter.
is_ipv6_enabled
: This configuration option makes IPv6 available for the CloudFront distribution.
default_root_object
: When the root URL is accessed, the default root object for the CloudFront distribution will be provided.
aliases
: In addition to the AWS-provided default domain name, this parameter defines any extra domain names that the CloudFront distribution should reply to.
custom_error_response
: This block defines a custom error response that will be sent in the event of a 404 error, along with the HTTP response code to use, the response page path, and the caching period.
default_cache_behavior
: This block defines the default cache behavior for the CloudFront distribution, including the HTTP methods that are permitted and cached, the target origin ID, the query string and cookies that are transmitted, the viewer protocol policy, and the duration of the content caching.
restrictions
: This block details any limitations to be applied to the CloudFront distribution, such as IP address-based boundaries.
The viewer SSL certificate to use for the CloudFront distribution is specified in the block viewer_certificate, along with the ARN of the ACM certificate, the SSL support method, and the required minimum SSL protocol version.
route53.tf
resource "aws_route53_record" "root-a" {
zone_id = var.route53_zone_id
name = var.domain_name
type = "A"
alias {
name = aws_cloudfront_distribution.s3_distribution.domain_name
zone_id = aws_cloudfront_distribution.s3_distribution.hosted_zone_id
evaluate_target_health = false
}
}
For adding a A
record to a zone hosted by Amazon Web Services (AWS) Route 53, use this Terraform resource block. To construct a record set in a Route 53 hosted zone, utilize the aws_route53_record
resource. AnA
record, which links a domain name to an IP address, is the specific record set being created here.
The following characteristics apply to the resource block:
Zone ID is used to identify the hosted zone by Route 53 where the record set will be created. The var.route53_zone_id
field provides the value.
name
: The domain name for which the record set is being made. Thevar.domain_name
variable provides the value.
type
: The kind of record set that is being made. This particular record is aA
record.
An alias block that identifies the target of the record set is known as an alias. The target for the record set is an AWS CloudFront distribution, and the name attribute is set to the distribution’s domain name. The hosted zone ID of the CloudFront distribution is the value for the zone_id
parameter. Since Route 53 won’t run a target’s health checks, the evaluate_target_health
attribute is set to false.
Time to launch terraform commands!
Let’s begin with:
$ terraform init
Terraform sets up a backend to store the state of your infrastructure when you run terraform init. It also downloads the necessary provider plugins and initializes a number of other parameters.
When you run terraform init, the following processes take place:
- Installs the required provider plugins that have been downloaded.
- the backend is set up to store the infrastructure’s current state.
- the backend is set up to use the chosen backend provider (if applicable).
- creates the necessary directories and files to configure Terraform’s working directory.
- determines whether the necessary provider versions are set up and accessible locally.
- enables any necessary parameters or variables in the Terraform environment.
One of the first tasks you execute when working with a fresh Terraform project or when setting up an old project on a new machine is normally terraform init.
$ terraform plan
$ terraform apply
The terraform apply command is used to actually apply the changes that Terraform will make to your infrastructure, as opposed to using it to preview them.
The terraform plan command can be used to generate a report on the changes that will be made to your infrastructure depending on the current state and the configuration after you have written your Terraform configuration files. This enables you to examine and confirm the alterations that will be made before putting them into effect.
Use the terraform apply command to implement the changes to your infrastructure after you are happy with them. To achieve the intended state, Terraform will add, alter, or destroy resources as necessary.
Test the application
Ok, now you should find the bucket that will host your website in the S3 dashboard:
In my case, the name of the bucket is demo-apps.link
the same name as the website (this is not mandatory).
Let’s test the website!
If you try to access your website using your browser you will receive the following error:
This is because the S3 bucket doesn’t have any objects.
In the repo on GitHub is present a simple html file that contains a hello world code. You can upload the file into the bucket in order to test the website:
After having uploaded the index.html file retry to access your website via browser:
Now you should see the content of the index.html.
If you launch terraform destroy
command, it will fail if you have objects inside the bucket. Make sure to delete all the objects inside the bucket in order to perform successfully the destroy command.
Bye 😘