Przejdź do treści
Zaktualizowano: 47 min czytania

Jak przejść z developera na Cloud Architect - plan działania

Praktyczny plan przejścia z roli developera na Cloud Architect. Poznaj wymagane umiejętności, certyfikaty, ścieżkę rozwoju i konkretne kroki do zmiany kariery.

Marcin Godula Autor: Marcin Godula

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. Organizacje masowo migrują do chmury publicznej (AWS, Azure, GCP), a zapotrzebowanie na architektów chmurowych bije rekordy. Według raportu IDC, 95% przedsiębiorstw działa już w modelu multi-cloud, a globalne wydatki na infrastrukturę chmurową w 2026 roku przekroczą 1 bilion dolarów.

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, przetestowany 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. To nie teoria – to roadmap używany przez setki polskich specjalistów, którzy skutecznie przeszli tę transformację.

Na skróty

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 80% tańsze 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

AspektDeveloperCloud Architect
Zakres wpływuPojedyncza aplikacja/mikroserwisCały ekosystem (infrastruktura, networking, security, koszt)
Horyzont czasowySprint (2-4 tygodnie)Kwartały/lata – long-term vision
Główni stakeholdersProduct Owner, Tech LeadCTO, CFO, Security Officer, compliance
Metryki sukcesuFunkcjonalność działa, testy przechodząRTO/RPO spełnione, koszty w budżecie, zero incydentów security
Odpowiedzialność finansowaBrak lub ograniczonaBezpośrednia – cloud bill może wynieść miliony PLN rocznie
Decyzje techniczneWybór biblioteki, framework w ramach aplikacjiWybó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, dlaczego migracja do serverless zwróci się w 8 miesięcy, a CFO, dlaczego inwestycja w multi-region zwiększy dostępność SLA do 99.99%.

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:

  • 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 (60% redukcja kosztów)

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ść: 99.95% 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ń: 2-4 miesiące (zakładając 10-15h/tydzień)
  • Koszt: ~$150 (ok. 600 PLN)
  • 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 zdaj Azure Fundamentals (AZ-900), potem Azure Administrator Associate (AZ-104), na końcu Azure Solutions Architect Expert (AZ-305)
  • Poziom: Expert (wymaga 2 certyfikatów niższego poziomu)
  • Czas przygotowań: 4-6 miesięcy łącznie
  • Koszt: ~$165 za egzamin (~660 PLN), łącznie 3 egzaminy
  • 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: Dominuje rynek (32% udziału), najwięcej ofert pracy dla AWS architektów, szersza ekosystem usług
  • Azure: Silna pozycja w enterprise (szczególnie firmy z Microsoft 365/Active Directory), rosnący udział w rynku (23%)
  • 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ń: 3-6 miesięcy (wymaga solidnej praktyki)
  • Koszt: ~$300 (ok. 1,200 PLN)
  • Co obejmuje: Zaawansowana architektura (multi-region, hybrid cloud, migration strategies), cost optimization na poziomie enterprise, compliance, disaster recovery
  • Wymagania nieformalne: 1-2 lata doświadczenia z AWS
  • 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 (3 dni, płatne)
  • Adrian Cantrill’s SAP-C02 Course (Udemy, ~$15)
  • 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 ok. 11% udziału w rynku, 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?

Dane z polskiego rynku (NoFluffJobs, Bulldogjob, 2025-2026):

  • 68% ofert na Cloud Architect wymaga lub preferuje certyfikacje AWS/Azure
  • Mediana zarobków dla Cloud Architect z certyfikacją AWS SAP: 24,000-28,000 PLN brutto (UoP)
  • Mediana zarobków dla Cloud Architect bez certyfikacji: 18,000-22,000 PLN brutto
  • Różnica: ~25-30% wyższa oferta z certyfikacją

Świadectwa specjalistów EITT:

“Zdałem AWS Solutions Architect Professional po 6 miesiącach intensywnej nauki. W ciągu miesiąca dostałem 3 oferty – dwie o 30% wyższe niż poprzednia pensja jako senior developer.” – Piotr K., Cloud Architect w międzynarodowym fintech’u

