ทำไมเราถึงต้องการซับเน็ตส่วนตัวใน VPC

มี4 สถานการณ์ในการกำหนดค่า AWS VPC แต่ลองดูสองสิ่งนี้:

• สถานการณ์สมมติ 1: 1 ซับเน็ตสาธารณะ
• สถานการณ์จำลอง 2: 1 ซับเน็ตสาธารณะและ 1 ซับเน็ตส่วนตัว

เนื่องจากอินสแตนซ์ใด ๆ ที่เปิดตัวในเครือข่ายย่อยสาธารณะไม่มี EIP (เว้นแต่จะได้รับมอบหมาย) จึงไม่สามารถระบุแอดเดรสได้จากอินเทอร์เน็ต แล้ว:

• เหตุใดจึงจำเป็นต้องมีซับเน็ตส่วนตัว
• อะไรคือความแตกต่างระหว่างเครือข่ายย่อยส่วนตัวและเครือข่ายสาธารณะ

ปรับปรุง:ในช่วงปลายเดือนธันวาคม 2015, AWS ประกาศคุณลักษณะใหม่ที่มีการจัดการ NAT เกตเวย์สำหรับ VPC บริการเสริมนี้มีกลไกทางเลือกสำหรับอินสแตนซ์ VPC ในซับเน็ตส่วนตัวในการเข้าถึงอินเทอร์เน็ตซึ่งก่อนหน้านี้โซลูชันทั่วไปคืออินสแตนซ์ EC2 บนเครือข่ายย่อยสาธารณะภายใน VPC ซึ่งทำงานเป็น "อินสแตนซ์ NAT" ซึ่งให้การแปลที่อยู่เครือข่าย ( ในทางเทคนิคคือการแปลที่อยู่พอร์ต ) สำหรับอินสแตนซ์ในเครือข่ายย่อยส่วนตัวอื่น ๆ ซึ่งอนุญาตให้เครื่องเหล่านั้นใช้ที่อยู่ IP สาธารณะของอินสแตนซ์ NAT สำหรับการเข้าถึงอินเทอร์เน็ตขาออก

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

โปรดทราบว่าInternet GatewayและNAT Gatewayเป็นคุณลักษณะที่แตกต่างกันสองประการ การกำหนดค่า VPC ทั้งหมดที่มีการเข้าถึงอินเทอร์เน็ตจะมีวัตถุเสมือนของเกตเวย์อินเทอร์เน็ต

เพื่อให้เข้าใจถึงความแตกต่างระหว่างเครือข่ายย่อย "ส่วนตัว" และ "สาธารณะ" ใน Amazon VPC ต้องมีความเข้าใจว่าการกำหนดเส้นทาง IP และการแปลที่อยู่เครือข่าย (NAT) โดยทั่วไปทำงานอย่างไรและวิธีการนำไปใช้โดยเฉพาะใน VPC

ความแตกต่างหลักระหว่างซับเน็ตสาธารณะและส่วนตัวใน VPC ถูกกำหนดโดยเส้นทางเริ่มต้นของซับเน็ตนั้นคืออะไรในตารางการกำหนดเส้นทาง VPC

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

แต่ละเครือข่ายย่อยมีเส้นทางเริ่มต้นเพียงเส้นทางเดียวซึ่งอาจเป็นได้เพียงหนึ่งในสองสิ่ง:

• อ็อบเจ็กต์ "Internet Gateway" ของ VPC ในกรณีของซับเน็ต "สาธารณะ" หรือ
• อุปกรณ์ NAT นั่นคือเกตเวย์ NAT หรืออินสแตนซ์ EC2 ที่ทำหน้าที่ "อินสแตนซ์ NAT" ในกรณีของซับเน็ต "ส่วนตัว"

