สถาปัตยกรรมเครือข่ายระดับโลก

ทฤษฎีและกลไกการทำงาน (How it works):
Transit Gateway (TGW) ทำหน้าที่ได้ดีเยี่ยมในการเชื่อมต่อ VPC ภายใน "ภูมิภาค (Region)" เดียวกัน แต่เมื่อบริษัทเติบโตระดับโลก มี VPC ในสิงคโปร์, อเมริกา, และยุโรป การนำ TGW มาทำ Peering ข้ามทวีป (Inter-region Peering) จะสร้างปัญหาความซับซ้อนของ Route Table ระดับมหากาพย์ (Spaghetti Routing)

AWS Cloud WAN คือวิวัฒนาการขั้นสุดยอดของระบบเครือข่าย มันคือ Global Transit Gateway ที่จัดการจากจุดศูนย์กลางผ่านสิ่งที่เราเรียกว่า "Core Network Policy"
แทนที่คุณจะต้องไปนั่งคอนฟิก Route Table ทีละ Region คุณเพียงแค่เขียนไฟล์นโยบายส่วนกลาง (JSON policy) ว่า "กลุ่ม Production (Segment) ในสิงคโปร์ ห้ามคุยกับกลุ่ม Development ในอเมริกา" Cloud WAN จะทำการกระจายกฎนี้ (Propagate) และสร้างโครงข่าย Border Gateway Protocol (BGP) ข้ามทวีปทั้งหมดให้โดยอัตโนมัติ ภายใต้โครงสร้าง AWS Backbone Network ที่มีความเร็วสูงลิ่ว

resource "aws_networkmanager_core_network" "global_core" {
  global_network_id = aws_networkmanager_global_network.global.id

  # นโยบายควบคุมเครือข่ายทั่วโลก (Global Policy)
  policy_document = jsonencode({
    segments = [
      { name = "production", require_attachment_acceptance = false },
      { name = "development", require_attachment_acceptance = true }
    ],
    edge_locations = [
      { location = "ap-southeast-1" },
      { location = "us-east-1" }
    ],
    attachment_policies = [
      {
        rule_number     = 100
        condition_logic = "or"
        conditions      = [{ type = "tag-value", key = "env", value = "prod" }]
        action          = { association_method = "constant", segment = "production" }
      }
    ]
  })
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริษัทข้ามชาติที่มีการควบรวมกิจการ (M&A) และมีโครงข่าย Data Center เก่ากระจายอยู่ 5 ทวีป การใช้ Cloud WAN ร่วมกับ Site-to-Site VPN ทำให้วิศวกรเครือข่ายศูนย์กลาง สามารถเห็นสถานะ (Topology) ของเราเตอร์และ VPC ทั่วโลกบนหน้าจอเดียว (Global Network Dashboard) และสามารถตัดขาด (Isolate) สาขาที่ถูกโจมตีทางไซเบอร์ได้ภายในเสี้ยววินาทีผ่านการเปลี่ยน Policy ส่วนกลาง

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): Cloud WAN มีราคาที่ดุเดือดมาก คิดค่าบริการทั้งฐานะ Attachment และต่อจำนวน Data Processing ซึ่งหากนำไปใช้กับบริษัทที่ไม่ได้มีเครือข่ายข้าม Region จริงๆ ถือว่าขี่ช้างจับตั๊กแตน
* Mitigation (วิธีแก้): หากคุณมี VPC กระจุกตัวอยู่แค่ใน Region เดียว (เช่น สิงคโปร์เท่านั้น) ให้ใช้ Transit Gateway พื้นฐานก็พอครับ Cloud WAN จะคุ้มค่าก็ต่อเมื่อคุณมีเครือข่ายระดับ Multi-Region หรือ Multi-Cloud ที่ซับซ้อนจริงๆ

ทฤษฎีและกลไกการทำงาน (How it works):
ในยุค On-Premises หาก Security Team ต้องการจับแพ็กเกจ (Packet Capture) เพื่อเอาไปวิเคราะห์ไวรัส พวกเขาจะใช้สาย SPAN Port เสียบที่สวิตช์หลักของ Data Center แต่ในโลกของคลาวด์ที่ทุกอย่างเป็น Virtual เราจะเอาสายไปเสียบตรงไหน?

