VPC'de neden özel alt ağa ihtiyacımız var?

AWS VPC yapılandırmasında 4 senaryo vardır . Ama şu ikisine bakalım:

• Senaryo 1: 1 genel alt ağ.
• Senaryo 2: 1 genel alt ağ ve 1 özel alt ağ.

Genel alt ağda başlatılan herhangi bir örnek EIP'ye sahip olmadığından (atanmadıkça), zaten İnternet'ten adreslenemez. Sonra:

• Neden özel alt ağa ihtiyaç var?
• Özel ve genel alt ağlar arasındaki farklar tam olarak nedir?

Güncelleme: Aralık 2015'in sonlarında AWS , VPC için Yönetilen NAT Ağ Geçidi adlı yeni bir özelliği duyurdu . Bu isteğe bağlı hizmet, özel bir alt ağdaki VPC örneklerinin İnternet'e erişmesi için alternatif bir mekanizma sağlar. Önceden ortak çözüm, VPC içindeki genel bir alt ağda bulunan ve ağ adresi çevirisi sağlayan bir "NAT örneği" olarak çalışan bir EC2 örneğiydi ( teknik olarak, diğer özel alt ağlardaki örnekler için bağlantı noktası adresi çevirisi), bu makinelerin NAT örneğinin genel IP adresini giden İnternet erişimi için kullanmasına izin verir.

Yeni yönetilen NAT hizmeti, aşağıdaki bilgilerin uygulanabilirliğini temelden değiştirmez, ancak bu seçenek aşağıdaki içerikte ele alınmamaktadır. Bir NAT örneği yine de açıklandığı gibi kullanılabilir veya bunun yerine Yönetilen NAT Ağ Geçidi hizmeti sağlanabilir. Her ikisi de VPC'deki özel / genel alt ağ paradigması ile ilgili olduğundan, NAT Ağ Geçidi ve bunun bir NAT örneğiyle nasıl karşılaştırıldığı hakkında daha fazla bilgiyi entegre eden bu cevabın genişletilmiş bir sürümü çıkacaktır.

Not Internet Ağ Geçidi ve NAT Geçidi iki farklı özellikleridir. İnternet erişimi olan tüm VPC yapılandırmalarının bir İnternet Ağ Geçidi sanal nesnesi olacaktır.

Amazon VPC'de "özel" ve "genel" alt ağlar arasındaki farkı anlamak için, genel olarak IP yönlendirmesinin ve ağ adresi çevirisinin (NAT) nasıl çalıştığını ve VPC'de özel olarak nasıl uygulandığını anlamak gerekir.

VPC'deki genel ve özel alt ağ arasındaki temel fark, VPC yönlendirme tablolarında bu alt ağın varsayılan yolunun ne olduğu ile tanımlanır.

Bu yapılandırma, sırayla, söz konusu alt ağdaki örneklerde genel IP adreslerinin kullanılıp kullanılmamasının geçerliliğini belirler.

Her alt ağın tam olarak bir varsayılan yolu vardır ve bu, iki şeyden yalnızca biri olabilir:

• "genel" bir alt ağ olması durumunda VPC'nin "İnternet Ağ Geçidi" nesnesi veya
• bir NAT aygıtı - yani, bir "özel" alt ağ durumunda "NAT örneği" rolünü gerçekleştiren bir NAT Ağ Geçidi veya bir EC2 örneği.

İnternet Ağ Geçidi, genel IP adresleri olmayan örnekler için herhangi bir ağ adresi çevirisi yapmaz, bu nedenle genel IP adresi olmayan bir örnek , yazılım güncellemelerini indirmek veya S3 ¹ ve SQS gibi diğer AWS kaynaklarına erişmek gibi işlemler için İnternet'e dışarıya bağlanamaz. - VPC alt ağındaki varsayılan yol İnternet Ağ Geçidi nesnesiyse. Eğer bir "kamu" alt ağda bir örneği olup olmadığını Yani, o zaman ihtiyaç sunucuları genellikle yapmanız gereken şeylerin önemli sayıda yapmak için bir genel IP adresi.

