Zuletzt überprüft: Mai 2026
Erstellen Sie die AWS-Dienste der ANS-C01-Prüfung mit reinem Terraform — ein Block nach dem anderen, jeweils abgestimmt auf eine Prüfungsdomäne. Derselbe Code funktioniert auch mit OpenTofu.
Am Ende dieses Labs haben Sie mit einfachem Terraform das kanonische AWS Multi-VPC-Backbone bereitgestellt – zwei Dual-Stack (IPv4 + IPv6) VPCs in derselben Region, die über ein Transit Gateway mit expliziten Routing-Tabellen-Assoziationen verbunden sind, und CloudWatch-gestützte VPC Flow Logs auf der primären VPC, damit Sie tatsächlich sehen können, was Ihr Netzwerk durchläuft. Dies ist die Architektur, die jeder ANS-C01 Multi-VPC-Frage zugrunde liegt.
Jede Ressource ist einfaches Terraform. Fügen Sie die Snippets in eine einzelne main.tf ein, führen Sie terraform init aus und anschließend Schritt für Schritt terraform apply.
>= 1.5 oder OpenTofu >= 1.6.us-east-1.Die meisten Teile dieses Labs sind günstig oder kostenlos, aber das Transit Gateway nicht:
Die stündliche TGW-Gebühr ist die Hauptkostenposition für dieses Lab. Zwei Attachments × $0,05/Stunde × 24 Stunden × 30 Tage ≈ $72/Monat während des Betriebs. Zerstören Sie die Ressourcen, sobald Sie mit der Erkundung fertig sind – das TGW ist die größte Kostenfalle in jedem ANS-C01-Lab.
Standard-Einstieg. Ein Transit Gateway ist regional – alle Attachments müssen sich in der Region befinden, in der das TGW läuft. Für regionsübergreifende Konnektivität würden Sie TGW-Peering hinzufügen (nicht im Umfang von v1 enthalten). Wir verwenden standardmäßig us-east-1.
terraform {
required_version = ">= 1.5"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.60"
}
}
}
provider "aws" {
region = "us-east-1"
default_tags {
tags = {
Project = "certlabpro-ans-c01"
ManagedBy = "terraform"
}
}
}
data "aws_availability_zones" "available" {
state = "available"
}ANS-C01 testet speziell Dual-Stack-VPCs – AWS weist nun standardmäßig einen IPv6 /56 zu jeder neuen VPC zu, wenn Sie assign_generated_ipv6_cidr_block = true setzen. Der Bereich „Netzwerkdesign“ der Prüfung testet sowohl die IPv4-CIDR-Planungsmathematik (nicht überlappende /16-Blöcke, wenn Sie Peering oder TGW-Attach nutzen möchten) als auch die IPv6-Subnetz-Ableitung (jedes Subnetz erhält einen /64-Block, der aus dem /56-Block der VPC geschnitzt wird).
Wir weisen IPv4 10.0.0.0/16 und einen von AWS automatisch generierten IPv6 /56 zu. Das einzige Subnetz hier verwendet einen /24-IPv4-Block und einen /64-IPv6-Block, der aus dem /56-Block der VPC geschnitzt wird – cidrsubnet ist die eingebaute Terraform-Funktion für diese Berechnung. Das Internet-Gateway ist in modernen AWS-Regionen standardmäßig Dual-Stack.
resource "aws_vpc" "primary" {
cidr_block = "10.0.0.0/16"
assign_generated_ipv6_cidr_block = true
enable_dns_hostnames = true
tags = { Name = "certlabpro-ans-c01-primary" }
}
resource "aws_subnet" "primary_a" {
vpc_id = aws_vpc.primary.id
cidr_block = "10.0.1.0/24"
ipv6_cidr_block = cidrsubnet(aws_vpc.primary.ipv6_cidr_block, 8, 1)
availability_zone = data.aws_availability_zones.available.names[0]
assign_ipv6_address_on_creation = true
tags = { Name = "certlabpro-ans-c01-primary-a" }
}
resource "aws_internet_gateway" "primary" {
vpc_id = aws_vpc.primary.id
}Wir bauen eine zweite VPC unter 10.1.0.0/16 auf – bewusst nicht-überlappend mit der 10.0.0.0/16 von VPC #1. ANS-C01 betont diese Designregel, denn sobald Sie zwei VPCs verbinden möchten (Peering, TGW, irgendetwas), verbieten überlappende CIDRs dies auf der AWS-API-Ebene. Sie können nicht zu einem CIDR routen, der auch lokal beansprucht wird.
VPC #2 erhält ebenfalls einen eigenen, von AWS automatisch generierten IPv6 /56-Block (jede VPC erhält einen global eindeutigen Block, sodass standardmäßig kein IPv6-Überlappungsrisiko besteht). Die Subnetz-Berechnung ist identisch mit der in Schritt 2.
resource "aws_vpc" "secondary" {
cidr_block = "10.1.0.0/16"
assign_generated_ipv6_cidr_block = true
enable_dns_hostnames = true
tags = { Name = "certlabpro-ans-c01-secondary" }
}
resource "aws_subnet" "secondary_a" {
vpc_id = aws_vpc.secondary.id
cidr_block = "10.1.1.0/24"
ipv6_cidr_block = cidrsubnet(aws_vpc.secondary.ipv6_cidr_block, 8, 1)
availability_zone = data.aws_availability_zones.available.names[0]
assign_ipv6_address_on_creation = true
tags = { Name = "certlabpro-ans-c01-secondary-a" }
}Das Transit Gateway ist der Hub. Es skaliert auf Tausende von VPC-Attachments, unterstützt kontoübergreifendes Teilen über AWS Resource Access Manager (RAM) und bietet Ihnen eine einzige Routing-Tabelle zum Nachdenken anstelle von N² Peering-Verbindungen. ANS-C01 testet diese Hub-and-Spoke-Wahl gegenüber VPC-Peering immer dann, wenn die Frage „mehr als drei VPCs“ oder „wenn unser Netzwerk wächst“ erwähnt.
Wir erstellen das TGW mit standardmäßiger Routing-Tabellen-Assoziation und Propagation deaktiviert – das ist das häufiger getestete ANS-C01-Muster, da es Sie zwingt, explizit festzulegen, welche Attachments welche Routing-Tabellen befüllen. Auto-Assoziation ist die Komforteinstellung; manuell ist die auditfreundliche Einstellung.
Die Attachment-Ressource ist die Brücke pro VPC. Mit beiden angehängten VPCs kennt das TGW deren beide CIDRs; wir müssen immer noch Routen von der Haupt-Routing-Tabelle jeder VPC hinzufügen, die auf das TGW zeigen (Schritt 5).
resource "aws_ec2_transit_gateway" "hub" {
description = "certlabpro-ans-c01 hub"
default_route_table_association = "disable"
default_route_table_propagation = "disable"
multicast_support = "disable"
tags = { Name = "certlabpro-ans-c01-tgw" }
}
resource "aws_ec2_transit_gateway_route_table" "main" {
transit_gateway_id = aws_ec2_transit_gateway.hub.id
tags = { Name = "certlabpro-ans-c01-tgw-rt" }
}
resource "aws_ec2_transit_gateway_vpc_attachment" "primary" {
transit_gateway_id = aws_ec2_transit_gateway.hub.id
vpc_id = aws_vpc.primary.id
subnet_ids = [aws_subnet.primary_a.id]
transit_gateway_default_route_table_association = false
transit_gateway_default_route_table_propagation = false
}
resource "aws_ec2_transit_gateway_vpc_attachment" "secondary" {
transit_gateway_id = aws_ec2_transit_gateway.hub.id
vpc_id = aws_vpc.secondary.id
subnet_ids = [aws_subnet.secondary_a.id]
transit_gateway_default_route_table_association = false
transit_gateway_default_route_table_propagation = false
}
resource "aws_ec2_transit_gateway_route_table_association" "primary" {
transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.primary.id
transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.main.id
}
resource "aws_ec2_transit_gateway_route_table_association" "secondary" {
transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.secondary.id
transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.main.id
}
resource "aws_ec2_transit_gateway_route_table_propagation" "primary" {
transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.primary.id
transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.main.id
}
resource "aws_ec2_transit_gateway_route_table_propagation" "secondary" {
transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.secondary.id
transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.main.id
}Das TGW aus Schritt 4 kennt beide VPCs, aber die eigene Routing-Tabelle jeder VPC weiß immer noch nicht, wie die andere erreicht werden kann. Wir fügen explizite Routen in beide Richtungen hinzu: Die Routing-Tabelle von VPC #1 sendet 10.1.0.0/16-Traffic an das TGW und umgekehrt. Die Prüfung testet diese zweiseitige Anforderung wiederholt – „Ich habe beide an das TGW angeschlossen, warum können sie sich nicht anpingen?“ ist fast immer eine fehlende Rückwegroute.
Schließlich VPC Flow Logs. Der Bereich „Netzwerküberwachung“ von ANS-C01 testet diese als einzige Möglichkeit, zu sehen, welche Pakete tatsächlich Ihr Netzwerk durchqueren – akzeptiert, abgelehnt und nur Metadaten (5-Tupel + Bytes + Pakete + Ergebnis). Wir aktivieren sie für die primäre VPC, wobei die Protokolle an eine dedizierte CloudWatch-Protokollgruppe fließen. Die IAM-Rolle, die wir anfügen, ist diejenige, die Flow Logs zum Schreiben in die Protokollgruppe annimmt.
Mit den eingerichteten Routen und laufenden Flow Logs ist das Backbone vollständig. Zwei Dual-Stack-VPCs, die über ein TGW mit explizitem (auditfreundlichem) Routing verbunden sind, mit Paket-Ebene-Sichtbarkeit auf der primären Seite. Jedes zusätzliche ANS-C01-Muster (Direct Connect Gateway, TGW-Peering, NAT, PrivateLink, VPC-Endpunkte) knüpft an diese Basis an.
resource "aws_route" "primary_to_secondary" {
route_table_id = aws_vpc.primary.main_route_table_id
destination_cidr_block = "10.1.0.0/16"
transit_gateway_id = aws_ec2_transit_gateway.hub.id
depends_on = [aws_ec2_transit_gateway_vpc_attachment.primary]
}
resource "aws_route" "secondary_to_primary" {
route_table_id = aws_vpc.secondary.main_route_table_id
destination_cidr_block = "10.0.0.0/16"
transit_gateway_id = aws_ec2_transit_gateway.hub.id
depends_on = [aws_ec2_transit_gateway_vpc_attachment.secondary]
}
# ── VPC Flow Logs ─────────────────────────────────────────────
resource "aws_cloudwatch_log_group" "vpc_flow" {
name = "/aws/vpc-flow/certlabpro-ans-c01-primary"
retention_in_days = 30
}
resource "aws_iam_role" "vpc_flow" {
name = "certlabpro-ans-c01-vpc-flow"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "vpc-flow-logs.amazonaws.com" }
Action = "sts:AssumeRole"
}]
})
}
resource "aws_iam_role_policy" "vpc_flow" {
name = "write-flow-logs"
role = aws_iam_role.vpc_flow.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
]
Resource = aws_cloudwatch_log_group.vpc_flow.arn
}]
})
}
resource "aws_flow_log" "primary" {
vpc_id = aws_vpc.primary.id
traffic_type = "ALL"
log_destination_type = "cloud-watch-logs"
log_destination = aws_cloudwatch_log_group.vpc_flow.arn
iam_role_arn = aws_iam_role.vpc_flow.arn
max_aggregation_interval = 60
}terraform destroy reißt alles in diesem Lab ab, aber seien Sie vorsichtig mit der Reihenfolge – Transit Gateway Attachments benötigen 5–10 Minuten zum Trennen, und das TGW selbst kann erst gelöscht werden, wenn beide Attachments vollständig entfernt wurden. terraform destroy handhabt den Abhängigkeitsgraphen korrekt, aber der Vorgang ist nicht schnell. Drücken Sie nicht Strg-C mitten im Löschvorgang, sonst bleiben Ihnen halb abgetrennte Attachments übrig, die Sie über die Konsole bereinigen müssen.
Der wichtigste Grund für eine sofortige Zerstörung ist die stündliche TGW-Gebühr – zwei Attachments zu je $0,05/Stunde = insgesamt $72/Monat. Das Lab summiert sich schnell, wenn Sie vergessen, dass es läuft.
ANS-C01 deckt Netzwerkbereiche ab, die dieses Lab nicht behandeln kann – Direct Connect (keine Testumgebung ohne physischen Port), AWS Site-to-Site VPN (benötigt einen kundenseitigen Endpunkt), Route 53 Resolver Inbound-/Outbound-Endpunkte für Hybrid-DNS, PrivateLink + VPC-Endpunktdienste, AWS Network Firewall, AWS Global Accelerator, Route 53 Health Checks + Failover, Network Access Analyzer, Reachability Analyzer, Transit Gateway Peering (regionsübergreifend), Cloud WAN, AWS App Mesh und BGP-spezifische Szenarien (Routenfilterung, Prepend, AS-PATH-Manipulation).
Wir konzentrieren uns auf die Multi-VPC-Backbone-Struktur, da sie die am häufigsten getestete Architektur in der Prüfung ist – Direct Connect-Attachments, VPN-Tunnel, Hybrid-DNS und PrivateLink basieren alle auf dieser Art von TGW-Hub. Verstehen Sie das Hub-and-Spoke-Modell richtig; die Spoke-Typen sind Erweiterungen davon.
Für die nicht bereitgestellten Bereiche bieten die Abschnitte Durchsuchen, Handbuch und Editorial dieser Zertifizierungsseite konzeptionelle Abdeckung. Ein weiteres Lab, das Route 53 Resolver + ein VPN-Attachment + PrivateLink hinzufügt, würde die hybride Netzwerkgeschichte abrunden.