บทความ 12

เมื่อคนเปิดเว็บไซต์หนึ่งครั้ง ข้อมูลเดินทางผ่าน AWS อย่างไร

ตามคำขอหนึ่งรายการตั้งแต่ผู้ใช้พิมพ์ชื่อเว็บ ผ่านด่านป้องกันและเครื่องที่รันแอป ไปจนถึงฐานข้อมูล พร้อมอธิบายว่าทำไมแต่ละส่วนจึงมีอยู่ และส่วนไหนไม่จำเป็นสำหรับทุกระบบ

22 นาที เจ้าของระบบ, Solution Architect, DevOps และ Tech Lead 2026-07-17

Infographic ภาพรวม

คำขอหนึ่งรายการเดินทางผ่านระบบอย่างไร

Route 53พาชื่อเว็บไซต์ไปยังจุดรับคำขอ

CloudFront + WAFส่งข้อมูลใกล้ผู้ใช้และกรองคำขออันตราย

Load Balancerแบ่งคำขอไปยังแอปที่ยังพร้อมทำงาน

ECS Fargateรันแอปและเพิ่มจำนวนเมื่อมีงานมากขึ้น

RDSข้อมูลหลัก

ElastiCacheข้อมูลที่เรียกซ้ำ

SQSงานที่รอทำต่อ

พาชื่อเว็บไซต์ไปยังจุดรับคำขอRoute 53ส่งข้อมูลใกล้ผู้ใช้และกรองคำขออันตรายCloudFront + WAFแบ่งคำขอไปยังแอปที่ยังพร้อมทำงานLoad Balancerรันแอปและเพิ่มจำนวนเมื่อมีงานมากขึ้นECS Fargate

เริ่มจากสิ่งที่ระบบต้องรับมือ

ลองเริ่มจากเหตุการณ์ที่คนทำงานพบจริง

ชื่อบริการเยอะไม่ได้แปลว่าระบบดี ทุกกล่องต้องตอบได้ว่าช่วยเรื่องอะไร

เวลาเห็นแผนภาพ AWS ที่มีกล่องต่อกันหลายชั้น คนที่ไม่ได้ทำงานด้านนี้อาจคิดว่ายิ่งมีกล่องมากยิ่งปลอดภัย ความจริงคือทุกกล่องเพิ่มทั้งค่าใช้จ่ายและงานดูแล ก่อนเลือกจึงต้องรู้ก่อนว่า หากระบบหยุดหนึ่งชั่วโมงธุรกิจเสียอะไร ข้อมูลใดห้ามรั่ว คนเข้าใช้พร้อมกันประมาณเท่าไร และทีมยอมใช้เวลานานแค่ไหนในการกู้ระบบ ตัวอย่างนี้เป็นเพียงภาพตั้งต้นของเว็บหรือ API สำหรับธุรกิจทั่วไป ระบบเล็กอาจไม่ต้องใช้ทุกส่วน ส่วนระบบที่หยุดไม่ได้อาจต้องมีสำรองมากกว่านี้

คำที่คุณจะเจอในบทความ

แต่ละคำหมายถึงอะไร และเกี่ยวข้องกับระบบตรงไหน

ไม่ต้องจำทั้งหมดในครั้งเดียว อ่านเพื่อให้รู้หน้าที่คร่าว ๆ ก่อน แล้วค่อยกลับมาเทียบเมื่อเจอคำนั้นในเนื้อหา