“Certyfikaty otworzyły drzwi. Na rozmowach mniej pytali o basic stuff, od razu przechodziliśmy do case studies. Rekruterzy wiedzieli, że mam fundament.” – Agnieszka M., Azure Solutions Architect

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 >85% score
  • 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

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 o 40% 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)
  • ✅ Zarobki 22,000-28,000 PLN brutto (mid-level Cloud Architect 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”

Przykład sukcesu:

“Zacząłem od przełożenia naszego dev environment na AWS z pomocą Terraform. Po 3 miesiącach zaproponowałem migrację staging – dostałem zielone światło. Po roku byłem de facto cloud lead w zespole, mimo że oficjalnie wciąż byłem senior developerem. Rok później dostałem awans na Cloud Architect.” – Tomasz P., Cloud Architect w polskim scale-up’ie

2. Side projects – Twoje laboratorium architektoniczne

Projekty osobiste dają Ci 100% kontroli 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

Przykład sukcesu:

“Zbudowałem side project – clone Airbnb z pełną infrastrukturą AWS (ECS, Aurora, S3, CloudFront, Route53). Napisałem case study ‘How I built scalable Airbnb clone for $50/month’. Post dostał 20k views na Dev.to. Dostałem 5 wiadomości od rekruterów w ciągu miesiąca.” – Karolina S., obecnie Cloud Architect w Warszawie

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): 150-250 PLN/h
  • Mid-level (po 6-12 miesiącach): 300-450 PLN/h
  • Senior level (18+ miesięcy): 500-800 PLN/h

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 Przykład sukcesu:

“Wziąłem 3 freelance’owe projekty przez rok (po godzinach, równolegle z etatem). Każdy był inny: e-commerce migration, IoT platform na AWS, multi-cloud setup. To było intensywne, ale zbudowałem portfolio, które otworzyło drzwi do pierwszej pracy jako architekt.” – Marcin L., Cloud Solutions Architect

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

Przykład sukcesu:

“Zacząłem pisać na Medium – artykuły o Terraform i AWS. Po 6 miesiącach miałem 5000 followers. Dostałem zaproszenie do speaking na AWS User Group Polska, potem konferencję. Rekruter z międzynarodowej firmy znalazł mnie przez LinkedIn – widziała moje posty. Dostałam ofertę 35% wyższą niż na poprzednim stanowisku.” – Ania W., Senior Cloud Architect

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 znaczący skok finansowy. Oto realne dane z polskiego rynku (2025-2026).

Mediana zarobków – porównanie

Dane z NoFluffJobs, Bulldogjob, JustJoinIT (próba: 2000+ ofert, 2025-2026):

StanowiskoJuniorMidSeniorLead/Principal
Backend Developer8,000-12,00014,000-18,00018,000-24,00024,000-30,000
Cloud Engineer12,000-16,00016,000-22,00022,000-28,00028,000-35,000
Cloud Architect20,000-26,00026,000-34,00034,000-45,000+

Kluczowe wnioski:

  • Mid-level Cloud Architect zarabia jak Senior Developer (20-26k vs 18-24k)
  • Senior Cloud Architect zarabia ~40% więcej niż Senior Developer (26-34k vs 18-24k)
  • Lead Cloud Architect zarabia jak VP Engineering (34-45k+)

Co wpływa na zarobki?

1. Certyfikaty

  • Bez certyfikacji: lower end of range (18-22k dla mid-level)
  • AWS SAA: +10-15%
  • AWS SAP: +25-30%
  • Multi-cloud (AWS + Azure): +15-20%

2. Branża

  • Najwyżej płacące: Fintech, banking, gaming, e-commerce scale-upy (30-40% premium)
  • Average: Software houses, enterprise, outsourcing (baseline)
  • Najniżej: Agencje, małe lokalne firmy (15-25% poniżej baseline) 3. Wielkość firmy
  • Startup (<50 osób): Niższe base salary (15-25k), ale equity
  • Scale-up (50-500): Średnie/wysokie (22-32k), equity lub bonus
  • Enterprise (500+): Średnie base (20-28k), stabilność, benefity
  • Big Tech (Google, Amazon): Najwyższe (35-50k+), equity, benefity 4. Doświadczenie
  • 0-2 lata jako architekt: Mid-level (20-26k)
  • 2-5 lat: Senior (26-34k)
  • 5+ lat: Lead/Principal (34-45k+)

