DEV Community: Tiago Boeing

CDN de alta disponibilidade na AWS com Terraform: um guia para reduzir a latência e aumentar a performance de seu site

Tiago Boeing — Sun, 26 Mar 2023 01:35:32 +0000

Este artigo é uma continuação do primeiro sobre o mesmo assunto que foi escrito há algum tempo, mas sem abordar a utilização de Infrastructure as Code (IaC). Neste artigo, será apresentado um guia de como criar sua própria CDN de alta disponibilidade na AWS usando IaC com Terraform.

Utilize a CDN para hospedar um website estático e/ou servir arquivos estáticos com baixa latência e alta disponibilidade. Além de melhorar o desempenho do website, as CDNs garantem que o usuário sempre será servido do servidor mais próximo, o que reduz ainda mais a latência e garante uma experiência de navegação rápida e suave. Isso pode levar a um aumento de tráfego e conversões.

ℹ️ Para explicação dos serviços envolvidos, precificação e outras informações, leia o primeiro artigo sobre o mesmo assunto que demonstra a configuração via Console da AWS.

É necessário conhecimento do funcionamento do Terraform e da AWS. Não serão abordados aqui conceitos introdutórios sobre essas tecnologias.

Objetivos

Criar automaticamente toda a infraestrutura necessária dentro da AWS em poucos minutos e com alguns comandos, incluindo:

Configuração dos serviços necessários;
Criação dos registros DNS para validar o certificado e um alias para o CloudFront;
Geração do certificado SSL para servir conteúdo utilizando protocolo HTTPS;

Pré-requisitos

Conta AWS;
AWS CLI devidamente configurado;
Terraform devidamente instalado e configurado;

Composição da infraestrutura

S3 como fonte dos arquivos;
CloudFront para distribuir os arquivos;
Route53 para criar os registros DNS no domínio próprio;
Certificate Manager (ACM) para gerenciar os certificados SSL/TLS para a distribuição do CloudFront.

IaC - Infrastructure as Code

É uma prática de gerenciamento de infraestrutura de TI em que a infraestrutura é gerenciada por meio de código, em vez de configurações manuais. Com IaC, a infraestrutura é definida em arquivos de configuração que podem ser versionados, testados e implementados automaticamente, permitindo que os desenvolvedores gerenciem a infraestrutura de maneira mais eficiente e consistente. Ferramentas populares de IaC incluem o Terraform, o AWS CloudFormation e o Ansible.

Terraform

O Terraform é uma ferramenta de IaC que permite definir e provisionar infraestrutura em nuvem de forma declarativa, utilizando arquivos de configuração para descrever os recursos necessários. Com o Terraform, é possível criar, modificar e excluir recursos em diversos provedores de nuvem, como AWS, Azure e Google Cloud Platform, de forma consistente e replicável. Além disso, o Terraform possui recursos avançados, como a possibilidade de criar módulos reutilizáveis e gerenciar o estado da infraestrutura, permitindo uma gestão mais eficiente e segura da infraestrutura em nuvem.

Para mais informações, consulte a documentação oficial do Terraform.

ℹ️ Se desejar apenas o código-fonte para provisionar a infraestrutura acesse o repositório no GitHub.

Código-fonte

Link permanente com snapshot do repositório no momento que o artigo foi escrito.

O projeto Terraform será dividido em vários arquivos para facilitar compreensão:

provider.tf: Especifica com qual cloud e versões estamos trabalhando;
main.tf: Arquivo principal que centraliza configurações comuns do Terraform, data, locals, etc;
outputs.tf: Define as saídas dos recursos criados pelo Terraform;
inputs.tf: Define as variáveis de entrada para o Terraform;
s3.tf: Configurações do bucket, políticas e outros;
certificate.tf: Configurações do certificado SSL para servir conteúdo utilizando HTTPS;
cloudfront.tf: Criação e configuração do CloudFront;
test-cdn.tf: Apenas para demonstração e teste do funcionamento, este arquivo fará upload de um arquivo HTML para o bucket e invalidará o cache do CloudFront para que as alterações sejam refletidas rapidamente. Remova após validar a implementação;
terraform.tfvars: Arquivo onde o valor das variáveis pode ser especificado.

Para visualizar o conteúdo dos arquivos, confira o repositório no momento que o artigo foi escrito. As seções abaixo abordarão apenas arquivos chave para facilitar a compreensão.

Definição do provedor (`provider.tf`)

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "4.59.0"
    }
  }
}

provider "aws" {
  skip_credentials_validation = true
}

Variáveis locais e queries (`main.tf`)

locals {
  service              = var.service
  stage                = var.stage
  resource_prefix_name = "${var.service}-${var.stage}"
  route53_private_zone = var.route53_private_zone
  route53_base_domain  = var.route53_zone_domain
  cdn_domain           = var.cdn_domain
}

# Get AWS Account ID
data "aws_caller_identity" "current" {}

