Einheit 2.3: Lastverteilung und Security as Code

Einführung

Der TaskBoard-Netzwerkstack aus Einheit 2.2 besteht aus drei miteinander verbundenen Ebenen: einem öffentlichen LAN, einem Anwendungslan und einem Datenbank-LAN. Die API-Server sind im App-LAN erreichbar, aber es gibt noch kein Frontend für sie und nichts filtert den Traffic, der ihre NICs erreicht. In dieser Einheit provisionieren Sie die Edge-Ebene.

Sie setzen einen Managed Application Load Balancer vor die API, um HTTP-Anfragen über die App-Server mit pfadbasierter Routing-Logik zu verteilen. Sie erfahren, wann ein Network Load Balancer das richtige Werkzeug ist, und Sie sichern jede Ebene mit Network Security Group-Regeln. Die wichtige IONOS CLOUD-spezifische Lektion in diesem Zusammenhang ist, wo Sicherheit tatsächlich greift: NSGs gelten auf Server-NIC-Ebene, niemals für den Load Balancer und niemals für Managed Kubernetes-Knoten. Wenn Sie das falsch verstehen, werden Sie Stunden damit verbringen, sich zu fragen, warum Ihre Firewall-Regeln keinen Einfluss auf den Traffic haben, der über den ALB eintrifft. Alles in dieser Einheit ist Code: Terraform-Ressourcen und die zugrunde liegenden Cloud API-Aufrufe.

1. Application Load Balancer as Code

Die ionoscloud_application_loadbalancer-Ressource provisioniert einen Layer-7-Load Balancer, der HTTP und HTTPS terminiert und anhand von Attributen auf Anwendungsebene routet. Der ALB befindet sich zwischen einem Listener-LAN, über das Clients ihn erreichen, und einem Target-LAN, in dem Ihre Backends hostet werden. Für die TaskBoard-API ist das Listener-LAN das öffentliche LAN und das Target-LAN das App-LAN.

Ein ALB besteht aus drei Ressourcentypen: dem Load Balancer selbst, einer oder mehreren Target Groups, die Backend-Targets registrieren, und Forwarding Rules, die einen Listener auf diese Targets abbilden. Eine Target Group ist eine logische Gruppierung registrierter Targets, wobei jedes Target ein beliebiges Objekt mit einer IP-Adresse in Ihrem VDC ist, beispielsweise eine VM oder ein anderer Load Balancer. Sie können dieselbe Target Group über mehrere Forwarding Rules hinweg wiederverwenden.

1.1 Provisionierung des Load Balancers und der Target Group

Beginnen Sie mit dem Load Balancer und einer Target Group. Jedes Target wird mit einer IP, einem Port und einem Gewicht registriert. Der Bereich für das Target-Gewicht ist 1 - 256, und Sie verwenden ihn, um anteilig mehr Traffic an größere Backends zu senden.

resource "ionoscloud_application_loadbalancer" "taskboard_api" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-api-alb"
  listener_lan  = ionoscloud_lan.public.id
  target_lan    = ionoscloud_lan.app.id
  ips           = [ionoscloud_ipblock.alb_ip.ips[0]]
}

resource "ionoscloud_target_group" "api_targets" {
  name      = "taskboard-api-tg"
  algorithm = "ROUND_ROBIN"
  protocol  = "HTTP"

  targets {
    ip                 = ionoscloud_server.api_1.nics[0].ips[0]
    port               = 8080
    weight             = 10
    health_check_enabled = true
  }
  targets {
    ip                 = ionoscloud_server.api_2.nics[0].ips[0]
    port               = 8080
    weight             = 10
    health_check_enabled = true
  }
}

Ein öffentlicher ALB erfordert eine reservierte öffentliche IP, weshalb das Argument ips auf eine ionoscloud_ipblock verweist. Die unterstützten Lastverteilungsalgorithmen sind Round Robin, Least Connections, Random und Source IP, wobei Round Robin als Standard festgelegt ist.

1.2 Weiterleitungsregeln und Listener

Weiterleitungsregeln definieren, wie der Client-Verkehr auf die Ziele verteilt wird, und für denselben Load Balancer können mehrere Regeln erstellt werden. Eine Weiterleitungsregel bindet eine Listener-IP und einen Port an eine HTTP-Regel, die übereinstimmende Anfragen an eine Zielgruppe weiterleitet.

