AWS VPC centralisée ou VPC dans les comptes projets : Quand, Pourquoi et Comment ?

Bien que le partage d'Amazon Virtual Private Cloud (VPC) soit disponible depuis fin 2018, il est encore rare de le voir déployé dans les landing zones.

Cette possibilité peut apporter de nombreux gains en termes d'organisation et de répartition des tâches entre les équipes, des économies non négligeables, et une implémentation réseau alignée avec le modèle opérationnel de l'entreprise. Nous allons voir ensemble les points qui vont pousser l'adoption de cette implémentation à la place d'une implémentation décentralisée, qui elle est le reflet d'une organisation plus orientée DevOps.

Les Challenges

Les VPCs sont difficilement extensibles, et il est compliqué de réorganiser les ressources qui sont à l'intérieur. Il est donc nécessaire de choisir la bonne implémentation dès la mise en place de la landing zone.

Il est également important de n'avoir aucun VPC avec un CIDR block (ensemble d'IP) identique, ce qui rendrait le routage complexe.

Dans les grands groupes, une portion importante des IP privées ont été consommées. Souvent un CIDR Block /16 est assigné à un cloud provider, ce qui nécessite une réflexion importante pour organiser les VPCs et les subnets.

L'organisation de l'entreprise est aussi importante. La responsabilité du réseau peut être assumée par différentes équipes, et il est important que les politiques IAM reflètent ces responsabilités. Pour faciliter ces règles IAM, une organisation des comptes AWS rigoureuse est nécessaire.

La maîtrise des coûts et la sécurité sont les deux derniers domaines qui influencent l'organisation réseau. Comme nous le verrons plus loin, les liaisons réseaux ont un coût non négligeable et peuvent à l'échelle devenir un problème financier.

VPC par compte, le modèle par défaut

Chaque compte AWS étant indépendant, nous pouvons donc aisément créer une infrastructure réseau indépendante. Un VPC par défaut est fourni dans chaque compte, je vous déconseille de l'utiliser dans votre landing zone.

Il est donc aisé de créer les ressources réseau pour un projet lors de son déploiement. Nous avons un tout cohérent, et si nous devons terminer le projet, nous pourrons détruire toutes les ressources liées. C'est également ce que l'on retrouve sur de nombreux modèles de projet (blueprint). En créant tous les éléments, du réseau à l'application, on s'assure que tous les éléments seront conformes et fonctionnels.

Ce modèle est également apprécié car il fait écho à la philosophie DevOps, où l'équipe projet est responsable de son périmètre.

Modèle centralisé

Le but de ce modèle est d'éviter le morcellement de la partie réseau. Dans ce modèle, nous allons créer un nombre limité de VPC, qui se trouveront dans le compte AWS gérant le réseau. Il y aura au moins 2 VPCs, un pour la production et un pour la non-production. Cela permettra de gérer les flux entre ces 2 zones, et rassurera les équipes sécurité. Le modèle de sous-réseau (Subnets) sera le même que pour le modèle décentralisé, c'est la taille de ces subnets qui sera supérieure. Ces subnets seront ensuite partagés avec les comptes projets pour qu'ils puissent les utiliser.

Ce modèle reflète le modèle opérationnel où les équipes réseau et sécurité sont responsables des fondations réseau. Les équipes projets ne sont qu'utilisatrices des ressources mises à disposition et vont créer les ressources projets dans les sous-réseaux fournis sans pouvoir modifier leur fonctionnement.

Critères de sélection

Plusieurs critères entrent en compte, les plus impactants sont en premier :

Besoin de contrôle et de conformité lié à des contraintes légales

Si la séparation des responsabilités est un prérequis et que le réseau est géré par une équipe spécialisée, un modèle centralisé est la solution à privilégier. Chaque projet aura son compte AWS, mais ils ne pourront pas créer de composants réseau au sein de ces comptes.

Si la responsabilité du réseau est portée par le projet et non par une équipe centrale, un modèle décentralisé sera le meilleur choix. Il faudra néanmoins déployer des outils permettant de vérifier la conformité à l'échelle. Ces outils devront être capables de récupérer et d'agréger des données venant de nombreux comptes.

Modèle opérationnel et responsabilité des équipes

Les mêmes arguments que la partie précédente sont à utiliser pour choisir le modèle. La seule différence est que ce n'est pas un besoin externe qui impose le choix, mais le fonctionnement de l'entreprise.