# Get Route53 Zone
data "aws_route53_zone" "domain_zone" {
  name         = "${local.route53_base_domain}."
  private_zone = local.route53_private_zone
}

São definidas algumas variáveis locais para utilizar nos demais arquivos;
aws_caller_identity: consulta usada para obter o ID da conta e concatená-lo com o nome do bucket do S3 para garantir que o nome seja único na AWS e tentar evitar falhas na criação do bucket.
aws_route53_zone: consulta uma Hosted Zone no Route53 que possua o domínio informado.

Definição das `inputs` (`inputs.tf`)

Na infraestrutura teremos as seguintes inputs:

service: nome com que os recursos serão criados dentro da AWS;
stage: estágio da aplicação caso desejar criar mais de uma CDN para o mesmo serviço (dev, test, prod). Nota: é possível utilizar a implantação contínua do próprio CloudFront;
route53_private_zone: define se a zona DNS é privada ou não;
route53_zone_domain: domínio da zona DNS
cdn_domain: nome do domínio para a CDN, pode ser deixado em branco para utilizar o domínio base (Hosted Zone do Route53);
cloudfront_allowed_methods: métodos HTTP permitidos no CloudFront;
cloudfront_cached_methods: métodos HTTP que serão mantidos em cache no CloudFront;
cloudfront_default_root_object: arquivo raiz padrão no CloudFront;
cloudfront_http_version: versão do protocolo HTTP no CloudFront.

variable "service" {
  default     = "terraform-cdn"
  type        = string
  description = "Service name"
}

variable "stage" {
  default     = "dev"
  type        = string
  description = "Stage (dev, test, prod)"
}

variable "route53_private_zone" {
  default = false
  type    = bool
}

variable "route53_zone_domain" {
  default     = ""
  type        = string
  description = "Route53 zone domain (base domain)"
}

variable "cdn_domain" {
  default     = ""
  type        = string
  description = "Domain name (Where you want to deploy the CloudFront distribution. Leave empty to deploy inside base domain)"
}

variable "cloudfront_allowed_methods" {
  default = ["GET", "HEAD", "OPTIONS"]
  type    = list(string)
}

variable "cloudfront_cached_methods" {
  default = ["GET", "HEAD", "OPTIONS"]
  type    = list(string)
}

variable "cloudfront_default_root_object" {
  default = "index.html"
  type    = string
}

variable "cloudfront_http_version" {
  default = "http2"
  type    = string
}

Passando valores para as variáveis criadas (`terraform.tfvars`)

Existem várias formas de passar valores para as variáveis do Terraform, incluindo a utilização de arquivos JSON, variáveis de ambiente ou a passagem de valores diretamente pela linha de comando no momento da execução do Terraform. Consulte a documentação oficial do Terraform para mais informações.

Neste exemplo será utilizado um arquivo com a extensão .tfvars, então basta criar um arquivo terraform.tfvars e definir o seguinte conteúdo:

route53_zone_domain = "tiagoboeing.com"
cdn_domain          = "terraform-cdn.tiagoboeing.com"

Neste caso o domínio (Hosted Zone no Route53) é tiagoboeing.com e a CDN será implantada em um subdomínio.

A propriedade route53_zone_domain serve como base para o Terraform obter a Hosted Zone no Route53.

Criação do bucket no S3 (`s3.tf`)

O primeiro passo é criar um bucket no S3 e definir uma política de segurança que restrinja o acesso público direto a qualquer conteúdo. Isso impedirá que um objeto seja tornado público diretamente via S3. O CloudFront será a única maneira de acessar os arquivos.

Crie um arquivo chamado s3.tf e adicione o seguinte conteúdo:

resource "aws_s3_bucket" "bucket" {
  bucket = "${local.resource_prefix_name}-bucket-${data.aws_caller_identity.current.account_id}"

  tags = {
    Stage   = local.stage,
    Service = local.service
  }
}

resource "aws_s3_bucket_acl" "bucket_acl" {
  bucket = aws_s3_bucket.bucket.id
  acl    = "private"
}

resource "aws_s3_bucket_public_access_block" "bucket_public_access" {
  bucket = aws_s3_bucket.bucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_policy" "bucket_policy" {
  bucket = aws_s3_bucket.bucket.id

  policy = jsonencode({
    "Version" : "2008-10-17",
    "Statement" : [
      {
        "Sid" : "AllowCloudFrontServicePrincipalReadOnly",
        "Effect" : "Allow",
        "Principal" : {
          "Service" : "cloudfront.amazonaws.com",
        },
        "Action" : "s3:GetObject",
        "Resource" : "arn:aws:s3:::${aws_s3_bucket.bucket.bucket}/*",
        "Condition" : {
          "StringEquals" : {
            "aws:SourceArn" : aws_cloudfront_distribution.cloudfront.arn
          }
        }
      }
    ]
  })

  depends_on = [
    aws_s3_bucket.bucket
  ]
}

