Microsoft AZ-900: Architektura Azure i infrastruktura globalna — Przewodnik do nauki

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Część Microsoft Azure AZ-900 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Globalna architektura Azure została zaprojektowana w celu dostarczania odpornych, wydajnych i zgodnych z przepisami usług chmurowych na dużą skalę. Zrozumienie fizycznego układu geografii, regionów i stref dostępności, a także logicznej hierarchii grup zarządzania, subskrypcji, grup zasobów i zasobów, jest podstawą niezawodnego projektowania i ładu korporacyjnego. Płaszczyzna sterowania zapewniana przez Azure Resource Manager, w połączeniu z szablonami deklaratywnymi, umożliwia spójne, powtarzalne wdrożenia zgodne z polityką organizacyjną i wymaganiami bezpieczeństwa. Decyzje projektowe w tym obszarze bezpośrednio wpływają na docelowe wskaźniki dostępności, zobowiązania dotyczące rezydencji danych oraz doświadczenie użytkowników na całym świecie. Wybór odpowiedniego modelu redundancji, obliczanie złożonych umów SLA oraz dobór globalnych usług routingu, takich jak Azure Front Door, Traffic Manager i Azure CDN, są kluczowe dla osiągnięcia celów ciągłości biznesowej, zgodności i wydajności.

Geografie, Regiony, Strefy Dostępności i Pary Regionów

Geografie Azure to zdefiniowane zbiory regionów, które zachowują granice rezydencji danych i zgodności z przepisami. Przykłady obejmują Stany Zjednoczone, Europę, Wielką Brytanię, Australię i Kanadę, a także suwerenne chmury (sovereign clouds) o odrębnych modelach zgodności i łączności. Obciążenia robocze, które muszą pozostać w danej jurysdykcji, powinny być wdrażane w regionach należących do docelowej geografii, aby zapewnić zgodność z regulacjami i rezydencję danych. Region to zbiór centrów danych wdrożonych w obrębie granic zdefiniowanych przez opóźnienie (latency-defined perimeter) i połączonych za pomocą dedykowanej sieci o niskim opóźnieniu. Nie wszystkie usługi i funkcje są dostępne w każdym regionie, dlatego dostępność zasobów i funkcji należy zweryfikować na wczesnym etapie planowania. Regiony obsługujące Strefy Dostępności (Availability Zones) zapewniają co najmniej trzy fizycznie oddzielne strefy centrów danych z niezależnym zasilaniem, chłodzeniem i siecią. Usługi redundantne strefowo (ZRS) oraz architektura rozproszona na wiele stref chronią przed awariami na poziomie centrum danych, zachowując jednocześnie dostęp o niskim opóźnieniu w obrębie regionu. Każdy region Azure jest sparowany z innym regionem w tej samej geografii, tworząc parę regionów (np. North Europe z West Europe, East US z West US). Pary regionów umożliwiają priorytetowe odzyskiwanie po rozległych awariach, rozłożone w czasie aktualizacje platformy oraz replikację danych dla niektórych usług. Opcje georedundancji w Azure Storage (GRS/GZRS) replikują dane asynchronicznie do sparowanego regionu; gdy wymagany jest dostęp do odczytu w regionie pomocniczym, należy użyć RA-GRS lub RA-GZRS, aby zezwolić na odczyty z pomocniczego punktu końcowego podczas awarii lub planowanego przełączenia awaryjnego. W przypadku obciążeń o znaczeniu krytycznym, wymagających zarówno wysokiej dostępności wewnątrz regionu, jak i odzyskiwania po awarii między regionami, należy połączyć redundancję strefową z replikacją do pary regionów. Równoważenie opóźnień, odporności i zgodności prowadzi do powszechnego wzorca: wdrażanie aktywnych obciążeń w strefach w regionie podstawowym i ochrona przed katastrofami regionalnymi poprzez replikację danych i zapewnienie ścieżek przełączania awaryjnego do sparowanego regionu. Należy regularnie weryfikować procedury przełączania awaryjnego (runbooks) oraz zachowanie routingu DNS lub front-endu, aby upewnić się, że cele odzyskiwania są spełnione.

