Scentralizuj dostęp za pomocą punktów końcowych interfejsu VPC, aby uzyskać dostęp do usług AWS w wielu VPC

Bezpieczeństwo i koszt są zawsze priorytetem dla klientów AWS podczas projektowania ich sieci. Amazon Virtual Private Cloud (Amazon VPC) i powiązane z nim składniki sieciowe oferują wiele narzędzi do wdrażania łączności sieciowej.

Jednym z takich narzędzi są endpointy VPC. Obsługiwane przez AWS PrivateLink, endpointy VPC to prywatne połączenia między VPC a inną usługą AWS bez wysyłania ruchu przez Internet, za pośrednictwem instancji NAT, połączenia VPN lub AWS Direct Connect. W tym poście przedstawiamy projekt hub-and-spoke w którym wszystkie spoke VPC używają interfejsu końcowego punktu VPC udostępnionego wewnątrz huba (usług wspólnych) VPC. Ta architektura może pomóc w obniżeniu kosztów i utrzymaniu wielu punktów końcowych interfejsu VPC w różnych VPC.

Od momentu uruchomienia w 2015 roku, punkty końcowe VPC były używane do prywatnego uzyskiwania dostępu do usług AWS, endpointów API AWS i aplikacji SaaS. Punkty końcowe VPC to skalowalne w poziomie, nadmiarowe i wysoce dostępne komponenty VPC. Umożliwiają komunikację między instancjami w VPC a usługami bez narzucania ryzyka związanego z dostępnością. Dzięki punktom końcowym VPC, Twoje VPC nie muszą mieć bramy internetowej ani bramy NAT dla instancji EC2, aby uzyskać dostęp do usług AWS i punktów końcowych.

Istnieją dwa typy endpointów VPC - punkty końcowe bramy i punkty końcowe interfejsu. Punkty końcowe bramy mogą być używane do uzyskiwania dostępu do regionalnego bucketu S3, tabel DynamoDB, a endpointy interfejsu mogą być używane do uzyskiwania dostępu do punktów końcowych usług AWS lub usług punktów końcowych VPC. Wraz ze wzrostem liczby VPC na koncie centralizacja punktów końcowych interfejsu może być opłacalnym rozwiązaniem. Przejrzyj informacje o cenach AWS PrivateLink, aby dowiedzieć się więcej o cenie.

Centralizowanie punktu końcowego interfejsu VPC

Oceniając opcje łączności VPC i rozpoznawanie nazw DNS, należy wziąć pod uwagę kilka rzeczy.

Jak połączyć spoke VPC, aby uzyskać dostęp do endpointu  interfejsu wewnątrz huba VPC?

W tym celu używamy połączeń VPC typu peering. (Alternatywnie możesz użyć AWS Transit Gateway, który jest opisany w artykule na blogu Integrating AWS Transit Gateway with AWS PrivateLink i Amazon Route 53 Resolver.)

Jak rozwiązać DNS dla enpointu usługi AWS ze spoke VPC?

Możemy włączyć Private DNS dla punktu końcowego interfejsu i dzięki temu możemy rozwiązać DNS punktu końcowego usługi AWS z tego samego VPC (na przykład sqs.us-east-1.amazonaws.com). Jednak punkt końcowy usługi AWS nie jest rozpoznawany z peered VPC. W tym celu możemy utworzyć Private Hosted Zone (prywatną strefę) (na przykład sqs.us-east-1.amazonaws.com) i powiązać ją z równorzędnymi VPC.

W jaki sposób uzyskujesz dostęp do punktów końcowych interfejsu spoza VPC?

Możesz również uzyskać dostęp do endpointów interfejsu przez AWS Site-to-Site VPN lub AWS Direct Connect, jednak połączenie to musi zostać zakończone w VPC usług wspólnych.

Kroki konfiguracji (część 1):