Estamos definindo os seguintes recursos:

aws_s3_bucket: Cria o bucket que o CloudFront utilizará como origin.
aws_s3_bucket_policy: Define uma política de acesso para que o CloudFront seja capaz de obter os objetos do bucket no S3 (necessário quando trabalhamos com buckets privados)
aws_s3_bucket_acl: Define o controle de acesso ao bucket no S3 como privado.
aws_s3_bucket_public_access_block: Define os parâmetros de acesso público para o bucket no S3 da AWS, bloqueando a criação de buckets públicos, políticas públicas, listagens públicas e controle de acesso público.

Criação e validação do certificado SSL (`certificate.tf`)

resource "aws_acm_certificate" "certificate" {
  domain_name       = local.cdn_domain != "" ? local.cdn_domain : data.aws_route53_zone.domain_zone.name
  validation_method = "DNS"

  tags = {
    Stage   = local.stage,
    Service = local.service
  }
}

resource "aws_acm_certificate_validation" "certificate_validation" {
  certificate_arn         = aws_acm_certificate.certificate.arn
  validation_record_fqdns = [for record in aws_route53_record.certificate_records : record.fqdn]

  depends_on = [
    aws_acm_certificate.certificate
  ]

  timeouts {
    create = "10m"
  }
}

# Add Certificate Validation Records on Route53
resource "aws_route53_record" "certificate_records" {
  for_each = {
    for dvo in aws_acm_certificate.certificate.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }

  allow_overwrite = true
  name            = each.value.name
  records         = [each.value.record]
  ttl             = 60
  type            = each.value.type
  zone_id         = data.aws_route53_zone.domain_zone.zone_id
}

Estamos definindo os seguintes recursos:

aws_acm_certificate: criação do certificado SSL para a CDN utilizando o AWS Certificate Manager (ACM);
aws_acm_certificate_validation: Define que a validação do certificado será realizada via DNS;
aws_route53_record: adiciona registros no Route53 para validar o certificado SSL.

Criação do CloudFront (`cloudfront.tf`)

resource "aws_cloudfront_origin_access_control" "cloudfront_acl" {
  name = "ACL - ${local.resource_prefix_name}"

  origin_access_control_origin_type = "s3"
  signing_behavior                  = "always"
  signing_protocol                  = "sigv4"
}

resource "aws_cloudfront_distribution" "cloudfront" {
  enabled             = true
  is_ipv6_enabled     = true
  comment             = "CDN for ${local.resource_prefix_name}"
  default_root_object = var.cloudfront_default_root_object
  http_version        = var.cloudfront_http_version

  aliases = local.cdn_domain != "" ? [local.cdn_domain] : local.route53_base_domain != "" ? [local.route53_base_domain] : []

  origin {
    origin_id                = aws_s3_bucket.bucket.id
    origin_access_control_id = aws_cloudfront_origin_access_control.cloudfront_acl.id
    domain_name              = aws_s3_bucket.bucket.bucket_regional_domain_name
  }

  default_cache_behavior {
    target_origin_id = aws_s3_bucket.bucket.id

    compress        = true
    allowed_methods = var.cloudfront_allowed_methods
    cached_methods  = var.cloudfront_cached_methods

    forwarded_values {
      query_string = false

      cookies {
        forward = "none"
      }
    }

    viewer_protocol_policy = "redirect-to-https"
    min_ttl                = 0
    default_ttl            = 3600
    max_ttl                = 86400
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = false

    minimum_protocol_version = "TLSv1.2_2021"
    ssl_support_method       = "sni-only"

    acm_certificate_arn = aws_acm_certificate_validation.certificate_validation.certificate_arn
  }

  tags = {
    Stage   = local.stage,
    Service = local.service
  }

  depends_on = [
    aws_s3_bucket.bucket
  ]
}

# Create Route53 Record to CloudFront
resource "aws_route53_record" "domain_record" {
  name    = local.cdn_domain != "" ? local.cdn_domain : data.aws_route53_zone.domain_zone.name
  type    = "A"
  zone_id = data.aws_route53_zone.domain_zone.zone_id

  alias {
    name                   = aws_cloudfront_distribution.cloudfront.domain_name
    zone_id                = aws_cloudfront_distribution.cloudfront.hosted_zone_id
    evaluate_target_health = false
  }

  depends_on = [
    aws_cloudfront_distribution.cloudfront
  ]
}

Estamos definindo os seguintes recursos:

aws_cloudfront_origin_access_control: Cria uma política de acesso para o S3;
aws_cloudfront_distribution: Cria e configura a distribuição do CloudFront;
aws_route53_record: Adiciona um registro DNS no Route53 como alias para o CloudFront.

Teste da infraestrutura (`test-cdn.tf`)

Aqui será a etapa onde um arquivo HTML será enviado para o bucket S3 e então o cache do CloudFront invalidado para garantir que as alterações reflitam imediatamente.

