Amazon Elastic Compute Cloud (Amazon EC2) fournit une capacité de calcul redimensionnable dans le cloud et est souvent la première étape d’utilisation d’AWS. Cette session vous présentera les concepts fondamentaux d’Amazon EC2. En tant que participant vous vivrez l’expérience d’une première semaine d’utilisation d’Amazon EC2 au travers du déploiement d’une application réelle en production, de l’utilisation des AMI (Amazon Machine Image) sur les instances Amazon EC2 à la mise en œuvre de fonctionnalités avancées. Au cours de ce processus, vous identifierez les meilleures pratiques et les spécificités de déploiement dans le Cloud.

1. Pierre Gilot
Votre première semaine avec Amazon EC2
Solutions Architect

2. Questions pour votre première semaine sur Amazon EC
• Qu’est-ce qu’ Amazon EC2 ?
• Par quoi démarrer sur EC2 ?
– Quels sont les composants de EC2 ?
– Quels sont les grands patterns d’architecture dans le cloud ?
– Quels autres services d’Amazon Web Services utiliser ?
• Comment projeter mon architecture existante dans Amazon EC2 ?
– Comment configurer mon environnement pour la haute disponibilité ?
– Comment gérer mon environnement dans le cloud ?
– Comment superviser mon environnement dans le cloud ?

3. Une approche pour votre première semaine sur Amazon EC2
• Utilisez ce que vous savez déjà sur les architectures web
• Comprenez le minimum requis pour démarrer avec Amazon EC2
• Prenez une approche itérative
– Remaniez et itérez
– Payez uniquement pour ce que vous utilisez
• Comprenez et appliquez les bonnes pratiques du cloud
– Capacité à la demande
– Elasticité
– Conçu pour la tolérance aux pannes
– Automatisation de l’infrastructure

4. Jour 1 – Identifiez et déployez une application sur Amazon EC2
Région
Zone de disponiblité
Linux
Apache
Ruby
MySQL
Source Protocol Port
0.0.0.0/0 HTTP 80
148.20.57.0/24 SSH 22

5. Jour 1 – Lancez votre première instance EC2
1. Connectes vous sur la AWS Management Console et choisissez EC2
2. Choisissez une Amazon Machine Image (AMI)
3. Choisissez une taille d’instance
4. Créez une paire de clef pour l’accès SSH
5. Créez des règles de sécurité basées sur le filtrage de ports
6. Lancez l’instance
7. Chargez votre code

6. Jour 1 – Choisissez une AMI

7. Jour 1 – Choisissez une taille d’instance

8. Jour 1 – user-data d’instance

9. Jour 1 – Tags

10. Jour 1 – Créez une paire de clefs

11. Jour 1- Configurez le Firewall

12. Jour 1 – Instance opérationnelle

13. Day 1 – Connectez-vous
[laptop]$ ssh -i ~/ec2.pem ec2-user@ec2-54-242-253-200.compute-1.amazonaws.com
__| __|_ )
_| ( / Amazon Linux AMI
___|___|___|
https://aws.amazon.com/amazon-linux-ami/2012.09-release-notes/
There are 13 security update(s) out of 24 total update(s) available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-40-203-29 ~]$ sudo yum -y -q update
[ec2-user@ip-10-40-203-29 ~]$ sudo yum -y -q install httpd mysql-server ruby19 git
[ec2-user@ip-10-40-203-29 ~]$ sudo service mysqld start
[ec2-user@ip-10-40-203-29 ~]$ sudo /etc/init.d/httpd start

14. Jour 1  Jour 2
Jour 1 Recapitulatif Jour 2 Considérations
1. Créez un compte AWS
2. Identifiez votre application
3. Connectez vous à la console
4. Choisissez une AMI
5. Lancez une instance EC2
6. Configurez votre application
• Comment capturer ces tâches et les
rendre répétables pour réagir en cas
de panne ?
• Quelles sont les options pour une
architecture multi-tiers ?
• Comment appliquer une sécurité
accrue à vos instances ?

15. Jour 2 – Créez une architecture multi-tiers
Région
Zone de disponibilité
Snapshot Amazon S3
Internet
Utilisateur
HTTP (80)
Source Protocol Port
0.0.0.0/0 HTTP 80
148.20.57.0/2
4
SSH 22
Connection Type Details
EC2 Security
Group
web-tier-sg

16. Jour 2 – Lancez une application multi-tiers
1. Créez un Snapshot de l’instance EC2
– Stoppez MySQL
– Créez une nouvelle AMI
2. Créez une instance de base de données relationnelle (RDS)
– Nous illustrerons avec MySQL
– Autres options : Oracle, SQL Server
3. Configurez votre application pour utiliser la base de données RDS MySQL

17. Jour 2 – Créez une nouvelle AMI personnalisée

18. Jour 2 – Nouvelle AMI

19. Jour 2 – Lancez une Amazon instance RDS