Il faut rester vigilant sur ce choix et penser à la transformation de l'entreprise en passant dans le cloud et la trajectoire pour les prochaines années.
Vous pouvez avoir un modèle centralisé car vous êtes en cours de migration depuis le on-premise, mais la stratégie d'entreprise est de devenir plus agile en laissant les projets porter leur responsabilité de bout en bout. Dans ce cas, un modèle décentralisé sera à privilégier, avec un accompagnement des équipes opérations / sécurité / réseau pour leur permettre d'évoluer et de s'inscrire dans le nouveau modèle opérationnel.

Maîtrise des coûts

Un modèle décentralisé repose sur l'utilisation de la Transit Gateway pour passer à l'échelle. Mais ce modèle a un coût non négligeable, lié au nombre de VPC qui vont être créés.

Si la consommation de services AWS par VPC est faible (moins de 250$ par exemple, dans ce cas le réseau représente plus de 20% des dépenses), il est intéressant d'évaluer la possibilité de passer sur un modèle centralisé.

Un modèle décentralisé permettra également de plus facilement répartir les coûts par projets. Les ressources n'étant pas mutualisées et un compte AWS n'étant lié qu'à un projet, la somme des consommations par projet sera donc aisée.

Maturité de la société sur AWS

Si vous débutez sur AWS et que vous migrez depuis le on-premise, un modèle centralisé peut être rassurant car plus proche de ce que vous avez on-premise.

Si vous êtes une société en création, que vous voulez être agile et que vous n'avez pas une équipe réseau dédiée, un modèle décentralisé vous apportera plus de souplesse. Cela vous permettra par exemple de proposer de nouveaux produits, et s'ils ne trouvent pas leur public, vous n'aurez qu'à détruire le ou les comptes AWS associés pour ne plus avoir de dépenses.

Gestion des IPs

Si la gestion des IPs est un enjeu, et que chaque IP compte car votre entreprise a consommé presque toutes les possibilités d'adressage IP privé, il est recommandé de passer sur un modèle centralisé qui permettra de ne perdre que très peu d'IPs.

Si votre SI est d'une taille modeste, les 2 modèles peuvent être utilisés, ce sont d'autres critères qui guideront vos choix.

Isolation forte des projets

Si vous devez isoler fortement des projets, par exemple si vous offrez une plateforme SaaS pour des clients, il est recommandé d'utiliser un modèle décentralisé. Les ressources réseau et projets de chaque client seront isolés dans un compte AWS, et vous pourrez également ajouter du filtrage réseau au niveau de la Transit Gateway.

Mise en place de la VPC centralisée

Organisation des VPCs

Nous pouvons organiser les VPCs de différentes manières.

La première solution, la plus simple, est de faire une VPC pour la production et une autre pour la non-production. L'avantage est que les IPs pour la production sont réservées, nous pouvons contrôler les flux entre les deux VPCs.

La seconde solution est de faire un VPC par environnement. Cela permet un meilleur contrôle des flux est-ouest, et une garantie d'un nombre d'IP par environnement.

Nous ajouterons une VPC supplémentaire pour les outils réseau comme les points de terminaison VPC (VPC Endpoints), la gestion DNS ou la gestion de l'Egress, quelle que soit la solution proposée. Ainsi, nous mutualisons les coûts des VPC Endpoints et de l'Egress.

Les VPCs doivent être suffisamment grandes pour répondre à vos besoins en IP pour les années à venir. Il est possible d'étendre une VPC, mais cela reste une opération qui va ajouter de la complexité à votre landing zone.

Exemple

Vous avez 4 environnements : production, recette, intégration et développement. Vous avez à disposition un CIDR block 10.0.0.0/16

Première solution

• un VPC de production 10.0.0.0/18
• un VPC de non-production (recette, intégration et développement) 10.0.128.0/17
• il reste 10.0.64.0/18 pour les VPCs réseau, sandbox, ou les services partagés

Seconde solution

• un VPC de production : 10.0.0.0/19
• un VPC de recette (iso prod) : 10.0.64.0/18
• un VPC d'intégration : 10.0.128.0/19
• un VPC de développement : 10.0.160.0/19
• il reste 10.0.192.0/18 pour les VPCs réseau, sandbox, ou les services partagés

Partage des subnets

Nous avons plusieures stratégies pour le partage des subnets.

1 - Centralisation des VPCs dans le compte réseau

C'est le modèle le plus simple, la séparation en VPC projet est conservée, la différence est que les VPCs se trouvent dans le compte réseau.

L'avantage de cette technique est qu'elle simplifie la gestion IAM pour le réseau, on s'assure ainsi que les projets ne pourront pas modifier les fondations mises en place.