Yalnızca özel bir IP adresi olan örnekler için, İnternet'e giden erişimin alternatif bir yolu vardır. Burası Ağ Adresi Çevirisi² ve bir NAT örneğinin devreye girdiği yerdir.

Özel alt ağda varsayılan rota olduğu için özel bir alt ağda makineleri internete değil VPC "internet gateway" nesne - bir NAT örneği olarak yapılandırılmış bir EC2 örneğidir.

NAT örneği, genel bir IP'ye ve belirli bir yapılandırmaya sahip genel bir alt ağdaki bir örnektir. Bunu yapmak için önceden oluşturulmuş AMI'ler vardır veya kendinizinkini oluşturabilirsiniz.

Özel adresli makineler trafiği dışarıya gönderdiğinde, trafik VPC tarafından NAT örneğine gönderilir ve bu paket üzerindeki kaynak IP adresini (özel makinenin özel IP adresi) kendi genel IP adresiyle değiştirir, trafiği gönderir İnternete gönderilir, yanıt paketlerini kabul eder ve bunları kaynak makinenin özel adresine geri iletir. (Ayrıca kaynak bağlantı noktasını yeniden yazabilir ve her durumda eşlemeleri hatırlayarak yanıt paketlerini hangi dahili makinenin alması gerektiğini bilir). Bir NAT örneği, özel olarak yapılandırılmadığı sürece, "beklenmedik" gelen trafiğin özel örneklere ulaşmasına izin vermez.

Bu nedenle, harici İnternet kaynağına özel bir alt ağdan erişilirken, trafik NAT örneğinden geçer ve hedefe NAT örneğinin genel IP adresinden kaynaklanmış gibi görünür ... bu nedenle yanıt trafiği NAT örneğine geri döner. Güvenlik grupları durum bilgisine sahip olduğundan, ne NAT örneğine atanan güvenlik grubunun ne de özel örneğe atanan güvenlik grubunun bu yanıt trafiğine "izin verecek" şekilde yapılandırılmasına gerek yoktur. Yanıt trafiğinin dahili olarak oluşturulan oturumlarla ilişkilendirildiğini fark ederler, bu nedenle otomatik olarak izin verilir. Güvenlik grubu izin verecek şekilde yapılandırılmadıkça, beklenmeyen trafik elbette reddedilir.

Varsayılan ağ geçidinizin aynı alt ağınızda olduğu geleneksel IP yönlendirmesinin aksine, VPC'de çalışma şekli farklıdır: Herhangi bir özel alt ağ için NAT örneği her zaman farklı bir alt ağdadır ve diğer alt ağ her zaman genel bir alt ağdır, çünkü NAT örneğinin genel bir harici IP'ye sahip olması gerekir ve varsayılan ağ geçidinin VPC "İnternet Ağ Geçidi" nesnesi olması gerekir.

Benzer şekilde ... bir örneği özel bir alt ağda genel IP ile dağıtamazsınız. Çalışmaz, çünkü özel bir alt ağdaki varsayılan yol (tanım gereği) bir NAT örneğidir (trafikte NAT gerçekleştirir) ve İnternet Ağ Geçidi nesnesi değildir (ki bu değildir). İnternetten gelen trafik, örneğin genel IP'sini vuracaktı, ancak yanıtlar NAT örneğinden dışarıya doğru yönlendirmeye çalışacak ve bu da trafiği azaltacaktır (çünkü farkında olmadığı bağlantılara verilen yanıtlardan oluşacaktır, bu nedenle geçersiz sayılır) veya kendi genel IP adresini kullanmak için yanıt trafiğini yeniden yazar; bu, harici kaynak iletişim kurmaya çalıştığı IP adresinden farklı bir IP adresinden gelen yanıtları kabul etmeyeceği için çalışmaz. .

Öyleyse, özünde, "özel" ve "genel" sıfatlar gerçekte İnternet'ten erişilebilirlik veya erişilemezlikle ilgili değildir. Bunlar, söz konusu alt ağdaki örneklere atanacak adres türleriyle ilgilidir; bu, bu IP adreslerini İnternet etkileşimleri için çevirme veya çevirmekten kaçınma ihtiyacı nedeniyle önemlidir.

