↓Zum Hauptinhalt springen
Hardik Mehta - GEN AI, Cloud, Security Architekt
DE

EN

DE

  1. Projekte/

AWS Transit Gateway

Hardik Mehta
Autor
Hardik Mehta
Ein visionärer Softwarearchitekt mit einer Leidenschaft für die Lösung realer Probleme.

Einführung
#

AWS Transit Gateway ist ein verwalteter Dienst, der 2018 eingeführt wurde und Konnektivität und Routing zwischen verschiedenen VPCs und On-Premises-Netzwerken bietet.

  • Mehrere VPCs (mit einfacher Konfiguration und der Möglichkeit, neue VPCs hinzuzufügen, ohne neue Gateways oder Peering zu konfigurieren)
  • Über mehrere Regionen hinweg
  • Unternehmensdatenzentren (Kundensite) mit Customer Gateways
  • Direct Connect

Typische Architektur
#

Typische Architektur
Typische Architektur

Site-to-Site VPN
#

[[Site-to-Site VPN]] kann auch mit dem Transit Gateway anstelle des Virtual Private Gateway erreicht werden. Das VPG kann nur an eine VPC angehängt werden, während das Transit Gateway die Verbindung der Kundensite mit mehreren VPCs ermöglicht. Darüber hinaus bietet es auch die Konnektivität zwischen diesen mehreren VPCs, ohne dass ein zusätzliches [[VPC Peering]] erforderlich ist. Das AWS Transit Gateway kann als Hub fungieren, der mehrere VPCs, Site-to-Site-VPN, Direct Connect und andere Regionen über verschiedene AWS-Konten hinweg verbindet (unter Verwendung von Transit Gateway Peering)

Beispielübersicht
#

Beispielübersicht
Beispielübersicht

Das obige Beispiel umfasst 2 Szenarien der Nutzung des Transit Gateways

  1. Konnektivität zwischen 2 VPCs
  2. Konnektivität zwischen VPCs und Site-to-Site-Konnektivität, die beide VPCs umfasst

Terraform:
#

https://github.com/rangalo/aws-infra-tf/tree/main/hardik/transit-gw

resource "aws_ec2_transit_gateway" "eu-central-tgw" {
  amazon_side_asn                 = var.aws_asn
  default_route_table_association = "enable"
  default_route_table_propagation = "enable"

  tags = {
    terraform = "true"
    Name      = "eu-central-tgw"
  }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "dev-vpc-tgw-attachment" {
  subnet_ids         = [for s in module.networking1.private_subnets : s.id]
  transit_gateway_id = aws_ec2_transit_gateway.eu-central-tgw.id
  vpc_id             = module.networking1.vpc_id
}

resource "aws_ec2_transit_gateway_vpc_attachment" "prod-vpc-tgw-attachment" {
  subnet_ids         = [for s in module.networking2.private_subnets : s.id]
  transit_gateway_id = aws_ec2_transit_gateway.eu-central-tgw.id
  vpc_id             = module.networking2.vpc_id
}

AWS-Seiteneinrichtung
#

  1. VPC 1 DEV - CIDR 10.0.0.0/16

  2. VPC 2 PROD - CIDR 10.1.0.0/16

  3. Customer GW mit öffentlicher IP der Libreswan-Instanz in einem anderen AWS-Konto, das als Kundendatenzentrum (Site) fungiert

  4. Transit Gateway

    1. Transit Gateway-Anschluss zu VPC1 für jedes Subnetz in jeder AZ (Availability Zone), nennen wir sie tgw-attachment-vpc1, tgw-attachment-vpc-2
    2. VPN-Verbindung konfiguriert mit CGW-ID und TGW-ID mit statischem Routing. Dies wird automatisch einen TGW-Anschluss erstellen, den wir vorerst tgw-attachment-vpn nennen

  5. Routing Es ist wichtig, das Routing mit Transit Gateways zu verstehen.

    Das TGW wird mit einer Standard-Routingtabelle geliefert, die mit allen Anhängen verknüpft ist und auch propagiert wird. Da wir in unserem Beispiel statische Routen verwenden, müssen wir die statische Route für den VPN-Anschluss zur Standard-TGW-Routingtabelle hinzufügen.

Ziel CIDRZielAutomatisch hinzugefügt?
10.0.0.0/16tgw-attachment-vpc-1Ja
10.1.0.0/16tgw-attachment-vpc-2Ja
172.31.0.0/16tgw-attachment-vpnNein

Jede VPC benötigt auch eine Rückwärtsroute zum TGW. Die Routingtabelle jedes Subnetzes (das die Konnektivität benötigt) sollte zusätzlich die folgenden Routen enthalten.

Ziel CIDRZiel
10.0.0.0/8tgw_id
172.31.0.0/16tgw_id

Kundenseitige (Site) Einrichtung
#

  1. Verwendung des Standard-VPC - CIDR 172.31.0.0/16
  2. EC2-Instanz namens openswan (da openswan nicht verfügbar ist, installieren wir libreswan), das mit user-data installiert wurde.
  3. Eine weitere EC2-Instanz zum Testen der Konnektivität mit Ping.
  4. Routing: Die Standard-Routingtabelle des Standard-VPC muss eine Route enthalten, um den gesamten für das AWS-Netzwerk bestimmten Datenverkehr, sowohl die VPCs, zur openswan-Instanz weiterzuleiten.
Ziel CIDRZiel
10.0.0.0/8default_network_interrface_of_openswan_ec2_instance

Einrichtung der Site (VPN-Client mit libreswan)
#

Gleich wie in [[Site to Site VPN]] beschrieben.

Feineinstellung der Konnektivität
#

Das obige Beispiel bietet eine Standardkonnektivität zu allen beteiligten Netzwerken vpc1, vpc2 und vpn. Durch Bereitstellung einer separaten Routingtabelle für jeden Anschluss kann eine sehr feine Konnektivität erreicht werden, z. B. durch Isolierung bestimmter Netzwerke (z. B. vpc2).

Darüber hinaus kann der Zugriff auf das öffentliche Internet über ein bestimmtes VPC geleitet werden, um die Anzahl der NAT-Gateways zu reduzieren und damit die Kosten zu senken. Beispiel: https://aws.plainenglish.io/aws-transit-gateway-101-how-it-works-and-when-to-use-it-65c4369bcdb6

References:
#