ข้อมูลทั่วไป

ถาม: ฉันจะตัดสินใจเลือกโหลดบาลานเซอร์สำหรับแอปพลิเคชันของฉันได้อย่างไร

ตอบ: Elastic Load Balancing (ELB) รองรับโหลดบาลานเซอร์สี่ประเภท คุณสามารถเลือกโหลดบาลานเซอร์ที่เหมาะสมได้ตามความต้องการของแอปพลิเคชัน หากคุณต้องการปรับสมดุลโหลดคำขอ HTTP เราขอแนะนำให้คุณใช้ Application Load Balancer (ALB) เราขอแนะนำให้ใช้ Network Load Balancer สำหรับการปรับสมดุลโหลดโปรโตคอลเครือข่าย/การขนส่ง (เลเยอร์ 4 - TCP, UDP) และสำหรับแอปพลิเคชันที่มีสมรรถนะสูง/เวลาแฝงต่ำ หากแอปพลิเคชันของคุณสร้างภายในเครือข่าย Amazon Elastic Compute Cloud (Amazon EC2) Classic คุณควรใช้ Classic Load Balancer หากคุณต้องการปรับใช้และเรียกใช้อุปกรณ์เสมือนของบริษัทอื่น คุณสามารถใช้ Gateway Load Balancer ได้

ถาม: ฉันสามารถเข้าถึง Elastic Load Balancing API แบบส่วนตัวจาก Amazon Virtual Private Cloud (VPC) โดยไม่ต้องใช้ IP สาธารณะได้หรือไม่

ตอบ: ได้ คุณสามารถเข้าถึง Elastic Load Balancing API แบบส่วนตัวจาก Amazon Virtual Private Cloud (VPC) ได้โดยการสร้างตำแหน่งข้อมูล VPC ด้วยตำแหน่งข้อมูล VPC เส้นทางระหว่าง VPC กับ Elastic Load Balancing API จะได้รับการจัดการโดยเครือข่าย AWS โดยไม่ต้องใช้อินเทอร์เน็ตเกตเวย์, เกตเวย์ Network Address Translation (NAT) หรือการเชื่อมต่อ Virtual Private Network (VPN) ตำแหน่งข้อมูล VPC รุ่นล่าสุดที่ Elastic Load Balancing ใช้นั้นให้บริการโดย AWS PrivateLink ซึ่งเป็นเทคโนโลยีของ AWS ที่เปิดใช้การเชื่อมต่อแบบส่วนตัวระหว่างบริการของ AWS โดยใช้ Elastic Network Interface (ENI) ที่มี IP ส่วนตัวใน VPC ของคุณ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ AWS PrivateLink โปรดไปที่เอกสารประกอบของ AWS PrivateLink

ถาม: มี SLA สำหรับโหลดบาลานเซอร์หรือไม่

ตอบ: มี Elastic Load Balancing รับประกันความพร้อมใช้งานรายเดือนอย่างน้อย 99.99% สำหรับโหลดบาลานเซอร์ของคุณ (Classic, Application หรือ Network) หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ SLA และอยากทราบว่าคุณมีสิทธิ์รับเครดิตหรือไม่ โปรดไปที่นี่

Application Load Balancer

ถาม: ระบบปฏิบัติการใดที่ Application Load Balancer รองรับ

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

ถาม: โปรโตคอลใดที่ Application Load Balancer รองรับ

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

ถาม: Application Load Balancer รองรับ HTTP/2 หรือไม่

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

ถาม: ฉันจะใช้ IP แบบคงที่หรือ PrivateLink บน Application Load Balancer ได้อย่างไร

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

ถาม: พอร์ต TCP ใดที่ฉันสามารถใช้เพื่อปรับสมดุลโหลดได้

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

ถาม: Application Load Balancer รองรับ WebSockets หรือไม่

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

ถาม: Application Load Balancer รองรับการสืบย้อนคำขอหรือไม่

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

ถาม: Classic Load Balancer มีคุณสมบัติและสิทธิประโยชน์แบบเดียวกับ Application Load Balancer หรือไม่

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

ถาม: ฉันสามารถกำหนดค่าอินสแตนซ์ Amazon EC2 ให้ยอมรับปริมาณการรับส่งข้อมูลเฉพาะจาก Application Load Balancer ของฉันได้หรือไม่

ตอบ: ได้

