คำถามที่พบบ่อยเกี่ยวกับ Elastic Load Balancing

Application Load Balancer รองรับเป้าหมายที่ใช้ระบบปฏิบัติการใด ๆ ซึ่งบริการ Amazon EC2 รองรับในปัจจุบัน

Application Load Balancer รองรับการปรับสมดุลโหลดของแอปพลิเคชันที่ใช้โปรโตคอล HTTP และ HTTPS (HTTP ที่ปลอดภัย)

ใช่ Application Load Balancer จะเปิดใช้การรองรับ HTTP/2 แบบเนทีฟ ไคลเอ็นต์ที่รองรับ HTTP/2 สามารถเชื่อมต่อกับ Application Load Balancer ได้ผ่าน TLS

คุณสามารถส่งต่อการรับส่งข้อมูลจาก Network Load Balancer ซึ่งรองรับ PrivateLink และที่อยู่ IP แบบคงที่ต่อ Availability Zone ไปยัง Application Load Balancer ของคุณได้ สร้างกลุ่มเป้าหมายประเภท Application Load Balancer, ลงทะเบียน Application Load Balancer กับกลุ่มเป้าหมาย และกำหนดค่า Network Load Balancer เพื่อส่งต่อการรับส่งข้อมูลไปยังกลุ่มเป้าหมายประเภท Application Load Balancer ดังกล่าว

คุณสามารถดำเนินการปรับสมดุลโหลดสำหรับพอร์ต TCP ต่อไปนี้ได้: 1-65535

ใช่ การรองรับ WebSockets และ Secure WebSockets จะมีให้ใช้งานและพร้อมใช้งานแบบเนทีฟใน Application Load Balancer

ใช่ Application Load Balancer จะเปิดใช้การสืบย้อนคำขอตามค่าเริ่มต้น

แม้ว่าจะมีบางอย่างที่คล้ายกัน แต่โหลดบาลานเซอร์สองประเภทนี้จะไม่มีคุณสมบัติที่เท่าเทียมกัน Application Load Balancer คือรากฐานของแพลตฟอร์มการปรับสมดุลโหลดที่เลเยอร์แอปพลิเคชันสำหรับในอนาคต

ใช่

ใช่

ไม่ได้ Application Load Balancer ต้องใช้อินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน (Application Programming Interface หรือ API) ชุดใหม่

ELB Console จะช่วยให้คุณจัดการ Application Load Balancer และ Classic Load Balancer จากอินเทอร์เฟซเดียวกันได้ หากคุณกำลังใช้อินเทอร์เฟซบรรทัดคำสั่ง (Command-Line Interface หรือ CLI) หรือชุดเครื่องมือพัฒนาซอฟต์แวร์ (Software Development Kit หรือ SDK) คุณจะใช้ “บริการ” อื่นสำหรับ Application Load Balancer ตัวอย่างเช่น ใน CLI คุณจะอธิบาย Classic Load Balancer โดยใช้ `aws elb describe-load-balancers` และ Application Load Balancer โดยใช้ `aws elbv2 describe-load-balancers`

ไม่ได้ คุณไม่สามารถแปลงโหลดบาลานเซอร์ประเภทหนึ่งเป็นอีกประเภทหนึ่งได้

ใช่ คุณสามารถย้ายข้อมูลจาก Classic Load Balancer ไปยัง Application Load Balancer โดยใช้หนึ่งในตัวเลือกที่ระบุไว้ในเอกสารนี้ได้

ไม่ได้ หากต้องการคุณสมบัติเลเยอร์ 4 คุณควรใช้ Network Load Balancer

ใช่ คุณสามารถเพิ่ม listener สำหรับ HTTP พอร์ต 80 และ HTTPS พอร์ต 443 ไปยัง Application Load Balancer ตัวเดียวได้

ใช่ หากต้องการรับประวัติการเรียกใช้ Application Load Balancing API ที่ดำเนินการในบัญชีของคุณ ให้ใช้ AWS CloudTrail

ใช่ คุณสามารถยกเลิกใช้งานการเชื่อมต่อ HTTPS ใน Application Load Balancer ได้ คุณจะต้องติดตั้งใบรับรอง Secure Sockets Layer (SSL) ในโหลดบาลานเซอร์ โหลดบาลานเซอร์จะใช้ใบรับรองนี้เพื่อยกเลิกใช้งานการเชื่อมต่อดังกล่าว และจากนั้นก็จะถอดรหัสคำขอจากไคลเอ็นต์ก่อนที่จะส่งไปยังเป้าหมาย

คุณสามารถเลือกใช้ AWS Certificate Manager เพื่อจัดสรรใบรับรอง SSL/TLS หรือจะรับใบรับรองจากแหล่งที่มาอื่น ๆ ได้โดยการสร้างคำขอใบรับรอง รับคำขอใบรับรองที่ CA ลงชื่อแล้ว และจากนั้นจึงอัปโหลดใบรับรองดังกล่าวโดยเลือกใช้ AWS Certification Manager หรือบริการ AWS Identity and Access Management (IAM)

Application Load Balancer จะผสานรวมกับ AWS Certificate Manager (ACM) การผสานรวมกับ ACM จะช่วยให้การผูกใบรับรองกับโหลดบาลานเซอร์เป็นเรื่องง่ายขึ้น ซึ่งทำให้กระบวนการออฟโหลด SSL ทั้งกระบวนการมีประสิทธิภาพมากขึ้น การซื้อ การอัปโหลด และการต่ออายุใบรับรอง SSL/TLS เป็นกระบวนการที่ซับซ้อน ต้องดำเนินการด้วยตนเอง และใช้เวลานาน แต่ด้วยการผสานรวม ACM กับ Application Load Balancer ขั้นตอนทั้งหมดนี้จึงสั้นลง เพื่อให้การส่งคำขอใบรับรอง SSL/TLS ที่น่าเชื่อถือและการเลือกใบรับรอง ACM เพื่อจัดเตรียมให้มีโหลดบาลานเซอร์เป็นเรื่องง่าย

ไม่ แบ็คเอนด์ที่ใช้ Application Load Balancer รองรับเฉพาะการเข้ารหัสเท่านั้น

ระบบจะเปิดใช้ SNI โดยอัตโนมัติเมื่อคุณเชื่อมโยงใบรับรอง TLS มากกว่าหนึ่งรายการกับ listener ที่ปลอดภัยรายการเดียวกันในโหลดบาลานเซอร์ เช่นเดียวกัน ระบบจะปิดใช้โหมด SNI สำหรับ listener ที่ปลอดภัยโดยอัตโนมัติเมื่อคุณมีใบรับรองเพียงรายการเดียวเชื่อมโยงอยู่กับ listener ที่ปลอดภัย

ใช่ คุณสามารถเชื่อมโยงใบรับรองหลายรายการกับ listener ที่ปลอดภัยสำหรับโดเมนเดียวกันได้ ตัวอย่างเช่น คุณสามารถเชื่อมโยง:

• ใบรับรอง ECDSA และ RSA
• ใบรับรองที่มีขนาดคีย์ที่แตกต่างกัน (เช่น 2K และ 4K) สำหรับใบรับรอง SSL/TLS
• ใบรับรองแบบโดเมนเดียว หลายโดเมน (SAN) และ Wildcard

ใช่ Application Load Balancer รองรับ IPv6

คุณสามารถกำหนดค่ากฎสำหรับกระบวนการรอรับแต่ละรายการใน Load Balancer ได้ กฎต่างๆ จะประกอบด้วยเงื่อนไขและการดำเนินการที่สอดคล้องกันหากตรงตามเงื่อนไข เงื่อนไขที่รองรับได้แก่ ส่วนหัวของโฮสต์, เส้นทาง, ส่วนหัว HTTP, วิธีการ, พารามิเตอร์การสืบค้น และ เส้นทางระหว่างโดเมนแบบไม่มีคลาส (Classless Inter-Domain Routing หรือ CIDR) ของ IP ต้นทาง การดำเนินการที่รองรับได้แก่ การเปลี่ยนเส้นทาง การตอบสนองแบบคงที่ การรับรองความถูกต้อง และการส่งต่อ เมื่อตั้งค่าแล้ว โหลดบาลานเซอร์จะใช้กฎเพื่อกำหนดว่าคำขอ HTTP แต่ละรายการควรได้รับการจัดเส้นทางอย่างไร คุณสามารถใช้เงื่อนไขและการดำเนินการหลายรูปแบบในกฎเดียวได้ และสามารถระบุการจับคู่หลายค่าได้ในแต่ละเงื่อนไข

บัญชี AWS ของคุณมีข้อจำกัดต่อไปนี้สำหรับ Application Load Balancer