อินเทอร์เน็ตเกตเวย์ไม่ทำการแปลที่อยู่เครือข่ายสำหรับอินสแตนซ์ที่ไม่มีที่อยู่ IP สาธารณะดังนั้นอินสแตนซ์ที่ไม่มีที่อยู่ IP สาธารณะจึงไม่สามารถเชื่อมต่อกับอินเทอร์เน็ตภายนอกได้ - เพื่อทำสิ่งต่างๆเช่นดาวน์โหลดการอัปเดตซอฟต์แวร์หรือเข้าถึงทรัพยากร AWS อื่น ๆ เช่น S3 ¹และ SQS - หากเส้นทางเริ่มต้นบนเครือข่ายย่อย VPC คือวัตถุเกตเวย์อินเทอร์เน็ต ดังนั้นหากคุณเป็นอินสแตนซ์บนซับเน็ต "สาธารณะ" แสดงว่าคุณต้องมีที่อยู่ IP สาธารณะเพื่อทำสิ่งต่างๆมากมายที่เซิร์ฟเวอร์มักจะต้องทำ

สำหรับอินสแตนซ์ที่มีเพียงที่อยู่ IP ส่วนตัวมีวิธีอื่นในการเข้าถึงอินเทอร์เน็ตขาออก นี่คือที่ที่ Network Address Translation²และอินสแตนซ์ NAT เข้ามา

เครื่องบนซับเน็ตส่วนตัวสามารถเข้าถึงอินเทอร์เน็ตได้เนื่องจากเส้นทางเริ่มต้นบนซับเน็ตส่วนตัวไม่ใช่อ็อบเจ็กต์ "Internet Gateway" ของ VPC ซึ่งเป็นอินสแตนซ์ EC2 ที่กำหนดค่าเป็นอินสแตนซ์ NAT

อินสแตนซ์ NAT เป็นอินสแตนซ์บนเครือข่ายย่อยสาธารณะที่มี IP สาธารณะและการกำหนดค่าเฉพาะ มี AMI ที่สร้างไว้ล่วงหน้าเพื่อทำสิ่งนี้หรือคุณสามารถสร้างเองก็ได้

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

ดังนั้นเมื่อเข้าถึงทรัพยากรอินเทอร์เน็ตภายนอกจากซับเน็ตส่วนตัวทราฟฟิกจะข้ามผ่านอินสแตนซ์ NAT และดูเหมือนว่าปลายทางจะมาจากที่อยู่ IP สาธารณะของอินสแตนซ์ NAT ... ดังนั้นทราฟฟิกการตอบกลับจะกลับมาที่อินสแตนซ์ NAT ไม่จำเป็นต้องกำหนดค่ากลุ่มความปลอดภัยให้กับอินสแตนซ์ NAT หรือกลุ่มความปลอดภัยที่กำหนดให้กับอินสแตนซ์ส่วนตัวให้ "อนุญาต" ทราฟฟิกการตอบกลับนี้เนื่องจากกลุ่มความปลอดภัยเป็นสถานะ พวกเขาตระหนักดีว่าทราฟฟิกการตอบกลับมีความสัมพันธ์กับเซสชันที่เกิดจากภายในดังนั้นจึงได้รับอนุญาตโดยอัตโนมัติ แน่นอนว่าการรับส่งข้อมูลที่ไม่คาดคิดจะถูกปฏิเสธเว้นแต่จะมีการกำหนดค่ากลุ่มความปลอดภัยให้อนุญาต

แตกต่างจากการกำหนดเส้นทาง IP ทั่วไปที่เกตเวย์เริ่มต้นของคุณอยู่บนเครือข่ายย่อยเดียวกันวิธีการทำงานใน VPC นั้นแตกต่างกัน: อินสแตนซ์ NAT สำหรับซับเน็ตส่วนตัวที่ระบุจะอยู่บนเครือข่ายย่อยที่แตกต่างกันเสมอและเครือข่ายย่อยอื่น ๆ จะเป็นเครือข่ายย่อยสาธารณะเสมอเนื่องจาก อินสแตนซ์ NAT จำเป็นต้องมี IP ภายนอกสาธารณะและเกตเวย์เริ่มต้นจะต้องเป็นอ็อบเจ็กต์ "Internet Gateway" ของ VPC

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

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

