Site Web avec AWS : hébergement moderne

Dans mon premier article de cette série, j’ai approfondi le approche classique à l’hébergement d’un site Web S3 avec HTTPS et un domaine personnalisé. Cet article de suivi se concentrera sur approche moderne. Il n’y a que quelques différences et je vais me concentrer sur celles-ci. Je recommande de lire le premier message avant de continuer.

résumer

Commençons par un bref récapitulatif. Amazon S3 dispose d’une fonctionnalité appelée hébergement de sites Web statiques. S’il est activé, il fournit un point de terminaison tel que http://.s3-website..amazonaws.com/ qui est accessible uniquement via HTTP et non HTTPS. Pour l’accès HTTPS, une distribution CloudFront doit être créée qui fournit un point de terminaison tel que https://.cloudfront.net. Un domaine personnalisé peut également être attribué à cette distribution CloudFront. Mais plus important encore, le compartiment et tout son contenu doivent être accessibles au public, ce qui signifie que le Bloquer l’accès public Le paramètre doit être désactivé.

S3

Le approche moderne vers l’hébergement S3 présente quelques changements par rapport à l’hébergement approche classique. Ceux-ci affectent la configuration du site Web du compartiment, les autorisations et l’accès public, ainsi que le point de terminaison. Passons-les en revue.

Configuration du site Web

Le hébergement de site Web statique La fonctionnalité n’est plus nécessaire pour héberger un site Web sur S3, mais uniquement lors de l’utilisation de CloudFront.

Autorisation et accès public

Désactivation Bloquer l’accès public sur l’autorisation du bucket pose un problème de sécurité. Il est essentiel de s’assurer qu’aucune information sensible n’est stockée dans votre bucket car elle sera accessible depuis Internet. AWS a fourni de nombreux avertissements dans sa documentation concernant ce paramètre :

Avertissement
Avant de terminer cette étape, consultez Blocage de l’accès public à votre stockage Amazon S3 pour vous assurer que vous comprenez et acceptez les risques liés à l’autorisation de l’accès public. Lorsque vous désactivez les paramètres de blocage de l’accès public pour rendre votre compartiment public, n’importe qui sur Internet peut accéder à votre compartiment. Nous vous recommandons de bloquer tout accès public à vos buckets.
Modifier les paramètres de blocage de l’accès public

Heureusement, nous n’avons plus besoin de ce paramètre car nous pouvons restreindre l’accès au bucket avec une stratégie de bucket. C’est appelé Contrôle d’accès à l’origine (OAC) et nous l’ajoutons directement à la stratégie du bucket :

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

Cette stratégie autorise l’accès à CloudFront en lecture seule (s3:GetObject et s3:ListBucket) au seau. Le Condition restreint davantage la stratégie à l’accès à certaines distributions CloudFront uniquement.

403 Accès refusé contre 404 introuvable

Il est important de noter que la réponse d’Amazon S3 pour les objets non existants varie entre 404 et 403.

Si l’objet que vous demandez n’existe pas, l’erreur renvoyée par Amazon S3 dépend du fait que vous disposez également de l’objet s3:ListBucket autorisation.
Si vous avez le s3:ListBucket autorisation sur le compartiment, Amazon S3 renvoie un code d’état HTTP 404 (introuvable) erreur.
Si vous n’avez pas le s3:ListBucket autorisation, Amazon S3 renvoie un code d’état HTTP 403 (Accès refusé) erreur.
Autorisations Amazon S3 GetObject

Nous avons ajouté le s3:ListBucket autorisation à la stratégie de compartiment ci-dessus pour découvrir ces faux 403 Accès refusé des erreurs qui sont en réalité 404 introuvable les erreurs. De plus, cela ne devrait pas poser de problème de sécurité puisque le compartiment n’est pas public et uniquement accessible par CloudFront.

Points de terminaison

Puisque nous n’utilisons plus la fonctionnalité d’hébergement de sites Web statiques de S3, nous n’avons que la Point de terminaison REST sous cette forme :

https://.s3..amazonaws.com/.

L’ancien point de terminaison du site Web n’est plus disponible dans cette configuration :

http://.s3-website..amazonaws.com/