#############################
# Only for tests purposes
# Upload one HTML file to S3
#############################
resource "aws_s3_object" "public_folder" {
  for_each     = fileset("public/", "*")
  bucket       = aws_s3_bucket.bucket.id
  key          = each.value
  source       = "public/${each.value}"
  etag         = filemd5("public/${each.value}")
  content_type = "text/html"
}

#############################
# Only for tests purposes
# Invalidate index.html from CloudFront cache
#############################
resource "null_resource" "cache_invalidation" {

  # prevent invalidating cache before new s3 file is uploaded
  depends_on = [
    aws_s3_object.public_folder
  ]

  for_each = fileset("${path.module}/public/", "**")

  triggers = {
    hash = filemd5("public/${each.value}")
  }

  provisioner "local-exec" {
    # sleep is necessary to prevent throttling when invalidating many files; a dynamic sleep time would be more reliable
    # possible way of dealing with parallelism (though would lose the indiviual triggers): https://discuss.hashicorp.com/t/specify-parallelism-for-null-resource/20884/2
    command = "sleep 1; aws cloudfront create-invalidation --distribution-id ${aws_cloudfront_distribution.cloudfront.id} --paths '/${each.value}'"
  }
}

Crie uma pasta chamada public e adicione um arquivo index.html com qualquer conteúdo apenas para teste.

Provisionar infraestrutura

Com os recursos configurados, é hora de provisionar a infraestrutura.

# Valide o plano de criação
terraform plan

# Se tudo estiver correto, aplique o plano para iniciar a criação
terraform apply

O provisionamento inicial normalmente leva alguns minutos e a distribuição do CloudFront pode demorar mais alguns minutos para ficar disponível.

Aguarde o tempo necessário. Ao finalizar, acesse o domínio configurado e valide se o arquivo HTML foi apresentado corretamente.

No exemplo do artigo o subdomínio onde a CDN foi provisionada é terraform-cdn.tiagoboeing.com

Parabéns! Você agora possui uma CDN de alta disponibilidade na AWS utilizando IaC. Não hesite em explorar outras soluções e recursos da AWS e continue aprendendo!

Links do artigo

English

Serverless Framework + AWS: automatically creating certificate and domain for your app

Redes sociais

Quer saber mais sobre mim, o autor deste artigo? Então dê uma olhada nas minhas redes sociais:

Espero que tenha gostado do artigo e encontrado informações úteis. Se tiver alguma dúvida ou sugestão, deixe nos comentários.

Você sabia que pode se tornar um Community Builder da AWS? Como Community Builder, você terá a oportunidade de se conectar com outros profissionais da área de tecnologia e aprender com especialistas da AWS. Além disso, você poderá compartilhar seus conhecimentos e experiências com outros membros da comunidade. Não perca a chance de se tornar um líder na sua área e se juntar a uma comunidade global de entusiastas da AWS! Saiba mais em aws.amazon.com/developer/community/community-builders.

Serverless Framework + AWS: automatically creating certificate and domain for your app

Tiago Boeing — Fri, 04 Mar 2022 10:16:30 +0000

This is a guide showing how you can automatically create an SSL certificate on Amazon Certificate Manager (ACM) and configure a subdomain on Route 53 Hosted Zone using Serverless Framework with some wonderful plugins.

Before start:

You need an AWS account;
Have a Hosted Zone configured on Route53 with some domain name;
Have a little bit of knowledge of using Serverless Framework.

Firstly, you need to know that we'll use some Serverless Framework plugins to turn our life easier:

Serverless Domain Manager to control Route53 rules and API Gateway custom domain configs.
Serverless Certificate Creator to create certificates on Amazon Certificate Manager and confirm by DNS method.

Note: I’ll show some scripts using NodeJS, but Serverless Framework can be used on almost any language (to not say literally anywhere).

With this in mind, let's go ahead! Start installing dependencies:

npm install serverless-domain-manager serverless-certificate-creator —-save-dev

Create a custom domain section

I usually separate domains to allow customization for each one, it would be like this in my stack:

# serverless.yml
...

custom:
  domains:
    # References to 'prod' stage
    prod:
      domainName: api.tiagoboeing.com
      certificateName: api.tiagoboeing.com

    # References to 'dev' stage  
    dev:
      domainName: api-dev.tiagoboeing.com
      certificateName: api-dev.tiagoboeing.com

    ...

Of course, the certificate name is chosen by you. I only like to use the same name of the domain to keep easier to locate on ACM.

This is the way how I organize my apps, take this as an example to customize/start.

See our custom section:

