การเชื่อมต่อหลาย VPC และ Hybrid Cloud

ทฤษฎีและกลไกการทำงาน (How it works):
เมื่อระบบเติบโตขึ้น การแบ่งแยก Workload เป็นหลายๆ VPC ถือเป็น Best Practice เพื่อจำกัดวงความเสียหาย (Blast Radius) อย่างไรก็ตาม VPC แต่ละวงจะไม่สามารถคุยกันได้โดยธรรมชาติ การเชื่อมต่อเบื้องต้นและมีประสิทธิภาพที่สุดคือการทำ VPC Peering

VPC Peering คือการสร้างสะพานเชื่อมต่อผ่านสายเคเบิลเบื้องหลังของ AWS โดยตรง (AWS Backbone Network) ทราฟฟิกจะไม่วิ่งออกสู่อินเทอร์เน็ตสาธารณะเลย ข้อดีมหาศาลของ Peering คือไม่มีปัญหาคอขวด (No bandwidth bottleneck) และไม่มีจุดศูนย์กลางที่จะล่มได้เลย (No SPOF) ยิ่งไปกว่านั้น คุณสามารถเชื่อม VPC ข้ามภูมิภาค (Cross-Region) หรือข้ามบัญชี (Cross-Account) ได้อย่างไร้รอยต่อ

แต่คุณสมบัติทางสถาปัตยกรรมที่สำคัญที่สุดที่ต้องจำไว้ให้ขึ้นใจคือ VPC Peering เป็นระบบ Non-Transitive Routing (ไม่สามารถเป็นทางผ่านได้) หมายความว่า หากคุณมี VPC A เชื่อมกับ VPC B, และ VPC B เชื่อมกับ VPC C เครื่องใน VPC A จะไม่สามารถคุยทะลุ VPC B เพื่อไปหา VPC C ได้ หากต้องการให้ A คุยกับ C คุณต้องสร้างเส้นทาง Peering ระหว่าง A และ C โดยตรง เกิดเป็นโมเดลใยแมงมุม (Full Mesh Topology)

# ผู้ขอเชื่อม (Requester) จาก VPC A ไปหา VPC B
resource "aws_vpc_peering_connection" "peer_a_to_b" {
  vpc_id      = aws_vpc.vpc_a.id
  peer_vpc_id = aws_vpc.vpc_b.id
  auto_accept = true # ถ้าย้ายข้าม Account ต้องมีกระบวนการ Accept ฝั่ง Accepter ด้วย

  tags = {
    Name = "Peering-A-to-B"
  }
}

# ปรับปรุง Route Table ฝั่ง A ให้ส่งทราฟฟิกไปยัง B ผ่าน Peering
resource "aws_route" "route_in_a" {
  route_table_id            = aws_route_table.rt_a.id
  destination_cidr_block    = aws_vpc.vpc_b.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.peer_a_to_b.id
}

# ปรับปรุง Route Table ฝั่ง B ให้ส่งทราฟฟิกย้อนกลับมา A
resource "aws_route" "route_in_b" {
  route_table_id            = aws_route_table.rt_b.id
  destination_cidr_block    = aws_vpc.vpc_a.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.peer_a_to_b.id
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในสถาปัตยกรรม Microservices ที่แบ่งแยก VPC ตามแผนก เช่น แผนก HR (VPC A) แผนกเซลส์ (VPC B) การทำ Peering คือสิ่งที่ตอบโจทย์ที่สุดเพื่อดึงข้อมูลจากศูนย์รวมส่วนกลาง (Shared Services VPC) เช่น ระบบ Logging กองกลาง, Active Directory, หรือศูนย์ CI/CD Pipeline ทราฟฟิกจะวิ่งได้รวดเร็วและปลอดภัยระดับสายไฟเบอร์ส่วนตัว (Private Backbone) โดยไม่กิน Bandwidth ของ NAT Gateway

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): โครงสร้างแบบ Full Mesh Complexity เมื่อบริษัทเริ่มสร้าง VPC จำนวนมากๆ (เช่น 100 VPCs) ตามสูตรทางคณิตศาสตร์คุณจะต้องสร้างเส้นทาง Peering ถึง N(N-1)/2 เส้น หรือประมาณ 4,950 เส้น! ความซับซ้อนของการอัปเดต Route Table จำนวนหลักหมื่นบรรทัดจะกลายเป็นฝันร้ายของการบริหารจัดการเครือข่าย
* Mitigation (วิธีแก้): เลิกใช้ VPC Peering แบบ Full Mesh ในระดับ Enterprise และก้าวเข้าสู่สถาปัตยกรรมแบบ Hub-and-Spoke ด้วยเครื่องมือระดับองค์กรที่เรียกว่า AWS Transit Gateway ทันทีเมื่อจำนวน VPC ของคุณเริ่มเกิน 10 วงขึ้นไป