คุณสามารถผสานรวม Application Load Balancer เข้ากับ AWS Web Application Firewall (WAF) ซึ่งเป็นไฟร์วอลล์ของเว็บแอปพลิเคชันที่ช่วยปกป้องเว็บแอปพลิเคชันของคุณจากการโจมตี โดยช่วยให้คุณสามารถกำหนดค่ากฎตามที่อยู่ IP, ส่วนหัวของ HTTP และสตริงตัวระบุทรัพยากรสากล (Uniform Resource Identifier หรือ URI) แบบกำหนดเองได้ การใช้กฎเหล่านี้ช่วยให้ AWS WAF สามารถบล็อก อนุญาต หรือเฝ้าติดตาม (นับ) คำขอจากเว็บสำหรับเว็บแอปพลิเคชันของคุณได้ โปรดดูข้อมูลเพิ่มเติมในคู่มือสำหรับนักพัฒนา AWS WAF

คุณสามารถใช้ที่อยู่ IP ใด ๆ จาก VPC CIDR ของ Load Balancer สำหรับเป้าหมายภายใน VPC ของ Load Balancer และที่อยู่ IP ใด ๆ จากช่วง RFC 1918 (10.0.0.0/8, 172.16.0.0/12 และ 192.168.0.0/16) หรือช่วง RFC 6598 (100.64.0.0/10) สำหรับเป้าหมายที่อยู่ภายนอก VPC ของ Load Balancer (ตัวอย่างเช่น เป้าหมายใน VPC ระดับเดียวกัน, Amazon EC2 Classic และสถานที่ตั้งภายในองค์กรซึ่งเข้าถึงได้ผ่าน AWS Direct Connect หรือการเชื่อมต่อ VPN)

มีหลายวิธีในการปรับสมดุลโหลดแบบไฮบริด หากแอปพลิเคชันรันอยู่บนเป้าหมายที่กระจายอยู่ระหว่าง VPC กับสถานที่ตั้งภายในองค์กร คุณสามารถเพิ่มไปยังกลุ่มเป้าหมายเดียวกันได้โดยใช้ที่อยู่ IP ของเป้าหมาย หากต้องการย้ายข้อมูลไปยัง AWS โดยไม่ให้ส่งผลต่อแอปพลิเคชัน ให้ค่อยๆ เพิ่มเป้าหมาย VPC ไปยังกลุ่มเป้าหมายและลบเป้าหมายภายในองค์กรออกจากกลุ่มเป้าหมาย 

หากคุณมีแอปพลิเคชันที่แตกต่างกันสองตัว เช่น เป้าหมายของแอปพลิเคชันหนึ่งอยู่ใน VPC ส่วนเป้าหมายของอีกแอปพลิเคชันหนึ่งอยู่ในสถานที่ตั้งภายในองค์กร คุณสามารถนำเป้าหมาย VPC เข้าไปไว้ในกลุ่มเป้าหมายหนึ่ง และนำเป้าหมายภายในองค์กรเข้าไปไว้ในอีกกลุ่มเป้าหมายหนึ่งได้ รวมทั้งยังใช้เนื้อหาที่อิงตามการกำหนดเส้นทางเพื่อกำหนดเส้นทางการรับส่งข้อมูลไปยังแต่ละกลุ่มเป้าหมายได้อีกด้วย คุณยังสามารถใช้โหลดบาลานเซอร์แยกต่างหากสำหรับเป้าหมาย VPC และเป้าหมายภายในองค์กร รวมทั้งยังสามารถใช้การถ่วงน้ำหนัก DNS เพื่อปรับสมดุลโหลดที่มีการถ่วงน้ำหนักระหว่างเป้าหมาย VPC กับเป้าหมายภายในองค์กรได้อีกด้วย

คุณไม่สามารถปรับสมดุลโหลดไปยังอินสแตนซ์ EC2 Classic ได้เมื่อลงทะเบียนรหัสอินสแตนซ์เหล่านั้นเป็นเป้าหมาย แต่หากคุณลิงก์อินสแตนซ์ EC2 Classic เหล่านี้กับ VPC ของโหลดบาลานเซอร์โดยใช้ ClassicLink และใช้ IP ส่วนตัวของอินสแตนซ์ EC2 Classic เหล่านี้เป็นเป้าหมาย คุณก็สามารถปรับสมดุลโหลดไปยังอินสแตนซ์ EC2 Classic ได้ หากกำลังใช้อินสแตนซ์ EC2 Classic ที่มี Classic Load Balancer อยู่ในปัจจุบัน คุณก็สามารถย้ายข้อมูลไปยัง Application Load Balancer ได้อย่างง่ายดาย

เปิดใช้การปรับสมดุลโหลดข้ามโซนตามค่าเริ่มต้นอยู่แล้วใน Application Load Balancer

คุณควรใช้การตรวจสอบสิทธิ์ผ่าน Amazon Cognito หาก:

• คุณต้องการให้ผู้ใช้มีความยืดหยุ่นในการยืนยันตัวตนผ่านข้อมูลประจำตัวในเครือข่ายสังคม (Google, Facebook และ Amazon) หรือข้อมูลประจำตัวระดับองค์กร (SAML) หรือผ่านไดเรกทอรีผู้ใช้ของคุณเองซึ่งให้บริการโดย User Pool ของ Amazon Cognito
• คุณกำลังจัดการผู้ให้บริการข้อมูลประจำตัวหลายรายซึ่งรวมถึง OpenID Connect และต้องการสร้างกฎการตรวจสอบสิทธิ์รายการเดียวใน Application Load Balancer (ALB) ซึ่งสามารถใช้ Amazon Cognito เพื่อรวมศูนย์ผู้ให้บริการข้อมูลประจำตัวหลายรายได้
• คุณต้องจัดการโปรไฟล์ผู้ใช้ที่มีผู้ให้บริการข้อมูลประจำตัวในเครือข่ายสังคมหรือ OpenID Connect หนึ่งรายขึ้นไปจากส่วนกลางจุดเดียวอยู่เสมอ เช่น คุณสามารถรวมผู้ใช้ไว้ในกลุ่ม และเพิ่มแอตทริบิวต์ที่กำหนดเองเพื่อแสดงสถานะของผู้ใช้ รวมทั้งควบคุมการเข้าถึงสำหรับผู้ใช้แบบเสียค่าใช้จ่ายได้

นอกจากนี้ หากคุณลงทุนในการพัฒนาโซลูชัน IdP แบบกำหนดเอง และเพียงแค่ต้องการตรวจสอบสิทธิ์โดยอาศัยผู้ให้บริการข้อมูลประจำตัวรายเดียวที่ใช้งานร่วมกับ OpenID Connect ได้ คุณอาจเลือกใช้โซลูชัน OIDC แบบเนทีฟของ Application Load Balancer

รองรับการเปลี่ยนเส้นทาง 3 ประเภทดังต่อไปนี้

HTTP ไปยัง HTTP
http://hostA ไปยัง http://hostB

HTTP ไปยัง HTTPS
http://hostA ไปยัง https://hostB
https://hostA:portA/pathA ไปยัง https://hostB:portB/pathB

HTTPS ไปยัง HTTPS
https://hostA ไปยัง https://hostB

รองรับเนื้อหาประเภทดังต่อไปนี้: text/plain, text/css, text/html, application/javascript, application/json

คำขอ HTTP(S) ที่ Load Balancer ได้รับจะประมวลผลด้วยกฎการเปลี่ยนเส้นทางตามเนื้อหา หากเนื้อหาของคำขอตรงกับกฎที่มีการดำเนินการเพื่อส่งต่อไปยังกลุ่มเป้าหมายผ่านฟังก์ชัน Lambda เป็นเป้าหมาย ดังนั้นระบบจะเรียกฟังก์ชัน Lambda ที่เกี่ยวข้อง ระบบจะส่งต่อเนื้อหาของคำขอ (รวมถึงส่วนหัวและเนื้อความ) ไปยังฟังก์ชัน Lambda ในรูปแบบ JavaScript Object Notation (JSON) การตอบสนองจากฟังก์ชัน Lambda ควรอยู่ในรูปแบบ JSON ระบบจะแปลงการตอบสนองจากฟังก์ชัน Lambda ให้เป็นการตอบสนอง HTTP และส่งต่อไปยังไคลเอ็นต์ โหลดบาลานเซอร์จะเรียกฟังก์ชัน Lambda โดยใช้ AWS Lambda Invoke API และคุณจำเป็นต้องให้สิทธิ์ในการเรียกสำหรับฟังก์ชัน Lambda ไปยังบริการ Elastic Load Balancing

ใช่ Application Load Balancer รองรับการเรียก Lambda สำหรับคำขอจากโปรโตคอลทั้ง HTTP และ HTTPS