custom:
  # Amazon Certificate Manager
  customCertificate:
    # Route 53 Hosted Zone name
    # don't forget the dot on the end!
    hostedZoneNames: "tiagoboeing.com."

    # Here we get our certificate name inside custom.domain.STAGE.certificateName
    # STAGE will be automatically filled with the value from "provider > stage"
    certificateName: ${self:custom.domains.${self:provider.stage}.certificateName}

    region: ${self:provider.region}

  # Route53
  customDomain:
    # Get value from "domains" section using stage that is being deployed
    domainName: ${self:custom.domains.${self:provider.stage}.domainName}

    # Same case of certificaName inside customCertificate
    certificateName: ${self:custom.domains.${self:provider.stage}.certificateName}

    # Enable plugin to create an A Alias and AAAA Alias records in Route53
    # mapping the domainName to the generated distribution domain name.
    createRoute53Record: true

    # Enable plugin to autorun create_domain/delete_domain as part of sls deploy/remove
    autoDomain: true

Deploy

Take the following tips and tricks:

To create the certificate on ACM run:

serverless create-cert

# or

npx serverless create-cert

Create the certificate on the deploying stage, you can change the stage using --stage prod flag or STAGE=prod env.

Create domain - simply run

To create domain on Route 53, use:

serverless create_domain

# or

npx serverless create_domain

Keep in mind that createRoute53Record and autoDomain were enabled on serverless.yml, a simple serverless deploy will start automatically this step.

Deploying to another stage (not on the default: dev) you need to use the option --stage (read more here). As an example for the first time you can use:

# First deploy PROD stage

serverless create-cert --stage=prod

serverless deploy --stage=prod

It’s possible to manually generate a domain using serverless-domain-manager, you can do it using the command serverless create_domain, this isn’t needed if you have the autoDomain flag enabled (as mentioned earlier).

Complete stack

See the complete Serverless stack below.

service: sls-my-app

plugins:
  - serverless-domain-manager
  - serverless-certificate-creator

provider:
  name: aws
  runtime: nodejs14.x
  stage: ${opt:stage, 'dev'}
  region: ${opt:region, 'us-east-1'}
  apiGateway:
    shouldStartNameWithService: true
  timeout: 5

  # passing base domain name and stage to our functions
  environment:
    DOMAIN: ${self:custom.customDomain.domainName}
    STAGE: ${self:provider.stage}

functions:
  authenticate:
    handler: src/functions/hello.handler
    description: "Return a hello world"
    timeout: 3
    events:
      - http:
          method: GET
          path: /
          cors: true

custom:
  domains:
    prod:
      domainName: api.tiagoboeing.com
      certificateName: api.tiagoboeing.com
    dev:
      domainName: api-dev.tiagoboeing.com
      certificateName: api-dev.tiagoboeing.com

  # Amazon Certificate Manager
  customCertificate:
    hostedZoneNames: "tiagoboeing.com." # don't forget the dot on the end - is required by Route53
    certificateName: ${self:custom.domains.dev.certificateName}
    region: ${self:provider.region}

  # Route53
  customDomain:
    domainName: ${self:custom.domains.${self:provider.stage}.domainName}
    certificateName: ${self:custom.domains.dev.certificateName}
    createRoute53Record: true
    autoDomain: true

📝 Thanks, Paulo Weber by the review this text.

Automating changelogs in your NodeJS project

PT-BR:

CDN de alta disponibilidade na AWS com S3, CloudFront e Route53

Tiago Boeing — Tue, 30 Nov 2021 03:06:08 +0000

Este é um guia sem enrolações (prometo entrar no detalhe apenas do que for essencial) sobre como provisionar uma rede de distribuição de conteúdo (CDN) na AWS. Os passos são executados via console (GUI/interface) e as capturas de tela tendem a ficar obsoletas com o passar do tempo, podendo não representar o estado atual da interface à medida que as soluções evoluem.

Em outra ocasião abordarei a criação utilizando IaC (Infrastructure as Code)

Pressuponho que:

já possua uma conta na AWS, se não tiver crie e logo de início ganhe 12 meses de nível gratuito (as ferramentas envolvidas no artigo são privilegiadas);
tem um domínio (hosted zone) cadastrado no Route53 (caso preferir utilizar o seu).
está buscando distribuir conteúdo de maneira replicada pelo mundo e com baixa latência. Caso os usuários forem de uma única região e não existir preocupação com futuras expansões, é possível utilizar apenas o S3 com a opção static website.

O que são conteúdos estáticos?

São arquivos em que o conteúdo não é criado dinamicamente, embora possa mudar com determinada frequência, em sua essência ele permanecerá o mesmo até a próxima alteração e, no momento que ela (alteração) ocorrer podemos realizar diversas operações para garantir que o novo conteúdo seja distribuído para os clientes através de práticas como a invalidação de cache.

Exemplos de arquivos estáticos: Imagens, aplicações SPAs (já que são compostas de arquivos de texto/scripts), tipografias, vídeos (você até pode, mas o tipo da distribuição do CloudFront deste artigo não tem este propósito — assunto para outra ocasião) e outros.

CDN