ทฤษฎีและกลไกการทำงาน (How it works):
เพื่อแก้ไขปัญหาความซับซ้อนของ VPC Peering แบบใยแมงมุม AWS จึงเปิดตัว Transit Gateway (TGW) ซึ่งทำงานในรูปแบบ Hub-and-Spoke (จุดศูนย์กลางและซี่ล้อ) โดย TGW จะทำหน้าที่เสมือนศูนย์กลางจราจรทางเครือข่าย (Cloud Router ระดับภูมิภาค)

คุณเพียงแค่นำ VPC ทั้ง 100 วง มาเสียบปลั๊ก (Attach) เข้ากับ Transit Gateway ตรงกลางเพียงจุดเดียว (ใช้จำนวนการเชื่อมต่อแค่ 100 เส้นแทน 4,950 เส้น) TGW จะรองรับคุณสมบัติ Transitive Routing อย่างสมบูรณ์ ทำให้ VPC A สามารถวิ่งทะลุ TGW ไปหา VPC Z ได้ทันทีตามกฎของการเลือกเส้นทาง

เบื้องหลังการทำงาน TGW ขับเคลื่อนด้วยสถาปัตยกรรม Hyperplane ซ่อนโครงสร้างพื้นฐานระดับ Fleet จำนวนมหาศาลไว้ รองรับปริมาณรับส่งข้อมูลได้ถึง 50 Gbps ต่อการเชื่อมต่อ และสามารถกระจายตัว Route Table ภายใน TGW เพื่อแยกวง (Isolate) ให้กลายเป็นหลายๆ ศูนย์ย่อยเสมือนการทำ VRF (Virtual Routing and Forwarding) ในสวิตช์เครือข่าย

# สร้างศูนย์กลาง Transit Gateway
resource "aws_ec2_transit_gateway" "main_tgw" {
  description                     = "Core Enterprise TGW"
  default_route_table_association = "enable"
  default_route_table_propagation = "enable"
  # แนะนำให้เปิด auto_accept เฉพาะใน AWS Organization เดียวกัน
  auto_accept_shared_attachments  = "enable"
}

# เสียบปลั๊ก (Attach) VPC แผนก Dev เข้าไป
resource "aws_ec2_transit_gateway_vpc_attachment" "dev_attach" {
  subnet_ids         = [aws_subnet.dev_subnet_1.id, aws_subnet.dev_subnet_2.id]
  transit_gateway_id = aws_ec2_transit_gateway.main_tgw.id
  vpc_id             = aws_vpc.dev_vpc.id
}