2 - Un seul VPC, des subnets indépendants pour chaque compte

Ce modèle assure une isolation stricte entre les comptes, car chaque subnet est lié à un seul compte AWS. Ainsi il n'y a pas de risque de manque d'IP venant d'un autre projet, les coûts d'interconnexions sont réduits car on a moins de VPCs.

Pour assurer une isolation parfaite, il est recommandé d'ajouter des listes de contrôle d'accès réseau (NACL) aux sous-réseaux pour ne laisser passer que les flux venant de sous-réseaux légitimes.

Cela ne facilite toujours pas suffisamment la gestion des adresses IP. Nous avons toujours des adresses IP utilisées dans chaque sous-réseau, et si nous n'avons plus d'adresses IP disponibles sur un sous-réseau, il faudra utiliser un nouveau sous-réseau pour étendre la plage d'adresses IP.

Cela nécessite encore de trouver la ou les bonnes tailles de sous-réseaux pour les projets, afin de réduire le nombre d'adresses IP non utilisées.

3 - Un seul VPC, des sous-réseaux partagés entre tous les comptes d'un même environnement

Dans cette solution, nous avons un petit nombre de sous-réseaux de grande taille partagés entre les comptes. L'isolation est en place par design, nous le verrons un peu plus bas, et avec ce modèle nous obtenons une zone de travail où aucune IP ne sera potentiellement inutilisée, et il n'est plus nécessaire de réfléchir longuement à la taille de chacun des sous-réseaux.

Tout comme la solution précédente, le nombre d'interconnexions réseau est réduit au strict minimum pour maîtriser les coûts.

Responsabilité partagée

Comme nous l'avons vu plus haut, le modèle de VPC doit refléter le modèle de responsabilité entre les équipes. AWS a fait le nécessaire au niveau des droits, pour que cette séparation soit claire. Source : Responsibilities and permissions for owners and participants

Responsabilité du compte qui partage

• Il est responsable de la création, de la gestion et de la suppression des ressources associées à un VPC partagé (sous-réseaux, tables de routage, passerelles NAT, etc.).
  La liste complète est disponible dans la documentation, et l'on peut vérifier que ce ne sont que des composants de réseau, sécurité et routage qui peuvent être gérés.

• il ne peut pas modifier les interfaces réseau appartenant aux participants (attacher, détacher...).
  Les interfaces sont visibles dans le compte qui partage, ce qui a du sens car les interfaces utilisent les IPs du compte. Les informations sont limitées, on ne sait rien sur la ressource liée.

• il peut visualiser les groupes de sécurité créés par les participants.
  Le principe d'observabilité est respecté, et les responsables du réseau et de la sécurité peuvent examiner facilement ce qui est implémenté. Dans l'exemple ci-dessous, nous pouvons voir des groupes de sécurité liés à d'autres comptes avec la mention shared entre parenthèses.
  Exemple :
  