• Geografia
  • Zakres: Granica obejmująca wiele regionów
  • Kluczowa korzyść: Rezydencja danych i zgodność z przepisami
  • Typowe użycie: Zgodność z regulacjami (np. dane w UE)
• Region
  • Zakres: Pojedynczy obszar metropolitalny
  • Kluczowa korzyść: Dostęp do usług z niskim opóźnieniem
  • Typowe użycie: Podstawowa lokalizacja wdrożenia
• Strefa Dostępności
  • Zakres: Odrębne centra danych w obrębie regionu
  • Kluczowa korzyść: Izolacja awarii na poziomie centrum danych
  • Typowe użycie: Wysoka dostępność wewnątrz regionu
• Para Regionów
  • Zakres: Dwa regiony w tej samej geografii
  • Kluczowa korzyść: Skoordynowane odzyskiwanie i aktualizacje
  • Typowe użycie: Odzyskiwanie po awarii między regionami

Organizacja i ład zasobów: Grupy zarządzania, subskrypcje, grupy zasobów i zasoby

Hierarchia zarządzania w Azure umożliwia kontrolę nad politykami, dostępem i kosztami na dużą skalę. Grupy zarządzania znajdują się powyżej subskrypcji i pozwalają na centralne stosowanie Azure Policy oraz kontroli dostępu opartej na rolach (RBAC), z dziedziczeniem kaskadowym do podrzędnych grup zarządzania i subskrypcji. Jest to właściwa konstrukcja do segmentacji według działów firmy, poziomów środowisk (produkcyjne, nieprodukcyjne) lub granic regulacyjnych, przy jednoczesnym zachowaniu jednolitych zasad ochronnych. Subskrypcje stanowią granicę administracyjną, rozliczeniową i limitów (quota). Dobrze nadają się do izolowania kosztów i dostępu dla jednostek biznesowych, środowisk lub aplikacji. Używaj spójnego projektu subskrypcji, aby oddzielić środowiska produkcyjne od nieprodukcyjnych oraz aby wymuszać limity i budżety. W przypadku organizacji z wieloma działami i zdecentralizowaną administracją, przypisz każdemu działowi jedną lub więcej subskrypcji i umieść je w dedykowanych dla działu grupach zarządzania, aby zapewnić czyste dziedziczenie polityk i RBAC. Grupy zasobów to logiczne kontenery na zasoby, które mają wspólny cykl życia. Umożliwiają atomowe wdrożenia, spójne tagowanie oraz operacje na cyklu życia, takie jak usuwanie czy blokowanie. Grupuj zasoby, które są wdrażane, aktualizowane i wycofywane razem, na przykład warstwę webową i jej komponenty monitorujące. Używaj tagów do obsługi chargeback/showback, określania właściciela, środowiska i atrybutów zgodności dla zasobów i grup. Blokady (ReadOnly, CanNotDelete) dodają ochronę przed przypadkowym usunięciem na poziomie zasobu lub grupy. Zasoby to wdrożone instancje usług (maszyny wirtualne, plany App Service, konta magazynu). Zakresy RBAC (grupa zarządzania, subskrypcja, grupa zasobów, zasób) pozwalają na nadawanie dostępu z najmniejszymi uprawnieniami dokładnie tam, gdzie jest to potrzebne. W przypadku wdrożeń obejmujących wiele działów, utrzymuj jednego tenanta Microsoft Entra ID, chyba że istnieje silny wymóg zgodności lub autonomii dla wielu tenantów; subskrypcje i grupy zarządzania zazwyczaj zapewniają wystarczającą separację przy znacznie mniejszym obciążeniu administracyjnym.

• Grupa zarządzania
  • Główny cel: Ład w całej organizacji
  • Stosowane mechanizmy kontroli: RBAC, Policy, Blueprints (przez Policy + szablony)
  • Typowe wzorce: Segmentacja według działów/regulacji
• Subskrypcja
  • Główny cel: Granica rozliczeniowa i limitów
  • Stosowane mechanizmy kontroli: Budżety, RBAC, Policy
  • Typowe wzorce: Izolacja per jednostka biznesowa lub per środowisko