เนื่องจาก VPC มีเส้นทางโดยนัยจากเครือข่ายย่อยของ VPC ทั้งหมดไปยังเครือข่ายย่อยของ VPC อื่น ๆ เส้นทางเริ่มต้นจึงไม่มีบทบาทในการรับส่งข้อมูล VPC ภายใน อินสแตนซ์ที่มีที่อยู่ IP ส่วนตัวจะเชื่อมต่อกับที่อยู่ IP ส่วนตัวอื่น ๆ ใน VPC "จาก" ที่อยู่ IP ส่วนตัวไม่ใช่ "จาก" ที่อยู่ IP สาธารณะ (หากมี) ... ตราบใดที่ที่อยู่ปลายทางเป็นที่อยู่ส่วนตัวอื่น ภายใน VPC

หากอินสแตนซ์ของคุณที่มีที่อยู่ IP ส่วนตัวไม่จำเป็นต้องสร้างการรับส่งข้อมูลทางอินเทอร์เน็ตขาออกในทางเทคนิคแล้วอินสแตนซ์เหล่านี้สามารถใช้งานได้บนเครือข่ายย่อย "สาธารณะ" และจะยังคงไม่สามารถเข้าถึงได้จากอินเทอร์เน็ต ... แต่ภายใต้การกำหนดค่าดังกล่าว เป็นไปไม่ได้ที่พวกเขาจะสร้างการรับส่งข้อมูลขาออกไปยังอินเทอร์เน็ตซึ่งรวมถึงการเชื่อมต่อกับบริการโครงสร้างพื้นฐานของ AWS อื่น ๆ เช่น S3 ¹หรือ SQS

^{1. เกี่ยวกับ S3 โดยเฉพาะอย่างยิ่งที่จะกล่าวว่าการเข้าถึงอินเทอร์เน็ตเป็นสิ่งจำเป็นเสมอคือการลดความซับซ้อนที่มีแนวโน้มที่จะขยายขอบเขตไปเรื่อย ๆ และกระจายไปยังบริการอื่น ๆ ของ AWS เนื่องจากความสามารถของ VPC ยังคงเติบโตและพัฒนาอย่างต่อเนื่อง มีแนวคิดที่ค่อนข้างใหม่ที่เรียกว่าVPC Endpointที่อนุญาตให้อินสแตนซ์ของคุณรวมถึงอินสแตนซ์ที่มีที่อยู่ IP ส่วนตัวเท่านั้นสามารถเข้าถึง S3 ได้โดยตรงจากเครือข่ายย่อยที่เลือกภายใน VPC โดยไม่ต้องแตะ "อินเทอร์เน็ต" และไม่ต้องใช้อินสแตนซ์ NAT หรือเกตเวย์ NAT แต่ต้องมีการกำหนดค่าเพิ่มเติมและ ใช้ได้เฉพาะในการเข้าถึงที่เก็บข้อมูลภายในภูมิภาค AWS เดียวกับ VPC ของคุณ ตามค่าเริ่มต้น S3 ซึ่งเป็นบริการเดียวที่เปิดเผยความสามารถในการสร้างจุดสิ้นสุด VPC - สามารถเข้าถึงได้จากภายใน VPC ผ่านทางอินเทอร์เน็ตเท่านั้น เมื่อคุณสร้างจุดสิ้นสุด VPC สิ่งนี้จะสร้างรายการคำนำหน้า (pl-xxxxxxxx) ที่คุณสามารถใช้ในตารางเส้นทาง VPC ของคุณเพื่อส่งปริมาณการใช้งานสำหรับบริการ AWS นั้นโดยตรงไปยังบริการผ่านวัตถุเสมือน "VPC Endpoint" นอกจากนี้ยังแก้ปัญหาในการ จำกัด การเข้าถึงขาออกไปยัง S3 สำหรับบางกรณีเนื่องจากสามารถใช้รายการคำนำหน้าในกลุ่มความปลอดภัยขาออกแทนที่อยู่ IP ปลายทางหรือบล็อก - และปลายทาง S3 VPC อาจอยู่ภายใต้คำแถลงนโยบายเพิ่มเติม จำกัด การเข้าถึงที่เก็บข้อมูลจากภายในตามต้องการ}