resource "ionoscloud_application_loadbalancer_forwardingrule" "api_http" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  application_loadbalancer_id = ionoscloud_application_loadbalancer.taskboard_api.id
  name          = "taskboard-api-fwd"
  protocol      = "HTTP"
  listener_ip   = ionoscloud_ipblock.alb_ip.ips[0]
  listener_port = 80

  http_rules {
    name           = "forward-api"
    type           = "FORWARD"
    target_group   = ionoscloud_target_group.api_targets.id
  }
}

Der ALB unterstützt die Protokolle HTTP und HTTPS über HTTP1 und HTTP2. Neben der einfachen pfadbasierten Weiterumleitung umfassen die Routentypen die basierte Weiterleitung nach Hostname, Query-String, Header, Methode, Cookie, Quell-IP, URL-Umleitung sowie statische, feste Antworten. Ein ALB im Rahmen Ihres Vertrags kann 1 bis 10 Listener enthalten, und Sie können pro Vertrag bis zu 5 ALBs bereitstellen.

1.3 TLS, WebSocket und gRPC

Der ALB unterstützt das TLS-Offloading, sodass er HTTPS terminiert und plain HTTP an Ihre Backends weiterleitet, wodurch die Zertifikatsverarbeitung von Ihren Anwendungsservern entfernt wird. SNI wird unterstützt, wodurch ein einzelner Listener mehrere Zertifikate nach Hostname bereitstellen kann. WebSocket und gRPC werden beide unterstützt, sodass derselbe ALB sowohl eine REST API als auch einen Streaming-Endpunkt bedient, ohne einen separaten Proxy zu benötigen. Der rohe API-Aufruf zur Erstellung eines WebSocket-fähigen ALB richtet sich an die applicationloadbalancers-Sammlung:

curl -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN" \
  https://api.ionos.com/cloudapi/v6/datacenters/$DC_ID/applicationloadbalancers \
  -d '{"properties":{"name":"alb-websocket","listenerLan":1,"targetLan":2,"ips":["1.2.3.4"]}}'

2. Network Load Balancer als Code

Wenn Sie einen hohen L4-Durchsatz benötigen und keine Routing-Funktionen auf Anwendungsebene erforderlich sind, provisioniert die ionoscloud_networkloadbalancer-Ressource einen Load Balancer der Ebene 4. Der NLB arbeitet auf der OSI-Ebene 4 und verteilt TCP-Verkehr auf Ziele, ohne die Nutzlast zu untersuchen.

Der NLB verfügt über eine einzelne Listener-Schnittstelle, die mehrere IPs mit unterschiedlichen Weiterleitungsregeln unterstützen kann. Ein öffentlicher NLB ist dem Internet ausgesetzt und nimmt Client-Verbindungen direkt aus dem Internet an; er dient als Edge-Gerät für Nord-Süd-Verkehr. Die Lastverteilungsalgorithmen sind dieselben wie beim ALB: Round Robin, Least Connections, Random und Source IP.

2.1 Provisionierung eines NLB mit Weiterleitungsregeln

resource "ionoscloud_networkloadbalancer" "taskboard_nlb" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nlb"
  listener_lan  = ionoscloud_lan.public.id
  target_lan    = ionoscloud_lan.app.id
  ips           = [ionoscloud_ipblock.nlb_ip.ips[0]]
}

resource "ionoscloud_networkloadbalancer_forwardingrule" "tcp" {
  datacenter_id          = ionoscloud_datacenter.taskboard.id
  networkloadbalancer_id = ionoscloud_networkloadbalancer.taskboard_nlb.id
  name          = "taskboard-tcp-fwd"
  algorithm     = "SOURCE_IP"
  protocol      = "TCP"
  listener_ip   = ionoscloud_ipblock.nlb_ip.ips[0]
  listener_port = 5432

  targets {
    ip     = ionoscloud_server.db_1.nics[0].ips[0]
    port   = 5432
    weight = 1
  }

  health_check {
    client_timeout = 50000
    connect_timeout = 5000
    target_timeout  = 50000
    retries         = 3
  }
}

