Archives de
Catégorie : Divers

AWS & COREXPERT organisent le 1er AWS DevDay en France

AWS & COREXPERT organisent le 1er AWS DevDay en France

Le 27 avril prochain et pour la première fois en France, Amazon Web Services en partenariat avec COREXPERT, organise un événement incontournable du Cloud à Lyon :

L’ AWS DevDay


Après San Francisco, Austin, Munich, il s’agira du lieu parfait pour les profils techniques souhaitant perfectionner leurs connaissances sur le Cloud AWS.

Evénement gratuit et situé à La Tour du Web, vous pourrez en apprendre plus sur les annonces récentes du Cloud Computing grâce à l’intervention de deux Solutions Architects AWS, et celle de Julien Simon, AWS Principal Technical Evangelist.

COREXPERT est un partenaire privilégié du Cloud Public Amazon Web Services. A travers ses deux business units : Cloud Native Apps & Cloud Infrastructure, l’équipe d’architectes et développeurs certifiés AWS joue un rôle essentiel dans la transformation digitale cloud de la PME aux Multinationales.

awsome-day-event

Vous pourrez compléter vos connaissances avec l’équipe technique de AWS et celle de Corexpert, qui auront le plaisir de vous conseiller sur les bonnes pratiques et les outils incontournables de la plateforme.

sinscrire-gratuitement

La journée


Celle-ci sera rythmée par des démonstrations en live, et des temps d’échanges dédiés à vos questions, sur vos problématiques.

La journée débutera avec La bataille des Big Data, une session où nous verrons comment Redshift, Athena, Spark et Hive se comportent face à un gros dataset. Qui sera le plus rapide ? Le plus efficace en terme de coûts ? Le plus simple d’utilisation ? Assistez à cette session, votez en direct pour votre favori et découvrez les résultats avec nous !

Next up : A 60 minutes tour of AWS ComputeAvec plus de 10 familles d’instances, Elastic Beanstalk, ECS et Lambda, le choix peut vite s’avérer difficile. Dans cette session, nous verrons donc en une heure quelle solution convient le mieux à chaque cas de figure.

L’après-midi, nous nous répartirons en 3 groupes, chacun abordant un sujet différent. Rejoignez un groupe, puis un autre, libre à vous de composer votre après-midi telle que vous la concevez ! Vous pourrez également proposer des sujets pendant la pause déjeuner.

Voir l’agenda de la journée ]

Cet événement AWS à l’initiative et sponsorisé par COREXPERT

aws-advanced

COREXPERT : AWS Advanced Consulting Partner

COREXPERT profite d’une expertise de plus de 7 ans dans l’exploitation des services managés AWS, à la fois dans le développement applicatif (Web, SaaS, etc.) et la gestion de la croissance d’infrastructures.

L’équipe comptabilise plus d’une dizaine de certifications AWS, qui ont validé l’expérience acquise et les nombreux projets déployés sur la plateforme Cloud leader mondial.
Partenaire depuis 2014, l’un des premiers en région, COREXPERT a rejoint peu de temps après le réseau de distribution AWS Channel Reseller et reçu le label Consulting Partner. Le réseau de partenaires AWS (Amazon Partner Network) est un programme de partenariat proposé par AWS qui évalue la capacité de ses partenaires à accompagner les clients vers les bonnes pratiques et la meilleure exploitation de la plateforme Cloud. De plus, il confirme les compétences (certifications, accréditations) des équipes techniques.

En développant son expertise des services AWS et son engagement, COREXPERT a accédé début février au niveau APN supérieur : Advanced Consulting Partner, une étape importante dans sa croissance et son partenariat.

Ce niveau de partenariat avec Amazon Web Services est le fruit du travail de nos architectes et développeurs qui accompagnent nos clients, vos projets, dans la conception, le déploiement ou la migration et l’exploitation des infrastructures & applications sur AWS.

Acteur incontournable des quarts sud-est et sud-ouest, COREXPERT accompagne également ses clients sur toute la métropole et à l’international.

Partenariat : ORINOX choisit COREXPERT et Amazon Web Services pour propulser OCWS

Partenariat : ORINOX choisit COREXPERT et Amazon Web Services pour propulser OCWS

Dans le cadre du développement de sa plateforme cloud de services dédiée à la digitalisation de site industriel nommée OCWS (Orinox Cloud Web Services), ORINOX s’appuie sur COREXPERT, afin de s’assurer que sa solution répondra aux exigences les plus élevées en termes de sécurité, contrôle et scalabilité.

