Introduction

Ce cours Fondamentaux d'AWS est conçu pour vous enseigner les concepts de base dont vous avez besoin pour travailler efficacement dans AWS.

Au départ, la maîtrise d'AWS peut sembler insurmontable. Un paradigme cloud natif de construction d'infrastructures peut constituer un changement radical par rapport à l'informatique sur site. Peu importe que ce soit la première fois que vous travaillez avec une infrastructure ou que vous adaptiez les noyaux Linux depuis une dizaine d'années, il peut être difficile de savoir par où commencer face au choix de plus de 175 services proposés par AWS.

Le cours Fondamentaux d'AWS est conçu pour vous aider à prendre en main AWS, quelle que soit votre expérience. Dans ce cours, nous vous apprendrons les cinq piliers d'AWS, les modèles mentaux à utiliser dans le cadre de votre approche cloud, ainsi que les concepts clés qui seront applicables à tout service que vous finirez par utiliser.

 

Structure

Le cours Fondamentaux d'AWS sera divisé en cinq modules. Chaque module obéit au format suivant :

  • Introduction : brève description du pilier que nous allons étudier
  • Modèle mental : modèle mental directeur pour vous aider à comprendre les concepts introduits dans chaque pilier
  • Concepts : concepts clés couvrant les grands thèmes fondamentaux pour chaque pilier
  • Conclusion : résumé des thèmes abordés
  • Lectures complémentaires : liens et ressources supplémentaires
 

Les cinq piliers

Les cinq piliers abordés dans le cours Fondamentaux d'AWS font partie intégrante du Cadre AWS Well-Architected. Le Cadre Well-Architected est le fruit de plus d'une décennie d'expérience dans la création d'applications évolutives sur le cloud.

Les cinq piliers couvrent les domaines suivants :

  1. Sécurité
  2. Efficacité des performances
  3. Fiabilité
  4. Excellence opérationnelle
  5. Optimisation des coûts
 

Sécurité

Le pilier Sécurité concerne la manière de sécuriser votre infrastructure sur le cloud. La sécurité et la conformité constituent une responsabilité partagée entre AWS et le client. Dans ce modèle de responsabilité partagée, AWS est responsable de la sécurité du cloud. Cela comprend l'infrastructure physique, les logiciels et les capacités de mise en réseau des services AWS dans le cloud. Le client est responsable de la sécurité dans le cloud. Cela comprend la configuration de services cloud spécifiques, le logiciel d'application et la gestion des données sensibles.

Si vos charges de travail doivent respecter les exigences FedRAMP, DoD SRG, ITAR, CJIS ou d'autres exigences de conformité, ou si elles contiennent des données classifiées comme Controlled Unclassified Information (CUI), veuillez consulter la section AWS GovCloud (US) du cours.

 

Modèle mental

En matière de sécurité dans le cloud, il est utile d'adopter le modèle confiance zéro.

Dans ce modèle, tous les composants et services d'application sont considérés comme des entités distinctes potentiellement malveillantes. Cela concerne la structure du réseau sous-jacent, tous les agents qui ont accès à vos ressources, ainsi que les logiciels qui fonctionnent dans votre service.

 

Concepts

