Avantages d'EBS par rapport au magasin d'instance (et inversement)
Je ne sais pas quels sont les avantages de EBS par rapport à instance-store pour mes instances sur Amazon EC2. Le cas échéant, il semble qu'EBS soit beaucoup plus utile (arrêt, démarrage, persistance + vitesse plus rapide) à une différence de coût relativement faible ...? En outre, existe-t-il un critère permettant de déterminer si davantage de personnes utilisent EBS maintenant qu'il est disponible, étant donné qu'il est encore relativement récent?
En bout de ligne, vous devez presque toujours utiliser des instances basées sur EBS.
Voici pourquoi
- Les instances basées sur EBS peuvent être définies de manière à ne pas pouvoir être arrêtées (accidentellement) via l'API.
- Les instances EBS peuvent être arrêtées lorsque vous ne les utilisez pas et reprises lorsque vous en avez besoin à nouveau (comme par exemple, suspendre un PC virtuel), du moins grâce à mes habitudes d'utilisation, vous économisez beaucoup plus que ce que je dépense en quelques dizaines de Go de stockage EBS.
- Les instances sauvegardées par EBS ne perdent pas leur stockage d'instance lorsqu'elles se bloquent (cela n'est pas obligatoire pour tous les utilisateurs, mais rend la récupération beaucoup plus rapide)
- Vous pouvez redimensionner dynamiquement le stockage d'instance EBS.
- Vous pouvez transférer le stockage d'instance EBS vers une toute nouvelle instance (utile si le matériel chez Amazon sur lequel vous étiez en cours d'exécution devient instable ou meurt, ce qui se produit de temps à autre).
- Il est plus rapide de lancer une instance sécurisée EBS car il n'est pas nécessaire d'extraire l'image de S3.
- Si le matériel de votre instance EBS est planifié pour maintenance , l'arrêt et le démarrage de l'instance migrent automatiquement vers le nouveau matériel. J'ai également pu déplacer une instance basée sur EBS sur un matériel défaillant en arrêtant l'instance et en la relançant (le kilométrage peut varier en fonction du matériel défaillant).
Je suis un grand utilisateur d’Amazon et toutes mes instances sont passées au stockage sécurisé EBS dès que la technologie est sortie de la version bêta. Je suis très content du résultat.
EBS peut toujours échouer - pas une solution miracle
N'oubliez pas que toute infrastructure en nuage peut échouer à tout moment. Planifiez votre infrastructure en conséquence. Bien que les instances basées sur EBS offrent un certain niveau de durabilité par rapport aux instances de stockage éphémères, elles peuvent échouer et échouent. Disposez d'une AMI à partir de laquelle vous pouvez lancer de nouvelles instances selon vos besoins dans n'importe quelle zone de disponibilité, sauvegardez vos données importantes (par exemple, des bases de données) et, si votre budget le permet, exécutez plusieurs instances de serveurs pour l'équilibrage de la charge et la redondance (idéalement dans plusieurs zones de disponibilité). ).
Quand pas à
À certains moments, il peut être moins coûteux d’atteindre plus rapidement IO sur les instances de magasin d’instances. Il fut un temps où c'était certainement vrai. Il existe maintenant de nombreuses options pour le stockage EBS, répondant à de nombreux besoins. Les options et leurs prix évoluent constamment à mesure que la technologie évolue. Si vous avez un nombre important d'instances réellement disponibles (elles n'affecteront pas beaucoup votre entreprise si elles disparaissent), faites le calcul coûts/performances. Les instances basées sur EBS peuvent également mourir à tout moment, mais mon expérience pratique montre qu'EBS est plus durable.
99% de notre configuration AWS est recyclable. Donc, pour moi, peu importe que je mette fin à une instance, rien n'est jamais perdu. Par exemple. mon application est automatiquement déployée sur une instance de SVN, nos journaux sont écrits sur un serveur syslog central.
Les seuls avantages du stockage d'instance que je vois sont les économies de coûts. Sinon, les instances basées sur EBS sont gagnantes. Eric a mentionné tous les avantages.
[2012-07-16] Je dirais que cette réponse est très différente aujourd'hui.
Je n'ai eu aucune bonne expérience avec les instances soutenues par EBS au cours des dernières années. Les derniers temps morts sur AWS ont également anéanti EBS.
Je suppose qu'un service comme RDS utilise également une sorte d'EBS et cela semble fonctionner dans la plupart des cas. Dans les cas où nous nous gérons nous-mêmes, nous nous sommes débarrassés d’EBS autant que possible.
Débarrassez-vous dans une mesure où nous avons déplacé un cluster de bases de données vers le fer (= matériel réel). Le seul élément restant de notre infrastructure est un serveur de base de données dans lequel nous répartissons plusieurs volumes EBS dans un logiciel RAID et effectuons une sauvegarde deux fois par jour. Tout ce qui serait perdu entre les sauvegardes, nous pouvons vivre avec.
EBS est une technologie quelque peu floconneuse puisqu'il s'agit essentiellement d'un volume réseau: un volume connecté à votre serveur à distance. Je ne nie pas le travail effectué - c’est un produit étonnant, car pratiquement illimité persistant le stockage n’est qu’un appel API. Mais il n’est guère adapté aux scénarios dans lesquels les performances d’E/S sont essentielles.
Et en plus du comportement du stockage réseau, tout le réseau est partagé sur les instances EC2. Plus une instance est petite (par exemple, t1.micro, m1.small), plus elle s’aggrave du fait que vos interfaces réseau sur le système hôte réel sont partagées par plusieurs machines virtuelles (= votre instance EC2) qui s’exécutent par dessus.
La plus grande instance que vous obtenez, le mieux il obtient bien sûr. Mieux ici signifie dans des limites raisonnables.
Lorsque la persistance est nécessaire, je conseillerais toujours aux personnes d'utiliser quelque chose comme S3 pour centraliser les instances. S3 est un service très stable. Ensuite, automatisez la configuration de votre instance à un point où vous pouvez démarrer un nouveau serveur et il se prépare tout seul. Il n’est alors pas nécessaire d’avoir un stockage réseau qui dure plus longtemps que l’instance.
Dans l’ensemble, je ne vois donc aucun avantage à ce que les instances basées sur EBS profitent. Je préfère ajouter une minute pour bootstrap, puis courir avec un potentiel SPOF.
Nous aimons l'instance-store. Cela nous oblige à rendre nos instances entièrement recyclables et nous pouvons facilement automatiser le processus de création d’un serveur à partir de zéro sur une AMI donnée. Cela signifie également que nous pouvons facilement échanger des IAM. De plus, EBS a toujours des problèmes de performances de temps en temps.
Eric a très bien réussi. Nous ( Bitnami ) sommes un fournisseur populaire d’AMI gratuites pour des applications populaires et des cadres de développement (PHP, Joomla, Drupal, vous avez l’idée). Je peux vous dire que les AMI soutenues par EBS sont nettement plus populaires que celles soutenues par S3. En général, je pense que les instances basées sur s3 sont utilisées pour des travaux distribués à durée limitée (par exemple, le traitement de données à grande échelle) dans lesquels, si une machine tombe en panne, une autre est tout simplement accélérée. Les systèmes AMIS reposant sur EBS ont tendance à être utilisés pour des tâches de serveur "classiques", telles que des serveurs Web ou des serveurs de bases de données qui conservent l'état localement et exigent donc que les données soient disponibles en cas de blocage.
Un aspect que je n'ai pas vu mentionné est le fait que vous pouvez prendre des instantanés d'une instance basée sur EBS pendant son exécution, ce qui vous permet effectivement de réaliser des sauvegardes très économiques de votre infrastructure (les instantanés sont basés sur des blocs et incrémentaux).
Le "matériel" EC2
Lorsqu'une instance EC2 est lancée, une machine virtuelle est réservée à son exécution. Cette machine virtuelle a des spécifications particulières en fonction du type d'instance: UC 32 bits ou 64 bits, nombre de cœurs virtuels, taille du disque dur, etc. Des informations détaillées sur les spécifications de l'instance sont disponibles à l'adresse . http://aws.Amazon.com/ec2/#instance .
Lorsque votre instance EC2 est dans un état "en cours d'exécution", cela signifie qu'elle s'exécute sur la machine virtuelle, et c'est pour cela que vous êtes facturé.
Le disque dur de la machine virtuelle est considéré comme "éphémère". Le terme "éphémère" vient du mot grec "éphémères" qui signifie "ne dure qu'un jour". Tout ce qui se trouve sur un tel disque dur doit être considéré comme temporaire. À moins que les données ne soient copiées du disque dur, si la machine virtuelle est arrêtée, les données sont perdues. Cela inclut les données, les logiciels et même un système d'exploitation résidant sur ces disques durs.
Amazon Web Services fournit aux instances EC2 deux types de périphériques racine: "basé sur EBS" et "magasin d'instances".
"Instance Store" Instances
Une instance de "magasin d'instances" est une instance EC2 dont le périphérique racine réside sur le disque dur de la machine virtuelle. Lors de la création de l'instance, l'AMI de base est copiée sur le disque dur de la machine virtuelle et lancée. L'instance peut s'exécuter aussi longtemps que vous le souhaitez, mais elle ne peut pas être arrêtée. Le périphérique racine de l’instance étant le disque dur réel, il est "bloqué" sur le matériel et vous ne pouvez que mettre fin à l’instance. Si vous faites cela, l'instance est supprimée, elle ne sera jamais récupérée. Vous courez également le risque que, en cas de défaillance matérielle de la machine virtuelle, vous perdiez tout ce qui se trouve sur le disque dur.
Si vous lancez une instance "instance store", soyez prêt à la laisser fonctionner jusqu'à ce que vous ayez complètement terminé. Notez que vous serez facturé à partir du moment où l'instance est démarrée, jusqu'au moment où elle est terminée.
Instances "basées sur EBS"
Une instance "basée sur EBS" est une instance EC2 qui utilise un volume EBS en tant que périphérique racine. Les volumes EBS sont des disques "virtuels" redondants, qui ne sont liés à aucun matériel particulier, mais ils sont limités à une zone de disponibilité EC2 particulière. Cela signifie qu'un volume EBS peut passer d'un matériel à un autre dans la même zone de disponibilité. Vous pouvez considérer les volumes EBS comme une sorte de stockage en réseau.
Si le matériel de la machine virtuelle échoue, le volume EBS peut simplement être déplacé vers une autre machine virtuelle et relancé. En théorie, vous ne perdrez aucune donnée.
Un autre avantage est que les volumes EBS peuvent facilement être sauvegardés et dupliqués. Vous pouvez ainsi prendre des instantanés de sauvegarde faciles de vos volumes, créer de nouveaux volumes et lancer de nouvelles instances EC2 basées sur ces volumes dupliqués.
Le principal avantage des instances "basées sur EBS" sur les instances "magasin d'instance" est qu'elles peuvent être arrêtées. Lorsque vous procédez ainsi, la machine virtuelle est arrêtée et le volume EBS est stocké pour une récupération ultérieure. Le matériel est alors disponible pour une autre personne. De plus, pendant ce temps, vous ne payez pas les frais de fonctionnement de l'instance EC2. Mais vous êtes facturé pour le stockage EBS. Lorsque vous souhaitez que l'instance soit à nouveau exécutée, il vous suffit de la redémarrer. Une nouvelle machine virtuelle est réservée, votre volume EBS est connecté et votre instance est démarrée.
Mais qu’en est-il des disques durs de la machine virtuelle?
Oui, il est possible d'utiliser ces disques durs, même lorsque votre instance EC2 est "basée sur EBS". Par défaut, ils ne sont pas disponibles. Si vous utilisez les programmes de ligne de commande pour lancer votre instance, vous pouvez utiliser l'option "-b" de la commande ec2-run-instances pour attacher les lecteurs "magasin d'instances" à votre instance EC2.
Avoir ces lecteurs disponibles peut être bénéfique si vous souhaitez stocker des données temporaires. L’accès en lecture et en écriture doit être plus rapide que la lecture et l’écriture sur un volume EBS, car vous n’envoyez pas de données sur le réseau. De plus, vous ne serez pas facturé pour le transfert ou le stockage de données. Mais cela ne fonctionne que si les données peuvent être perdues à tout moment.
Source: http://help.skeddly.com/Amazon-web-services/ebs-backed-versus-instance-store
J'ai eu exactement la même expérience qu'Eric à mon dernier poste. Maintenant, dans mon nouvel emploi, je suis en train de suivre le même processus que lors de mon dernier emploi: reconstruire tous leurs AMI pour des instances basées sur EBS - et éventuellement en tant que machines 32 bits (moins chères - mais ne peut pas utiliser le même AMI sur 32 et 32). 64 machines).
Les instances basées sur EBS se lancent assez rapidement pour que vous puissiez commencer à utiliser = Amazon AutoScaling API , qui vous permet d'utiliser les métriques CloudWatch pour déclencher le lancement d'instances supplémentaires et les enregistrer dans ELB (Elastic Load Balancer), et aussi de les fermer lorsqu'ils ne sont plus nécessaires.
AWS est ce type de mise à l'échelle automatique dynamique, où les économies réelles en infrastructure informatique peuvent jouer. Il est pratiquement impossible de réaliser une mise à l'échelle automatique correcte avec les anciennes instances s3 "InstanceStore".
Je commence tout juste à utiliser EC2 moi-même, donc pas un expert, mais la propre documentation d'Amazon dit:
nous vous recommandons d'utiliser le magasin d'instances local pour les données temporaires et, pour les données nécessitant un niveau de durabilité supérieur , nous vous recommandons d'utiliser des volumes Amazon EBS ou de les sauvegarder. les données à Amazon S3.
L'accent est à moi.
Je fais plus analyse de données que l'hébergement Web, la persistance n'a donc pas autant d'importance pour moi que pour un site Web. Compte tenu de la distinction faite par Amazon lui-même, je ne présumerais pas qu'EBS convient à tout le monde.
Je vais essayer de me rappeler de peser à nouveau après avoir utilisé les deux.
EBS est comme le disque virtuel d'une machine virtuelle:
- Des instances durables supportées par EBS peuvent être démarrées et arrêtées librement (économie d'argent)
- Peut être instantané à tout moment pour obtenir des sauvegardes à un moment donné
- Les AMI peuvent être créées à partir d'instantanés EBS. Ainsi, le volume EBS devient un modèle pour les nouveaux systèmes.
Le stockage d'instance est:
- Local, donc généralement plus rapide
- Normalement, les E/S EBS non-mises en réseau entraînent des coûts en bande passante réseau (à l'exception des instances optimisées pour EBS, qui ont une bande passante EBS distincte)
- A limité I/O par seconde IOPS. Même les E/S provisionnées atteignent quelques milliers d’IOPS
- Fragile. Dès que l'instance est arrêtée, vous perdez tout dans le stockage d'instance.
Voici où utiliser chacun:
- Utilisez EBS pour la partition du système d'exploitation et le stockage permanent (données de base de données, journaux critiques, configuration de l'application).
- Utilisez le stockage d'instance pour les données en cours de traitement, les journaux non critiques et l'état de l'application transitoire. Exemple: stockage de tri externe, fichiers temporaires, etc.
- Le stockage d'instance peut également être utilisé pour des données critiques en termes de performances, lorsqu'il existe une réplication entre instances (bases de données NoSQL, systèmes de messagerie/file d'attente distribués et bases de données avec réplication).
- Utilisez S3 pour les données partagées entre les systèmes: ensemble de données en entrée et résultats traités, ou pour les données statiques utilisées par chaque système lors de son lancement.
- Utiliser des AMI pour des serveurs préchauffés et lancables
La plupart des gens choisissent d'utiliser une instance basée sur EBS, car elle est avec état. C'est plus sûr car tout ce que vous avez en cours d'exécution et installé à l'intérieur survivra à un arrêt/arrêt ou à toute défaillance d'instance.
Le magasin d'instance est sans état, vous le perdez avec toutes les données qu'il contient en cas de défaillance de l'instance. Cependant, il est gratuit et plus rapide car le volume d'instance est lié au serveur physique sur lequel la VM est en cours d'exécution.
Pour quelqu'un de nouveau à tout cela et si atterri accidentellement ici
A présent, tous les AMI de la section quickstart sont pris en charge par EBS
Il y a aussi une bonne explication à document officiel pour la différence entre EBS et Instance magasin
& cette image le résume à peu près 
Si vous exécutez plusieurs instances et affectez un service planifié d'instance AWS comme l'une de vos priorités sur éviter les charges inattendues , je recommanderais de ne pas utiliser le magasin d'instance .
Comme expliqué dans la documentation de EBS Volumes et la réponse de j2d et Siddharth Sharma l'instance -store peut fonctionner aussi longtemps que vous le souhaitez, mais il ne peut pas être arrêté . Cela signifie que le service ne peut pas être planifié par un démarrage/arrêt automatique ou récupération d'instance .
De plus, pour ce type de schéma, il n’ya aucun avantage à utiliser EBS Backed sur Elastic Beanstalk car il est conçu pour garantir que toutes les ressources dont vous avez besoin sont continuer à courir . Il fera toujours un relance automatiquement tous les services que vous arrêtez. 
Examen tout le reste , sur le total des frais d'utilisation des VPC , EBS et ELB cela ajouté à EC2-Classic , le EC2-VPC avec ELB est principalement le meilleur choix où contrairement à EC2-Classic, une instance arrêtée conserve son associé adresses IP élastiques et le volume EBS est stocké automatiquement.
En conclusion , reprenant l'essentiel de votre question:
il semble qu'EBS soit beaucoup plus utile (arrêter, démarrer, persister + meilleure vitesse) à une différence de coût relativement faible ...?
La réponse est oui mais si votre instance est basée sur EBS, elle peut être arrêtée. Il restera sur votre compte, vous ne serez pas facturé . Vous ne facturerez que le volume mais EBS est facturé à l'heure . Vous pouvez également considérer que parmi tous types disponibles vous avez la possibilité de redimensionner le volume EBS .
Outre les avantages déjà énumérés par Eric , vous devez également savoir qu'en termes de coût S3 peut être ou ne pas être moins cher que EBS . Je conviens qu'il y a relativement peu de différence de coût si vous continuez à utiliser les deux types d'instance dans la même plate-forme et la même architecture de l'application tout le temps.
Toutefois, s’il existe un scénario pour exécuter l’application sur un service moins coûteux, affichez toutes les tâches non gérées et leur rôle dans le champ VPC)./EBS via un pipeline ou lambda dans un laps de temps court, dites <1 heure par jour, ce qui est impossible à faire lorsque vous utilisez un magasin d'instances , il s'agira alors d'un histoire différente.