AWS Paris Summit 2014 - T3 - Evolution des architectures VPC

  • 1,020 views
Uploaded on

Track 3 - Session 2 : Evolution des architectures VPC

Track 3 - Session 2 : Evolution des architectures VPC

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,020
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
70
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Evolution des architectures VPC Pierre Gilot, Solutions Architect AWS
  • 2. Avertissement : Faites ceci chez vous! Toutes ces architectures sont mises en œuvre par de vrais clients!
  • 3. Concevez… puis epuisez vous à déployer vos infrastructures Déployez des datacenters virtuels à la vitesse à laquelle vous les concevez version
  • 4. Route Table Elastic Network Interface Amazon VPC Router Internet Gateway Customer Gateway Virtual Private Gateway VPN ConnectionSubnet Elements d’une architecture VPC
  • 5. Availability Zone A Availability Zone B
  • 6. Subnet Availability Zone A Subnet Availability Zone B VPC CIDR: 10.1.0.0 /16
  • 7. Prévoyez votre plan d’adressage IP avant de le créer • Prenez en compte l’expansion régionale d’AWS • Prenez en compte la connectivité potentielle avec vos réseaux internes • Prenez en compte les architectures de subnet • L’adressage VPC sétend de /16 à /28 • Les CIDR ne peuvent pas être modifiés après création • Plans d’adressage IP non disjoints = migraine assurée
  • 8. Public Subnet Private Subnet Public Subnet Availability Zone B Private Subnet VPC CIDR: 10.1.0.0 /16 Availability Zone A
  • 9. Public Subnet Private Subnet Public Subnet Availability Zone B Private Subnet Instance A 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 VPC CIDR: 10.1.0.0 /16 Availability Zone A
  • 10. Public Subnet Availability Zone A Private Subnet Public Subnet Availability Zone B Private Subnet Instance A 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 VPC CIDR: 10.1.0.0 /16 .1 .1 .1 .1
  • 11. Public Subnet Private Subnet Public Subnet Availability Zone B Private Subnet Instance A 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 VPC CIDR: 10.1.0.0 /16 Route Table Destination Target 10.1.0.0/16 local Availability Zone A
  • 12. Laissez la Main Route Table tranquille!
  • 13. Availability Zone B Public Subnet Availability Zone A Private Subnet Public Subnet Private Subnet Instance A 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 VPC CIDR: 10.1.0.0 /16 Route Table Destination Target 10.1.0.0/16 local 10.1.1.0/24 Instance B
  • 14. Network ACLs vs Security Groups NACLs • S’appliquent aux subnets (1 par) • Stateless • Allow & Deny (blacklist) • Priorités des règles Security groups • S’appliquent aux ENI d’instances (jusqu’à 5 par) • Stateful • ‘Allow’ seulement (whitelist) • Règles évaluées globalement • Possibilité de référencer d’autres security groups dans le même VPC VPC Subnet Elastic network interface Security group Network ACL
  • 15. ACLs réseau VPC : Pour quoi faire ? • Renforcer les stratégies de sécurité – Exemple: “Pas de TFTP, NetBIOS ou SMTP en sortie de ce subnet” • Garde-fous pour les security groups d’instance • Ségrégation de sécurité entre les équipes réseau et dev VPC Subnet Instance
  • 16. ACLs réseau VPC : Bonnes pratiques • Utilisez rarement, restez simple • Evitez les plages de ports éphémères • Donnez des ordres de priorité larges (pour en intercaler d’autres) • Utilisez IAM pour autoriser qui pourra modifier ou supprimer vos ACLs Cliquer ici peut faire mal! ACL réseau par défaut :
  • 17. Créez un groupe d’admin VPC avec IAM Exemples d’appels d’API a fort impact (High Blast Radius) don’t l’accès devrait être restreint: AttachInternetGateway AssociateRouteTable CreateRoute DeleteCustomerGateway DeleteInternetGateway DeleteNetworkAcl DeleteNetworkAclEntry DeleteRoute DeleteRouteTable DeleteDhcpOptions ReplaceNetworkAclAssociation DisassociateRouteTable {Support Resource Permissions
  • 18. Exemple de stratégie IAM Policy pour Admin NACL { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DeleteNetworkAcl", "ec2:DeleteNetworkAclEntry" ], "Resource": "arn:aws:ec2:us-west-2:123456789012:network-acl/*", "Condition": { "StringEquals": { "ec2:ResourceTag/Environment": "prod" }, "Null": { "aws:MultiFactorAuthAge": "false" } } } ] }
  • 19. Public Subnet Availability Zone A Private Subnet Public Subnet Availability Zone B Private Subnet Instance A 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 VPC CIDR: 10.1.0.0 /16 Créer des sorties à votre VPC
  • 20. Public Subnet Availability Zone A Private Subnet Public Subnet Availability Zone B Private Subnet Instance A 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 VPC CIDR: 10.1.0.0 /16 Virtual Private Gateway Internet Gateway Une seule IGW et une Seule VGW par VPC VPN connection Customer data center Customer data center AWS Direct Connect Route Table Destination Target 10.1.0.0/16 local Internal CIDR VGW
  • 21. Public Subnet Availability Zone A Private Subnet Public Subnet Availability Zone B Private Subnet Instance A 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 VPC CIDR: 10.1.0.0 /16 Route Table Route Table Destination Target 10.1.0.0/16 local 0.0.0.0/0 IGW
  • 22. Façons d’affecter des IP publiques Adresse Elastic IP (EIP) • Associée à un compte AWS et non à une instance • Mapping statique NAT de l’IP publique à l’IP privée • L’instance ne « voit » pas son EIP associée • Persiste indépendamment de l’instance • Peut être assignée alors que l’instance est stoppée ou en cours d’exécution • Peut être déplacée, réassignée à d’autres ENIs
  • 23. Façons d’affecter des IP publiques Affectation automatique d’IP publique • Au lancement d’instance dans un subnet de VPC • L’IP publique est dynamique et peut changer à l’arrêt/redémarrage de l’instance • N’est pas comptée parmi les EIP d’un compte • Uniquement sur les instance avec une seule ENI
  • 24. Public Subnet Availability Zone A Private Subnet Public Subnet Availability Zone B Private Subnet Instance A Public: 54.200.129.18 Private: 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 Route Table Internet Amazon S3 Amazon Dynamo DB AWS region AWS en dehors du VPC
  • 25. Exemples AWS en dehors du VPC • Point d’entrée des API AWS API – Pensez au appels d’API que vous pouvez lancer depuis vos instances à l’interieur d’un VPC – Exemples: Amazon EC2, AWS CloudFormation, Auto Scaling, Amazon SWF, Amazon SQS, Amazon SNS • Services régionaux – Amazon S3 – Amazon Dynamo DB • Software and patch repositories – Amazon Linux repo allows access only from AWS public IP blocks
  • 26. Public Subnet Availability Zone A Private Subnet Public Subnet Availability Zone B Private Subnet Instance A Public: 54.200.129.18 Private: 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 Route Table Internet Amazon S3 AWS region Que se passe-t-il si L’instance C, dans un Réseau privé, a besoin de communiquer en Dehors du VPC? Il n’y a pas de route vers l’IGW ni d’adresse IP publique. Amazon Dynamo DB
  • 27. Public Subnet Availability Zone A Private Subnet Public Subnet Availability Zone B Private Subnet NAT A Public: 54.200.129.18 Private: 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 Internet Amazon S3 AWS region Deployez une instance dont la fonction est : N etwork A ddress T ranslat(or) Route Table Destination Target 10.1.0.0/16 local 0.0.0.0/0 NAT instanc e Amazon Dynamo DB
  • 28. Qu’est-ce qui constitue l’AMI Amazon Linux NAT ? $echo 1 > /proc/sys/net/ipv4/ip_forward $echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects $/sbin/iptables -t nat -A POSTROUTING -o eth0 –s 10.1.0.0/16 -j MASQUERADE $/sbin/iptables-save $aws ec2 modify-instance-attributes –instance-id i-xxxxxxxx –source-dest- check “{”Value”:false}” Assez peu de choses, en réalité : 1. L’IP forwarding est activé 2. L’IP NAT Masquerading est activé dans les iptables pour le bloc d’adresses su VPC 3. Source/destination check est désactivé sur l’interface primaire
  • 29. Public Subnet Availability Zone A Private Subnet Public Subnet Availability Zone B Private Subnet NAT A Public: 54.200.129.18 Private: 10.1.1.11 /24 Instance C 10.1.3.33 /24 Instance B 10.1.2.22 /24 Instance D 10.1.4.44 /24 Internet Amazon S3 AWS region D’autres subnets privés pourraient partager la même route Et se servir de la NAT instance Cependant… Amazon Dynamo DB
  • 30. Public Subnet Availability Zone A Private Subnet Public Subnet Availability Zone B Private Subnet NAT A Public: 54.200.129.18 Private: 10.1.1.11 /24 Instance B 10.1.2.22 /24 Internet Amazon S3 AWS region … vous pourriez atteindre un goulot d’étranglement si vos instances privées devaient augmenter ainsi que le trafic NAT associé. Amazon Dynamo DB
  • 31. NAT disponible et évolutif
  • 32. Les process consommateurs de bande passante doivent ils nécessairement être derrière un NAT ? • Séparez les composants applicatifs en fonction de leur besoins en BP • Exécutez ces composants depuis les subnets publics • Utilisez toute la bande passante de vos instances • L’Auto Scaling vous facilitera la vie • Conservez quand même votre NAT pour les autres instances • Cas le plus fréquent : Flux Multi-Gbps vers Amazon S3
  • 33. Availability Zone A Availability Zone B Private Subnet Internet Amazon S3 Amazon Dynamo DB AWS region Public Subnet Public Subnet NAT Customers Public load balancer Web Servers • Application de traitement d’images Image avec nombreux transferts vers S3 Direct to Amazon S3 Public ELB Subnet Private Subnet Public ELB Subnet Multi-AZ Auto Scaling group Auto Scaling group • Le Elastic Load Balancer recoit les requêtes HTTP/S des utilisateurs • L’Auto Scaling affecte des IP publiques aux nouveaux serveurs • Grâce à leurs IP publiques les serveurs web initient des connexions vers Amazon S3 • L’instance NAT est toujours disponible pour les réseaux privés
  • 34. Affectation automatique d’IP publiques grâce à l’Auto Scaling $aws autoscaling create-launch-configuration --launch-configuration-name hi-bandwidth- public --image-id ami-xxxxxxxx --instance-type m1.xlarge --associate-public-ip-address Exemple de launch configuration (nommée “hi-bandwidth-public”):
  • 35. Availability Zone A Private Subnet Availability Zone B Private Subnet Internet Amazon S3 AWS region Public Subnet Public Subnet NAT • Utilisez l’Auto Scaling pour la haute disponibilité de votre NAT • Créez 1 NAT par Availability Zone • Chaque table de routage de chaque subnet pointe sur la NATde la même zone • 1 Auto Scaling group par NAT avec les paramètres min et max définis à 1 • L’Auto Scaling surveille la santé et la disponibilité des NATs • Un script de bootstrap NAT met à jour les tables de routage Auto scale NAT NAT Amazon Dynamo DB
  • 36. Disponibilité grâce à l’Auto Scaling $aws autoscaling create-auto-scaling-group --auto-scaling-group-name ha- nat-asg --launch-configuration-name ha-nat-launch --min-size 1 --max-size 1 --vpc-zone-identifier subnet-xxxxxxxx Exemple de HA NAT Auto Scaling group (nommé “ha-nat-asg”):
  • 37. Exemple de HA NAT User Data : PRIVATE_SUBNETS="`aws ec2 describe-subnets --query 'Subnets[*].SubnetId’ --filters Name=availability- zone,Values=$AVAILABILITY_ZONE Name=vpc-id,Values=$VPC_ID Name=state,Values=available Name=tag:network,Values=private`” if [ -z "$PRIVATE_SUBNETS" ]; then die "No private subnets found to modify for HA NAT." else log "Modifying Route Tables for following private subnets: $PRIVATE_SUBNETS" fi for subnet in $PRIVATE_SUBNETS; do ROUTE_TABLE_ID=`aws ec2 describe-route-tables --query 'RouteTables[*].RouteTableId’ --filters Name=association.subnet-id,Values=$subnet`; if [ "$ROUTE_TABLE_ID" = "$MAIN_RT" ]; then log "$subnet is associated with the VPC Main Route Table. HA NAT script will NOT edit Main Route Table.” elif [ -z "$ROUTE_TABLE_ID" ]; then log "$subnet is not associated with a Route Table. Skipping this subnet." else aws ec2 create-route --route-table-id $ROUTE_TABLE_ID --destination-cidr-block 0.0.0.0/0 --instance-id $INSTANCE_ID && log "$ROUTE_TABLE_ID associated with $subnet modified to point default route to $INSTANCE_ID." if [ $? -ne 0 ] ; then aws ec2 replace-route --route-table-id $ROUTE_TABLE_ID --destination-cidr-block 0.0.0.0/0 --instance-id $INSTANCE_ID fi fi done
  • 38. Taggez Vite, Taggez Souvent! • Les stratégies de Tagging doivent faire partie de vos conceptions • Code project, centre de coût, environnement, version, business unit • Taggez les ressources dès leur création • Les Tags sont utiles pour gérer les permissions • Les Tags sont utiles pour la facturation AWS
  • 39. Rôle IAM EC2 pour Instance NAT HA { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:ModifyInstanceAttribute", "ec2:DescribeSubnets", "ec2:DescribeRouteTables", "ec2:CreateRoute", "ec2:ReplaceRoute" ], "Resource": "*" } ] }
  • 40. Automatiser la Haute Disponibilité des NAT avec les User Data EC2 Latest version of the script: https://github.com/ralex-aws/vpc
  • 41. Et si vos architectures exigent des bandes passantes NAT élevées ? • Appliquez le pattern « 1 HA NAT per Availability Zone » • Redimensionnez votre instance NAT vers un type d’instance avec une classification réseau plus élevée • Vérifiez méticuleusement vos métriques réseau m1.small Low m1.large Moderate m1.xlarge, c3.2xlarge High t1.micro Very Low
  • 42. Profitez du “Enhanced Networking” • Disponible uniquement en VPC • Plus de PPS, faible Latence, faible Jitter • Supporté par les instances de type C3, I2, R3 • Inclus dans Amazon Linux, mais supporté par plusieurs systèmes (y compris Windows) http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html
  • 43. Un VPC, Deux VPC
  • 44. AWS region Approche multi-VPCs Public-facing web app Internal company app What’s next? VPN connection Customer data center
  • 45. Cas d’usage les plus fréquents : • Isolation d’applications • Isolation des périmètres d’audit • Séparation des niveaux de risque • Isolation prod/hors-prod • Isolation des environnements multi-tenant • Alignement avec les Business Units de l’entreprise
  • 46. Contrôle aux frontières…
  • 47. AWS region Application interne déployée dans un VPC Public-facing web app Internal company app VPN connection Customer data center
  • 48. Availability Zone A Private Subnet Private Subnet AWS region Virtual Private Gateway VPN connection Customer data center Intranet App Intranet App Availability Zone B Internal customers Route Table Destination Target 10.1.0.0/16 local Corp CIDR VGW Application interne déployée dans un VPC
  • 49. Mais… votre application stocke ses données là! Amazon S3
  • 50. Availability Zone A Private Subnet Private Subnet AWS region Virtual Private Gateway VPN connection Customer data center Intranet App Intranet App Availability Zone B Et vous ne souhaitez pas vraiment faire ça : Amazon S3 Internet Customer border router Customer VPN Internet
  • 51. Contrôlez l’accès à l’IGW avec du proxy • Déployez une couche de séparation proxy entre votre application et l’IGW • Restreignez les accès HTTP/S sortants uniquement aux destinations approvées, comme Amazon S3 • Supprimez toute route vers l’IGW pour les subnets privés • Contrôlez l’accès au proxy avec des security groups • Configurez les paramètres de proxy sur les systèmes d’exploitation des instances
  • 52. Availability Zone A Private Subnet Private Subnet AWS region VPN connection Customer data center Intranet App Intranet App Availability Zone B Internal customers Contrôle aux frontières Internal Load balancer Elastic Load Balancing Private Subnet Elastic Load Balancing Private Subnet ELB Multi AZ Auto Scaling group • Deployez un etage de Elastic Load Balancing reparti sur vos Availability Zones • Intégrez toutes les instances autorisées à « sortir » dans un security group • Référencez ce security group comme unique source autorisée à accéder l’étage de load balancing
  • 53. Placez vos Elastic Load Balancers dans leurs propres Subnets • Elastic Load Balancing c’est de l’Amazon EC2 dans vos subnets • Elastic Load Balancing consomme vos adresses privées • Subnets isolés = meilleure maîtrise • Distinguez bien l’étage de load balancing des autres étages applicatifs
  • 54. Availability Zone A Private Subnet(s) Private Subnet(s) AWS region VPN connection Customer data center Intranet App Intranet App Availability Zone B Internal customers Contrôle aux frontières Internal Load balancer Elastic Load Balancing Private Subnet Elastic Load Balancing Private Subnet • Etage de proxy Squid déployé entre l’IGW et l’étage de load balancing. Proxy Public Subnet Proxy Public Subnet Amazon S3 HTTP/S Multi AZ Auto Scaling group • Seuls les subnets proxy sont routés vers l’IGW. • Le security group des proxy ne permet l’accès qu’à partir de l’étage de load balancers. • Les proxy restreignent les URLs autorisées. Dans notre cas, s3.amazonaws.com est autorisée. • Les ACLs réseau de sortie forcent le protocole HTTP/S uniquement.
  • 55. Exemple de configuration Squid.conf : # CIDR AND Destination Domain based Allow # CIDR Subnet blocks for Internal ELBs acl int_elb_cidrs src 10.1.3.0/24 10.1.4.0/24 # Destination domain for target S3 bucket acl s3_v2_endpoints dstdomain $bucket_name.s3.amazonaws.com # Squid does AND on both ACLs for allow match http_access allow int_elb_cidrs s3_v2_endpoints # Deny everything else http_access deny all
  • 56. HTTP://AWS.AMAZON.COM/ARTICLES/5995712515781075
  • 57. AWS region Public-facing web app Internal company app What’s next? VPN connection Customer data center
  • 58. AWS region Public-facing web app Internal company app #1 HA pair VPN endpoints Internal company app #2 Internal company app #3 Internal company app #4 Customer data center Customer gateways (CGW): • 1 par tunnel VPN • 1 IP publique par CGW • AWS fournit 2 terminaisons de tunnel par region
  • 59. Public-facing web app Internal company app #2 HA pair VPN endpointsCustomer data center Internal company app #3 Internal company app #4 Internal company app #1 Internal company Dev Internal company QA AWS region BackupAD, DNS Monitoring Logging
  • 60. AWS region Public-facing web app Internal company app #1 HA pair VPN endpoints Customer data center L’option VPN en étoile… Internal company app #2 Internal company app #3 Internal company app #4 Services VPC • Des instances Amazon EC2 pour le VPN vers la virtual private gateway centrale • Pour la Haute Dispo, deux terminaisons VPN Amazon EC2 par site • Un VPC de contrôle contient les services communs à toutes les applications et VPCs • Protocole de routage dynamique (BGP, OSPF) entre les sites et le VPC central.
  • 61. VPC Peering
  • 62. 10.1.0.0/16 10.0.0.0/16 • VPCs de la même Region Peer Request Peer Accept • Entre comptes AWS • Plans d’adressage IP disjoints • Un seul entre deux VPCs
  • 63. 10.1.0.0/16 10.0.0.0/16 10.0.0.0/16 ✔
  • 64. 10.1.0.0/16 10.0.0.0/16 Route Table Destination Target 10.1.0.0/16 local 10.0.0.0/16 PCX-1 Route Table Destination Target 10.0.0.0/16 local 10.1.0.0/16 PCX-1 PCX-1 • Ni IGW ni VGW requis A B • Pas de SPoF • Pas de goulots d’étranglements de bande passante
  • 65. 10.0.0.0/16 10.0.0.0/16 PCX-1 PCX-2 Subnet 1 10.1.1.0/24 Subnet 2 10.1.2.0/24 10.1.0.0/16 Route Table Subnet 1 Destination Target 10.1.0.0/16 local 10.0.0.0/16 PCX-1 Route Table Subnet 2 Destination Target 10.1.0.0/16 local 10.0.0.0/16 PCX-2 A B C
  • 66. 10.0.0.0/16 10.0.0.0/16 PCX-1 PCX-2 Subnet 1 10.1.1.0/24 Subnet 2 10.1.2.0/24 10.1.0.0/16 Route Table Subnet 1 Destination Target 10.1.0.0/16 local 10.0.1.11/32 PCX-1 Route Table Subnet 2 Destination Target 10.1.0.0/16 local 10.0.0.0/16 PCX-2 A B CSubnet 3 Route Table Subnet 3 Destination Target 10.0.0.0/16 local 10.1.1.0/24 PCX-1 10.0.1.11 Route Table Subnet 1 Destination Target 10.1.0.0/16 local 10.0.0.0/16 PCX-1
  • 67. 10.1.0.0/16 10.0.0.0/16 10.0.0.0/16 10.3.0.0/16 172.16.0.0/16 192.168.0.0/16 10.2.0.0/16 172.17.0.0/16 CA
  • 68. 10.1.0.0/16 10.0.0.0/16 10.0.0.0/16 10.3.0.0/16 172.16.0.0/16 192.168.0.0/16 10.2.0.0/16 172.17.0.0/16 company data center 10.10.0.0/16
  • 69. 10.1.0.0/16 10.0.0.0/16 10.0.0.0/16 10.3.0.0/16 172.16.0.0/16 192.168.0.0/16 10.2.0.0/16 172.17.0.0/16 company data center 10.10.0.0/16
  • 70. 10.0.0.0/16 10.0.0.0/16 172.16.0.0/16 192.168.0.0/16 172.17.0.0/16 10.1.0.0/16 10.2.0.0/1610.3.0.0/16
  • 71. 10.0.0.0/16 10.0.0.0/16 10.3.0.0/16 172.16.0.0/16 192.168.1.0/24 10.2.0.0/16 172.17.0.0/16
  • 72. AWS region Public-facing web app Internal company app #1 HA pair VPN endpoints company data center Vue 360… Internal company app #2 Internal company app #3 Internal company app #4 Services VPC • Service d’infrastructure communs placés dans un VPC. Internal company Dev Internal company QA AD, DNS Monitoring Logging • Peering 1-1 = Isolation des Apps • Les Security Groups et les ACLs réseau s’appliquent • Security Groups sont quand même rattachés à un seul VPC.
  • 73. Utilisez IAM pour définir et contrôler vos operations VPC Les « EC2 Run Resource Permissions » permettent : • Quelle AMI peut être instanciée • Quel VPC ou subnet peut être manipulé • Quels Security Groups doivent être mis en place • Quels VPC autorisent le Peering http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html Pour des exemples de stratégies IAM :
  • 74. AWS region Public-facing web app HA pair VPN endpoints Customer data center AWS region Prod QA Dev
  • 75. Garder le contact
  • 76. Customer data center Point de présence AWS Direct Connect La Private Virtual Interface (PVI) de AWS Direct Connect relie la VGW du VPC • 1 PVI par VPC • Les Tags VLAN 802.1Q isolent le trafic dans le lien AWS Direct Connect Connexion fibre privée Multiple de 50 – 500 Mbps, 1 Gbps or 10 Gbps Simplifier l’accès avec AWS Direct Connect Public-facing web app AWS region Prod QA Dev
  • 77. Un point sur AWS Direct Connect… • Connexions privées, dédiées vers AWS • Interfaces privées (VPC) ou publiques vers AWS • Données sortantes moins chères que sur internet (données entrantes toujours gratuites) • Performances réseau constantes en comparaison d’internet • Au moins un point de présence par région AWS • Vous pouvez même redonder vos connexions • Plusieurs comptes AWS peuvent partager une même connexion
  • 78. Evolution des architectures VPC • Concepts d’architecture VPC • NAT fiable et évolutif • Un VPC, Deux VPC, … • Contrôle des frontières • VPC Peering • Garder le contact
  • 79. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Témoignage eFront Laurent Delhomme, Olivier Paillon
  • 80. Qui sommes nous • Olivier Paillon – Fondateur de Waterton Consulting – 17+ ans d’expèrience dans l’infrastructure et la transformation de SI • Laurent Delhomme – DSI adjoint – 17+ ans d’expèrience dans l’infrastructure et la transformation de SI – Accompagne la croissance d’eFront depuis 7 ans
  • 81. La Mission d’eFront • Editeur de logiciel dans le monde de la finance • Supporter l’industrie des investissements alternative • Du front office au back office • Aide à la décision d’investissement
  • 82. eFront en quelques lignes 15 20 27 37 55 64 2008 2009 2010 2011 2012 2013 (Million Euro €) 30% CAGR. Profitable. • 700+ clients dans 40+ pays • 500+ employés dans 20 bureaux • Reconnu comme in leader Européen : • Ernst & Young survey “preferred vendor for European Fund Admin”
  • 83. Une présence globale Beijing Montreal Boston London Jersey Paris Cologn e Dubai Hong Kong Singapore Dallas Abu Dhabi San Francisco Mumba i Tamp a Chicago Luxembour g eFront office Client presence Sydney New York Belgrade
  • 84. La stratégie datacenter d’eFront • Impératif : consolidation des datacenters • Couverture mondiale • Haut niveau de certification • Multiplateforme / ouvert • Transition par hybridation • Time to market
  • 85. Le cas des VLAN / l’objectif isolation • L’isolation par vlan est incontournable dans nos datacenters … mais non disponible dans une VPC • Un modèle matriciel ACL Network + Security Group couvre ce besoin
  • 86. Un cas concret chez eFront Web server Database server Load balancer Web server Database server Load balancer SG-ELB Allow TCP 443 from 0.0.0.0/0 SG-WSRV Allow TCP 443 from SG-ELB SG-DBSRV Allow 1433 from SG-WSRV WebApp1 WebApp2 Subnet webapp1 / CIDR 10.40.100.0/24 Subnet webapp2 / CIDR 10.40.102.0/24 VPC CIDR: 10.40.0.0 /16 Subnet webapp1 / CIDR 10.40.100.0/24
  • 87. Les + de la solution • Absence de gateway interne – Pas de limitation du modèle en étoile • Limite des interfaces • SPOF et complexité de la gestion des changements – Montée en charge linéaire – Sauvegarde linéaire • Lecture matricielle • Auditable
  • 88. Les enseignements • Nouvelles opportunités • Accompagnement au changement – Nouvelles pratiques
  • 89. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Evolution des architectures VPC Pierre Gilot. 13 Mai 2014 Merci !