Amazon ANS-C01: DNS i Route 53 — Przewodnik do nauki
Część AWS Advanced Networking Specialty ANS-C01 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.
Podstawowa koncepcja
DNS jest spoiwem łączącym przyjazne dla człowieka nazwy z rozproszonymi punktami końcowymi, ale w AWS staje się aktywną płaszczyzną sterowania dla routingu opartego na opóźnieniach, przełączania awaryjnego uwzględniającego stan kondycji oraz prywatnego rozwiązywania nazw w środowiskach wielokontowych. Amazon Route 53 obsługuje autorytatywny publiczny DNS poprzez publiczne strefy hostowane (public hosted zones) oraz prywatny DNS do rozwiązywania nazw w zakresie VPC poprzez prywatne strefy hostowane (private hosted zones). Prywatne strefy hostowane są powiązane z jednym lub wieloma VPC i zwracają odpowiedzi tylko na zapytania pochodzące z tych VPC lub za pośrednictwem punktów końcowych wejściowych (inbound endpoints) Route 53 Resolver. Takie zachowanie typu split-horizon — czyli udzielanie różnych odpowiedzi na to samo zapytanie w zależności od jego źródła — pozwala na udostępnienie publicznego punktu końcowego dla klientów internetowych, jednocześnie rozwiązując tę samą nazwę na prywatne adresy IP wewnątrz VPC.
Route 53 integruje również z DNS logikę podejmowania decyzji o routingu oraz aktywne mechanizmy sprawdzania kondycji (health checks). Zasady routingu (routing policies) obejmują Simple, Weighted, Latency, Failover (primary/secondary), Geolocation, Multi-Value Answer oraz Traffic Flow (geoproximity i złożone przepływy). Mechanizmy sprawdzania kondycji tworzone za pomocą
undefined
pozwalają Route 53 na usuwanie punktów końcowych o złej kondycji z odpowiedzi DNS lub na sterowanie zestawami rekordów failover; są one konfigurowane za pomocą pól
undefined
, takich jak Type, FullyQualifiedDomainName, IPAddress, Port, ResourcePath, RequestInterval i FailureThreshold. Ponieważ DNS jest buforowany przez resolwery i klientów, wartość TTL w Route 53 oraz częste odpytywanie w ramach sprawdzania kondycji (minimum 10 sekund przy określonych ustawieniach) muszą być zrównoważone z zachowaniem propagacji DNS w kontekście przełączania awaryjnego i zmian w routingu ważonym.
Kluczowe usługi i konfiguracja
Udostępniając zasoby AWS, należy używać rekordów typu Alias, aby kierować DNS bezpośrednio na zasoby AWS tam, gdzie jest to wspierane, unikając dodatkowych przeskoków (hops) lub rekordów CNAME. Rekordy Alias używają
undefined
, który odwołuje się do ID strefy hostowanej zasobu AWS oraz jego nazwy DNS (na przykład Elastic Load Balancer, niestandardowa domena API Gateway, dystrybucja CloudFront lub punkt końcowy witryny S3). Tworzenie lub zmiana rekordów odbywa się za pomocą API
undefined
; w przypadku zautomatyzowanych przepływów pracy należy używać
undefined
z akcjami UPSERT/DELETE oraz
undefined
do identyfikacji zasad routingu. W celu skonfigurowania przełączania awaryjnego (failover) tworzy się dwa rekordy o tej samej nazwie z atrybutem Failover ustawionym na PRIMARY i SECONDARY, przy czym każdy z nich odwołuje się do mechanizmu sprawdzania kondycji poprzez
undefined
, który tworzy się za pomocą
undefined
.
Do rozwiązywania nazw w środowiskach hybrydowych i między kontami służy Route 53 Resolver, który dostarcza punkty końcowe wejściowe (inbound) i wyjściowe (outbound) tworzone za pomocą
undefined
. Punkt końcowy wejściowy pozwala resolwerom on-premises na przekazywanie zapytań do VPC (co jest przydatne do rozwiązywania nazw z prywatnych stref hostowanych), podczas gdy punkt końcowy wyjściowy pozwala zasobom w VPC na przekazywanie zapytań do serwerów DNS on-premises lub innych resolwerów. Reguły resolvera (tworzone za pomocą
undefined
) pozwalają na przekazywanie zapytań dla określonych domen na wskazane adresy IP, a reguły te przypisuje się do VPC za pomocą
undefined
. W architekturze z centralnym DNS można tworzyć reguły przekazywania (forwarding rules) na koncie centralnym i używać
undefined
do powiązania ich z VPC na innych kontach, opcjonalnie wykorzystując AWS Resource Access Manager (RAM) i
undefined
do kontrolowania tych powiązań.
Route 53 Resolver DNS Firewall zapewnia filtrowanie i logowanie zapytań na podstawie nazw domen. Listy domen tworzy się za pomocą
undefined
, grupy reguł za pomocą
undefined
, a następnie przypisuje się je do VPC za pomocą
undefined
w celu egzekwowania zasad. Reguły zapory mogą blokować (BLOCK), zezwalać (ALLOW) lub nadpisywać (OVERWRITE) odpowiedzi, a wyniki ich oceny można logować do CloudWatch Logs lub S3. Do zarządzania i stosowania reguł z priorytetami należy używać
undefined
i
undefined
, zwłaszcza w celu ograniczenia eksfiltracji danych przez DNS lub blokowania złośliwych domen dla zasobów podłączonych do VPC.
Wzorce projektowe i kompromisy
Dla wysoko dostępnych, globalnie rozproszonych usług, należy stosować routing oparty na opóźnieniach (latency-based) lub geolokalizacji (geo-based), aby kierować klientów do najbliższego sprawnego punktu końcowego, w połączeniu z mechanizmami sprawdzania kondycji w celu usuwania niesprawnych punktów końcowych w regionach. Routing oparty na opóźnieniach zależy od regionalnych tabel opóźnień Route 53 i jest odpowiedni dla architektur multi-region active-active; routing typu failover jest lepszy w przypadku odtwarzania po awarii w modelu active-passive, gdzie tylko jeden region powinien w danym momencie przyjmować ruch. Routing ważony (weighted routing) wspiera stopniowe przenoszenie ruchu (wdrożenia typu blue-green lub canary) poprzez przypisywanie wag do rekordów i zmienianie ich za pomocą
undefined
. Routing typu multi-value answer może zwracać wiele adresów IP w celu rozkładania obciążenia po stronie klienta i wymaga mechanizmów sprawdzania kondycji, aby zapewnić, że zwracane są tylko adresy IP sprawnych zasobów.
Prywatne strefy hostowane i punkty końcowe resolvera to kanoniczne wzorce dla rozwiązywania nazw w środowiskach obejmujących wiele kont i wiele VPC. Dla wielu jednostek biznesowych, centralne VPC usług współdzielonych, w którym znajdują się prywatne strefy hostowane lub punkty końcowe resolvera, upraszcza zarządzanie: należy utworzyć prywatną strefę hostowaną i użyć
undefined
do podłączenia VPC poszczególnych usług, lub uruchomić punkty końcowe wejściowe/wyjściowe Route 53 Resolver i reguły przekazywania, aby każde konto zachowało izolację swojego VPC, polegając jednocześnie na centralnej polityce DNS. Kompromis polega na tym, że prywatne strefy hostowane powiązane z wieloma VPC komplikują zarządzanie IAM i kontrolę zmian, a powiązania między kontami wymagają kroku autoryzacji. Przekazywanie zapytań przez resolver wprowadza centralny narzut operacyjny, ale dobrze się skaluje, ponieważ nie trzeba bezpośrednio wiązać każdego VPC z każdą strefą hostowaną; zamiast tego przypisuje się reguły resolvera.
Przy wymuszaniu ścisłych ścieżek dostępu — na przykład wymagając, aby ruch przepływał wyłącznie przez Global Accelerator — należy zaprojektować grupy bezpieczeństwa i kontrole sieciowe tak, aby odpowiadały konfiguracji DNS. Route 53 może wskazywać na Global Accelerator poprzez tworzenie rekordów A ze statycznymi adresami IP akceleratora lub używanie rekordów CNAME do domeny zarządzanej przez akcelerator, ale egzekwowanie zasad odbywa się na poziomie grupy bezpieczeństwa ALB i sieciowych list ACL. Grupa bezpieczeństwa ALB powinna zezwalać na ruch przychodzący tylko ze statycznych adresów IP Global Accelerator; Global Accelerator gwarantuje, że te statyczne adresy IP będą źródłem ruchu przychodzącego, więc ograniczenie ruchu przychodzącego pozwala zachować wymóg dostępu wyłącznie przez akcelerator.
Częste pułapki i kryteria decyzyjne
Typową pułapką jest zakładanie, że kontrole kondycji Route 53 natychmiast usuwają punkty końcowe; buforowanie DNS (TTL) i zachowanie resolvera klienta oznaczają, że przełączanie awaryjne nie jest natychmiastowe. Dla krytycznych nazw używanych do przełączania awaryjnego utrzymuj niskie wartości TTL, ale pamiętaj, że niższe TTL zwiększają liczbę zapytań i koszty. Innym częstym błędem jest duplikowanie nazw w publicznych i prywatnych strefach hostowanych bez zrozumienia skojarzeń z VPC: prywatna strefa hostowana o tej samej nazwie co publiczna strefa hostowana przesłoni publiczne odpowiedzi na zapytania pochodzące ze skojarzonych VPC, co jest zazwyczaj pożądane w konfiguracji split-horizon, ale może być zaskakujące, jeśli nie jest udokumentowane.
Starannie wybieraj między rekordami Alias i CNAME: rekordy Alias dla ELB i CloudFront są preferowane, ponieważ pozwalają uniknąć dodatkowych zapytań DNS i są obsługiwane przez logikę propagacji zmian Route 53, ale są one powiązane z ID stref hostowanych zasobów AWS i nie mogą być używane dla dowolnych zewnętrznych punktów końcowych. Projektując międzykontowe DNS, preferuj reguły i punkty końcowe resolvera zamiast bezpośredniego kojarzenia wielu VPC z jedną prywatną strefą hostowaną, gdy istotne są skalowalność lub granice administracyjne; reguły resolvera dają bardziej szczegółową kontrolę i są łatwiejsze do audytowania za pomocą CloudTrail.
Praktyczny problem: Scenariusz użycia
Firma: NimbusPay — wyzwanie: Zapewnienie bezpiecznych usług gRPC o niskim opóźnieniu przez TLS z wzajemnym uwierzytelnianiem (mTLS) do backendu na EKS, wymuszenie dostępu do front-endu webowego wyłącznie przez Global Accelerator oraz umożliwienie wielu VPC z różnych kont i jednostek biznesowych korzystania ze współdzielonych usług danych z centralnym sterowaniem DNS.
- Dla usługi gRPC wymagającej szyfrowania end-to-end TLS z wzajemnym uwierzytelnianiem i obsługą tysięcy jednoczesnych połączeń, wdróż Network Load Balancer (NLB) z nasłuchiwaniem TCP na porcie 443, używając typu celu
ip, aby adresy IP podów były rejestrowane bezpośrednio. Skonfiguruj adnotacje kontrolera AWS Load Balancer
undefined
i ustaw protokół grupy docelowej na TCP; nie terminuj TLS na NLB (brak nasłuchiwania TLS), aby wzajemne uwierzytelnianie TLS było przekazywane do kontenerów w podach, gdzie egzekwowane są certyfikaty serwera i weryfikacja certyfikatów klienta. Użyj rekordów A (typu Alias) w Route 53 wskazujących na NLB poprzez ChangeResourceRecordSets; preferuj niskie wartości TTL tylko jeśli potrzebujesz szybkiego przełączania awaryjnego, w przeciwnym razie zachowaj konserwatywną wartość TTL dla stabilności DNS.
Aby zapewnić, że ALB front-endu webowego akceptuje ruch tylko z Global Accelerator, utwórz akcelerator i przypisz jego dwa statyczne adresy IP do NimbusPay. Skonfiguruj publiczne rekordy w Route 53, aby publiczna nazwa rozwiązywała się na adresy IP akceleratora (rekordy A ze statycznymi adresami IP). W grupie zabezpieczeń ALB ustaw reguły wejściowe tak, aby zezwalały na ruch tylko z tych statycznych adresów IP, i zamknij dostęp z 0.0.0.0/0. Wymusza to, że tylko ruch przychodzący ze statycznych adresów IP akceleratora może dotrzeć do ALB. Użyj CloudWatch Logs i VPC Flow Logs, aby weryfikować przychodzące źródłowe adresy IP i audytować, czy ruch spoza akceleratora jest blokowany.
Dla wielu VPC z różnych kont i jednostek biznesowych, które potrzebują dostępu do usług współdzielonych, wdróż centralną parę punktów końcowych (wychodzący/przychodzący) Route 53 Resolver na koncie usług współdzielonych za pomocą CreateResolverEndpoint i umieść je w prywatnych podsieciach. Utwórz reguły przekierowujące (CreateResolverRule) na koncie współdzielonym dla domen usług współdzielonych i udostępnij te reguły za pomocą AWS RAM lub użyj PutResolverRulePolicy, aby zezwolić na skojarzenia. Każda jednostka biznesowa kojarzy regułę resolvera ze swoimi VPC (AssociateResolverRule), co umożliwia rozwiązywanie nazw bez bezpośredniego dołączania wszystkich VPC do prywatnych stref hostowanych. Dla wrażliwych kontroli, dołącz grupy reguł Route 53 Resolver DNS Firewall (CreateFirewallRuleGroup i AssociateFirewallRuleGroup) do współdzielonego VPC, aby blokować niepożądaną eksfiltrację danych lub wymuszać stosowanie białych list domen. Uzasadnienie: Przekazywanie TCP (passthrough) przez NLB zachowuje wzajemne uwierzytelnianie TLS i skaluje się do wielu jednoczesnych połączeń, ograniczenie ruchu przychodzącego do ALB do statycznych adresów IP Global Accelerator wymusza dostęp wyłącznie przez akcelerator, a punkty końcowe resolvera z centralnie zarządzanymi regułami skalują rozwiązywanie nazw DNS między kontami, zachowując jednocześnie granice IAM i możliwości audytu dla każdego konta.
← Transit Gateway i topologia sieci · Wszystkie domeny · Równoważenie obciążenia i zarządzanie ruchem →
Przećwicz te pytania → · Testy na czas na ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Zdaj egzamin →