Lire la suite Lire la suite

Le cloud public n’est pas infaillible, vous en doutiez ?

Le cloud public n’est pas infaillible, vous en doutiez ?

Cette douce nuit du 28 février au 1er mars 2017 a tenu éveillés beaucoup d’européens, le service S3 de Amazon Web Services a connu une indisponibilité de plusieurs heures dans la région historique us-east-1 situé en Virginie (USA). Mais pourquoi de grands noms du web se trouvent autant impactés ? Ces grands du web, Trello, Slack, etc. valorisés à plusieurs millions voire milliards auraient-ils un bad-design d’infrastructure ?

Lire la suite Lire la suite

Le SLA chez Amazon Web Services #AWS

Le SLA chez Amazon Web Services #AWS

Chez Corexpert, nos clients nous posent souvent cette question :

« On nous parle toujours de Haute Disponibilité et Très Haute Disponibilité chez AWS, mais s’engagent-ils vraiment ? Existe-t-il un SLA ? »

 

Qu’est ce que le SLA ?

Le SLA, ou Service Level Agreement, est le niveau de qualité et de performance contractuel d’un service ou d’une infrastructure technique. Dans le cas de AWS, fournisseur Cloud, on parlera donc bien d’un service, vue qu’on évolue dans le monde IaaS – Infrastructure as a Service !

Le SLA doit cadrer en premier lieu de quelle fourniture nous parlons, et les critères de performances sur lesquels le fournisseur va s’engager. On pourra donc parler de temps de réponse, de fonctionnalité assurée, de disponibilité complète du service etc.

SLA chez AWS

Nous allons parcourir ci-dessous les principaux services, ou services majeurs de l’offre AWS, qui possèdent un SLA à la date de rédaction de cet article. Bien évidemment la liste est non exhaustive.

Amazon Route 53 : SLA du DNS AWS

Le service DNS de AWS, Amazon Route 53, possède un SLA de disponibilité du service du niveau le plus haut possible. En effet on a ici un engagement de disponibilité de 100% sur le service, ce qui est explicité par « Amazon Route 53 n’échouera pas pour répondre à vos requêtes DNS dans le cycle de facturation d’un mois ». Pourquoi parler d’un mois ? Car AWS, s’engage, en cas d’éventuelle défaillance avérée, de vous rembourser sous forme de crédits sur ce cycle de facturation.

sla-amazon-route-53

Extrait de la page SLA – Amazon Route 53 au 29 décembre 2016

Amazon EC2 ou Elastic Cloud Compute : SLA des VM AWS

Service principal de AWS, Amazon EC2 et Amazon EBS fournissent respectivement l’hyperviseur managé pour executer vos Machines Virtuelles, aka instances EC2 et le stockage virtualisé Amazon Elastic Block Store.

Le SLA de ces services, avec l’engagement de Amazon Web Services, est d’au moins 99.95% mensuel. Soient moins de 22 minutes.

Si une indisponibilité était avérée entre 99.95 et 99.0%, AWS s’engage à effectuer une remise de 10% en crédits AWS sur le service EC2, en deça de 99.0% de disponibilité AWS proposera une remise de 30% en crédits.

Il est important de noter que le SLA est lié à l’état « Region Unavailable« . Si vous ne le savez pas déjà, une région est l’ensemble de plusieurs zones (2+) de disponibilités, mais dans le cadre du SLA, AWS précise que l’état « Région indisponible » vous concerne si plus d’une zone de disponibilité où vous exécutez des instances EC2 est indisponible, comprendre les instances n’ont plus accès à Internet.

L’insdisponibilité de EBS, est si vos volumes de stockage ne génèrent plus d’I/O alors que la file d’attente n’est pas vide.

Amazon RDS, SLA des bases de données managées AWS

Amazon RDS est le service de Base de données managée par AWS, il supporte à ce jour MySQL, Oracle, PostgreSQL, MariaDB, Microsoft SQL Server, AuroraDB. Mais le SLA proposé par AWS, concerne uniquement les instances Multi-AZ (c’est à dire avec un serveur en Stand-By mode dans une autre zone de disponibilité) des moteurs SQL : Oracle, MariaDB, MySQL & PostgreSQL. Ce SLA est de 99.95% de disponibilité du service. L’indisponibilité est avérée quand toutes les requêtes de connection échouent pendant une minute sur l’instance RDS
multi-AZ.

sla-amazon-rds

Engagement de AWS et remboursement en crédits au 29 décembre 2016