ถาม: ฉันสามารถกำหนดค่ากลุ่มความปลอดภัยสำหรับฟรอนต์เอนด์ของ Application Load Balancer ได้หรือไม่

ตอบ: ได้

ถาม: ฉันสามารถนำ API ที่มีอยู่แล้วซึ่งใช้กับ Classic Load Balancer มาใช้ร่วมกับ Application Load Balancer ได้หรือไม่

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

ถาม: ฉันจะจัดการทั้ง Application Load Balancer และ Classic Load Balancer ไปพร้อมๆ กันได้อย่างไร

ตอบ: 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 (หรือในทางกลับกัน) ได้หรือไม่

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

ถาม: ฉันสามารถย้ายข้อมูลจาก Classic Load Balancer ไปยัง Application Load Balancer ได้หรือไม่

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

ถาม: ฉันสามารถใช้ Application Load Balancer เป็นโหลดบาลานเซอร์เลเยอร์ 4 ได้หรือไม่

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

ถาม: ฉันสามารถใช้ Application Load Balancer ตัวเดียวเพื่อจัดการคำขอ HTTP และ HTTPS ได้หรือไม่

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

ถาม: ฉันสามารถขอรับประวัติการเรียกใช้ Application Load Balancing API บนบัญชีของฉันเพื่อการวิเคราะห์ความปลอดภัยและแก้ปัญหาการดำเนินการได้หรือไม่

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

ถาม: Application Load Balancer รองรับการยกเลิกใช้งาน HTTPS หรือไม่

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

ถาม: ขั้นตอนในการได้รับใบรับรอง SSL มีอะไรบ้าง

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

ถาม: Application Load Balancer จะผสานรวมกับ AWS Certificate Manager (ACM) ได้อย่างไร

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

ถาม: Application Load Balancer รองรับการตรวจสอบสิทธิ์ของเซิร์ฟเวอร์แบ็คเอนด์หรือไม่

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

ถาม: ฉันจะเปิดใช้ Server Name Indication (SNI) สำหรับ Application Load Balancer ได้อย่างไร

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

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

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

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

ถาม: Application Load Balancer รองรับ IPv6 หรือไม่

ตอบ: รองรับ โดย Application Load Balancer จะรองรับ IPv6

ถาม: คุณจะตั้งค่ากฎใน Application Load Balancer ได้อย่างไร

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

ถาม: Application Load Balancer มีข้อจำกัดเกี่ยวกับทรัพยากรหรือไม่

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

ถาม: ฉันจะปกป้องเว็บแอปพลิเคชันเบื้องหลังโหลดบาลานเซอร์จากการโจมตีเว็บได้อย่างไร

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

ถาม: ฉันสามารถปรับสมดุลโหลดที่อยู่ IP ใดๆ ตามที่เห็นสมควรได้หรือไม่

ตอบ: คุณสามารถใช้ที่อยู่ 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)

ถาม: ฉันจะปรับสมดุลโหลดแอปพลิเคชันที่กระจายทั่ว VPC และสถานที่ตั้งภายในองค์กรได้อย่างไร

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

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

ถาม: ฉันจะปรับสมดุลโหลดไปยังอินสแตนซ์ EC2 Classic ได้อย่างไร

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

ถาม: ฉันจะเปิดใช้การปรับสมดุลโหลดข้ามโซนใน Application Load Balancer ได้อย่างไร

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

ถาม: เมื่อใดที่ฉันควรตรวจสอบสิทธิ์ผู้ใช้โดยใช้การผสานรวม Application Load Balancer กับ Amazon Cognito เทียบกับการรองรับแบบเนทีฟของ Application Load Balancer สำหรับผู้ให้บริการข้อมูลประจำตัว (IdP) OpenID Connect (IODC)

ตอบ: คุณควรใช้การตรวจสอบสิทธิ์ผ่าน 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

ถาม: 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

ถาม: ALB รองรับเนื้อหาข้อความใดบ้างสำหรับการดำเนินการที่มีการตอบสนองแบบตายตัว

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

ถาม: การเรียก AWS Lambda ผ่าน Application Load Balancer ทำงานอย่างไร

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

ถาม: การเรียก Lambda ผ่าน Application Load Balancer รองรับคำขอจากโปรโตคอลทั้ง HTTP และ HTTPS หรือไม่

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

ถาม: ฉันสามารถใช้ฟังก์ชัน Lambda เป็นเป้าหมายด้วย Application Load Balancer ในรีเจี้ยน AWS ใดได้บ้าง

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