Content Delivery Network (Rede de distribuição de conteúdo) — tem como principal motivo contribuir para a melhora do tempo de carregamento de páginas e aumentar a disponibilidade do conteúdo ao redor do mundo, normalmente esta inclui diversos servidores de borda (edge) que são próximos do usuário (e isto é o que garante a baixa latência).

S3

O S3 é o serviço da AWS voltado ao armazenamento de arquivos, nele criamos diversos buckets (baldes) que são os espaços onde iremos realizar o upload. Um bucket pode ser organizado por pastas e conter configurações de vida útil de um objeto/arquivo (tais como expiração), permissões, CORS e uma infinidade de outros.

CloudFront

O CloudFront é um serviço vital para inúmeros outros dentro da nuvem da AWS, muitas das vezes você o utiliza sem perceber. É ele quem garante a disponibilidade ao redor do mundo e melhores taxas de latência com base na localização do cliente. Embora este artigo trate de arquivos estáticos, não é só para isto que o CloudFront serve, podendo distribuir APIs através de Lambda@Edge, transmissão ao vivo e sob demanda de vídeo, distribuição de atualizações para dispositivos IoT e outros.

Podemos adicionar um nome de domínio para uma distribuição (nome dado a instância do CloudFront) utilizando o Route53 (serviço para gerenciamento de DNS da AWS), configurar regras de proxy adicionando uma Lambda à frente para controlar CSP — Content Security Policies [assunto para próximos artigos, mas se tiver pressa, veja esse artigo do Jake Wells], revalidação de cache, monitorar tráfego e uma infinidade de cenários.

Antes de provisionar qualquer recurso cloud é importante analisar os custos envolvidos para evitar surpresas, se estiver em uma conta de nível gratuito trate de certificar quais os limites.

Definição de preço

A AWS oferece no nível gratuito (de 12 meses), a cada mês: 50 GB de transferência de dados para fora, 2 milhões de solicitações HTTP ou HTTPS e 2 milhões de invocações do CloudFront Functions. Para mais detalhes, consulte a definição de preço.

Se não estiver no nível gratuito, faça uma simulação utilizando a calculadora de preços.

Cenário hipotético de um CloudFront com as seguintes características e seus respectivos custos:

Região us-east-1 (N. Virginia)
10 GB por mês de tráfego de saída para a internet = 0.85 USD
10 GB por mês de transferência para o servidor de origem (solicitações POST e PUT) = 0.20 USD
100.000 requisições HTTPS por mês = 0.10 USD

0.85 USD + 0.20 USD + 0.10 USD = 1.15 USD (Custo total por mês)

Vamos lá…

Meu console se encontra em inglês para facilitar o entendimento e evitar traduzir alguns termos técnicos (mesmo que sua conta estiver em português é comum o console não ser 100% traduzido e ainda aparecer termos em inglês).

S3 Bucket

O S3 é o local onde vamos armazenar os conteúdos da CDN, para isto precisamos criar um bucket (balde). Localize o S3 na busca de serviços:

Clique em Create Bucket:

Com base em minha experiência em determinado momento você pode desejar ativar alguns recursos no bucket que dependem de requisitos que sigam boas práticas de nomenclatura, como o Transfer acceleration e para isto obrigatoriamente o nome não pode conter .

Mais sobre convenção de nomes:

Seguindo as boas práticas, vamos utilizar hífen — para separar as palavras, preencha os dados para a criação do bucket:

Bucket name: deve ser um nome único em toda a AWS;
AWS Region: como o CloudFront ficará à frente do nosso bucket e esta será a única maneira de acessar os conteúdos, preferi utilizar us-east-1 porque os custos são inferiores à São Paulo sa-east-1 — Mais sobre custos do S3. (dependendo de seus planos, verifique a legislação quanto ao local de armazenamento dos dados);
Block Public Access settings for this bucket: mantenha o padrão;
Bucket Versioning: fica a critério, isto criará novas versões caso o documento enviado tenha o mesmo nome e facilitará rollback em caso de sobrescritas acidentais, em contrapartida tende a aumentar o consumo de armazenamento do bucket ao longo do tempo se não for configurada uma rotina automática de limpeza;
Mantenha as demais opções sem alterar e crie o bucket clicando em Create bucket.

Após isto seu bucket estará criado:

No S3 por enquanto não há mais o que fazer, já existe um local para armazenar os arquivos. O próximo passo é criar a distribuição do CloudFront.

Distribuição do CloudFront

Localize o CloudFront na busca de serviços:

Clique em Create Distribution:

Agora a lista de configurações começa a ficar um pouco extensa, esta etapa é de extrema importância, resolvi numerar os passos iniciais para facilitar o entendimento:

Origin domain (1): é o bucket do S3 a ser utilizado pelo CloudFront, pesquise pelo nome criado na seção anterior, no meu caso é tiagoboeing-cdn-article.s3.us-east-1.amazonaws.com ;
Origin path: é opcional, ao deixar em branco o CloudFront estará utilizando a raiz do bucket como caminho relativo, mas se preferir é possível especificar uma determinada subpasta como raiz;
Name (2): por padrão este campo será preenchido com o nome do bucket, defina o valor que preferir para facilitar a identificação da distribuição, costumo utilizar o domínio associado à mesma;