• Grupa zasobów
  • Główny cel: Granica cyklu życia
  • Stosowane mechanizmy kontroli: Blokady, Tagi, RBAC
  • Typowe wzorce: Per aplikacja lub jednostka obciążenia
• Zasób
  • Główny cel: Instancja usługi
  • Stosowane mechanizmy kontroli: RBAC na poziomie instancji, Tagi
  • Typowe wzorce: Pojedyncze komponenty usługi

Azure Resource Manager i szablony

Azure Resource Manager (ARM) to płaszczyzna sterowania służąca do wdrażania, aktualizowania i usuwania zasobów Azure za pomocą spójnego API i modelu opartego na rolach. ARM zapewnia operacje idempotentne, zarządzanie zależnościami, tagowanie i egzekwowanie polityk w momencie wdrożenia, co pozwala na osadzenie ładu platformy w każdej zmianie. Deklaratywne szablony ARM opisują pożądany stan środowiska w formacie JSON i obsługują parametry, zmienne, warunki oraz modułowe szablony połączone. Umożliwiają one powtarzalne, wersjonowane wdrożenia w różnych środowiskach i subskrypcjach. Aby usprawnić proces tworzenia, Bicep oferuje zwięzłą składnię, która transpiluje się do szablonów ARM, zachowując ten sam silnik wdrożeniowy i korzyści. Przechowuj szablony w kontroli wersji, pakuj je jako specyfikacje szablonów (template specs) w celu udostępniania i integruj je z potokami CI/CD, aby zapewnić audytowalne zmiany w infrastrukturze bez dryfu konfiguracji. Wartości wrażliwe, takie jak hasła administratora czy parametry połączenia, nigdy nie powinny być osadzane w szablonach. Używaj parametrów typu secureString/secureObject z odwołaniami do Key Vault, aby ARM pobierał sekrety w czasie wdrożenia bez ujawniania ich w logach. Połącz szablony z tożsamościami zarządzanymi, aby wyeliminować zakodowane na stałe poświadczenia w automatyzacji. Takie podejście zmniejsza ryzyko, zachowując jednocześnie pełną automatyzację dla wdrożeń na dużą skalę, obejmujących wiele subskrypcji.

• Wdrożenia idempotentne
  • Wsparcie ARM/Szablonów: Tak
  • Rezultat: Bezpieczne, powtarzalne zmiany
• Egzekwowanie polityk przy wdrożeniu
  • Wsparcie ARM/Szablonów: Tak
  • Rezultat: Zasady ochronne wbudowane w potoki
• Kompozycja modułowa
  • Wsparcie ARM/Szablonów: Szablony połączone / moduły Bicep
  • Rezultat: Ponowne wykorzystanie i standaryzacja
• Obsługa sekretów
  • Wsparcie ARM/Szablonów: Odwołania do Key Vault
  • Rezultat: Brak sekretów w kodzie i logach

Dostępność, umowy SLA, złożone umowy SLA i cykl życia usługi

