Skip to content
malak.cloud
  • Kontakt
  • O mnie
  • Search Icon

malak.cloud

Cloud Native na co dzień

AWS Resource Access Manager

AWS Resource Access Manager

26 stycznia 2019

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.

 


AWS, Security
AWS

Post navigation

PREVIOUS
AWS Lambda Layers. Nowość na re:Invent 2018
NEXT
Nie samą pracą człowiek żyje
Comments are closed.
Cześć. Nazywam się Przemek Malak. Dzięki za wizytę. Mam nadzieję, że to o czym piszę Cię zainteresowało. Jeżeli chcesz ze mną pogadać, najłatwiej będzie przez LinkedIn.

Losowe wpisy

  • Jak utworzyć Lambda Layer w Pythonie

    9 czerwca 2022
  • Step Functions i obsługa błędów

    22 października 2022
  • Czym jest dla mnie Cloud Native

    20 listopada 2020
  • CI/CD za pomocą AWS Copilot

    2 grudnia 2021
  • AWS Lambda i idempotentność

    21 marca 2022
  • Apps
  • AWS
  • CloudNative
  • Cookbook
  • Data
  • DEV
  • GCP
  • IoT
  • Istio
  • k8s
  • Security
  • Social
  • GitHub
  • LinkedIn
© 2023   All Rights Reserved.