Das Protokollset des NLB beschränkt sich auf TCP; UDP wird nicht unterstützt, und HTTP-Health-Checks werden nicht unterstützt, sodass die Health-Checks auf TCP basieren. Die Sitzungsfestigkeit (Session Stickiness) am NLB verwendet Source-IP-Affinität: Eine Client-Sitzung verbleibt auf demselben Ziel, solange ihre TCP-Sitzungen aktiv sind. Das Standard-Gewicht der Ziele beträgt 1, mit einem Maximum von 256, und der Standardwert für Health-Checks ist 3 Wiederholungen. Sie können bis zu 5 NLBs pro Vertrag bereitstellen.

2.2 Auswahl zwischen ALB und NLB

Die Entscheidung wird davon bestimmt, auf welcher Ebene Ihre Routing-Anforderungen inspiziert werden müssen. Die folgende Tabelle fasst die beiden Optionen für Entscheidungen zur Code-Zeit zusammen:

Wählen Sie den ALB, wenn Sie nach URL-Pfad, Host oder Header routen, oder wenn Sie möchten, dass der Load Balancer TLS terminiert. Die TaskBoard-API verwendet einen ALB, damit /api/tasks und /api/health geroutet und TLS an der Kante terminiert werden kann. Wählen Sie den NLB für nicht-HTTP-TCP-Dienste, bei denen Sie eine L4-Verteilung mit minimalem Overhead wünschen und die Anwendung ihre eigenen Protokollaspekte behandelt.

3. Network Security Groups as Code

Eine Network Security Group ist eine zustandsbehaftete Firewall, die Sie Ihren VMs und NICs zuweisen. Die IONOS CLOUD-spezifische Regel, die alles in diesem Abschnitt regelt: NSGs werden auf Server-NIC-Ebene gebunden. Sie gelten nicht für den Managed ALB oder NLB, und die Knoten der Managed Kubernetes Node-Pools sind von NSGs ausgenommen. Sie sichern load-balanced Backends, indem Sie Regeln auf den Backend-NICs schreiben, nicht auf dem Load Balancer.

Die Standardaktion einer NSG ist deny-all, sodass Verkehr blockiert wird, es sei denn, eine explizite Regel erlaubt ihn. Regeln haben eine Richtung, entweder INGRESS oder EGRESS, und beide Richtungen werden unterstützt. Die unterstützten Protokolle sind TCP, UDP, ICMP, ICMPv6, GRE, VRRP, ESP, AH und ANY.

3.1 Anhängen von NSGs und Erstellen von Regeln

Die Granularität der Zuweisung erfolgt pro VM, was alle NICs dieser VM abdeckt, oder pro NIC für eine granulare Steuerung. Wenn eine VM Mitglied einer NSG ist, erben alle NICs der VM implizit die Firewall-Regeln. Jede NIC kann bis zu 10 NSGs tragen, ein VDC kann bis zu 200 NSGs enthalten, und jede NSG kann bis zu 100 Regeln enthalten.

resource "ionoscloud_nsg" "app_tier" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app-nsg"
  description   = "App tier: allow ALB to API port only"
}

resource "ionoscloud_nsg_firewallrule" "allow_api_from_app_lan" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  nsg_id        = ionoscloud_nsg.app_tier.id
  protocol      = "TCP"
  name          = "allow-api-8080"
  type          = "INGRESS"
  source_ip     = "10.0.1.0/24"
  port_range_start = 8080
  port_range_end   = 8080
}

Da die Firewall zustandsbehaftet ist, wird nur die Ingress-Regel für einen eingehenden TCP-Dienst erstellt; der Rückverkehr wird automatisch erlaubt, ohne dass eine entsprechende Egress-Regel erforderlich ist.

3.2 Die Roh-API und Regelattribute

Unter den Terraform-Ressourcen ist eine NSG die security-group API-Entität und jede Regel eine firewall-rule Entität. Nur Vertragsverwalter, Eigentümer und Benutzer mit Berechtigungen für das jeweilige VDC können NSGs über die API erstellen und verwalten. Die POST-Anfrage zum Hinzufügen einer Regel richtet sich an die Sicherheitsgruppe in einem Rechenzentrum:

curl -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN" \
  https://api.ionos.com/cloudapi/v6/datacenters/$DC_ID/securitygroups/$NSG_ID/rules \
  -d '{"properties":{"name":"allow-api-8080","protocol":"TCP","type":"INGRESS","sourceIp":"10.0.1.0/24","portRangeStart":8080,"portRangeEnd":8080}}'