S3 bucket access: como deixamos nosso bucket privado (de maneira proposital para evitar acesso direto à ele), vamos configurar uma política que permita ao CloudFront ler os arquivos que lá estão;

(3) — Marque Yes use OAI (bucket can restrict access to only CloudFront);
(4) — Vamos criar a access identity, clique em Create new OAI, preencha com o nome desejado conforme o padrão que preferir, costumo utilizar o prefixo sugerido (access-identity-) + domínio da CDN, clique em criar e a Origin access identity será preenchida automaticamente.

(5) — Marque a caixa Bucket policy → Yes, update the bucket policy.

Para facilitar, um resumo apenas do que alterei mais abaixo:

Em Default cache behavior — Viewer → Viewer protocol policy: Redirect HTTP to HTTPS;
Em Settings — Alternate domain name (CNAME): adicionei o domínio que pretendo usar e vou configurar no Route53 posteriormente;
Em Settings — Custom SSL certificate: clique em Request certificate e na nova aba será aberto o AWS Certificate Manager (o certificado SSL é gratuito), os passos são auto-guiados:
Request a public certificate → em Fully qualified domain name coloque o domínio que irá utilizar na CDN → escolha como pretende verificar o domínio (se estiver configurado no Route53 use DNS validation pois a validação é automática) → Clique em Request;
Via DNS: Após solicitar, acesse o certificado e em Domains clique em Create records in Route 53 → Create records.
Em Settings — Default root object: se for utilizar a CDN para hospedar páginas estáticas (SPAs) defina index.html
Em Settings — Description: opcionalmente preencha com a observação que preferir.

Crie a distribuição e aguarde, o status ficará como Deploying e isto pode levar alguns minutos.

Abaixo o resultado de todas as alterações realizadas para não restar dúvidas, em vermelho os locais modificados:

Após alguns minutos… Pronto! Temos a distribuição criada! 🚀

Clicando no título é possível verificar as configurações:

Criar registro no Route53 para o CloudFront

Como ao longo do artigo optei por utilizar o subdomínio cdn-article.tiagoboeing.com para exemplo, resta apenas criar este registro no Route53. Copie o domínio de Distribution domain name (inclusive se ignorar esta etapa, este será o endereço de acesso da CDN).

O passo é opcional, mas leve em conta que ao utilizar o domínio padrão do CloudFront as alterações nas propriedades do domínio durante a criação da distribuição e o certificado não devem ser realizadas.

Vou ser breve nesta etapa.

Estou presumindo que já existe uma hosted zone configurada. Acesse o Route53 buscando na lista de serviços; Clique na Hosted zone do seu domínio e vá para Create record.

Record name: coloque o subdomínio utilizado durante a criação do CloudFront, no meu caso cdn-article ;
Record type: A — Routes traffic to an IPv4 address and some AWS resources;
Marque a caixa de seleção Alias e escolha Route traffic to → Alias to CloudFront distribution
E na caixa Choose distribution se tiver sorte tente localizar sua distribuição. (Aqui há uma incógnita, às vezes a AWS simplesmente não encontra a distribuição, por isso a dica de copiar a Distribution domain name anteriormente) — se não conseguir localizar pela caixa basta colar o valor.
Mantenha as demais opções com os valores padrões.

Hora da diversão, vamos aos testes

Recapitulando…

Criamos o bucket no S3 para armazenar os arquivos da CDN;
Criamos a distribuição do CloudFront, definimos um nome de domínio, solicitamos um certificado SSL e anexamos nela;
Apontamos um subdomínio para a distribuição.

Vamos tentar acessar o subdomínio criado, no meu caso cdn-article.tiagoboeing.com (para você estará inacessível pois removi após finalizar o artigo).

Sem pânico! Não há conteúdo no bucket do S3 e neste caso haverá erro mesmo, mas perceba que ao digitar http:// automaticamente será alterado o endereço para utilizar HTTPS.

Adicione qualquer arquivo no S3

Adicionei um arquivo HTML chamado index.html para testar a propriedade Default root object que configuramos durante a criação do CloudFront. Basta arrastar e soltar o arquivo no bucket (não customizei nenhuma configuração, apenas fiz upload).

E… vamos testar novamente recarregando a página.

Tudo certo! A CDN está pronta para ser utilizada.

Por segurança vamos tentar acessar o S3 diretamente sem passar pelo CloudFront, o endereço será https://tiagoboeing-cdn-article.s3.us-east-1.amazonaws.com/index.html e é esperado um erro de permissão, isto indica que o bucket realmente está privado e apenas acessível via domínio do CloudFront:

Invalidação de cache