^{2. ตามที่ระบุไว้ในเอกสารสิ่งที่จะกล่าวถึงในที่นี้คือพอร์ตและการแปลที่อยู่เครือข่าย เป็นเรื่องปกติแม้ว่าในทางเทคนิคจะไม่ชัดเจนเล็กน้อยในการอ้างถึงการดำเนินการรวมกันว่า "NAT" นี่ค่อนข้างคล้ายกับวิธีที่พวกเราหลายคนมักจะพูดว่า "SSL" เมื่อเราหมายถึง "TLS" จริงๆ เรารู้ว่าเรากำลังพูดถึงอะไร แต่เราไม่ได้ใช้คำที่ถูกต้องที่สุดในการอธิบาย "หมายเหตุเราใช้คำว่า NAT ในเอกสารนี้เพื่อปฏิบัติตามแนวปฏิบัติด้านไอทีทั่วไปแม้ว่าบทบาทที่แท้จริงของอุปกรณ์ NAT จะเป็นทั้งการแปลที่อยู่และการแปลที่อยู่พอร์ต (PAT)"}

ฉันขอแนะนำแทคอื่น ๆ - ทิ้งเครือข่ายย่อย "ส่วนตัว" และอินสแตนซ์ / เกตเวย์ NAT ไม่จำเป็น หากคุณไม่ต้องการให้เครื่องเข้าถึงได้จากอินเทอร์เน็ตอย่าวางไว้ในกลุ่มความปลอดภัยที่อนุญาตให้เข้าถึงได้

การทิ้งอินสแตนซ์ NAT / เกตเวย์เป็นการกำจัดต้นทุนการดำเนินการของอินสแตนซ์ / เกตเวย์และกำจัดขีด จำกัด ความเร็ว (ไม่ว่าจะเป็น 250mbit หรือ 10gbit)

หากคุณมีเครื่องที่ไม่จำเป็นต้องเข้าถึงอินเทอร์เน็ตโดยตรง (และฉันจะถามว่าคุณจะแพตช์มันอย่างไร *) ไม่ต้องกำหนดที่อยู่ IP สาธารณะ

* หากคำตอบที่นี่คือพร็อกซีบางประเภทคุณจะต้องเสียค่าใช้จ่าย แต่เป็นของเขาเอง

ฉันไม่มีชื่อเสียงในการเพิ่มความคิดเห็นในคำตอบของ Michael ด้านบนดังนั้นจึงเพิ่มความคิดเห็นของฉันเป็นคำตอบ

เป็นที่น่าสังเกตว่าเกตเวย์ที่มีการจัดการของ AWS มีราคาแพงกว่า ณ วันที่ประมาณ 3 เท่าเมื่อเทียบกับการรันอินสแตนซ์ของคุณเอง แน่นอนว่าสมมติว่าคุณต้องการอินสแตนซ์ NAT เพียงตัวเดียว (เช่นคุณไม่มีอินสแตนซ์ NAT หลายรายการที่กำหนดค่าสำหรับเฟลโอเวอร์ ฯลฯ ) ซึ่งโดยทั่วไปแล้วจะเป็นจริงสำหรับสถานการณ์กรณีการใช้งานขนาดเล็กถึงขนาดกลางส่วนใหญ่ สมมติว่ามีการถ่ายโอนข้อมูล 100GB ต่อเดือนผ่านเกตเวย์ NAT

ค่าใช้จ่ายรายเดือนของอินสแตนซ์ NAT ที่มีการจัดการ = 33.48 USD / เดือน (0.045 USD / ชั่วโมง * 744 ชั่วโมงต่อเดือน) + 4.50 USD (0.045 USD ต่อ GB ข้อมูลที่ประมวลผล * 100GB) + 10 USD (ค่าธรรมเนียมการถ่ายโอนข้อมูล AWS มาตรฐาน 10 USD / GB สำหรับข้อมูลทั้งหมดที่ถ่ายโอนผ่าน เกตเวย์ NAT) = 47.98 USD

อินสแตนซ์ t2.nano ที่กำหนดค่าเป็นอินสแตนซ์ NAT = 4.84 USD / เดือน (0.0065 USD * 744 ชั่วโมงต่อเดือน) + 10 USD (ค่าธรรมเนียมการถ่ายโอนข้อมูล AWS มาตรฐาน $ .10 / GB สำหรับข้อมูลทั้งหมดที่ถ่ายโอนผ่านอินสแตนซ์ NAT) = 14.84 USD