ถาม: Application Load Balancer ให้บริการใน AWS Local Zones หรือไม่

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

คำถามที่พบบ่อยเกี่ยวกับราคา Application Load Balancer

ถาม: Application Load Balancer มีวิธีการกำหนดราคาอย่างไร

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

ถาม: หน่วยความจุของโหลดบาลานเซอร์ (LCU) คืออะไร

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

ถาม: ระบบจะเรียกเก็บค่าบริการฉันสำหรับ Classic Load Balancer ตาม LCU หรือไม่

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

ถาม: ฉันจะทราบได้อย่างไรว่า Application Load Balancer ใช้งาน LCU จำนวนกี่หน่วย

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

ถาม: ระบบจะเรียกเก็บค่าบริการฉันสำหรับ LCU ในทุกแง่มุมหรือไม่

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

ถาม: ระบบจะเรียกเก็บค่าบริการฉันสำหรับ LCU ที่ไม่ครบหน่วยหรือไม่

ตอบ: ใช่

ถาม: Application Load Balancer มีข้อเสนอ Free Tier สำหรับบัญชี AWS ใหม่หรือไม่

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

ถาม: ฉันสามารถใช้ Application Load Balancer และ Classic Load Balancer รวมกันเพื่อเป็นส่วนหนึ่งของ Free Tier ได้หรือไม่

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

ถาม: ค่าประเมินตามกฎคืออะไร

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

ถาม: การเรียกเก็บค่าบริการสำหรับ LCU มีวิธีคำนวณอย่างไรสำหรับประเภทใบรับรองและขนาดคีย์ที่แตกต่างกัน

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

 

ใบรับรอง RSA        
ขนาดคีย์ <=2K  <=4K  <=8K  >8K 
การเชื่อมต่อใหม่/วินาที 25 5 1 0.25
ใบรับรอง ECDSA        
ขนาดคีย์ <=256 <=384 <=521 >521 
การเชื่อมต่อใหม่/วินาที 25 5 1 0.25

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

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

ถาม: ระบบจะคิดค่าบริการแยกต่างหากสำหรับการตรวจสอบสิทธิ์ผู้ใช้ใน Application Load Balancer หรือไม่

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

ถาม: คุณจะคิดค่าใช้จ่ายสำหรับการใช้งาน Application Load Balancer ที่มีเป้าหมาย AWS Lambda อย่างไร

ตอบ: ระบบจะคิดค่าใช้จ่ายคุณตามปกติสำหรับแต่ละชั่วโมงหรือเศษของชั่วโมงที่รัน 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

ถาม: ฉันจะแยกความแตกต่างของไบต์ที่ได้รับการประมวลผลด้วยเป้าหมาย Lambda เทียบกับไบต์ที่ได้รับการประมวลผลด้วยเป้าหมายอื่นๆ (Amazon EC2, คอนเทนเนอร์ และเซิร์ฟเวอร์ในองค์กร) ได้อย่างไร

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

Network Load Balancer

ถาม: ฉันสามารถสร้าง TCP หรือ UDP listener (เลเยอร์ 4) สำหรับ Network Load Balancer ได้หรือไม่

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

ถาม: คุณสมบัติหลักที่พร้อมใช้งานใน Network Load Balancer มีอะไรบ้าง

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

ถาม: Network Load Balancer สามารถประมวลผลการรับส่งข้อมูลโปรโตคอล TCP และ UDP ในพอร์ตเดียวกันได้หรือไม่

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

ถาม: Network Load Balancer ทำงานเป็นอย่างไรเมื่อเทียบกับสิ่งที่ฉันได้รับจากกระบวนการรอรับ TCP ใน Classic Load Balancer

ตอบ: 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 ได้หรือไม่

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

ถาม: Network Load Balancer มีข้อจำกัดเกี่ยวกับทรัพยากรหรือไม่

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

ถาม: ฉันสามารถใช้ AWS Management Console เพื่อตั้งค่า Network Load Balancer ได้หรือไม่

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

ถาม: ฉันสามารถใช้ API ที่มีอยู่แล้วของ Classic Load Balancer กับ Network Load Balancer ได้หรือไม่

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

ถาม: ฉันสามารถสร้าง Network Load Balancer ใน Availability Zone เดียวได้หรือไม่

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

ถาม: Network Load Balancer รองรับการเปลี่ยนระบบระดับรีเจี้ยนและโซนของ DNS หรือไม่

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

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

