Jedną z usług zaprezentowanych podczas re:Invent 2018 był AWS Resource Access Manager. Ta nowość przeszła trochę niezauważona, a według mnie jest to usługa, która w znacznym stopniu może zmienić sposób w jaki projektujemy rozwiązania w chmurze Amazonu.

Mnóstwo firm pracuje w AWS na wielu kontach. Ułatwia to wiele rzeczy, a korzystając z AWS Organizations mamy wszystko pod kontrolą, możemy także, poprzez skonsolidowany billing dostawać tylko jedną fakturę i oszczędzać na usługach.

Do tej pory zasoby tworzone na poszczególnych kontach były od siebie zupełnie odseparowane. Nadal domyślnie tak jest. I jest to jedna z zalet posiadania wielu kont. Można odseparować od siebie na przykład zasoby poszczególnych aplikacji, czy też działów w naszej firmie. Ten fakt implikuje wiele decyzji architektonicznych.

AWS Resource Access Manager

Zaprezentowany na re:Invent 2018 AWS Resource Access Manager umożliwia „udostępnianie” zasobów utworzonych na jednym koncie dla innego konta.

W chwili gdy to piszę, usług, które możemy udostępniać pomiędzy kontami nie ma zbyt wiele,

ale AWS obiecuje, że będzie ich co raz więcej.

Już w tej chwili możemy udostępniać np. subnety. A to otwiera wielkie możliwości. Możemy na przykład utworzyć naszą infrastrukturę sieciową na jednym koncie, a same zasoby umieszczać już w poszczególnych subnetach korzystając z innych kont. Możemy w tym momencie mieć na przykład osobne konta dla sieci, baz danych czy też maszyn wirtualnych. Dlatego, tak jak napisałem na początku usługa ta może zmienić sposób w jaki projektujemy nasze rozwiązania w chmurze AWS.

Pobawiłem się kilka dni temu sharowaniem podsieci. Jest ograniczenie. Nie możemy współdzielić defaultowych VPC. Ale to chyba zrozumiałe. Nasunęły mi się jednak trzy pytania. I znalazłem na nie odpowiedzi.

Kto co może?

Pracując z Resource Access Manager posługujemy się dwoma pojęciami: owner i principal. Owner to właściciel zasobów. Principal to konto, dla którego zasoby zostały udostępnione. Principal może z współdzielonych zasobów korzystać, ale nie może ich zmieniać. Na przykład ma dostęp do tablic routingu i NACls, ale nie może edytować w nich wpisów. Logiczne. Jest ktoś odpowiedzialny za sieci i ktoś, kto z nich korzysta.

Kto płaci?

Załóżmy, że mamy sieci utworzone na jednym koncie. Udostępniamy je i na innym koncie tworzymy w tych sieciach maszyny wirtualne. Co z kosztami? Otóż za same maszyny płaci konto principal. Ale już na przykład za ruch wychodzący, jakieś NAT Gateway, z których korzystają maszyny wirtualne na koncie principal płaci owner. Nie ma to oczywiście znaczenia w przypadku korzystania z Consolidateg Billing for Organizations.

Czy można usunąć?

Co w przypadku, gdy właściciel podsieci chce przestać się nimi dzielić? Może je usunąć ze współdzielonych zasobów. Nie ma problemu. Ale co z samymi zasobami?

1. Zasoby umieszczone w sharowanych wcześniej podsieciach będą nadal pracowały. Nie będzie można oczywiście tworzyć w nich nowych zasobów.
2. Podsieci, które były wcześniej współdzielone, a w których nadal pracują jakieś zasoby utworzone na kontach principal nie można usunąć. Żeby je usunąć, należy wcześniej usunąć z nich wszystko co zostało wewnątrz nich utworzone.

Co dalej?

Naprawdę każdemu, kto pracuje z AWS polecam pobawienie się usługą. Na blogu AWS Jeff Barr opisał jak w kilku krokach współdzielić zasoby pomiędzy kontami. Lekcja na temat usługi już za moment w kursie AWS – Zrozum Wszystkie Usługi.

Napiszę to jeszcze raz. Ta usługa może naprawdę zmienić sposób, w jaki będziemy implementowali nasze rozwiązania w chmurze AWS.