O CloudFront possui um cache configurável, a distribuição que criamos utiliza as políticas padrões recomendadas, isto significa que o CloudFront entregará ao usuário o conteúdo que estiver em seu cache quando disponível e não expirado/invalidado. Esta é a razão pela qual ao realizar upload de um novo arquivo e/ou modificar um existente as alterações não são refletidas automaticamente, você precisar criar uma invalidação de cache!

No momento que uma invalidação for criada, assim que houver uma requisição para a distribuição o CloudFront verificará por novos arquivos e criará o cache novamente.

Esta foi a configuração de cache que utilizamos:

E aqui as políticas associadas a ela. Temos um TTL padrão de 24 horas (86.400 segundos).

Modifiquei o título do arquivo HTML para demonstrar o cache.

Realiza upload ao S3 e sobrescrito o index.html existente… Ao voltar no browser e recarregar a página ainda visualizamos o conteúdo antigo:

O motivo? Bem! O santo cache. Vamos criar uma invalidação. Volte ao CloudFront e clique na distribuição, depois acesse a aba Invalidations:

Clique em Create invalidation → na caixa Add object paths é possível:

escolher objetos (arquivos) individualmente: index.html, pasta/arquivo.txt, etc;
invalidar tudo de uma pasta específica: pasta/*;
invalidar todo o conteúdo de todo o CloudFront: /*.

Como no S3 temos apenas um arquivo chamado index.html e para exemplificar vou invalidar todo o conteúdo de todo o CloudFront informando: /*.

Tente ser o mais restritivo possível, evite criar invalidações usando /* pois isto tende a exigir maior tempo à medida que o conteúdo aumenta e fim do mês haverá uma surpresa ao verificar a fatura 😁, já que cada invalidação possui um custo.

Não há cobrança adicional para os primeiros 1.000 caminhos solicitados para invalidação a cada mês. Acima desse limite, será cobrado 0,005 USD por solicitação de invalidação de caminho.

Invalidação finalizada:

Agora é simples, basta voltar ao endereço da CDN, atualizar a página e o novo conteúdo será entregue ao cliente:

Ideias de próximos passos:

E talvez até mesmo artigo futuro… 🤔 O que acha?

Automatize via CI/CD o fluxo de upload dos arquivos para o S3 e invalidação do cache do CloudFront, utilize-o para entregar suas funcionalidades e correções com agilidade e/ou testar as MRs/PRs durante o desenvolvimento;
Configure a segurança utilizando Lambda@Edge para definir CSP — Content Security Policy. Duas ferramentas úteis para auxiliar na depuração: Mozila Observatory e Google CSP Evaluator; Configure a distribuição para navegar corretamente entre as rotas de um SPA;
Crie uma stack IaC (Infrastructure as Code) e evite configurações manuais via console da AWS sempre que precisar de uma nova CDN, faça deploy em poucos minutos com apenas alguns comandos. Ferramentas que podem auxiliar: Terraform, Serverless Framework ou AWS CloudFormation.

Fique por dentro das novidades

Se inscreva em meu canal do Youtube para acompanhar tutoriais.

DEV Community: Tiago Boeing

CDN de alta disponibilidade na AWS com Terraform: um guia para reduzir a latência e aumentar a performance de seu site

Objetivos

Pré-requisitos

Composição da infraestrutura

IaC - Infrastructure as Code

Terraform

Código-fonte

Definição do provedor (provider.tf)

Variáveis locais e queries (main.tf)

Definição das inputs (inputs.tf)

Passando valores para as variáveis criadas (terraform.tfvars)

Criação do bucket no S3 (s3.tf)

Criação e validação do certificado SSL (certificate.tf)

Criação do CloudFront (cloudfront.tf)

Teste da infraestrutura (test-cdn.tf)

Provisionar infraestrutura

Links do artigo

Leia também

English

Redes sociais

Serverless Framework + AWS: automatically creating certificate and domain for your app

Create a custom domain section

Deploy

To create the certificate on ACM run:

Create domain - simply run

Complete stack

Read more

CDN de alta disponibilidade na AWS com S3, CloudFront e Route53

O que são conteúdos estáticos?

CDN

S3

CloudFront

Definição de preço

Vamos lá…

S3 Bucket

Distribuição do CloudFront

Criar registro no Route53 para o CloudFront

Hora da diversão, vamos aos testes

Adicione qualquer arquivo no S3

Invalidação de cache

Ideias de próximos passos:

Fique por dentro das novidades

Definição do provedor (`provider.tf`)

Variáveis locais e queries (`main.tf`)

Definição das `inputs` (`inputs.tf`)

Passando valores para as variáveis criadas (`terraform.tfvars`)

Criação do bucket no S3 (`s3.tf`)

Criação e validação do certificado SSL (`certificate.tf`)

Criação do CloudFront (`cloudfront.tf`)

Teste da infraestrutura (`test-cdn.tf`)