Region: พื้นที่หลักที่ AWS เปิดให้บริการ เช่น Singapore หรือ Tokyo เราเลือกพื้นที่นี้โดยดูว่าผู้ใช้อยู่ใกล้ที่ไหน มีกฎหมายเรื่องข้อมูลหรือไม่ และบริการที่ต้องการมีให้ใช้หรือเปล่า
Availability Zone (AZ): กลุ่มศูนย์ข้อมูลที่แยกจากกันภายใน Region เดียวกัน หากวางแอปไว้สอง AZ ปัญหาที่จุดหนึ่งจะไม่ทำให้ระบบหยุดทั้งหมดโดยง่าย
VPC: พื้นที่เครือข่ายส่วนตัวของระบบบน AWS เปรียบเหมือนรั้วที่เราใช้แบ่งว่าจุดไหนรับคนจากอินเทอร์เน็ต และจุดไหนให้คุยกันเฉพาะภายใน
Public / Private Subnet: Public Subnet มีทางเชื่อมกับอินเทอร์เน็ต ส่วน Private Subnet ซ่อนเครื่องแอปหรือฐานข้อมูลไว้ด้านใน ไม่รับการเชื่อมต่อจากคนภายนอกโดยตรง
WAF: ด่านตรวจคำขอที่เข้ามาทางเว็บ ช่วยบล็อกรูปแบบโจมตี Bot หรือคนที่ยิงคำขอถี่ผิดปกติ แต่ยังต้องตรวจสิทธิ์ผู้ใช้ซ้ำในตัวแอป
Auto Scaling: กติกาสำหรับเพิ่มหรือลดจำนวนเครื่องที่รันแอปตามปริมาณงาน เช่น เพิ่มเมื่อ CPU สูงต่อเนื่อง และลดเมื่อช่วงพีคผ่านไป
Multi-AZ: การมีส่วนสำรองอยู่อีก Availability Zone เพื่อให้ระบบยังไปต่อได้เมื่อศูนย์ข้อมูลกลุ่มหนึ่งมีปัญหา
IAM: ระบบกำหนดว่าใครหรือบริการใดทำอะไรใน AWS ได้บ้าง หลักที่ดีคือให้สิทธิ์เท่าที่ต้องใช้และไม่ใช้กุญแจร่วมกัน

ถ้าคุณไม่ได้ทำงานสายเทคนิค ให้เริ่มจากส่วนนี้

เมื่อคนเปิดเว็บไซต์หนึ่งครั้ง ข้อมูลเดินทางผ่าน AWS อย่างไร

คนบนอินเทอร์เน็ตควรเข้าถึงได้เฉพาะประตูที่เราเตรียมไว้ ไม่ควรต่อถึงเครื่องแอปหรือฐานข้อมูลโดยตรง

ด่านหน้าแต่ละชั้นมีงานต่างกัน: DNS หาปลายทาง, CDN ส่งข้อมูลใกล้ผู้ใช้, WAF กรองคำขอที่น่าสงสัย และ Load Balancer แบ่งงานให้แอป

เครื่องที่รันแอปควรมีมากกว่าหนึ่งจุด หากจุดหนึ่งมีปัญหาอีกจุดยังรับงานต่อได้ ส่วนข้อมูลต้องมีทั้งการสำรองและการทดลองกู้กลับ

การเฝ้าระวัง วิธีเปิดเวอร์ชันใหม่ การเก็บรหัสลับ ค่าใช้จ่าย และแผนกู้ระบบต้องออกแบบพร้อมกัน ไม่ใช่รอให้ระบบล่มแล้วค่อยเพิ่ม

ภาพขยายความแบบเคลื่อนไหว

ดูความสัมพันธ์ของแต่ละขั้น ก่อนลงรายละเอียด

เลือกแต่ละขั้นเพื่อดูว่าเกิดอะไรขึ้น ต้องตรวจข้อมูลใด และผลจากขั้นหนึ่งส่งต่อไปยังขั้นถัดไปอย่างไร

ขั้น 01 / 05

01 / ด่านหน้า

เริ่มจากชื่อเว็บไซต์: ระบบต้องหาปลายทาง ส่งข้อมูลให้เร็ว และกันคำขออันตราย