Die Namen der Regel-Eigenschaften sind name, protocol, sourceMac, ipVersion, sourceIp, targetIp, portRangeStart, portRangeEnd, icmpCode, icmpType und type. Eine Standard-NSG enthält 4 vordefinierte Regeln: Erlaube allen IPv4-Ausgang, erlaube allen IPv6-Ausgang, erlaube IPv4-Eingang nur von 10.0.0.0/24 und erlaube IPv6-Eingang nur vom dem Rechenzentrum zugewiesenen /56 CIDR. Die Nettoauswirkung ist, dass der gesamte ausgehende Verkehr erlaubt wird, während eingehender Verkehr blockiert ist, mit Ausnahme der ausdrücklich erlaubten Bereiche.

4. Absicherung der Load-Balanced-Ebene

Die zentrale architektonische Konsequenz der Bindung von NSGs an NICs ist, dass der ALB keine Sicherheitsgrenze ist, die Sie mit Firewall-Regeln konfigurieren können. Der Traffic, den der ALB an Ihre Backends weiterleitet, trifft auf der Backend-NIC ein, und genau an dieser NIC erfolgt die Filterung. Daher sollten Sie Ihre NSG-Regeln so formulieren, dass nur der Traffic des Load Balancers zugelassen wird.

Für die App-Ebene der TaskBoard-Anwendung befindet sich der ALB im Listener (Public) LAN und leitet den Traffic in das App-LAN weiter. Die NICs der App-Server sollten TCP auf dem API-Port ausschließlich aus dem App-LAN-Subnetz akzeptieren und alles andere ablehnen. Die NICs der DB-Ebene sollten PostgreSQL-Traffic ausschließlich aus dem App-LAN akzeptieren, niemals aus dem Public LAN.

4.1 Regeln zur Ebenentrennung

# DB tier: PostgreSQL reachable only from the app subnet
resource "ionoscloud_nsg" "db_tier" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db-nsg"
}

resource "ionoscloud_nsg_firewallrule" "allow_pg_from_app" {
  datacenter_id    = ionoscloud_datacenter.taskboard.id
  nsg_id           = ionoscloud_nsg.db_tier.id
  protocol         = "TCP"
  name             = "allow-pg-from-app"
  type             = "INGRESS"
  source_ip        = "10.0.1.0/24"
  port_range_start = 5432
  port_range_end   = 5432
}

Da db_tier eine benutzerdefinierte NSG ist, die keine eigenen Regeln jenseits der gerade erstellten Regel enthält, erhält sie nicht die vordefinierten Standardregeln der Plattform (diese gelten nur für die eigene Default NSG des VDC). Dieser Stack ermöglicht ausschließlich eingehenden PostgreSQL-Zugriff aus dem App-Subnetz. Falls der Datenbankserver ausgehende Konnektivität benötigt (zum Beispiel für DNS, NTP oder Patches), muss eine explizite Egress-Regel in db_tier hinzugefügt werden. Es gibt keine Regel, die das öffentliche LAN erwähnt, daher ist die Datenbank per Konstruktion nicht aus dem Internet erreichbar.

4.2 Anbindung der NSG an die Backend-NICs

Die NSG wird erst wirksam, wenn sie an die NICs angebracht ist, die sie schützen soll. Bringen Sie die NSG der App-Ebene an den NICs der API-Server und die NSG der DB-Ebene an den NICs der Datenbankserver an. Da die Zugehörigkeit von allen NICs einer Mitglieds-VM geerbt wird, kann die Anbindung auf VM-Ebene erfolgen, wenn ein Server nur eine relevante NIC besitzt.

# NSG membership is an argument on the resource being protected, not a separate
# resource. Add it to the existing API server declarations.
resource "ionoscloud_server" "api_1" {
  # ... existing arguments unchanged
  security_groups_ids = [ionoscloud_nsg.app_tier.id]
}

resource "ionoscloud_server" "api_2" {
  # ... existing arguments unchanged
  security_groups_ids = [ionoscloud_nsg.app_tier.id]
}

Das Ergebnis ist eine Verteidigung-in-Tiefe-Strategie, die vollständig in Terraform geschrieben ist: Der ALB verteilt und beendet TLS, während die NSGs auf den Backend-NICs sicherstellen, dass nur der beabsichtigte Verkehr jede Ebene erreicht.

Schnellreferenz für die API