Envisager la sécurité en termes de confiance zéro consiste à devoir appliquer des mesures de sécurité à tous les niveaux du système. Voici trois concepts importants qui interviennent dans la sécurisation des systèmes avec une confiance zéro dans le cloud :

  1. Identity and Access Management (IAM)
  2. Sécurité du réseau
  3. Chiffrement des données

 

  • Identity and Access Management (IAM)

    Le service IAM est responsable du suivi des identités et des accès dans un système. Il est géré sur AWS par le service nommé à juste titre IAM. L'accès est géré à l'aide de politiques IAM qui imposent des limites d'accès aux agents dans AWS. La politique IAM comporte trois éléments fondamentaux :

    • Le MANDATAIRE précise à QUI les autorisations sont attribuées
    • L'ACTION précise CE QUI est exécuté
    • La RESSOURCE indique à QUELLES propriétés on accède

    Appliquer le modèle confiance zéro à IAM signifie adopter le principe de moindre privilège. Cela signifie que chaque agent ne doit avoir que les autorisations minimales nécessaires pour accomplir sa fonction.

    Une politique IAM peut être appliquée à un mandataire AWS ou à une ressource AWS. Les politiques qui sont associées à un mandataire sont connues sous le nom de politiques basées sur les identités. Les politiques qui sont associées à une ressource sont connues sous le nom de politiques basées sur les ressources. Notez que seuls certains services (par exemple S3, KMS, SES) possèdent des politiques basées sur les ressources.

    Le fait qu'un mandataire soit autorisé à effectuer une action pour une ressource particulière dépend du fait que la politique basée sur l'identité du mandataire lui permet de le faire et si la politique basée sur les ressources de la ressource (si elle existe) ne lui interdit pas de le faire.

    Notez qu'il s'agit d'une simplification majeure du modèle d'autorisation d'IAM. Il existe de nombreux autres types de politique qui déterminent l'attribution d'accès. Il peut s'agir de limites d'autorisation, de politiques de contrôle des services d'organisation, de listes de contrôle d'accès et de politiques de session. Ces types de politiques supplémentaires sortent du champ d'application du présent cours. La section Lectures complémentaires du présent module fournit plus de détails à leur sujet.

    Points clés

    • Les politiques IAM déclarent les limites d'accès pour les entités au sein d'AWS
    • Les politiques IAM se composent de MANDATAIRES, d'ACTIONS et de RESSOURCES
    • Les politiques IAM permettent de faire respecter le principe de moindre privilège
    • IAM possède un grand nombre de types de politiques : les politiques basées sur les identités et les politiques basées sur les identités en sont deux exemples
    • IAM évalue l'accès à partir de tous les types de politiques applicables à une ressource donnée
     

    Lectures complémentaires

  • Sécurité du réseau

    La sécurité des réseaux implique tout système, configuration ou processus qui protège l'accès et la convivialité du réseau et des ressources accessibles au réseau. AWS offre un large éventail de fonctionnalités de sécurisation de votre réseau, tant au niveau du réseau qu'au niveau des ressources.

    Une approche confiance zéro en matière de sécurité des réseaux implique une approche de défense approfondie qui applique des contrôles de sécurité à toutes les couches de votre réseau (par opposition à la seule couche la plus extérieure).

    Sécurité au niveau du réseau

    Amazon Virtual Private Cloud (VPC) constitue la primitive de niveau réseau fondamentale dans AWS. Il s'agit d'un réseau logique que vous définissez et dans lequel vous pouvez allouer des ressources.

    Voici quelques éléments composant le VPC :

    • Sous-réseaux : série d'adresses IP au sein de votre VPC
    • Tables de routage : ensemble de règles déterminant où le trafic est dirigé
    • Passerelle Internet : composant permettant la communication entre les instances de votre VPC et Internet

    Pour protéger le trafic dans votre VPC, vous pouvez diviser vos ressources en ressources publiques et en ressources internes. Pour réduire la surface d'attaque, vous pouvez utiliser un service proxy comme l'Équilibreur de charge d'application qui gère tout le trafic en réception ou à destination d'Internet. Tous les services internes, tels que les serveurs et les bases de données, peuvent alors être fournis dans des sous-réseaux internes qui sont coupés de l'accès public direct à l'internet.

    En plus des VPC, vous pouvez utiliser AWS Web Application Firewall (WAF) pour restreindre davantage le trafic sur votre réseau.

    Sécurité au niveau des ressources

    Les ressources AWS individuelles disposent également de contrôles de sécurité réseau que vous pouvez configurer. Le contrôle le plus courant est connu sous le nom de groupe de sécurité. Les groupes de sécurité sont des pare-feu virtuels que vous pouvez utiliser pour contrôler le trafic entrant et le trafic sortant de votre ressource. Utilisez des groupes de sécurité pour n'autoriser que le trafic provenant de ports spécifiques et de sources fiables vers votre instance. Vous pouvez joindre des groupes de sécurité à des ressources comme les instances EC2, les instances RDS et Lambda.

    Points clés

    • La sécurité des réseaux implique des mécanismes conçus pour sauvegarder l'accès et la convivialité du réseau et des ressources accessibles au réseau
    • Une approche confiance zéro en matière de sécurité du réseau implique la mise en place d'une défense approfondie à toutes les couches de votre réseau
    • Les VPC et les WAF vous permettent d'appliquer des mesures de sécurité au niveau du réseau
    • Les groupes de sécurité vous permettent d'appliquer des mesures de sécurité au niveau des ressources

    Lectures complémentaires

  • Chiffrement des données

    Le chiffrement des données est le processus qui consiste à coder les informations de manière à ce qu'elles soient inintelligibles pour n'importe quel tiers ne possédant pas la clé nécessaire pour déchiffrer les données.

    L'adoption d'un modèle confiance zéro pour les données signifie le chiffrement de nos données partout, tant en transit qu'au repos.

    Chiffrement en transit

    Le chiffrement en transit consiste à chiffrer les données lors de leur passage d'un système à l'autre. Tous les services de stockage et de base de données d'AWS fournissent des points de terminaison HTTPS qui prennent en charge le chiffrement des données en transit. AWS propose également des services de réseau qui peuvent aider à renforcer le chiffrement en transit pour vos propres services. Par exemple, vous pouvez utiliser l'Équilibreur de charge d'application (ALB) pour imposer une connexion HTTPS à vos points de terminaison.

    Chiffrement au repos

    Le chiffrement au repos consiste à chiffrer les données dans les systèmes. Tous les services de stockage et de base de données AWS prennent en charge le chiffrement au repos. Le chiffrement est activé par défaut pour la plupart de ces services. Le chiffrement de vos données n'entraîne pas de frais supplémentaires et a une faible incidence sur les performances.

    La plupart des services de stockage et de base de données s'intègrent également directement à Amazon Key Management Service (KMS). Il s'agit d'un service central de gestion des clés qui vous donne la possibilité de créer des clés CMK (Customer Managed Keys) pour chiffrer vos données.

    L'utilisation d'une clé CMK vous offre des fonctionnalités supplémentaires au-delà du chiffrement. Cela inclut la possibilité d'utiliser votre propre magasin de clés personnalisé, la possibilité de créer un suivi d'audit pour la ressource chiffrée par le biais d'intégrations avec AWS CloudTrail et la rotation automatique des clés.

    Points clés

    • Le chiffrement est le processus qui consiste à coder les informations de telle sorte que seules les parties possédant la clé appropriée puissent les déchiffrer
    • Sécuriser les données en les chiffrant en transit et au repos
    • Tous les services de stockage et de base de données sur AWS offrent un chiffrement au repos et en transit
    • Vous pouvez utiliser les services de mise en réseau AWS comme l'ALB afin de renforcer le chiffrement en transit pour vos propres services
    • Vous pouvez utiliser une clé CMK pour débloquer des fonctionnalités avancées comme la création de suivi d'audit, l'utilisation de vos propres clés personnalisées et la rotation automatique des clés

    Lectures complémentaires

    Caractéristiques

     

    Services

     

    Références

     

     

Conclusion

Ce module vous a présenté le pilier Sécurité d'AWS. Vous avez découvert le modèle mental de la confiance zéro. Vous vous êtes familiarisé avec IAM et le principe de moindre privilège. Vous vous êtes familiarisé avec la sécurité des réseaux AWS et le principe de défense approfondie. Vous vous êtes familiarisé avec le chiffrement des données et à son utilisation pour les données en transit qu'au repos.

 

Lectures complémentaires

Efficacité des performances

Le pilier Efficacité des performances se concentre sur votre mode de gestion des services efficace et évolutif dans le cloud. Si le cloud vous donne les moyens de gérer n'importe quel volume de trafic, il exige que vous choisissiez et configuriez vos services en tenant compte de l'échelle.

 

Modèle mental

En matière d'efficacité des performances dans le cloud, il est utile de considérer vos services comme des animaux d'élevage et non comme des animaux de compagnie.

Dans le modèle de fonctionnement sur site, les serveurs étaient coûteux et souvent déployés et configurés manuellement. Il pouvait s'écouler des semaines avant qu'un serveur soit effectivement livré et physiquement raccordé à votre centre de données. Cela explique pourquoi les serveurs étaient traités comme des animaux de compagnie : chacun d'eux était unique et nécessitait une maintenance soutenue et individualisée. Certains serveurs portaient même un nom.

Dans le cloud, les serveurs s'apparentent à des animaux d'élevage. Les serveurs sont des ressources de base qui peuvent être automatiquement mises en service en quelques secondes. Le fonctionnement du service ne repose pas sur un serveur unique.

 

Concepts