VPC Traffic Mirroring คือ SPAN Port แห่งยุคคลาวด์ มันทำงานในระดับ Elastic Network Interface (ENI) โดยตรง เมื่อเราเปิดฟีเจอร์นี้ที่ ENI ของ Web Server (Source) โครงสร้างพื้นฐานของ AWS (Hypervisor ชั้นใต้ดิน) จะทำการ สำเนา (Clone) ทุกแพ็กเกจที่วิ่งเข้า-ออก แล้วยิงมันไปหา Security Appliance (Target) แบบ Out-of-band

ความสุดยอด: การสำเนาแพ็กเกจนี้ ไม่กระทบ CPU หรือ Bandwidth ของ Web Server เลยแม้แต่น้อย เพราะมันถูกก๊อปปี้ที่ชั้นฮาร์ดแวร์เครือข่ายข้างใต้ของ AWS!

# 1. กำหนดตัวรับข้อมูล (Target) คือ Network Load Balancer ของฝั่ง Security Team
resource "aws_ec2_traffic_mirror_target" "ids_target" {
  network_load_balancer_arn = aws_lb.security_nlb.arn
}

# 2. ตัวกรองข้อมูล (Filter) เลือกจับเฉพาะ HTTP
resource "aws_ec2_traffic_mirror_filter" "http_filter" {
  description = "Capture only HTTP traffic"
}

resource "aws_ec2_traffic_mirror_filter_rule" "rule1" {
  traffic_mirror_filter_id = aws_ec2_traffic_mirror_filter.http_filter.id
  destination_cidr_block   = "0.0.0.0/0"
  source_cidr_block        = "0.0.0.0/0"
  rule_number              = 100
  rule_action              = "accept"
  traffic_direction        = "ingress"
  destination_port_range {
    from_port = 80
    to_port   = 80
  }
}

# 3. เริ่มทำการดักจับจาก ENI ของ Web Server
resource "aws_ec2_traffic_mirror_session" "session" {
  network_interface_id     = aws_instance.web_server.primary_network_interface_id
  traffic_mirror_target_id = aws_ec2_traffic_mirror_target.ids_target.id
  traffic_mirror_filter_id = aws_ec2_traffic_mirror_filter.http_filter.id
  session_number           = 1
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
สถาบันการเงินที่ต้องปฏิบัติตามกฎหมาย PCIDSS จะต้องมีการเฝ้าระวังทราฟฟิก (Intrusion Detection System - IDS) ทีมไซเบอร์จะติดตั้ง Zeek หรือ Suricata ไว้ใน Security VPC ลับ แล้วทำ VPC Traffic Mirroring ยิงทราฟฟิกจาก Payment VPC เข้ามาตรวจสอบหาการส่งข้อมูลบัตรเครดิตแบบ Plaintext โดยที่ทีมพัฒนาแอปพลิเคชันไม่มีทางรู้ตัวเลยว่ากำลังถูกตรวจสอบอยู่

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): หาก Web Server ส่งทราฟฟิกด้วยความเร็ว 10 Gbps ตัว Traffic Mirror ก็จะโคลนทราฟฟิก 10 Gbps ยิงไปที่ Target ด้วย ซึ่งอาจทำให้ Target (IDS Server) ร่ม (Overwhelmed) และเสียค่า Data Transfer มหาศาล
* Mitigation (วิธีแก้): เสมอใช้งาน Traffic Mirror Filters อย่างเคร่งครัด อย่าเลือกดักจับแบบ 0.0.0.0/0 (ทั้งหมด) ให้เลือกจับเฉพาะพอร์ตที่ต้องสงสัยหรือจำเป็น นอกจากนี้ AWS มีฟีเจอร์ "Truncate" ที่อนุญาตให้คุณตั้งค่าให้ดักจับเฉพาะ 64 bytes แรกของแพ็กเกจ (เอาแค่ Header) โดยตัด Payload ทิ้งเพื่อประหยัดแบนด์วิดท์