Azure publikuje umowy o gwarantowanym poziomie świadczenia usług (SLA) z gwarancją finansową dla usług ogólnie dostępnych (GA). W przypadku maszyn wirtualnych dostępność zależy od topologii wdrożenia: pojedyncza maszyna wirtualna z magazynem Premium SSD ma SLA na poziomie 99,9%; dwie lub więcej maszyn wirtualnych w zestawie dostępności (availability set) ma SLA na poziomie 99,95%; a dwie lub więcej maszyn wirtualnych wdrożonych w różnych strefach dostępności (availability zones) osiąga SLA na poziomie 99,99%. Usługi platformowe (na przykład Azure SQL Database lub App Service) mają własne umowy SLA, które mogą się różnić w zależności od warstwy lub opcji redundancji. Dostosuj architekturę do docelowego SLA, wybierając odpowiedni model redundancji i warstwy usług. Gdy rozwiązanie zależy od wielu usług, złożone SLA (composite SLA) jest iloczynem poszczególnych umów SLA, jeśli wszystkie komponenty są wymagane do działania aplikacji. Na przykład, jeśli aplikacja internetowa (99,95%) zależy od bazy danych (99,99%), złożona dostępność wynosi około 0,9995 × 0,9999 = 99,94%. Zwiększenie redundancji na dowolnej warstwie — na przykład poprzez wdrożenie w różnych strefach, dodanie wielu instancji za modułem równoważenia obciążenia (load balancer) lub użycie georedundantnych magazynów danych — poprawia efektywną dostępność. I odwrotnie, dodawanie zależności szeregowych obniża złożone SLA i powinno być uzasadnione wyraźną wartością funkcjonalną. Status cyklu życia usługi wpływa na gwarancje niezawodności. Funkcje w publicznej wersji zapoznawczej (public preview) są oferowane w celu zebrania opinii i mogą być ograniczone do niektórych regionów lub mieć braki funkcjonalne; zazwyczaj nie są objęte umową SLA i nie są zalecane dla ścieżek krytycznych w środowisku produkcyjnym. Funkcje ogólnie dostępne (GA) są gotowe do użytku produkcyjnego i objęte umową SLA. Należy śledzić plany rozwoju (roadmapy) i harmonogramy wdrażania w regionach, aby uniknąć przypadkowego polegania na funkcjach w wersji zapoznawczej w projektach produkcyjnych, zwłaszcza w środowiskach wrażliwych na zgodność z przepisami. Cele odzyskiwania po awarii, takie jak RPO i RTO, uzupełniają umowy SLA i ukierunkowują wybory projektowe, takie jak replikacja między strefami lub regionami, częstotliwość tworzenia kopii zapasowych i orkiestracja przełączania awaryjnego (failover). Regularnie weryfikuj procedury przełączania awaryjnego, aby upewnić się, że zmierzona wydajność odzyskiwania jest zgodna z celami biznesowymi oraz że zależności DNS, certyfikaty i tożsamości również są odzyskiwane zgodnie z oczekiwaniami.

• Pojedyncza maszyna wirtualna (Premium SSD)
  • Orientacyjne SLA: 99,9%
  • Uwagi: Do użytku w przypadku obciążeń niekrytycznych lub aplikacji odpornych na awarie
• 2+ maszyny wirtualne w zestawie dostępności (Availability Set)
  • Orientacyjne SLA: 99,95%
  • Uwagi: Chroni przed awariami szafy serwerowej/domeny awarii
• 2+ maszyny wirtualne w różnych strefach dostępności (Availability Zones)
  • Orientacyjne SLA: 99,99%
  • Uwagi: Chroni przed awariami na poziomie centrum danych
• Funkcja w publicznej wersji zapoznawczej (Public Preview)
  • Orientacyjne SLA: Brak SLA z gwarancją finansową
  • Uwagi: Do oceny; unikać na ścieżkach krytycznych
• Funkcja ogólnie dostępna (GA) (zależna od warstwy usługi)
  • Orientacyjne SLA: Objęta umową SLA
  • Uwagi: Sprawdź umowy SLA specyficzne dla warstwy i regionu

Globalny routing i dostarczanie treści: Azure Front Door, Traffic Manager i Azure CDN