คุณสามารถใช้ Lambda เป็นเป้าหมายกับ Application Load Balancer ในสหรัฐอเมริกาฝั่งตะวันออก (เวอร์จิเนียเหนือ) สหรัฐอเมริกาฝั่งตะวันออก (โอไฮโอ) สหรัฐอเมริกาฝั่งตะวันตก (แคลิฟอร์เนียตอนเหนือ) สหรัฐอเมริกาฝั่งตะวันตก (ออริกอน) เอเชียแปซิฟิก (มุมไบ) เอเชียแปซิฟิก (โซล) เอเชียแปซิฟิก (สิงคโปร์) เอเชียแปซิฟิก (ซิดนีย์) เอเชียแปซิฟิก (โตเกียว) แคนาดา (ภาคกลาง) สหภาพยุโรป (แฟรงเฟิร์ต) สหภาพยุโรป (ไอร์แลนด์) สหภาพยุโรป (ลอนดอน) สหภาพยุโรป (ปารีส) อเมริกาใต้ (เซาเปาลู) และ AWS GovCloud (สหรัฐอเมริกาฝั่งตะวันตก) ได้แล้ว

ใช่ Application Load Balancer ให้บริการแล้วในโซนท้องถิ่นของลอสแองเจลิส ภายในโซนท้องถิ่นของลอสแองเจลิส Application Load Balancer จะให้บริการด้วยเครือข่ายย่อยเดียวและจะขยายตัวอัตโนมัติเพื่อรองรับการใช้งานในทุกระดับโดยไม่ต้องอาศัยการดำเนินการด้วยตนเอง

ระบบจะคิดค่าใช้จ่ายสำหรับแต่ละชั่วโมงหรือเศษของชั่วโมงที่รัน Application Load Balancer อยู่และจำนวนหน่วยปริมาณของ Load Balancer (LCU) ที่ใช้ต่อชั่วโมง

LCU คือตัววัดใหม่สำหรับกำหนดวิธีที่คุณชำระเงินสำหรับ Application Load Balancer LCU จะกำหนดทรัพยากรสูงสุดที่ใช้ในแง่มุมใด ๆ (การเชื่อมต่อใหม่ การเชื่อมต่อที่ใช้งานอยู่ แบนด์วิดท์ และค่าประเมินตามกฎ) ที่ Application Load Balancer ประมวลผลปริมาณรับส่งข้อมูลของคุณ

ไม่ ระบบจะยังคงเรียกเก็บค่าบริการสำหรับ Classic Load Balancer ตามการใช้แบนด์วิดท์และการใช้งานเป็นรายชั่วโมง

เราจะแสดงการใช้งานทั้งสี่แง่มุมซึ่งประกอบรวมกันเป็น LCU ผ่านทาง Amazon CloudWatch

ไม่ใช่ จะกำหนดจำนวน LCU ต่อชั่วโมงตามทรัพยากรสูงสุดที่ใช้งานในทั้งสี่แง่มุมซึ่งประกอบรวมกันเป็น LCU หนึ่งหน่วย

ใช่

ใช่ สำหรับบัญชี AWS ใหม่นั้น Free Tier สำหรับ Application Load Balancer จะมอบข้อเสนอการใช้งาน 750 ชั่วโมงและ 15 LCU ข้อเสนอ Free Tier นี้ใช้ได้กับลูกค้า AWS รายใหม่เท่านั้น และจะพร้อมใช้งานเป็นเวลา 12 เดือนหลังจากวันที่สมัครใช้งาน AWS

ใช่ คุณสามารถใช้ทั้ง Classic Load Balancer และ Application Load Balancer ได้ 15 GB และ 15 LCU ตามลำดับ ชั่วโมงโหลดบาลานเซอร์ 750 ชั่วโมงจะใช้ร่วมกันได้ระหว่าง Classic Load Balancer และ Application Load Balancer

ค่าประเมินตามกฎจะคิดจากผลคูณของจำนวนกฎที่ได้รับการประมวลผลกับอัตราการส่งคำขอโดยเฉลี่ยต่อชั่วโมง

ขนาดคีย์ของใบรับรองจะมีผลเฉพาะกับจำนวนการเชื่อมต่อใหม่ต่อวินาทีในการประมวลผล LCU สำหรับการเรียกเก็บค่าบริการเท่านั้น ตารางต่อไปนี้จะระบุค่าตามแง่มุมนี้สำหรับขนาดคีย์ต่างๆ ของใบรับรอง RSA และ ECDSA

ใบรับรอง RSA
ขนาดคีย์: <=2K 
การเชื่อมต่อใหม่/วินาที: 25

ขนาดคีย์: <=4K 
การเชื่อมต่อใหม่/วินาที: 5

ขนาดคีย์: <=8K 
การเชื่อมต่อใหม่/วินาที: 1

ขนาดคีย์: >8K
การเชื่อมต่อใหม่/วินาที: 0.25

ใบรับรอง ECDSA
ขนาดคีย์: <=256
การเชื่อมต่อใหม่/วินาที: 25

ขนาดคีย์: <=384
การเชื่อมต่อใหม่/วินาที: 5

ขนาดคีย์: <=521 
การเชื่อมต่อใหม่/วินาที: 1

ขนาดคีย์: >521 
การเชื่อมต่อใหม่/วินาที: 0.25

ไม่ เนื่องจากการปรับสมดุลโหลดข้ามโซนจะเปิดใช้เสมอใน Application Load Balancer ระบบจึงไม่คิดค่าบริการคุณสำหรับการถ่ายโอนข้อมูลระดับภูมิภาคในประเภทนี้

ไม่ ไม่มีการคิดค่าบริการแยกต่างหากสำหรับการเปิดใช้ฟังก์ชันการตรวจสอบสิทธิ์ใน Application Load Balancer เมื่อใช้ Amazon Cognito ร่วมกับ Application Load Balancer จะมีการเรียกเก็บค่าบริการตามราคา Amazon Cognito

ระบบจะคิดค่าใช้จ่ายคุณตามปกติสำหรับแต่ละชั่วโมงหรือเศษของชั่วโมงที่รัน Application Load Balancer อยู่และจำนวนหน่วยความจุของโหลดบาลานเซอร์ (LCU) ที่ใช้ต่อชั่วโมง สำหรับเป้าหมาย Lambda นั้น LCU แต่ละรายการจะมีไบต์ที่ได้รับการประมวลผล 0.4 GB ต่อชั่วโมง การเชื่อมต่อใหม่ 25 รายการต่อวินาที การเชื่อมต่อที่ทำงานอยู่ 3,000 รายการต่อนาที และการประเมินกฎ 1,000 รายการต่อวินาที สำหรับแง่มุมของไบต์ที่ได้รับการประมวลผล LCU แต่ละรายการจะมีเป้าหมาย Lambda จำนวน 0.4 GB ต่อชั่วโมงเทียบกับ 1 GB ต่อชั่วโมงสำหรับประเภทเป้าหมายอื่น ๆ ทั้งหมด เช่น อินสแตนซ์ Amazon EC2, คอนเทนเนอร์ และที่อยู่ IP โปรดทราบว่าค่าบริการ AWS Lambda ตามปกติจะใช้กับการเรียก Lambda โดย Application Load Balancer

Application Load Balancer จะแสดงตัววัด CloudWatch ใหม่สองแบบ ตัววัด LambdaTargetProcessedBytes จะระบุไบต์ที่ได้รับการประมวลผลด้วยเป้าหมาย Lambda และตัววัด StandardProcessedBytes จะระบุไบต์ที่ได้รับการประมวลผลด้วยประเภทเป้าหมายแบบอื่น ๆ ทั้งหมด

ใช่ Network Load Balancer รองรับทั้ง TCP, UDP และ TCP+UDP listener (เลเยอร์ 4) รวมถึง TLS listener

Network Load Balancer ช่วยปรับสมดุลโหลดทั้ง TCP และ UDP (เลเยอร์ 4) ซึ่งได้รับการออกแบบสถาปัตยกรรมเพื่อรองรับคำขอนับล้านรายการต่อวินาที รวมถึงรูปแบบการรับส่งข้อมูลที่ฉับไวและเปลี่ยนแปลงตลอดเวลา อีกทั้งยังมีเวลาแฝงที่ต่ำมาก นอกจากนี้ Network Load Balancer ยังรองรับการยกเลิกใช้งาน TLS, รักษา IP ต้นทางของไคลเอ็นต์ และทำให้มีการรองรับ IP ที่เสถียรและการแยกตามโซนอีกด้วย รวมทั้งยังรองรับการเชื่อมต่อเป็นเวลานาน ซึ่งมีประโยชน์สำหรับแอปพลิเคชันประเภท WebSocket

ใช่ หากต้องการดำเนินการให้สำเร็จ คุณสามารถใช้กระบวนการรอรับ TCP+UDP ได้ ตัวอย่างเช่น สำหรับบริการ DNS ที่ใช้ทั้ง TCP และ UDP คุณสามารถสร้างกระบวนการรอรับ TCP+UDP ในพอร์ต 53 และโหลดบาลานเซอร์จะประมวลผลการรับส่งข้อมูลสำหรับทั้งคำขอ UDP และ TCP ในพอร์ตดังกล่าว คุณต้องเชื่อมโยงกระบวนการรอรับ TCP+UDP กับกลุ่มเป้าหมาย TCP+UDP