Wichtige API-Endpunkte für Lastverteilung und Sicherheit:

Basis-URL: https://api.ionos.com/cloudapi/v6 Authentifizierung: Authorization: Bearer <token>

Code Lab

Ziel: Provisionierung eines ALB für die TaskBoard API mit Terraform, Hinzufügen von NSG-Regeln zu den Ebenen App und DB sowie Überprüfung der Routing- und Isolationsmechanismen.

Voraussetzungen:

• IONOS CLOUD Konto mit API-Token (IONOS_TOKEN exportiert)
• Terraform mit dem ionoscloud Provider konfiguriert
• Der TaskBoard-Netzwerkstack aus Einheit 2.2 wurde bereits angewendet (Datacenter, LANs, Server)

Schritt 1: Reservierung einer öffentlichen IP für den ALB

resource "ionoscloud_ipblock" "alb_ip" {
  location = "de/fra"
  size     = 1
  name     = "taskboard-alb-ip"
}

Erwartete Ausgabe:

ionoscloud_ipblock.alb_ip: Creation complete after 8s [id=...]

Schritt 2: Load Balancer und Zielgruppe hinzufügen

terraform apply -target=ionoscloud_application_loadbalancer.taskboard_api \
  -target=ionoscloud_target_group.api_targets

**Erwartete Ausgabe:

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Schritt 3: Die Weiterleitungsregel hinzufügen

terraform apply -target=ionoscloud_application_loadbalancer_forwardingrule.api_http

Erwartete Ausgabe:

ionoscloud_application_loadbalancer_forwardingrule.api_http: Creation complete

Schritt 4: NSG für die App-Ebene erstellen und zuordnen

terraform apply \
  -target=ionoscloud_nsg.app_tier \
  -target=ionoscloud_nsg_firewallrule.allow_api_from_app_lan \
  -target=ionoscloud_server.api_1 \
  -target=ionoscloud_server.api_2

Erwartete Ausgabe:

Apply complete! Resources: 2 added, 2 changed, 0 destroyed.

Schritt 5: Erstellen der NSG für die DB-Ebene mit der Isolierungsregel

terraform apply -target=ionoscloud_nsg.db_tier \
  -target=ionoscloud_nsg_firewallrule.allow_pg_from_app

Erwartete Ausgabe:

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Schritt 6: Verifizieren Sie, dass der ALB an die API weiterleitet

curl -i http://$(terraform output -raw alb_ip)/api/health

Erwartete Ausgabe:

HTTP/1.1 200 OK
{"status":"ok"}

Schritt 7: DB-Isolation von der öffentlichen Seite überprüfen

nc -zv -w 5 $(terraform output -raw db_public_check) 5432

Erwartete Ausgabe:

nc: connect to ... port 5432 (tcp) timed out: Operation now in progress

Prüfliste:

• [ ] ALB gibt 200 für /api/health über die reservierte öffentliche IP zurück
• [ ] App-NICs akzeptieren TCP 8080 nur aus dem App-Subnetz
• [ ] PostgreSQL in der DB-Ebene ist von außerhalb des App-Subnetzes nicht erreichbar

Aufräumarbeiten:

terraform destroy \
  -target=ionoscloud_application_loadbalancer_forwardingrule.api_http \
  -target=ionoscloud_application_loadbalancer.taskboard_api \
  -target=ionoscloud_target_group.api_targets \
  -target=ionoscloud_nsg.app_tier \
  -target=ionoscloud_nsg.db_tier \
  -target=ionoscloud_ipblock.alb_ip

Häufige Fehlerquellen

Fehler von Entwicklerinnen und Entwicklern, die bei der Lastverteilung und Sicherheit in IONOS CLOUD zu vermeiden sind:

1. Versuch, eine NSG an den Load Balancer anzubinden

   • Problem: Sie schreiben Firewall-Regeln und erwarten, dass sie den Traffic am ALB filtern, doch sie haben keine Wirkung.
   • Ursache: NSGs werden ausschließlich auf der Ebene der Server-NIC gebunden. Sie gelten nicht für den Managed ALB oder NLB, und Knoten aus Knotenpools von Managed Kubernetes sind vollständig ausgeschlossen.
   • Lösung: Schreiben Sie die Regeln auf den Backend-NICs. Erlauben Sie nur den vom Load Balancer weitergeleiteten Traffic und isolieren Sie jede Ebene an ihren eigenen NICs.

