Passerelle S3 ou point de terminaison d’interface pour un client local ?

Atteindre S3 depuis un réseau de bureau via un VPN de site n’est pas un problème de routage qu’une route statique peut résoudre seul. Un point de terminaison de passerelle est attaché aux tables de routage et sert les requêtes qui naissent à l’intérieur du VPC. Un point de terminaison d’interface place des interfaces réseau élastiques avec des adresses privées dans vos sous-réseaux, et ces adresses sont joignables depuis les locaux via VPN ou Direct Connect. L’endroit où la requête commence décide laquelle des deux vous avez réellement besoin, et le travail sur DNS, groupe de sécurité et politique découle de cette réponse.

Séparez les types de point de terminaison selon l’endroit où la requête commence

Un point de terminaison de passerelle apparaît comme une entrée de table de routage pointant vers une liste de préfixes gérée. Il n’a ni interface réseau, ni groupe de sécurité, ni adresse privée propre, et c’est précisément pourquoi un hôte local ne peut pas y router : il n’y a rien de l’autre côté vers quoi router. Le trafic venant de l’intérieur du VPC atteint S3 parce que la table de routage du sous-réseau envoie ce préfixe au point de terminaison. Le trafic venu d’ailleurs n’a aucune entrée de ce genre à suivre.

Un point de terminaison d’interface est un ensemble d’interfaces réseau dans les sous-réseaux que vous choisissez, chacune avec une adresse privée de ce sous-réseau et un groupe de sécurité attaché. C’est la forme qu’un client hybride peut utiliser, car c’est une destination ordinaire vers laquelle votre tunnel peut transporter des paquets. Cela signifie aussi que le point de terminaison consomme des adresses dans le sous-réseau et peut les épuiser.

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

Lisez la colonne Type plutôt que le nom. Un même VPC contient souvent les deux types pour le même service, et l’entrée dont votre application locale a besoin est celle d’interface.

Construisez le chemin vers l’adresse d’interface avant de tester S3

Trois choses doivent être vraies en même temps : le routeur local a une route vers le sous-réseau du point de terminaison, le chemin de retour depuis ce sous-réseau atteint le réseau client, et le groupe de sécurité du point de terminaison admet la plage source du client. L’ACL réseau du sous-réseau peut encore jeter le paquet une fois les trois satisfaits, alors vérifiez-la comme quatrième élément et non comme une pensée tardive.

Une route qui fonctionne vers une instance EC2 quelconque du VPC ne prouve rien de tout cela. Elle montre que le tunnel est monté, ce qui est la seule partie du chemin que vous connaissiez déjà. Prouvez l’adresse du point de terminaison séparément, puis prouvez que le nom s’y résout.

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

La première commande montre quelle interface le client utiliserait. La deuxième prouve une poignée de main TCP. La troisième prouve que TLS aboutit avec un certificat valide pour le nom du point de terminaison, et c’est le contrôle qui attrape une mauvaise adresse avant que vous blâmiez les permissions.

Décidez quelle réponse DNS l’application reçoit

L’existence d’un point de terminaison d’interface dans le VPC ne redirige pas un SDK local à elle seule. Le client utilise soit le nom propre au point de terminaison qu’AWS publie pour celui-ci, soit une zone hébergée privée que vous avez délibérément rendue résoluble depuis le bureau.

Pour la résolution hybride, le résolveur local a besoin d’un chemin pris en charge vers la vue DNS du VPC, généralement via un point de terminaison entrant Resolver. Activer le DNS privé sans comprendre quelles sources de requêtes il affecte est la façon dont une recherche commence à renvoyer une adresse que le bureau ne peut pas atteindre. Le réglage change les réponses des requêtes qui arrivent par le résolveur du VPC, pas celles de tous les clients partout.

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

Exécutez les deux sur l’hôte de l’application, pas sur une machine de saut dans le VPC. Le résolveur qui répond là est celui que votre charge de travail utilise, et une réponse différente depuis un autre hôte est la source de confusion la plus courante dans cette conception.

La joignabilité n’est pas une autorisation

Une requête qui arrive au point de terminaison a encore besoin d’un principal autorisé et d’une autorisation de compartiment applicable. Une politique de point de terminaison peut restreindre ce que le point de terminaison autorise, et une politique de compartiment peut le restreindre encore. Atteindre l’interface ne dit rien des objets que l’appelant peut lire.

Testez les deux sens : un appel autorisé et inoffensif contre le compartiment prévu, et un appel dont on attend le refus pour une identité ou une ressource hors politique. Conservez le nom du point de terminaison, l’adresse résolue et le contexte de politique avec le résultat pour que la personne suivante puisse le reproduire. Un refus qui nomme le type de politique épargne une heure de conjectures.

Enfin, chiffrez le coût des deux options avant de provisionner. Un point de terminaison d’interface est facturé à l’heure d’interface et au gigaoctet, alors qu’un point de terminaison de passerelle ne l’est pas, et cette différence tranche la question pour de nombreuses charges à faible volume qui n’ont besoin que d’un accès côté VPC.