แน่นอนว่าสิ่งนี้จะเปลี่ยนแปลงไปเมื่อคุณใช้อินสแตนซ์ NAT ซ้ำซ้อนเนื่องจากเกตเวย์ NAT ที่มีการจัดการของ AWS มีความซ้ำซ้อนในตัวเพื่อความพร้อมใช้งานที่สูง หากคุณไม่สนใจเกี่ยวกับเงินพิเศษ $ 33 / เดือนอินสแตนซ์ NAT ที่มีการจัดการจะคุ้มค่ากับการปวดหัวที่ลดลงอย่างแน่นอนโดยไม่ต้องดูแลรักษาอินสแตนซ์อื่น หากคุณกำลังเรียกใช้อินสแตนซ์ VPN (เช่น OpenVPN) เพื่อเข้าถึงอินสแตนซ์ของคุณภายใน VPC คุณสามารถกำหนดค่าอินสแตนซ์นั้นให้ทำหน้าที่เป็นเกตเวย์ NAT ของคุณได้เช่นกันจากนั้นคุณไม่จำเป็นต้องดูแลอินสแตนซ์เพิ่มเติมสำหรับ NAT เท่านั้น ( แม้ว่าบางคนอาจขมวดคิ้วกับแนวคิดในการรวม VPN และ NAT)

คำตอบโดยMichael - sqlbotทำให้สมมติฐานโดยปริยายว่าต้องใช้ที่อยู่ IP ส่วนตัว ฉันคิดว่ามันคุ้มค่าที่จะตั้งคำถามกับสมมติฐานนั้น - เราจำเป็นต้องใช้ที่อยู่ IP ส่วนตัวตั้งแต่แรกหรือไม่? ผู้แสดงความคิดเห็นอย่างน้อยหนึ่งคนถามคำถามเดียวกัน

ข้อดีของเซิร์ฟเวอร์บนซับเน็ตส่วนตัวที่มีอินสแตนซ์ NAT [เทียบกับ] เซิร์ฟเวอร์ [ใน] ซับเน็ตสาธารณะที่มีนโยบายความปลอดภัยที่เข้มงวดคืออะไร - abhillman 24 มิ.ย. 57 เวลา 23:45 น

ลองนึกภาพสถานการณ์ที่คุณใช้ VPC และคุณกำหนดที่อยู่ IP สาธารณะให้กับอินสแตนซ์ EC2 ทั้งหมดของคุณ ไม่ต้องกังวลนั่นไม่ได้หมายความว่าพวกเขาสามารถเข้าถึงได้ทางอินเทอร์เน็ตเนื่องจากคุณใช้กลุ่มความปลอดภัยเพื่อ จำกัด การเข้าถึงในลักษณะเดียวกับที่ทำงานกับ EC2 classic การใช้ที่อยู่ IP สาธารณะจะช่วยให้คุณสามารถเปิดเผยบริการบางอย่างต่อผู้ชมที่ จำกัด ได้อย่างง่ายดายโดยไม่จำเป็นต้องใช้บางอย่างเช่น ELB สิ่งนี้ช่วยให้คุณไม่ต้องตั้งค่าอินสแตนซ์ NAT หรือเกตเวย์ NAT และเนื่องจากคุณต้องการเครือข่ายย่อยมากถึงครึ่งหนึ่งคุณจึงสามารถเลือกใช้การจัดสรร CIDR ที่เล็กลงสำหรับ VPC ของคุณหรือคุณอาจสร้างเครือข่ายย่อยที่ใหญ่ขึ้นด้วย VPC ที่มีขนาดเท่ากัน และเครือข่ายย่อยที่น้อยลงหมายความว่าคุณจะจ่ายน้อยลงสำหรับการรับส่งข้อมูลระหว่าง AZ เช่นกัน

แล้วทำไมเราไม่ทำเช่นนี้? เหตุใด AWS จึงกล่าวว่าแนวทางปฏิบัติที่ดีที่สุดคือการใช้ IP ส่วนตัว