ถาม: ฉันสามารถใช้ Network Load Balancer ร่วมกับ IP จาก ELB และ Elastic IP หรือ IP ส่วนตัวที่กำหนดให้ได้หรือไม่

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

ถาม: ฉันสามารถกำหนด EIP มากกว่าหนึ่งรายการให้กับ Network Load Balancer ในแต่ละเครือข่ายย่อยได้หรือไม่

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

ถาม: หากฉันนำ/ลบ Network Load Balancer ออก จะเกิดอะไรขึ้นกับที่อยู่ Elastic IP ที่เชื่อมโยงอยู่

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

ถาม: Network Load Balancer รองรับโหลดบาลานเซอร์ภายในหรือไม่

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

ถาม: Network Load Balancer ภายในสามารถรองรับที่อยู่ IP ส่วนตัวในแต่ละเครือข่ายย่อยมากกว่าหนึ่งรายการได้หรือไม่

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

ถาม: ฉันสามารถตั้งค่า Websocket ด้วย Network Load Balancer ได้หรือไม่

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

ถาม: ฉันสามารถปรับสมดุลโหลดที่อยู่ IP ใดๆ ตามที่เห็นสมควรได้หรือไม่

ตอบ: ใช่ ตอบ: คุณสามารถใช้ที่อยู่ 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 เพื่อตั้งค่า AWS PrivateLink ได้หรือไม่

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

ถาม: โฟลว์ UDP คืออะไร

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

ถาม: Network Load Balancer รองรับการหมดเวลาที่ไม่ได้ใช้งานใดบ้าง

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

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

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

ถาม: ฉันจะปรับสมดุลโหลดแอปพลิเคชันที่กระจายทั่ว VPC และสถานที่ตั้งภายในองค์กรได้อย่างไร

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

ถาม: ฉันจะปรับสมดุลโหลดไปยังอินสแตนซ์ EC2 Classic ได้อย่างไร

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

ถาม: ฉันจะเปิดใช้การปรับสมดุลโหลดข้ามโซนใน Network Load Balancer ได้อย่างไร

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

ถาม: ระบบจะคิดค่าบริการฉันเมื่อเปิดใช้การถ่ายโอนข้อมูล AWS ระดับรีเจี้ยนสำหรับการปรับสมดุลโหลดข้ามโซนใน Network Load Balancer หรือไม่

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

ถาม: การปรับสมดุลโหลดข้ามโซนจะส่งผลกระทบต่อข้อจำกัดของ Network Load Balancer หรือไม่

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

ถาม: Network Load Balancer รองรับการยกเลิกใช้งาน TLS หรือไม่

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

ถาม: จะมีการรักษา IP ต้นทางเมื่อยกเลิกใช้งาน TLS บน Network Load Balancer หรือไม่

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

ถาม: ขั้นตอนในการได้รับใบรับรอง SSL มีอะไรบ้าง

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

ถาม: ฉันจะเปิดใช้ Server Name Indication (SNI) สำหรับ Network Load Balancer ได้อย่างไร

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

ถาม: Network Load Balancer ผสานรวมกับ AWS Certificate Manager (ACM) หรือ Identity Access Manager (IAM) ได้อย่างไร

ตอบ: 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 รองรับเฉพาะการเข้ารหัสเท่านั้น

ถาม: Network Load Balancer รองรับใบรับรองประเภทใดบ้าง

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

ถาม: การยกเลิกใช้งาน TLS บน Network Load Balancer ได้รับการรองรับในภูมิภาค AWS ใดบ้าง

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

คำถามที่พบบ่อยเกี่ยวกับราคา Network Load Balancer

ถาม: Network Load Balancer มีวิธีการกำหนดราคาอย่างไร

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

ถาม: หน่วยความจุของโหลดบาลานเซอร์ (LCU) คืออะไร

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

ถาม: ตัววัด LCU สำหรับการรับส่งข้อมูล TCP บน Network Load Balancer คืออะไร

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

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

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

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

ถาม: ตัววัด LCU สำหรับการรับส่งข้อมูล TLS บน Network Load Balancer คืออะไร

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

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

ถาม: การเชื่อมต่อ/โฟลว์ใหม่ต่อวินาทีจะเหมือนกับคำขอ/วินาทีหรือไม่

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