Network Load Balancer จะรักษา IP ต้นทางของไคลเอ็นต์ไว้ ในขณะที่ Classic Load Balancer จะไม่ได้รักษาไว้เช่นนั้น ลูกค้าสามารถใช้โปรโตคอลพร็อกซีกับ Classic Load Balancer เพื่อให้ได้ IP ต้นทาง Network Load Balancer จะให้ IP แบบคงที่กับโหลดบาลานเซอร์โดยอัตโนมัติตาม Availability Zone (AZ) และยังเปิดใช้การกำหนด Elastic IP ให้กับโหลดบาลานเซอร์ตาม AZ อีกด้วย Classic Load Balancer ไม่รองรับคุณสมบัตินี้

ใช่ คุณสามารถย้ายข้อมูลจาก Classic Load Balancer ไปยัง Network Load Balancer ได้โดยใช้หนึ่งในตัวเลือกที่ระบุไว้ในเอกสารนี้

มี โปรดดูเอกสารข้อจำกัดของ Network Load Balancer สำหรับข้อมูลเพิ่มเติม

ใช่ คุณสามารถใช้ AWS Management Console, AWS CLI หรือ API เพื่อตั้งค่า Network Load Balancer ได้

ไม่ได้ หากต้องการสร้าง Classic Load Balancer ให้ใช้ 2012-06-01 API หากต้องการสร้าง Network Load Balancer หรือ Application Load Balancer ให้ใช้ 2015-12-01 API

ได้ คุณสามารถสร้าง Network Load Balancer ใน AZ เดียวได้โดยการระบุเครือข่ายย่อยเดียวเมื่อสร้างโหลดบาลานเซอร์

ใช่ คุณสามารถใช้คุณสมบัติการตรวจสอบคุณภาพการทำงานของ Amazon Route 53 และการเปลี่ยนระบบ DNS เพื่อปรับปรุงความพร้อมใช้งานของแอปพลิเคชันที่รันอยู่เบื้องหลัง Network Load Balancer ได้ เมื่อใช้การเปลี่ยนระบบ DNS ของ Route 53 คุณจะสามารถรันแอปพลิเคชันได้ในหลาย Availability Zone ของ AWS และกำหนดโหลดบาลานเซอร์สำรองสำหรับการเปลี่ยนระบบในรีเจี้ยนได้ 

ในกรณีที่กำหนดค่า Network Load Balancer สำหรับหลาย AZ ไว้แล้ว หากไม่มีอินสแตนซ์ Amazon EC2 ที่สมบูรณ์ลงทะเบียนไว้กับโหลดบาลานเซอร์ดังกล่าวใน AZ นั้น หรือหากโหนดของโหลดบาลานเซอร์ในโซนนั้นไม่สมบูรณ์ Route 53 ก็จะเปลี่ยนระบบไปยังโหนดของโหลดบาลานเซอร์สำรองใน AZ อื่น ๆ ที่สมบูรณ์

ไม่ได้ ไม่คุณก็ ELB จะต้องเป็นฝ่ายควบคุมที่อยู่ของ Network Load Balancer โดยสมบูรณ์เท่านั้น ซึ่งทำให้แน่ใจว่า เมื่อใช้ Elastic IP ร่วมกับ Network Load Balancer ที่อยู่ทั้งหมดที่ไคลเอ็นต์รู้จักก็จะไม่เปลี่ยนแปลง

ไม่ได้ สำหรับเครือข่ายย่อยที่เชื่อมโยงไว้แต่ละเครือข่ายที่มี Network Load Balancer อยู่ในนั้น Network Load Balancer จะรองรับเฉพาะที่อยู่ IP แบบสาธารณะ/เข้าถึงผ่านอินเทอร์เน็ตที่อยู่เดียวเท่านั้น

ที่อยู่ Elastic IP ซึ่งเชื่อมโยงไว้กับ Load Balancer ของคุณจะกลับไปยังแหล่งรวมที่จัดสรรไว้และจะพร้อมใช้งานในอนาคต

สามารถตั้งค่า Network Load Balancer เป็นโหลดบาลานเซอร์แบบเข้าถึงผ่านอินเทอร์เน็ตหรือโหลดบาลานเซอร์ภายในที่คล้ายคลึงกับรายการที่รองรับใน Application Load Balancer และ Classic Load Balancer ได้

ไม่ได้ สำหรับเครือข่ายย่อยที่เชื่อมโยงไว้แต่ละเครือข่ายซึ่งมีโหลดบาลานเซอร์อยู่ในนั้น Network Load Balancer จะรองรับเฉพาะที่อยู่ IP ส่วนตัวที่อยู่เดียวเท่านั้น