Amazon Web Services มีที่อยู่ IPv4 สาธารณะจำนวน จำกัด เนื่องจากอินเทอร์เน็ตโดยรวมมีที่อยู่ IPv4 สาธารณะจำนวน จำกัด เป็นประโยชน์สูงสุดสำหรับคุณในการใช้ที่อยู่ IP ส่วนตัวซึ่งไม่ จำกัด อย่างมีประสิทธิภาพแทนที่จะใช้ที่อยู่ IPv4 สาธารณะที่หายากเกินไป คุณสามารถดูหลักฐานเกี่ยวกับเรื่องนี้ได้ในราคาของ Elastic IP ของ AWS EIP ที่แนบมากับอินสแตนซ์นั้นฟรี แต่ EIP ที่ไม่ได้ใช้มีค่าใช้จ่าย

แต่เพื่อประโยชน์ในการโต้แย้งสมมติว่าเราไม่สนใจปัญหาการขาดแคลนที่อยู่ IPv4 สาธารณะบนอินเทอร์เน็ต หลังจากที่ทุกคนของฉันแอปพลิเคพิเศษ จะเกิดอะไรขึ้นต่อไป?

มีเพียงสองวิธีในการแนบที่อยู่ IP สาธารณะกับอินสแตนซ์ EC2 ใน VPC

1. เชื่อมโยงที่อยู่ IP สาธารณะ

คุณสามารถขอที่อยู่ IP สาธารณะเมื่อเรียกใช้อินสแตนซ์ EC2 ใหม่ ตัวเลือกนี้ปรากฏเป็นช่องทำเครื่องหมายในคอนโซลเป็นแฟล็ก --associate-public-ip-addressเมื่อใช้ aws-cli และเป็นแฟล็กAssociatePublicIpAddressบนอ็อบเจ็กต์อินเทอร์เฟซเครือข่ายแบบฝังเมื่อใช้ CloudFormation ไม่ว่าในกรณีใด ๆ ที่อยู่ IP สาธารณะจะถูกกำหนดให้กับeth0(DeviceIndex = 0) คุณสามารถใช้แนวทางนี้เมื่อเปิดอินสแตนซ์ใหม่เท่านั้น อย่างไรก็ตามสิ่งนี้มาพร้อมกับข้อเสียบางประการ

ข้อเสียคือการเปลี่ยนกลุ่มความปลอดภัยของอินสแตนซ์ที่ใช้ออบเจ็กต์อินเทอร์เฟซเครือข่ายแบบฝังจะบังคับให้เปลี่ยนอินสแตนซ์ทันทีอย่างน้อยถ้าคุณใช้ CloudFormation

ข้อเสียอีกประการหนึ่งคือที่อยู่ IP สาธารณะที่กำหนดด้วยวิธีนี้จะหายไปเมื่ออินสแตนซ์หยุดทำงาน

2. ยืดหยุ่น IP

โดยทั่วไป Elastic IP เป็นแนวทางที่ต้องการเนื่องจากปลอดภัยกว่า คุณรับประกันว่าจะใช้ที่อยู่ IP เดิมต่อไปคุณจะไม่เสี่ยงต่อการลบอินสแตนซ์ EC2 ใด ๆ โดยไม่ได้ตั้งใจคุณสามารถเชื่อมต่อ / ถอด Elastic IP ได้อย่างอิสระเมื่อใดก็ได้และคุณมีอิสระในการเปลี่ยนกลุ่มความปลอดภัยที่ใช้กับอินสแตนซ์ EC2 ของคุณ

... แต่ AWS จำกัด คุณไว้ที่ 5 EIP ต่อภูมิภาค คุณสามารถขอเพิ่มเติมและคำขอของคุณอาจได้รับอนุญาต แต่ AWS อาจปฏิเสธคำขอนั้นได้ตามเหตุผลที่ฉันได้กล่าวไว้ข้างต้น ดังนั้นคุณอาจไม่ต้องการพึ่งพา EIP หากคุณวางแผนที่จะปรับขนาดโครงสร้างพื้นฐานของคุณให้เกิน 5 อินสแตนซ์ EC2 ต่อภูมิภาค

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