Strefa lądowania AWS dla RISE with SAP
RISE dostajecie jako gotowe środowisko, do którego trzeba się podłączyć. Ta jedna czynność decyduje o tym, czy system będzie dostępny z Waszej sieci, czy przez pierwszy miesiąc będziecie pisać zgłoszenia. Rozkładamy architekturę na części.
Umowa RISE with SAP obejmuje środowisko, w którym stoi system. Nie obejmuje sieci, przez którą ten system rozmawia z resztą Waszego świata, z serwerownią, z systemami otoczenia, z hurtownią danych, z narzędziami analitycznymi. Ta sieć jest po Waszej stronie granicy i to Wy musicie ją zbudować.
AWS nazywa ją strefą lądowania i zaleca ją wprost jako sposób podłączenia się do RISE. Poniżej rozkładamy jej architekturę na części i pokazujemy, co realnie trzeba zrobić przed startem.
Dlaczego to nie jest jedno łącze
Najprostszy obraz, jaki krąży po prezentacjach handlowych, wygląda tak: jest RISE, jest Wasza serwerownia, między nimi łącze. Gdyby SAP był jedynym systemem w firmie, ten obraz by wystarczył.
W praktyce krajobraz SAP dogaduje się z kilkunastoma rzeczami naraz: systemami w serwerowni, rozwiązaniami SaaS, innymi chmurami, hurtownią danych, narzędziami raportowymi. Jeśli każde z tych połączeń budujecie osobno, po roku macie plątaninę, której nikt nie umie narysować, a przy audycie trzeba.
Strefa lądowania odwraca kolejność: najpierw powstaje szkielet sieci i reguły, potem podłącza się do niego kolejne rzeczy. RISE jest jedną z nich, nie wyjątkiem.
Architektura
Rzecz, którą najłatwiej przeoczyć na tym schemacie: konto RISE nie należy do Waszej organizacji AWS. Prowadzi je SAP Enterprise Cloud Services. Nie zalogujecie się do niego, nie zobaczycie jego rachunku, nie zmienicie w nim reguły sieciowej. Widzicie je wyłącznie od strony sieci, jako coś, co podłączyliście do swojego Transit Gateway.
To ma konsekwencję praktyczną: wszystko, co chcecie kontrolować, musi stać po Waszej stronie. Zapora, logi ruchu, rozdzielenie środowisk, punkty wyjścia do internetu.
Konta i po co jest każde z nich
Strefa lądowania to przede wszystkim podział na konta. Nie dlatego, że tak wypada, tylko dlatego, że konto AWS jest najtwardszą granicą, jaką ta platforma oferuje, mocniejszą niż jakakolwiek reguła uprawnień.
| Konto | Do czego służy |
|---|---|
| Zarządzające | Organizations, jednostki organizacyjne, polityki kontroli usług |
| Sieciowe | Transit Gateway, Direct Connect, VPN, zapora sieciowa |
| Logów | CloudTrail i Config ze wszystkich kont, tylko do zapisu |
| Bezpieczeństwa | GuardDuty, Security Hub, narzędzia przeglądu |
| Wspólnych usług | DNS, katalog, rzeczy używane przez wszystkich |
| Obciążeń | Osobne dla produkcji, rozwoju, analityki, GenAI |
Konto logów zasługuje na osobne zdanie. Jego sens polega na tym, że nikt z kont roboczych nie może skasować własnych śladów. Jeśli logi leżą w tym samym koncie co system, przy poważnym incydencie mogą zniknąć razem z nim.
Transit Gateway zamiast plątaniny
Bez węzła każde połączenie jest osobną parą: konto produkcyjne z serwerownią, konto testowe z serwerownią, konto produkcyjne z RISE, hurtownia z RISE. Przy pięciu punktach to już dziesięć par, a każda ma własną tablicę tras.
Transit Gateway zamienia to w gwiazdę. Każde konto łączy się raz, z węzłem, a o tym, kto z kim może rozmawiać, decydują tablice tras, jedno miejsce zamiast dziesięciu.
Dla RISE to szczególnie ważne, bo SAP podłącza się właśnie do tego węzła. Gdy później dołożycie kolejne konto, RISE zobaczy je bez żadnej zmiany po stronie SAP.
Dwie drogi: Control Tower albo Landing Zone Accelerator
AWS daje dwa sposoby zbudowania tego samego.
AWS Control Tower to droga przez konsolę. Klikacie, dostajecie strukturę kont, zestaw reguł i podstawowe zabezpieczenia. Sprawdza się, gdy chcecie ruszyć szybko i nie macie egzotycznych wymagań sieciowych.
Landing Zone Accelerator to ta sama rzecz opisana w plikach konfiguracyjnych. Rozszerza Control Tower o infrastrukturę jako kod, więc całość da się odtworzyć, przejrzeć w repozytorium i przenieść do drugiego regionu.
Wybór między nimi sprowadza się do jednego pytania: czy macie zespół, który utrzyma pliki konfiguracyjne. Jeśli tak, LZA zwraca się przy pierwszej większej zmianie. Jeśli nie, Control Tower wystarczy i lepiej nie budować czegoś, czego potem nikt nie ruszy.
Sami pracujemy infrastrukturą jako kodem, więc rekomendujemy LZA, ale nie w sytuacji, gdy oznaczałoby to, że jedyna osoba rozumiejąca konfigurację odejdzie z firmy za pół roku.
Co trzeba zrobić, po kolei
Pełna lista kroków w dokumentacji AWS ma czternaście pozycji. W praktyce dzielą się na cztery grupy:
- Ustalenie wymagań. Bezpieczeństwo, zgodność, sposób pracy. Na tym etapie przeglądacie kwestionariusz łączności od zespołu SAP ECS, to on określa, czego SAP potrzebuje od Was.
- Projekt. Liczba kont, podział sieci, adresacja, zabezpieczenia. Adresację warto przemyśleć dłużej, niż się chce: kolizja zakresów z serwerownią albo z RISE naprawia się bardzo drogo.
- Budowa. Control Tower, konta wspólne, sieć, Transit Gateway, zapora, uprawnienia, logi i monitoring.
- Podłączenie RISE. Przekazujecie SAP dane swojego Transit Gateway, akceptujecie zaproszenie do powiązania, konfigurujecie trasy i testujecie, w tym przełączenie na łącze zapasowe.
Ten ostatni punkt jest jedynym, który zależy od drugiej strony. Wszystko przed nim możecie zrobić sami, we własnym tempie.
Kiedy zacząć
AWS podaje wprost: sześć do ośmiu tygodni przed planowanym startem.
Ta liczba nie bierze się z ostrożności. Direct Connect ma czas realizacji liczony w tygodniach i zależy od operatora, nie od Was. Kwestionariusz łączności wraca z pytaniami. Adresacja wymaga uzgodnień z ludźmi, którzy zwykle są zajęci czym innym. Testy przełączenia na łącze zapasowe robi się raz i wtedy właśnie wychodzi, że trasa wraca nie tą drogą, co powinna.
Jeśli data startu jest ustalona, a strefy lądowania jeszcze nie ma, to jest pierwsza rzecz do zrobienia, przed wszystkim innym.
Czego ta architektura nie załatwia
Strefa lądowania rozwiązuje łączność i ład. Nie rozwiązuje niczego powyżej warstwy sieci.
Po Waszej stronie granicy nadal zostają: uprawnienia i rozdzielenie kompetencji w SAP, integracje z systemami otoczenia, procedury zmian, kopie tego, czego umowa nie obejmuje, oraz codzienna obsługa tego wszystkiego. To jest osobny zakres i osobna rozmowa, ale warto wiedzieć, że sieć jest początkiem listy, nie jej końcem.
Jedna uwaga, jeśli patrzycie na AWS Managed Services
Dokumentacja wielokontowej strefy lądowania AMS jest dobrym źródłem wzorców architektonicznych i warto ją przeczytać. Ma jednak notę, którą łatwo przeoczyć: AWS kończy wsparcie dla AMS Advanced 30 czerwca 2027 roku.
Wzorce zostają aktualne. Ale jeśli ktoś proponuje Wam oparcie modelu operacyjnego na tej usłudze, to jest pytanie, które trzeba zadać przed podpisem.
Źródła
- Connecting to RISE using a shared AWS Landing Zone, dokumentacja SAP on AWS
- MALZ network architecture, architektura sieci wielokontowej strefy lądowania AMS
- Guidance for Building an Enterprise-Ready Network Foundation for RISE with SAP on AWS, zwalidowane wzorce architektury
- Landing Zone Accelerator on AWS, rozwiązanie i pliki konfiguracyjne
Diagram powyżej jest naszym opracowaniem na podstawie architektury opisanej w powyższych dokumentach.