AWS เปิด ECS Gateway จัดการ Ingress กลางให้ Container Service และแชร์ ALB ได้

AWS เปิดตัว Amazon ECS Gateway เมื่อวันที่ 20 ตุลาคม 2026 เพื่อให้ทีม platform กำหนดทางเข้า service กลาง แล้วให้ทีมแอปผูก ECS service เข้ากับ gateway โดยไม่ต้องตั้ง Application Load Balancer, certificate, listener rule, target group และ security group ใหม่ด้วยมือทุกครั้ง ทรัพยากรเครือข่ายยังถูกสร้างในบัญชี AWS ของลูกค้าเอง ข่าวนี้สำคัญกับองค์กรที่มี microservices จำนวนมาก เพราะงาน ingress ที่ทำซ้ำบ่อยเป็นจุดที่เกิดการตั้งค่าไม่สม่ำเสมอและชะลอการปล่อย service ใหม่

ใครตั้งค่าอะไร

ทีม platform สร้าง gateway ระดับ account ระบุ VPC, subnets, security groups, TLS certificate, listener และ WAF web ACL ตามมาตรฐานขององค์กร แล้วผูก gateway กับ ECS clusters ที่ต้องการเปิดใช้ ทีมแอปเพิ่ม gateway connector ตอนสร้างหรืออัปเดต service โดยระบุพอร์ตและตัวกรองการเข้าถึง เมื่อ service เชื่อมต่อได้ ECS จะจัดหา hostname เฉพาะ service, listener rule, target group และ security group ที่อนุญาตทราฟฟิกจาก ALB ตามประกาศ AWS แนวคิดนี้ช่วยแยกความรับผิดชอบ: คนดูแลเครือข่ายวางกรอบ ส่วนคนพัฒนา deploy service ภายในกรอบที่กำหนด

Gateway ใช้ host-based routing บน ALB หนึ่งตัวรองรับได้ถึง 25 services เมื่อจำนวน service เพิ่ม ระบบจะสร้าง ALB เพิ่มตาม capacity และขอบเขต maxAlbCount ที่กำหนด หากจำนวน ALB ถึงเพดานและไม่มีที่ว่าง deployment จะล้มเหลว ดังนั้นการใช้ gateway ไม่ได้แปลว่า capacity planning หายไป ก่อนทดลองควรนับ service ใน cluster รวมแผนขยายและตรวจ quota ของ ALB โดย AWS ระบุค่าเริ่มต้น maxAlbCount ที่ 10 การแชร์ ALB อาจช่วยลดทรัพยากรที่ซ้ำ แต่ค่าใช้จ่ายของ ALB และการใช้งานจริงยังต้องวัด

เงื่อนไขด้านเครือข่ายที่ต้องรู้

ฟีเจอร์รองรับ ECS services ที่ใช้ network mode awsvpc บน ECS EC2, Fargate และ ECS Managed Instances gateway ที่ผูกต้องอยู่ VPC เดียวกับ service และครอบคลุม Availability Zones ของ subnets ที่ service ใช้ หากกำหนด service ใน AZ ที่ gateway ไม่มี subnet ระบบจะไม่จับคู่เส้นทางอย่างที่คาด AWS แนะนำให้วางชุด AZ ของ gateway กับ service ให้สอดคล้องกัน นอกจากนี้ gateway มีทางเลือก public หรือ VPC-internal จึงควรแบ่งสภาพแวดล้อมที่ต้องเปิดอินเทอร์เน็ตออกจากระบบภายในตั้งแต่การออกแบบ

หลายค่าของ gateway เปลี่ยนไม่ได้หลังสร้าง รวมชื่อ scheme, VPC, subnets, ชนิด IP, protocol และ port ของ listener ควรตรวจรายการเหล่านี้ในช่วงทดสอบและตั้งชื่อที่สะท้อนขอบเขตการใช้งาน หากต้องเปลี่ยนสถาปัตยกรรมภายหลัง การสร้าง gateway ใหม่และย้าย service ทีละชุดอาจปลอดภัยกว่าพยายามเปลี่ยนค่าบน gateway เดิม การเข้าถึงยังควรควบคุมด้วย IAM ว่าใครมีสิทธิ์ผูก gateway กับ cluster หรือ deploy service เข้า cluster นั้น

วิธีนำของเดิมมาทดลอง

AWS ระบุว่าสามารถเพิ่ม gateway connector ให้ service ที่มี load balancer เดิมผ่าน UpdateService โดยให้ ingress สองทางอยู่ร่วมกันระหว่างทดสอบได้ ขั้นตอนนี้เหมาะสำหรับเปรียบเทียบ health check, header, TLS และ log ของเส้นทางเก่ากับใหม่ ก่อนถอดของเดิมออก เริ่มจาก service ที่ rollback ง่าย แล้วส่งคำขอจริงจำลองหลายแบบ ทั้ง path ปกติ request ที่ควรปฏิเสธ และกรณี backend ไม่พร้อม ตรวจว่า DNS hostname ใหม่ชี้ไป service ถูกตัวและ security group เปิดเฉพาะจาก ALB

ด้าน monitoring ให้ดู ALB metrics ใน CloudWatch โดยใช้ TargetGroup dimension สำหรับ service แต่ละตัว และ LoadBalancer dimension สำหรับ ALB ที่แชร์ ตรวจ target health รวมถึง HealthyHostCount, TargetResponseTime และ HTTPCode_Target_5XX_Count การดูเพียงว่า deployment สำเร็จไม่พอ เพราะ service อาจขึ้น ACTIVE แต่ตอบผิด path หรือ health check ยังไม่สะท้อนความพร้อมของแอป การลบ service จะให้ ECS เก็บทรัพยากรต่อ service และถ้าเป็น route สุดท้ายของ ALB ก็จะนำ ALB ออก แต่ทีมยังควรตรวจต้นทุนและสถานะหลังลบจริง

AWS ระบุว่า ECS Gateway เปิดใน commercial Regions ที่มี ECS โดยไม่มีค่าบริการ gateway เพิ่ม แต่ยังคิดค่าทรัพยากรพื้นฐานที่สร้าง เช่น ALB, CloudWatch, certificate ที่เกี่ยวข้อง และ data transfer ดังนั้นตัวเลขประหยัดต้องคำนวณจากรูปแบบทราฟฟิกจริง ข่าวนี้เหมาะกับทีมที่ต้องการมาตรฐาน ingress ระดับ platform และลดงานตั้งค่า service ซ้ำ พร้อมยอมรับว่าการควบคุม network, quota และ observability ยังต้องมีเจ้าของชัดเจน

อ่านประกาศต้นทางวันที่ 20 ตุลาคม 2026: AWS News Blog