# แก้ Route Table ใน VPC ให้โยนจราจรที่ไม่ได้ระบุลง TGW ให้หมด
resource "aws_route" "dev_vpc_to_tgw" {
  route_table_id         = aws_route_table.dev_rt.id
  destination_cidr_block = "10.0.0.0/8" # โยนจราจรกลุ่มบริษัทใหญ่เข้า TGW
  transit_gateway_id     = aws_ec2_transit_gateway.main_tgw.id
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
รูปแบบสถาปัตยกรรมยอดนิยมคือ "Egress VPC Architecture" ในองค์กรที่มีหลายสิบ VPC แทนที่แต่ละ VPC จะต้องสร้าง NAT Gateway และ Internet Gateway ของตนเอง (ซึ่งแพงและจัดการ Policy ส่วนกลางยาก) สถาปนิกจะสร้าง VPC กองกลางชื่อว่า "Egress VPC" ให้มี NAT Gateway และตัวจับมัลแวร์ จากนั้นบังคับให้ทุก VPC ส่งข้อมูลผ่าน Transit Gateway มารวมกันที่ Egress VPC ก่อนออกสู่อินเทอร์เน็ต เพื่อบังคับทำคัดกรองเนื้อหา (Web Filtering) ควบคุมความปลอดภัยเป็นจุดเดียว

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): Transit Gateway คิดราคาแพงมาก โดยคิดราคาต่อชั่วโมงต่อ 1 การเชื่อมต่อ (Attachment) และที่เจ็บปวดที่สุดคือ คิดค่า "Data Processing" ต่อกิกะไบต์ของทราฟฟิกทั้งหมดที่วิ่งผ่าน หากนำมาเชื่อมต่อแอปพลิเคชันที่มีแบนด์วิดท์มหาศาล (เช่น สตรีมวิดีโอ) บิลสิ้นเดือนจะพุ่งสูงปรี๊ด
* Mitigation (วิธีแก้): พิจารณาใช้สถาปัตยกรรมแบบ ผสมผสาน (Hybrid Peering) โดยให้ VPC ทั่วไปวิ่งผ่าน TGW แต่ถ้ามี 2 VPC คู่หูที่รับส่งข้อมูลปริมาณหนักหน่วงต่อกัน เช่น Data Warehouse กับ EMR Cluster ให้ดึง 2 VPC นี้มาต่อ VPC Peering กันโดยตรง (เพื่อเลี่ยงค่า Data Processing) ควบคู่ไปกับการผูกเข้า TGW เพื่อกระจายเส้นทางปกติ

ทฤษฎีและกลไกการทำงาน (How it works):
AWS Client VPN เป็นบริการ Managed Service แบบยืดหยุ่นที่ช่วยให้ผู้ใช้งานแบบรีโมท (เช่น พนักงาน Work from home) สามารถมุดอุโมงค์เข้าสู่ทรัพยากรบน AWS ได้อย่างปลอดภัย เทคโนโลยีพื้นฐานใช้โปรโตคอลการเข้ารหัสระดับโลก OpenVPN (TLS VPN)

สถาปัตยกรรมทำงานในระดับเครือข่าย โดย Client VPN Endpoint จะเป็นประตูหน้าด่าน เมื่อพนักงานเชื่อมต่อสำเร็จ (ผ่าน AWS Client VPN Desktop App หรือ OpenVPN Client ทั่วไป) ระบบเครือข่ายเสมือน (Virtual Network) บน AWS จะทำการฉีด (Inject) IP ชุดใหม่ (Client CIDR) ให้กับคอมพิวเตอร์พนักงาน เพื่อให้พนักงานกลายเป็นเหมือนเครื่องลูกข่ายหนึ่งที่ตั้งอยู่ใน VPC จริงๆ

คุณสามารถตั้งค่าการพิสูจน์ตัวตน (Authentication) ได้แบบองค์กรเต็มตัว ไม่ว่าจะเป็น Active Directory, SAML-based IdP (อย่าง Okta, Azure AD), หรือใช้ Certificates เชิงใบรับรองส่วนบุคคล (Mutual TLS)

