Pour le web, les services d’Amazon répondent principalement à trois problématiques :

• le stockage des données, avec Amazon S3
• la puissance de calcul, avec Amazon EC2
• et la capacité de distribution, avec Amazon Cloudfront

Amazon S3, pour le stockage de données et la sauvegarde

Premier service à avoir été lancé par Amazon, il y a trois ans, S3 est une solution de stockage de données en ligne. Une fois son compte créé, l’utilisateur peut envoyer des fichiers - appelés des "objets" dans le jargon Amazon - dans des dépôts distants (des "buckets"), en identifiant chaque fichier par une clé unique (une "key").

Comme la majorité des services proposés par Amazon, S3 est accessible par le biais d’une API REST, à laquelle s’interfacent de nombreuses applications : l’extension S3Fox pour Mozilla Firefox, CloudBerry Explorer, etc., mais également des solutions de sauvegarde automatisée comme Jungledisk, Vembu StoreGrid ou encore s3backup.... Les données étant stockées de manière redondante sur les serveurs d’Amazon, une politique de sauvegarde s’appuyant sur S3 est donc plus sûre qu’une simple copie sur CD ou DVD ré-inscriptible, même s’il convient toujours de conserver par sécurité une copie locale de ces données. Au final, S3 est donc à la fois une solution de stockage de données en ligne, de sauvegarde automatisée d’entreprise, voire même de sauvegarde de tout un site web.

S3Fox, une extension Firefox permettant de gérer les contenus présents dans S3

La facturation du service par Amazon est faite sur la base du volume de données transférées et entreposées sur les serveurs d’Amazon.

Amazon EC2, une architecture scalable

Les services offerts par Amazon vont plus loin que le simple stockage en ligne de fichiers. Avec EC2, une offre lancée en août 2006, Amazon propose une solution de virtualisation à grande échelle. EC2 permet de déployer en quelques clics des images virtuelles, nommées des AMIs sur des serveurs virtualisés hébergés par Amazon, appelés des "instances".

Amazon fournit un outil permettant de créer ses propres instances (en réalité, des installations complètes du système d’exploitation), mais propose également un annuaire d’images virtuelles comprenant plus de 300 références, vierges (Windows Server, Ubuntu Linux, CentOS, OpenSolaris, Oracle Enterprise Linux, openSUSE, Debian, Fedora, etc...) ou spécialiées (MySQL Enterprise, Oracle 11g, Ruby On Rails, Drupal, IIS/Asp.Net, LAMP, Windows Media Server, ...). Le déploiement d’une instance vierge se fait donc en quelques minutes, directement depuis l’interface web d’AWS.

En plus de cette puissance de calcul virtualisé, EC2 fournit quelques outils supplémentaires :

• Amazon CloudWatch permet d’effectuer le monitoring détaillé des instances EC2, en collectant des métriques d’utilisation, de charge, et de performance des instances.
• Elastic Load Balancing permet de distribuer le trafic entrant entre différentes instances identiques. C’est, en quelque sorte, un load balancer virtuel.
• Auto Scaling permet de lancer au besoin, suivant les performances des instances déjà en fonctionnement, de nouvelles instances supplémentaires afin de faire face à une montée en charge temporaire. Piloté par CloudWatch, autoscaling est donc l’assurance qu’un système est toujours disponible, quel que soit le pic d’utilisateurs qu’il doive supporter.
• enfin, la Console de gestion, encore en cours de développement, permet de gérer les services.

Amazon Cloudfront, un CDN personnalisé

Dernier "gros" service fourni par Amazon, Cloudfront est un réseau de distribution de contenu. Le principe d’un CDN est simple : lorsqu’un utilisateur, situé au Japon, tente d’accéder à un contenu hébergé en France, il doit généralement faire face à une latence importante, en raison de la durée d’acheminement de ce contenu. Afin d’accélérer la "livraison" de ce contenu, Amazon propose avec Cloudfront un réseau comportant de très nombreux serveurs, répartis aux quatre coins de la planète, situés près des utilisateurs, et donc aptes à servir le contenu plus rapidement en en gardant une copie dans un cache local. Cloudfront est exclusivement capable de servir du contenu stocké sur S3, que l’utilisateur peut rendre disponible en créant des "distributions".

