Héberger un site web statique sur S3 + CloudFront : la bonne méthode actuelle

Le patron correct aujourd’hui, c’est un compartiment S3 privé servi par CloudFront avec Origin Access Control (OAC) — pas un compartiment public, pas le point de terminaison web de S3, et pas l’ancien Origin Access Identity (OAI). Block Public Access reste activé, la politique du compartiment n’admet que votre distribution CloudFront, le certificat TLS vient d’ACM dans us-east-1, et une petite fonction CloudFront gère la seule chose que le point de terminaison REST de S3 refuse de faire : servir index.html pour les URL de sous-répertoires. La plupart des vieux tutoriels montrent encore le point de terminaison web avec compartiment public; sautez-les.

Ce qui se passe

Il y a deux façons d’exposer du contenu S3 en HTTP, et elles se comportent différemment. Le point de terminaison web (bucket.s3-website-region.amazonaws.com) comprend les documents index et les pages d’erreur personnalisées, mais exige un compartiment public et ne parle que HTTP en clair — CloudFront ne peut pas s’y connecter en HTTPS. Le point de terminaison REST (bucket.s3.region.amazonaws.com) supporte HTTPS et l’accès privé via OAC, mais n’a aucune notion de document par défaut au-delà du Default Root Object de CloudFront — et ce réglage ne couvre que l’URL racine, pas /blog/ ni /pricing/.

OAC est la façon dont CloudFront s’authentifie auprès d’un compartiment privé : la distribution signe ses requêtes d’origine, et la politique du compartiment n’accorde s3:GetObject au principal de service CloudFront que si la requête vient de l’ARN précis de votre distribution. Il a remplacé OAI et supporte les objets SSE-KMS et toutes les régions; les nouveaux montages ne devraient pas utiliser OAI. Les certificats pour CloudFront doivent vivre dans ACM en us-east-1 peu importe où se trouve le compartiment — une règle dure qui coûte trente minutes de confusion à tout le monde une fois. Les détails sont dans la documentation CloudFront.

Quoi vérifier d’abord

La zone DNS est-elle accessible? Vous aurez besoin de créer des enregistrements de validation pour ACM et un alias pour le site; confirmez qui contrôle la zone avant de commencer.
Quelque chose exige-t-il de la logique côté serveur? Formulaires, authentification, redirections avec logique — l’hébergement statique ne le fera pas; il faudra des fonctions en périphérie ou une autre plateforme.
SPA ou site multipage? Les SPA veulent les 403/404 réécrits vers /index.html; les sites de documents veulent des fichiers index par répertoire. Les deux exigent une gestion d’erreur différente.
Compartiment existant ou nouveau? Adapter OAC sur un compartiment public implique aussi de retirer la politique publique et de réactiver Block Public Access.

Comment vérifier

Après le montage, confirmez que le compartiment est scellé et que seul CloudFront peut le lire :

# Devrait montrer les quatre réglages Block Public Access à true
aws s3api get-public-access-block --bucket my-site-bucket

# L'URL directe de l'objet doit retourner 403
curl -sI https://my-site-bucket.s3.ca-central-1.amazonaws.com/index.html | head -1

# À travers la distribution : 200, avec un en-tête de cache
curl -sI https://www.example.com/ | grep -iE 'HTTP|x-cache'

CloudFront > Distributions > votre distribution > Origins devrait montrer l’origine avec Origin access control settings, et la politique du compartiment devrait référencer l’ARN de votre distribution.

Le runbook

Créez le compartiment, gardez-le privé. Laissez Block Public Access complètement activé. Pas de bascule d’hébergement web — cette fonctionnalité appartient au point de terminaison que vous n’utilisez pas.
Demandez le certificat en us-east-1. Dans Certificate Manager (région Virginie du Nord), demandez un certificat public pour example.com et www.example.com, validez par DNS.
Créez la distribution avec OAC. Origine = le point de terminaison REST du compartiment (la console le propose), Origin access > Origin access control settings, créez un nouvel OAC. Réglez Default Root Object à index.html, attachez le certificat et vos noms de domaine alternatifs, redirigez HTTP vers HTTPS.

Appliquez la politique de compartiment que CloudFront vous donne. La console offre de la copier; elle ressemble à ceci :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-site-bucket/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
      }
    }
  }]
}

Gérez les index de sous-répertoires avec une fonction CloudFront. Attachée sur viewer request :

function handler(event) {
  var request = event.request;
  var uri = request.uri;
  if (uri.endsWith('/')) {
    request.uri += 'index.html';
  } else if (!uri.includes('.')) {
    request.uri += '/index.html';
  }
  return request;
}

Pour une SPA, sautez plutôt la fonction et ajoutez des réponses d’erreur personnalisées qui mappent 403 et 404 vers /index.html avec un code 200.

Pointez le DNS vers la distribution. Un enregistrement alias dans Route 53, ou un CNAME chez votre hébergeur DNS, vers le domaine dxxxxxxxxxxxx.cloudfront.net.
Déployez avec sync plus une invalidation ciblée :
```
aws s3 sync ./dist s3://my-site-bucket/ --delete
aws cloudfront create-invalidation --distribution-id EDFDVBD6EXAMPLE --paths "/*"
```
L’article sur les patrons sync couvre les drapeaux à connaître; notez que les invalidations au-delà de l’allocation mensuelle gratuite sont facturées par chemin.

Quand ce n’est pas la bonne approche

Si le site a besoin de rendu côté serveur, de sessions ou d’un backend d’administration, cette pile n’a pas la bonne forme — vous finirez par visser du Lambda sur tout ce qu’un petit serveur d’application fait proprement. Si l’auditoire est entièrement interne, un ALB interne ou un hôte plus simple évite la plomberie de distribution publique. Et si vous publiez deux fois par année avec un trafic minuscule, le palier gratuit d’une plateforme gérée donne le même résultat avec moins à posséder — ce patron gagne sa place quand vous voulez la performance d’un CDN, du TLS personnalisé et une infrastructure que vous contrôlez.

Erreurs courantes

Demander le certificat ACM dans la région du compartiment et fixer une liste déroulante de certificats vide dans CloudFront — il doit être en us-east-1.
Suivre un vieux tutoriel vers le point de terminaison web public, puis échouer une revue de sécurité pour un compartiment lisible par tout le monde.
Oublier le comportement des index de sous-répertoires et livrer un site où /about/ retourne 403 pendant que /about/index.html fonctionne.
Invalider /* à chaque commit dans un pipeline CI occupé et le payer — utilisez des noms de fichiers d’actifs versionnés et n’invalidez que le HTML.

Prévention

Codifiez toute la pile (compartiment, OAC, distribution, fonction, DNS) en Terraform ou CloudFormation dès la première semaine, pendant que c’est encore petit.
Gardez les déploiements dans un seul script : sync, invalidation, terminé — pas de dérive de console.
Alarmez sur le taux de 5xx CloudFront comme pour n’importe quelle origine, aux côtés de votre base d’alarmes CloudWatch.
Revérifiez la politique du compartiment après tout renommage de compartiment ou reconstruction de distribution; un ARN de distribution périmé dans la condition brise le site avec des 403 uniformes.

Monté de cette façon, le résultat est rapide, peu coûteux et presque sans entretien — les modes de défaillance sont tous dans le montage, pas dans l’exploitation. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.