# สร้าง Client VPN Endpoint
resource "aws_ec2_client_vpn_endpoint" "employee_vpn" {
  description            = "Corporate Employee VPN"
  server_certificate_arn = aws_acm_certificate.vpn_server_cert.arn
  client_cidr_block      = "192.168.200.0/22" # ย่าน IP เสมือนที่จะแจกให้พนักงาน
  split_tunnel           = true # ให้วิ่งมาที่ VPC เฉพาะทราฟฟิกบริษัท (ไม่ให้เล่นเฟซบุ๊กผ่าน VPN)

  authentication_options {
    type                       = "certificate-authentication"
    root_certificate_chain_arn = aws_acm_certificate.vpn_client_root.arn
  }

  connection_log_options {
    enabled               = true
    cloudwatch_log_group  = aws_cloudwatch_log_group.vpn_logs.name
  }
}

# กำหนดสิทธิ์ให้พนักงานเข้าไปดึงข้อมูลใน VPC ได้
resource "aws_ec2_client_vpn_authorization_rule" "allow_all" {
  client_vpn_endpoint_id = aws_ec2_client_vpn_endpoint.employee_vpn.id
  target_network_cidr    = "10.0.0.0/16"
  authorize_all_groups   = true
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในช่วงการ Work from home 100% บริษัทยกเลิกการเปิดพอร์ต SSH (22) หรือ RDP (3389) ผ่าน IP สาธารณะโดยเด็ดขาด ใช้นโยบาย Zero-surface Attack ด้วยการให้ Database และเซิร์ฟเวอร์ทั้งหมดเป็น Private IPs พนักงานทุกคนต้องยืนยันตัวตนระดับ Multi-Factor Authentication (MFA) และลงชื่อเข้าใช้ผ่าน AWS Client VPN เข้ามาก่อนเท่านั้น เพื่อทำการบำรุงรักษาระบบ (Maintenance) หรือรันคำสั่ง Admin ผ่านเซิร์ฟเวอร์กระโดด (Bastion Hosts) ภายใน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): ถ้าพนักงานเปิดเปิดใช้ Split Tunnel ผิดพลาด (เป็น false) หมายความว่าทุกทราฟฟิกอินเทอร์เน็ตของพนักงาน (รวมถึงการดู Netflix หรือ YouTube ที่บ้าน) จะวิ่งลอดท่อ VPN เข้ามากินแบนด์วิดท์และผ่าน NAT Gateway ของบริษัทออกไปเพื่อเล่นเน็ต เสียค่า Data Processing มหาศาล!
* Mitigation (วิธีแก้): ต้องเปิดคุณสมบัติ split_tunnel = true เสมอ เพื่อสอนให้ OpenVPN ของเครื่องพนักงานทราบว่า "ถ้าเป้าหมายไอพีขึ้นต้นด้วย 10.0.x.x ให้มุดอุโมงค์เข้าบริษัท แต่ถ้าเป็นไอพีชาวบ้านบนโลก ให้ใช้อินเทอร์เน็ตที่บ้านพนักงานเองตามปกติ"

ทฤษฎีและกลไกการทำงาน (How it works):
กรณีที่มีสาขาย่อย (Branch Offices) หรือเซิร์ฟเวอร์ในศูนย์ข้อมูลส่วนตัว (On-Premises Data Center) จำเป็นต้องเชื่อมกับระบบ AWS ตลอดเวลา การใช้ Client VPN ให้พนักงานแต่ละคนกดต่อจะไม่ตอบโจทย์ สถาปัตยกรรมจะเปลี่ยนมาใช้ Site-to-Site VPN

Site-to-Site VPN เป็นอุโมงค์ถาวรข้ามผ่านอินเทอร์เน็ตสาธารณะที่มีการเข้ารหัสระดับแข็งแกร่ง (IPsec - IP Security) องค์ประกอบฝั่ง AWS จะสร้าง Virtual Private Gateway (VGW) เตรียมรอรับการเชื่อมต่อ และต้องระบุ Customer Gateway (CGW) ซึ่งก็คือหมายเลข IP สาธารณะของเร้าเตอร์ที่ติดตั้งอยู่ฝั่งบริษัทผู้ใช้งาน

