Track 3 - Session 2 : Evolution des architectures VPC

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 !