Mengapa kita membutuhkan subnet pribadi di VPC?

Ada 4 skenario dalam konfigurasi AWS VPC. Tapi mari kita lihat dua ini:

• Skenario 1: 1 subnet publik.
• Skenario 2: 1 subnet publik dan 1 subnet pribadi.

Karena contoh apa pun yang diluncurkan di subnet publik tidak memiliki EIP (kecuali jika ditetapkan), itu sudah tidak dapat dialamatkan dari Internet. Kemudian:

• Mengapa ada kebutuhan untuk subnet pribadi?
• Apa sebenarnya perbedaan antara subnet pribadi dan publik?

Pembaruan: pada akhir Desember 2015, AWS mengumumkan fitur baru, Managed NAT Gateway untuk VPC . Layanan opsional ini menyediakan mekanisme alternatif untuk instance VPC dalam subnet pribadi untuk mengakses Internet, di mana sebelumnya, solusi umum adalah instance EC2 pada subnet publik dalam VPC, berfungsi sebagai "instance NAT," menyediakan terjemahan alamat jaringan ( secara teknis, terjemahan alamat port ) untuk instance di subnet pribadi lainnya, yang memungkinkan mesin tersebut untuk menggunakan alamat IP publik milik NAT untuk akses Internet keluar mereka.

Layanan NAT yang dikelola baru tidak secara fundamental mengubah penerapan informasi berikut, tetapi opsi ini tidak dibahas dalam konten yang mengikuti. Sebuah instance NAT masih dapat digunakan seperti yang dijelaskan, atau layanan Gateway NAT yang Dikelola dapat disediakan. Versi yang diperluas dari jawaban ini mengintegrasikan lebih banyak informasi tentang NAT Gateway dan bagaimana perbandingannya dengan instance NAT akan muncul, karena keduanya relevan dengan paradigma subnet pribadi / publik di VPC.

Perhatikan bahwa Internet Gateway dan NAT Gateway adalah dua fitur yang berbeda. Semua konfigurasi VPC dengan akses Internet akan memiliki objek virtual Gateway Internet.

Untuk memahami perbedaan antara subnet "pribadi" dan "publik" di Amazon VPC, diperlukan pemahaman tentang bagaimana IP routing dan terjemahan alamat jaringan (NAT) bekerja secara umum, dan bagaimana subnet itu secara khusus diimplementasikan dalam VPC.

Diferensiasi inti antara subnet publik dan pribadi dalam VPC ditentukan oleh apa rute default subnet itu, dalam tabel perutean VPC.

Konfigurasi ini, pada gilirannya, menentukan validitas menggunakan, atau tidak menggunakan, alamat IP publik pada instance pada subnet tertentu.

Setiap subnet memiliki tepat satu rute default, yang hanya dapat satu dari dua hal:

• objek "Internet Gateway" VPC, dalam kasus subnet "publik", atau
• perangkat NAT - yaitu, baik NAT Gateway atau instance EC2, melakukan peran "instance NAT", dalam kasus subnet "pribadi".

Internet Gateway tidak melakukan terjemahan alamat jaringan untuk contoh tanpa alamat IP publik sehingga sebuah contoh tanpa alamat IP publik tidak dapat terhubung ke luar ke Internet - untuk melakukan hal-hal seperti men-download pembaruan perangkat lunak, atau mengakses sumber informasi lainnya AWS seperti S3 ¹ dan SQS - jika rute default pada subnet VPC-nya adalah objek Internet Gateway. Jadi, jika Anda adalah instance pada subnet "publik", maka Anda memerlukan alamat IP publik untuk melakukan sejumlah besar hal yang perlu dilakukan server.

Untuk contoh dengan hanya alamat IP pribadi, ada cara alternatif akses keluar ke Internet. Di sinilah Terjemahan Alamat Jaringan² dan instance NAT masuk.

Mesin-mesin pada subnet pribadi dapat mengakses Internet karena rute default pada subnet pribadi bukanlah objek "Internet Gateway" VPC - ini adalah instance EC2 yang dikonfigurasi sebagai instance NAT.

Sebuah instance NAT adalah instance pada subnet publik dengan IP publik, dan konfigurasi khusus. Ada AMI yang dibuat untuk melakukan ini, atau Anda bisa membuat sendiri.

Ketika mesin beralamat pribadi mengirim lalu lintas keluar, lalu lintas dikirim, oleh VPC, ke instance NAT, yang menggantikan alamat IP sumber pada paket (alamat IP pribadi mesin pribadi) dengan alamat IP publiknya sendiri, mengirimkan lalu lintas keluar ke Internet, menerima paket respons, dan meneruskannya kembali ke alamat pribadi mesin asal. (Mungkin juga menulis ulang port sumber, dan dalam hal apa pun, ia mengingat pemetaan sehingga ia tahu mesin internal mana yang harus menerima paket respons). Mesin virtual NAT tidak mengizinkan lalu lintas masuk "tak terduga" untuk mencapai mesin virtual pribadi, kecuali jika sudah dikonfigurasikan secara khusus untuk melakukannya.