• il peut attacher une passerelle de transit à un sous-réseau VPC partagé.
  Le principe de responsabilité est bien respecté, et cela évite des dérives de sécurité (cartographie des flux) et financières (prix de l'attachement, coûts de trafic)

Responsabilité des comptes qui utilisent le partage

• ils sont responsables des ressources VPC dont ils sont propriétaires.
  Tout est dit, on respecte bien le modèle de responsabilité partagée entre le compte qui partage et les comptes qui utilisent les sous-réseaux

• ils ne peuvent créer qu'un ensemble limité de ressources VPC : groupes de sécurité, journaux de flux VPC (sur leurs interfaces réseau).

• Les ressources VPC créées par un participant sont comptabilisées dans les quotas VPC du compte participant.

• Les participants ne peuvent pas créer, attacher ni supprimer de passerelles Internet.
  Cela nous assure qu'il n'y aura pas d'exposition publique incontrôlée.

• Les participants ne peuvent pas créer ni supprimer de NAT Gateway.
  On évite ainsi des coûts non maîtrisés (35$ par mois). Ce sont des éléments de routage que les équipes réseaux doivent mettre en place, que les NAT Gateway soient privées ou publiques. Les équipes projet ne sont qu'utilisatrices de ces services.

• Les participants ne peuvent pas créer, supprimer ni remplacer de listes de contrôle d'accès réseau (NACL)
  La sécurité du réseau est la responsabilité des équipes réseau et sécurité. Personne dans le compte participant ne pourra unilatéralement modifier des règles de filtrage réseau.

• Les participants peuvent visualiser les NACL
  Le filtrage mis en place peut être visualisé par l'équipe projet (transparence) et peut ainsi permettre de comprendre pourquoi certains composants ne peuvent pas communiquer ensemble. Cela évite des frustrations et peut faciliter le travail des équipes réseau qui pourront avoir des indications claires des équipes projet.

• Les participants ne peuvent pas travailler sur des tables de routage (par exemple, créer, supprimer ou associer des tables de routage)
  Tous les éléments réseau sont bien gérés pour que le partage de responsabilité soit respecté par défaut.

• Les participants ne peuvent pas utiliser le groupe de sécurité par défaut du VPC
  Ce n'est pas une bonne pratique d'utiliser le groupe de sécurité par défaut d'un VPC.
  La bonne pratique est de laisser ce groupe de sécurité sans règle, ce qui bloque tout le trafic entrant et sortant. Donc ne pas pouvoir utiliser ce groupe de sécurité ne posera pas de problème.

• Les participants ne peuvent pas utiliser de groupes de sécurité qui appartiennent au propriétaire du VPC ou à d'autres participants, à moins que le groupe de sécurité ne soit partagé avec eux.
  Les règles des groupes de sécurité peuvent référencer un groupe de sécurité d'un autre compte. Ce qui permet de gérer via des noms les flux entre les applications. Il est nécessaire d'interdire l'utilisation d'un groupe de sécurité extérieur au compte car les règles liées à celui-ci pourraient être changées sans que le compte qui l'utilise soit informé.

Répartition des coûts

Dans un VPC partagé, chaque participant paie ses ressources applicatives. Ils paient également les frais de transfert de données entre zones de disponibilité, via les passerelles Internet et les passerelles AWS Direct Connect.

Les propriétaires de VPC paient des frais horaires ainsi que des frais de traitement et de transfert de données via les passerelles NAT, la Transit Gateway, PrivateLink et les points de terminaison VPC.
Les adresses IPv4 publiques utilisées dans les VPC partagés sont facturées aux propriétaires de VPC.

Limites et points d'attention

Tags

• Les tags des groupes de sécurité créés dans un compte ne sont pas visibles dans les autres comptes.
  Nous ne pouvons pas profiter nativement des informations originales. Nous pouvons recréer de nouveaux tags sur ces groupes de sécurité et leurs règles dans le compte utilisant le sous-réseau via une Lambda par exemple.
  Exemple :
  • dans le compte utilisant un sous-réseau partagé :
    
  • dans le compte qui partage le sous-réseau :
    

Modèle centralisé et zones de disponibilité

Dans le modèle centralisé, comme le trafic ne quitte pas le VPC, vous ne payez pas de frais de réseau supplémentaires, mais uniquement les éventuels frais de réseau inter-zones.

Il est important de noter que tous les comptes AWS disposent d'un mappage de zones de disponibilité aléatoire. Ainsi, la zone de disponibilité A du compte A peut être la zone de disponibilité B du compte B. Lors de l'utilisation d'un VPC partagé, il est important d'en tenir compte pour limiter les frais de réseau inter-zones. Une bonne utilisation des tags peut réduire ces coûts en nommant de manière claire les sous-réseaux en s'appuyant sur l'ID de zone de disponibilité.

Que se passe-t-il si le partage est coupé ?

Le propriétaire peut à tout moment annuler le partage d'un sous-réseau partagé. Une fois le partage d'un sous-réseau annulé, les règles suivantes s'appliquent :

• Les ressources existantes des participants continuent de s'exécuter dans le sous-réseau.
• Les participants ne peuvent plus créer de ressources dans le sous-réseau.
• Les participants peuvent modifier, décrire et supprimer leurs ressources.
• Si des participants disposent encore de ressources dans le sous-réseau, le propriétaire ne peut pas supprimer le sous-réseau partagé ni le VPC du sous-réseau partagé.

Pour conclure

Ces deux modèles sont complémentaires et répondent chacun à des besoins spécifiques.

Vous pouvez également appliquer chacun de ces modèles à une partie de votre système d'information.
Si vous avez par exemple des applications que vous voulez déplacer à partir du on-premise et que vous ne pouvez pas transformer, vous pouvez les héberger sur un VPC centralisé. Pour les nouveaux projets, vous pouvez utiliser un modèle décentralisé qui apporte plus de souplesse aux équipes de développement.

Il est important de choisir le modèle qui correspond à vos besoins (légaux, opérationnels, ...), qui soit efficace et aligné avec votre savoir-faire, plutôt que d'utiliser un modèle à la mode qui, au final, vous amènera à des coûts élevés et à des opérations plus complexes et coûteuses.