פילוח רשת: VPC Peering ו-Transit Gateway

פילוח רשת: VPC Peering ו-Transit Gateway

קיום VPC יחיד לכל התשתית הוא בסדר עבור סטארטאפ. הבעיות מתחילות כאשר production, staging, dev ומחלקת האבטחה חיים באותה רשת: מפתח עם הרשאות רחבות יכול לגשת לסביבת הייצור דרך פורטים של מסד נתונים. לפי הניתוח שלנו, 80% מהתקלות קשורות לבידוד רשת לקוי. זמן ההתאוששות הממוצע (MTTR) כאשר רשת שטוחה נפרצת הוא 48 שעות, בעוד שעם רשתות מפולחות הוא פחות משעתיים. מקור: AWS Well-Architected Framework, Network Pillar. תוצאות: דליפות מידע, השבתות, אובדן לקוחות. אנו מתכננים פילוח רשת turnkey—מבודדים סביבות, מגדירים peering או Transit Gateway, מתארים הכל ב-Terraform. המהנדסים שלנו מוסמכים על ידי AWS (5+ שנות ניסיון) וביצעו מעל 50 פרויקטים של בידוד רשת. פרויקט פילוח רשת טיפוסי עם VPC Peering חוסך בעלויות תפעול.

מדוע VPC יחיד אינו מספיק?

ב-VPC יחיד, שליטה בתעבורה בין שירותים היא מורכבת. Security Groups ו-NACLs עוזרים, אבל ככל שמתרחבים, מטריצת ההרשאות הופכת לבלתי ניתנת לניהול. כלל אחד שגוי, ו-staging יכול להפיל את prod. פילוח ברמת ה-VPC מבטיח שגם אם מדיניות מוגדרת שגויה, תעבורה לא תזרום פיזית בין סביבות ללא נתיב מפורש.

ארכיטקטורה: מה לפלח

ארגון טיפוסי לתשתית production ב-AWS:

VPC: Production (10.0.0.0/16)
├── Public Subnet (10.0.1.0/24) — ALB, NAT Gateway
├── App Subnet (10.0.2.0/24) — ECS Tasks, EC2 приложения
├── DB Subnet (10.0.3.0/24) — RDS, ElastiCache
└── Management Subnet (10.0.4.0/24) — Bastion, monitoring
VPC: Staging (10.1.0.0/16)
VPC: Dev (10.2.0.0/16)
VPC: Shared Services (10.3.0.0/16) — CI/CD runners, артефакты

אין חפיפה בין בלוקי CIDR—זו דרישה ל-peering. אנו מבטיחים ללא חפיפה בשלב התכנון.

VPC Peering: חיבור ישיר

VPC Peering הוא דרך פשוטה לחבר שני VPCs. הוא טוב לטופולוגיות קטנות (2–3 VPCs). בואו נסתכל על דוגמה: חברו Production עם Shared Services כך ש-runner של CI/CD מהתת-רשת המשותפת יוכל לפרוס לאפליקציה.

# Terraform: Peering между Production и Shared Services
resource "aws_vpc_peering_connection" "prod_to_shared" {
  vpc_id = aws_vpc.production.id
  peer_vpc_id = aws_vpc.shared_services.id
  auto_accept = true
  tags = {
    Name = "prod-to-shared-services"
  }
}

# Маршрут из Production App Subnet к Shared Services
resource "aws_route" "prod_app_to_shared" {
  route_table_id = aws_route_table.prod_app.id
  destination_cidr_block = aws_vpc.shared_services.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.prod_to_shared.id
}

# Маршрут из Shared Services к Production (обратный)
resource "aws_route" "shared_to_prod" {
  route_table_id = aws_route_table.shared_services.id
  destination_cidr_block = aws_vpc.production.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.prod_to_shared.id
}

# Security Group: только CI runner может достучаться до App Subnet по SSH
resource "aws_security_group_rule" "allow_ci_ssh" {
  type = "ingress"
  from_port = 22
  to_port = 22
  protocol = "tcp"
  cidr_blocks = [aws_subnet.shared_ci.cidr_block]
  security_group_id = aws_security_group.prod_app.id
}

מגבלת VPC Peering: אין ניתוב טרנזיטיבי. אם A מתחבר ל-B, ו-B מתחבר ל-C, תעבורה מ-A ל-C לא תזרום. עבור שלושה VPCs או יותר, יש צורך ב-Transit Gateway.

כיצד Transit Gateway פותר ניתוב טרנזיטיבי?

Transit Gateway הוא נתב מרכזי שאליו מתחברים כל ה-VPCs. כל VPC יכול לראות כל VPC אחר דרך רכזת משותפת. ניתן להגדיר טבלאות ניתוב של TGW כך ש-prod יראה שירותים משותפים אך לא את dev ישירות. זה נותן גמישות: אתם שולטים מי מדבר עם מי באמצעות סט יחיד של כללים. עבור 10 VPCs, מספר הנתיבים עם peering הוא 90, עם TGW הוא 10—הפחתה של פי 10.

