Réseautique centre de données et infonuagique

Le problème que règle une conception de réseau hybride

Situation courante : la connectivité a grandi un tunnel VPN et un appairage à la fois, jusqu’à ce que le routage devienne un mystère, que le DNS se comporte différemment selon l’emplacement, et qu’une seule personne puisse le déboguer. Cause profonde : une connectivité développée de façon organique, sans conception centrale de routage, de DNS ni de segmentation, produit des chemins non documentés, des CIDR qui se chevauchent et une confiance à plat entre les environnements ; rien de tout cela n’est en code, on ne peut donc ni le raisonner ni le reconstruire.

Ce que vous possédez à notre départ

• Du Terraform/IaC pour le tissu de connectivité dans la portée (routage transit/hub, VPN/Direct Connect/interconnexion, appairage, tables de routage).
• Une conception unifiée de DNS et de résolution (résolution de noms cohérente entre le sur site et les clouds), sous forme de code.
• Un modèle de segmentation qui borne le rayon d’impact entre les environnements et les paliers, appliqué et documenté.
• Des diagrammes de réseau clairs générés à partir de l’IaC réel / maintenus synchronisés avec lui — pas un Visio ponctuel.
• Des guides d’exploitation pour ajouter un site/VPC/cloud, et un plan d’adressage IP/CIDR documenté.
• Des ADR pour les décisions de routage et de segmentation.

Pas un rapport d’évaluation de réseau. Un réseau que vous pouvez reproduire à partir du code et étendre en toute sécurité.

Notre façon de procéder

1. 01

   Découverte

   Nous lisons directement vos comptes, vos configurations et vos contraintes (accès en lecture seule à portée définie ou état exporté), nous cartographions l’état actuel réel et nous convenons d’une portée écrite et de critères de réussite avant d’écrire la moindre ligne de code.

2. 02

   Registres de décisions d’architecture (ADR)

   Nous consignons les décisions clés — ce que nous faisons, les options écartées et les raisons — sous forme d’ADR dans votre dépôt, afin que le raisonnement survive longtemps après notre départ et que vous puissiez le remettre en question avant que nous construisions quoi que ce soit.

3. 03

   Implémentation

   Nous bâtissons la solution sous forme de Terraform/IaC révisable, dans de petites pull requests testées et intégrées à votre CI, pour que vous la voyiez arriver progressivement et que rien ne débarque comme une boîte noire.

4. 04

   Transfert

   Nous guidons votre équipe en direct à travers le dépôt, le modèle de menaces et les guides d’exploitation, nous confirmons que vous pouvez l’appliquer, le détruire et l’étendre vous-mêmes, puis nous partons. Vous êtes propriétaires de tout : il n’y a pas de phase 5 où vous avez encore besoin de nous.

Forme du mandat

Une construction/refonte à portée fixe sur un ensemble défini de sites, de clouds et de connexions — livrée sous forme de Terraform avec une conception de routage/DNS/segmentation testée et une passation en direct. La portée est déterminée par le nombre d’environnements et de connexions en jeu, convenu par écrit d’abord.

Un exemple illustratif du format

# network/transit.tf — hub: explicit routing, no flat mesh
resource "aws_ec2_transit_gateway" "hub" {
  description = "on-prem + cloud hub"

  # No implicit any-to-any: every attachment is associated and
  # propagated deliberately, per environment.
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"
}

# Prod and non-prod live in separate route tables: non-prod reaches
# shared services and on-prem, never prod.
resource "aws_ec2_transit_gateway_route_table" "env" {
  for_each           = toset(["prod", "nonprod", "shared"])
  transit_gateway_id = aws_ec2_transit_gateway.hub.id
  tags               = { Name = "rt-${each.key}" }
}