2. Erfassen von Egress-Regeln für eingehende Dienste

   • Problem: Sie fügen eine Ingress-Regel für TCP 8080 sowie eine passende Egress-Regel für die Antwort hinzu, woraufhin der Traffic unbeständig reagiert oder die NSG zu weit geöffnet wird.
   • Ursache: Die NSG von IONOS CLOUD ist eine zustandsbehaftete Firewall, daher wird der Rückkehr-Traffic für eine erlaubte eingehende Verbindung automatisch gestattet.
   • Lösung: Erfassen Sie für einen eingehenden Dienst nur die Ingress-Regel. Verwenden Sie Egress-Regeln ausschließlich für Verbindungen, die Ihr Server initiiert.

3. Vergessen, dass der ALB eine reservierte öffentliche IP benötigt

   • Problem: terraform apply schlägt bei der Erstellung eines öffentlichen ALB fehl, weil keine nutzbare öffentliche IP bereitgestellt wird.
   • Ursache: Ein öffentlicher ALB erfordert eine reservierte öffentliche IP, die über das Argument ips bereitgestellt wird.
   • Lösung: Stellen Sie zuerst eine ionoscloud_ipblock bereit und verweisen Sie in beiden Fällen, dem Load Balancer und dem Listener der Weiterleitungsregel, auf ionoscloud_ipblock.alb_ip.ips[0].

Zusammenfassung

Sie können nun einen verwalteten Load Balancer vor einer Ebene platzieren und diese Ebene vollständig über Code absichern. Der ALB übernimmt das Routing auf Layer 7, das TLS-Offloading sowie Protokolle wie WebSocket und gRPC, während der NLB eine TCP-Verteilung auf Layer 4 mit minimalem Overhead bereitstellt. Network Security Groups erzwingen stateful, deny-all-basierte Filterung pro NIC, und Sie sichern load-balanced Backends, indem Sie Regeln auf den NICs der Backends definieren, da der Load Balancer selbst kein NSG-Ziel ist.

Für TaskBoard befindet sich die API nun hinter einem ALB im öffentlichen LAN, die App-NICs akzeptieren nur weitergeleitetes API-Traffic aus dem App-Subnetz, und die Datenbank ist nur aus der App-Ebene erreichbar. Die nächste Einheit provisioniert die Storage-Ebene, von der diese Server abhängen.

Wichtige Punkte:

• Der ALB besteht aus drei Ressourcen: ionoscloud_application_loadbalancer, ionoscloud_target_group und ionoscloud_application_loadbalancer_forwardingrule
• Wählen Sie den ALB für HTTP- und HTTPS-Anwendungsrouting sowie TLS-Offloading; wählen Sie den NLB für L4-TCP-Verteilung
• NSGs werden ausschließlich auf Server-NIC-Ebene gebunden, niemals an ALB, NLB oder Managed Kubernetes-Knoten
• NSGs sind standardmäßig deny-all und stateful, daher sollten Sie nur Ingress-Regeln für eingehende Dienste definieren
• Sichern Sie eine load-balanced Ebene, indem Sie auf den Backend-NICs filtern und jede Ebene mit einer eigenen NSG isolieren

Wichtige Begriffe:

• Target group: Eine logische Gruppierung registrierter Ziele (IP, Port, Gewicht), auf die ein ALB Traffic verteilt; wiederverwendbar über Forwarding-Regeln hinweg.
• Forwarding rule: Eine Regel, die eine Listener-IP und einen Port mit Zielen verknüpft und definiert, wie der Load Balancer Client-Traffic verteilt.
• Listener: Die clientseitige Schnittstelle eines Load Balancers, die Verbindungen auf einer freigegebenen IP und einem konfigurierten Port annimmt.
• Network Security Group (NSG): Eine stateful, deny-all-basierte Firewall, die pro VM oder pro NIC angebracht wird und bis zu 100 Regeln enthält.
• TLS offloading: Beendigung von HTTPS am ALB und Weiterleitung von reinem HTTP an Backends, wodurch die Zertifikatsverarbeitung von den Anwendungsservern entfernt wird.

Nächste Schritte

Weiter lernen: Einheit 2.4: Storage Provisioning as Code

Verwandte Themen:

• Einheit 2.2: Network and Connectivity as Code
• Einheit 5.2: Security Automation