Amazon S3, SLA du stockage AWS

Amazon S3 est le service de stockage d’objets, il est l’un des plus anciens services de AWS, et possède une durabilité des données de 99.999999999% en mode de stockage standard. Toutefois le SLA, concerne la disponibilité d’accès à la données stockée via l’API AWS. Le SLA de Amazon S3 est donc calculé sur le comptage d’erreurs ou d’indisponibilité de l’API sur 5 minutes.

L’engagement de AWS est de conserver une disponibilité au-delà de 99.9% mensuel, ce qui représente moins de 43 minutes 36 secondes.

Si AWS ne peut assurer cette disponibilité sur la région où est stocké votre bucket S3, alors 10% de remise sur le coût de stockage S3 seront reversés en crédits, et en deça de 99.0%, alors la remise en crédit s’élèvera à 25% du coût du service Amazon S3.

Amazon CloudFront, SLA du CDN AWS

Amazon Cloudfront est le service CDN de AWS, avec plusieurs dizaines de « Edge Locations », ce service met en cache les requêtes web selon vos comportements et pattern d’URLs choisis. Il permet des diffusions et donc des chargements de données accélérés sur les sites web et applications mobile, notamment lorsque du contenu media transite.

AWS s’engage à maintenir une disponibilité globale du service au-dessus de 99.9% mensuel (identique à Amazon S3). Les remises effectués sur le service, en cas de défaillance avérée, également basé sur la fréquence des erreurs d’accès aux données sont identiques à celles de Amazon S3.

AWS Shield, SLA du service de protection anti-DDoS

Récemment lancé lors du re:Invent 2016, AWS Shield est l’officialisation de la protection anti DDoS de AWS. Le service utilise et protège les autres services Amazon CloudFront et Amazon Route 53, et son SLA, ramené sur des périodes de 24 heures, est lié directement aux SLA des produits cités précédemment. On pourra donc traduire ce SLA, par un simple rappel que l’utilisation du service AWS Shield devant Amazon CloudFront ou Amazon Route 53 ne modifie pas leur SLA.

Synthèse des SLA chez AWS

 

Service AWS SLA mensuel SLA minutes/mois
Amazon Route 53 100.00 % 0 seconde
Amazon EC2 99.95 % 21 minutes et 36 secondes
Amazon RDS 99.95 % 21 minutes et 36 secondes
Amazon S3 99.90 % 43 minutes et 12 secondes
Amazon CloudFront 99.90 % 43 minutes et 12 secondes
AWS Shield Cf. CloudFront ou Route 53 Cf. CloudFront ou Route 53

 

Calcul du SLA d’une infrastructure AWS

Partons d’une infrastructure Web App, relativement classique. Elle est composée de plusieurs serveurs applicatifs frontaux, ici EC2 C4.Large, le code exécuté est le même sur chaque instance, et nous avons une redondance multi-zone de disponibilités. La base de données est un MySQL sur RDS en Multi-AZ (Stand-By Instance). Les éléments statiques du sites sont stockés sur S3. CloudFront, est placé devant le Load Balancer, il met en cache les éléments statiques de S3 et reroute les autres requêtes sur le LoadBalancer. Route53 gère le nom de domaine du site.

cloudcraft-web-app

Infrastructure Web : Amazon Route 53, CloudFront, S3, EC2 et RDS

Voici comment nous pouvons calculer le SLA de cette infrastructure, bien entendu celui-ci est dans le cas d’une défaillance de tous les services AWS utilisés sur une région, et dans le cadre du SLA de chacun de ses services. Dans ce cas l’infrastructure ne peut prétendre à un SLA supérieur sans redondance supplémentaire.

  • RDS Multi-AZ MySQL : SLA de 99,95 %
  • EC2 : SLA de 99.95 %
  • CloudFront : SLA de 99.9 %
  • S3 : SLA de 99.9%
  • Route 53 : 100.0 %

Le SLA de l’infrastructure brute sera de :

99.95% x 99.95% x 99.9% x 99.9% x 100% = 99,70 %

Si l’on considère que l’indisponibilité S3 n’est pas critique pour la conservation de la disponibilité de l’infrastructure web (par exemple une API) et qu’on gère via Route 53 l’éventuel downtime de CloudFront en pointant vers le Load Balancer en secours, nous gagnerons 0,2% de SLA juste par modification et optimisation du Design de l’infrastructure :

99.95% x 99.95% x 100% = 99,90 %

N’hésitez pas à poser vos questions ou nous contacter pour plus d’informations.