จุดเด่นของบริการนี้คือ AWS จะสร้างช่องทางการเชื่อมต่อแบบซ้อนคู่กันให้ทันที (2 Tunnels) เสมอ เพื่อรองรับกรณีอุโมงค์หลักขัดข้อง (High Availability Setup) โดยการบริหารเส้นทางสามารถเลือกทำแบบคงที่ (Static Routing) สำหรับโครงข่ายเล็ก หรือให้เร้าเตอร์ทั้งสองฝั่งกระซิบเส้นทางใหม่ๆ หากันอัตโนมัติผ่าน BGP (Border Gateway Protocol) แบบ Dynamic Routing ก็ได้

# 1. ฝั่ง AWS (Virtual Private Gateway)
resource "aws_vpn_gateway" "vgw" {
  vpc_id = aws_vpc.main_vpc.id
}

# 2. ฝั่งลูกค้า (บอก AWS ว่า Router ต้นทางของลูกค้าอยู่ IP ไหน)
resource "aws_customer_gateway" "cgw" {
  bgp_asn    = 65000 # หมายเลขระบบอิสระของลูกค้า
  ip_address = "203.0.113.12"
  type       = "ipsec.1"
}

# 3. สร้างรอยเชื่อม (VPN Connection)
resource "aws_vpn_connection" "main_vpn" {
  vpn_gateway_id      = aws_vpn_gateway.vgw.id
  customer_gateway_id = aws_customer_gateway.cgw.id
  type                = "ipsec.1"
  static_routes_only  = false # ใช้ระบบ BGP Dynamic Routing
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
รูปแบบสถาปัตยกรรมระดับองค์กรที่ใช้ TGW ศูนย์กลาง มักจะทำ Site-to-Site VPN แนบเข้ากับ Transit Gateway (ไม่ได้แนบติด VPC โดยตรง) ทำให้เมื่อสำนักงานใหญ่ (On-premise) เชื่อมท่อขึ้นมาที่ TGW ครั้งเดียว จะสามารถมองเห็นและคุยกับ VPC นับร้อยวงด้านหลัง TGW ได้ทั้งหมดทันที นี่คือเคล็ดลับความรวดเร็วในการผนวกเครือข่ายของบริษัทลูก (M&A) เข้าสู่ระบบคลาวด์บริษัทแม่

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): Site-to-Site VPN วิ่งผ่านอินเทอร์เน็ตสาธารณะ (Internet Weather) ความเสถียรจะไม่ 100% อาจมีจังหวะหน่วงสะดุด (Jitter) หรือ Packet Drops นอกจากนี้แบนด์วิดท์สูงสุดต่อ Tunnel ถูกล็อกจำกัดที่ 1.25 Gbps ซึ่งไม่เพียงพอสำหรับการ Migration ข้อมูลฐานข้อมูลขนาดเพตาไบต์
* Mitigation (วิธีแก้): สำหรับระบบที่อ่อนไหวและห้ามสะดุดเด็ดขาด ต้องอัปเกรดไปใช้ AWS Direct Connect เพื่อหลบเลี่ยงอินเทอร์เน็ตสาธารณะ และถ้าจำเป็นต้องใช้ VPN เพื่อให้ได้แบนด์วิดท์สูงขึ้น สามารถนำหลายๆ Tunnels มาผูกรวมกันด้วยเทคโนโลยี ECMP (Equal-Cost Multi-Path routing) เพื่อขยายขนาดท่อ

ทฤษฎีและกลไกการทำงาน (How it works):
เมื่อความหน่วงระดับมิลลิวินาทีเป็นเรื่องคอขาดบาดตาย (เช่น ระบบเทรดหุ้นความถี่สูง) และการวิ่งผ่านอินเทอร์เน็ตสาธารณะถือว่าผิดกฎข้อบังคับความปลอดภัยระดับชาติ สถาปัตยกรรมระดับสูงสุดที่ก้าวเข้ามาตอบโจทย์คือ AWS Direct Connect (DX)

