Miért terelte a Microsoft a GitHub forgalmát az AWS-re? A Business Insider 2026 júniusában — két, nevét nem vállaló forrásra hivatkozva — azt írta, hogy a Microsoft extra felhőkapacitást vásárolt az Amazon Web Servicestől (AWS), hogy tehermentesítse a túlterhelt GitHubot. Az ok az AI kódoló ügynökök (GitHub Copilot, agentic development) robbanásszerű forgalomnövekedése: az ügynökök által nyitott pull requestek száma 2025 szeptembere és 2026 márciusa között körülbelül 4 millióról 17 millióra ugrott (+325%), miközben a GitHub áprilisban 10, májusban 9 szolgáltatási incidenst jelentett, és a havi rendelkezésre állás júniusban nagyjából 88,4%-ra esett (a 90 napos átlag 87,26%) a célként kitűzött 99,9%-hoz képest. A csavar: a Microsoft a felhőpiacon a fő versenytársához, az AWS-hez fordult segítségért — miközben a GitHubot hosszú távon a saját Azure-jára migrálná. Fontos: sem a Microsoft, sem a GitHub nem erősítette meg hivatalosan az AWS-megállapodást, így a konkrét részletek egyelőre a sajtóértesülés szintjén állnak. Magyar fejlesztőcégnek és SaaS-nak ez nem önmagában a hír, hanem a tanulság számít: ha még a GitHub gazdája is multi-cloudra kényszerül, akkor a vendor lock-in és az SLA-függőség kérdését neked is most kell végiggondolnod.
Kedden reggel egy mondat futott végig a tech-hírleveleken, amitől sokan kétszer is megnézték a feladót: „Microsoft turns to AWS to keep GitHub running." Vagyis a Microsoft a legnagyobb felhős riválisához fordult, hogy a saját kódtárhely-platformja ne dőljön be. Ha valaki kitalált volna egy ilyen forgatókönyvet két éve, kinevetik. 2026 nyarán viszont pont ez a hír kering — és a háttérben egy olyan jelenség áll, amiről idén már részletesen is írtunk a GitHub áprilisi kieséssorozata kapcsán.
Most viszont nem a leállásokról van szó, hanem arról, amit a Microsoft csinál velük. És ez a döntés sokkal többet árul el a 2026-os felhőpiacról — és a saját kockázataidról — mint maguk az üzemzavarok.
Mi történt pontosan? A hír és a fenntartások
A sztorit a Business Insider hozta ki elsőként, két, a tervekhez közel álló, de nevét nem vállaló forrásra hivatkozva. Eszerint a Microsoft többletkapacitást szerződött le az AWS-től, hogy a GitHub kibírja az AI-vezérelt fejlesztési hullámot. A Techzine és a The Register is átvette és kiegészítette a beszámolót.
Egy dolgot rögtön az elején tisztázzunk, mert ez a hitelesség kérdése: sem a Microsoft, sem a GitHub nem erősítette meg hivatalosan az AWS-megállapodást. A The Register kifejezetten kiemeli, hogy az állítás „két anonim Business Insider-forráson nyugszik, és a Microsoft vagy a GitHub részéről megerősítetlen". Tehát a fő tény — hogy a GitHub infrastruktúrája az AI-forgalom alatt nyögött, és a Microsoft multi-cloud irányba mozdul — több független forrásból megáll. A pontos szerződéses részletek viszont egyelőre értesülés szintűek. Ezt érdemes fejben tartani, mielőtt bárki messzemenő következtetést von le belőle.
Milyen számok állnak a GitHub kapacitásgondja mögött?
Az AI kódolás nem marketingszöveg többé, hanem mérhető terhelés a szervereken. Néhány adat, amit a források megerősítenek:
- AI ügynökök által nyitott pull requestek: körülbelül 4 millió (2025 szeptember) → 17 millió (2026 március). Ez nagyjából +325% fél év alatt. (Forrás: Business Insider nyomán az AI Weekly.)
- Szolgáltatási incidensek: 10 a 2026. áprilisi jelentésben, 9 a májusiban — „egyel kevesebb, mint áprilisban", ahogy a The Register fogalmaz.
- Rendelkezésre állás: a 90 napos átlag 87,26%, ezen belül április 78,33%, május 93,86%, június (a jelentésig) 88,39%. A GitHub saját, hivatalos célja a „nagyjából 99,9%" körüli érték.
- GitHub Actions terhelés: 2023-ban heti 500 millió számítási perc, 2026 elejére egyetlen hét alatt 2,1 milliárd perc. (Forrás: AI Weekly.)
- Commit-mennyiség: a korábbi évi 1 milliárd helyett a The Register szerint már havi 1,4 milliárd commit fut át a rendszeren.
A rendelkezésre állás havi bontása jól mutatja, milyen hullámzó volt a tavasz — és mennyire elmarad a hivatalos 99,9%-os céltól:
| Időszak (2026) | Rendelkezésre állás |
|---|---|
| Április | 78,33% |
| Május | 93,86% |
| Június (a jelentésig) | 88,39% |
| 90 napos átlag | 87,26% |
| GitHub hivatalos cél | ~99,9% |
Forrás: The Register, a GitHub status-jelentése alapján.
Egy emberi fejlesztő naponta néhány pull requestet nyit. Egy ügynök percenként többet is, megállás nélkül, éjjel-nappal. A különbség nem fokozati, hanem nagyságrendi — és pontosan ez borítja fel azokat a kapacitástervezési feltételezéseket, amelyekre a GitHub annak idején épült. Aki mélyebben kíváncsi a technikai összeomlás mechanizmusára (tight coupling, thundering herd, rekurzív API-hívások), annak a korábbi cikkünkben végigvettük a részleteket.
Miért fordul a Microsoft épp a fő riválisához, az AWS-hez?
Itt válik a sztori igazán érdekessé. A Microsoft Azure és az Amazon Web Services a nyilvános felhő piacának két legnagyobb szereplője — keményen versengenek minden nagy ügyfélért. Az, hogy a Microsoft épp az AWS-től vásárol kapacitást, hogy a saját platformját életben tartsa, üzletileg fájdalmas gesztus. A Business Insider megfogalmazásában: „Giving an arch rival more business is likely not an ideal move for Microsoft" — vagyis egy ősi riválisnak üzletet adni aligha ideális lépés.
A hosszú távú terv egyébként pont az ellenkezője: a Microsoft a GitHubot fokozatosan a saját Azure-jára költözteti, az eredeti ütemezés szerint nagyjából 2027-re. A The Register szerint a migráció halad is: „a monolit forgalom 40 százalékát már az Azure kezeli (a februári 8 százalékról), a Git-forgalom pedig 30 százalékon áll", és „négy hónap alatt több mint megdupláztuk a tényleges kapacitásunkat". Az AWS bevonása tehát nem stratégiai irányváltás, hanem vészféken meghúzott áthidaló megoldás: amíg az Azure-ra költözés beérik, valahonnan azonnal kell a plusz kapacitás.
Ez a fajta kényszerű többfelhős működés nem új a piacon. Tavaly arról írtunk, hogy az OpenAI is kilépett a Microsoft-exkluzivitásból, és AWS Bedrockon is elérhetővé vált — a nagy AI-szereplők egyre kevésbé engedhetik meg maguknak, hogy egyetlen felhőre tegyenek fel mindent.
Mi az a multi-cloud, és miért lesz belőle kényszerpálya?
A multi-cloud azt jelenti, hogy egy szolgáltatás nem egyetlen felhőszolgáltatóra támaszkodik, hanem többre párhuzamosan — például Azure-ra és AWS-re egyszerre. A cél kettős: egyrészt a kapacitás rugalmas bővítése (ha az egyik szolgáltatónál elfogy a hely, a másik felfogja a túlcsordulást), másrészt a függőség csökkentése egyetlen beszállítótól.
A GitHub esete jól mutatja, miért nem feltétlenül szabad döntés ez. A Business Insider beszámolója szerint a GitHub szóvivője úgy nyilatkozott, hogy a cég „egyszerre gyorsítja az Azure-ra költözést és vizsgálja a multi-cloud stratégiát, hogy meglegyen a jövőbeli kapacitás, a számítási rugalmasság és a vízszintes skálázhatóság a növekedés kiszolgálásához". Magyarra fordítva: a növekedés akkora, hogy egyetlen felhő — még a sajátjuk is — kevés hozzá. A multi-cloud itt nem elegancia, hanem túlélés.
És van egy mélyebb réteg is. A The Register a digitális szuverenitásról szóló elemzésében így fogalmaz: „Control is not about isolation; it is about enforceable governance and reducing hidden dependency" — az irányítás nem elszigetelődés kérdése, hanem érvényesíthető kontrollé és a rejtett függőségek csökkentéséé. Ez a mondat egy globális platformra ugyanúgy igaz, mint egy háromfős magyar fejlesztőcsapatra.
Hogyan változik a GitHub Copilot árazása?
A kapacitásgond nem marad a szerverteremben — beszivárog a számládba is. A The Register és a Techzine szerint a GitHub felhagyott a Copilot eddigi, fix „seat alapú" (felhasználónkénti) árazásával, és áttért a használatalapú modellre: a Copilot-használat mostantól GitHub AI Credit-eket fogyaszt. A Techzine megfogalmazásában „évek támogatott ára és a fix díj után" a GitHub Copilot ára immár fogyasztásfüggő.
A váltás nem minden modellnél fáj egyformán. A Techzine szerint aki a Claude-ot akarja futtatni ezen a platformon, az „nagyjából kilencszer annyit fizet, mint korábban". A nyomás akkora volt, hogy a GitHub egy időre fel is függesztette az új Copilot-előfizetések felvételét. Ha a céged napi szinten épít AI kódolásra, ez nem apró tétel — érdemes most átnézni, melyik feladatra melyik modell éri meg, mielőtt a havi számla magától írja át a költségvetésed.
Mit tanulhat ebből egy magyar fejlesztőcég vagy SaaS?
Itt jön a része, ami valóban rólad szól. A GitHub-sztori önmagában távolinak tűnhet — de a tanulság a legkisebb csapatra is leképezhető. A következő pontok már a mi szerkesztői elemzésünk, nem a források tényállításai; gyakorlati kockázatkezelési szempontok 2026-ra.
- Egyetlen platform = egyetlen hibapont. Ha a teljes CI/CD-d, a kódtárad és az automatizációd egyetlen szolgáltatón (mondjuk csak a GitHubon) fut, akkor annak a szolgáltatónak a rossz hónapja a te rossz hónapod is. Érdemes legalább a kritikus repók tükrözését megoldani egy második helyre (GitLab, Gitea, self-hosted).
- Olvasd el az SLA apróbetűjét. A „99,9%" jól hangzik, de havi szinten az is közel 45 perc megengedett kiesés — és a GitHub júniusi 88,4%-os száma ennél nagyságrendekkel rosszabb. Tudd, mi a vállalt rendelkezésre állás, és mi a kompenzáció, ha nem teljesül.
- Tervezz fallbacket a futószalagra. Ha a build- és deploy-folyamatod megáll, amikor a szolgáltató megáll, az közvetlen bevételkiesés. Egy minimális tartalék-pipeline (akár egy másik futtatókörnyezetben) sokat ér egy rossz napon.
- A vendor lock-in valós költség. Minél mélyebben kötöd magad egyetlen ökoszisztéma egyedi funkcióihoz, annál drágább lesz később kilépni. Ez nem azt jelenti, hogy ne használj menedzselt szolgáltatást — azt jelenti, hogy legyen átgondolt kilépési útvonalad.
- Az AI-terhelés rád is igaz. Ha a saját terméked AI ügynököket enged a rendszeredre (vagy te eresztesz ügynököket mások API-jaira), számolj a GitHubéhoz hasonló, nem-lineáris terheléssel. Rate limit, sorbaállítás, költségplafon — ezek nem opcionális extrák.
A kép tágabb kontextusa egyébként hatalmas: a nagy felhőszolgáltatók 2026-ban együttesen több száz milliárd dolláros nagyságrendben költenek AI-infrastruktúrára. Erről a beruházási hullámról és arról, hogy egy magyar KKV hogyan pozicionálja magát benne, külön is elemeztük a stratégiai következményeket. És hogy az AWS-en futó vállalati agentic AI mit jelent a gyakorlatban, azt a Snowflake 6 milliárd dolláros AWS-megállapodása kapcsán jártuk körbe.
Összefoglaló
A GitHub esete egyetlen mondatban: az AI kódolás akkora forgalmat termel, hogy még a Microsoft is kénytelen a fő riválisához, az AWS-hez fordulni, hogy a platform talpon maradjon — legalábbis a Business Insider értesülése szerint, amelyet hivatalosan egyik fél sem erősített meg. A számok valósak és több forrásból megállnak: négyszeres ügynök-pull request, romló rendelkezésre állás, átalakuló Copilot-árazás.
Magyar fejlesztőcégnek a tanulság nem az, hogy hagyja ott a GitHubot — hanem hogy ne kezelje megdönthetetlennek. A multi-cloud, az SLA-tudatosság és a vendor lock-in elleni védekezés tavaly még nagyvállalati téma volt; idén már a kétfős csapatnak is napirendre kell vennie. Aki az AI ügynökökre épít a mindennapokban, annak az infrastruktúra megbízhatósága nem mellékszál, hanem üzleti alap.
Ha bizonytalan vagy abban, hol fut a céged kritikus infrastruktúrája, és mi történne egy elhúzódó szolgáltatáskiesésnél, vedd fel velünk a kapcsolatot — átnézzük együtt, hol vannak a rejtett függőségeid, és mit érdemes redundánssá tenni.
Források: Business Insider — Microsoft turns to AWS for GitHub capacity | The Register — GitHub outages persist as AI coding drives traffic surge | Techzine — GitHub turns to AWS due to growth in AI development | AI Weekly — Microsoft taps AWS to keep GitHub running
A cikk külső forrásait 2026-06-18-án ellenőriztem. A számszerű adatok (pull request növekedés, incidensek, rendelkezésre állás, Actions-terhelés, commit-mennyiség) a Business Insider, az AI Weekly és a The Register beszámolóiból származnak; a Microsoft–AWS megállapodás tényét hivatalosan egyik fél sem erősítette meg, így azt értesülésként kezelem. A magyar fejlesztőcégekre vonatkozó tanulságok szerkesztői következtetések, nem a források tényállításai.