ทฤษฎีและกลไกการทำงาน (How it works):
สมมติว่าคุณมีเซิร์ฟเวอร์เกมอยู่ที่ ap-southeast-1 (สิงคโปร์) แต่มีผู้เล่นอยู่ในยุโรป ทราฟฟิกของผู้เล่นคนนั้นจะต้องกระโดดผ่านผู้ให้บริการอินเทอร์เน็ตสาธารณะ (Public ISP Hops) นับสิบแห่ง ข้ามน้ำข้ามทะเล ซึ่งคาดเดา Latency ไม่ได้เลย แถมยังเสี่ยงต่อปัญหา BGP Hijacking หรือสายเคเบิลใต้น้ำขาด

AWS Global Accelerator แก้ปัญหานี้โดยการมอบ Anycast Static IP (2 เบอร์) ให้กับแอปของคุณ Anycast IP คือเบอร์วิเศษที่จะดึงผู้เล่นชาวยุโรปคนนั้น เข้าสู่เครือข่ายของ AWS (Edge Location) ที่ "ใกล้บ้านเขาที่สุดในยุโรป" ทันที จากนั้นทราฟฟิกจะพุ่งตรงมายังสิงคโปร์ผ่าน เส้นทางพิเศษ (AWS Global Backbone) ที่เป็นสายไฟเบอร์ส่วนตัวของ AWS ล้วนๆ ไม่ปะปนกับอินเทอร์เน็ตสาธารณะ

ลดจำนวน Hop ลงเหลือแค่เข้าและออก AWS ช่วยลด Latency และ Packet Loss อย่างมีนัยสำคัญ

resource "aws_globalaccelerator_accelerator" "game_accel" {
  name            = "Global-Game-Accelerator"
  ip_address_type = "IPV4"
  enabled         = true
}

resource "aws_globalaccelerator_listener" "listener_80" {
  accelerator_arn = aws_globalaccelerator_accelerator.game_accel.id
  client_affinity = "SOURCE_IP" # บังคับให้ผู้เล่นคนเดิมวิ่งไปเซิร์ฟเวอร์เดิม
  port_range {
    from_port = 80
    to_port   = 80
  }
}

resource "aws_globalaccelerator_endpoint_group" "sg_endpoint" {
  listener_arn = aws_globalaccelerator_listener.listener_80.id
  endpoint_group_region = "ap-southeast-1"

  endpoint_configuration {
    endpoint_id = aws_lb.singapore_alb.arn # ชี้เป้าไปที่ ALB ที่สิงคโปร์
    weight      = 128
  }
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริการ API ด้านการเทรดหุ้น (Trading API) หรือระบบ VoIP (โทรศัพท์ผ่านเน็ต) ที่ต้องการความเสถียรขั้นสุด ทราฟฟิกแบบ UDP (เช่นเสียง/วิดีโอ) มักจะเละเทะมากหากวิ่งบนเน็ตสาธารณะ การใช้ Global Accelerator ไม่เพียงแต่ทำให้การโทรเสียงชัดขึ้น แต่ยังได้รับเกราะป้องกัน AWS Shield Standard ป้องกัน DDoS ระดับ Edge ก่อนที่ทราฟฟิกขยะจะมาถึง VPC ด้วยซ้ำ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): Global Accelerator คิดค่าบริการตาม Premium Data Transfer ซึ่งแพงกว่า Data Transfer ขาออกปกติ (แพงกว่า CloudFront ด้วยซ้ำ) หากนำมาใช้เสิร์ฟรูปภาพหรือไฟล์วิดีโอ (Static Assets) ธุรกิจคุณอาจล้มละลาย
* Mitigation (วิธีแก้): อย่าใช้ Global Accelerator กับการแคชไฟล์ (Caching) หน้าที่นั้นคือของ Amazon CloudFront! ให้ใช้ Global Accelerator สำหรับ Dynamic Traffic ที่ไม่สามารถแคชได้ (เช่น API, TCP/UDP sockets, เกม, หรือ Database replication ข้ามทวีป) เท่านั้น

ทฤษฎีและกลไกการทำงาน (How it works):
แอปพลิเคชันบางประเภท (เช่น ระบบในโรงพยาบาล, หรือเครื่องจักรในโรงงาน) ยอมรับ Latency สู่ Cloud (ราว 20-50ms) ไม่ได้เลย พวกเขาต้องการ Latency ต่ำกว่าระดับ 1ms (Single-digit millisecond) ซึ่งต้องวางเซิร์ฟเวอร์ไว้ในอาคารเดียวกันเท่านั้น! แต่ถ้าซื้อ Server ธรรมดามาตั้ง ทีมงานก็ต้องทนทุกข์กับความยุ่งยากในการดูแลแบบเดิมๆ