5. Umowa

  • UoP: Baseline (jak w tabeli powyżej)
  • B2B: +20-30% brutto, ale bez ZUS, urlopu (real take-home ~równe lub +10%)
  • Kontrakt zagraniczny (UK, DE, Nordics): +50-100% (45-70k PLN equivalent)

Przykłady realnych ofert (anonimizowane)

Oferta 1: Mid-level Cloud Architect, fintech (Warszawa, remote)

  • Wynagrodzenie: 24,000-28,000 PLN brutto (UoP)
  • Wymagania: AWS SAA, 3+ lata doświadczenia (w tym 1 rok cloud), Terraform
  • Stack: AWS, Kubernetes (EKS), Terraform, Python
  • Benefity: Private healthcare, Multisport, conference budget 5000 PLN/year

Oferta 2: Senior Cloud Architect, e-commerce scale-up (remote EU)

  • Wynagrodzenie: 30,000-36,000 PLN brutto (B2B) lub 24,000-28,000 PLN (UoP)
  • Wymagania: AWS SAP lub Azure Expert, 5+ lat total experience, 2+ jako architekt
  • Stack: Multi-cloud (AWS + GCP), Terraform, Kubernetes, Istio
  • Benefity: Equity (0.1-0.5%), unlimited PTO, equipment budget

Oferta 3: Lead Cloud Architect, międzynarodowy bank (Warszawa, hybrid)

  • Wynagrodzenie: 38,000-44,000 PLN brutto (UoP)
  • 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: Annual bonus 20%, private healthcare family, company car

Oferta 4: Principal Cloud Architect, Big Tech (remote global)

  • Wynagrodzenie: 50,000-65,000 PLN equivalent (USD contract, ~$160k-$200k base)
  • 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 (45-60k+): Architekt dla całej organizacji, strategic technical decisions
  • Distinguished Engineer (60-80k+): Najwyższy poziom IC (individual contributor) – równy VP 2. Management:
  • Head of Cloud / Cloud Lead (40-50k): Zarządzanie zespołem architektów (5-10 osób)
  • VP Engineering / CTO (50-80k+): C-level, strategic technology leadership 3. Consulting:
  • Independent consultant (500-1200 PLN/h): High-value, project-based
  • 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 jedna z najlepiej płatnych i najszybciej rosnących ścieżek kariery w IT. Inwestycja 12-18 miesięcy w naukę i przejście zwraca się wielokrotnie w ciągu 2-3 lat.

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: Dokument PDF “Your Cloud Architect Roadmap” z konkretnym planem działania. 2. Kompleksowe szkolenia cloud – od podstaw do Professional

Oferujemy pełną ścieżkę edukacyjną dostosowaną do Twojego poziomu:

Poziom Foundation (3-4 miesiące):