VPC, tüm VPC alt ağlarından diğer tüm VPC alt ağlarına örtük yollara sahip olduğundan, varsayılan yol dahili VPC trafiğinde bir rol oynamaz. Özel IP adreslerine sahip örnekler, hedef adres başka bir özel adres olduğu sürece, VPC'deki diğer özel IP adreslerine "kendi özel IP adreslerinden" "bağlanır, genel IP adreslerinden" değil (eğer varsa) "bağlanır. VPC içinde.

Özel IP adreslerine sahip örnekleriniz hiçbir koşulda hiçbir zaman giden İnternet trafiği oluşturmaya ihtiyaç duymazsa, teknik olarak "genel" bir alt ağda konuşlandırılabilir ve yine de İnternet'ten erişilemez ... ancak böyle bir yapılandırma altında, S3 ¹ veya SQS gibi diğer AWS altyapı hizmetleriyle bağlantıları içeren İnternet'e giden trafiği başlatmaları imkansızdır .

^{1. S3 ile ilgili olarak, özellikle, İnternet erişiminin her zaman gerekli olduğunu söylemek, VPC'nin yetenekleri büyümeye ve gelişmeye devam ettikçe, kapsam açısından büyük olasılıkla zaman içinde büyüyecek ve diğer AWS hizmetlerine yayılacak bir aşırı basitleştirmedir. VPC Uç Noktası adı verilen nispeten yeni bir kavram varyalnızca özel IP adresleri olanlar dahil örneklerinizin "İnternet" e dokunmadan ve NAT örneği veya NAT ağ geçidi kullanmadan VPC içindeki seçili alt ağlardan S3'e doğrudan erişmesine olanak tanır, ancak bu ek yapılandırma gerektirir ve yalnızca VPC'nizle aynı AWS bölgesindeki paketlere erişmek için kullanılabilir. Varsayılan olarak, S3 - bu yazı itibariyle, VPC uç noktaları oluşturma yeteneğini açığa çıkaran tek hizmettir - yalnızca İnternet üzerinden VPC içinden erişilebilir. Bir VPC uç noktası oluşturduğunuzda, bu bir önek listesi oluşturur (pl-xxxxxxxx) söz konusu AWS hizmetine bağlı trafiği sanal "VPC Uç Noktası" nesnesi aracılığıyla doğrudan hizmete göndermek için VPC yönlendirme tablolarınızda kullanabileceğiniz. Önek listesi, bir hedef IP adresi veya blok yerine giden güvenlik gruplarında kullanılabildiğinden ve bir S3 VPC uç noktası ek politika ifadelerine tabi olabileceğinden, belirli bir örnek için giden erişimi S3'e kısıtlama sorununu da çözer. , istendiği gibi içeriden kova erişimini kısıtlama.}

^{2. Belgelerde belirtildiği gibi, burada aslında tartışılan şey bağlantı noktası ve ağ adresi çevirisidir. Teknik olarak biraz kesin olmasa da, birleşik işleme "NAT" olarak atıfta bulunmak yaygındır. Bu, birçoğumuzun aslında "TLS" yi kastettiğimizde "SSL" deme eğilimine benziyor. Neden bahsettiğimizi biliyoruz, ancak onu tanımlamak için en doğru kelimeyi kullanmıyoruz. "Not Bir NAT cihazının asıl rolü hem adres çevirisi hem de bağlantı noktası adresi çevirisi (PAT) olmasına rağmen, bu dokümantasyonda NAT terimini yaygın BT uygulamalarını takip etmek için kullanıyoruz."}

Farklı bir "özel" alt ağlar ve NAT örnekleri / ağ geçitleri öneririm. Gerekli değiller. Makinenin internetten erişilebilir olmasını istemiyorsanız, bu tür erişime izin veren bir güvenlik grubuna koymayın.