ใช่ โปรดกำหนดค่า TCP listener ที่จัดเส้นทางการรับส่งข้อมูลไปยังเป้าหมายที่ใช้โปรโตคอล WebSockets (https://tools.ietf.org/html/rfc6455 ) เนื่องจาก WebSockets เป็นโปรโตคอลเลเยอร์ 7 และ Network Load Balancer ปฏิบัติการที่เลเยอร์ 4 ดังนั้นจึงไม่มีการจัดการพิเศษใน Network Load Balancer สำหรับ WebSockets หรือโปรโตคอลระดับสูงกว่าอื่น ๆ

ใช่ ตอบ: คุณสามารถใช้ที่อยู่ IP ใด ๆ จาก VPC CIDR ของโหลดบาลานเซอร์สำหรับเป้าหมายภายใน VPC ของโหลดบาลานเซอร์และที่อยู่ IP ใด ๆ จากช่วง RFC 1918 (10.0.0.0/8, 172.16.0.0/12 และ 192.168.0.0/16) หรือช่วง RFC 6598 (100.64.0.0/10) สำหรับเป้าหมายที่อยู่ภายนอก VPC ของโหลดบาลานเซอร์ (ตัวอย่างเช่น เป้าหมายใน VPC ระดับเดียวกัน, Amazon EC2 Classic และสถานที่ตั้งภายในองค์กรซึ่งเข้าถึงได้ผ่าน AWS Direct Connect หรือการเชื่อมต่อ VPN) โดยรองรับการปรับสมดุลโหลดไปยังประเภทเป้าหมายของที่อยู่ IP สำหรับกระบวนการรอรับ TCP เท่านั้น และในขณะนี้ยังไม่รองรับกระบวนการรอรับ UDP

ได้ คุณสามารถใช้ Network Load Balancer ที่มีกระบวนการรอรับ TCP และ TLS เพื่อตั้งค่า AWS PrivateLink ได้ คุณไม่สามารถตั้งค่า PrivateLink ด้วยกระบวนการรอรับ UDP บน Network Load Balancer ได้

แม้ว่าโปรโตคอลเดทาแกรมผู้ใช้ (User Datagram Protocol หรือ UDP) จะไม่มีการเชื่อมต่อ แต่ Load Balancer จะรักษาสถานะโฟลว์ของ UDP ตามแฮช 5-tuple โดยรับรองว่ากลุ่มข้อมูลที่ส่งในบริบทเดียวกันนั้นได้รับการส่งต่อไปยังเป้าหมายเดียวกันอย่างสม่ำเสมอ ระบบจะถือว่าโฟลว์ใช้งานอยู่ตราบใดที่การรับส่งข้อมูลยังคงไหลเวียนและจนถึงการหมดเวลาที่ไม่ได้ใช้งาน เมื่อถึงเกณฑ์การหมดเวลาแล้ว โหลดบาลานเซอร์จะลืมความเกี่ยวข้อง และจะพิจารณากลุ่มข้อมูล UDP ขาเข้าเป็นโฟลว์ใหม่และได้รับการปรับสมดุลโหลดกับเป้าหมายใหม่

การหมดเวลาที่ไม่ได้ใช้งานของ Network Load Balancer สำหรับการเชื่อมต่อ TCP คือ 350 วินาที การหมดเวลาที่ไม่ได้ใช้งานสำหรับโฟลว์ UDP คือ 120 วินาที

ขณะนี้คอนเทนเนอร์แต่ละรายการในอินสแตนซ์จะมีกลุ่มความปลอดภัยของตนเองและไม่จำเป็นต้องใช้กฎความปลอดภัยร่วมกับคอนเทนเนอร์อื่น คุณสามารถแนบกลุ่มความปลอดภัยกับ ENI ได้ และแต่ละ ENI บนอินสแตนซ์จะมีกลุ่มความปลอดภัยที่แตกต่างกัน คุณสามารถจับคู่คอนเทนเนอร์กับที่อยู่ IP ของ ENI ที่เฉพาะเจาะจงได้เพื่อเชื่อมโยงกลุ่มความปลอดภัยต่อคอนเทนเนอร์ นอกจากนี้ การปรับสมดุลโหลดที่ใช้ที่อยู่ IP ยังอนุญาตให้คอนเทนเนอร์หลายรายการที่รันบนอินสแตนซ์ใช้งานพอร์ตเดียวกัน (เช่น พอร์ต 80) ได้อีกด้วย ความสามารถในการใช้พอร์ตเดียวกันสำหรับคอนเทนเนอร์ต่างๆ จะทำให้คอนเทนเนอร์บนอินสแตนซ์สื่อสารกันได้ผ่านพอร์ตที่รู้จัก แทนที่จะเป็นพอร์ตแบบสุ่ม

มีหลายวิธีในการปรับสมดุลโหลดแบบไฮบริด หากแอปพลิเคชันรันอยู่บนเป้าหมายที่กระจายอยู่ระหว่าง VPC กับสถานที่ตั้งภายในองค์กร คุณสามารถเพิ่มไปยังกลุ่มเป้าหมายเดียวกันได้โดยใช้ที่อยู่ IP ของเป้าหมาย หากต้องการย้ายข้อมูลไปยัง AWS โดยไม่ให้ส่งผลต่อแอปพลิเคชัน ให้ค่อยๆ เพิ่มเป้าหมาย VPC ไปยังกลุ่มเป้าหมายและลบเป้าหมายภายในองค์กรออกจากกลุ่มเป้าหมาย คุณยังสามารถใช้โหลดบาลานเซอร์แยกต่างหากสำหรับเป้าหมาย VPC และเป้าหมายภายในองค์กร รวมทั้งยังสามารถใช้การถ่วงน้ำหนัก DNS เพื่อปรับสมดุลโหลดที่มีการถ่วงน้ำหนักระหว่างเป้าหมาย VPC กับเป้าหมายภายในองค์กรได้อีกด้วย

คุณไม่สามารถปรับสมดุลโหลดไปยังอินสแตนซ์ EC2 Classic ได้เมื่อลงทะเบียนรหัสอินสแตนซ์เหล่านั้นเป็นเป้าหมาย แต่หากคุณลิงก์อินสแตนซ์ EC2 Classic เหล่านี้กับ VPC ของโหลดบาลานเซอร์โดยใช้ ClassicLink และใช้ IP ส่วนตัวของอินสแตนซ์ EC2 Classic เหล่านี้เป็นเป้าหมาย คุณก็สามารถปรับสมดุลโหลดไปยังอินสแตนซ์ EC2 Classic ได้ หากคุณกำลังใช้อินสแตนซ์ EC2 Classic ที่มี Classic Load Balancer อยู่ในปัจจุบัน คุณจะย้ายข้อมูลไปยัง Network Load Balancer ได้อย่างง่ายดาย

คุณสามารถเปิดใช้การปรับสมดุลโหลดข้ามโซนได้หลังจากสร้าง Network Load Balance แล้วเท่านั้น คุณจะทำเช่นนี้ได้โดยการแก้ไขส่วนแอตทริบิวต์การปรับสมดุลโหลด แล้วเลือกช่องทำเครื่องหมายรองรับการปรับสมดุลโหลดข้ามโซน

ใช่ ระบบจะคิดค่าบริการคุณสำหรับการถ่ายโอนข้อมูลระดับภูมิภาคระหว่าง Availability Zone ต่างๆ ด้วย Network Load Balancer เมื่อเปิดใช้การปรับสมดุลโหลดข้ามโซน ตรวจสอบค่าบริการในส่วนการถ่ายโอนข้อมูลที่หน้าราคาแบบตามความต้องการของ Amazon EC2

ใช่ ปัจจุบัน Network Load Balancer รองรับ 200 เป้าหมายต่อ Availability Zone ตัวอย่างเช่น หากคุณอยู่ใน AZ สองโซน คุณก็จะมีเป้าหมายที่ลงทะเบียนไว้กับ Network Load Balancer ได้สูงสุด ถึง 400 เป้าหมาย หากเปิดใช้การปรับสมดุลโหลดข้ามโซน จำนวนเป้าหมายสูงสุดก็จะลดลงจาก 200 เป้าหมายต่อ AZ เป็น 200 เป้าหมายต่อโหลดบาลานเซอร์ ดังนั้น ในตัวอย่างด้านบนนี้ เมื่อเปิดใช้การปรับสมดุลโหลดข้ามโซน แม้ว่าโหลดบาลานเซอร์จะอยู่ใน AZ สองโซน แต่คุณก็จะถูกจำกัดให้มีเป้าหมายที่ลงทะเบียนไว้กับโหลดบาลานเซอร์ได้เพียง 200 เป้าหมายเท่านั้น

ใช่ คุณสามารถยกเลิกใช้งานการเชื่อมต่อ TLS บน Network Load Balancer ได้ คุณจะต้องติดตั้งใบรับรอง SSL ในโหลดบาลานเซอร์ โหลดบาลานเซอร์จะใช้ใบรับรองนี้เพื่อยกเลิกใช้งานการเชื่อมต่อดังกล่าว และจากนั้นก็จะถอดรหัสคำขอจากไคลเอ็นต์ก่อนที่จะส่งไปยังเป้าหมาย

IP ต้นทางจะยังได้รับการรักษาไว้แม้ว่าคุณจะยกเลิกการใช้งาน TLS บน Network Load Balancer

คุณสามารถเลือกใช้ AWS Certificate Manager เพื่อจัดสรรใบรับรอง SSL/TLS หรือจะรับใบรับรองจากแหล่งที่มาอื่น ๆ ได้โดยการสร้างคำขอใบรับรอง รับคำขอใบรับรองที่ผู้ออกใบรับรอง (Certificate Authority หรือ CA) ลงชื่อแล้ว และจากนั้นจึงอัปโหลดใบรับรองดังกล่าวโดยเลือกใช้ AWS Certification Manager (ACM) หรือบริการ AWS Identity and Access Management (IAM)

ระบบจะเปิดใช้ SNI โดยอัตโนมัติเมื่อคุณเชื่อมโยงใบรับรอง TLS มากกว่าหนึ่งรายการกับ listener ที่ปลอดภัยรายการเดียวกันในโหลดบาลานเซอร์ เช่นเดียวกัน ระบบจะปิดใช้โหมด SNI สำหรับ listener ที่ปลอดภัยโดยอัตโนมัติเมื่อคุณมีใบรับรองเพียงรายการเดียวเชื่อมโยงอยู่กับ listener ที่ปลอดภัย

Network Load Balancer จะผสานรวมกับ AWS Certificate Manager (ACM) การผสานรวมกับ ACM จะช่วยให้การผูกใบรับรองกับโหลดบาลานเซอร์เป็นเรื่องง่าย ซึ่งทำให้กระบวนการออฟโหลด SSL ทั้งกระบวนการง่ายดายมาก การซื้อ การอัปโหลด และการต่ออายุใบรับรอง SSL/TLS เป็นขั้นตอนที่ต้องทำด้วยตนเองซึ่งใช้เวลานาน และเป็นกระบวนการที่ซับซ้อน แต่ด้วยการผสานรวม ACM กับ Network Load Balancer ขั้นตอนทั้งหมดนี้จึงสั้นลง เพื่อให้เหลือเพียงการส่งคำขอใบรับรอง SSL/TLS ที่น่าเชื่อถือและการเลือกใบรับรอง ACM เพื่อจัดเตรียมให้กับโหลดบาลานเซอร์ เมื่อคุณสร้าง Network Load Balancer ขึ้นแล้ว คุณจะสามารถกำหนดค่า TLS Listener แล้วตามด้วยตัวเลือกเพื่อเลือกใบรับรองจาก ACM หรือ Identity Access Manager (IAM) ได้ ขั้นตอนนี้จะใกล้เคียงกับการใช้งาน Application Load Balancer หรือ Classic Load Balancer

ไม่ แบ็คเอนด์ที่ใช้ Network Load Balancer รองรับเฉพาะการเข้ารหัสเท่านั้น

Network Load Balancer รองรับเฉพาะใบรับรอง RSA ในขนาดคีย์ 2K เรายังไม่รองรับใบรับรอง RSA ในขนาดคีย์ที่ใหญ่กว่า 2K หรือใบรับรอง ECDSA บน Network Load Balancer

คุณสามารถใช้การยกเลิกการใช้ TLS บน Network Load Balancer ในภูมิภาค AWS สหรัฐอเมริกาฝั่งตะวันออก (เวอร์จิเนียเหนือ), สหรัฐอเมริกาฝั่งตะวันออก (โอไฮโอ), สหรัฐอเมริกาฝั่งตะวันตก (แคลิฟอร์เนียตอนเหนือ), สหรัฐอเมริกาฝั่งตะวันตก (ออริกอน), เอเชียแปซิฟิก (มุมไบ), เอเชียแปซิฟิก (โซล), เอเชียแปซิฟิก (สิงคโปร์), เอเชียแปซิฟิก (ซิดนีย์), เอเชียแปซิฟิก (โตเกียว), แคนาดา (ภาคกลาง), สหภาพยุโรป (แฟรงเฟิร์ต), สหภาพยุโรป (ไอร์แลนด์), สหภาพยุโรป (ลอนดอน), สหภาพยุโรป (ปารีส), อเมริกาใต้ (เซาเปาลู) และ GovCloud (สหรัฐอเมริกาฝั่งตะวันตก)

ระบบจะคิดค่าใช้จ่ายสำหรับแต่ละชั่วโมงหรือเศษของชั่วโมงที่รัน Network Load Balancer อยู่และจำนวนหน่วยปริมาณของ Load Balancer (LCU) ที่ Network Load Balancer ใช้ต่อชั่วโมง

LCU คือตัววัดใหม่สำหรับกำหนดวิธีที่คุณชำระเงินสำหรับ Network Load Balancer LCU จะกำหนดทรัพยากรสูงสุดที่ใช้ในแง่มุมใด ๆ (การเชื่อมต่อ/โฟลว์ใหม่ การเชื่อมต่อ/โฟลว์ที่ใช้งานอยู่ และแบนด์วิดท์) ที่ Network Load Balancer ประมวลผลปริมาณรับส่งข้อมูลของคุณ

ตัววัด LCU สำหรับการรับส่งข้อมูล TCP มีดังต่อไปนี้

• การเชื่อมต่อ TCP ใหม่ 800 ครั้งต่อวินาที
• การเชื่อมต่อ TCP ที่ใช้งานอยู่ 100,000 ครั้ง (สุ่มตัวอย่างต่อนาที)
• 1 GB ต่อชั่วโมงสำหรับอินสแตนซ์ Amazon EC2, คอนเทนเนอร์ และที่อยู่ IP ในฐานะเป้าหมาย

ตัววัด LCU สำหรับการรับส่งข้อมูล UDP มีดังต่อไปนี้

• โฟลว์ใหม่ 400 ครั้งต่อวินาที
• โฟลว์ UDP ที่ใช้งานอยู่ 50,000 ครั้ง (สุ่มตัวอย่างต่อนาที)
• 1 GB ต่อชั่วโมงสำหรับอินสแตนซ์ Amazon EC2, คอนเทนเนอร์ และที่อยู่ IP ในฐานะเป้าหมาย

ตัววัด LCU สำหรับการรับส่งข้อมูล TLS มีดังต่อไปนี้

• การเชื่อมต่อ TLS ใหม่ 50 ครั้งต่อวินาที
• การเชื่อมต่อ TLS ที่ใช้งานอยู่ 3,000 ครั้ง (สุ่มตัวอย่างต่อนาที)
• 1 GB ต่อชั่วโมงสำหรับอินสแตนซ์ Amazon EC2, คอนเทนเนอร์ และที่อยู่ IP ในฐานะเป้าหมาย

ไม่ ระบบจะเรียกเก็บค่าบริการคุณสำหรับแต่ละโปรโตคอลจากหนึ่งในสามมิติเท่านั้น (ค่าสูงสุดสำหรับชั่วโมง)

ไม่ สามารถส่งคำขอหลายรายการในการเชื่อมต่อครั้งเดียวกันได้

ไม่ ระบบจะยังคงเรียกเก็บค่าบริการสำหรับ Classic Load Balancer ตามการใช้แบนด์วิดท์และค่าบริการรายชั่วโมง

เราจะแสดงการใช้งานทั้งสามแง่มุมที่ประกอบรวมกันเป็น LCU ผ่าน Amazon CloudWatch

ไม่ จำนวน LCU ต่อชั่วโมงจะกำหนดตามทรัพยากรสูงสุดที่ใช้งานในแง่มุมทั้งสามซึ่งประกอบรวมกันเป็น LCU หนึ่งหน่วย

ใช่

ใช่ สำหรับบัญชี AWS ใหม่นั้น Free Tier สำหรับ Network Load Balancer จะมอบข้อเสนอการใช้งาน 750 ชั่วโมงและ 15 LCU ข้อเสนอ Free Tier นี้ใช้ได้กับลูกค้า AWS รายใหม่เท่านั้น และจะพร้อมใช้งานเป็นเวลา 12 เดือนหลังจากวันที่สมัครใช้งาน AWS

ใช่ คุณสามารถใช้ Application Load Balancer และ Network Load Balancer ได้อย่างละ 15 LCU และ Classic Load Balancer ได้ 15 GB ตามลำดับ ชั่วโมงโหลดบาลานเซอร์ 750 ชั่วโมงจะใช้ร่วมกันระหว่าง Application Load Balancer, Network Load Balancer และ Classic Load Balancer

คุณควรใช้ Gateway Load Balancer เมื่อติดตั้งใช้จริงอุปกรณ์เสมือนแบบอินไลน์ที่ไม่ได้กำหนดปลายทางการรับส่งข้อมูลบนเครือข่ายไว้สำหรับ Gateway Load Balancer เอง Gateway Load Balancer ส่งมอบการรับส่งข้อมูลทั้งหมด 3 ชั้นอย่างโปร่งใสผ่านอุปกรณ์เสมือนของบริษัทอื่น และมองไม่เห็นโดยต้นทางและปลายทางของการรับส่งข้อมูล สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับความแตกต่างของ Load Balancer เหล่านี้ โปรดดูที่หน้าการเปรียบเทียบคุณสมบัติ

Gateway Load Balancer ดำเนินงานภายในหนึ่ง AZ เท่านั้น

Gateway Load Balancer มีทั้งความสามารถโหลดบาลานซิงเลเยอร์ 3 และเลเยอร์ 4 เป็นอุปกรณ์ Bump-in-the-wire แบบโปร่งใสที่ไม่เปลี่ยนแปลงส่วนใดของแพ็กเก็ต ซึ่งได้รับการออกแบบสถาปัตยกรรมเพื่อรองรับคำขอนับล้านรายการ/วินาที รูปแบบการรับส่งข้อมูลที่ฉับไวและเปลี่ยนแปลงตลอดเวลา อีกทั้งยังมีเวลาแฝงที่ต่ำมาก ดูคุณสมบัติของ Gateway Load Balancer ได้ในตารางนี้ 

Gateway Load Balancer ไม่ดำเนินการยกเลิกการใช้งาน TLS และไม่รักษาไว้ซึ่งสถานะใด ๆ ของแอปพลิเคชัน ฟังก์ชันเหล่านี้จะดำเนินการโดยอุปกรณ์เสมือนของบริษัทอื่นที่มีการรับข้อมูลปริมาณการใช้งาน

Gateway Load Balancer ไม่รักษาไว้ซึ่งสถานะใด ๆ ของแอปพลิเคชัน แต่จะรักษาไว้ซึ่งการยึดตามโฟลว์อุปกรณ์เฉพาะโดยใช้ 5-tuple (สำหรับโฟลว์ TCP/UDP) หรือ 3-tuple (สำหรับโฟลว์ที่ไม่ใช่ TCP/UDP)

ตามค่าเริ่มต้น Gateway Load Balancer กำหนดโฟลว์เป็นการรวมกันของ 5 ทูเพิลที่ประกอบด้วย IP ต้นทาง, IP ปลายทาง, โปรโตคอล IP, พอร์ตต้นทาง และพอร์ตปลายทาง Gateway Load Balancer ใช้แฮช 5 ทูเพิลเพื่อตรวจสอบว่าทั้งสองทิศทางของโฟลว์ (นั่นคือ ต้นทางไปยังปลายทาง และปลายทางไปยังต้นทาง) จะถูกส่งต่อไปยังเป้าหมายเดียวกันอย่างสม่ำเสมอ ระบบจะถือว่าโฟลว์ใช้งานอยู่ตราบใดที่การรับส่งข้อมูลยังคงไหลเวียนและจนถึงการหมดเวลาที่ไม่ได้ใช้งาน เมื่อถึงเกณฑ์การหมดเวลาแล้ว Load Balancer จะลืมความเกี่ยวข้อง และจะพิจารณากลุ่มข้อมูลการรับส่งข้อมูลขาเข้าเป็นโฟลว์ใหม่และได้รับการปรับสมดุลโหลดกับเป้าหมายใหม่

Stickness แบบ 5 ทูเพิลตามค่าเริ่มต้น (IP ต้นทาง, IP ปลายทาง, โปรโตคอล IP, พอร์ตต้นทาง และพอร์ตปลายทาง) ให้การกระจายการรับส่งข้อมูลไปยังเป้าหมายที่เหมาะสมที่สุด และเหมาะสำหรับแอปพลิเคชันที่ใช้ TCP และ UDP ส่วนใหญ่ โดยมีข้อยกเว้นบางประการ Stickness แบบ 5 ทูเพิลตามค่าเริ่มต้นไม่เหมาะสำหรับแอปพลิเคชันที่ใช้ TCP หรือ UDP ที่ใช้สตรีมหรือหมายเลขพอร์ตแยกกันสำหรับการควบคุมและข้อมูล เช่น FTP, Microsoft RDP, Windows RPC และ SSL VPN โฟลว์การควบคุมและข้อมูลของแอปพลิเคชันดังกล่าวอาจถูกส่งไปยังอุปกรณ์เป้าหมายที่แตกต่างกันและอาจทำให้เกิดการจราจรหยุดชะงัก หากคุณต้องการรองรับโปรโตคอลดังกล่าว คุณควรเปิดใช้งาน GWLB Flow Stickiness โดยใช้ 3 ทูเพิล (IP ต้นทาง, IP ปลายทาง, โปรโตคอล IP) หรือ 2 ทูเพิล (IP ต้นทาง, IP ปลายทาง)

บางแอปพลิเคชันไม่ได้ใช้การขนส่ง TCP หรือ UDP เลย แต่ใช้โปรโตคอล IP เช่น SCTP และ GRE แทน หากใช้ Stickness แบบ 5 ทูเพิลซึ่งเป็นค่าเริ่มต้นของ GWLB โฟลว์การรับส่งข้อมูลจากโปรโตคอลเหล่านี้อาจส่งไปยังอุปกรณ์เป้าหมายที่แตกต่างกันและอาจทำให้เกิดการหยุดชะงักได้ หากคุณต้องการรองรับโปรโตคอลดังกล่าว คุณควรเปิดใช้งาน GWLB Flow Stickiness โดยใช้ 3 ทูเพิล (IP ต้นทาง, IP ปลายทาง, โปรโตคอล IP) หรือ 2 ทูเพิล (IP ต้นทาง, IP ปลายทาง)

โปรดดูเอกสาร Flow Stickiness สำหรับวิธีการเปลี่ยนประเภท Flow Stickiness

การหมดเวลาที่ไม่ได้ใช้งานของ Gateway Load Balancer สำหรับการเชื่อมต่อ TCP คือ 350 วินาที การหมดเวลาที่ไม่ได้ใช้งานสำหรับโฟลว์ที่ไม่ใช่ TCP คือ 120 วินาที การหมดเวลาเหล่านี้เป็นค่าคงที่และไม่สามารถเปลี่ยนแปลงได้

เนื่องจากเป็นอุปกรณ์แบบ Bump-in-the-Wire ทำให้ GWLB จึงไม่แยกส่วนหรือประกอบแพ็กเก็ตกลับคืน

GWLB ส่งต่อชิ้นส่วน UDP ไปยัง/จากอุปกรณ์เป้าหมาย อย่างไรก็ตาม GWLB จะทิ้งชิ้นส่วน TCP และ ICMP เนื่องจากไม่มีส่วนหัวของเลเยอร์ 4 อยู่ในชิ้นส่วนเหล่านี้

นอกจากนี้ หากอุปกรณ์เป้าหมายแปลงแพ็กเก็ตขาเข้าดั้งเดิมเป็นชิ้นส่วน และส่งชิ่นส่วนที่สร้างขึ้นใหม่กลับไปที่ GWLB ทาง GWLB จะทิ้งชิ้นส่วนที่สร้างขึ้นใหม่เหล่านี้เนื่องจากไม่มีส่วนหัวของเลเยอร์ 4 เพื่อป้องกันไม่ให้เกิดการแยกส่วนที่อุปกรณ์เป้าหมาย เราขอแนะนำให้เปิดใช้งาน Jumbo Frame บนอุปกรณ์เป้าหมายของคุณ หรือตั้งค่าอินเทอร์เฟซเครือข่ายของอุปกรณ์เป้าหมายให้ใช้ MTU ที่ต้องการสูงสุด ซึ่งจะทำให้มีลักษณะการส่งต่อที่โปร่งใสโดยการเก็บรักษาเนื้อหาแพ็กเก็ตดั้งเดิมไว้ตามที่เป็น 

เมื่ออินสแตนซ์เครื่องเสมือนหนึ่งตัวเกิดล้มเหลว Gateway Load Balancer จะนำอินสแตนซ์ดังกล่าวออกจากรายการการกำหนดเส้นทาง แล้วกำหนดเส้นทางการรับส่งข้อมูลใหม่ไปยังอินสแตนซ์อุปกรณ์ที่มีสภาพดี

หากอุปกรณ์เสมือนภายใน Availability Zone ล้มเหลว Gateway Load Balancer จะหยุดการรับส่งข้อมูลในเครือข่าย เราขอแนะนำให้ปรับใช้ Gateway Load Balancer ใน AZ หลายแห่งเพื่อให้มีความพร้อมใช้งานมากยิ่งขึ้น หากอุปกรณ์ทั้งหมดล้มเหลวใน AZ หนึ่งแห่ง จะสามารถใช้สคริปต์เพื่อเพิ่มอุปกรณ์ใหม่หรือกำหนดการรับส่งข้อมูลไปยัง Gateway Load Balancer ใน AZ อื่นได้

ได้ Gateway Load Balancer สามารถกำหนดไปยังอุปกรณ์เสมือนชุดเดียวกันได้หลายตัว

Gateway Load Balancer เป็นอุปกรณ์ bump-in-the-wire ที่โปร่งใสและจะรอรับการรับส่งข้อมูล IP ทุกประเภท (รวมถึง TCP, UDP, ICMP, GRE, ESP และอื่น ๆ) ดังนั้นเฉพาะกระบวนการรอรับ IP เท่านั้นที่จะถูกสร้างขึ้นบน Gateway Load Balancer

มี โปรดดูเอกสารข้อจำกัดของ Gateway Load Balancer สำหรับข้อมูลเพิ่มเติม

ได้ คุณสามารถใช้ AWS Management Console, AWS CLI หรือ API เพื่อตั้งค่า Gateway Load Balancer ได้

ได้ คุณสามารถสร้าง Gateway Load Balancer ใน Availability Zone เดียวได้โดยการระบุเครือข่ายย่อยเดียวเมื่อสร้างโหลดบาลานเซอร์ อย่างไรก็ตาม เราแนะนำให้ใช้ Availability Zone หลายแห่งเพื่อปรับปรุงความพร้อมใช้งาน คุณไม่สามารถเพิ่มหรือลบ Availability Zone สำหรับ Gateway Load Balancer หลังจากที่คุณสร้างได้

ตามค่าเริ่มต้น ระบบจะปิดใช้งานการปรับสมดุลโหลดข้ามโซน คุณสามารถเปิดใช้การปรับสมดุลโหลดข้ามโซนได้หลังจากสร้าง Gateway Load Balancer แล้วเท่านั้น คุณจะทำเช่นนี้ได้โดยการแก้ไขส่วนแอตทริบิวต์การปรับสมดุลโหลด แล้วเลือกช่องทำเครื่องหมายรองรับการปรับสมดุลโหลดข้ามโซน

ใช่ ระบบจะคิดค่าบริการคุณสำหรับการถ่ายโอนข้อมูลระหว่าง Availability Zone ต่างๆ ด้วย Gateway Load Balancer เมื่อเปิดใช้การปรับสมดุลโหลดข้ามโซน ตรวจสอบค่าบริการในส่วนการถ่ายโอนข้อมูลที่หน้าราคาแบบตามต้องการของ Amazon EC2

ใช่ ปัจจุบัน Gateway Load Balancer รองรับ 300 เป้าหมายต่อ Availability Zone เช่น หากคุณสร้าง Gateway Load Balancer ใน Availability Zone 3 โซน คุณก็จะมีเป้าหมายที่ลงทะเบียนได้สูงสุดถึง 900 เป้าหมาย หากเปิดใช้การปรับสมดุลโหลดข้ามโซน จำนวนเป้าหมายสูงสุดก็จะลดลงจาก 300 เป้าหมายต่อ Availability Zone เป็น 300 เป้าหมายต่อ Gateway Load Balancer

ระบบจะคิดค่าใช้จ่ายสำหรับแต่ละชั่วโมงหรือเศษของชั่วโมงที่รัน Gateway Load Balancer อยู่และจำนวนหน่วยความจุของ Load Balancer (LCU) ที่ Gateway Load Balancer ใช้ต่อชั่วโมง

LCU คือเมตริก Elastic Load Balancing สำหรับกำหนดวิธีชำระเงินสำหรับ Gateway Load Balancer LCU จะกำหนดทรัพยากรสูงสุดที่ใช้ในแง่มุมใดๆ (การเชื่อมต่อ/โฟลว์ใหม่ การเชื่อมต่อ/โฟลว์ที่ใช้งานอยู่ และแบนด์วิดท์) ที่ Gateway Load Balancer ประมวลผลปริมาณรับส่งข้อมูลของคุณ

ตัววัด LCU สำหรับการรับส่งข้อมูล TCP มีดังต่อไปนี้

• โฟลว์ (หรือการเชื่อมต่อ) ใหม่ 600 ครั้งต่อวินาที
• โฟลว์ (หรือการเชื่อมต่อ) ที่ใช้งานอยู่ 60,000 ครั้ง (สุ่มตัวอย่างต่อนาที)
• 1 GB ต่อชั่วโมงสำหรับ EC2 instance, คอนเทนเนอร์ และที่อยู่ IP ในฐานะเป้าหมาย

ไม่ ระบบจะเรียกเก็บค่าบริการคุณจากหนึ่งในสามมิติเท่านั้น (ค่าสูงสุดสำหรับชั่วโมง)

ไม่ สามารถส่งคำขอหลายรายการในการเชื่อมต่อครั้งเดียวกันได้

คุณสามารถติดตามการใช้งาน LCU ทั้งสามมิติได้ผ่าน Amazon CloudWatch

ใช่

เพื่อให้เกิดประโยชน์ อุปกรณ์เสมือนจำเป็นต้องมีเวลาแฝงเพิ่มเติมให้น้อยที่สุด และการไหลเข้าและออกของการรับส่งข้อมูลจากอุปกรณ์เสมือนจะต้องเป็นไปตามการเชื่อมต่อที่ปลอดภัย ตำแหน่งข้อมูลของ Gateway Load Balancer สร้างการเชื่อมต่อที่ปลอดภัยและมีเวลาแฝงต่ำซึ่งจำเป็นต่อการทำให้เป็นไปตามข้อกำหนดเหล่านี้

ด้วยการใช้ตำแหน่งข้อมูลของ Gateway Load Balancer ทำให้สามารถวางอุปกรณ์เสมือนไว้ในบัญชี AWS และ VPC ที่ต่างกันได้ ซึ่งช่วยรวมอุปกรณ์ไว้ที่ศูนย์กลางในตำแหน่งที่ตั้งเดียวกันเพื่อการจัดการที่ง่ายขึ้นและค่าใช้จ่ายในการปฏิบัติงานที่ลดลง

ตำแหน่งข้อมูลของ Gateway Load Balancer เป็นตำแหน่งข้อมูล VPC แบบใหม่ซึ่งใช้เทคโนโลยี PrivateLink ขณะที่การรับส่งข้อมูลในเครือข่ายเคลื่อนที่จากต้นทาง (อินเทอร์เน็ตเกตเวย์, VPC ฯลฯ) ไปยัง Gateway Load Balancer แล้วกลับมา ตำแหน่งข้อมูลของ Gateway Load Balancer จะช่วยรับรองการเชื่อมต่อที่เป็นส่วนตัวระหว่างสองฝั่ง การรับส่งข้อมูลทั้งหมดเคลื่อนที่บนเครือข่ายของ AWS และจะไม่มีการเปิดเผยข้อมูลออกสู่อินเทอร์เน็ต ซึ่งเพิ่มทั้งความปลอดภัยและประสิทธิภาพ

ตำแหน่งข้อมูล PrivateLink Interface จับคู่กับ Network Load Balancer (NLB) เพื่อกระจายการรับส่งข้อมูล TCP และ UDP ซึ่งกำหนดเป้าหมายไว้สำหรับเว็บแอปพลิเคชัน ในทางกลับกัน ตำแหน่งข้อมูล Gateway Load Balancer จะใช้กับ Gateway Load Balancer เพื่อเชื่อมต่อต้นทางและปลายทางในการรับส่งข้อมูล การรับส่งข้อมูลจะเคลื่อนที่จากตำแหน่งข้อมูล Gateway Load Balancer ไปยัง Gateway Load Balancer ผ่านอุปกรณ์เสมือน แล้วกลับไปยังปลายทางผ่านการเชื่อมต่อ PrivateLink ที่ปลอดภัย

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

Classic Load Balancer รองรับอินสแตนซ์ Amazon EC2 ที่ใช้ระบบปฏิบัติการใดๆ ซึ่งบริการ Amazon EC2 รองรับในปัจจุบัน

Classic Load Balancer รองรับการปรับสมดุลโหลดของแอปพลิเคชันที่ใช้โปรโตคอล HTTP, HTTPS (HTTP ที่ปลอดภัย), SSL (TCP ที่ปลอดภัย) และ TCP

คุณสามารถดำเนินการปรับสมดุลโหลดสำหรับพอร์ต TCP ต่อไปนี้ได้:

• [EC2-VPC] 1-65535
• [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535

ใช่ Classic Load Balancer แต่ละรายการจะมี IPv4, IPv6 และชื่อ DNS สแต็กคู่ (ทั้ง IPv4 และ IPv6) ที่เชื่อมโยงไว้ VPC ไม่รองรับ IPv6 คุณสามารถใช้ Application Load Balancer สำหรับการรองรับ IPv6 แบบเนทีฟใน VPC

ใช่

หากกำลังใช้ Amazon Virtual Private Cloud คุณสามารถกำหนดค่ากลุ่มความปลอดภัยสำหรับฟรอนต์เอนด์ของ Classic Load Balancer ได้

ใช่ คุณสามารถจับคู่ HTTP พอร์ต 80 และ HTTPS พอร์ต 443 กับ Classic Load Balancer รายการเดียวได้

Classic Load Balancer ไม่ได้จำกัดจำนวนการเชื่อมต่อสูงสุดที่ดำเนินการได้เพื่อเชื่อมต่อกับอินสแตนซ์ Amazon EC2 ที่ปรับสมดุลโหลดแล้วของคุณ คุณสามารถคาดการณ์จำนวนนี้เพื่อปรับขนาดตามจำนวนคำขอ HTTP, HTTPS หรือ SSL ที่เกิดขึ้นพร้อมกัน หรือจำนวนการเชื่อมต่อ TCP ที่เกิดขึ้นพร้อมกันซึ่ง Classic load balancer ได้รับมา

คุณสามารถปรับสมดุลโหลดอินสแตนซ์ Amazon EC2 ที่เปิดใช้ด้วย AMI แบบเสียค่าใช้จ่ายได้จาก AWS Marketplace อย่างไรก็ตาม Classic Load Balancer ไม่รองรับอินสแตนซ์ที่เปิดใช้ด้วย AMI แบบเสียค่าใช้จ่ายจากเว็บไซต์ Amazon DevPay

ใช่ โปรดดูที่หน้าเว็บ Elastic Load Balancing

ใช่ หากต้องการรับประวัติการเรียกใช้ Classic Load Balancer API ที่ดำเนินการบนบัญชี เพียงแค่เปิดใช้ CloudTrail ใน AWS Management Console

ใช่ คุณสามารถยกเลิกใช้ SSL ใน Classic Load Balancer ได้ คุณจะต้องติดตั้งใบรับรอง SSL ในโหลดบาลานเซอร์แต่ละรายการ โหลดบาลานเซอร์จะใช้ใบรับรองนี้เพื่อยกเลิกใช้งานการเชื่อมต่อดังกล่าว และจากนั้นก็จะถอดรหัสคำขอจากไคลเอ็นต์ก่อนที่จะส่งไปยังอินสแตนซ์แบ็คเอนด์

คุณสามารถเลือกใช้ AWS Certificate Manager เพื่อจัดเตรียมใบรับรอง SSL/TLS หรือจะรับใบรับรองจากแหล่งที่มาอื่น ๆ ได้โดยการสร้างคำขอใบรับรอง รับคำขอใบรับรองที่ CA ลงชื่อแล้ว และจากนั้นจึงอัปโหลดใบรับรองดังกล่าวโดยใช้บริการ AWS Identity and Access Management (IAM)

Classic Load Balancer ผสานรวมกับ AWS Certificate Manager (ACM) แล้วในตอนนี้ การผสานรวมกับ ACM จะช่วยให้การผูกใบรับรองกับโหลดบาลานเซอร์แต่ละรายการเป็นเรื่องง่าย ซึ่งทำให้ขั้นตอนการลดภาระการประมวลผล SSL ทั้งหมดมีความง่ายดาย โดยปกติแล้ว การซื้อ การอัปโหลด และการต่ออายุใบรับรอง SSL/TLS เป็นขั้นตอนที่ต้องทำด้วยตนเองซึ่งใช้เวลานาน และเป็นกระบวนการที่ซับซ้อน แต่ด้วยการผสานรวม ACM กับ Classic Load Balancer ขั้นตอนทั้งหมดนี้จึงสั้นลง เพื่อให้การส่งคำขอใบรับรอง SSL/TLS ที่น่าเชื่อถือและการเลือกใบรับรอง ACM เพื่อจัดเตรียมให้มีโหลดบาลานเซอร์แต่ละรายการเป็นเรื่องง่าย

คุณสามารถเปิดใช้การปรับสมดุลโหลดข้ามโซนได้โดยใช้ Console, AWS CLI หรือ AWS SDK ดูเอกสารประกอบเกี่ยวกับ Cross-Zone Load Balancing (การปรับสมดุลโหลดข้ามโซน) สำหรับรายละเอียดเพิ่มเติม

ไม่ ระบบจะไม่คิดค่าบริการคุณสำหรับการถ่ายโอนข้อมูลระดับภูมิภาคระหว่าง Availability Zone ต่างๆ เมื่อเปิดใช้การปรับสมดุลการโหลดข้ามโซนสำหรับ Classic Load Balancer ของคุณ