AWS dla Developerów – droga do Solutions Architect (5 dni, stacjonarnie/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: 40h (5 dni × 8h), instruktor + labs
  • Cena: 4,500 PLN LUB

Microsoft Azure dla Architektów – AZ-305 (4 dni)

  • Azure compute, storage, networking
  • Identity management (Azure AD)
  • Security i compliance
  • Przygotowanie do AZ-305 (Solutions Architect Expert)

Poziom Advanced (6-9 miesięcy):

AWS Solutions Architect Professional – intensywny bootcamp (10 dni)

  • Zaawansowana architektura (multi-region, hybrid cloud)
  • Migration strategies (6R framework)
  • Disaster recovery planning
  • Cost optimization dla enterprise
  • Security i compliance (RODO, NIS2)
  • Format: 80h (2 tygodnie intensive) + 40h self-paced labs
  • Cena: 9,500 PLN (includes exam voucher + 3 miesiące dostępu do labs) Infrastructure as Code z Terraform (3 dni)
  • Terraform fundamentals
  • Best practices: modules, state management, CI/CD
  • Multi-environment strategies
  • Security scanning (tfsec, Checkov)
  • Hands-on: Deployment pełnej aplikacji
  • Format: 24h (3 dni), heavily hands-on (70% labs)
  • Cena: 3,200 PLN Cloud Security Engineering (3 dni)
  • IAM zaawansowane, Zero Trust Architecture
  • Encryption, secrets management
  • Network security (Security Groups, NACLs, WAF)
  • Incident response w chmurze
  • Format: 24h (3 dni)
  • Cena: 3,500 PLN Kubernetes dla Cloud Architektów (4 dni)
  • Kubernetes architecture
  • EKS/AKS deployment i management
  • Service mesh (Istio basics)
  • Security (RBAC, Network Policies)
  • Format: 32h (4 dni)
  • Cena: 4,000 PLN Poziom Specjalizacja:

FinOps – Cloud Cost Optimization (2 dni)

  • Cloud pricing models deep dive
  • Cost allocation strategies
  • Automation narzędzia (AWS Cost Explorer, Cloudability)
  • Real case study: Optymalizacja kosztów o 40%
  • Format: 16h (2 dni)
  • Cena: 2,800 PLN Multi-Cloud Architecture (3 dni)
  • AWS vs Azure vs GCP – kiedy co wybrać
  • Multi-cloud networking (interconnects)
  • Unified observability
  • Terraform multi-cloud
  • Format: 24h (3 dni)
  • Cena: 3,500 PLN 3. Praktyczne projekty i mentoring

Cloud Architecture Capstone Project (3 miesiące, part-time):

  • Pracujesz nad real-world case study (np. “Zaprojektuj architekturę dla fintech’u przetwarzającego 1M transakcji/dzień”)
  • Mentor (Senior Cloud Architect z min. 5 lat doświadczenia) 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: 5,000 PLN (3 miesiące 1:1 mentoring) 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: 500 PLN/review 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: 2,400 PLN Networking events:
  • Dostęp do EITT Cloud Architects Community (Slack, quarterly meetups)
  • Połączenie z alumni EITT pracującymi jako Cloud Architects (referrals)

5. Finansowanie i elastyczność

Flexible payment:

  • Ratalne płatności (do 12 rat 0%)
  • 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: frekwencja >90%, zaliczenie quizów)

Dlaczego EITT?

  • 500+ ekspertów: Nasi trenerzy to praktycy – Senior Cloud Architects z certyfikacjami AWS/Azure/GCP, pracujący w enterprise i scale-upach
  • 2500+ przeprowadzonych szkoleń: Zaufało nam Orange, PZU, PKO BP, Allegro, polskie fintechy i scale-upy
  • 4.8/5 średnia ocena: Od uczestników szkoleń (dane z ostatnich 12 miesięcy)
  • Praktyczne podejście: 60-70% 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:

“Przeszedłem pełną ścieżkę EITT: AWS dla Developerów → Terraform → AWS Professional bootcamp. W 14 miesięcy przeskoczyłem z senior developera na Cloud Architect. Zarobki wzrosły o 35%. Najlepsza inwestycja w moją karierę.” – Piotr K., Cloud Architect w międzynarodowym fintech’u (Kraków)

“Mentoring z EITT otworzył mi oczy na to, jak naprawdę myślą architekci. Mój mentor (architekt z 8-letnim doświadczeniem) pokazał mi nie tylko ‘jak’, ale ‘dlaczego’. To jest bezcenne.” – Agnieszka M., obecnie Azure Solutions Architect (Warszawa)

Gotowy zacząć transformację?

👉 Sprawdź nasze szkolenia Cloud i certyfikacje 👉 Umów bezpłatną konsultację – zaplanujemy Twoją roadmapę 👉 Pobierz guide “From Developer to Cloud Architect – Complete Roadmap 2026”

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. Dane z ankiety wśród Cloud Architects (Poland, 2025):

  • 62% posiada studia informatyczne (inżynierskie lub magisterskie)
  • 24% posiada studia z innej dziedziny (matematyka, fizyka, ekonomia, nawet humanistyczne)
  • 14% nie posiada wyższego wykształcenia– samoucy, bootcampy, certyfikacje 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
  • 3 lata pracowała jako backend developer
  • Samodzielnie zdała AWS SAA i SAP
  • Dziś zarabia 38,000 PLN brutto 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:

