נבדק לאחרונה: מאי 2026
בנו את שירותי AWS של בחינת ANS-C01 עם Terraform פשוט — בלוק אחד בכל פעם, כאשר כל אחד מהם מקושר בחזרה לתחום במבחן. אותו הקוד עובד גם ב-OpenTofu.
בסוף מעבדה זו תפרוס, באמצעות Terraform פשוט, את עמוד השדרה הקנוני של AWS multi-VPC — שני VPCs בעלי ערימה כפולה (IPv4 + IPv6) באותו אזור, המחוברים באמצעות Transit Gateway עם שיוכים מפורשים לטבלאות ניתוב, ו-VPC Flow Logs המגובים ב-CloudWatch ב-VPC הראשי, כך שתוכל לראות בפועל מה עובר ברשת שלך. זוהי הארכיטקטורה שכל שאלת ANS-C01 multi-VPC מניחה.
כל משאב הוא Terraform פשוט. זרוק את הקטעים לקובץ main.tf יחיד, הפעל terraform init, ולאחר מכן terraform apply צעד אחר צעד.
>= 1.5 או OpenTofu >= 1.6.us-east-1.רוב מעבדה זו זולה או חינמית, אך Transit Gateway אינו כזה:
העמלה השעתית של TGW היא החשבון עבור מעבדה זו. שני חיבורים × $0.05/שעה × 24 שעות × 30 ימים ≈ $72 לחודש בזמן ריצה. השמד מיד לאחר שתסיים לבדוק — TGW הוא מלכודת העלות הגדולה ביותר בכל מעבדת ANS-C01.
פתיחה סטנדרטית. Transit Gateway הוא אזורי — כל החיבורים חייבים להיות באזור שבו ה-TGW נמצא. עבור קישוריות חוצת אזורים, היית מוסיף TGW peering (מחוץ לתחום עבור v1). אנו מוגדרים כברירת מחדל ל-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 בוחן במיוחד VPCs בעלי ערימה כפולה — AWS מגדיר כעת כברירת מחדל הקצאת IPv6 /56 לכל VPC חדש אם תגדיר assign_generated_ipv6_cidr_block = true. תחום עיצוב רשת של הבחינה בוחן גם את תכנון ה-CIDR של IPv4 (/16ים שאינם חופפים אם ברצונך לבצע peering או לצרף TGW) וגם את גזירת ה-subnet של IPv6 (כל subnet מקבל /64 מגזור מתוך ה-/56 של ה-VPC).
אנו מקצים IPv4 10.0.0.0/16 ו-IPv6 /56 שנוצר אוטומטית על ידי AWS. ה-subnet היחיד כאן משתמש בבלוק IPv4 /24 ובבלוק IPv6 /64 מגזור מתוך ה-/56 של ה-VPC — cidrsubnet הוא הפונקציה המובנית של Terraform עבור חישוב זה. שער האינטרנט הוא בעל ערימה כפולה כברירת מחדל באזורי AWS מודרניים.
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
}אנו בונים VPC שני ב-10.1.0.0/16 — במכוון אינו חופף ל-10.0.0.0/16 של VPC #1. בחינת ANS-C01 מדגישה כלל עיצוב זה מכיוון שברגע שאתה רוצה לחבר שני VPCs (peering, TGW, כל דבר), CIDRs חופפים אוסרים זאת בשכבת ה-API של AWS. אינך יכול לנתב ל-CIDR שגם נתבע מקומית.
VPC #2 מקבל גם /56 IPv6 משלו שנוצר אוטומטית על ידי AWS (כל VPC מקבל בלוק ייחודי גלובלית, כך שאין סיכון לחפיפה של IPv6 כברירת מחדל). חישובי חלוקת ה-subnet זהים בצורתם לשלב 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" }
}ה-Transit Gateway הוא הרכזת. הוא מתרחב לאלפי חיבורי VPC, תומך בשיתוף חוצה חשבונות באמצעות AWS Resource Access Manager (RAM), ומעניק לך טבלת ניתוב אחת להתייחס אליה במקום N² חיבורי peering. בחינת ANS-C01 בוחנת את הבחירה הזו של רכזת וחישורים על פני VPC peering בכל פעם שהשאלה מזכירה "יותר משלושה VPCs" או "ככל שהרשת שלנו גדלה".
אנו יוצרים את ה-TGW כאשר שיוך טבלת הניתוב והפרופגציה כברירת מחדל מושבתים — זהו התבנית הנבחנת יותר ב-ANS-C01 מכיוון שהיא מאלצת אותך להיות מפורש לגבי אילו חיבורים מאכלסים אילו טבלאות ניתוב. שיוך אוטומטי הוא הגדרת הנוחות; ידני הוא הגדרת הביקורת-ידידותית.
משאב החיבור הוא הגשר לכל VPC. עם שני ה-VPC-ים מחוברים, ה-TGW יודע על שני ה-CIDR שלהם; עדיין עלינו להוסיף ניתובים מטבלת הניתוב הראשית של כל VPC המצביעים על ה-TGW (שלב 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
}ה-TGW משלב 4 יודע על שני ה-VPC-ים, אך טבלת הניתוב של כל VPC עדיין אינה יודעת כיצד להגיע לשנייה. אנו מוסיפים ניתובים מפורשים בשני הכיוונים: טבלת הניתוב של VPC #1 שולחת תעבורת 10.1.0.0/16 אל ה-TGW, ולהיפך. הבחינה בוחנת דרישה דו-צדדית זו שוב ושוב — "חיברתי את שניהם ל-TGW, מדוע הם לא יכולים לבצע פינג?" היא כמעט תמיד ניתוב חסר בנתיב החזרה.
לבסוף, VPC Flow Logs. תחום ניטור רשת של ANS-C01 בוחן את אלה כדרך היחידה לראות אילו חבילות עוברות בפועל ברשת שלך — מקובלות, נדחות, ורק מטא-דאטה (5-tuple + בתים + חבילות + תוצאה). אנו מפעילים אותם עבור ה-VPC הראשי, כאשר יומנים זורמים לקבוצת יומנים ייעודית של CloudWatch. תפקיד ה-IAM שאנו מצרפים הוא זה ש-Flow Logs מניח כדי לכתוב לקבוצת היומנים.
עם הניתובים במקום ו-Flow Logs פועלים, עמוד השדרה הושלם. שני VPCs בעלי ערימה כפולה, המחוברים באמצעות TGW עם ניתוב מפורש (ידידותי לביקורת), עם נראות ברמת החבילה בצד הראשי. כל תבנית נוספת של ANS-C01 (Direct Connect Gateway, TGW peering, NAT, PrivateLink, VPC endpoints) מתחברת לבסיס זה.
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 מפרק את כל מה שיש במעבדה זו, אך היזהר עם הסדר — לוקח 5–10 דקות לנתק חיבורי Transit Gateway, וה-TGW עצמו לא ניתן למחיקה עד ששני החיבורים נעלמים לחלוטין. terraform destroy מטפל בגרף התלות בצורה נכונה, אך הפעולה אינה מהירה. אל תלחץ Ctrl-C באמצע ההשמדה אחרת תישאר עם חיבורים מנותקים למחצה שתצטרך לנקות דרך הקונסולה.
הסיבה הגדולה ביותר להשמיד מיד היא העמלה השעתית של TGW — שני חיבורים ב-$0.05/שעה כל אחד = $72 לחודש בסך הכל. עלויות המעבדה מצטברות במהירות אם תשכח שהיא פועלת.
ANS-C01 מכסה משטחי רשת שמעבדה זו אינה יכולה להכיל — Direct Connect (אין סביבת בדיקה ללא פורט פיזי), AWS Site-to-Site VPN (זקוק לנקודת קצה בצד הלקוח), Route 53 Resolver inbound/outbound endpoints עבור DNS היברידי, PrivateLink + שירותי VPC endpoint, AWS Network Firewall, AWS Global Accelerator, בדיקות תקינות ו-failover של Route 53, Network Access Analyzer, Reachability Analyzer, Transit Gateway peering (חוצה אזורים), Cloud WAN, AWS App Mesh, ותרחישים ספציפיים ל-BGP (סינון ניתובים, prepend, מניפולציה של AS-PATH).
אנו נדבקים לצורת עמוד השדרה של multi-VPC מכיוון שהיא הארכיטקטורה הנבחנת ביותר בבחינה — חיבורי Direct Connect, מנהרות VPN, DNS היברידי ו-PrivateLink כולם מתבססים על סוג זה של רכזת TGW. קבל את הרכזת והחישורים נכון; סוגי החישורים הם הרחבות שלה.
עבור המשטחים שלא סופקו, סעיפי העיון, המדריך וה-Editorial של דף הסמכה זה מכילים כיסוי קונספטואלי. מעבדה עוקבת שתוסיף Route 53 Resolver + חיבור VPN + PrivateLink תשלים את סיפור הרשת ההיברידית.