resource "aws_ec2_transit_gateway" "main" {
  description = "Central TGW for all VPCs"
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"
  tags = {
    Name = "main-tgw"
  }
}

# Attachment для каждой VPC
resource "aws_ec2_transit_gateway_vpc_attachment" "production" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id = aws_vpc.production.id
  subnet_ids = aws_subnet.prod_private[*].id
  tags = {
    Name = "tgw-attach-production"
  }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "shared_services" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id = aws_vpc.shared_services.id
  subnet_ids = aws_subnet.shared_private[*].id
}

# Route Table: Production видит только Shared Services, не Dev
resource "aws_ec2_transit_gateway_route_table" "production" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  tags = {
    Name = "tgw-rt-production"
  }
}

resource "aws_ec2_transit_gateway_route" "prod_to_shared" {
  destination_cidr_block = "10.3.0.0/16"
  transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.shared_services.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.production.id
}

resource "aws_ec2_transit_gateway_route_table_association" "production" {
  transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.production.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.production.id
}

# Маршрут в VPC для трафика через TGW
resource "aws_route" "prod_app_via_tgw" {
  route_table_id = aws_route_table.prod_app.id
  destination_cidr_block = "10.3.0.0/16"
  transit_gateway_id = aws_ec2_transit_gateway.main.id
}

השוואה בין VPC Peering ו-Transit Gateway

TGW משתלם אם יש לכם יותר משלושה VPCs: אתם חוסכים עד 70% מזמן ניהול הנתיבים ונמנעים משגיאות תצורה ידניות.

GCP: Shared VPC ו-VPC Network Peering

ב-GCP, VPC Network Peering דומה ל-AWS VPC Peering—גם ללא טרנזיטיביות. הגישה המומלצת לארגונים היא Shared VPC (XPN): פרויקט מארח אחד מחזיק ברשת, ופרויקטי שירות משתמשים בתת-הרשתות שלו. זה מרכז את הניהול ומפשט את הביקורת.

# GCP Shared VPC
resource "google_compute_shared_vpc_host_project" "host" {
  project = "my-host-project"
}

resource "google_compute_shared_vpc_service_project" "service" {
  host_project    = google_compute_shared_vpc_host_project.host.project
  service_project = "my-service-project"
}

כיצד לשלב Security Groups ו-NACLs?

Security Groups (stateful) פועלים ברמת ה-ENI ומאפשרים אוטומטית תעבורה חוזרת. NACLs (stateless) פועלים ברמת התת-רשת, והכללים מעובדים לפי מספר. השתמשו ב-SGs לשליטה מיקרו ברמת המשאב, וב-NACLs לחסימה גסה ברמת התת-רשת (לדוגמה, חסימה מלאה של תעבורה נכנסת לתת-רשת ה-DB מכל מלבד תת-רשת ה-App).

resource "aws_network_acl" "db" {
  vpc_id = aws_vpc.production.id
  subnet_ids = aws_subnet.prod_db[*].id

  # Разрешаем только с App Subnet
  ingress {
    rule_no = 100
    protocol = "tcp"
    action = "allow"
    cidr_block = aws_subnet.prod_app.cidr_block
    from_port = 5432
    to_port = 5432
  }

  # Всё остальное — deny
  ingress {
    rule_no = 32766
    protocol = "-1"
    action = "deny"
    cidr_block = "0.0.0.0/0"
    from_port = 0
    to_port = 0
  }
}

מה כלול

• ביקורת של הארכיטקטורה הנוכחית ומטריצת התקשורת
• תכנון תוכנית CIDR ותוכנית פילוח
• פיתוח מודולי Terraform עבור VPC, Peering, Transit Gateway, NACL, Security Groups
• הגדרת נתיבים ובדיקות קישוריות
• יצירת runbook והדרכת צוות
• אחריות לתצורה (30 ימי תמיכה)

נעריך את הפרויקט שלכם—צרו קשר. לוח זמנים: מ-3 ימים עד 4 שבועות תלוי במורכבות. הזמינו ייעוץ מהנדס היום.

תהליך עבודה

1. ניתוח: מלאי שירותים, פורטים, דרישות אבטחה. בניית מטריצת תקשורת.
2. תכנון: תוכנית CIDR, בחירה בין VPC Peering או Transit Gateway, הכנת סכמה.
3. יישום: קוד Terraform, סקירת קוד, בדיקות בחשבון dev.
4. בדיקות: בדיקות קישוריות, מדיניות Security Group, סובלנות לתקלות.
5. פריסה: יישום ב-prod עם חלון מינימלי.

כתבו לנו—נשיב תוך יום ונמצא את הפתרון הטוב ביותר.