เมื่อผู้ใช้พิมพ์ชื่อเว็บ Route 53 จะตอบว่าคำขอนี้ต้องไปที่ใด จากนั้น CloudFront รับการเชื่อมต่อไว้ใกล้ผู้ใช้และส่งไฟล์ที่เก็บสำเนาไว้ได้ทันที จึงช่วยให้รูปหรือไฟล์เปิดเร็วขึ้นและลดงานของเครื่องหลัก ก่อนคำขอจะผ่านเข้าแอป WAF จะตรวจรูปแบบที่ดูคล้ายการโจมตี ตรวจหมายเลข IP ที่มีประวัติเสี่ยง และจำกัดคนที่ส่งคำขอถี่เกินไป อย่างไรก็ตาม WAF ไม่รู้ว่าพนักงานคนใดมีสิทธิ์เห็นใบสั่งซื้อใด เรื่องนั้นแอปยังต้องตรวจเอง และหน้าที่มีข้อมูลส่วนตัวต้องตั้งค่าไม่ให้ CloudFront นำสำเนาของคนหนึ่งไปแสดงให้อีกคน

รายละเอียดเชิงลึก

ค่อย ๆ ดูทีละส่วนว่าเกิดอะไรขึ้น และควรเตรียมอย่างไร

เราเริ่มจากผลที่คนใช้งานหรือธุรกิจจะพบ แล้วจึงอธิบายว่าทีมเทคนิคต้องตรวจอะไร มีตัวอย่างแบบไหน และจุดใดไม่ควรปล่อยให้เดาเอง

01 / ด่านหน้า

เริ่มจากชื่อเว็บไซต์: ระบบต้องหาปลายทาง ส่งข้อมูลให้เร็ว และกันคำขออันตราย

02 / เครือข่ายและ App

เมื่อคำขอผ่านด่านหน้าแล้ว Load Balancer จะแบ่งงานให้แอปที่ยังพร้อม

Application Load Balancer เปรียบเหมือนคนจัดคิวหน้าห้อง มันตรวจว่าแอปแต่ละชุดยังตอบสนองหรือไม่ แล้วส่งคำขอไปยังชุดที่พร้อมทำงาน แอปรันเป็น ECS Task บน Fargate ซึ่งช่วยให้ทีมไม่ต้องดูแลเครื่อง Server ทีละเครื่อง และสามารถเพิ่มจำนวน Task เมื่อมีงานมากขึ้นได้ แต่ทีมยังต้องกำหนดว่าแต่ละ Task ใช้ CPU กับ Memory เท่าไร เพิ่มหรือลดเมื่อใด และเปิดเวอร์ชันใหม่อย่างไร เครื่องแอปควรอยู่ใน Private Subnet โดยรับการเชื่อมต่อจาก Load Balancer เท่านั้น ส่วนฐานข้อมูลก็รับเฉพาะจากแอป ไม่ควรเปิด Port ฐานข้อมูลหรือ SSH ให้ทั้งอินเทอร์เน็ตเข้าถึงเพื่อความสะดวก

ลองตามคำขอหนึ่งรายการ

จากชื่อเว็บไปถึงข้อมูลที่ต้องใช้

Route 53 หาปลายทางให้ชื่อเว็บ จากนั้น CloudFront และ WAF รับคำขอที่ด่านหน้า Load Balancer เลือก ECS Fargate ชุดที่พร้อม แล้วแอปจึงอ่านข้อมูลหลักจาก RDS อ่านข้อมูลที่เรียกซ้ำจาก ElastiCache หรือส่งงานที่ใช้เวลานานไปต่อคิวใน SQS ภาพเคลื่อนไหวด้านบนแสดงเส้นทางนี้ทีละช่วง

03 / ข้อมูล

ข้อมูลแต่ละชนิดไม่ได้ควรอยู่ที่เดียวกัน และฐานข้อมูลไม่ควรเปิดรับอินเทอร์เน็ต