Cette approche innovante procure de nombreux avantages liés aux performances. Dans le « modèle animal de compagnie » de gestion des serveurs, il est assez courant d'utiliser le même type de serveur (ou même le même serveur) pour plusieurs charges de travail, car il était trop compliqué de commander et de configurer des ordinateurs différents. Dans le « modèle élevage », la mise en service est bon marché et rapide, ce qui nous donne la liberté de choisir le type de serveur qui correspond le mieux à notre charge de travail.

Le « modèle élevage » nous permet aussi de dimensionner aisément notre service. Comme chaque serveur est interchangeable et rapide à déployer, nous pouvons rapidement augmenter notre capacité en ajoutant d'autres serveurs.

Nous étudierons les deux concepts suivants pour l'efficacité des performances :

  1. Sélection
  2. Dimensionnement
 
  • Sélection

    Sur AWS, la sélection permet de choisir le service qui correspond le mieux à votre charge de travail. AWS possède la plus vaste sélection de services, avec plus de 175 services répartis dans plus d'une vingtaine de catégories. Sélectionner des services dans l'optique d'atteindre des performances optimales signifie être capable de choisir l'outil approprié pour la tâche.

    La gestion d'une charge de travail typique requiert généralement la sélection de services parmi les quatre principales catégories de services dans AWS : Calcul, Stockage, Base de données et Réseau.

    • Calcul concerne le service qui traitera vos données (par exemple, une machine virtuelle)
    • Stockage concerne le stockage statique des données (par exemple, le stockage d'objets)
    • Base de données concerne le stockage organisé des données (p. ex., une base de données relationnelle)
    • Réseau concerne la façon dont vos données se déplacent (p. ex., un réseau de distribution de contenu)

    Dans ce module, nous allons étudier la sélection appropriée d'éléments dans les trois premières catégories. Veuillez vous référer à la section Lectures complémentaires sur les différentes façons de choisir les options de mise en réseau.

    Quelle que soit la catégorie de services que vous choisissez, vous devez prendre en compte trois facteurs.

    1. Type de service
    2. Degré de gestion
    3. Configuration

    Type de service

    Lorsque vous effectuez une sélection dans une catégorie, AWS vous propose de nombreuses options pour le type de service que vous pouvez utiliser. Le type est spécifique à chaque catégorie.

    Lorsque vous sélectionnez un service Calcul, décidez si vous voulez que le calcul soit basé sur une machine virtuelle, un conteneur ou un serveur.

    • Le calcul basé sur une machine virtuelle est associé au modèle mental le plus familier pour la plupart des gens mais il peut être plus coûteux et nécessiter plus de maintenance
    • Le calcul basé sur un conteneur permet une répartition plus fine de votre charge de travail et peut s'adapter rapidement, mais il s'accompagne d'une configuration et d'une orchestration plus complexes
    • Le calcul sans serveur permet d'éliminer la plupart des complexités de gestion et de dimensionnement, mais il présente des limites importantes et nécessite l'adoption de nouvelles chaînes d'outils et de nouveaux processus

    Lorsque vous sélectionnez un service Stockage, décidez si vous avez besoin d'un stockage de fichiers, d'un stockage par blocs, d'un stockage d'objets ou d'un stockage d'archives.

    • Les services de stockage par bloc comme EBS sont bien adaptés pour les données persistantes d'une même instance EC2
    • Les systèmes de fichiers tels que EFS permettent à plusieurs clients d'accéder aux mêmes données
    • Les magasins d'objets comme S3 sont parfaits pour les gros blocs de données qui doivent être accessibles à un nombre illimité de clients
    • Le stockage d'archives comme S3 Glacier est idéal pour les grandes quantités de données qui doivent être consultées peu fréquemment

    Lorsque vous sélectionnez un service Base de données, décidez si vous avez besoin d'une base de données relationnelle, d'une base de données non relationnelle, d'une solution d'entrepôt de données ou d'une solution d'indexation et de recherche de données.

    • Les bases de données relationnelles permettent de disposer de jointures et de propriétés ACID mais ont une limite supérieure de performance et de stockage des données
    • Les bases de données non relationnelles ont des schémas plus souples et peuvent atteindre des limites beaucoup plus élevées que leurs homologues relationnelles, mais elles ne disposent généralement pas de jointures et de capacités ACID complètes
    • Les solutions d'entrepôt de données autorisent l'analytique à grande échelle grâce à l'accès rapide à des pétaoctets de données structurées
    • Les solutions d'indexation et de recherche de données vous permettent d'indexer et de rechercher des données provenant d'un large éventail de sources
     

    Degré de gestion

    Après avoir choisi un type de service, vous devez vous limiter à un service spécifique - AWS propose parfois plusieurs offres pour des types de services spécifiques. La principale différence entre les différents services AWS du même type réside dans leur degré de gestion.

    Lorsque vous utilisez les services Calcul et choisissez le type de machine virtuelle, vous avez le choix entre EC2, Lightsail et Elastic Beanstalk. L'utilisation directe d'EC2 vous donne un contrôle maximale avec une gestion minimale alors que le choix de Lightsail implique une certaine personnalisation dans un cadre de gestion moins automatisé. Elastic Beanstalk se situe quelque part entre les deux : il vous offre un cadre de travail pour votre architecture de services mais vous permet de le personnaliser grâce à la configuration.

    Lorsque vous utilisez les services Stockage, la sélection d'un service est plus facile car il n'y a souvent qu'un service pour un type donné (par exemple, S3 pour le magasin d'objets, EFS pour le magasin de fichiers).

    Lorsque vous utilisez les services Base de données et optez pour le type relationnel, vous avez le choix entre RDS et Aurora. RDS vous donne plus de contrôle sur la base de données sous-jacente et il est disponible pour la plupart des bases de données relationnelles. Aurora ne fonctionne qu'avec certaines versions de MySQL et PostgreSQL, mais gère le stockage sous-jacent et dispose d'un support intégré de clustering.

    En fin de compte, le choix d'un service spécifique dépend largement de votre connaissance de la technologie sous-jacente et de votre préférence pour une expérience plus ou moins gérée.

     

    Configuration

    Après avoir choisi un service, vous devrez décider de la manière dont vous voulez le configurer. La configuration dépend des caractéristiques de performance spécifiques que vous souhaitez obtenir, lesquelles diffèrent pour chaque catégorie de service.

    Lors de l'évaluation des caractéristiques de performance des services Calcul, il est judicieux de commencer à examiner vos besoins en matière de mémoire et de calcul :

    • Si vous choisissez le calcul basé sur une machine virtuelle, la mémoire et le CPU sont affectés par la taille de votre instance (par exemple, t3.small par rapport à t3.xlarge) et la famille d'instance (par exemple, r3.small par rapport à c5.small)
    • Si vous choisissez le calcul basé sur des conteneurs, la mémoire et le CPU peuvent être réglés individuellement
    • Si vous utilisez le calcul sans serveur, seule la mémoire peut être réglée directement - la valeur du calcul (ainsi que d'autres ressources du système) augmente de façon linéaire en fonction de la quantité de mémoire disponible

    Notez qu'en fonction de votre charge de travail, certaines contraintes de ressources supplémentaires peuvent vous intéresser, comme la capacité du réseau et la disponibilité de certaines ressources telles que Stockage d'instance.

    Lors de l'évaluation de la caractéristique de performances des services Stockage, tenez compte de la latence, du débit et des exigences de votre environnement en matière d'IOPS :

    • Si vous utilisez un service de stockage par bloc
      • La latence est affectée par le choix du type de volume (p. ex., lecteur SSD ou disque dur)
      • Le débit est proportionnel à la taille du volume pour la plupart des types de volume
      • La capacité d'IOPS est proportionnelle à la taille du volume pour la plupart des types de volume
    • Si vous utilisez un service de système de fichiers
      • La latence et IOPS sont affectés par votre sélection des modes de performances
      • Le débit est affecté par votre choix d'utiliser le débit alloué
    • Si vous utilisez un stockage d'objets
      • La latence est affectée par la distance géographique du point de terminaison du compartiment
      • Le débit est affecté par l'utilisation d'API optimisées, comme le téléchargement partitionné
      • IOPS n'est pas configurable
    • Si vous utilisez un magasin d'archives
      • La latence est affectée par la distance géographique du point de terminaison du compartiment et par le choix de la méthode de récupération
      • Le débit est affecté par l'utilisation d'API optimisées, comme le téléchargement partitionné
      • IOPS n'est pas configurable

    Lors de l'évaluation de la caractéristique de performance pour les services Base de données, il est nécessaire de tenir compte des exigences de ressources (p. ex., processeur, mémoire, stockage, etc.) :

    • Si vous utilisez une base de données relationnelle
      • Les capacités des ressources sont déterminées par votre choix d'instance EC2
    • Si vous utilisez une base de données non relationnelle telle que DynamoDB
      • Les capacités des ressources sont déterminées par des options de configuration telles que la capacité provisionnée
    • Si vous utilisez une solution d'entrepôt de données telle que Redshift
      • Les capacités des ressources sont déterminées par votre choix d'instance EC2 sous-jacente
    • Si vous utilisez une solution d'indexation telle que Elasticsearch Service
      • Les capacités des ressources sont déterminées par votre choix d'instance EC2

     

    Points clés

    • AWS propose de nombreux services et de nombreuses façons d'atteindre vos objectifs
    • L'implémentation d'une charge de travail sur AWS implique la sélection de services dans les catégories calcul, stockage, base de données et réseau
    • Dans chaque catégorie, vous pouvez sélectionner le type de service approprié en fonction de votre cas d'utilisation
    • Dans chaque type, vous pouvez sélectionner le service spécifique en fonction du degré de gestion que vous souhaitez
    • Au sein de chaque service, vous pouvez sélectionner la configuration spécifique en fonction des caractéristiques de performances que vous souhaitez obtenir
     

    Lectures complémentaires

  • Dimensionnement

    Le choix du service approprié est certes essentiel au démarrage, mais le choix de son dimensionnement est également important pour bénéficier d'un niveau cohérent de performances.

    AWS dispose de deux principaux moyens de dimensonnement :

    1. Dimensionnement vertical
    2. Dimensionnement horizontal


    Dimensionnement vertical

    Le dimensionnement vertical implique la mise à niveau de votre calcul sous-jacent vers un type d'instance plus important. Par exemple, supposons que vous exécutiez une instance t3.small. Le dimensionnement vertical peut faire passer cette instance au niveau t3.large.

    Le dimensionnement vertical est généralement plus facile à mettre en œuvre car vous pouvez le faire sans avoir à mettre votre service en cluster. L'inconvénient est que vous vous heurtez à une limite supérieure beaucoup plus basse (égale à la taille maximale de votre instance de calcul) à celle du dimensionnement horizontal. Il constitue également un point de défaillance unique, car une perturbation de votre instance peut entraîner l'indisponibilité totale de votre service.

     

    Dimensionnement horizontal

    Le dimensionnement horizontal consiste à augmenter le nombre d'instances sous-jacentes. Par exemple, supposons que vous exécutiez une instance t3.small. Dimensionner horizontalement cette instance impliquerait de fournir deux instances t3.small supplémentaires.

    Le dimensionnement horizontal implique davantage de frais d'implémentation. En effet, vous avez besoin d'un service proxy pour acheminer le trafic vers votre environnement de services. Vous devez également effectuer des contrôles d'intégrité pour retirer les instances de mauvaise qualité du pool de routage et choisir un algorithme de routage spécifique qui soit optimal pour votre charge de travail. Votre service devient ainsi plus résilient et capable de s'adapter à des limites bien plus élevées que son homologue dimensionné verticalement.


    Points clés

    • Le dimensionnement vertical est plus simple sur le plan opérationnel mais il offre des limites inférieures et représente un risque de disponibilité
    • Le dimensionnement horizontal est plus onéreux mais s'accompagne d'une fiabilité bien meilleure et de limites bien plus élevées
     

    Lectures complémentaires

Conclusion

Dans ce module, vous avez découvert le pilier Efficacité des performances d'AWS. Vous avez découvert le modèle mental consistant à traiter vos serveurs plus comme des animaux d'élevage que comme des animaux de compagnie. Vous avez appris à choisir le bon service ainsi que sa configuration en fonction de vos objectifs de performance. Vous avez découvert ce qu'est le dimensionnement des services et les compromis entre le dimensionnement vertical et le dimensionnement horizontal.

 

Lectures complémentaires

Fiabilité

Le pilier Fiabilité concerne la manière dont vous pouvez mettre en place des services qui résistent aux interruptions de service et d'infrastructure. Tout comme pour l'efficacité des performances, si le cloud vous donne les moyens de créer des services résilients capables de résister aux perturbations, il exige que vous structuriez vos services dans un souci de fiabilité.


Modèle mental

La fiabilité des objets dans le cloud s'envisage en termes de rayon d'explosion. Le rayon d'explosion peut être considéré comme l'impact maximal qui pourrait être subi en cas de défaillance du système. Pour construire des systèmes fiables, il est nécessaire de réduire au minimum le rayon d'explosion de chaque composant individuel.

 

Concepts

En matière de rayon d'explosion, l'approche n'est plus de considérer l'éventualité d'une panne mais les mesures qui seront prises quand une panne se produira. Pour faire face à une défaillance lorsqu'elle se produit, les techniques suivantes permettent de limiter le rayon de l'explosion :

  1. Isolement des pannes
  2. Limites


  • Isolement des pannes

    L'isolement des pannes limite le rayon d'explosion d'un incident en utilisant des composants indépendants redondants séparés par des zones d'isolement des pannes. Une zone d'isolement confine les pannes à l'intérieur de ses limites.

    AWS dispose de zones d'isolement des pannes à trois niveaux :

    1. Ressources et demandes
    2. Zone de disponibilité
    3. Région

     

    Ressources et demandes

    Les services AWS répartissent toutes les ressources et demandes sur une dimension donnée comme l'ID de la ressource. Ces partitions sont appelées cellules. Les cellules sont conçues pour être indépendantes les unes des autres et contenir les pannes en elles. En arrière-plan, AWS utilise des techniques comme le partitionnement aléatoire pour limiter le rayon de l'explosion. Tout cela se passe de manière transparente chaque fois que vous faites une demande ou créez une ressource. Aucune action supplémentaire de votre part n'est requise.


    Zone de disponibilité

    Une zone de disponibilité AWS est une installation complètement indépendante avec des capacités dédiées en termes d'alimentation, de service et de réseau. Chaque zone de disponibilité est géographiquement éloignée des autres zones de disponibilité afin d'éviter les pannes liées aux risques environnementaux tels que les incendies et les inondations.

    L'isolement des pannes est réalisé au niveau de la zone de disponibilité en déployant des instances redondantes de votre service dans plusieurs zones de disponibilité. Cela signifie qu'une panne électrique se produisant dans une zone de disponibilité n'aura pas d'incidence sur votre trafic dans une autre zone de disponibilité.

    Remarque sur la latence : bien qu'elles soient géographiquement séparées, les zones de disponibilité sont suffisamment proches les unes des autres pour que la latence du réseau entre elles soit minimale. Cela permet à certaines fonctionnalités, comme la réplication synchrone des données, de fonctionner entre les zones de disponibilité.


    Région

    Une région AWS offre un isolement ultime. Chaque région est un centre de données complètement autonome, composé de deux zones de disponibilité ou plus. L'isolement des pannes s'exerce au niveau régional en déployant des copies redondantes de vos services dans des régions AWS différentes (c'est exactement ce que fait AWS avec ses propres services).

    Si vous avez besoin de niveaux de disponibilité très élevés, vous pouvez envisager un déploiement dans plusieurs régions. Il est à noter que l'exploitation d'un service dans plusieurs régions entraîne des frais de gestion importants en raison de l'absence d'infrastructure partagée entre les régions. Certains services et fonctionnalités peuvent vous aider à développer des projets multi-régions. Par exemple, vous pouvez utiliser Route53, le service DNS scalable d'AWS, pour acheminer le trafic entre régions différentes. Vous pouvez également utiliser des fonctionnalités telles que DynamoDB Global Tables et la réplication entre régions S3 pour répliquer vos données dans des régions différentes.


    Points clés

    • Utiliser des zones d'isolement des pannes pour limiter le rayon d'explosion des perturbations de service ou d'infrastructure
    • L'isolement des pannes au niveau des ressources et des demandes est intégré à la conception de chaque service AWS - cela ne nécessite aucune action supplémentaire de votre part
    • L'isolement des pannes au niveau des zones de disponibilité est réalisé en déployant vos services dans plusieurs zones de disponibilité avec un impact minimal sur la latence
    • L'isolement des pannes au niveau régional est réalisé en déployant vos services dans plusieurs régions, ce qui induit des frais d'exploitation importants


    Lectures complémentaires

  • Limites

    Les limites sont des contraintes qui peuvent être appliquées pour protéger vos services contre une charge excessive. Elles constituent un moyen efficace de limiter le rayon d'explosion tant au niveau externe (p. ex., une attaque par déni de service ) qu'interne (p. ex., une configuration inadéquate des logiciels).

    Les services AWS sont soumis à des limites spécifiques par compte et par région. Ces limites sont également connues sous le nom de Service Quotas. Il s'agit de valeurs maximales pour des ressources, actions et éléments spécifiques de votre compte AWS.

    Il existe deux types de limites :

    • les limites logicielles qui peuvent être augmentées sur demande adressée à AWS
    • les limites matérielles qui ne peuvent être augmentées

    Chaque service a des limites différentes. Pour suivre vos limites et demander des augmentations, vous pouvez utiliser le service Service Quotas.

    Il est important de surveiller les limites de service et de savoir à quel moment votre limite de service est sur le point d'être atteinte afin d'éviter toute interruption de service. Pour certaines ressources, comme les exécutions Lambda simultanées, il est possible d'effectuer le suivi via CloudWatch. D'autres ressources, comme le nombre d'instances EC2, doivent être suivies manuellement ou à l'aide de scripts. Vous pouvez utiliser le service AWS Trusted Advisor pour suivre vos limites si vous avez un plan Business Support ou Enterprise Support. Des outils open source comme awslimitchecker permettent également d'automatiser le processus.


    Points clés

    • Les limites sont des contraintes qui peuvent être appliquées pour protéger un service contre une charge excessive
    • Les limites de services AWS peuvent être suivies et gérées en utilisant le service Quota de service
    • À la différence des limites matérielles, les limites logicielles peuvent être augmentées
    • Surveillez les limites des services que vous utilisez et planifiez vos augmentations de limites en conséquence pour éviter toute interruption de service


    Lectures complémentaires

Conclusion

Ce module vous a présenté le pilier Fiabilité d'AWS. Vous vous êtes familiarisé avec le modèle mental qui consiste à considérer l'impact d'une panne comme un rayon d'explosion. Vous vous êtes familiarisé avec l'utilisation des zones d'isolement des pannes afin de contenir le rayon d'explosion. Vous vous êtes familiarisé avec les limites de service et l'augmentation des vôtres afin d'éviter toute interruption de service.

 

Lectures complémentaires

Excellence opérationnelle

Le pilier Excellence opérationnelle concerne la manière dont vous pouvez améliorer en permanence votre capacité à faire fonctionner les systèmes, à créer de meilleures procédures et à acquérir des connaissances.


Modèle mental

L'excellence opérationnelle dans le cloud est rendue possible par l'automatisation des processus.

L'erreur humaine est la cause principale des défauts et des incidents opérationnels. Plus les opérations peuvent être automatisées, plus le risque d'erreur humaine est faible.

En plus de prévenir les erreurs, l'automatisation vous aide à améliorer continuellement vos processus internes. Elle encourage l'utilisation d'un ensemble de bonnes pratiques reproductibles qui peuvent être appliquées dans toute votre organisation.


Concepts

Lorsque vous envisagez d'automatiser les opérations, vous concentrez vos efforts dans les domaines qui exigent actuellement le plus de travail manuel et dont les erreurs pourraient avoir des conséquences graves sur votre entreprise. Dans ce cas, vous souhaitez également mettre en place un processus pour suivre, analyser et améliorer vos efforts opérationnels.

Nous étudierons les deux concepts suivants liés à l'excellence opérationnelle :

  1. Infrastructure en tant que code
  2. Observabilité


  • Infrastructure en tant que code

    L'Infrastructure en tant que code (IaC) est le processus de gestion de votre infrastructure au moyen de fichiers de configuration lisibles par un ordinateur. IaC sert de base à l'automatisation de votre infrastructure.

    Au lieu de fournir manuellement des services, vous créez des modèles qui décrivent les ressources souhaitées. La plateforme IaC se charge ensuite d'allouer et de configurer les ressources en votre nom.

    IaC vous offre un moyen déclaratif et automatisé de mettre en service l'infrastructure. Cela vous permet d'appliquer à votre infrastructure les mêmes outils (p. ex., git) et les mêmes processus (p. ex., révision de code) qu'à votre code.

    IaC sur AWS a traditionnellement été implémenté à l'aide du service CloudFormation. CloudFormation nécessite de déclarer vos ressources à l'aide de JSON ou de YAML. Si vous n'aimez pas ces langages de configuration, AWS fournit également le Cloud Development Kit (CDK) qui vous permet de créer des modèles CloudFormation à l'aide de programmation natifs comme JavaScript, Python et Java.

     

    Points clés

    • IaC est le processus de gestion de votre infrastructure au moyen de fichiers de configuration lisibles par un ordinateur
    • IaC est un moyen déclaratif et automatisé de mettre en service l'infrastructure
    • Vous pouvez appliquer les mêmes outils et processus à votre infrastructure qu'à votre code
    • Utiliser des services tels que CloudFormation et CDK pour mettre en œuvre IaC sur AWS
     

    Lectures complémentaires

  • Observabilité

    L'observabilité est le processus qui consiste à mesurer l'état interne de votre système. Cela passe par l'optimisation du système jusqu'à un certain état final souhaité.

    Lorsqu'il s'agit d'excellence opérationnelle, il n'est pas possible d'améliorer ce qui n'est pas mesuré. La création d'une base d'observabilité solide vous donne la possibilité de suivre l'impact de votre automatisation et de l'améliorer en permanence.

    L'implémentation de l'observabilité implique les étapes suivantes :

    1. Collecte
    2. Analytique
    3. Action


    Collecte

    La collecte est le processus d'agrégation de tous les paramètres nécessaires à l'évaluation de l'état de votre système.

    Ces mesures peuvent être classées dans les catégories suivantes :

    • Mesures au niveau de l'infrastructure
      • Ces mesures sont émises automatiquement par les services AWS et collectées par le service CloudWatch
      • Certains services émettent également des journaux structurés qui peuvent être activés et collectés via CloudWatch Logs
    • Mesures au niveau de l'application
      • Ces mesures sont générées par votre logiciel et peuvent être collectées par CloudWatch Custom Metrics
      • Les journaux des logiciels peuvent être stockés à l'aide de CloudWatch Logs ou téléchargés sur S3
    • Mesures au niveau du compte
      • Ces mesures sont enregistrées par votre compte AWS et peuvent être collectées par le service CloudTrail


    Analytique

    Pour analyser les données collectées, vous pouvez utiliser l'une des nombreuses solutions de base de données et d'analytique fournies par AWS.

    Le choix de la solution adéquate dépend de votre cas d'utilisation :

    • Pour analyser les journaux stockés dans CloudWatch Logs, vous pouvez utiliser CloudWatch Logs Insight, un service qui vous permet de rechercher et d'analyser de manière interactive les données de vos journaux Cloudwatch
    • Pour analyser les journaux stockés dans S3, utilisez Athena, un service d'interrogation sans serveur
    • Pour analyser les données de structure, utilisez RDS, un service de base de données relationnelle géré
    • Pour analyser de grandes quantités de données structurées, utilisez RedShift, un service d'entrepôt de données géré à l'échelle du pétaoctet
    • Pour analyser les données basées sur les journaux, Elasticsearch Service est une version gérée d'Elasticsearch, le célèbre moteur d'analytique open-source

     

    Action

    Après avoir collecté et analysé vos données, vous pouvez les utiliser pour atteindre un résultat ou un processus particulier.

    Voici des exemples de résultats et de processus :

    • Surveillance et alarmes
      • Vous pouvez utiliser CloudWatch Alarms pour vous avertir lorsqu'un système a dépassé le seuil de sécurité pour une mesure particulière
      • Cette alarme peut déclencher une atténuation manuelle ou automatique.
    • Tableaux de bord
      • Vous pouvez créer des tableaux de bord de vos mesures en utilisant Cloudwatch Dashboards
      • Vous pouvez utiliser ces tableaux de bord pour suivre et améliorer les performances des services au fil du temps
    • Décisions guidées par les données
      • Vous pouvez suivre les performances et les KPI de l'entreprise pour prendre des décisions sur les produits en fonction des données

     

    Points clés

    • L'observabilité est le processus qui consiste à mesurer l'état interne de votre système pour atteindre un état final souhaité
    • L'observabilité consiste à collecter et analyser des mesures et à agir sur elles
    • Vous pouvez collecter des données au niveau du service, de l'application et du compte
    • Vous pouvez analyser les mesures grâce à des services comme CloudWatch Log Insight, Athena, Elasticsearch Service, RDS et Redshift
    • Vous pouvez agir sur vos mesures en créant des contrôles, des alarmes et des tableaux de bord et en suivant les performances et les KPI de l'entreprise

     

    Lectures complémentaires

Conclusion

Dans ce module, vous avez découvert le pilier Excellence opérationnelle. Vous vous êtes familiarisé avec le modèle mental qui consiste à intégrer les opérations dans un processus automatique. Vous avez découvert l'Infrastructure en tant que code et la façon dont elle peut automatiser vos services à l'aide des outils et processus que vous utilisez déjà pour le code. Vous vous êtes familiarisé avec le concept d'observabilité, la collecte et l'analyse des mesures et l'action sur celles-ci afin d'améliorer continuellement vos efforts opérationnels.

 

Lectures complémentaires

Optimisation des coûts

Le pilier Optimisation des coûts vous aide à obtenir des résultats pour votre entreprise tout en minimisant les coûts.


Modèle mental

Concernant l'optimisation des coûts dans le cloud, il est judicieux d'envisager les dépenses en termes d'OpEx plutôt que de CapEx. L'OpEx est un modèle de paiement à l'utilisation, tandis que le CapEx est un modèle d'achat unique.

Les coûts informatiques traditionnels des centres de données sur site étaient essentiellement des dépenses CapEx. Vous payez d'avance toute la capacité, que vous l'utilisiez en totalité ou pas. L'achat de nouveaux serveurs peut être un long processus qui implique l'approbation de plusieurs parties. Cela s'explique par le fait que les coûts CapEx étaient souvent importants et les erreurs coûteuses. Une fois que vous aviez effectué un achat, les serveurs physiques pouvaient être livrés des semaines après.

Dans AWS, vos coûts sont des dépenses OpEx. Le paiement est basé sur la capacité que vous utilisez. La mise en service de nouveaux serveurs peut être effectuée en temps réel par l'ingénierie sans qu'il soit nécessaire de recourir à un long processus d'approbation. En effet, les coûts OpEx sont beaucoup plus faibles et peuvent être annulés en cas de changement d'exigences. Comme vous ne payez que ce que vous utilisez, toute capacité excédentaire peut simplement être arrêtée et supprimée. Lorsque vous décidez d'utiliser un service, la mise en service ne prend que quelques secondes ou quelques minutes.


Concepts

Le passage d'un modèle CapEx à un modèle OpEx change fondamentalement votre approche du calcul des coûts de votre infrastructure. Au lieu de coûts fixes initiaux importants, vous effectuez de petites dépenses variables en continu.

Ce modèle de paiement à l'utilisation introduit les changements suivants dans votre processus d'optimisation des coûts :

  1. Paiement à l'utilisation
  2. Cycle de vie de l'optimisation des coûts


  • Paiement à l'utilisation

    Les services AWS s'appuient sur un modèle de paiement à l'utilisation dans lequel vous ne payez que la capacité que vous utilisez. Voici quatre façons courantes d'optimiser vos dépenses liées au cloud lorsque vous effectuez un paiement à l'utilisation :

    1. Dimensionnement approprié
    2. Sans serveur
    3. Réservations
    4. Instances Spot


    Dimensionnement approprié

    Le dimensionnement approprié consiste à adapter le provisionnement et la configuration des services à votre charge de travail. Pour les services basés sur EC2, cela signifie choisir la taille et la famille d'instance appropriée. Si vos ressources de calcul sont pour la plupart inutilisées, vous pouvez envisager d'utiliser une instance EC2 plus petite. Si votre charge de travail nécessite une grande quantité de ressources système spécifiques, vous pouvez envisager de passer à une famille d'instance optimisée pour cette ressource.

    Pour vous aider dans ce processus, vous pouvez utiliser AWS Compute Optimizer afin d'obtenir des suggestions de dimensionnement EC2 optimal basées sur les mesures passées du système.


    Sans serveur

    Lorsque vous utilisez des technologies sans serveur comme Lambda, vous ne payez que ce que vous utilisez. Si votre technologie Lambda ne s'exécute pas, vous n'avez pas de frais d'utilisation. La technologie sans serveur est l'exemple ultime du paiement à l'utilisation. Lorsque votre cas d'utilisation le permet, le choix du sans serveur peut être le moyen le plus rentable de construire votre service.


    Réservations

    Demander des réservations signifie s'engager à payer une certaine quantité de capacité en échange d'une remise importante. Pour EC2, cela peut se traduire par une réduction de 72 % de vos capacités de calculs.

    Savings Plans vous permet d'effectuer des réservations de capacités de calcul. Vous pouvez vous inscrire pour une durée de 1 ou 3 ans et vous engager à utiliser un montant spécifique de capacités de calcul pour effectuer des économies sur EC2, Fargate et Lambda.

    Notez que les réservations ne sont pas spécifiques à EC2, car vous pouvez également demander d'autres services comme RDS, DynamoDB et CloudFront.


    Instances Spot

    Les Instances Spot EC2 vous permettent de bénéficier de la capacité d'EC2 inutilisée pour exécuter des instances avec une réduction allant jusqu'à 90 % par rapport aux prix à la demande. Cela peut vous permettre de réaliser des économies importantes sur vos charges de travail à tolérance de pannes.

    L'utilisation d'une instance Spot permet à EC2 de récupérer la capacité à tout moment. Votre application reçoit alors un avertissement deux minutes avant l'interruption.


    Points clés

    • Les services AWS sont payants - vous êtes facturé en fonction de la capacité que vous utilisez
    • Vous pouvez adapter la taille de vos instances pour effectuer des économies sur les services qui ne correspondent pas à votre charge de travail
    • Vous pouvez utiliser des technologies sans serveur pour être certain de payer uniquement lorsque les clients utilisent votre service
    • Vous pouvez utiliser les réservations pour obtenir des réductions en échange d'un engagement préalable
    • Vous pouvez utiliser des instances Spot pour obtenir des réductions en cas d'exécution de charges de travail tolérantes aux pannes


    Lectures complémentaires

  • Cycle de vie de l'optimisation des coûts

    Le cycle de vie de l'optimisation des coûts est le processus continu d'amélioration de vos dépenses dans le cloud au fil du temps.

    Il comporte le flux de travail en trois étapes suivant :

    1. Examen
    2. Suivi
    3. Optimisation


    Examen

    Avant de pouvoir optimiser vos dépenses dans le cloud, vous devez d'abord comprendre leur origine.

    AWS Cost Explorer vous aide à visualiser et à examiner vos dépenses dans le cloud au fil du temps. Vous pouvez répartir les dépenses entre des facettes différentes comme le service et la catégorie. Cost Explorer vous permet d'obtenir une vue d'ensemble de haut niveau ainsi que des rapports détaillés sur votre facture.

    Si vous avez besoin de données plus précises, vous pouvez obtenir des postes horaires dans le Rapport sur les coûts et l'utilisation d'AWS.


    Suivi

    Une fois que vous avez une vue d'ensemble de vos dépenses globales dans le cloud, vous pouvez commencer à les regrouper selon les dimensions qui vous intéressent. Les balises de répartition des coûts sont conçues à cet effet. Il est nécessaire d'activer les coûts pour chaque étiquette que vous souhaitez suivre.

    Voici des exemples courants de catégories de balises :

    • ID d'application - Identifie les ressources liées à une application spécifique pour faciliter le suivi de l'évolution des dépenses et de son arrêt à la fin des projets.
    • Activation/désactivation de l'automatisation - Indique si une ressource doit être incluse dans une activité automatisée telle que le démarrage, l'arrêt ou le redimensionnement d'instances.
    • Centre de coûts/unité opérationnelle - Identifie le centre de coûts ou l'unité opérationnelle qui est associé à une ressource, généralement pour l'allocation et le suivi des coûts.
    • Propriétaire - Identifie la personne responsable de la ressource. Il s'agit généralement du propriétaire technique. Si nécessaire, vous pouvez ajouter une balise distincte pour le propriétaire de l'entreprise. Vous pouvez indiquer l'adresse e-mail de celui-ci. L'utilisation d'une adresse e-mail permet d'envoyer des notifications automatisées aux responsables techniques et commerciaux selon les besoins (par exemple, si la ressource est candidate à l'élasticité ou au dimensionnement approprié).

    En plus des balises, vous pouvez utiliser Budgets AWS pour créer des objectifs budgétaires. Grâce à Budgets, vous pouvez suivre vos dépenses dans les domaines qui vous intéressent. Budgets suit et crée des prévisions pour vos dépenses AWS actuelles en fonction des filtres que vous avez mis en place.


    Optimisation

    Après avoir examiné et suivi vos dépenses, vous pouvez les optimiser. L'optimisation de vos dépenses implique la mise en œuvre des techniques que nous avons évoquées dans Paiement à l'utilisation. Cette optimisation est généralement réalisée dans le cadre d'un objectif budgétaire global.

    Voici des exemples d'objectifs d'optimisation :

    • Pourcentage d'instances EC2 couvertes par un Cost Savings Plan : votre organisation doit couvrir 80 à 90 % des instances
    • Pourcentage de ressources inutilisées : la définition des ressources inutilisées et le pourcentage exact varient selon votre entreprise


    Points clés

    • Le cycle de vie de l'optimisation des coûts est un processus continu d'amélioration de vos dépenses dans le cloud au fil du temps
    • Le cycle de vie de l'optimisation des coûts consiste à examiner, suivre et optimiser vos dépenses
    • L'examen de vos dépenses implique l'utilisation d'outils tels que Cost Explorer et le rapport sur les coûts et l'utilisation pour comprendre vos dépenses
    • Le suivi de vos dépenses implique l'utilisation de balises de répartition des coûts et de budgets pour filtrer les données selon les dimensions pertinentes pour votre entreprise
    • L'optimisation de vos dépenses implique l'utilisation des techniques de la section précédente dans le cadre d'un objectif budgétaire global


    Lectures complémentaires

Conclusion

Dans ce module, vous avez découvert le pilier Optimisation des coûts. Vous avez appris à appliquer un modèle OpEx pour vos dépenses dans le cloud. Vous avez appris les techniques d'optimisation des coûts comme le dimensionnement approprié, la technologie sans serveur, les réservations et les instances Spot. Vous avez appris à examiner, suivre et optimiser votre budget en utilisant des services tels que Cost Explorer, les balises et les budgets.

 

Lectures complémentaires

AWS GovCloud (US)

Cette section concerne ceux dont les charges de travail doivent respecter les exigences FedRAMP, DoD SRG, ITAR, CJIS ou d'autres exigences strictes de conformité, ou si elles contiennent des données classifiées comme Controlled Unclassified Information (CUI).

AWS GovCloud (US) aide à répondre aux besoins de conformité et de réglementation des agences gouvernementales américaines aux niveaux fédéral, national et local, ainsi que les organisations commerciales américaines dans les secteurs de l'aéronautique, de la défense, de la fabrication, de la santé, des services financiers, de l'énergie et d'autres secteurs très réglementés. Conçus pour héberger des données sensibles et des charges de travail réglementées dans le cloud, les régions AWS GovCloud (US) sont des régions AWS isolées opérées par des employés qui sont des citoyens américains sur le sol américain.

AWS GovCloud (US) offre aux clients d'agences gouvernementales et à leurs partenaires la flexibilité de créer des solutions cloud sécurisées qui respectent le programme FedRAMP High baseline ; la stratégie de sécurité CJIS (Criminal Justice Information Systems) du DOJ ; les réglementations américaines ITAR (International Traffic in Arms Regulations) ; les réglementations EAR (Export Administration Regulations) ; le guide Cloud Computing Security Requirements Guide (SRG) du Ministère de la défense (DoD) pour les niveaux d'impact 2, 4 et 5 ; les FIPS 140-2 ; l'IRS-1075 ; et d'autres régimes de conformité.

Que ce soit les informations désignées CUI (Controlled Unclassified Information), les informations identifiables personnellement (PII), les dossiers médicaux sensibles des patients et les données financières ou les données d'application de la loi, l'exportation de données contrôlées et d'autres formes d'informations désignées « CUI », les régions AWS GovCloud (US) peuvent aider les clients à respecter la conformité dans toutes les étapes de leurs transition vers le cloud.

 

Lectures complémentaires

Félicitations !

Vous avez maintenant terminé le cours Fondamentaux d'AWS. Ce cours a abordé les thèmes et concepts suivants :

  • Les cinq piliers du Cadre AWS Well-Architected
  • Les modèles mentaux importants qui représentent l'approche cloud native des cinq piliers
  • Les concepts clés dans chacun des cinq piliers

À ce stade, vous avez appris les concepts fondamentaux de la création de services sécurisés, performants, fiables, excellents sur le plan opérationnel et à coût optimisé dans le cloud. Bien que nous n'ayons fait qu'effleurer la surface des possibilités, vous avez maintenant de solides bases pour le reste de votre expérience AWS. Maintenant que vous avez terminé le cours Fondamentaux d'AWS, mettez en pratique ce que vous avez appris pour créer votre futur service d'entreprise sur AWS.