สอน AWS Networking เบื้องต้น (Part 1)
Basic AWS Networking (Part 1)
สวัสดีครับทุกคน 🙏 ผมกำลังเริ่มทำ Facebook Page และ YouTube Channel ซึ่งจะแชร์เรื่อง cloud, infrastructure as code (IaC), automation/DevOps, programming, generative AI และอื่น ๆ ตามอารมณ์ 😅
และตั้งใจจะทำวิดีโอสอนพื้นฐาน(ยัน advanced)ฟรีตั้งแต่ AWS ไล่มา Git, Linux, networking, Terraform, Docker, Kubernetes, Python, Go, etc. ไม่ครบไม่เลิกทำ 😂
รบกวนทุกคนกด Follow/Subscribe ไว้ทุกช่องทางเลยนะครับ 🙏
- 💙 Facebook: Nopnithi Tech
- ❤️ YouTube: Nopnithi Tech
- 💙 LinkedIn: Nopnithi (Game) Khaokaew
สิ่งที่ต้องรู้ก่อนอ่านบทความนี้
- Region คืออะไร?
- Availability Zone (AZ) คืออะไร?
ซึ่งสามารถอ่านได้ที่นี่ครับ
เกริ่นนำ
บน AWS นั้น networking ถือว่าเป็นหนึ่งในส่วนที่ใหญ่และสำคัญไม่แพ้ส่วนอื่นเลย และใน ซีรี่ส์สอน AWS networking เบื้องต้น ของผมนั้นตั้งใจจะอธิบายถึง component ต่าง ๆ ดังนี้
- Virtual Private Cloud (VPC)
- Subnets = Public Subnet และ Private Subnet
- Gateways = Internet Gateway (IG), NAT Gateway, Virtual Private Gateway (VGW), AWS Direct Connect (DX), VPC Peering, Transit Gateway และ VPC Endpoint
- Network Security = Route Table, Security Group และ Network ACL
โดยผมจะแบ่งเนื้อหาออกเป็น 2 part ครับ
หัวข้อใน AWS Networking Part 1 (บทความนี้)
- Virtual Private Cloud (VPC)
- Public Subnet และ Private Subnet
- Main Route Table และ Custom Route Table
- Internet Gateway (IGW)
- NAT Gateway
- Security Group
- Network ACL
หัวข้อใน AWS Networking Part 2
- Virtual Private Gateway (VGW)
- VPC Peering
- Transit Gateway
- VPC Endpoint
- AWS Direct Connect (DX)
1. VPC และการสร้าง VPC
Amazon VPC คืออะไร?
VPC เป็นชื่อ service นึงของ AWS ที่ทำเรื่อง networking ย่อมาจาก Virtual Private Cloud ซึ่งส่วนตัวผมฟังชื่อแล้วขัดหูนิดหน่อย เพราะแท้จริงแล้วมันก็คือ virtual network ที่เราสามารถสร้างขึ้นได้บน AWS infrastructure นั่นเอง
จุดประสงค์หลักของ VPC คือการ isolate workload ต่าง ๆ เช่น เราสามารถแยก environment เป็น dev, test หรือ production ได้โดยแต่ละตัวจะไม่เกี่ยวข้องกันเลย แถมยังจัดการ IP address space เองได้อิสระ นอกจากนั้นยังมีเรื่องของ security อย่างการกำหนด access rule ด้วย route table หรือ network ACL ด้วย
กำหนด Region
ในการสร้าง VPC นั้นเราจะต้องเลือก region ก่อน ซึ่ง VPC ที่เราสร้างขึ้นมานั้นจะ cover ทุก availability zone (AZ) ภายใน region นั้น เช่น ถ้าผมเลือก region เป็น Singapore (ap-southeast-1) นั่นหมายความว่า VPC ของผมก็จะทำงานครอบคลุมทั้ง 3 โซน (AZ) เลยแบบนี้
กำหนด IP Addressing Range (CIDR) ของ VPC
เมื่อจะสร้าง VPC ก็จะต้อง assign IP ให้กับมันก่อน โดยมีข้อกำหนดดังนี้
- ต้องเป็น private IP ตาม RFC 1918
- การ assign จะต้องเป็นรูปแบบ CIDR notation เช่น 10.0.0.0/16
สมมุติผมเลือกเป็น 10.0.0.0/16 นั่นแปลว่า VPC นี้ของผมจะมี IP ทั้งหมด 65,536 IPs ตั้งแต่ 10.0.0.0 ถึง 10.0.255.255 เลย
2. Subnets และการสร้าง Subnets
สมมุติตอนนี้เราได้ VPC ที่มี address range เป็น 10.0.0.0/16 แล้ว จากนั้นเราก็ต้องสร้าง subnet ขึ้นมาโดยให้มองว่า subnet ก็คือการแบ่ง VPC ก้อนใหญ่ของเราออกเป็น network ย่อย ๆ ซึ่ง subnet จะเล็กใหญ่แค่ไหนก็ขึ้นอยู่กับ mask ที่เรากำหนด
ประเภทของ Subnet
บน AWS นั้นจะมี subnet อยู่ 2 ประเภท คือ
- Private subnet
- Public subnet
ซึ่ง AWS จะแยกว่าตัวไหนเป็น private หรือ public ง่าย ๆ เพียงแค่ถ้า subnet ไหนที่เรามีการ associate เข้ากับ route table ที่มี entry ชี้ไปหา internet gateway ก็ถือว่าเป็น public subnet ไป นอกนั้นคือ private subnet ทั้งหมด
สำหรับการสร้าง subnet นั้น เราก็จะต้องกำหนด CIDR ด้วยว่า subnet ของเราจะมีขนาดเท่าไร เช่น ผมจะสร้าง subnet มาทั้งหมด 4 subnet ตามรูปด้านล่างนี้
- PublicSubnet1 = 10.0.0.0/24
- PrivateSubnet1 = 10.0.1.0/23
- PublicSubnet2= 10.0.3.0/24
- PrivateSubnet2= 10.0.4.0/23
โดยตอนสร้างเราก็จะต้อง associate subnet เข้าไปภายใน AZ โซนใดโซนนึงด้วย ซึ่งถ้าไม่กำหนดสุดท้าย AWS ก็จะ auto-assign ให้เราอยู่ดี เพราะ subnet จะอยู่ภายใต้ AZ
ความแตกต่างของ Subnet บน AWS และ On-premise
สำหรับ subnet บน AWS นั้นจะต่างกับ subnet บน on-premise network ในเรื่องของจำนวนของ IP ที่ถูก reserved ไว้ เช่น ปกติแล้ว 1 subnet จะถูก reserved ไว้ 2 IP คือ
- Network Address = IP แรกสุดของ network
- Broadcast Address = IP สุดท้ายของ network
แต่บน AWS นั้น 1 subnet จะถูก reserved ไว้ทั้งหมด 5 IP ดังนี้
(สมมุติ subnet เป็น 10.0.0.0/24)
10.0.0.0
= Network address10.0.0.1
= VPC router10.0.0.2
= DNS server10.0.0.3
= AWS reserved ไว้ใช้ทำอะไรบางอย่างในอนาคต10.0.0.255
= Broadcast address (บน AWS ไม่มี broadcast แล้ว แต่ก็ reserved กันเอาไว้)
3. Route Table และการสร้าง Route Table
Main Route Table
เมื่อเราสร้าง VPC เสร็จ หนึ่งในสิ่งที่จะมาพร้อมกับ VPC โดยอัตโนมัติก็คือ main route table ครับ โดยจะมีหน้าตาเป็นแบบนี้ (และเราสามารถเพิ่ม/ลบ route ลงไปเองได้นะ)
จะเห็นว่ามี entry ของทั้ง subnet ที่ชี้ไปยัง local โดย local ก็คือ router ตัวหนึ่งที่อยู่ภายใน VPC นั่นแหละ(แต่เราไม่สนใจ) และมันจะทำให้ host ที่แม้จะอยู่คนละ subnet ก็คุยกันได้ทันที
Custom Route Table
ปกติแล้ว subnet ทุกอันของเรามันจะ associate ไปหา main route table โดยอัตโนมัติ แต่ว่ามันไม่ยืดหยุ่นเท่าไร ดังนั้นเราสามารถสร้าง custom route table ขึ้นมาแล้วจับ associate กับ subnet ไหนก็ได้ ทำให้เรา control traffic ของ subnet นั้นได้ยืดหยุ่นมากขึ้น (และปกติเราก็ไม่ใช้ main route table กันหรอกครับ)
จากตัวอย่างนี้ผมจะสร้าง custom subnet ขึ้นมา 2 ตัว คือ
- Private Route Table
- Public Route Table
แล้วจัดการ association โดยนำ public route table ไป associate เข้ากับ public subnet 1 และ 2 ส่วน private route table ก็ associate เข้ากับ private subnet 1 และ 2
4. Internet Gateway (IGW)
หากเราต้องการให้ instance ภายใน VPC ของเราสามารถเชื่อมต่อกับโลกภายนอกได้ผ่านทาง internet ก็ให้ใช้ตัวนี้เลยครับ “Internet Gateway (IGW)”
สำหรับ IGW เนี่ย ถือว่าเป็น managed service ของ AWS ดังนั้นเรื่อง high availability, redundant หรือ scalability นั้นไม่ต้องกังวล เช่น มันจะ down มั้ย, ต้องสร้างไว้ 2 ตัวหรือเปล่า หรือว่าจะรับ bandwidth ไม่ไหวมั้ย จะโดน attack เข้ามาหรือเปล่า เป็นต้น
หลักการสร้างและใช้งาน Internet Gateway
- สร้าง internet gateway ขึ้นมา, ผูกกับ elastic IP ให้เรียบร้อย จากนั้น attach เข้ากับ VPC ที่ต้องการ
- เพิ่ม entry บน public route table ที่เราต้องการแบบนี้
0.0.0.0/0 -> igw-xxxxx
โดยชี้ไปหา internet gateway ตัวที่เราสร้างขึ้นมา - Subnet ไหนที่เราต้องการให้ออก internet ได้(เป็น public subnet) ก็ให้เราไป associate เข้ากับ public route table ตัวในข้อ 2
ถ้าเรา configure ตามรูปจะทำให้ instance ใน public subnet 1 และ public subnet 2 สามารถออก internet ได้ครับ
5. NAT Gateway (เมื่อก่อนมี NAT Instance)
ประโยชน์ของ NAT Gateway คือทำให้ instance ที่อยู่ใน private subnet ของเราสามารถออก internet ได้ และช่วยป้องกัน traffic ที่ไม่พึงประสงค์เข้ามายัง private subnet ของเราด้วย (อยู่ใน private network จะเข้ามาได้ไงหละ)
การใช้งาน NAT Gateway เนี่ย ก่อนอื่นเราต้องมี Internet Gateway เสียก่อน จากนั้นก็ทำตามนี้ได้เลยครับ
- สร้าง NAT Gateway ไว้ใน public subnet ก่อน
- เพิ่ม entry บน private route table ที่เราต้องการแบบนี้
0.0.0.0/0 -> nat-xxxxx
โดยชี้ไปหา NAT gateway ตัวที่เราสร้างขึ้นมา - Private subnet ไหนที่เราต้องการให้ออก internet ได้ก็ให้เราไป associate เข้ากับ private route table ตัวในข้อ 2
เป็นอันเรียบร้อย คราวนี้ instance ภายใน private subnet 1 ของเราก็จะสามารถออก internet ได้โดยที่ไม่ต้อง assign public IP ให้กับมัน
6. Security Group
Security group คือ virtual firewall ขนาดย่อม ๆ บน AWS ที่ใช้ในการ control inbound และ outbound traffic ที่ผ่านเข้าออก instance ของเรา โดยสามารถกำหนดเงื่อนไขในการ allow หรือ block ได้จาก IP, protocol หรือ port แต่ด้วยความที่มันเป็น stateful ดังนั้นส่วนมากเราก็มักจะทำ policy ที่ฝั่ง inbound อย่างเดียว
วิธีใช้งาน Security Group
ด้วยความที่มันเป็น group-based(ไม่ใช่ port-based) ก็ให้เราก็เริ่มจากการสร้าง security group ขึ้นมา จากนั้นกำหนด policy ต่าง ๆ ลงไปแล้วจับ instance มายัดเข้าไปใน group ซะก็เป็นอันเสร็จ ทีนี้ instance เหล่านั้นก็จะถูก policy ของ group ดังกล่าว apply ลงไปเรียบร้อย
แต่ความเจ๋งของ security group คือเราสามารถเขียนเป็น chaining rule ได้ นั่นทำให้เราจัดการกับ policy ได้ง่ายกว่า firewall ทั่วไปบน on-premise มาก
จากรูปเราแบ่งเป็น 3 tier คือ web, app แล้วก็ db ซึ่งส่วน web tier เนี่ยเป็นส่วนที่เรา allow any IPs จาก internet ที่ผ่านเข้ามาด้วย HTTPs ถูกมั้ยครับ?
ทีนี้พอมาถึง app tier เราไม่จำเป็นต้องไปกำหนด source IP ว่า instance ใน web tier มี instance ที่มี IP อะไรบ้าง แต่เราสามารถกำหนด source เป็น web security group ได้เลย ดังนั้น instance ใด ๆ ก็ตามที่อยู่ใน web tier จะสามารถ access เข้ามาที่ app tier ได้ และแน่นอนว่าระหว่าง app tier กับ db tier ก็ทำเช่นเดียวกัน
7. Network ACLs (NACL) คืออะไร?
ถ้า security group เปรียบเสมือน firewall ในระดับ instance ส่วน network ACL ก็เปรียบเสมือน firewall ในระดับ subnet ครับ ดังนั้นสิ่งที่เกิดขึ้นจาก NACL ก็จะมีผลไปทั้ง subnet เลย ซึ่งเราสามารถกำหนดเงื่อนไขในการ allow หรือ block ได้จาก IP, protocol หรือ port เหมือน security group แหละ
แต่ NACL นั้นเป็น stateless ดังนั้นถ้าเราทำการ allow traffic ในฝั่ง inbound แล้ว ก็อย่าลืมทำฝั่ง outbound ด้วยนะครับ ตรงจุดนี้เป็นอีกข้อแตกต่างกับ security group
ทีนี้ในตอนที่เราสร้าง VPC เนี่ย ทุก subnet ของเราจะใช้ default NACL ซึ่งจะมี inbound และ outbound policy เป็น allow any traffic ครับ ทำให้เหมือนว่าเราไม่ได้ยุ่งอะไรกับมัน แต่ในกรณีที่เราสร้าง NACL ขึ้นมาเองจะเป็น deny by default นะครับ
ข้อแตกต่างระหว่าง Security Group กับ Network ACL
- Security group มีผลแค่ในระดับ instance
- NACL มีผลทั้ง subnet แปลว่าทุก instance ภายใต้ subnet นั้นจะโดนหมด
- Security group เป็น stateful ดังนั้นเรากำหนด policy แค่ฝั่ง inbound อย่างเดียวก็ใช้งานได้
- NACL เป็น stateless ในการกำหนด policy จะต้องทำทั้งฝั่ง inbound และ outbound ด้วย
- Policy บน security group ไม่มี preference หรือลำดับความสำคัญก่อน-หลัง ทุก policy จะมีผลทั้งหมด
- Policy บน NACL จะมี preference เป็นตัวเลข 1–32766 ซึ่ง NACL จะเชื่อ policy ที่มีตัวเลขน้อยกว่าก่อน เช่น ถ้าผม allow IP x.x.x.x ไว้ที่ 100 แต่ที่ 200 ผม deny IP x.x.x.x นั่นแปลว่า IP x.x.x.x จะสามารถผ่าน NACL นี้ได้ครับ
แต่โดยทั่วไปแล้วถ้า infrastructure ไม่ได้ซับซ้อนมาก เราอาจจะไม่ค่อยได้ใช้ network ACL ในการทำ policy เพื่อ control traffic เท่าไร ยกเว้นในกรณีที่เป็นเรื่องของ network security เช่น หากเราโดน attack และต้องการจะ block IP ชุดนั้นทั้ง subnet เลย ก็ให้มาทำที่เจ้าตัวนี้ เป็นต้น
ใครอยากต่อส่วนที่เหลือสามารถตามไปที่ลิงค์นี้ได้ครับ
อย่าลืมนะครับ รบกวนทุกคนกด Follow/Subscribe ไว้ทุกช่องทางเลยนะครับ 🙏
- 💙 Facebook: Nopnithi Tech
- ❤️ YouTube: Nopnithi Tech
- 💙 LinkedIn: Nopnithi (Game) Khaokaew