Pour qu'une instance RDS dans un VPC soit accessible "publiquement" (Internet), tous les sous-réseaux auxquels elle est attachée doivent être des sous-réseaux "publics" - par opposition à "privés" du VPC.
Un sous-réseau public est essentiellement défini comme un sous-réseau qui a l'objet passerelle Internet (igw-xxxxxxxx) comme route vers «Internet», ou au moins vers toutes les destinations Internet auxquelles vous devez accéder. Il s'agit généralement d'une adresse de destination de 0.0.0.0/0
. Les sous-réseaux publics doivent être utilisés pour les instances (y compris RDS) qui auront une adresse IP publique associée, et ne doivent pas être utilisées pour les instances qui n'ont pas d'adresse IP publique, car les adresses privées ne fonctionnent pas sur Internet sans traduction.
Un sous-réseau privé, en revanche, a sa table de routage configurée pour atteindre les destinations Internet via une autre instance EC2, généralement une instance NAT. Cela apparaît dans la table de routage VPC associée à ce sous-réseau en tant que i-xxxxxxxx, plutôt que «igw». Cette machine (qui, elle-même, sera en fait sur un sous-réseau différent de ceux pour lesquels elle agit comme une destination de route) sert de traducteur, permettant aux instances privées IP uniquement de faire de manière transparente des demandes Internet sortantes en utilisant le public de la machine NAT. IP pour leurs besoins Internet. Les instances avec une adresse IP publique ne peuvent pas interagir correctement avec Internet si elles sont attachées à un sous-réseau privé.
Dans le cas spécifique, ici, les sous-réseaux associés à l'instance RDS n'étaient pas vraiment configurés comme quelque chose qui pouvait être simplement classé comme un sous-réseau privé ou public, car le sous-réseau n'avait aucun itinéraire par défaut. L'ajout d'une route par défaut via l'objet «igw» ou, comme OP, l'ajout d'une route statique à l'adresse IP Internet où la connectivité était nécessaire, dans la table de routage VPC pour les sous-réseaux résout le problème de connectivité.
Cependant ... Si vous rencontrez un problème similaire, vous ne pouvez pas simplement modifier la table de routage ou créer de nouvelles tables de routage et leur associer les sous-réseaux, à moins que rien d'autre ne fonctionne déjà correctement sur les sous-réseaux, car la modification pourrait raisonnablement être devrait rompre la connectivité existante. Le cours correct, dans ce cas, serait de provisionner les instances sur différents sous-réseaux avec les entrées de table de routage correctes en place.
Lors de la configuration d'un VPC, il est idéal de définir clairement les rôles de sous-réseau et de fournir ensuite les itinéraires nécessaires lors de la première mise en service du VPC. Il est également important de se rappeler que le "LAN" VPC entier est un réseau défini par logiciel. Contrairement à un réseau physique, où le routeur peut devenir un goulot d'étranglement et il est souvent judicieux de placer des machines à fort trafic parmi elles sur le même sous-réseau ... le trafic traversant les sous-réseaux n'a aucun inconvénient en termes de performances sur VPC. Les machines doivent être placées sur des sous-réseaux appropriés aux besoins d'adressage IP de la machine - adresse publique, sous-réseau public; pas d'adresse publique, sous-réseau privé.
Plus de discussion sur la logistique des sous-réseaux privés / publics dans VPC peut être trouvée dans Pourquoi avons-nous besoin d'un sous-réseau privé dans VPC (à Stack Overflow).
(110)
message d'erreur signifie «connexion expirée», il s'agit donc définitivement d'un problème de connectivité IP. Votre instance RDS montre qu'elle est associée à deux sous-réseaux. Dans la console VPC, quelle est la route par défaut de ces deux sous-réseaux? Est-ce un "igw-xxxxxxxx" ou est-ce un "i-xxxxxxxx"?