S3 : point de terminaison de passerelle ou d’interface pour l’accès depuis le réseau local

Deux types de point de terminaison S3 semblent interchangeables lors d’une revue de conception et se comportent tout autrement dès que le client se trouve hors site. Un point de terminaison de passerelle est une intégration à la table de routage à l’intérieur d’un VPC, donc une requête issue d’un VPN de site n’y arrive jamais comme destination privée. Un point de terminaison d’interface place des adresses privées sur des interfaces réseau, ce qu’un chemin hybride peut réellement atteindre. Tout ce qui suit dépend de celui des deux que vous avez choisi.

Décidez d’après l’entrée réseau, pas d’après le nom du service

Partez de l’endroit où le trafic prend naissance, car c’est la question à laquelle le type de point de terminaison répond. Une charge de travail dans un contexte de VPC pris en charge peut utiliser un point de terminaison de passerelle et n’a jamais besoin de sa propre adresse privée. Une charge de travail sur site a besoin d’une adresse privée vers laquelle elle peut router, et c’est ce que fournit un point de terminaison d’interface. Si une conception mélange les deux, les deux types de point de terminaison peuvent coexister dans un même VPC, et c’est un agencement normal et non une duplication.

Les mélanger n’est pas le problème. Supposer qu’un type couvre l’autre l’est.

Classez le client avant de choisir quoi que ce soit. Un espace de travail à l’intérieur du VPC, un conteneur derrière une passerelle NAT et une application dans une agence sont trois sources différentes, et seule la dernière impose l’entrée hybride. Inscrivez cette classification à côté de l’inventaire des points de terminaison pour que le prochain relecteur voie pourquoi chaque point de terminaison existe.

Ce que le chemin d’interface exige de bout en bout

Un point de terminaison d’interface accorde l’accessibilité aux adresses privées, et l’accessibilité n’est qu’une des quatre exigences. Le réseau local a besoin d’une route vers ces adresses, le côté VPC a besoin d’un chemin de retour, le groupe de sécurité du point de terminaison doit admettre la plage source, et tout équipement d’inspection entre les deux doit autoriser le flux. Une route vers une instance quelconque du VPC ne prouve aucune des quatre.

Travaillez depuis l’extrémité distante vers l’arrière. Confirmez que les interfaces réseau du point de terminaison existent dans les sous-réseaux attendus, puis confirmez que son groupe de sécurité admet la plage locale réelle et non un espace réservé. Vérifiez ensuite que le tunnel ou le circuit transporte le chemin de retour dans le même sens. L’inspection est l’étape que les gens sautent, car un équipement intermédiaire qui autorise la connexion peut encore abandonner un corps de réponse plus volumineux, et cela ressemble à un problème de débit plutôt qu’à un problème de politique.

Testez avec la plus petite opération autorisée disponible plutôt qu’avec un téléchargement volumineux. La panne apparaît plus tôt et avec moins de trafic à justifier.

Le DNS suit la source de la requête, pas le VPC

Un point de terminaison qui existe ne redirige rien par lui-même. L’application reçoit le nom que son résolveur a renvoyé, et le résolveur répond selon la vue qu’il est autorisé à voir. Une instance à l’intérieur du VPC et un ordinateur portable au bureau posent deux questions différentes et peuvent tous deux obtenir des réponses correctes et différentes. Vérifier l’une et conclure sur l’autre, c’est ainsi qu’un test réussi devient un déploiement raté.

Lisez le réglage DNS privé du point de terminaison comme faisant partie de la conception, pas comme une case à cocher à activer après la mise en service.

Si le résolveur du bureau doit voir la vue du VPC, ce chemin doit être construit exprès, souvent au moyen d’un point de terminaison de résolveur entrant. Interrogez depuis le contexte propre à l’application et notez quel résolveur a répondu. Un résultat recueilli sur un hôte bastion à l’intérieur du VPC décrit la vue du bastion et rien d’autre.

L’autorisation est distincte de l’accessibilité

Un point de terminaison accessible renvoie des erreurs pour les requêtes que le principal n’est pas autorisé à effectuer, et cette erreur signifie que le système fonctionne comme prévu. La politique d’identité, la politique de bucket et toute politique de point de terminaison sont évaluées dans leurs propres couches. L’accès réseau n’a jamais accordé d’autorisation.

Acceptez la conception sur deux résultats : un appel autorisé anodin qui réussit, et un refus attendu pour une identité ou un bucket exclu.

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

Consignez le nom du point de terminaison, la destination résolue et le contexte de politique à côté de chaque résultat, car un changement DNS ultérieur peut invalider toute la conclusion. Comparez le coût actuel et le poids opérationnel des deux types de point de terminaison avant de provisionner quoi que ce soit. Un point de terminaison d’interface achète une entrée privée hybride, ce n’est pas une exigence universelle, et le chemin de passerelle reste souvent la meilleure réponse pour les charges de travail à l’intérieur du VPC. Le choix se fait par client et reste révisable.