DX ไม่ใช่อุโมงค์ซอฟต์แวร์ แต่คือ "การลากสายไฟเบอร์ออปติก (Dedicated Fiber Connection) ของจริง" จากศูนย์ข้อมูลของคุณ หรือผ่านพันธมิตรผู้ให้บริการสื่อสาร (DX Partner) เข้าไปเสียบเข้ากับโครงข่ายหลักของ AWS โดยตรง

DX ให้ความเร็วคงที่แน่นอนตั้งแต่ 1 Gbps ถึง 100 Gbps โดยมีความหน่วงต่ำมากๆ (Ultra-low Latency) เพื่อป้องกันการดักจับข้อมูล คุณสามารถเปิดใช้งาน MACsec (Media Access Control Security) เพื่อเข้ารหัสระดับฮาร์ดแวร์ Layer 2 ได้ด้วย นอกจากนี้ คุณสามารถแบ่งท่อจริงนี้ออกเป็นเส้นทางเสมือน (Virtual Interfaces - VIFs) เพื่อจัดสรรจราจรว่าวิ่งไปจุดไหนได้แบบเจาะจง

# การสร้าง Virtual Interface เสมือนวิ่งเข้าท่อ DX ตัวหลัก
resource "aws_dx_private_virtual_interface" "prod_vif" {
  connection_id    = "dxcon-fg5xyz" # รหัสของท่อ DX ที่ลากมาเรียบร้อยแล้ว
  name             = "prod-vlan-200"
  vlan             = 200
  address_family   = "ipv4"
  bgp_asn          = 65352
  amazon_address   = "169.254.20.1/30" # IP ภายในฝั่ง AWS
  customer_address = "169.254.20.2/30" # IP ภายในฝั่งลูกค้า

  # เสียบเข้า VPN Gateway หรือ Direct Connect Gateway
  vpn_gateway_id = aws_vpn_gateway.vgw.id
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
สถาปัตยกรรมคลาวด์แบบผสม (Hybrid Cloud Environment) ของธนาคารใหญ่ ที่มีระบบ Core Banking รุ่นเก่าเกาะอยู่กับ Mainframe ของ IBM ภายในองค์กร แต่ต้องการสร้างบริการแอปพลิเคชันมือถือรุ่นใหม่ (Mobile Banking API) บน AWS การลากสาย Direct Connect คู่กัน 2 เส้นแบบ Active/Active ไปยัง AWS Regions 2 แห่ง (เพื่อความซ้ำซ้อนสูงสุด) เป็นมาตรฐานที่ถูกบังคับใช้เพื่อการรับประกัน SLA สภาพแวดล้อม 99.999%

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): กระบวนการขอ Direct Connect ไม่ใช่สิ่งที่คลิก 2 นาทีเสร็จบนหน้าเว็บ แต่ต้องใช้เวลาลากสายนานหลายสัปดาห์หรือเป็นเดือน นอกจากนี้ DX เป็นแค่สายไฟเบอร์ที่เชื่อถือได้ แต่มัน "ไม่ได้เข้ารหัส (Unencrypted by default)" ข้อมูล IP ระดับ Layer 3 แต่อย่างใด หากต้องการการรักษาความลับทางการค้าขั้นสุด จะต้องทำยังไง?
* Mitigation (วิธีแก้): บังคับใช้สถาปัตยกรรมผสมผสาน VPN over Direct Connect โดยการสร้าง Site-to-Site VPN ซ้อนทับลงไปในสาย Direct Connect อีกชั้นหนึ่ง เพื่อให้ได้ทั้งความเร็วและความเสถียรของไฟเบอร์ส่วนตัว พร้อมกับได้รับการเข้ารหัสลับระดับทหาร (Military-grade IPsec Encryption) ของ VPN ซ้อนไปอีกชั้นหนึ่ง