Jadi, ketika mengakses sumber daya Internet eksternal dari subnet pribadi, lalu lintas melintasi instance NAT, dan tampaknya ke tujuan berasal dari alamat IP publik instance NAT ... sehingga lalu lintas respons kembali ke instance NAT. Grup keamanan yang ditugaskan pada instance NAT maupun grup keamanan yang ditugaskan untuk instance privat tidak perlu dikonfigurasi untuk "mengizinkan" lalu lintas respons ini, karena grup keamanan stateful. Mereka menyadari bahwa lalu lintas respons terkait dengan sesi yang berasal dari internal, sehingga secara otomatis diizinkan. Lalu lintas yang tidak terduga, tentu saja, ditolak kecuali grup keamanan dikonfigurasi untuk mengizinkannya.

Tidak seperti IP routing konvensional, di mana gateway default Anda berada di subnet yang sama, cara kerjanya di VPC berbeda: contoh NAT untuk setiap subnet pribadi yang diberikan selalu pada subnet yang berbeda, dan bahwa subnet lain selalu merupakan subnet publik, karena instance NAT perlu memiliki IP eksternal publik, dan gateway default-nya harus menjadi objek "Internet Gateway" VPC.

Demikian pula ... Anda tidak dapat menggunakan instance dengan IP publik pada subnet pribadi. Tidak berfungsi, karena rute default pada subnet pribadi adalah (menurut definisi) instance NAT (yang melakukan NAT pada lalu lintas), dan bukan objek Internet Gateway (yang tidak). Lalu lintas masuk dari Internet akan mencapai IP publik dari instance, tetapi balasan akan mencoba untuk merutekan keluar melalui instance NAT, yang akan menjatuhkan lalu lintas (karena itu akan terdiri dari balasan untuk koneksi yang tidak disadari, sehingga mereka akan dianggap tidak valid) atau akan menulis ulang lalu lintas balasan untuk menggunakan alamat IP publiknya sendiri, yang tidak akan berfungsi karena asal eksternal tidak akan menerima balasan yang berasal dari alamat IP selain dari yang mereka coba untuk memulai komunikasi dengan .

Pada intinya, sebutan "pribadi" dan "publik" tidak benar-benar tentang aksesibilitas atau tidak dapat diaksesnya dari Internet. Mereka adalah tentang jenis-jenis alamat yang akan ditugaskan untuk instance pada subnet itu, yang relevan karena kebutuhan untuk menerjemahkan - atau menghindari menerjemahkan - alamat IP untuk interaksi Internet.

Karena VPC memiliki rute implisit dari semua subnet VPC ke semua subnet VPC lainnya, rute default tidak berperan dalam lalu lintas VPC internal. Mesin virtual dengan alamat IP pribadi akan terhubung ke alamat IP pribadi lainnya di VPC "dari" alamat IP pribadi mereka, bukan "dari" alamat IP publik mereka (jika ada) ... selama alamat tujuan adalah alamat pribadi lain dalam VPC.

Jika instance Anda dengan alamat IP pribadi tidak pernah, dalam keadaan apa pun, perlu berasal dari lalu lintas Internet keluar, maka mereka secara teknis dapat digunakan pada subnet "publik" dan masih akan tetap tidak dapat diakses dari Internet ... tetapi di bawah konfigurasi seperti itu, tidak mungkin bagi mereka untuk memulai lalu lintas keluar menuju Internet, yang mencakup koneksi dengan layanan infrastruktur AWS lainnya, sekali lagi, seperti S3 ¹ atau SQS.

^{1. Mengenai S3, khususnya, untuk mengatakan bahwa akses Internet selalu diperlukan adalah penyederhanaan berlebihan yang kemungkinan akan tumbuh dalam cakupan seiring waktu dan menyebar ke layanan AWS lainnya, karena kemampuan VPC terus tumbuh dan berkembang. Ada konsep yang relatif baru yang disebut VPC Endpointyang memungkinkan mesin virtual Anda, termasuk yang hanya memiliki alamat IP pribadi, untuk secara langsung mengakses S3 dari subnet yang dipilih dalam VPC, tanpa menyentuh "Internet," dan tanpa menggunakan instance NAT atau gateway NAT, tetapi ini membutuhkan konfigurasi tambahan, dan merupakan hanya dapat digunakan untuk mengakses bucket dalam wilayah AWS yang sama dengan VPC Anda. Secara default, S3 - yang, pada tulisan ini, satu-satunya layanan yang telah memaparkan kemampuan membuat titik akhir VPC - hanya dapat diakses dari dalam VPC melalui Internet. Saat Anda membuat titik akhir VPC, ini membuat daftar awalan (pl-xxxxxxxx) yang dapat Anda gunakan dalam tabel rute VPC Anda untuk mengirim lalu lintas terikat untuk layanan AWS tertentu langsung ke layanan melalui objek "VPC Endpoint" virtual. Ini juga memecahkan masalah membatasi akses keluar ke S3 untuk contoh tertentu, karena daftar awalan dapat digunakan dalam grup keamanan keluar, di tempat alamat IP atau blok tujuan - dan titik akhir S3 VPC dapat dikenakan pernyataan kebijakan tambahan , membatasi akses bucket dari dalam, seperti yang diinginkan.}