NAT örneğini / ağ geçidini ortadan kaldırarak, örneğin / ağ geçidinin çalıştırma maliyetini ortadan kaldırırsınız ve hız sınırını ortadan kaldırırsınız (250 mbit veya 10 gbit).

İnternete doğrudan erişmesi gerekmeyen bir makineniz varsa (ve ona nasıl yama uyguladığınızı sorarım *), o zaman kesinlikle genel bir IP adresi atamayın.

* Buradaki cevap bir çeşit vekil ise, bir ek yüke maruz kalıyorsunuz, ancak her biri kendi başına.

Michael'ın yukarıdaki cevabına yorum ekleyecek saygınlığa sahip değilim, dolayısıyla yorumumu cevap olarak ekledim.

AWS tarafından yönetilen ağ geçidinin, kendi bulut sunucunuzu çalıştırmaya kıyasla tarihte olduğundan yaklaşık 3 kat daha pahalı olduğunu belirtmek gerekir. Bu, elbette, yalnızca bir NAT örneğine ihtiyaç duyduğunuzu varsayar (yani, yük devretme için yapılandırılmış birden fazla NAT örneğiniz yok, vb.), Bu genellikle çoğu küçük ila orta kullanım durumu senaryosu için geçerlidir. NAT ağ geçidi üzerinden aylık 100 GB veri aktarımı olduğunu varsayarsak,

Yönetilen NAT örneğinin aylık maliyeti = 33,48 USD / ay (0,045 USD / saat * bir ayda 744 saat) + 4,50 USD (işlenen GB veri başına 0,045 USD * 100GB) + 10 USD (0,10 USD / GB standart AWS veri aktarım ücretleri, üzerinden aktarılan tüm veriler için NAT ağ geçidi) = 47,98 ABD doları

NAT örneği olarak yapılandırılan t2.nano örneği = 4,84 USD (ayda 0,0065 USD * 744 saat) + 10 USD (NAT örneği üzerinden aktarılan tüm veriler için 0,10 USD / GB standart AWS veri aktarım ücretleri) = 14,84 USD