20. Jour 2 – Détails de l’instance RDS

21. Jour 2 – Options Amazon RDS

22. Jour 2 – Ouvrez l’accès de RDS à votre application EC2

23. Jour 2 – Connectez-vous à la base de données RDS
[ec2-user@ip-10-40-203-29 ~]$ mysql -uroot –p –D devdb
–h nonprod.ctjsifycx3sq.us-east-1.rds.amazonaws.com
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 268
Server version: 5.5.27-log Source distribution
Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
mysql>

24. Jour 2  Jour 3
Jour 2 Récapitulatif Jour 3 Considerations
1. Créez une nouvelle AMI personnalisée
2. Créez une DB RDS MySQL
3. Créez et validez les Security Groups
• Quels outils fournit AWS pour
superviser EC2 et RDS ?
• Comment améliorer la supervision
de l’environnement (proactif vs.
réactif) ?
• Comment être notifié quand les
serveurs atteignent un certain seuil ?

25. Jour 3 – Supervisez l’environnement
Region
Availability Zone
Internet User
Amazon
CloudWatch
Users
Alarm
Administrator
Email Notification

26. Jour 3 – Créez une alarme CloudWatch
1. Sélectionnez une métrique à superviser
– La latence des écritures dans une base de données est un bon indicateur de l’état de
santé de l’application
2. Définissez un seuil
– Des latences d’écritures dépassant les 500ms requièrent généralement une
intervention de votre part
3. Créez un ‘topic’ pour votre alarme et abonnez-vous à ce ‘topic’

27. Jour 3 – Créez une alarme

28. Jour 3 – Créez une alarme

29. Jour 3 – Créez une alarme

30. Jour 3 – Créez une alarme

31. Jour 3 – Alarme créée

32. Jour 3  Jour 4
Jour 3 Récapitulatif Day 4 Considérations
1. Identifiez les métriques CloudWatch
disponibles pour EC2 et RDS
2. Créez une alarme CloudWatch
3. Configurez l’alarme pour envoyer un
email en cas de souci
4. Vérifiez le dashboard CloudWatch
• Que se passe-t-il quand une instance
EC2 ne fonctionne plus ?
• Que se passe-t-il si une zone de
disponibilité devient inaccessible ?
• Comment dimensionner de manière
élastique en cas d’augmentation ou
de baisse du trafic ?
• Que se passe-t-il si une instance RDS
primaire ne fonctionne plus ?

33. Jour 4 – Concevoir pour la haute disponibilité
Region
Availability Zone
Internet
Amazon
CloudWatch
Users
Alarm
Availability Zone
RDS DB Standby
Auto scaling Group

34. Jour 4 – Les étapes vers la haute disponibilité
1. Créez un Elastic Load Balancer (ELB)
– Répartissez la charge entre plusieurs instances EC2
– Permet d’avoir des instances dans des zones de disponibilité multiples (AZ)
2. Configure Auto Scaling
– Ajoute des ressources automatiquement quand la demande monte
– Puis les enlève pour économiser les coûts
3. Mettez en place le Multi-AZ sur la DB RDS
– Réplication synchrone vers un ‘standby’ dans une autre zone de disponibilité (AZ)
– Bascule automatique en cas de besoin
– Réduction de la fenêtre de backup (le standby est utilisé pour les sauvegardes)

35. Jour 4 – Créez un Load Balancer

36. Jour 4 – Configurez le Health Check

37. Jour 4 – Ajoutez des instances EC2

38. Jour 4 – Elastic Load Balancer est actif

39. Jour 4 – Configurez Auto Scaling
1. Utilisez l’AMI créée précédemment
2. Utilisez plusieurs zones de disponibilité (AZ)
– Distribuez les instances entre deux AZ
– Vérifiez qu’au moins deux instances sont actives
3. Créez un trigger Auto Scaling
– Concept identique aux alarmes CloudWatch vu précédemment
– Maintenant nous menons des actions proactives

40. Jour 4 – Repérez l’AMI créée précédemment

41. Jour 4 – Configurez Auto Scaling
[laptop]$ as-create-launch-configuration webcfg
--image-id ami-08dc4461 --instance-type m1.small
--region us-east-1
[laptop]$ as-create-auto-scaling-group webscg
--launch-configuration-name webcfg
--availability-zones us-east-1a us-east-1c
--min-size 2 --max-size 10 --load-balancer-names frontlb

42. Jour 4 – Configurez Auto Scaling (suite)
[laptop]$ as-put-scaling-policy WebScaleUpPolicy
--auto-scaling group webscg
--adjustment=1 --type ChangeInCapacity --cooldown 300
[laptop]$ mon-put-metric-alarm WebHighCPUAlarm
--comparison-operator Greater ThanThreshold
--evaluation-periods 1 --metric-name CPUUtilization
--namespace "AWS/EC2" --period 600
--statistic Average --threshold 80
--alarm-actions POLICY-ARN_from_previous_step
--dimensions "AutoScalingGroup Name=webscg"