Globalne doświadczenie użytkownika zależy od inteligentnego routingu, bliskości treści i szybkiego przełączania awaryjnego (failover). Azure Front Door to globalny, działający w warstwie 7 odwrotny serwer proxy (reverse proxy) typu anycast, z wbudowanym Web Application Firewall (WAF), terminacją TLS, routingiem opartym na adresie URL/ścieżce, koligacją sesji (session affinity) i sondami kondycji z krawędzi sieci. Przyspiesza dynamiczną treść za pomocą optymalizacji protokołów i split-TCP oraz zapewnia niemal natychmiastowe przełączanie awaryjne między źródłami (origins). Front Door jest idealny dla wieloregionowych aplikacji internetowych i interfejsów API działających w trybie aktywny-aktywny lub aktywny-pasywny, gdzie potrzebna jest zarówno wydajność, jak i scentralizowane zabezpieczenia na krawędzi sieci. Azure Traffic Manager to usługa dystrybucji ruchu oparta na DNS, która kieruje klientów do najlepszego punktu końcowego przy użyciu zasad takich jak priorytet, waga, wydajność (opóźnienie), lokalizacja geograficzna, podsieć lub multivalue. Ponieważ działa na poziomie DNS, obsługuje punkty końcowe inne niż HTTP (np. usługi TCP) i scenariusze hybrydowe, ale szybkość przełączania awaryjnego jest ograniczona przez DNS TTL i buforowanie po stronie klienta. Traffic Manager nie pośredniczy w ruchu ani nie przyspiesza treści; po prostu odpowiada na zapytania DNS, wskazując wybrany punkt końcowy. Azure CDN buforuje treści statyczne w krawędziowych punktach obecności (points of presence), aby zmniejszyć opóźnienia i odciążyć źródła. Jest dobrze dostosowany do dużych zasobów statycznych, takich jak obrazy, filmy, skrypty i pliki do pobrania. Chociaż CDN zmniejsza liczbę przejść w obie strony (round trips) dla treści, które można buforować, nie jest to świadomy kondycji globalny load balancer dla dynamicznych źródeł; należy go łączyć z Front Door lub Traffic Manager w celu przełączania awaryjnego między wieloma źródłami lub dla logiki dynamicznego routingu. W wielu architekturach umieszcza się CDN do buforowania zasobów statycznych oraz Front Door do obsługi ruchu dynamicznego i zabezpieczeń przed tą samą aplikacją.

• Azure Front Door (Std/Prm)
  • Warstwa/Mechanizm: Proxy anycast w warstwie 7
  • Główne przypadki użycia: Globalne równoważenie obciążenia, bezpieczeństwo na krawędzi, akceleracja
  • Metody routingu: Priorytet, waga; reguły oparte na ścieżce/hoście
  • Sondowanie kondycji: Sondy z krawędziowych punktów obecności (POP)
  • Szybkość przełączania awaryjnego: Sekundy (niemal natychmiast)
  • Akceleracja dynamiczna: Tak
  • Buforowanie statyczne: Tak (oparte na regułach)
  • Dostępność WAF: Tak (zintegrowany)
  • Typowy wzorzec: Front Door przed wieloregionowymi aplikacjami internetowymi/API
• Azure Traffic Manager
  • Warstwa/Mechanizm: Zasady oparte na DNS
  • Główne przypadki użycia: Routing DNS między regionami; punkty końcowe inne niż HTTP
  • Metody routingu: Priorytet, waga, wydajność, lokalizacja geograficzna, podsieć, multivalue
  • Sondowanie kondycji: Globalne sondowanie punktów końcowych
  • Szybkość przełączania awaryjnego: Ograniczona przez TTL (dziesiątki sekund do minut)
  • Akceleracja dynamiczna: Nie
  • Buforowanie statyczne: Nie
  • Dostępność WAF: Nie dotyczy
  • Typowy wzorzec: Sterowanie DNS dla usług HTTP i innych niż HTTP
• Azure CDN
  • Warstwa/Mechanizm: Sieć buforowania na krawędzi (edge caching)
  • Główne przypadki użycia: Odciążanie źródeł z treści statycznych i redukcja opóźnień
  • Metody routingu: Nie dotyczy (reguły buforowania)
  • Sondowanie kondycji: Nie dotyczy (opcjonalne przełączanie awaryjne grupy źródeł)
  • Szybkość przełączania awaryjnego: Nie dotyczy (oparte na buforze)
  • Akceleracja dynamiczna: Nie (poza buforem)
  • Buforowanie statyczne: Tak
  • Dostępność WAF: Przez Front Door Premium lub oddzielny WAF
  • Typowy wzorzec: CDN dla zasobów + Front Door/Traffic Manager dla źródeł

Problem praktyczny: Projektowanie wysoce dostępnej, zgodnej z przepisami i globalnie wydajnej platformy internetowej dla IronPeak Manufacturing

Scenariusz: Firma IronPeak Manufacturing, działająca w Europie i Ameryce Północnej, konsoliduje swoje portale dla klientów i partnerów na platformie Azure. Platforma musi spełniać dostępność na poziomie 99,99% dla warstwy internetowej, przechowywać dane klientów z UE na terenie UE, zapewniać szybkie przełączanie awaryjne (failover) między regionami oraz szybkie ładowanie stron na całym świecie. Zespół chce w pełni zautomatyzowanych wdrożeń bez przechowywania poświadczeń w postaci zwykłego tekstu w kodzie lub logach.

