AWS Paris Summit 2014 - T3 - Evolution des architectures VPC

© 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

Avertissement :

Faites ceci chez vous!

Toutes ces architectures

sont mises en œuvre par

de vrais clients!

Concevez…

puis epuisez vous à déployer vos infrastructures

Déployez des datacenters virtuels à la vitesse à

laquelle vous les concevez

version

Route Table Elastic Network

Interface Amazon VPC Router

Internet

Gateway

Customer

Gateway Virtual

Private

Gateway

VPN

Connection Subnet

Elements d’une architecture VPC

Availability Zone A Availability Zone B

Subnet

Availability Zone A

Subnet

Availability Zone B

VPC CIDR: 10.1.0.0 /16

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

Public Subnet

Private Subnet

Public Subnet

Availability Zone B

Private Subnet

VPC CIDR: 10.1.0.0 /16

Availability Zone A

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

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

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

Laissez la Main Route Table

tranquille!

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

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

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

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 :

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

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"

}

}

}

]

}

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

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

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

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

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

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

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

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

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

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

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

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

NAT disponible et évolutif

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

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

• With public IPs, web servers initiate outbound requests directly to Amazon S3

• NAT device still in place for private subnets

• 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

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”):

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

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”):

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

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

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": "*"

}

]

}

Automatiser la Haute Disponibilité des

NAT avec les User Data EC2

Latest version of the script:

https://github.com/ralex-aws/vpc

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

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

Un VPC, Deux VPC

AWS

region

Approche multi-VPCs

Public-facing

web app

Internal

company

app

What’s next?

VPN

connection

Customer

data center

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

Contrôle aux frontières…

AWS

region

Application interne déployée dans un VPC

Public-facing

web app

Internal

company

app

VPN

connection

Customer

data center

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

Mais… votre application stocke ses données là!

Amazon S3

Availability Zone A


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

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

Availability Zone A


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

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

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.

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

HTTP://AWS.AMAZON.COM/ARTICLES/5995712515781075

AWS region

Public-facing

web app

Internal

company

app

What’s next?

VPN

connection

Customer data center

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 gateways (CGW):

• 1 par tunnel VPN

• 1 IP publique par CGW

• AWS fournit 2 terminaisons

de tunnel par region

Public-facing

web app

Internal

company

app #2

HA pair VPN

endpoints Customer data center

Internal

company

app #3

Internal

company

app #4

Internal

company

app #1

Internal

company

Dev

Internal

company

QA

AWS region

Backup AD, DNS Monitoring

Logging

AWS

region

Public-facing

web app

Internal

company

app #1

HA pair VPN

endpoints


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.

VPC Peering

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

10.1.0.0/16

10.0.0.0/16 10.0.0.0/16

✔

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

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


Destination Target

10.1.0.0/16 local

10.0.0.0/16 PCX-2

A

B C

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


Destination Target

10.1.0.0/16 local

10.0.1.11/32 PCX-1


Destination Target

10.1.0.0/16 local

10.0.0.0/16 PCX-2

A

B C Subnet 3


Destination Target

10.0.0.0/16 local

10.1.1.0/24 PCX-1

10.0.1.11


Destination Target

10.1.0.0/16 local

10.0.0.0/16 PCX-1

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

C A

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

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

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/16 10.3.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.1.0/24

10.2.0.0/16

172.17.0.0/16

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.

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 :

AWS

region

Public-facing

web app

HA pair VPN

endpoints


AWS

region Prod QA Dev

Garder le contact

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

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


• Concepts d’architecture VPC

• NAT fiable et évolutif

• Un VPC, Deux VPC, …

• Contrôle des frontières

• VPC Peering

• Garder le contact


Témoignage eFront

Laurent Delhomme, Olivier Paillon

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

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

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”

Une présence globale

Beijing

Montreal Boston

London

Jersey

Paris

Cologne

Dubai

Hong Kong

Singapore Dallas

Abu Dhabi

San Francisco

Mumbai

Tampa

Chicago Luxembourg

eFront office

Client presence Sydney

New York

Belgrade

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

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

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


VPC CIDR: 10.40.0.0 /16


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

Les enseignements

• Nouvelles opportunités

• Accompagnement au changement – Nouvelles pratiques



Pierre Gilot.

13 Mai 2014

Merci !

Technology

AWS Paris Summit 2014 - T3 - Evolution des architectures VPC