43. Jour 4 – Vérifiez les instances

44. Jour 4 – Basculez RDS en mode Multi-AZ
[laptop]$ aws rds modify-db-instance
--db-instance-identifier nonprod
--multi-az --region us-east-1
Oui, c’est tout.
Pas de souris requise. :)

45. Jour 4  Jour 5
Jour 4 Récapitulatif Day 5 Considérations
1. Répartissez votre application dans
plusieurs zones de disponibilité
2. Automatisez la montée et descente de
charge avec Auto Scaling
3. Mettez de la répartition de charge avec
AWS Elastic Load Balancing.
4. Passez la base de données en mode
haute disponibilité avec le mode multi-
AZ de RDS
• Comment mettre en place un nom
de domaine personnalisé pour notre
répartiteur de charge ?
• Comment configurer un compte
pour un autre utilisateur AWS ?
• Comment répliquer l’environnement
?

46. Jour 5 – DNS, Identity & Access Management, automatisation des
déploiements
Region
Availability Zone
Internet
S3 Bucket
Amazon
CloudWatch
Users
Alarm
Availability Zone
RDS DB Standby
AWS IAM
www.example.com
AWS Management
Console
AWS
CloudFormation
TemplateStack
images.example.com

47. Jour 5 – Route 53 (DNS)

48. Jour 5 – Identity & Access Management

49. Jour 5 – Automatisation des déploiements

50. Votre première semaine sur Amazon EC2
• Evolution du Jour 1  Jour 5
– Simple AMI  Multi-tier Monitoré  Haute Dispo. DNS, AM, Automatisation
• Meilleures pratiques du cloud mises en place en semaine 1
– Scaling pro-actf – Auto scaling
– Elasticité – EC2
– Conçu pour résister aux pannes – ELB, Auto scaling groups, zones de disponibilité
– Couplage faible des composants – EC2, RDS
– Automatisation de l’infrastructure – CloudFormation

51. …et au delà
• Après votre première semaine avec Amazon EC2
– AWS Management Console est très bien mais vous avez d’autres options
• Command Line Interface
• API
– Autres services AWS
• VPC, Elasticache, OpsWorks, Beanstalk, DynamoDB, SQS
– Checklist opérationnelle
• http://media.amazonwebservices.com/AWS_Operational_Checklists.pdf
– Automatisation des déploiements
• http://aws.amazon.com/cloudformation/aws-cloudformation-articles-and-tutorials/
– Liens vers les whitepapers et architectures
• http://aws.amazon.com/whitepapers/
• http://aws.amazon.com/architecture/

52. Exemple Client
SMATIS
Daniel SERY – Responsible SI

53. • Smatis, Mutuelle créée en 1943.
• Placée parmi les premières mutuelles de France avec une protection performante à plus de
• 160 000 personnes.
• Une présence nationale avec un réseau de 18 agences.
• Une plateforme de Gestion et un Système d'Informations robustes, orientés vers l'Innovation.
• Une volonté de rester au plus proche de ses clients et répondre aux exigences du « Time To
Market »

54. Dans le cadre de son PCA Globale, SMATIS recherchait une solution pour son SI, répondant aux exigences
suivantes :
• Une solution hautement disponible (PSI)
• Une solution hautement scalable
• Une solution de type Iaas avec des éléments Managés, permettant aux équipes d'assurer la transversalité
Métiers
• Une solution permettant une « orchestration » complète (pas seulement la virtualisation) de l'infrastructure :
provisionning, industrialisation, automatisation (API)
• Enfin une solution permettant de projeter une croissance importante, voir très importante de nos données à
traiter.

55. Nos premières expériences, et une première projection, avec AWS :
• Un Extranet Gestion pour Comptes, utilisant les briques importantes que sont EC2, les ELB (Load
Balancing), les Snapshots, l'autoScaling Group.
• Un Tarificateur Actuariel, utilisant aussi EC2 mais avec RDS pour une gestion managée et sécurisée
des bases de données.
• Un environnement de Recette et de Pre-production qui nous permet de suivre notre cycle de
développement applicatifs plus souplement et aussi valider les éléments de nos futurs migrations
(Web/GRC, Outils Métiers, GED, et applications périphériques de type indexation, serveurs de
fichiers...)
• Une interconnexion sécurisée en IPSEC avec tunnels redondants(coté AWS et coté SMATIS)

56. Pour résumer : les points positifs et ce qu'il faut retenir
• Mise en œuvre rapide
• Facilité d'administration et ouverture par les API
• Couts contrôlés et à la consommation
Mais n'oublions pas qu'un « Best Practice » doit être pris en compte :
• Tout ce qui est mis en place doit être penser par l'ECHEC (fail by design)
• Couplage lâche et applications Stateless : scalabilité garantie.

57. Pierre Gilot
Merci.
Solutions Architect