Wyzwanie: Osiągnięcie wysokiej dostępności wewnątrz regionu i odtwarzania po awarii (disaster recovery) między regionami z zachowaniem rezydencji danych w UE, globalne przyspieszenie i przełączanie awaryjne dla ruchu dynamicznego oraz powtarzalne, bezpieczne wdrożenia w różnych subskrypcjach.

Zalecane podejście:

1. Wybierz geografię Europa i wdróż główne obciążenie w regionie ze Strefami Dostępności (Availability Zones) (na przykład West Europe), używając dwóch lub więcej instancji VM scale set lub App Service rozproszonych w strefach.
2. Włącz odtwarzanie po awarii między regionami do regionu sparowanego (North Europe), korzystając z natywnej replikacji usług: użyj RA-GZRS dla Storage i replikacji geograficznej dla baz danych, jeśli jest dostępna; skonfiguruj zautomatyzowane runbooki do przełączania awaryjnego.
3. Użyj Azure Front Door Standard/Premium jako punktu wejściowego dla aplikacji w celu globalnego terminowania HTTPS, WAF, sond kondycji na brzegu sieci (edge), przełączania awaryjnego opartego na priorytetach między West Europe (główny) a North Europe (zapasowy) oraz reguł routingu opartego na ścieżkach.
4. Buforuj zasoby statyczne (obrazy, skrypty, pliki do pobrania) za pomocą Azure CDN zintegrowanego z tymi samymi źródłami (origins), aby zmniejszyć opóźnienia i odciążyć ruch; zweryfikuj reguły buforowania i wartości TTL.
5. Zdefiniuj grupy zarządzania (management groups) dla oddziałów w UE i Ameryce Północnej; umieść pod nimi subskrypcje produkcyjne i nieprodukcyjne, stosując Azure Policy do zapewnienia rezydencji danych, tagowania i dozwolonych lokalizacji.
6. Wdróż szablony ARM/Bicep przechowywane w kontroli wersji i opublikowane jako specyfikacje szablonów (template specs); sparametryzuj regiony, jednostki SKU i skalowanie; odwołuj się do sekretów z Azure Key Vault przy użyciu tożsamości zarządzanych (managed identities) podczas wdrożeń.
7. Ustal umowy SLA i testuj dostępność złożoną: dwie instancje rozproszone w strefach za usługą Front Door mają na celu osiągnięcie 99,99% dla warstwy aplikacji; kwartalnie weryfikuj kompleksowe ćwiczenia przełączania awaryjnego, DNS, certyfikaty i zależności tożsamości.
8. Zainstrumentuj platformę za pomocą Application Insights i Azure Monitor; skonfiguruj sondy kondycji i alerty w usłudze Front Door; dostrajaj zasady automatycznego skalowania i buforowania na podstawie danych telemetrycznych.

Uzasadnienie dla Azure: Ten projekt utrzymuje dane z UE w geografii Europa, zapewniając jednocześnie izolację błędów wewnątrz regionu za pomocą Stref Dostępności (Availability Zones) oraz odtwarzanie po awarii między regionami do regionu sparowanego. Azure Front Door zapewnia globalne przyspieszenie i przełączanie awaryjne dla ruchu dynamicznego z uwzględnieniem kondycji usług, podczas gdy Azure CDN odciąża ruch do treści statycznych w celu zwiększenia wydajności. Szablony ARM/Bicep z odwołaniami do Key Vault zapewniają powtarzalne i bezpieczne wdrożenia w różnych subskrypcjach i regionach. Wybrane topologie są zgodne z opublikowanymi umowami SLA, aby osiągnąć cel 99,99% dla warstwy internetowej, a zasady (policy) na poziomach grup zarządzania i subskrypcji wymuszają ład korporacyjny przy minimalnym obciążeniu operacyjnym.

← Koncepcje chmury · Wszystkie domeny · Usługi obliczeniowe i aplikacyjne →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Microsoft →