AWS tarafından yönetilen NAT ağ geçidinde yüksek kullanılabilirlik için yerleşik yedeklilik bulunduğundan bu durum elbette yedekli NAT örneklerine gittiğinizde değişir. Ayda fazladan 33 ABD doları önemsemiyorsanız, yönetilen NAT örneği kesinlikle başka bir örneği sürdürmek zorunda kalmamanın azaltılmış baş ağrısına değer. VPC içindeki örneklerinize erişim için bir VPN (ör. OpenVPN) örneği çalıştırıyorsanız, bu örneği NAT ağ geçidiniz olarak işlev görecek şekilde yapılandırabilir ve ardından yalnızca NAT için fazladan bir örnek tutmanız gerekmez ( bazı insanlar VPN ve NAT'ı birleştirme fikrine kaşlarını çatabilir).

Michael - sqlbot'un cevabı , gizli IP adreslerinin gerekli olduğu varsayımını yapar. Bu varsayımı sorgulamanın faydalı olduğunu düşünüyorum - ilk etapta özel IP adreslerini kullanmamız gerekiyor mu? En az bir yorumcu aynı soruyu sordu.

NAT örneğine sahip özel bir alt ağdaki bir sunucunun, katı bir güvenlik politikasına sahip [bir] genel alt ağdaki bir sunucuya [karşı] avantajı nedir? - abhillman 24 Haziran 2014 , 23:45

Bir VPC kullandığınız ve tüm EC2 bulut sunucularınıza genel IP adresleri atadığınız bir senaryo hayal edin. Endişelenmeyin, bu onların internet üzerinden mutlaka erişilebilir oldukları anlamına gelmez, çünkü erişimi kısıtlamak için güvenlik gruplarını, tıpkı EC2 classic ile işlediği gibi aynı şekilde kullanırsınız. Genel IP adreslerini kullanarak, ELB gibi bir şey kullanmaya gerek kalmadan belirli hizmetleri sınırlı bir hedef kitleye kolayca sunma avantajına sahipsiniz. Bu sizi bir NAT örneği veya NAT ağ geçidi kurma ihtiyacından kurtarır. Ve yarısı kadar alt ağa ihtiyacınız olduğundan, VPC'niz için daha küçük bir CIDR tahsisi kullanmayı seçebilir veya aynı boyutta VPC ile daha büyük alt ağlar oluşturabilirsiniz. Ve daha az alt ağ, AZ arası trafik için de daha az ödeme yapacağınız anlamına gelir.

Öyleyse neden bunu yapmıyoruz? AWS neden en iyi uygulamanın özel IP kullanmak olduğunu söylüyor?

Amazon Web Services sınırlı bir genel IPv4 adres kaynağına sahiptir, çünkü internetin tamamı sınırlı bir genel IPv4 adresine sahiptir. Kıt olan genel IPv4 adreslerini aşırı derecede tüketmek yerine, etkin olarak sınırsız olan özel IP adreslerini kullanmanız onların yararınadır. AWS'nin Esnek IP'leri nasıl fiyatlandırdığına dair bazı kanıtları görebilirsiniz; bir örneğe eklenen bir EIP ücretsizdir ancak kullanılmayan bir EIP ücretlidir.

Ancak tartışma uğruna, internetteki herkese açık IPv4 adreslerinin eksikliğini umursamadığımızı varsayalım. Sonuçta, benim uygulama özeldir. Sonra ne olur?

Bir VPC'deki EC2 bulut sunucusuna genel bir IP adresi eklemenin yalnızca iki yolu vardır.

1. Genel IP Adresini İlişkilendirin

Yeni bir EC2 bulut sunucusu başlatırken genel bir IP adresi talep edebilirsiniz. Bu seçenek, konsolda bir onay kutusu olarak, aws-cli kullanılırken --associate-public-ip-address bayrağı olarak ve CloudFormation kullanılırken katıştırılmış bir ağ arabirimi nesnesinde AssociatePublicIpAddress bayrağı olarak görünür. Her durumda, genel IP adresi eth0(DeviceIndex = 0) 'a atanır . Bu yaklaşımı yalnızca yeni bir bulut sunucusu başlatırken kullanabilirsiniz. Ancak bunun bazı dezavantajları da vardır.

Bir dezavantaj, gömülü bir ağ arabirimi nesnesi kullanan bir örneğin güvenlik grubunu değiştirmenin, en azından CloudFormation kullanıyorsanız, örneğin hemen değiştirilmesini zorlayacağıdır.

Diğer bir dezavantaj, bu şekilde atanan genel bir IP adresinin, örnek durdurulduğunda kaybolacak olmasıdır.

2. Esnek IP

Genel olarak Esnek IP'ler daha güvenli oldukları için tercih edilen yaklaşımdır. Aynı IP adresini kullanmaya devam edeceğiniz garanti edilir, herhangi bir EC2 bulut sunucusunu yanlışlıkla silme riskini almazsınız, bir Esnek IP'yi dilediğiniz zaman serbestçe bağlayabilir / çıkarabilir ve EC2 bulut sunucularınıza uygulanan güvenlik gruplarını değiştirme özgürlüğüne sahipsiniz.

... Ancak AWS sizi bölge başına 5 EIP ile sınırlar. Daha fazlasını talep edebilirsiniz ve talebiniz kabul edilebilir. Ancak AWS, yukarıda bahsettiğim gerekçeye dayanarak bu isteği reddedebilir. Dolayısıyla, altyapınızı bölge başına 5 EC2 bulut sunucusunun ötesinde ölçeklendirmeyi planlıyorsanız muhtemelen EIP'lere güvenmek istemezsiniz.

Sonuç olarak, genel IP adreslerini kullanmanın bazı güzel faydaları vardır, ancak yalnızca genel IP adreslerini kullanmaya çalışırsanız, yönetim veya ölçeklendirme sorunlarıyla karşılaşırsınız. Umarım bu, en iyi uygulamaların neden olduğu gibi olduğunu göstermeye ve açıklamaya yardımcı olur.