ถาม: ระบบจะเรียกเก็บค่าบริการฉันสำหรับ Classic Load Balancer ตาม LCU หรือไม่

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

ถาม: ฉันจะทราบได้อย่างไรว่า Network Load Balancer ใช้งาน LCU จำนวนกี่หน่วย

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

ถาม: ระบบจะเรียกเก็บค่าบริการฉันสำหรับ LCU ในทุกแง่มุมหรือไม่

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

ถาม: ระบบจะเรียกเก็บค่าบริการฉันสำหรับ LCU ที่ไม่ครบหน่วยหรือไม่

ตอบ: ใช่

ถาม: Network Load Balancer มีข้อเสนอ Free Tier สำหรับบัญชี AWS ใหม่หรือไม่

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

ถาม: ฉันสามารถใช้ Network Load Balancer, Application Load Balancer และ Classic Load Balancer รวมกันเพื่อเป็นส่วนหนึ่งของ Free Tier ได้หรือไม่

ตอบ: ใช่ คุณสามารถใช้ 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 เมื่อใดเมื่อเปรียบเทียบกับ Network Load Balancer หรือ Application Load Balancer

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

ถาม: การปรับใช้ Gateway Load Balancer จะปรับใช้ต่อ Region หรือต่อ Availability Zone (AZ)

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

ถาม: คุณสมบัติหลักที่พร้อมใช้งานใน Gateway Load Balancer มีอะไรบ้าง

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

ถาม: Gateway Load Balancer ดำเนินการยกเลิกการใช้งาน TLS หรือไม่

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

ถาม: Gateway Load Balancer รักษาไว้ซึ่งสถานะใดๆ ของแอปพลิเคชันหรือไม่

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

ถาม: Gateway Load Balancer กำหนดโฟลว์ไว้อย่างไร

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

ถาม: เมื่อใดที่ฉันควรใช้ Stickness แบบ 5 ทูเพิล, 3 ทูเพิล และ 2 ทูเพิลบน Gateway 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

ถาม เกตเวย์ Load Balancer รองรับการหมดเวลาที่ไม่ได้ใช้งานนานเท่าใด

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

ถาม: อุปกรณ์สามารถแยกแพ็กเก็ตออกเป็นส่วนๆ ได้หรือไม่

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

ถาม: Gateway Load Balancer จัดการกับความล้มเหลวของอินสแตนซ์อุปกรณ์เสมือนหนึ่งตัวใน Availability Zone หนึ่งแห่งอย่างไร

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

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

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

ถาม: ฉันสามารถกำหนดค่าอุปกรณ์เป็นเป้าหมายสำหรับ Gateway Load Balancer มากกว่าหนึ่งตัวได้หรือไม่

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

ถาม: ฉันสามารถสร้างกระบวนการรอรับประเภทใดได้สำหรับ Gateway Load Balancer

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

ถาม: Gateway Load Balancer มีข้อจำกัดเกี่ยวกับทรัพยากรหรือไม่

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

ถาม: ฉันสามารถใช้ AWS Management Console เพื่อตั้งค่า Gateway Load Balancer ได้หรือไม่

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

ถาม: ฉันสามารถสร้าง Gateway Load Balancer ใน Availability Zone เดียวได้หรือไม่

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

ถาม: ฉันจะเปิดใช้การปรับสมดุลโหลดข้ามโซนใน Gateway Load Balancer ได้อย่างไร

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

ถาม: ระบบจะคิดค่าบริการฉันเมื่อเปิดใช้การถ่ายโอนข้อมูล AWS สำหรับการปรับสมดุลโหลดข้ามโซนใน Gateway Load Balancer หรือไม่

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

ถาม: การปรับสมดุลโหลดข้ามโซนจะส่งผลกระทบต่อขีดจำกัดของ Gateway Load Balancer หรือไม่

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

คำถามที่พบบ่อยเกี่ยวกับราคา Gateway Load Balancer

ถาม: Gateway Load Balancer มีวิธีการกำหนดราคาอย่างไร

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

ถาม: หน่วยความจุของโหลดบาลานเซอร์ (LCU) คืออะไร

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

ถาม: ตัววัด LCU สำหรับการรับส่งข้อมูล Gateway Load Balancer คืออะไร

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

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

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

ถาม: โฟลว์ (หรือการเชื่อมต่อ) ใหม่ต่อวินาทีจะเหมือนกับคำขอ/วินาทีหรือไม่
 