AWS Outposts คือการที่ AWS ยกลำพัง "ตู้แร็คเซิร์ฟเวอร์ตัวจริง (Physical Rack)" มาตั้งไว้ในห้องเซิร์ฟเวอร์ (On-Premises) ของบริษัทคุณ! และเชื่อมสายไฟเบอร์ตรงเข้ากลับไปที่ Region
ความมหัศจรรย์คือ ตู้แร็คนี้จะทำตัวประหนึ่งเป็น "Subnet อีกวงหนึ่ง" ของ VPC ที่อยู่บนคลาวด์
คุณสามารถใช้ AWS Console ล็อกอินเข้าไปแล้วกดปุ่ม "Create EC2" โดยเลือก Subnet ที่เป็น Outposts... ทันใดนั้น EC2 เครื่องนั้นจะไปโผล่รันอยู่บนตู้แร็คในห้องเซิร์ฟเวอร์ของคุณทันที! ควบคุมทุกอย่างด้วย API เดียวกัน (Single pane of glass)

AWS Local Zones มีคอนเซปต์คล้ายกัน แต่แทนที่จะยกตู้มาตั้งที่บริษัท AWS จะไปเช่า Data Center ในเมืองใหญ่ (เช่น กรุงเทพมหานคร - ap-southeast-1-bkk-1a) แล้วตั้งเซิร์ฟเวอร์ไว้ที่นั่น เพื่อให้ธุรกิจในกรุงเทพสามารถรัน EC2 ได้ใกล้ตัวมากที่สุด

# การสร้าง Subnet ใน Local Zone ของกรุงเทพมหานคร
resource "aws_subnet" "bkk_local_zone_subnet" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.100.0/24"
  # พระเอกคือตรงนี้: ระบุชื่อ Availability Zone ที่เป็น Edge Location
  availability_zone = "ap-southeast-1-bkk-1a" 

  tags = {
    Name = "Bangkok-Ultra-Low-Latency-Subnet"
  }
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริษัทผลิตชิปหรือโรงงานผลิตรถยนต์แบบ Automated นำ AWS Outposts มาตั้งไว้ที่โรงงานเพื่อรัน EKS Cluster ประมวลผลภาพจากกล้องวงจรปิดเพื่อตรวจสอบรอยตำหนิของชิ้นส่วนแบบ Real-time (Computer Vision Inference) ทราฟฟิกกล้องไม่ต้องวิ่งออกเน็ตไปหาสิงคโปร์ ช่วยประหยัดแบนด์วิดท์มหาศาล และหากสายไฟเบอร์เกิดขาด Outposts ก็ยังสามารถทำงาน Local ต่อไปได้ (ในระดับหนึ่ง)

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): สำหรับ Outposts หากเครื่องทำความเย็นในบริษัทคุณพัง หรือไฟไหม้ห้องเซิร์ฟเวอร์ AWS จะไม่รับผิดชอบเรื่อง Physical Security และ Power (เพราะมันตั้งอยู่ในบ้านคุณ) ส่วน Local Zone ไม่ใช่ทุก Region ที่จะมี และบริการ (Services) บน Local Zone/Outposts จะถูกจำกัดอย่างมาก (มักจะมีแค่ EC2, EBS, EKS, ECS, RDS พื้นฐานเท่านั้น จะไม่มีของหรูหราอย่าง Redshift หรือ DynamoDB)
* Mitigation (วิธีแก้): ต้องออกแบบ Data Pipeline อย่างชาญฉลาด ให้ Outposts หรือ Local Zone รับบทบาทเป็นแค่ตัวประมวลผลด่านหน้า (Edge Processing / Edge Caching) แล้วค่อยคายข้อมูลที่สรุปผลแล้ว (Aggregated Data) กลับไปบันทึกลงถังใหญ่ (S3 / Data Warehouse) ที่อยู่ใน AWS Region หลักเสมอ (Core-Edge Architecture Pattern)