^{2. Seperti disebutkan dalam dokumentasi, apa yang sebenarnya dibahas di sini adalah port serta terjemahan alamat jaringan. Adalah umum, meskipun secara teknis sedikit tidak tepat, untuk menyebut operasi gabungan sebagai "NAT." Ini agak mirip dengan cara banyak dari kita cenderung mengatakan "SSL" ketika kita sebenarnya berarti "TLS." Kita tahu apa yang kita bicarakan, tetapi kita tidak menggunakan kata yang paling tepat untuk menggambarkannya. "Catatan Kami menggunakan istilah NAT dalam dokumentasi ini untuk mengikuti praktik TI yang umum, meskipun peran sebenarnya dari perangkat NAT adalah terjemahan alamat dan terjemahan alamat port (PAT)."}

Saya akan menyarankan subnet "private" taktik dan parit yang berbeda dan instance / gateway NAT. Mereka tidak perlu. Jika Anda tidak ingin mesin dapat diakses dari internet, jangan letakkan di grup keamanan yang memungkinkan akses tersebut.

Dengan membuang instance / gateway NAT, Anda menghilangkan biaya pengoperasian instance / gateway, dan Anda menghilangkan batas kecepatan (baik itu 250mbit atau 10gbit).

Jika Anda memiliki mesin yang juga tidak perlu mengakses internet secara langsung, (dan saya akan bertanya bagaimana Anda menambalnya *), maka dengan segala cara, jangan tetapkan alamat IP publik.

* Jika jawabannya di sini adalah semacam proxy, well, Anda dikenai biaya tambahan, tetapi masing-masing untuknya sendiri.

Saya tidak memiliki reputasi untuk menambahkan komentar pada jawaban Michael di atas, karenanya menambahkan komentar saya sebagai jawaban.

Perlu dicatat bahwa gateway yang dikelola AWS ~ 3 kali lebih mahal daripada tanggal saat dibandingkan dengan menjalankan instance Anda sendiri. Ini tentu saja dengan asumsi bahwa Anda hanya memerlukan satu instance NAT (yaitu Anda tidak memiliki beberapa instance NAT yang dikonfigurasi untuk failover, dll.) Yang umumnya berlaku untuk sebagian besar skenario kasus penggunaan kecil. Dengan asumsi transfer data bulanan 100GB melalui gateway NAT,

Biaya bulanan instance NAT yang dikelola = $ 33,48 / bulan ($ 0,045 / jam * 744 jam dalam sebulan) + $ 4,50 ($ 0,045 per GB data yang diproses * 100GB) + $ 10 ($ .10 / GB biaya transfer data AWS standar untuk semua data yang ditransfer melalui Gateway NAT) = $ 47,98

instance t2.nano dikonfigurasikan sebagai instance NAT = $ 4,84 / bulan ($ 0,0065 * 744 jam dalam sebulan) + $ 10 ($ .10 / GB biaya transfer data AWS standar untuk semua data yang ditransfer melalui instance NAT) = $ 14,84

Ini tentu saja berubah ketika Anda menggunakan instance NAT redundan karena gateway NAT yang dikelola AWS memiliki redundansi bawaan untuk ketersediaan tinggi. Jika Anda tidak peduli dengan tambahan $ 33 / bulan, maka instance NAT yang dikelola pasti sepadan dengan berkurangnya sakit kepala karena tidak harus mempertahankan instance lain. Jika Anda menjalankan instance VPN (mis. OpenVPN) untuk akses ke instance Anda dalam VPC, Anda bisa mengonfigurasi instance itu untuk juga bertindak sebagai gateway NAT Anda, dan kemudian Anda tidak perlu mempertahankan instance tambahan hanya untuk NAT ( meskipun beberapa orang mungkin tidak menyukai gagasan menggabungkan VPN dan NAT).

Jawaban oleh Michael - sqlbot membuat asumsi implisit bahwa alamat IP pribadi diperlukan. Saya pikir ada baiknya mempertanyakan asumsi itu - apakah kita bahkan perlu menggunakan alamat IP pribadi? Setidaknya satu komentator mengajukan pertanyaan yang sama.

