Dois-je utiliser le cloud privé virtuel AWS d'Amazon (VPC)
En cours de migration vers Amazon EC2 depuis un autre fournisseur VPS. Nous avons vos besoins typiques de serveur Web/serveur de base de données. Serveurs Web devant nos serveurs de bases de données. Les serveurs de bases de données ne sont pas directement accessibles depuis Internet.
Je me demande s'il y a une raison de placer ces serveurs dans un cloud privé virtuel AWS (VPC) au lieu de simplement créer les instances et d'utiliser des groupes de sécurité pour les pare-feu.
Nous ne faisons rien d'extraordinaire juste une application web typique.
Une raison d'utiliser un VPC ou de ne pas utiliser un VPC?
Merci.
REMARQUE: Les nouveaux comptes dans AWS se lancent avec un "VPC par défaut" activé immédiatement et rendent "EC2-Classic" indisponible. En tant que tel, cette question et réponse a moins de sens maintenant qu'en août 2012. Je laisse la réponse telle quelle car elle aide à encadrer les différences entre "EC2-Classic" et la gamme de produits VPC. Veuillez consulter FAQ d'Amazon pour plus de détails.
Oui. Si vous êtes soucieux de la sécurité, un utilisateur lourd de CloudFormation, ou si vous souhaitez un contrôle complet sur la mise à l'échelle automatique (par opposition à Beanstalk, qui en résume certaines facettes mais vous donne toujours un accès complet aux paramètres de mise à l'échelle), utilisez un VPC. Cette article de blog fait un excellent travail résumant les avantages et les inconvénients. Quelques points saillants du billet de blog (écrit par kiip.me ):
Qu'est-ce qui ne va pas avec EC2?
Tous les nœuds sont adressables par Internet. Cela n'a pas beaucoup de sens pour les nœuds qui n'ont aucune raison d'exister sur Internet mondial. Par exemple: un nœud de base de données ne doit pas avoir de nom d'hôte/IP Internet public.
Tous les nœuds sont sur un réseau partagé et sont adressables les uns aux autres. Cela signifie qu'un nœud EC2 lancé par un utilisateur "Bob" peut accéder à n'importe lequel des nœuds EC2 lancé par un utilisateur "Fred". Notez que par défaut, les groupes de sécurité l'interdisent, mais il est assez facile d'annuler cette protection, en particulier lors de l'utilisation personnalisée groupes de sécurité.
Pas d'interface publique vs privée. Même si vous vouliez désactiver tout le trafic sur le nom d'hôte public, vous ne pouvez pas. Au niveau de l'interface réseau, chaque instance EC2 n'a qu'une seule interface réseau. Les noms d'hôte publics et les adresses IP élastiques sont routés sur le réseau "privé".
Ce qui est génial avec le VPC
D'abord et avant tout, VPC offre une quantité incroyable de sécurité par rapport à EC2. Les nœuds lancés dans un VPC ne sont pas adressables via Internet mondial, par EC2 ou par tout autre VPC. Cela ne signifie pas que vous pouvez oublier la sécurité, mais cela fournit un point de départ beaucoup plus sain par rapport à EC2. De plus, cela rend les règles de pare-feu beaucoup plus faciles, car les nœuds privés peuvent simplement dire "autoriser tout trafic provenant de notre réseau privé". Le temps écoulé entre le lancement d'un nœud et la mise en place d'un serveur Web entièrement exécuté est passé de 20 minutes à environ 5 minutes, uniquement en raison du temps gagné à éviter de propager les modifications du pare-feu.
Les jeux d'options DHCP vous permettent de spécifier le nom de domaine, les serveurs DNS, les serveurs NTP, etc.) que les nouveaux nœuds utiliseront lorsqu'ils seront lancés dans le VPC. Cela facilite la mise en œuvre du DNS personnalisé. EC2, vous devez faire tourner un nouveau nœud, modifier la configuration DNS, puis redémarrer les services de mise en réseau afin d'obtenir le même effet. Nous exécutons notre propre serveur DNS chez Kiip pour la résolution du nœud interne, et les jeux d'options DHCP rendent cela indolore (cela fait juste beaucoup plus de sens de taper east-web-001 dans votre navigateur au lieu de 10.101.84.22).
Et enfin, VPC fournit simplement un environnement de serveur beaucoup plus réaliste. Alors que VPC est un produit unique à AWS et semble vous "verrouiller" à AWS, le modèle que prend VPC est plus proche de si vous décidiez de commencer à exécuter votre propre matériel dédié. Avoir ces connaissances à l'avance et développer l'expérience du monde réel qui les entoure sera inestimable si vous devez passer à votre propre matériel.
La publication répertorie également certaines difficultés avec le VPC, qui concernent toutes plus ou moins le routage: obtenir une passerelle Internet ou NAT instance hors du VPC, communiquer entre les VPC, configurer un VPN pour votre datacenter. Celles-ci peuvent parfois être assez frustrantes, et la courbe d'apprentissage n'est pas triviale. Néanmoins, les avantages en matière de sécurité valent à eux seuls le déplacement, et le support d'Amazon (si vous êtes prêt à payer pour cela) est extrêmement utile en ce qui concerne la configuration VPC.
Actuellement, VPC présente certains avantages utiles par rapport à EC2, tels que:
- plusieurs cartes réseau par instance
- plusieurs IP par carte réseau
- règles de "refus" dans les groupes de sécurité
- Options DHCP
- plages IP internes prévisibles
- déplacement des cartes réseau et des adresses IP internes entre les instances
- VPN
On peut supposer qu'Amazon mettra également à niveau EC2 avec certaines de ces fonctionnalités, mais actuellement, elles sont uniquement VPC.
À l'heure actuelle, le VPC est le seul moyen d'avoir des équilibreurs de charge internes
Les VPC sont utiles si votre application doit accéder à des serveurs en dehors d'EC2, par exemple si vous disposez d'un service commun hébergé dans votre propre centre de données physique et non accessible via Internet. Si vous allez mettre tous vos serveurs Web et DB sur EC2, il n'y a aucune raison d'utiliser VPC.
Si vous choisissez RDS pour fournir vos services de base de données, vous pouvez configurer les groupes de sécurité DB pour autoriser les connexions à la base de données à partir d'une donnée Groupes de sécurité EC2 , même si vous avez des adresses IP dynamiques dans votre cluster EC2, le RDS créera automatiquement les règles de pare-feu pour autoriser les connexions uniquement à partir de vos instances , ce qui réduit les avantages d'un VPS dans ce cas.
VPS est en revanche génial lorsque vos instances EC2 doivent accéder à votre réseau local, vous pouvez alors établir une connexion VPN entre votre VPS et votre réseau local , contrôler la plage IP, les sous-réseaux, les routes et les règles de pare-feu sortantes, ce qui, je pense, n'est pas ce que vous recherchez.
Je recommanderais également fortement d'essayer Elastic Beanstalk , qui fournira une console qui facilite la configuration de votre cluster EC2 pour PHP, Java et applications .Net, permettant - Auto Scaling , Elastic Load Balancer et Automatic Application Versioning, permettant une restauration facile en cas de mauvais déploiements.
Vous avez soulevé une bonne préoccupation ici.
Je voudrais me concentrer sur la viabilité en termes de coût ...
Et le facteur coût?
Je pense que vous paierez pour ce serveur par heure. Même si vous choisissez 20 à 50 dollars par mois, ce sera quelque chose que vous paierez le reste de la vie de votre serveur. Le serveur VPN est quelque chose que vous pouvez facilement configurer sur un ancien matériel très bon marché et même gratuit pour une solution open source.
L'ajout de VPN au parc de serveurs AWS existant est logique, la configuration d'un serveur VPN solo sur AWS ne le fait pas. Je ne pense pas que ce soit la meilleure option rentable, mais c'est juste mon opinion.
Merci,
Alisa