CloudFront

Seules quelques modifications sont requises pour la configuration d’Amazon CloudFront.

Origine

L’origine est toujours Amazon S3, mais nous utilisons désormais un compartiment S3 standard au lieu d’un compartiment configuré comme point de terminaison de site Web. Cela signifie que nous devons spécifier le point de terminaison REST du bucket. De toute façon, la liste déroulante d’origine dans la console CloudFront n’affichera que les compartiments S3 standard, vous pouvez donc sélectionner le compartiment directement à partir de là.

Accès à l’origine

L’accès à l’origine accorde à la distribution CloudFront l’accès au compartiment S3. Il existe trois paramètres : identités d’accès publiques, d’origine et héritées. Nous utilisons le paramètre de contrôle d’accès à l’origine (OAC) recommandé. L’OAC peut être créé directement dans la console ou sélectionné s’il existe. Une fois la distribution créée, la stratégie du compartiment S3 doit être mise à jour pour accorder l’accès à CloudFront. Cette politique est la même que celle que j’ai mentionnée plus tôt.

Objet racine par défaut

Le objet racine par défaut est le fichier renvoyé lorsqu’une requête est effectuée vers l’URL racine de votre distribution.

Lorsque vous définissez un objet racine par défaut, une requête de l’utilisateur final qui appelle la racine de votre distribution renvoie l’objet racine par défaut. Par exemple, si vous désignez le fichier index.html comme objet racine par défaut, une requête pour : https://d111111abcdef8.cloudfront.net/
Retour:
https://d111111abcdef8.cloudfront.net/index.html
Comment fonctionne l’objet racine par défaut

Ceci est similaire au document d’indexation de l’hébergement de sites Web statiques Amazon S3, mais avec une différence subtile. Amazon S3 renvoie le document d’index pour les requêtes vers les sous-répertoires, tandis que CloudFront renvoie uniquement l’objet racine par défaut pour les requêtes au niveau racine.

Par exemple, une requête de sous-répertoire pour ne renverra pas l’objet racine par défaut index.htmlmême s’il existe dans le sous-répertoire sous photos/index.html.

Réponse d’erreur personnalisée

Si l’objet demandé n’est pas disponible pour une raison quelconque, CloudFront renverra normalement le code d’état HTTP approprié à l’utilisateur. Par exemple, si l’objet à n’existe pas, CloudFront répondra avec le code d’état 404 introuvable. Ce comportement peut être configuré avec réponses d’erreur personnalisées.

Encore une fois, cela ressemble à documents d’erreur de l’hébergement de sites Web statiques Amazon S3, mais plus puissant. Amazon S3 renvoie le document d’erreur uniquement pour 404 introuvable les erreurs. CloudFront, en revanche, nous permet de personnaliser comment et quoi répondre pour diverses erreurs HTTP 400 et 500.

En revenant sur notre exemple précédent, ce comportement nous permet de renvoyer l’objet racine par défaut index.html pour toutes les requêtes de sous-répertoire comme cela déclencherait habituellement 404 introuvable les erreurs. Cependant, nous avons la possibilité d’écraser le code d’état de la réponse et de renvoyer un 200 OK. Il s’agit d’une différence significative par rapport à l’hébergement de sites Web statiques Amazon S3, qui renvoie le document d’erreur avec un 404 introuvable Code de réponse. Certains navigateurs ignoreront le contenu renvoyé par une telle réponse et afficheront à la place leur propre page d’erreur.

En passant : cette fonctionnalité est particulièrement utile pour les applications à page unique (SPA) qui sont généralement servies via un seul index.html déposer. La navigation entre les pages est principalement gérée côté client sans lancer de nouvelles requêtes HTTP. Découvrez-en plus sur mon article précédent concernant ce sujet.

Modèle de formation cloud

Le référentiel suivant contient deux modèles qui peuvent être déployés via Console CloudFormation ou la AWS CLI.

• templates/classic.yml: utilise un compartiment S3 public avec hébergement de sites Web statiques. Voir mon premier message pour plus d’informations.
• templates/modern.yml: utilise un bucket S3 privé sans hébergement de sites Web statiques.