RDS ใช้กับข้อมูลที่ต้องเชื่อมโยงและถูกต้องเป็นชุด เช่น ลูกค้า คำสั่งซื้อ หรือการชำระเงิน ส่วนไฟล์รูปและเอกสารเหมาะกับ S3 มากกว่า ElastiCache เก็บข้อมูลที่ถูกเรียกซ้ำไว้ชั่วคราวเพื่อให้ตอบเร็วขึ้น และ SQS พักงานที่ไม่จำเป็นต้องเสร็จในคำขอเดียว เช่น ส่งอีเมลหรือสร้างรายงานขนาดใหญ่ การเพิ่ม Cache หรือ Queue ช่วยเรื่องความเร็ว แต่ทำให้ต้องตอบคำถามใหม่ด้วย เช่น ถ้างานถูกส่งซ้ำจะเกิดรายการซ้ำหรือไม่ และงานที่ทำไม่สำเร็จจะไปอยู่ที่ไหน ฐานข้อมูลควรเข้ารหัส มีสำรอง และทดลองกู้กลับตามเวลาที่ธุรกิจต้องการ การมีเครื่องสำเนาไม่เท่ากับมี Backup เพราะหากมีคนลบข้อมูลผิด การลบนั้นอาจถูกส่งตามไปที่เครื่องสำเนาด้วย

04 / ควบคุมและมองเห็น

กำหนดว่าใครเข้าถึงอะไร เก็บรหัสลับให้ถูกที่ และส่งสัญญาณเตือนไปหาคนที่ลงมือได้

คนและบริการไม่ควรใช้กุญแจชุดเดียวกันหรือได้สิทธิ์มากเกินหน้าที่ แอปควรใช้ IAM Role ที่ AWS ออกสิทธิ์ให้ชั่วคราว ส่วนรหัสผ่านฐานข้อมูลและ API Key ควรเก็บใน Secrets Manager ไม่วางไว้ใน Source Code CloudWatch ใช้รวมตัวเลข Log และสัญญาณเตือนของระบบ แต่การมี Alert อย่างเดียวไม่ช่วย หากไม่มีคนรับและไม่มีขั้นตอนบอกว่าต้องตรวจอะไรต่อ Log ควรเชื่อมเหตุการณ์เดียวกันด้วย Request ID กำหนดว่าจะเก็บนานเท่าไร และปิดบังข้อมูลส่วนบุคคลก่อนบันทึก

05 / ส่งมอบและกู้คืน

แผนเปิดเวอร์ชันใหม่ แผนกู้ระบบ และค่าใช้จ่ายต้องทดลองและติดตามจริง

ทุกเวอร์ชันควรย้อนกลับไปได้ว่าสร้างจาก Source Code จุดใด ผ่านการทดสอบอะไร และใครอนุมัติ การเปิดใช้ควรค่อย ๆ เปลี่ยนเครื่องหรือสลับไปชุดใหม่ พร้อมหยุดเมื่ออัตราผิดพลาดสูงขึ้น สำหรับการกู้ระบบ ธุรกิจต้องตอบสองคำถามก่อน: ยอมเสียข้อมูลย้อนหลังได้กี่นาที และยอมให้ระบบหยุดได้นานเท่าไร แล้วทีมจึงออกแบบ Backup และซ้อมกู้ให้ตรงกับคำตอบนั้น ด้านค่าใช้จ่ายควรแยกได้ว่าระบบใดใช้เงินเท่าไร มีงบเตือน และทบทวนขนาดเป็นรอบ หากจะลดเครื่องสำรองเพื่อประหยัด ต้องบอกธุรกิจให้ชัดว่าความเสี่ยงเพิ่มขึ้นอย่างไร

ถ้าคุณเป็นคนออกแบบหรือดูแลระบบ

ตรวจทั้งหกมุมของ AWS Well-Architected: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization และ Sustainability โดยบันทึก trade-off

ก่อนนำไปใช้ ลองตรวจทีละข้อนี้

กำหนด impact, RPO, RTO และ load model

แยก public/private subnet อย่างมีเหตุผล

กระจาย app อย่างน้อยสอง AZ

จำกัด Security Group ตามเส้นทาง

ใช้ IAM Role และ least privilege

เก็บ Secret นอก source code

เข้ารหัสและทดสอบ restore ข้อมูล

ตั้ง autoscaling พร้อม min/max

เชื่อม alert กับ owner/runbook

ตั้ง tag, budget และ cost anomaly

ทดสอบ deployment/rollback