ตอบ: ไม่ สามารถส่งหลายคำขอในการเชื่อมต่อครั้งเดียวได้
 
ถาม: ฉันจะทราบได้อย่างไรว่า Gateway Load Balancer ใช้งาน LCU จำนวนกี่หน่วย
 
ตอบ: คุณสามารถติดตามการใช้งาน LCU ทั้งสามมิติได้ผ่าน Amazon CloudWatch
 
ถาม: ระบบจะเรียกเก็บค่าบริการฉันสำหรับ LCU ที่ไม่ครบหน่วยหรือไม่
 
ตอบ: ใช่

ตำแหน่งข้อมูลของ Gateway Load Balancer

ถาม: เหตุใดฉันจึงต้องใช้ตำแหน่งข้อมูลของ Gateway Load Balancer

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

ถาม: ตำแหน่งข้อมูลของ Gateway Load Balancer มีส่วนช่วยในการรวมศูนย์กลางอย่างไร

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

ถาม: ตำแหน่งข้อมูลของ Gateway Load Balancer ทำงานอย่างไร

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

ถาม: ตำแหน่งข้อมูล PrivateLink Interface แตกต่างจากตำแหน่งข้อมูล Gateway Load Balancer อย่างไร

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

ถาม: ฉันสามารถเชื่อมต่อตำแหน่งข้อมูลของ Gateway Load Balancer ได้กี่รายการกับ Gateway Load Balancer หนึ่งรายการ

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

Classic Load Balancer

ถาม: ระบบปฏิบัติการใดที่ Classic Load Balancer รองรับ

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

ถาม: โปรโตคอลใดที่ Classic Load Balancer รองรับ

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

ถาม: พอร์ต TCP ใดที่ฉันสามารถปรับสมดุลโหลดได้

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

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

ถาม: Classic Load Balancer รองรับการรับส่งข้อมูล IPv6 หรือไม่

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

ถาม: ฉันสามารถกำหนดค่าอินสแตนซ์ Amazon EC2 ให้ยอมรับเฉพาะปริมาณการรับส่งข้อมูลจาก Classic Load Balancer ได้หรือไม่

ตอบ: ใช่

ถาม: ฉันสามารถกำหนดค่ากลุ่มความปลอดภัยสำหรับฟรอนต์เอนด์ของ Classic Load Balancer ได้หรือไม่

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

ถาม: ฉันสามารถใช้ Classic Load Balancer เดียวสำหรับจัดการคำขอ HTTP และ HTTPS ได้หรือไม่

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

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

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

ถาม: ฉันสามารถปรับสมดุลโหลดอินสแตนซ์ Amazon EC2 ที่เปิดใช้ด้วย AMI แบบเสียค่าใช้จ่ายได้หรือไม่

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

ถาม: ฉันสามารถใช้ Classic Load Balancer ใน Amazon Virtual Private Cloud ได้หรือไม่

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

ถาม: ฉันสามารถขอรับประวัติการเรียกใช้ Classic Load Balancer API ในบัญชีของฉันเพื่อวิเคราะห์ความปลอดภัยและแก้ปัญหาการดำเนินการได้หรือไม่

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

ถาม: Classic Load Balancer รองรับการยกเลิกใช้งาน SSL หรือไม่

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

ถาม: ขั้นตอนในการได้รับใบรับรอง SSL มีอะไรบ้าง

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

ถาม: Classic Load Balancer จะผสานรวมกับ AWS Certificate Manager (ACM) ได้อย่างไร

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

ถาม: ฉันจะเปิดใช้การปรับสมดุลโหลดข้ามโซนใน Classic Load Balancer ได้อย่างไร

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

ถาม: ระบบจะคิดค่าบริการฉันเมื่อเปิดใช้การถ่ายโอนข้อมูล AWS ระดับภูมิภาคสำหรับการปรับสมดุลโหลดข้ามโซนใน Classic Load Balancer หรือไม่

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

เรียนรู้เพิ่มเติมเกี่ยวกับราคา Elastic Load Balancing

ไปที่หน้าราคา

เรียนรู้เพิ่มเติม 
ลงชื่อสมัครใช้บัญชีฟรี

รับสิทธิ์การเข้าถึง AWS Free Tier ได้ทันที 

ลงชื่อสมัครใช้งาน 
เริ่มต้นสร้างใน Console

เริ่มใช้งาน Elastic Load Balancing ใน AWS Console

ลงชื่อเข้าใช้