La mise en place d’un CDN nécessite que les médias servis par le CDN (les images, les feuilles de style, les fichiers javascript, les vidéos volumineuses, etc.) soient placés sur un sous-domaine différent du domaine principal. Par exemple, pour le site web http://www.clever-age.com/, une idée de sous-domaine adéquat serait http://medias.clever-age.com/ (ne cherchez pas, ça n’existe pas... pour l’instant !). Dans le cas d’Amazon, ce sous-domaine est personnalisable client par client (le nom "Amazon" n’apparait pas dans l’url des contenus hébergés), et est un CNAME vers un sous-domaine de la forme http://hadopivomi.cloudfront.net/.

Les critères permettant d’évaluer quel est le serveur du CDN à partir duquel l’utilisateur télécharge un contenu peuvent varier : proximité géographique, nombre de nœuds réseau à parcourir, coût potentiel de l’acheminement, etc. C’est à la mise en place du CDN qu’est décidée la stratégie de redirection du trafic. Dans le cas spécifique d’Amazon Cloudfront, c’est la proximité réseau qui est prise en compte. Lorsqu’un utilisateur tente donc d’accéder au contenu http://medias.clever-age.com/logo.jpg, les serveur DNS de Cloudfront (ns-01.cloudfront.net et ns-02.cloudfront.net) renvoient une liste d’adresses IP convenables pour l’utilisateur. Les serveurs situés à ces adresses IP, situés au sein du réseau d’Amazon, rapatrient alors le contenu depuis le bucket S3 où le contenu est stocké, en font une copie locale qu’ils servent alors à l’utilisateur.

Voici un schéma global, montrant une architecture tirant partie des services offerts par AWS :

Un exemple d’architecture tirant partie des services d’Amazon

Quelques limitations

Si les solutions offertes par Amazon sont encore en béta, elles permettent dés maintenant de mettre en place des architectures évolutives, performantes et maîtrisées, ce que peu d’hébergements peuvent prétendre. Néanmoins, les services d’Amazon souffrent de certaines limitations, ou sont en tout cas sujets à certaines questions :

• Cloudfront ne supporte pas SSL : il n’est donc pas possible de servir des médias, scripts ou feuilles de style depuis des pages https à l’aide de Cloudfront, ce qui peut être problématique pour les sites marchands à fort trafic (alors que la plupart des concurrents savent faire).
• la sphère logicielle des services web d’Amazon reste restreinte, malgré la qualité des APIs et de la documentation. Certaines fonctionnalités de Cloudfront restent difficiles à maîtriser, comme par exemple la possibilité de correctement positionner le mime-type ou les headers HTTP de cache. La console de gestion, prévue pour gérer ces éléments, est encore en cours de développement et n’est actuellement pas disponible pour S3 ou Cloudfront : le contrôle ne peut donc se faire que de manière programmatique, par le biais de l’API, ou alors en utilisant des outils externes.
• plus gênant, Cloudfront est en mode push uniquement, c’est-à-dire qu’il ne sert que les contenus préalablement placés sur S3. Hors de question, avec Cloudfront, d’employer le CDN comme un proxy "devant" la plateforme web, ce que propose par exemple Akamai. Cela signifie que, chaque fois qu’une feuille de style ou un fichier javascript est modifié, il faut le déployer sur S3. Ce n’est pas fait automatiquement (à moins, évidemment, de monter les dossiers de javascripts, de CSS et d’images à l’aide de s3fs, mais ce n’est pas une solution évidente...).
• la facturation de ces services est à surveiller de près. S’ils sont "extensibles", la facturation l’est également, et les plateformes les plus consommatrices en bande passante peuvent vite devenir coûteuses.
• dernier problème, lié d’un manière plus générale à la notion de "cloud" : il n’est a priori pas possible de mettre en concurrence plusieurs fournisseurs de ce type de service. Il faudrait, pour cela, que les fournisseurs exposent des APIs publiques, de sorte que l’utilisateur puisse indifféremment utiliser les infrastructures d’Amazon, Google App Engine, Akamai, Limelight, etc. Et évidemment, ça, ce n’est pas pour demain.