Jesteś developerem z kilkuletnim doświadczeniem i zaczynasz odczuwać, że kodowanie przestaje Cię satysfakcjonować. Widzisz szerszą perspektywę – jak systemy powinny ze sobą współpracować, jak optymalizować koszty, jak projektować rozwiązania, które skalują się do milionów użytkowników. Zastanawiasz się: czy jestem gotowy na Cloud Architecta?
To pytanie zadaje sobie coraz więcej polskich developerów. Cloud computing przestał być technologią przyszłości – to standard dzisiejszego biznesu. Firmy masowo migrują do chmury publicznej (AWS, Azure, GCP), często do więcej niż jednej, a zapotrzebowanie na architektów chmurowych rośnie wraz z wydatkami na infrastrukturę.
Dla developerów to szczególnie atrakcyjna ścieżka kariery. Posiadasz już techniczne fundamenty – rozumiesz architekturę aplikacji, znasz design patterns, pracowałeś z bazami danych. Teraz potrzebujesz rozszerzyć perspektywę: z poziomu pojedynczej aplikacji na poziom całego ekosystemu infrastruktury, bezpieczeństwa, kosztów i strategii biznesowej.
W tym artykule otrzymasz konkretny plan przejścia z developera na Cloud Architecta w 12-18 miesięcy. Poznasz wymagane umiejętności, najlepsze certyfikaty, sposoby budowania doświadczenia architektonicznego oraz praktyczne wskazówki, jak wynegocjować zmianę roli w obecnej firmie lub znaleźć pierwszą pracę jako architekt.
Na skróty
- Czym różni się Cloud Architect od Developera i jakie są różnice w myśleniu?
- Networking, security, IaC, cost optimization – umiejętności, które musisz rozwinąć
- Które certyfikaty są kluczowe: AWS Solutions Architect Pro, Azure Solutions Architect Expert
- Plan 12-18 miesięcy: szczegółowa roadmapa przejścia
- Jak budować doświadczenie architektoniczne, jeszcze będąc developerem
- Zarobki Cloud Architect vs Developer – różnice i perspektywy finansowe
- Jak EITT wspiera transformację kariery
- FAQ: odpowiedzi na najczęstsze pytania o przejście na Cloud Architecta
Czym różni się Cloud Architect od Developera?
Fundamentalna różnica nie polega na tym, że architekt “koduje mniej” (choć to prawda), lecz na zmianie perspektywy i zakresu odpowiedzialności. Developer buduje funkcjonalności aplikacji, architekt projektuje fundamenty, na których te aplikacje działają.
Mentalność i sposób myślenia
Developer myśli: “Jak zaimplementować tę funkcję?” Cloud Architect myśli: “Czy ta funkcja powinna w ogóle istnieć w tej formie?”
Jako architekt odpowiadasz za pytania znacznie szersze:
- Jak system będzie się skalował przy 10x większym ruchu?
- Czy wybraliśmy odpowiedni trade-off między latencją a kosztem?
- Co się stanie, gdy region AWS padnie na 4 godziny?
- Czy ta architektura jest zgodna z polityką bezpieczeństwa firmy i regulacjami (RODO, NIS2)?
- Ile będzie nas to kosztować przy 1M użytkowników?
Przykład praktyczny: Developer: “Zbuduję API do przetwarzania zdjęć, użyję Python + Flask, wrzucę na EC2.” Cloud Architect: “Czy to workload synchroniczny czy asynchroniczny? Jeśli async, użyjmy Lambda + SQS + S3, będzie taniej i skaluje się automatycznie. Dodajmy CloudFront CDN dla redukcji latencji i DDoS protection. Potrzebujemy multi-region dla compliance RODO? Jak długo przechowujemy te obrazy i jakie lifecycle policies zastosować?”
Zakres odpowiedzialności
| Aspekt | Developer | Cloud Architect |
|---|---|---|
| Zakres wpływu | Pojedyncza aplikacja/mikroserwis | Cały ekosystem (infrastruktura, networking, security, koszt) |
| Horyzont czasowy | Sprint (2-4 tygodnie) | Kwartały/lata – long-term vision |
| Główni stakeholders | Product Owner, Tech Lead | CTO, CFO, Security Officer, compliance |
| Metryki sukcesu | Funkcjonalność działa, testy przechodzą | RTO/RPO spełnione, koszty w budżecie, zero incydentów security |
| Odpowiedzialność finansowa | Brak lub ograniczona | Bezpośrednia – cloud bill może wynieść miliony PLN rocznie |
| Decyzje techniczne | Wybór biblioteki, framework w ramach aplikacji | Wybór cloud providera, database engine, networking model, disaster recovery strategy |
Współpraca międzyfunkcyjna
Developer współpracuje głównie z innymi programistami i testerami. Cloud Architect to rola silnie międzyfunkcyjna:
- Z DevOps/SRE: Określanie strategii CI/CD, monitoring, observability
- Z Security: Projektowanie network segmentation, IAM policies, encryption at rest/in transit
- Z Finance/Procurement: Optymalizacja kosztów, negocjacje Enterprise Agreements z cloud providerami
- Z Legal/Compliance: Zapewnienie zgodności architektury z RODO, NIS2, branżowymi standardami (PCI-DSS, HIPAA)
- Z Business Leadership: Tłumaczenie wymogów biznesowych na architekturę techniczną
Architekt musi mówić językiem biznesu – potrafić wyjaśnić CTO, w jakim horyzoncie zwróci się migracja do serverless, a CFO, o ile inwestycja w multi-region podniesie dostępność usługi.
Umiejętności “miękkie” stają się krytyczne
Podczas gdy developer może się skupić głównie na hard skills (język programowania, algorytmy), architekt musi rozwinąć:
- Komunikację i prezentacje: Przedstawianie propozycji architektonicznych zarządowi, prowadzenie Architecture Decision Records (ADR)
- Mentoring: Podnoszenie kompetencji zespołów developerskich w zakresie cloud best practices
- Negocjacje: Balansowanie między potrzebami biznesu, ograniczeniami technicznymi i budżetem
- Strategiczne myślenie: Widzenie 2-3 lat do przodu, antycypowanie przyszłych wymagań skalowalności i zmian regulacyjnych Wniosek: Jeśli lubisz rozwiązywać złożone problemy systemowe, interesuje Cię nie tylko “jak”, ale także “dlaczego” i “po co”, a komunikacja i strategiczne myślenie nie są Ci obce – masz potencjał na Cloud Architecta.
Jakie umiejętności trzeba rozwinąć, aby zostać Cloud Architect?
Przejście z developera na Cloud Architecta wymaga systematycznego rozszerzenia kompetencji. Nie musisz być ekspertem we wszystkim od razu, ale potrzebujesz solidnych fundamentów w pięciu kluczowych obszarach:
1. Networking i connectivity w chmurze
Jako developer mogłeś unikać głębokiego zanurzenia się w sieci komputerowe – wystarczyło, że aplikacja słuchała na porcie 8080. Jako architekt networking to fundament wszystkiego. Co musisz opanować:
VPC (Virtual Private Cloud) i subnetting:
- Projektowanie CIDR blocks – jak prawidłowo podzielić przestrzeń IP (np. 10.0.0.0/16 vs 10.0.0.0/24)
- Public vs private subnets – kiedy stosować każdy typ
- Multi-tier architecture (public subnet dla load balancerów, private dla aplikacji, isolated dla baz danych)
- Peering między VPC i komunikacja cross-account
Routing i gateway:
- Internet Gateway, NAT Gateway, Transit Gateway – różnice i przypadki użycia
- Route tables i routing priorities
- VPN connections (site-to-site, client VPN)
- Direct Connect / ExpressRoute – dedykowane połączenia do on-premise
Load balancing i traffic management:
- Application Load Balancer (ALB) vs Network Load Balancer (NLB) vs Classic Load Balancer
- Health checks, target groups, listener rules
- Cross-zone load balancing
- Global load balancing dla multi-region
DNS i service discovery:
- Route 53 (AWS) / Azure DNS – routing policies (simple, weighted, latency, failover, geolocation)
- Private DNS zones dla internal services
- Service discovery dla microservices (AWS Cloud Map, Consul)
Przykład praktyczny: Projektujesz architekturę dla aplikacji e-commerce działającej w trzech availability zones. Musisz zaplanować:
- CIDR: 10.0.0.0/16 (65,536 adresów IP)
- 6 subnets (3 AZ × 2 tiers: public dla ALB, private dla aplikacji)
- NAT Gateway w każdej AZ dla high availability
- Transit Gateway łączący produkcję, staging i shared services VPC
- Routing policy latency-based dla użytkowników z różnych regionów Polski
Narzędzia do nauki: VPC Hands-on Labs (AWS Training), Azure Virtual Network Labs, narzędzia do wizualizacji (draw.io, Lucidchart z AWS/Azure stencils)
2. Security i compliance w środowisku cloud
Security to non-negotiable dla Cloud Architecta. Naruszenie bezpieczeństwa w chmurze może kosztować firmę miliony złotych i reputację. Co musisz opanować:
Identity and Access Management (IAM):
- Principle of Least Privilege – nadawanie minimalnych uprawnień
- Projektowanie IAM roles vs IAM users
- Service Control Policies (SCP) na poziomie AWS Organizations
- Federation (SAML, OIDC) – integracja z corporate identity providers (Azure AD, Okta)
- Cross-account access patterns
Encryption at rest i in transit:
- KMS (Key Management Service) – zarządzanie kluczami szyfrowania
- Encryption dla S3, EBS, RDS, DynamoDB
- TLS/SSL certificates – AWS Certificate Manager, Let’s Encrypt
- Secrets management – AWS Secrets Manager, Azure Key Vault, HashiCorp Vault
Network security:
- Security Groups vs Network ACLs (stateful vs stateless)
- Web Application Firewall (WAF) – ochrona przed OWASP Top 10
- DDoS protection – AWS Shield, Azure DDoS Protection
- VPC Flow Logs – analiza ruchu sieciowego
Compliance frameworks:
- RODO – data residency, right to erasure, data portability
- NIS2 – wymogi dla operatorów usług kluczowych
- ISO 27001, SOC 2 – kontrole bezpieczeństwa
- Industry-specific: PCI-DSS (finanse), HIPAA (healthcare)
Zero Trust Architecture:
- Mikrosegmentacja sieci
- Continuous verification
- Assume breach mindset
Przykład praktyczny: Projektujesz architekturę dla fintech’u przetwarzającego dane płatnicze (wymóg PCI-DSS):
- Izolacja cardholder data environment (CDE) w oddzielnym VPC
- Encryption at rest dla wszystkich danych (KMS z customer-managed keys)
- WAF z regułami blokującymi SQL injection i XSS
- VPC Flow Logs wysyłane do SIEM (Security Information and Event Management)
- Multi-factor authentication (MFA) obowiązkowe dla dostępu administracyjnego
- Regularne penetration testing i vulnerability scanning
- Audit logs w CloudTrail z immutable storage (S3 Object Lock)
Narzędzia do nauki: AWS Security Specialty certification path, Azure Security Engineer Associate, hands-on labs z IAM policies, CTF (Capture The Flag) challenges dla cloud security
3. Infrastructure as Code (IaC) i automatyzacja
Architekt nie konfiguruje infrastruktury ręcznie przez konsolę. Wszystko musi być replikowalne, versionowane i audytowalne – to wymaga IaC. Co musisz opanować:
IaC frameworks:
- Terraform (najpopularniejsze, multi-cloud)
- AWS CloudFormation /Azure Resource Manager (ARM) /Google Cloud Deployment Manager
- Pulumi (IaC w językach programowania: Python, TypeScript)
- CDK (Cloud Development Kit)– AWS/Azure CDK Kluczowe koncepcje IaC:
- State management (Terraform state file, remote backend w S3)
- Modules i reusability – jak strukturyzować kod IaC
- Drift detection – wykrywanie ręcznych zmian w infrastrukturze
- Plan → Apply → Destroy workflow
- Dependency management między zasobami
CI/CD dla infrastruktury:
- GitOps – infrastructure changes przez pull requesty
- Automatyczne testy IaC (linting, security scanning, cost estimation)
- Staged deployments (dev → staging → production)
- Rollback strategies
Configuration management:
- Ansible, Chef, Puppet – dla konfiguracji na poziomie OS/aplikacji
- Różnice między IaC (provisioning) a configuration management
Immutable infrastructure:
- Koncepcja “cattle vs pets” – infrastruktura jednorazowa, nie łatana
- Golden images (AMI, custom VM images)
- Container-based infrastructure (ECS, EKS, AKS)
Przykład praktyczny: Piszesz moduł Terraform dla standardowej aplikacji webowej:
- VPC z subnets (public + private w 3 AZ)
- Application Load Balancer
- Auto Scaling Group z Launch Template
- RDS Multi-AZ dla bazy danych
- S3 bucket dla statycznych assetów + CloudFront distribution
- IAM roles dla EC2 instances
- CloudWatch alarms dla kluczowych metryk
- Wszystko parametryzowalne (variables.tf) i testowalne
Narzędzia do nauki: HashiCorp Learn (Terraform tutorials), AWS CloudFormation workshops, Terraform Associate certification, hands-on projekty na GitHubie
4. Cost optimization i FinOps
Developer rzadko widzi cloud bill. Architekt odpowiada za każdą złotówkę wydaną w chmurze. FinOps (Financial Operations) to rosnąca dyscyplina w cloud computing. Co musisz opanować:
Cloud pricing models – poziomy oszczędności poniżej podaje AWS na swoich stronach cenowych (aws.amazon.com):
- On-Demand – pay-as-you-go, najdroższe, pełna elastyczność
- Reserved Instances / Reserved Capacity – zobowiązanie 1-3 lata, oszczędności do 72%
- Savings Plans – elastyczniejsze od RI, oszczędności do 66%
- Spot Instances – niewykorzystana pojemność AWS, oszczędności do 90%, ale może być reclaimed
- Różnice między providerami (AWS vs Azure vs GCP)
Cost allocation i tagging:
- Resource tagging strategy (projekt, zespół, środowisko, cost center)
- Cost allocation reports
- Chargeback i showback – rozliczanie kosztów na działy
Right-sizing i waste elimination:
- Identyfikacja overprovisioned resources (instancje z CPU 5%)
- Downscaling lub zmiana instance types
- Usuwanie zombie resources (unused EBS volumes, unattached Elastic IPs, old snapshots)
- Lifecycle policies dla S3 (transition do cheaper storage classes, expiration)
Architectural patterns dla cost optimization:
- Serverless – płacisz za execution time, nie za idle capacity (Lambda, DynamoDB on-demand)
- Auto Scaling – dopasowanie capacity do rzeczywistego obciążenia
- Multi-tier storage – hot data w SSD, cold data w Glacier
- Content delivery – CDN zamiast direct origin requests
- Database optimization– read replicas, caching (Redis, Memcached), query optimization Monitoring i alerting:
- AWS Cost Explorer, Azure Cost Management, GCP Billing Reports
- Budgety i alerty przy przekroczeniu progów
- Anomaly detection – nietypowe wzrosty kosztów
- Narzędzia third-party: CloudHealth, Cloudability, Apptio
Przykład praktyczny: Audytujesz koszty aplikacji e-commerce:
- Obecny bill: 50,000 PLN/miesiąc
- Znalezione optymalizacje:
- EC2: zamiana t3.large (sempre on-demand) na t3.medium z Savings Plan → -15,000 PLN/mies.
- RDS: downsize z db.m5.xlarge do db.m5.large (overprovisioned) → -5,000 PLN/mies.
- S3: lifecycle policy dla logów (transition do Glacier po 90 dniach) → -2,000 PLN/mies.
- Unused EBS volumes i snapshots → -3,000 PLN/mies.
- CloudFront z cache dla static assets (redukcja origin requests) → -5,000 PLN/mies.
- Razem: 30,000 PLN oszczędności miesięcznie w tym przykładzie
Narzędzia do nauki: FinOps Foundation training, AWS Cost Optimization workshops, hands-on audyty kosztów w demo accounts
5. Cloud-native design patterns i best practices
Architekt musi znać proven patterns dla typowych problemów architektonicznych. Nie wymyślasz koła na nowo – stosujesz sprawdzone rozwiązania. Co musisz opanować:
Well-Architected Frameworks:
- AWS Well-Architected Framework (5 filarów: operational excellence, security, reliability, performance efficiency, cost optimization)
- Azure Well-Architected Framework
- Google Cloud Architecture Framework
Reliability patterns:
- Multi-AZ deployments – redundancja w availability zones
- Multi-region architectures – disaster recovery i latency optimization
- Circuit breaker – ochrona przed kaskadowymi awariami
- Retry with exponential backoff – graceful degradation
- Health checks i auto-recovery
Scalability patterns:
- Horizontal scaling (scale out) vs vertical scaling (scale up)
- Stateless applications – łatwe do skalowania
- Database sharding – partycjonowanie danych
- Read replicas – offloading read traffic
- Caching layers (Redis, Memcached, CloudFront) Decoupling patterns:
- Message queues (SQS, Azure Service Bus) – asynchronous processing
- Event-driven architecture (EventBridge, SNS, Event Grid)
- API Gateway – abstrakcja backend services
- Service mesh (Istio, Linkerd) – dla mikroserwisów Data patterns:
- Database per service vs shared database (microservices)
- CQRS (Command Query Responsibility Segregation)
- Event sourcing
- Data lake architectures (S3 + Athena + Glue) Disaster recovery patterns:
- Backup and Restore (RTO/RPO w godzinach, najtańsze)
- Pilot Light (RTO/RPO w dziesiątkach minut)
- Warm Standby (RTO/RPO w minutach)
- Multi-Site Active/Active (RTO/RPO bliskie zera, najdroższe) Przykład praktyczny: Projektujesz architekturę dla SaaS B2B z wymaganiami:
- Dostępność: wysoki poziom SLA
- Skalowalność: od 100 do 100,000 concurrent users
- Disaster recovery: RTO 15 minut, RPO 5 minut
Twoja propozycja:
- Region: eu-central-1 (Frankfurt) – primary, eu-west-1 (Irlandia) – DR
- Compute: ECS Fargate (serverless containers) z Auto Scaling
- Database: Aurora PostgreSQL Multi-AZ + cross-region read replica
- Frontend: S3 + CloudFront (global CDN)
- API: ALB + API Gateway z WAF
- Messaging: SQS dla async tasks, SNS dla notifications
- Monitoring: CloudWatch + X-Ray dla distributed tracing
- Backup: Automatyczne snapshots co 5 minut, cross-region replication
- DR procedure: Route53 health check z automatic failover do Irlandii Narzędzia do nauki: AWS Solutions Architect certification, Azure Solutions Architect Expert, case studies z AWS/Azure blogs, książki: “Designing Data-Intensive Applications” (Martin Kleppmann), “Cloud Native Patterns” (Cornelia Davis)
Które certyfikaty są kluczowe dla Cloud Architect?
Certyfikaty nie zastąpią praktycznego doświadczenia, ale są silnym sygnałem dla pracodawców, że opanowałeś fundamenty. Co ważniejsze – proces przygotowania do certyfikacji systematyzuje wiedzę.
Ścieżka certyfikacyjna – rekomendowane kroki
Etap 1: Foundation (3-6 miesięcy)
Zacznij od certyfikatu fundamentalnego wybranego providera:
AWS Certified Solutions Architect – Associate
- Poziom: Intermediate
- Czas przygotowań: kilka miesięcy przy regularnej nauce
- Koszt: 150 USD według oficjalnej strony egzaminu (aws.amazon.com)
- Co obejmuje: Projektowanie rozwiązań w AWS (compute, storage, databases, networking, security), cost optimization, reliability
- Zalecany dla: Developerów przechodzących na Cloud Architect, pierwsza certyfikacja AWS
- Materiały: AWS Training (darmowe), A Cloud Guru, Tutorials Dojo Practice Exams, dokumentacja AWS LUB
Microsoft Certified: Azure Solutions Architect Expert
- Wymagania: Najpierw zdobądź Azure Administrator Associate (AZ-104), a potem zdaj Azure Solutions Architect Expert (AZ-305); Azure Fundamentals (AZ-900) jest opcjonalnym wstępem, nie warunkiem
- Poziom: Expert (wymaga certyfikatu niższego poziomu)
- Czas przygotowań: kilka miesięcy łącznie
- Koszt: zależny od kraju, w którym zdajesz egzamin – aktualną cenę podaje Microsoft Learn
- Co obejmuje: Projektowanie architektury infrastruktury, security, data platform, aplikacji biznesowych
- Zalecany dla: Firm z ekosystemem Microsoft, projektów enterprise z Azure AD integration
- Materiały: Microsoft Learn (darmowe), Pluralsight, WhizLabs, dokumentacja Azure Który wybrać: AWS czy Azure?
- AWS: Największy udział w rynku, najwięcej ofert pracy dla AWS architektów, szerszy ekosystem usług
- Azure: Silna pozycja w enterprise (szczególnie firmy z Microsoft 365/Active Directory), rosnący udział w rynku
- Praktyczna rada: Wybierz providera używanego w Twojej obecnej firmie lub dominującego w Twoim regionie (sprawdź oferty pracy na NoFluffJobs/JustJoinIT) Etap 2: Professional (6-12 miesięcy od rozpoczęcia)
Po Associate/Expert idź na poziom Professional:
AWS Certified Solutions Architect – Professional
- Poziom: Advanced
- Czas przygotowań: kilka miesięcy intensywnej praktyki
- Koszt: 300 USD według oficjalnej strony egzaminu (aws.amazon.com)
- Co obejmuje: Zaawansowana architektura (multi-region, hybrid cloud, migration strategies), cost optimization na poziomie enterprise, compliance, disaster recovery
- Zalecane doświadczenie: 2 lata lub więcej pracy z usługami AWS – tyle rekomenduje oficjalna strona egzaminu
- Trudność: Wysoka – case studies wymagają głębokiego zrozumienia trade-offs
- Zalecany dla: Osób celujących w role Senior Cloud Architect, AWS-focused companies Materiały:
- AWS Training: Advanced Architecting on AWS (kurs płatny)
- Adrian Cantrill’s SAP-C02 Course (Udemy)
- Tutorials Dojo Practice Exams (najtrudniejsze, najbardziej realistyczne)
- AWS Whitepapers (obowiązkowe): Well-Architected Framework, Disaster Recovery, Security Pillar
Microsoft Certified: Azure Solutions Architect Expert (AZ-305)
- Już omówione powyżej jako część ścieżki Azure
- Po AZ-305 rozważ specjalizację:
- Azure Security Engineer Associate (AZ-500) – dla security-focused roles
- DevOps Engineer Expert (AZ-400)– dla architektów pracujących blisko DevOps Etap 3: Specjalizacje (12-18 miesięcy+)
Po solidnym fundamencie rozważ certyfikaty specjalistyczne:
AWS Certified Security – Specialty
- Dla architektów z fokusem na bezpieczeństwo, compliance (finanse, healthcare)
- Obejmuje: IAM zaawansowane, encryption, incident response, logging & monitoring
AWS Certified Advanced Networking – Specialty
- Dla architektów projektujących złożone topologie sieciowe (hybrid cloud, multi-VPC, Direct Connect)
Google Cloud Professional Cloud Architect
- Jeśli pracujesz w środowisku multi-cloud lub firma używa GCP
- GCP ma mniejszy udział w rynku niż AWS i Azure, ale silną pozycję w ML/AI workloads
Kubernetes certyfikaty (CNCF):
- Certified Kubernetes Administrator (CKA) – dla architektów pracujących z EKS/AKS/GKE
- Certified Kubernetes Application Developer (CKAD)
Czy certyfikaty rzeczywiście pomagają w zdobyciu pracy?
Jak to wygląda w ogłoszeniach: certyfikacje AWS lub Azure pojawiają się w ofertach na Cloud Architecta bardzo często – raz jako twardy wymóg, raz jako preferencja. Twardych danych o tym, ile certyfikat dokłada do wynagrodzenia, ten artykuł nie przytacza; zweryfikuj to sam w aktualnych ogłoszeniach.
Ważna uwaga: Certyfikat bez praktyki to czerwona flaga. Pracodawcy sprawdzają:
- Potrafisz wyjaśnić decyzje architektoniczne z certyfikacji?
- Używałeś tych technologii w prawdziwych projektach?
- Masz portfolio (GitHub z IaC, diagramy architektury)?
Wniosek: Certyfikaty są kluczowym elementem, ale tylko w połączeniu z praktycznym doświadczeniem. Traktuj je jako strukturę nauki, nie cel sam w sobie.
Jak zbudować plan przejścia – roadmapa 12-18 miesięcy?
Oto sprawdzona, konkretna roadmapa przejścia z developera na Cloud Architecta. Zakłada, że pracujesz full-time (będziesz inwestować 10-15h tygodniowo w naukę) i masz już minimum 2-3 lata doświadczenia jako developer.
Miesiące 1-3: Fundamenty cloud + pierwsza certyfikacja
Cele:
- Zrozumieć podstawy jednego cloud providera (AWS lub Azure)
- Zdać certyfikację Associate/Fundamentals
- Zbudować pierwsze środowisko w chmurze
Konkretne działania:
Tydzień 1-2: Teoria + setup
- Załóż AWS Free Tier account lub Azure Free Account
- Nauka: AWS Cloud Practitioner Essentials (darmowy kurs AWS Training) LUB Azure Fundamentals (AZ-900) na Microsoft Learn
- Zainstaluj AWS CLI / Azure CLI, skonfiguruj credentials
- Zrób pierwsze laboratorium: uruchom EC2 instance / Azure VM, połącz się SSH, zainstaluj webserver
Tydzień 3-8: Przygotowanie do certyfikacji
- AWS: Kurs A Cloud Guru/Udemy “AWS Certified Solutions Architect Associate”
- Azure: Microsoft Learn learning path dla AZ-104 (Administrator) + AZ-305 (Architect)
- Hands-on labs (co tydzień):
- Tydzień 3: VPC setup z public/private subnets, NAT gateway, bastion host
- Tydzień 4: Load balancer + Auto Scaling Group
- Tydzień 5: RDS Multi-AZ database + backups
- Tydzień 6: S3 bucket + lifecycle policies + CloudFront
- Tydzień 7: IAM roles, policies, federated access
- Tydzień 8: CloudWatch monitoring, SNS alerts
- Dokumentuj wszystko: Twórz diagramy architektoniczne w draw.io, rób notatki Tydzień 9-12: Intensywne powtórki + egzamin
- Practice exams: Tutorials Dojo (AWS) / WhizLabs (Azure) – rób testy, analizuj błędy
- Przeczytaj AWS Well-Architected Framework (whitepaper) / Azure Well-Architected Framework
- Tydzień 12: Zdaj egzamin certyfikacyjny Rezultat po 3 miesiącach:
- ✅ Certyfikat AWS SAA lub Azure Administrator/Fundamentals
- ✅ Praktyczna umiejętność stawiania podstawowej infrastruktury
- ✅ Portfolio: 6-8 hands-on projektów (publish na GitHub)
Miesiące 4-6: Pogłębianie wiedzy + IaC
Cele:
- Opanować Infrastructure as Code
- Wdrożyć automatyzację w obecnej pracy (pierwsze projekty architektoniczne)
- Rozwinąć networking i security
Konkretne działania:
Terraform (Miesiące 4-5):
- Tydzień 13-14: HashiCorp Learn – Terraform Associate tutorials
- Tydzień 15-16: Przepisz swoje hands-on labs z miesięcy 1-3 na Terraform
- Tydzień 17-18: Stwórz reusable Terraform module dla standardowej aplikacji 3-tier (web/app/db)
- Tydzień 19-20: CI/CD dla Terraform (GitHub Actions – plan/apply przy pull request) Networking deep dive (Miesiąc 5):
- Kurs: “AWS Advanced Networking” lub “Azure Virtual Networks Deep Dive”
- Hands-on labs:
- VPC peering i Transit Gateway (AWS) / VNet peering i Virtual WAN (Azure)
- VPN site-to-site setup
- Private Link / Private Endpoints
- Network segmentation i Security Groups zaawansowane
Security (Miesiąc 6):
- Kurs: AWS Security Fundamentals / Azure Security Engineer (AZ-500 materiały)
- Hands-on labs:
- IAM policy design (least privilege)
- KMS encryption (at rest dla S3, RDS, EBS)
- WAF rules (OWASP Top 10 mitigation)
- GuardDuty / Security Center setup
- Projekt końcowy: Zaprojektuj secure architecture dla aplikacji fintech (PCI-DSS compliance) W pracy:
- Zaproponuj inicjatywę: “Mogę przygotować proof-of-concept migracji naszego środowiska dev do chmury?”
- Weź odpowiedzialność za cloud-related tasks w zespole
- Bierz udział w architecture decision meetings – obserwuj, zadawaj pytania
Rezultat po 6 miesiącach:
- ✅ Umiejętność pisania production-grade Terraform
- ✅ Głęboka wiedza z networking i security
- ✅ Pierwsze projekty architektoniczne w obecnej firmie (POC, dev environment)
Miesiące 7-9: Zaawansowana architektura + druga certyfikacja
Cele:
- Zdać certyfikację Professional/Expert
- Opanować cloud-native patterns (microservices, serverless, containers)
- Przygotować się do zmiany roli
Konkretne działania:
AWS Solutions Architect Professional / Azure Solutions Architect Expert (Miesiące 7-9):
- Tydzień 25-32: Kurs Adrian Cantrill SAP-C02 (AWS) lub oficjalny Microsoft learning path AZ-305
- Hands-on labs (zaawansowane):
- Multi-region active-active architecture z Route53 failover
- Hybrid cloud: Direct Connect / ExpressRoute setup (symulacja)
- Migration strategy: lift-and-shift vs re-architecture
- Disaster recovery: implementacja Warm Standby
- Cost optimization: Reserved Instances strategy, Savings Plans calculator
- Practice exams: Tutorials Dojo Professional level – cel: powtarzalnie wysokie wyniki
- Tydzień 36: Zdaj egzamin Professional/Expert Containers i orchestration (Miesiąc 8):
- Docker fundamentals (jeśli jeszcze nie znasz)
- Kubernetes basics – Certified Kubernetes Administrator (CKA) materiały
- AWS ECS/EKS lub Azure AKS – deploy aplikacji kontenerowej
- Service mesh basics (Istio introduction)
Serverless (Miesiąc 9):
- AWS Lambda deep dive / Azure Functions
- API Gateway + Lambda integration
- DynamoDB / Cosmos DB (NoSQL w chmurze)
- Projekt: Stwórz serverless API (Lambda + API Gateway + DynamoDB) z IaC
W pracy:
- Zainicjuj discussion: “Czy powinniśmy rozważyć serverless dla naszego nowego projektu?”
- Przedstaw cost-benefit analysis cloud migration dla jednego projektu
- Zaproponuj się jako “Cloud Champion” w zespole – mentor dla innych developerów
Rezultat po 9 miesiącach:
- ✅ Certyfikat Professional/Expert (AWS SAP lub Azure AZ-305)
- ✅ Umiejętność projektowania złożonych architektur (multi-region, hybrid, serverless)
- ✅ Widoczność jako cloud expert w obecnej firmie
Miesiące 10-12: Budowanie portfolio + networking + job search
Cele:
- Stworzyć portfolio pokazujące umiejętności architektoniczne
- Zbudować personal brand
- Rozpocząć rozmowy rekrutacyjne na stanowisko Cloud Architect
Konkretne działania:
Portfolio projects (Miesiąc 10): Stwórz 2-3 showcase projects na GitHubie:
Projekt 1: E-commerce platform architecture
- Multi-tier (web/app/db), Auto Scaling, RDS Multi-AZ, S3 + CloudFront, WAF
- Terraform code + szczegółowa dokumentacja (README.md)
- Architecture diagram (draw.io/Lucidchart)
- Cost estimation (AWS Pricing Calculator)
Projekt 2: Serverless data pipeline
- S3 → Lambda → DynamoDB/RDS → API Gateway
- Event-driven (S3 event notifications)
- IaC (Terraform lub SAM/CloudFormation)
- Monitoring (CloudWatch Dashboards)
Projekt 3: Disaster recovery solution
- Active-passive setup (primary region + DR region)
- RTO/RPO calculations
- Runbook (procedura failover)
Personal brand (Miesiąc 11):
- LinkedIn: Dodaj certyfikaty, opisz swoje cloud projects, użyj słów kluczowych (AWS, Azure, Terraform, Cloud Architect)
- Blog/Medium: Napisz 2-3 artykuły:
- “5 błędów, które popełniłem ucząc się AWS”
- “Jak zoptymalizowałem koszty chmury w mojej firmie”
- “Terraform best practices – lekcje z prawdziwych projektów”
- Konferencje/meetupy: Weź udział w AWS User Group Polska, Azure User Group, przedstaw lightning talk Job search (Miesiąc 12):
- Zaktualizuj CV (format: developer → cloud engineer → cloud architect progression)
- Aplikuj na stanowiska: Cloud Architect, Solutions Architect, Cloud Infrastructure Architect
- Target: Firmy z dojrzałym cloud adoption (fintech, SaaS, e-commerce scale-ups)
- Przygotuj się do rozmów:
- Whiteboard architecture: Ćwicz projektowanie architektury na tablicy (20-30 minut case study)
- Behavioral questions: STAR format (Situation, Task, Action, Result)
- Technical deep dive: Przygotuj się na pytania o trade-offs (CAP theorem, eventual consistency, cost vs performance) W obecnej firmie:
- Oficjalnie zaproponuj przejście: “Chciałbym rozwijać się w kierunku Cloud Architect, czy możemy zaplanować transition?”
- Jeśli firma nie ma takiej roli – rozpocznij external job search
Rezultat po 12 miesiącach:
- ✅ Portfolio na GitHubie z 3 showcase projects
- ✅ Aktywny personal brand (LinkedIn, blog)
- ✅ Pierwsze oferty pracy jako Cloud Architect LUB transition w obecnej firmie
Miesiące 13-18: Pierwsze 6 miesięcy jako Cloud Architect
Cele:
- Zbudować credibility w nowej roli
- Pogłębiać wiedzę w obszarach specific do Twojej branży
- Mentorować innych, rozwijać team capabilities
Konkretne działania:
Pierwsze projekty (Miesiące 13-15):
- Weź ownership za 1-2 kluczowe architektury
- Dokumentuj Architecture Decision Records (ADR) – dlaczego wybraliśmy X zamiast Y
- Przeprowadź Well-Architected Review dla istniejących systemów
- Zaproponuj quick wins (cost optimization, security hardening)
Specjalizacja (Miesiące 16-18): Wybierz niszę według branży:
- Fintech/Banking: Security (AZ-500, AWS Security Specialty), compliance (PCI-DSS)
- Healthcare: HIPAA compliance, data privacy
- Media/Gaming: Serverless, high-traffic architectures, CDN optimization
- IoT: Edge computing (AWS Greengrass, Azure IoT Edge) Mentoring:
- Przeprowadź lunch & learn dla developerów: “Cloud fundamentals for developers”
- Code review dla IaC pull requests
- Pomóż junior developerom przygotować się do certyfikacji
Continuous learning:
- Śledź AWS/Azure release notes (nowe usługi, features)
- Czytaj case studies (AWS Architecture Blog, Azure Blog)
- Certyfikacje dodatkowe (Kubernetes, security specialty)
Rezultat po 18 miesiącach:
- ✅ Stabilna pozycja jako Cloud Architect
- ✅ Track record udanych projektów
- ✅ Rozpoznawalność w branży (konferencje, blog, LinkedIn)
- ✅ Wynagrodzenie na poziomie mid-level Cloud Architecta w Polsce
Jak budować doświadczenie architektoniczne, będąc developerem?
Największe wyzwanie: jak zdobyć doświadczenie architektoniczne, skoro nie jestem jeszcze architektem? To klasyczny catch-22. Oto sprawdzone strategie:
1. Startuj małymi krokami w obecnej firmie
Nie czekaj na oficjalny tytuł – zacznij działać jak architekt już dziś.
Konkretne kroki:
Weź odpowiedzialność za infrastrukturę developerską:
- “Mogę przenieść nasze środowisko dev/staging do chmury?”
- “Zautomatyzuję provisioning środowisk testowych z Terraform”
- To świetny poligon doświadczalny bez ryzyka dla produkcji
Zaproponuj proof-of-concept dla nowych technologii:
- “Sprawdzę, czy serverless (Lambda) sprawdzi się dla naszych background jobs – zrobimy POC?”
- POC daje Ci przestrzeń do eksperymentowania i budowania portfolio case studies
Bierz udział w architecture discussions:
- Nawet jeśli nie masz formalnej roli, zadawaj pytania na spotkaniach technicznych:
- “Dlaczego wybraliśmy ALB zamiast NLB?”
- “Czy rozważaliśmy multi-AZ dla tej bazy danych?”
- Pokazujesz, że myślisz architektonicznie
Zgłoś się na wolontarza do projektów cloud migration:
- Jeśli firma migruje do chmury – to złoto. Będziesz pracować blisko architektów, uczysz się przez obserwację Pisz Architecture Decision Records (ADR):
- Dokumentuj decyzje techniczne w zespole (nawet jeśli jeszcze nie ma takiego procesu)
- Format ADR: Context → Decision → Consequences
- To pokazuje, że rozumiesz nie tylko “jak”, ale “dlaczego”
2. Side projects – Twoje laboratorium architektoniczne
Projekty osobiste dają Ci pełną kontrolę i przestrzeń do eksperymentowania.
Co budować:
Realworld applications, nie tutoriale:
- Dobry projekt: Sklep e-commerce z pełną infrastrukturą (VPC, ALB, RDS, S3, CloudFront, monitoring)
- Słaby projekt: “Hello World Lambda” z tutoriala AWS Fokus na różnorodność technologiczną:
- Projekt 1: Monolith na EC2 + RDS (tradycyjna architektura)
- Projekt 2: Microservices na ECS/EKS (containers)
- Projekt 3: Serverless (Lambda + API Gateway + DynamoDB)
- To pokazuje, że potrafisz wybrać odpowiednie narzędzie do problemu
Dokumentacja > Kod:
- README.md: Problem → Solution → Architecture → Cost estimation → Lessons learned
- Diagram architektury (draw.io, cloudcraft.co)
- ADR (Architecture Decision Records) – wyjaśnij kluczowe decyzje
- Rekruterzy patrzą na dokumentację, nie kod (większość i tak nie przeczyta całego Terraform) Open source contributions:
- Contribute do projektów związanych z cloud infrastructure (Terraform providers, Kubernetes operators)
- To pokazuje collaboration skills i aktywność w community
Publikuj case studies:
- Blog post: “Jak zbudowałem disaster recovery solution dla 1000 PLN miesięcznie”
- Udostępnij na LinkedIn, Reddit (r/aws, r/azure), Dev.to
3. Freelancing i consulting
Freelancing pozwala zdobyć exposure do różnych projektów i technologii szybciej niż full-time employment.
Gdzie szukać:
- Upwork, Toptal: Projekty “AWS migration”, “Terraform infrastructure”, “Cloud architecture consulting”
- Polskie platformy: Useme, Gruper – “Cloud infrastructure”, “DevOps”
- LinkedIn: Aktywnie komentuj posty z hashtag #AWS #Azure #CloudArchitecture – znajdą Cię klienci Jakie projekty brać:
- First project: “Terraform automation for small business” – niski risk, buduje confidence
- Second project: “AWS migration for legacy application” – bardziej complex, lepiej płatne
- Avoid: Projekty tylko “maintenance” (patching, monitoring) – nie budujesz architecture skills Pricing:
- Junior level (pierwsze projekty): najniższe stawki, ale wystarczające, by wejść na rynek
- Mid-level (po kilkunastu miesiącach praktyki): stawki wyraźnie wyższe
- Senior level (po kilku latach): stawki najwyższe, zwykle negocjowane projektowo
Korzyści:
- Diversyfikacja experience – widzisz różne architektury, problemy, stacki
- Portfolio case studies (za zgodą klienta)
- Dodatkowy dochód – możesz zainwestować w szkolenia, certyfikaty, konferencje
- Network– zadowoleni klienci polecają dalej
4. Aktywność w community
Personal branding acceleruje Twoją karierę – stajesz się “known expert”.
Konkretne działania:
LinkedIn:
- Publikuj regularnie (1-2 posty tygodniowo): TIL (Today I Learned), quick tips, lessons learned
- Komentuj posty influencerów z branży cloud (Adrian Cockcroft, Corey Quinn, AWS Heroes)
- Używaj hashtagów: #AWS #Azure #CloudArchitecture #Terraform #DevOps
Blogging:
- Medium, Dev.to, własny blog (Hugo/Jekyll + GitHub Pages)
- Pisz practical content: “How to…”, “5 mistakes…”, “Complete guide to…”
- SEO: targetuj keywords “AWS architecture”, “Terraform tutorial”, “cloud cost optimization”
Konferencje i meetupy:
- Słuchaj i networkuj: AWS Summit Poland, Microsoft Ignite, DevOpsDays
- Lightning talks (5-10 min): Niski próg wejścia, świetny trening
- Full presentations (30-45 min): Po roku doświadczenia, zaproponuj talk “My journey from developer to Cloud Architect” YouTube/Twitch:
- Live coding: “Building AWS architecture from scratch”
- Niszowe, ale highly engaging– pokazujesz praktyczne umiejętności w real-time Networking efekt:
- Rekruterzy znajdują Cię przez contentu
- Polecenia od community (większość ofert cloud architect nie jest publicznie ogłaszanych)
- Invitacje do consulting gigs
5. Mentoring i teaching
“Jeśli potrafisz wytłumaczyć, to naprawdę rozumiesz.”
Konkretne działania:
Wewnętrzne szkolenia w firmie:
- Przeprowadź lunch & learn: “AWS basics for developers”, “Terraform introduction”
- To buduje Twoją pozycję jako eksperta in-house
Mentorowanie juniorów:
- Zostań mentorem dla junior developerów uczących się cloud
- Platformy: MentorCruise, GrowthMentor, ADPList (darmowe mentoring)
Teaching online:
- Stwórz mini-kurs na Udemy (nawet darmowy) – to portfolio piece
- Tutorials na YouTube
Korzyści:
- Utrwalasz wiedzę – teaching wymusza głębokie zrozumienie
- Buduje confidence – jeśli potrafisz nauczyć, potrafisz prezentować architektury stakeholderom
- Network i reputation
Zarobki Cloud Architect vs Developer – ile można zarobić?
Przejście na Cloud Architecta to zwykle znaczący skok finansowy. Poniżej – co na ten skok wpływa i jak sprawdzić aktualne widełki samodzielnie.
Mediana zarobków – porównanie
Jak czytać widełki: na polskim rynku Cloud Architect zarabia zwykle więcej niż Backend Developer na tym samym poziomie seniority, a Cloud Engineer leży pomiędzy nimi. Konkretnych kwot ten artykuł nie podaje – zestawienia, które by je kotwiczyły, nie są tu cytowane. Aktualne widełki sprawdzisz najszybciej w ogłoszeniach na NoFluffJobs, Bulldogjob czy JustJoinIT.
Kluczowe wnioski:
- Mid-level Cloud Architect zarabia zwykle tyle, co Senior Developer
- Senior Cloud Architect zarabia wyraźnie więcej niż Senior Developer
- Lead Cloud Architect wchodzi w widełki porównywalne z VP Engineering
Co wpływa na zarobki?
1. Certyfikaty
- Bez certyfikacji: oferty z dolnej części widełek
- AWS SAA: pierwszy wyraźny dodatek do stawki
- AWS SAP: dodatek wyższy niż za poziom Associate
- Multi-cloud (AWS + Azure): dodatek za szerokość kompetencji
2. Branża
- Najwyżej płacące: Fintech, banking, gaming, e-commerce scale-upy (premia nad rynkiem)
- Average: Software houses, enterprise, outsourcing (baseline)
- Najniżej: Agencje, małe lokalne firmy (poniżej baseline) 3. Wielkość firmy
- Startup (<50 osób): Niższe base salary, ale equity
- Scale-up (50-500): Średnie lub wysokie, equity lub bonus
- Enterprise (500+): Średnie base, stabilność, benefity
- Big Tech (Google, Amazon): Najwyższe stawki, equity, benefity 4. Doświadczenie
- 0-2 lata jako architekt: poziom Mid-level
- 2-5 lat: poziom Senior
- 5+ lat: poziom Lead/Principal
5. Umowa
- UoP: Baseline
- B2B: Wyższa kwota brutto, ale bez ZUS i urlopu – na rękę wychodzi często podobnie
- Kontrakt zagraniczny (UK, DE, Nordics): Stawki wyraźnie wyższe niż polskie
Przykłady realnych ofert (anonimizowane)
Oferta 1: Mid-level Cloud Architect, fintech (Warszawa, remote)
- Wymagania: AWS SAA, 3+ lata doświadczenia (w tym 1 rok cloud), Terraform
- Stack: AWS, Kubernetes (EKS), Terraform, Python
- Benefity: Private healthcare, Multisport, budżet konferencyjny
Oferta 2: Senior Cloud Architect, e-commerce scale-up (remote EU)
- Wymagania: AWS SAP lub Azure Expert, 5+ lat total experience, 2+ jako architekt
- Stack: Multi-cloud (AWS + GCP), Terraform, Kubernetes, Istio
- Benefity: Equity, unlimited PTO, equipment budget
Oferta 3: Lead Cloud Architect, międzynarodowy bank (Warszawa, hybrid)
- Wymagania: AWS + Azure certifications (SAP + AZ-305), 7+ lat experience, security specialty
- Stack: Hybrid cloud (AWS + Azure + on-premise), regulatory compliance (PCI-DSS, RODO)
- Benefity: Roczny bonus, private healthcare family, company car
Oferta 4: Principal Cloud Architect, Big Tech (remote global)
- Wymagania: 10+ lat experience, multiple certifications, proven track record at scale
- Stack: Multi-cloud, kubernetes at scale, FinOps, architecture governance
- Benefity: Equity (RSU), relocation package, global healthcare
Perspektywy wzrostu – następne kroki kariery
Po osiągnięciu pozycji Senior/Lead Cloud Architect masz kilka ścieżek:
1. Specjalizacja techniczna:
- Principal/Staff Architect: Architekt dla całej organizacji, strategic technical decisions
- Distinguished Engineer: Najwyższy poziom IC (individual contributor) – równy VP 2. Management:
- Head of Cloud / Cloud Lead: Zarządzanie zespołem architektów (5-10 osób)
- VP Engineering / CTO: C-level, strategic technology leadership 3. Consulting:
- Independent consultant: High-value, project-based, stawki godzinowe
- Partner w firmie consultingowej (equity + profit sharing) 4. Entrepreneurship:
- Cloud-native startup (z technical co-founder jako CTO)
- DevOps tooling / IaC automation (budowa produktu dla innych architektów) Wniosek: Cloud Architect to dobrze płatna i rozwojowa ścieżka kariery w IT. Inwestycja 12-18 miesięcy w naukę i przejście zwraca się w dłuższym horyzoncie.
Jak EITT wspiera transformację z developera na Cloud Architect?
W EITT rozumiemy, że transformacja kariery to nie tylko nauka technologii – to zmiana mindset, budowanie pewności siebie i praktyczne doświadczenie. Nasz program “Developer to Cloud Architect” został zaprojektowany specjalnie dla osób w Twojej sytuacji.
Nasze podejście: od fundamentów do pierwszej pracy
1. Assessment i personalizowana roadmapa
Zaczynamy od indywidualnej konsultacji:
- Current state assessment: Jakie umiejętności już posiadasz? (języki, frameworki, doświadczenie z infrastrukturą)
- Target role analysis: Cloud Architect w jakiej branży? AWS/Azure/GCP? Enterprise vs startup?
- Gap analysis: Co musisz nauczyć się, aby osiągnąć cel?
- Personalized roadmap: 12-18 miesięczny plan z milestones, rekomendowanymi szkoleniami, projektami Rezultat: konkretny plan działania ustalony na konsultacji. 2. Kompleksowe szkolenia cloud – od podstaw do Professional
Oferujemy pełną ścieżkę edukacyjną dostosowaną do Twojego poziomu:
Poziom Foundation (3-4 miesiące):
Szkolenia z fundamentów AWS dla developerów (stacjonarnie lub online)
- VPC, EC2, S3, RDS, Lambda – fundamenty AWS
- Hands-on labs: Stawianie 3-tier web application
- Best practices: Security, cost optimization
- Przygotowanie do AWS Solutions Architect Associate
- Format: zajęcia z instruktorem i hands-on labs
- Cena: ustalana indywidualnie LUB
Szkolenia z architektury rozwiązań chmurowych Microsoft
- Azure compute, storage, networking
- Identity management (Azure AD)
- Security i compliance
- Przygotowanie do AZ-305 (Solutions Architect Expert)
Poziom Advanced (6-9 miesięcy):
Szkolenia zaawansowane z architektury AWS
- Zaawansowana architektura (multi-region, hybrid cloud)
- Migration strategies (6R framework)
- Disaster recovery planning
- Cost optimization dla enterprise
- Security i compliance (RODO, NIS2)
- Format: blok intensywny + labs self-paced
- Cena: ustalana indywidualnie (z voucherem na egzamin i dostępem do labów) Infrastructure as Code z Terraform (szkolenie praktyczne)
- Terraform fundamentals
- Best practices: modules, state management, CI/CD
- Multi-environment strategies
- Security scanning (tfsec, Checkov)
- Hands-on: Deployment pełnej aplikacji
- Format: w większości hands-on
- Cena: ustalana indywidualnie Cloud Security Engineering
- IAM zaawansowane, Zero Trust Architecture
- Encryption, secrets management
- Network security (Security Groups, NACLs, WAF)
- Incident response w chmurze
- Format: zajęcia z ćwiczeniami laboratoryjnymi
- Cena: ustalana indywidualnie Kubernetes dla Cloud Architektów
- Kubernetes architecture
- EKS/AKS deployment i management
- Service mesh (Istio basics)
- Security (RBAC, Network Policies)
- Format: warsztat z labami
- Cena: ustalana indywidualnie Poziom Specjalizacja:
FinOps – Cloud Cost Optimization
- Cloud pricing models deep dive
- Cost allocation strategies
- Automation narzędzia (AWS Cost Explorer, Cloudability)
- Real case study: optymalizacja kosztów chmury
- Format: krótki, skoncentrowany blok
- Cena: ustalana indywidualnie Multi-Cloud Architecture
- AWS vs Azure vs GCP – kiedy co wybrać
- Multi-cloud networking (interconnects)
- Unified observability
- Terraform multi-cloud
- Format: szkolenie praktyczne
- Cena: ustalana indywidualnie 3. Praktyczne projekty i mentoring
Projekt praktyczny z architektury chmurowej (part-time):
- Pracujesz nad real-world case study (np. “Zaprojektuj architekturę dla fintech’u przetwarzającego 1M transakcji/dzień”)
- Mentor (doświadczony Senior Cloud Architect) przegląda Twoje rozwiązania co tydzień
- Dostarczasz: Architecture diagram, IaC code (Terraform), dokumentację, cost estimation, DR plan
- Rezultat: Portfolio piece gotowe do pokazania rekruterom
- Cena: ustalana indywidualnie Code review i feedback:
- Wysyłasz swoje IaC projects (Terraform, CloudFormation) do review
- Senior architekt z EITT dostarcza szczegółowy feedback (security, cost, best practices)
- Format: Asynchroniczne (Slack/email), 48h turnaround
- Cena: ustalana indywidualnie 4. Wsparcie w job search
Career coaching (3 sesje × 1.5h):
- Sesja 1: Przygotowanie CV i LinkedIn profilu (optymalizacja dla Cloud Architect roles)
- Sesja 2: Mock interview – technical (whiteboard architecture design)
- Sesja 3: Mock interview – behavioral + negotiation strategies
- Cena: ustalana indywidualnie Networking events:
- Połączenie z alumni EITT pracującymi jako Cloud Architects (referrals)
5. Finansowanie i elastyczność
Flexible payment:
- Ratalne płatności (warunki ustalamy indywidualnie)
- Employer-sponsored training (współpracujemy z działami HR/L&D)
Success guarantee:
- Jeśli nie zdasz certyfikacji po naszym kursie – darmowy re-take kursu (warunek: wysoka frekwencja i zaliczenie quizów)
Dlaczego EITT?
- Eksperci: Nasi trenerzy to praktycy – Senior Cloud Architects z certyfikacjami AWS/Azure/GCP, pracujący w enterprise i scale-upach
- Ponad 2500 szkoleń w katalogu: Zaufało nam Orange, PZU, PKO BP, Allegro, polskie fintechy i scale-upy
- Praktyczne podejście: większość czasu to hands-on labs, nie nudna teoria
- Real-world case studies: Używamy przykładów z polskiego rynku, regulacji (RODO, NIS2), problemów, które napotykasz w pracy Success stories:
Typowa ścieżka w EITT prowadzi od szkoleń z fundamentów chmury, przez automatyzację infrastruktury, do przygotowania na poziomie zaawansowanym. Ile zajmie przejście z roli developera do roli architekta i jak zmieni się wynagrodzenie, zależy od punktu startowego — tego artykuł nie obiecuje.
Mentoring w EITT polega na pracy z praktykującym architektem, który wyjaśnia powody wyboru rozwiązania, a nie tylko samo rozwiązanie. Relacji uczestników nie przypisujemy tu konkretnym osobom, bo nie da się ich zweryfikować.
Gotowy zacząć transformację?
👉 Sprawdź nasze szkolenia Cloud i certyfikacje 👉 Umów bezpłatną konsultację – zaplanujemy Twoją roadmapę
FAQ – najczęstsze pytania o przejście na Cloud Architect
Czy potrzebuję studiów informatycznych, aby zostać Cloud Architect?
Nie, studia informatyczne nie są wymagane. Rynek cloud computing jest niezwykle merytokratyczny – liczy się praktyczna wiedza i umiejętności, nie dyplom. Wśród architektów chmury spotkasz i absolwentów informatyki, i osoby po zupełnie innych kierunkach, i samouków po bootcampach oraz certyfikacjach – ankiety, która rozkładałaby to na procenty, ten artykuł nie cytuje. Co jest ważniejsze niż dyplom:
- Certyfikacje cloud (AWS/Azure/GCP) – konkretny, weryfikowalny proof of knowledge
- Portfolio projektów – pokazujesz, że potrafisz projektować architektury
- Doświadczenie praktyczne– lata pracy jako developer/DevOps są równie wartościowe co studia Przykład: Jednym z najbardziej cenionych Cloud Architects w polskim fintech’u jest osoba, która:
- Studiowała filologię angielską (!)
- Przebranżowiła się do IT przez bootcamp programistyczny
- Kilka lat pracowała jako backend developer
- Samodzielnie zdała AWS SAA i SAP
- Dziś pracuje jako Lead Cloud Architect
Wniosek: Jeśli masz doświadczenie jako developer (2-3+ lata), certyfikacje i portfolio – dyplom nie będzie barierą.
Ile czasu zajmuje realnie przejście z developera na Cloud Architect?
Realistyczny timeframe: 12-24 miesiące, w zależności od punktu startowego i intensywności nauki. Breakdown:
Fast track (12-15 miesięcy) – wymaga:
- Mocny background developerski (3+ lata)
- Intensywna nauka (15-20h tygodniowo)
- Full-time employment z dostępem do cloud projects
- 2-3 certyfikaty w tym czasie (Associate → Professional)
Standard track (18-24 miesiące) – bardziej typowe:
- 2-3 lata doświadczenia jako developer
- Umiarkowane tempo nauki (10-15h tygodniowo)
- Stopniowe przejmowanie architecture responsibilities w obecnej firmie
- 2 certyfikaty (Associate + Professional)
Slow track (24-36 miesięcy) – jeśli:
- Ograniczona ilość czasu (5-10h tygodniowo)
- Pracujesz w firmie bez cloud projects (trudniej budować doświadczenie)
- Startujesz z juniorskiego poziomu developera
Kluczowe milestones na timelines:
| Czas | Milestone | Możliwy tytuł |
|---|---|---|
| 3-6 miesięcy | Pierwsza certyfikacja (SAA/AZ-104) | Wciąż Developer (z cloud skills) |
| 6-12 miesięcy | Hands-on projekty w firmie, druga certyfikacja (SAP/AZ-305) | Cloud Engineer lub Junior Cloud Architect |
| 12-18 miesięcy | Ownership za kluczowe architektury, portfolio | Mid-level Cloud Architect |
| 18-24 miesięcy | Prowadzenie architecture decisions, mentoring | Senior Cloud Architect |
Kasia (12 miesięcy):
- Start: Senior Backend Developer (Python, 4 lata doświadczenia)
- Miesiące 1-4: AWS SAA, Terraform, labs w weekendy
- Miesiące 5-8: Przejęła ownership za migrację dev/staging do AWS w firmie
- Miesiące 9-12: AWS SAP, propozycja architektury produkcji, promocja na Cloud Architect
- Rezultat: Internal promotion i wyraźnie wyższe zarobki Michał (24 miesiące):
- Start: Mid-level Frontend Developer (React, 2 lata doświadczenia)
- Miesiące 1-12: AWS SAA, nauka backend (Node.js + databases), hands-on labs
- Miesiące 13-18: Przepisał osobiste projekty na IaC (Terraform), AWS SAP
- Miesiące 19-24: Freelancing (3 małe projekty cloud migration), LinkedIn personal branding
- Rezultat: Nowa praca jako Cloud Architect w startupie i wyraźnie wyższe zarobki Wniosek: 12-24 miesiące to realistyczny timeframe przy konsekwentnej pracy i strategicznym podejściu.
Czy muszę znać programowanie, aby być Cloud Architect?
Tak, ale nie na poziomie production developer.
Wymagane programming skills dla Cloud Architect:
Podstawy 1-2 języków (Python, Bash, Go):
- Python: Do automation scripts, Lambda functions, SDK usage (boto3 dla AWS)
- Bash: Do scripting, automation, infrastructure troubleshooting
- Go (opcjonalne): Dla performance-critical Lambdas, Kubernetes operators Poziom: Nie musisz pisać złożonych algorytmów ani frameworków. Wystarczy:
- Rozumieć kod napisany przez developerów (code review)
- Pisać proste automation scripts (100-200 linii)
- Debugować infrastructure issues
IaC to musisz znać:
- Terraform/CloudFormation: To “język” architektów cloud – declarative, nie procedural
- Poziom: Średniozaawansowany – umiejętność pisania modułów, zarządzanie stanem
Co NIE jest wymagane:
- Zaawansowane algorytmy, struktury danych
- Deep understanding konkretnych frameworków (React, Django, Spring)
- Umiejętność pisania production-grade aplikacji od zera
Przykład praktyczny: Jako Cloud Architect możesz potrzebować napisać:
- Lambda function, która reaguje na S3 event i przetwarza plik (50 linii Python)
- Bash script do automatyzacji backup’u (30 linii)
- Terraform module dla standardowej aplikacji 3-tier (200-300 linii HCL)
Ale NIE będziesz:
- Implementować business logic aplikacji
- Pisać frontend UI
- Debugować złożonych bugów w kodzie aplikacyjnym
Wniosek: Jeśli masz 2-3 lata jako developer, Twoje programming skills są wystarczające. Jeśli Twoje doświadczenie to głównie frontend (HTML/CSS/JS) – powinieneś doedukować się w zakresie backend basics (REST API, databases, Linux).
Czy Cloud Architect to praca zdalna, czy trzeba być w biurze?
Cloud Architect to rola bardzo przyjazna pracy zdalnej.
Jak to wygląda w ogłoszeniach:
- Większość ofert na Cloud Architect to praca w pełni zdalna albo hybrydowa z kilkoma dniami w biurze
- Część ofert wymaga obecności przez większość tygodnia
- Praca wyłącznie z biura jest dziś rzadkością Dlaczego Cloud Architect to świetna rola remote:
- Praca z chmurą: Infrastruktura jest w AWS/Azure, nie w lokalnym biurze – nie ma różnicy, czy pracujesz z Warszawy, czy Krakowa
- Collaboration tools: Architecture discussions przez Zoom/Teams, diagramy w Miro/Lucidchart, code reviews w GitHub
- Flexibility: Senior-level role – większa autonomia, trust-based work culture Kiedy on-site jest wymagane:
- Highly regulated industries: Banking, government – mogą wymagać on-site ze względów security/compliance
- Startup culture: Niektóre startupy preferują in-person collaboration (ale to rzadkie)
- Occasional on-site: Architecture workshops, kickoffs, quarterly planning – zwykle 1-2 dni/kwartał Perspektywa międzynarodowa: Remote + cloud skills otwierają drzwi do pracy dla firm zagranicznych:
- Umowy B2B dla firm UK/Niemcy/Nordics
- Zarobki wyraźnie wyższe (ale w USD/EUR)
- Timezone compatibility (Europa Zachodnia: 1-2h różnicy, USA West Coast: 9h – trudniejsze)
Wniosek: Jeśli work-life balance i remote flexibility są dla Ciebie ważne – Cloud Architect to świetny wybór.
Czy muszę specjalizować się w jednym cloud providerze, czy lepiej multi-cloud?
Strategia: Start z jednym (deep), potem rozszerzaj (breadth).
Faza 1 (pierwsze 12-18 miesięcy): Deep dive w jednym providerze
Zalety specjalizacji:
- Szybsza ścieżka: Opanowanie jednego providera jest znacznie szybsze niż próba uczenia się wszystkich naraz
- Certyfikacja: Profesjonalne certyfikacje wymagają głębokiej wiedzy jednego ekosystemu
- Job market: firmy zwykle opierają się na jednym głównym providerze, a drugiego trzymają jako backup Którego wybrać:
- AWS: Największy udział w rynku, najwięcej ofert pracy, najszerszy ekosystem
- Azure: Silna pozycja w enterprise (Microsoft ecosystem), rosnący udział
- GCP: Najmniejszy z trójki, ale silny w ML/AI, data analytics, startupach tech Polskie realia:
- AWS: w polskich ogłoszeniach pojawia się najczęściej
- Azure: drugi najczęstszy wymóg
- GCP: wymagany najrzadziej Wniosek Faza 1: Wybierz AWS (największy rynek pracy) lub Azure (jeśli Twoja firma/branża to Microsoft ecosystem). Faza 2 (po 18-24 miesiącach): Multi-cloud breadth
Kiedy dodać drugiego providera:
- Opanowałeś pierwszego (certyfikat Professional/Expert + 1-2 lata praktyki)
- Widzisz oferty pracy multi-cloud (zwykle lepiej płatne)
- Twoja firma faktycznie używa multi-cloud
Multi-cloud w praktyce:
- Większość firm multi-cloud to 80/20: Główny provider (AWS) + backup/specjalizacja (GCP dla BigQuery, Azure dla Active Directory integration)
- Rzadkie: True multi-cloud (równe obciążenie między providerami) – zwykle tylko w bardzo dużych enterprise Second provider – co musisz wiedzieć:
- Fundamenty są podobne (VPC = Virtual Network, EC2 = VM, S3 = Blob Storage) – koncepty się przenoszą
- duża część wiedzy z pierwszego providera jest transferowalna
- Fokus na różnice: Unique services, pricing models, management paradigms Przykład multi-cloud career path:
- Miesiące 1-18: AWS (SAA → SAP) – deep specialization
- Miesiące 19-24: Azure basics (AZ-900 → AZ-104) – breadth
- Miesiące 25+: Multi-cloud projects, certyfikacje specjalistyczne (Kubernetes, FinOps)
Wniosek: Start z jednym (AWS lub Azure), dodaj drugiego po 18-24 miesiącach. Multi-cloud to advanced skill, który zwiększa Twoją wartość rynkową, ale nie próbuj uczyć się wszystkiego naraz na początku.
Jak wygląda typowy dzień pracy Cloud Architect?
Cloud Architect to rola wysoce interaktywna i zróżnicowana. Oto przykładowy dzień z życia Cloud Architecta: 9:00-9:30 – Stand-up z zespołem DevOps/Platform Engineering
- Synchronizacja: co działa, co nie działa, blockers
- Architecture questions od zespołu: “Czy powinniśmy użyć ALB czy NLB dla tego workloada?”
- Quick decisions, unblocking team
9:30-11:00 – Deep work: Architecture design
- Projektujesz nową architekturę dla feature’a/projektu
- Diagramy w Lucidchart/draw.io (VPC, subnets, load balancers, databases, etc.)
- Architecture Decision Record (ADR): dlaczego wybieramy Rozwiązanie A zamiast B
- Cost estimation w AWS Pricing Calculator
11:00-12:00 – Architecture review meeting
- Spotkanie z Product, Engineering Lead, Security Officer
- Prezentujesz propozycję architektury: diagramy, trade-offs, costs
- Dyskusja: security concerns, scalability, DR strategy
- Decisions & action items
12:00-13:00 – Lunch + learning
- Czytasz AWS/Azure blog: nowe features, updates
- Śledzisz community (Reddit r/aws, HackerNews, LinkedIn)
13:00-14:30 – Hands-on: Code review i IaC
- Przeglądasz pull requesty z Terraform code od zespołu
- Feedback: security issues (overly permissive IAM), cost optimization (użyj spot instances), best practices
- Sam piszesz/updatujesz Terraform module dla nowego projektu
14:30-15:30 – Incident response / troubleshooting
- Alert: RDS high CPU
- Analizujesz CloudWatch metrics, RDS Performance Insights
- Identyfikujesz: slow query + brak indeksu
- Współpracujesz z developerami: optymalizacja query, dodanie indeksu
- Documentation: post-mortem, lessons learned
15:30-16:30 – Vendor meeting / Advisory
- Spotkanie z AWS Solutions Architect (external) – review wykorzystania RI/Savings Plans
- Dyskusja: nowe usługi (np. AWS App Runner) – czy pasują do naszych use cases?
- LUB: Advisory dla innego zespołu: “Planujemy migrację legacy app, jak to zrobić?”
16:30-17:30 – Documentation & knowledge sharing
- Aktualizujesz Architecture Wiki (Confluence/Notion)
- Piszesz blog post wewnętrzny: “How we reduced costs with Savings Plans”
- Przygotowanie do lunch & learn w przyszłym tygodniu: “Kubernetes best practices”
17:30-18:00 – Async work & wrap-up
- Odpowiedzi na Slack: pytania od developerów, code review comments
- Planning jutrzejszego dnia
- Learning: 30 min kursu Udemy (np. advanced Kubernetes)
Weekly recurring:
- 1x tydzień: Architecture guild meeting – wszyscy architekci w firmie, knowledge sharing
- 1x tydzień: Cost review meeting – analiza cloud bill, identyfikacja waste
- 1x tydzień: Security review – audit IAM policies, security incidents
- 1-2x miesiąc: All-hands engineering meeting – strategic updates Różnice według senioratu:
Junior/Mid Cloud Architect:
- Więcej hands-on (IaC coding, troubleshooting)
- Mniej strategic meetings
- Pracujesz pod nadzorem Senior Architecta
Senior/Lead Cloud Architect:
- Więcej strategic decisions (multi-year roadmap, provider selection)
- Mentoring junior architects i developerów
- Cross-functional collaboration (finance, legal, compliance)
- Reprezentacja tech przed C-level
Wniosek: Cloud Architect to zróżnicowana rola – czas dzieli się między pracę techniczną, spotkania i współpracę oraz naukę z dokumentowaniem. Jeśli lubisz variety i nie chcesz 8h dziennie tylko kodować – to rola dla Ciebie.
Co jeśli moja obecna firma nie używa cloud – jak zdobyć doświadczenie?
To częste wyzwanie w Polsce – wiele firm wciąż operuje on-premise. Oto strategie: Strategia 1: Inicjuj cloud adoption w obecnej firmie (najlepsza opcja)
Konkretne kroki:
- Start small: Zaproponuj migrację dev/staging environment do chmury (niskie ryzyko, proof of concept)
- Cost-benefit analysis: Przygotuj prezentację dla managementu: “Cloud może obniżyć nam koszty infrastruktury i wyraźnie przyspieszyć deployment”
- Volunteer: “Mogę zrobić POC migracji jednej aplikacji do AWS/Azure – 2 tygodnie, zero ryzyka dla produkcji”
- Quick wins: Pokaż namacalne korzyści (faster provisioning, auto-scaling, backup automation)
Strategia 2: Side projects + portfolio (jeśli firma nie jest otwarta na cloud)
Działania:
- Buduj cloud projects w wolnym czasie (15-20h/tydzień)
- Publikuj na GitHub z pełną dokumentacją
- Pisz blog posty o swoich projektach
- To zastępuje “commercial experience” w oczach rekruterów (zwłaszcza w startupach/scale-upach)
Strategia 3: Freelancing part-time (budowanie commercial experience)
Działania:
- Weź 1-2 małe projekty freelance cloud-related (Upwork, Useme)
- Nawet małe projekty dają Ci “commercial cloud experience” do CV
- 3-4 projekty przez 6 miesięcy = solidny track record
Strategia 4: Zmień pracę na “cloud-first company” wcześniej
Jeśli firma absolutnie nie jest zainteresowana cloud, rozważ:
- Przejście do firmy używającej cloud jako Mid/Senior Developer (nie czekaj na tytuł Architect)
- Po 6-12 miesiącach w cloud environment – transition do Cloud Architect w tej samej firmie lub zewnętrznie
- Target companies: Fintechy, SaaS, e-commerce scale-upy, software houses z cloud-native clients Jak znaleźć cloud-first companies:
- Filtruj oferty na NoFluffJobs: tech stack “AWS” lub “Azure” + “Terraform” + “Kubernetes”
- Sprawdź: Allegro, OLX, Booksy, Brainly, polskie fintechy (Ramp, Uncapped), outsourcing dla klientów EU/US
Strategia 5: Internship / Junior Cloud Engineer (jeśli masz <2 lata experience)
Działania:
- Niektóre firmy oferują “Junior Cloud Engineer” – rola między DevOps a Architect
- Akceptujesz przejściowy step back (może niższe zarobki), ale zyskujesz commercial cloud experience
- Po roku: transition na Cloud Architect
Wniosek: Brak cloud w obecnej firmie to challenge, ale nie blocker. Najlepsza strategia: inicjuj cloud adoption (pokazujesz leadership, budujesz experience). Jeśli to niemożliwe: side projects + freelancing + zmiana firmy.
Podsumowanie: Przejście z developera na Cloud Architect to osiągalny cel w 12-24 miesiące dla programistów z 2-3+ letnim doświadczeniem. Wymaga:
- Systematycznej nauki (fundamenty cloud, networking, security, IaC)
- Zdobycia kluczowych certyfikacji (AWS SAA/SAP lub Azure AZ-305)
- Budowania praktycznego doświadczenia (projekty w firmie, side projects, freelancing)
- Personal brandingu (portfolio, LinkedIn, blog)
Korzyści są ogromne:
- Zarobki wyraźnie wyższe niż u senior developera
- Praca remote-friendly
- Strategiczna rola z wpływem na biznes
- Ciągły rozwój (technologia chmurowa ewoluuje non-stop)
- Perspektywy kariery (Principal Architect, CTO, consulting)
EITT wspiera Cię na każdym etapie– od pierwszej certyfikacji AWS/Azure, przez praktyczne projekty i mentoring, po career coaching i job placement. Z naszym doświadczeniem znamy sprawdzone ścieżki sukcesu. Gotowy zacząć swoją transformację?
👉 Sprawdź nasze szkolenia Cloud Architecture i certyfikacje AWS/Azure 👉 Umów bezpłatną konsultację – omówimy Twoją personalizowaną roadmapę
Nie czekaj – zainwestuj w siebie dzisiaj. Za rok będziesz żałował, że nie zacząłeś wcześniej.