S3: punkt końcowy bramy lub interfejsu dla dostępu z sieci lokalnej

Dwa typy punktów końcowych S3 wyglądają na wymienne w przeglądzie projektu i zachowują się zupełnie inaczej, gdy klient znajdzie się poza siedzibą. Punkt końcowy bramy to integracja z tabelą tras wewnątrz VPC, więc żądanie z VPN siedziby nigdy do niego nie trafia jako prywatne miejsce docelowe. Punkt końcowy interfejsu umieszcza prywatne adresy na interfejsach sieciowych, do których ścieżka hybrydowa naprawdę może dotrzeć. Wszystko, co następuje, zależy od tego, który z tych dwóch wybrano.

Decyduj według wejścia sieciowego, a nie nazwy usługi

Zacznij od miejsca, w którym powstaje ruch, bo to jest pytanie, na które odpowiada typ punktu końcowego. Obciążenie w obsługiwanym kontekście VPC może korzystać z punktu końcowego bramy i nigdy nie potrzebuje własnego adresu prywatnego. Obciążenie w siedzibie potrzebuje prywatnego adresu, do którego może routować, i właśnie to zapewnia punkt końcowy interfejsu. Jeśli projekt miesza oba, oba typy punktów końcowych mogą współistnieć w jednym VPC, a to normalny układ, a nie duplikacja.

Mieszanie ich nie jest problemem. Problemem jest założenie, że jeden typ obejmuje drugi.

Sklasyfikuj klienta, zanim cokolwiek wybierzesz. Obszar roboczy wewnątrz VPC, kontener za bramą NAT i aplikacja w oddziale to trzy różne źródła, a tylko ostatnie wymusza wejście hybrydowe. Zapisz tę klasyfikację obok spisu punktów końcowych, aby następny recenzent widział, dlaczego każdy punkt końcowy istnieje.

Czego wymaga ścieżka interfejsu od początku do końca

Punkt końcowy interfejsu zapewnia osiągalność prywatnych adresów, a osiągalność to tylko jeden z czterech wymogów. Sieć lokalna potrzebuje trasy do tych adresów, strona VPC potrzebuje drogi powrotnej, grupa zabezpieczeń punktu końcowego musi dopuszczać zakres źródłowy, a każde urządzenie kontrolne pomiędzy musi zezwalać na przepływ. Trasa do dowolnej instancji w VPC nie dowodzi żadnego z tych czterech.

Pracuj od dalekiego końca wstecz. Potwierdź, że interfejsy sieciowe punktu końcowego istnieją w oczekiwanych podsieciach, a następnie potwierdź, że jego grupa zabezpieczeń dopuszcza rzeczywisty zakres lokalny, a nie symbol zastępczy. Potem sprawdź, czy tunel lub łącze przenosi drogę powrotną w tym samym kierunku. Kontrola to krok, który ludzie pomijają, bo urządzenie pośrednie zezwalające na połączenie wciąż może odrzucić większe ciało odpowiedzi, a to wygląda na problem przepustowości, a nie polityki.

Testuj najmniejszą dostępną dozwoloną operacją, a nie dużym pobieraniem. Awaria pojawia się szybciej i przy mniejszym ruchu do wyjaśnienia.

DNS podąża za źródłem zapytania, a nie za VPC

Istniejący punkt końcowy sam niczego nie przekierowuje. Aplikacja otrzymuje nazwę zwróconą przez swój resolver, a resolver odpowiada zgodnie z widokiem, który wolno mu widzieć. Instancja wewnątrz VPC i laptop w biurze zadają dwa różne pytania i oba mogą otrzymać poprawne, ale różne odpowiedzi. Sprawdzenie jednego i wyciągnięcie wniosku o drugim to droga od zaliczonego testu do nieudanego wdrożenia.

Czytaj prywatne ustawienie DNS punktu końcowego jako część projektu, a nie jako pole wyboru do włączenia po uruchomieniu.

Jeśli resolver w biurze ma widzieć widok VPC, ta ścieżka musi być zbudowana celowo, zwykle przez przychodzący punkt końcowy resolvera. Odpytuj z własnego kontekstu aplikacji i notuj, który resolver odpowiedział. Wynik zebrany na hoście bastionowym wewnątrz VPC opisuje widok bastionu i nic więcej.

Uprawnienie jest oddzielone od osiągalności

Osiągalny punkt końcowy zwraca błędy dla żądań, których podmiot nie ma prawa wykonać, a ten błąd oznacza, że system działa zgodnie z projektem. Polityka tożsamości, polityka bucketu i każda polityka punktu końcowego są oceniane w swoich własnych warstwach. Dostęp sieciowy nigdy nie przyznał uprawnienia.

Zaakceptuj projekt na podstawie dwóch wyników: nieszkodliwe autoryzowane wywołanie, które się udaje, oraz oczekiwana odmowa dla wykluczonej tożsamości lub bucketu.

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

Zapisz nazwę punktu końcowego, rozwiązywane miejsce docelowe i kontekst polityki obok każdego wyniku, bo jedna późniejsza zmiana DNS może unieważnić cały wniosek. Porównaj bieżący koszt i ciężar operacyjny obu typów punktów końcowych, zanim cokolwiek przygotujesz. Punkt końcowy interfejsu kupuje hybrydowe wejście prywatne, nie jest wymogiem uniwersalnym, a ścieżka bramy często pozostaje lepszą odpowiedzią dla obciążeń wewnątrz VPC. Wybór jest per klient i pozostaje do ponownego rozważenia.