İki AWS hesabı, tek şirket içi ağ: hangi yol?
Paylaşılan Transit Gateway, iki bağımsız VPN veya tek dar proxy: bugün eklenmesi en kolay rotaya göre değil, sahipliğe ve etki alanına göre seçin.
Bariz çerçeve peering'e karşı VPN'dir ve bu yanlış çerçevedir. Eşlenmiş bir VPC, komşusunun VPN bağlantısını uçtan uca yönlendirme için ödünç alamaz, bu yüzden rota tablosu ne önerirse önersin o seçenek hiç masada olmadı. Gerçekte seçtiğiniz şey paylaşılan bir ağ merkezi, iki bağımsız VPN yolu ve tek dar bir uygulama girişidir. Her biri yönlendirmenin kime ait olduğuna dair farklı bir soruyu yanıtlar.
Üç seçenek ve seçenek olmayan
Peering fikrini silerek başlayın, ardından kalanı diyagram basitliğine göre değil sahipliğe göre karşılaştırın. Aşağıdaki tablo kararın sıkıştırılmış hâlidir.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
Hesap A'nın tüm şirket içi ağa erişmesi gerekiyorsa proxy satırı yanlış biçimdedir. Hesap A'nın tek bir API'ye ihtiyacı varsa ilk iki satır gereksinimin istediğinden fazla ağdır.
Paylaşılan Transit Gateway ne zaman kazanır
Transit Gateway her VPC'yi ve VPN'i ayrı ağlar olarak bağlar, hesaplar arası paylaşım VPC sahiplerinin hesapları birleştirmeden merkezi kullanmasını sağlar. Çekiciliği budur: şirket içi öneklerin AWS ağlarıyla buluştuğu tek yer ve hangi bağlantının hangi rotayı öğrendiğini düşünmek için tek yer.
Her şeyi bağlamak her şeye izin vermek değildir. İlişkilendirme ve yayılma hangi bağlantının hangi rota tablosunu kullandığını belirler, bu yüzden iki VPC öneki ayrı ayrı bir şirket içi hizmete ulaşabilirken karşılıklı erişimleri merkezin tasarımıyla dışarıda kalır. Şirket içi taraf hâlâ AWS önekleri için dönüş rotalarına ihtiyaç duyar ve bu başka bir ekibin değişiklik talebidir.
Maliyet finansal olduğu kadar örgütseldir. Merkezin sahibi diğer ekiplerin bağımlı olduğu yönlendirme ilişkilerini kontrol eder, bu yüzden tek bir bağlantıdaki değişiklik merkez sahibinin hiç duymadığı bir hizmetin trafiğini taşıyabilir. Bağlantı saatleri ve veri işleme bağladığınız her ağla birikir; bu yüzden merkezler genellikle onları işleten ekipten daha hızlı büyür.
Ayrı VPN'ler veya dar proxy ne zaman kazanır
İki bağımsız VPN gerçek operasyonel sınırları olan küçük bir kuruluma uyar: her hesap kendi tünellerini değiştirir ve hiçbiri rota tablosunu düzenleyerek diğerini bozamaz. Sınırlar şirket içi taraftadır. Eş ağ geçidinin ek tüneller için kapasiteye ihtiyacı vardır, adres planları çakışmamalıdır ve aynı önekleri duyuran iki yapılandırmanın umut yerine bilinçli bir tercihe ihtiyacı vardır.
Proxy en dar arayüzdür. Hesap A'nın B hesabında tek bir veritabanına veya tek bir API'ye ihtiyacı varsa, kapsamı belirlenmiş bir aracı size kendi kimlik doğrulama, günlükleme ve kullanılabilirlik hikâyesiyle tanımlı bir giriş verir. Aynı zamanda kötüye kullanılmaya en açık seçenektir: her özel hedefe yönlendiren bir aracı, fazladan adımlarla sınırsız bir röleye dönüşmüştür ve başka hiçbir şey için VPC'den şirket içi ağa şeffaf geçiş gibi davranmayacaktır.
Bunların hepsinden önce VPC peering kısıtlamalarını okumaya değer, çünkü dördüncü fikrin neden sürekli geri döndüğünü ve neden çalışamayacağını açıklarlar.
Gereksinimi karşılayan en dar arayüzü seçin
Soruları sıralayın: A bir ağa, bir ağ kümesine mi yoksa tek bir hizmete mi ihtiyaç duyuyor? Şirket içi ekip tek bir yol mu yoksa birkaç yol mu istiyor? Diğer ekibin trafiği için yönlendirmeyi kimin değiştirmesine izin var? En dar arayüzü üreten ilk yanıt mimaridir ve sonrasındaki her şey uygulamadır.
Yanıtı önek planı, rota sahipliği, tünel veya bağlantı envanteri ve her iki tarafın beklediği arıza moduyla birlikte kaydedin. Birisi daha sonra A hesabının neden yalnızca B hesabının VPN'ini kullanamadığını sorduğunda o kayıt yanıttır ve sizi bir sonraki projede aynı üç seçeneği yeniden tartışmaktan kurtarır.