CzasMilestoneMożliwy tytuł
3-6 miesięcyPierwsza certyfikacja (SAA/AZ-104)Wciąż Developer (z cloud skills)
6-12 miesięcyHands-on projekty w firmie, druga certyfikacja (SAP/AZ-305)Cloud Engineer lub Junior Cloud Architect
12-18 miesięcyOwnership za kluczowe architektury, portfolioMid-level Cloud Architect
18-24 miesięcyProwadzenie architecture decisions, mentoringSenior 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, +30% 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 startupu, +40% 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 jedna z najbardziej remote-friendly ról w IT.

Dane z polskiego rynku (oferty pracy 2025-2026):

  • 78% ofert na Cloud Architect: Fully remote lub hybrid (2 dni/tydzień w biurze)
  • 15% ofert: Hybrid (3-4 dni w biurze)
  • 7% ofert: Fully on-site 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 50-100% wyższe (ale w USD/EUR)
  • Timezone compatibility (Europa Zachodnia: 1-2h różnicy, USA West Coast: 9h – trudniejsze)

Przykład:

“Pracuję jako Cloud Architect dla firmy z Londynu, mieszkam w Gdańsku. Full remote, synchroniczne spotkania tylko 2-3 razy w tygodniu (reszta async Slack). Latam do Londynu 4 razy w roku na tygodniowe planningi. Zarabiam w GBP, living costs w Polsce – lifestyle upgrade.” – Adam R., Senior Cloud Architect

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 zajmuje 1/3 czasu vs. próba uczenia się wszystkich naraz
  • Certyfikacja: Profesjonalne certyfikacje wymagają głębokiej wiedzy jednego ekosystemu
  • Job market: Większość firm używa 1 głównego providera (80% workloads) + drugi jako backup Którego wybrać:
  • AWS: Największy udział w rynku (32%), najwięcej ofert pracy, najszerszy ekosystem
  • Azure: Silna pozycja w enterprise (Microsoft ecosystem), rosnący udział (23%)
  • GCP: Najmniejszy (11%), ale silny w ML/AI, data analytics, startupach tech Polskie realia (oferty pracy Cloud Architect, 2025-2026):
  • AWS: 58% ofert wymaga/preferuje AWS
  • Azure: 32% ofert wymaga/preferuje Azure
  • GCP: 10% ofert wymaga/preferuje GCP 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ą
  • 60-70% 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 realny dzień z życia Cloud Architecta (na podstawie wywiadów z 20 architektów): 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 by 30% 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 – balans między hands-on technical work (40%), meetings & collaboration (40%), learning & documentation (20%). 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 zaoszczędzić nam 30% kosztów infrastruktury + przyspieszyć deployment 3x”
  • 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) Przykład sukcesu:

“Moja firma (manufacturing, 200 osób) działała 100% on-premise. Zaproponowałem migrację środowiska testowego do AWS. Management zgodził się na POC. Po 3 miesiącach: środowisko testowe w chmurze, koszty -40%, deployment z 2 dni do 2 godzin. Rok później migrowaliśmy produkcję. Dostałem promotion na Cloud Lead.” – Tomasz P., obecnie Cloud Architect

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 (500-2000 PLN) 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 25-40% wyższe niż senior developer
  • 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 (500+ ekspertów, 2500+ szkoleń, 4.8/5 ocena) 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ę 👉 Dołącz do EITT Cloud Architects Community – networking, mentoring, job opportunities

Nie czekaj – zainwestuj w siebie dzisiaj. Za rok będziesz żałował, że nie zacząłeś wcześniej.

Przeczytaj również

Poproś o ofertę

Rozwiń swoje kompetencje

Sprawdź naszą ofertę szkoleń i warsztatów.

Zapytaj o szkolenie
Zadzwoń do nas +48 22 487 84 90