Dlaczego wiele kont AWS?

Gdy zaczynasz naukę, masz jedno konto. Ale w realnym świecie firmy używają dziesiątek, a nawet setek kont AWS. Dlaczego? Bo jedno konto dla wszystkiego to jak trzymanie dokumentów osobistych, firmowych i podatkowych w jednej szufladzie.

Argumenty za wieloma kontami

  • Izolacja środowisk - dev, staging, production w osobnych kontach. Błąd developera nie uszkodzi produkcji.
  • Izolacja kosztów - łatwo zobaczyć, ile kosztuje każdy projekt/zespół
  • Limity bezpieczeństwa - nawet jeśli ktoś przejmie konto dev, nie ma dostępu do produkcji
  • Compliance - dane wrażliwe w osobnym koncie z surowszymi regułami
  • Service Quotas - AWS ma limity per konto (np. max 5 VPC). Osobne konta = osobne limity.

AWS Organizations

AWS Organizations to usługa, która pozwala zarządzać wieloma kontami AWS z jednego miejsca. Tworzy hierarchiczną strukturę:

Organizacja ma strukturę drzewa:

  • Root - korzeń (najwyższy poziom)
  • OU (Organizational Unit) - „foldery" do grupowania kont
  • Accounts - poszczególne konta AWS

Przykładowa struktura:

  • Root
    • OU: Production → Konto: prod-app, Konto: prod-db
    • OU: Development → Konto: dev-team-a, Konto: dev-team-b
    • OU: Security → Konto: audit-logs, Konto: security-tools

Service Control Policies (SCP) to polityki na poziomie organizacji. Definiują maksymalne uprawnienia dla kont w OU.

Kluczowe cechy:

  • SCP NIE nadaje uprawnień (tylko ogranicza)
  • SCP na OU działa na wszystkie konta w tym OU
  • SCP nie wpływa na Management Account (konto główne)
  • SCP + IAM Policy muszą OBA pozwalać na akcję

Przykład SCP: „Zabroń wszystkim kontom w OU Development uruchamiania instancji p4d.24xlarge (najdroższa instancja GPU)".

Consolidated Billing - wszystkie konta w organizacji mają jedną zbiorczą fakturę. Zalety:

  • Jeden rachunek zamiast wielu
  • Volume discounts - użycie ze wszystkich kont się sumuje, więc szybciej osiągasz progi rabatowe
  • Shared Reserved Instances - RI zakupione w jednym koncie mogą być używane przez inne konta

Konto zarządzające (management account) płaci za wszystko, ale każde konto widzi swoje koszty.

⚠️ EXAM ALERT
Na egzaminie SCP to gorący temat. Zapamiętaj: SCP ogranicza (nie nadaje) uprawnienia. Jeśli SCP na OU zabrania EC2, to nawet admin w tym koncie z polityką AdministratorAccess nie uruchomi EC2. Wyjątek: Management Account nie podlega SCP.

Jak działa SCP + IAM razem?

Żeby user mógł wykonać akcję, OBA muszą pozwalać:

SCPIAM PolicyWynik
Allow EC2Allow EC2✅ Działa
Allow EC2Deny EC2❌ Zablokowane (IAM Deny)
Deny EC2Allow EC2❌ Zablokowane (SCP Deny)
Brak Allow EC2Allow EC2❌ Zablokowane (SCP implicit deny)
🏢 Scenariusz: Kontrola kosztów w firmie

Firma ma 3 zespoły developerskie. CTO chce, żeby:

  • Developerzy mogli uruchamiać instancje EC2, ale tylko t3.micro i t3.small
  • Nikt poza zespołem security nie mógł tworzyć IAM userów
  • Żadne konto nie mogło działać poza regionem eu-central-1 (GDPR)

Rozwiązanie:

  • OU „Development" z SCP blokującym drogie instancje i ograniczającym region
  • OU „Security" z SCP pozwalającym na pełny dostęp do IAM
  • Każdy zespół dev ma osobne konto w OU Development

Nawet jeśli developer zdobędzie AdminAccess w swoim koncie, SCP na OU nie pozwoli mu uruchomić p4d.24xlarge ani działać poza Frankfurtem.

AWS Control Tower

Ustawianie Organizations, OU, SCP ręcznie to sporo pracy. AWS Control Tower automatyzuje cały proces. Ustawia „landing zone" z gotowymi best practices:

  • Automatyczne tworzenie kont z odpowiednią konfiguracją
  • Gotowe guardrails (reguły bezpieczeństwa)
  • Centralne logowanie (CloudTrail, Config)
  • Dashboard do monitorowania compliance
💡 Ciekawostka
Amazon sam używa tysięcy kont AWS wewnętrznie. Każdy zespół ma swoje konto (a często kilka: dev, staging, prod). To pozwala na pełną autonomię zespołów przy zachowaniu kontroli na poziomie organizacji.

AWS rekomenduje kilka standardowych kont w każdej organizacji:

  • Management Account - tylko do zarządzania organizacją. Zero workloadów!
  • Security/Audit Account - centralne logi, GuardDuty, Security Hub
  • Shared Services Account - Active Directory, DNS, CI/CD pipeline
  • Log Archive Account - centralne przechowywanie logów z CloudTrail
  • Sandbox Account - eksperymentowanie bez ryzyka dla produkcji

Ta struktura to rekomendacja AWS Well-Architected Framework i jest bazą dla Control Tower.

🧠 Podsumowanie
  • Wiele kont AWS = izolacja, bezpieczeństwo, kontrola kosztów
  • AWS Organizations = zarządzanie wieloma kontami
  • OU (Organizational Units) = grupowanie kont w „foldery"
  • SCP = ograniczenia na poziomie organizacji (Deny, nie Allow)
  • Consolidated Billing = jeden rachunek + volume discounts
  • Control Tower = automatyzacja setup multi-account
🧪 Sprawdź się

SCP zabrania uruchamiania EC2 w OU „Development". Admin w koncie dev ma polityke IAM AdministratorAccess. Czy uruchomi EC2?

A Tak, bo AdministratorAccess daje pełne uprawnienia
B Nie, bo SCP ogranicza nawet adminów
C Tak, ale tylko instancje t2.micro
SCP definiuje maksymalne uprawnienia. Nawet AdministratorAccess nie przebije SCP Deny. Wyjątek to Management Account, które nie podlega SCP.

Jaka jest główna zaleta Consolidated Billing w AWS Organizations?

A Volume discounts dzięki sumowaniu użycia ze wszystkich kont
B Darmowe korzystanie z AWS
C Automatyczne skalowanie zasobów
Consolidated Billing sumuje użycie ze wszystkich kont, co pozwala szybciej osiągnąć progi rabatowe (volume discounts). Np. jeśli masz 10 kont z S3, łączne użycie storage kwalifikuje się do niższych cen.

Które konto w AWS Organizations NIE podlega SCP?

A Konto w OU Production
B Konto z rolą Admin
C Management Account (konto zarządzające)
Management Account to jedyne konto w organizacji, które nie podlega SCP. Dlatego nie powinno się w nim uruchamiać żadnych workloadów, tylko zarządzać organizacją.