1. Zakładając, że obciążenia (spoke) VPC już istnieją, utwórz nowy koncentrator VPC i prywatną podsieć do hostowania punktu końcowego VPC interfejsu.
2. Utwórz endpoint interfejsu VPC dla wymaganej usługi AWS (na przykład Amazon SQS) i wybierz podsieć utworzoną w kroku 1. W grupie zabezpieczeń upewnij się, że dodano regułę przychodzącą dla ruchu HTTPS ze spoke’ów VPC CIDR. W regułach ruchu wychodzącego grupy zabezpieczeń nie są wymagane żadne zmiany, ponieważ ruch nigdy nie jest inicjowany przez interfejs sieciowy punktu końcowego interfejsu (ENI - elastic network interface).
3. W przypadku zasad dotyczących punktów końcowych VPC wybieramy zasadę domyślną, jednak w środowisku produkcyjnym można ograniczyć dostęp do AWS Principals.
4. Skonfiguruj połączenie peering pomiędzy VPC spoke oraz hub.
5. Skonfiguruj tabele tras w hub i spoke VPC oraz dodaj regułę kierowania ruchu dla odpowiednich CIDR VPC.

Przykładowa tabela tras spoke VPC:

Trasa do huba VPC CIDR za pośrednictwem komunikacji VPC typu peering.

Przykładowa tabela tras huba VPC:

Trasa do spoke VPC CIDR za pośrednictwem komunikacji VPC typu peer

W powyższej konfiguracji spoke VPC powinny mieć dostęp do endpointu usługi AWS, ale nie mogą rozwiązać publicznego DNS endpointu usługi AWS. Jeśli używasz interfejsu wiersza polecenia AWS lub zestawu SDK ze środowiska spoke VPC, musisz użyć parametru –endpoint-url , aby zastąpić endpoint usługi AWS i użyć interfejsu DNS endpointu VPC, jak pokazano poniżej:

Kroki konfiguracji (część 2)

Jeśli chcesz rozwiązać endpoint usługi AWS natywnie z poziomu spoke VPC, musisz wykonać następujące dodatkowe kroki:

1. Wyłącz Private DNS dla endpointu interfejsu VPC w hubie VPC (jeśli jest włączony).

2. Utwórz Private Hosted Zone o tej samej nazwie, co endpoint usługi AWS (na przykład sqs.us-east-1.amazonaws.com) i utwórz rekord A (alias), aby wskazywać na interfejs DNS punktu końcowego VPC.

Rekord typu alias dla usługi Amazon Simple Queue Service wskazujący na DNS interface endpoint

3. Dołącz Private Hosted Zone do wszystkich spoke VPC.

Przy takiej konfiguracji powinno być możliwe rozwiązanie punktu końcowego usługi AWS bez dodatkowych parametrów (na przykład nie trzeba używać parametru –endpoint-url dla interfejsu wiersza polecenia AWS).

Rozważania projektowe

• Aby zwiększyć niezawodność projektu, endpointy VPC interfejsu powinny używać co najmniej dwóch stref dostępności (AZ - Availability Zones).

Ograniczenia, które należy wziąć pod uwagę w przypadku konfiguracji na dużą skalę

• 50 aktywnych połączeń VPC typu peering na VPC (ten limit można zwiększyć do 125).
• 100 powiązanych VPC na  Private Hosted Zone(możesz poprosić o zwiększenie tego limitu).
• 50 endpointów interfejsu VPC na VPC (możesz poprosić o zwiększenie tego limitu).
• Przepustowość 10 Gb/s na ENI punktu końcowego VPC, chociaż może to wzrosnąć.

Cleanup

Pamiętaj, aby wyczyścić utworzone zasoby, aby uniknąć opłat na koncie.

• Zakończ instancje EC2 w spoke VPC uruchomionych w tej konfiguracji.
• Usuń endpoint interfejsu w środowisku VPC usług współużytkowanych (hub).
• Usuń wszystkie połączenia VPC typu peering.
• Usuń Route 53 Private Hosted Zone.
• Usuń utworzony zasób usługi AWS (na przykład Amazon Simple Queue Service).

Podsumowanie

W tym poście na blogu pokazaliśmy, jak model hub-and-spoke może być używany do scentralizowania dostępu do endpointu VPC interfejsu w celu uzyskania prywatnego dostępu do punktów końcowych usług AWS ze spoke VPC. Pomaga to zabezpieczyć dostęp i obniżyć koszt wielu endpointów interfejsu. W przypadku zaawansowanych przypadków użycia, w których konieczne jest również uzyskanie dostępu do endpointów interfejsu z sieci lokalnej, można zaimplementować podobne rozwiązanie przy użyciu usługi AWS Transit Gateway i Amazon Route 53. W tym celu zapoznaj się z stroną Integrating AWS Transit Gateway with AWS PrivateLink and Amazon Route 53 Resolver.

źródło:AWS