CloudFront + Cross-Account VPC Origins — Multi-Account Architecture bez bólu

Wprowadzenie

CloudFront cross-account VPC origins — temat, który pojawił się jakiś czas temu, ale mało kto go używa. Szkoda, bo to naprawdę fajne rozwiązanie dla organizacji z wieloma kontami AWS.

Dzisiaj pokażę Ci konkretny case: jak postawić jeden CloudFront distribution, który obsługuje wiele prywatnych API Gateway z różnych kont.

Brzmi dobrze? To lecimy.

Problem — jak było wcześniej?

Masz firmę z kilkoma zespołami, każdy ma swoje konto AWS i własne prywatne API Gateway. Chcesz to wszystko udostępnić przez CloudFront.

Opcje? Nie było ich dużo:

Zwinąć wszystko na jedno konto — ale wtedy tracisz izolację, safety, i własność zespołów
Oddzielny CloudFront per zespół — każdy płaci osobno, overkill dla małych API

Obie opcje są… powiedzmy — suboptimal.

Rozwiązanie — Cross-Account VPC Origins

Wejdźmy do sedna. Z nowym podejściem:

Każdy zespół tworzy VPC origin — wskazuje na wewnętrzny ALB
ALB stoi przed prywatnym API Gateway — bo CloudFront VPC origins obsługują tylko ALB, NLB lub EC2 (nie API Gateway bezpośrednio)
Jeden CloudFront distribution — path-based routing do różnych origins
Route 53 alias records — każdy subdomain wskazuje na ten sam CloudFront

Proste, czyste, elegant.

Architektura — jak to wygląda?

┌─────────────────────────────────────────────────────────────┐
│                        CloudFront                            │
│                   (jedna dystrybucja)                       │
│                 *.twojafirma.com → /api-a/*                 │
└─────────────────────────────┬───────────────────────────────┘
                              │
         ┌────────────────────┼────────────────────┐
         │                    │                    │
         ▼                    ▼                    ▼
    ┌─────────┐          ┌─────────┐          ┌─────────┐
    │  ALB A  │          │  ALB B  │          │  ALB C  │
    │ Account │          │ Account │          │ Account │
    │    1    │          │    2    │          │    3    │
    └────┬────┘          └────┬────┘          └────┬────┘
         │                    │                    │
         ▼                    ▼                    ▼
    ┌─────────┐          ┌─────────┐          ┌─────────┐
    │API GW A │          │API GW B │          │API GW C │
    │ Private │          │ Private │          │ Private │
    └─────────┘          └─────────┘          └─────────┘

Podział odpowiedzialności — kto co robi?

Newsletter AWS

Tutoriale, case study, nowości z chmury · co tydzień · po polsku

🔒 Zero spamu · wypis jednym kliknięciem

To jest kluczowe — architektura musi być czytelna dla zespołów:

Komponent	Kto odpowiada?
API Gateway (prywatne)	Zespół developerski
ALB (wewnętrzny)	Zespół developerski
VPC Origin	Zespół developerski
CloudFront Distribution	Networking team
Route 53	Networking team
Wildcard certyfikat	Networking team

Każdy zespół ma swoje — i nikt nie musi prosić nikogo o zmiany.

Ograniczenia — WAŻNE

Zanim rzucisz się do implementacji, sprawdź dwie rzeczy:

WebSockets — NIE działa z VPC origins
gRPC — NIE działa z VPC origins

Jeśli Twoje API używa któregoś z tych protokołów — musisz szukać innego rozwiązania (np. ApiGateway V2 z websockets, albo bezpośrednie połączenie przez VPC peering).

Podsumowanie

Cross-account VPC origins to:

✅ Jeden CloudFront zamiast wielu
✅ Czysty podział odpowiedzialności między zespołami
✅ Path-based routing do różnych API
✅ Oszczędność (nie płacisz za osobne dystrybucje)
❌ Bez WebSockets i gRPC

Jeśli masz multi-account i prywatne API — warto rozważyć. Szczególnie jeśli:

Zespoły potrzebują autonomii
Chcesz unified endpoint dla klientów
Liczysz koszty i nie chcesz przepłacać za osobne dystrybucje

Pytanie do Ciebie: ile masz dziś oddzielnych CloudFront distributions dla różnych środowisk/kont? Daj znać w komentarzu!

Chcesz więcej takich architektonicznych breakdownów? Daj lajka, subscribe, i zostaw komentarz — to mnie motywuje do dalszej roboty.

#AWS #CloudFront #APIGateway #MultiAccount #Architecture #DevOps