Apa keuntungan dari server pada subnet pribadi dengan instance NAT [vs] server [dalam] subnet publik dengan kebijakan keamanan yang ketat? - abhillman 24 Juni 14 jam 23:45

Bayangkan sebuah skenario di mana Anda menggunakan VPC dan Anda menetapkan alamat IP publik untuk semua instance EC2 Anda. Jangan khawatir, itu tidak berarti mereka harus dapat dijangkau melalui internet, karena Anda menggunakan grup keamanan untuk membatasi akses dengan cara yang persis sama dengan yang bekerja dengan EC2 classic. Dengan menggunakan alamat IP publik, Anda mendapatkan manfaat untuk dapat dengan mudah mengekspos layanan tertentu kepada khalayak terbatas tanpa perlu menggunakan sesuatu seperti ELB. Ini membebaskan Anda dari kebutuhan untuk membuat instance NAT atau gateway NAT. Dan karena Anda membutuhkan setengah jumlah subnet, Anda dapat memilih untuk menggunakan alokasi CIDR yang lebih kecil untuk VPC Anda atau Anda dapat membuat subnet yang lebih besar dengan ukuran VPC yang sama. Dan lebih sedikit subnet berarti Anda akan membayar lebih sedikit untuk lalu lintas antar-AZ juga.

Jadi, mengapa kita tidak melakukan ini? Mengapa AWS mengatakan praktik terbaik adalah menggunakan IP pribadi?

Amazon Web Services memiliki persediaan terbatas alamat IPv4 publik karena internet secara keseluruhan memiliki persediaan terbatas alamat IPv4 publik. Adalah kepentingan terbaik mereka bagi Anda untuk menggunakan alamat IP pribadi yang secara efektif tidak terbatas, daripada mengonsumsi alamat IPv4 publik yang langka secara berlebihan. Anda dapat melihat beberapa bukti tentang ini dalam cara AWS harga Elastic IP's EIP yang dilampirkan ke instance gratis, tetapi EIP yang tidak digunakan membutuhkan biaya.

Tetapi demi argumen, mari kita asumsikan bahwa kita tidak peduli dengan kekurangan alamat IPv4 publik di internet. Lagipula, aplikasi saya istimewa. Apa yang terjadi selanjutnya?

Hanya ada dua cara untuk melampirkan alamat IP publik ke instance EC2 dalam VPC.

1. Mengaitkan Alamat IP Publik

Anda dapat meminta alamat IP publik saat meluncurkan instance EC2 baru. Opsi ini muncul sebagai kotak centang di konsol, sebagai flag --associate-public-ip-address saat menggunakan aws-cli, dan sebagai flag AssociatePublicIpAddress pada objek antarmuka jaringan tertanam saat menggunakan CloudFormation. Dalam hal apa pun, alamat IP publik ditetapkan untuk eth0(DeviceIndex = 0). Anda hanya dapat menggunakan pendekatan ini saat meluncurkan instance baru. Namun, ini dilengkapi dengan beberapa kelemahan.

Kerugiannya adalah bahwa mengubah grup keamanan dari instance yang menggunakan objek antarmuka jaringan tertanam akan memaksa penggantian instance dengan segera, setidaknya jika Anda menggunakan CloudFormation.

Kerugian lain adalah bahwa alamat IP publik yang ditetapkan dengan cara ini akan hilang ketika instance dihentikan.

2. IP elastis

Secara umum Elastic IP adalah pendekatan yang disukai karena lebih aman. Anda dijamin untuk terus menggunakan alamat IP yang sama, Anda tidak mengambil risiko secara tidak sengaja menghapus instance EC2, Anda dapat dengan bebas melampirkan / melepaskan IP Elastis kapan saja, dan Anda memiliki kebebasan untuk mengubah grup keamanan yang diterapkan pada instance EC2 Anda.

... Tapi AWS membatasi Anda hingga 5 EIP per wilayah. Anda dapat meminta lebih banyak, dan permintaan Anda mungkin dikabulkan. Tetapi AWS bisa saja menolak permintaan itu berdasarkan alasan yang saya sebutkan di atas. Jadi Anda mungkin tidak ingin bergantung pada EIP jika Anda berencana untuk meningkatkan skala infrastruktur Anda melebihi 5 instance EC2 per wilayah.

Kesimpulannya, menggunakan alamat IP publik memang membawa manfaat yang bagus, tetapi Anda akan mengalami masalah administrasi atau penskalaan jika Anda mencoba menggunakan alamat IP publik secara eksklusif. Semoga ini membantu untuk menggambarkan dan menjelaskan mengapa praktik terbaik adalah cara mereka.