AWS satte en ny kaldstart-rekord for AI-agenter 18. september 2026. Amazon Bedrock AgentCore Runtime V2 gikk i generell tilgjengelighet og kutter typisk oppstartstid fra mellom 5,4 og 30 sekunder ned til 1,9-2,0 sekunder, ifølge tidlige tredjepartsmålinger av tjenesten. For nordiske utviklerteam som bygger AI-agenter på tvers av AWS, Azure og Google Cloud, er dette det klareste tegnet så langt på at “agent-skyen” har blitt en egen infrastrukturkategori med sine egne priskurver, sikkerhetsspørsmål og konkurransedynamikk.
Lanseringen kommer bare fem uker etter at AWS tok Bedrock AgentCore til generell tilgjengelighet i august, og den understreker et mønster: de tre store skyleverandørene bygger nå om kjernearkitekturen sin spesifikt for AI-agenter som kjører i timevis, venter på verktøykall og modellsvar, og krever helt andre kostnadsmodeller enn tradisjonelle serverløse funksjoner. Denne artikkelen går gjennom hva som faktisk endret seg, hva det koster, hvordan det måler seg mot Azure AI Foundry Agent Service og Google Vertex AI Agent Builder, og hva det betyr for selskaper i Norge og Norden som allerede har lagt AI-arbeidslaster i skyen.
Hva AWS faktisk lanserte 18. september
Amazon Bedrock AgentCore Runtime er AWS sin administrerte kjøremiljø for AI-agenter, bygget på serverløse mikro-VM-er. Runtime V2 er ikke et helt nytt produkt, men en ny plattformversjon av det samme kjøretidsmiljøet. Utviklere aktiverer den ved å sette parameteren platformVersion til V2 når de oppretter eller oppdaterer en runtime. V1 forblir standardvalget dersom feltet utelates, så eksisterende arbeidslaster påvirkes ikke automatisk.
De to mekanismene som definerer V2, er elastisk minnegjenvinning og øyeblikksbilde-basert gjenoppretting. Med elastisk minne frigjøres ledig minne når en agentøkt slutter å bruke det, i stedet for å forbli reservert gjennom hele øktens levetid. Med snapshot-gjenoppretting kan AWS gjenskape et allerede initialisert kjøremiljø fra et komprimert øyeblikksbilde i stedet for å bygge miljøet fra bunnen av for hver ny økt. Til sammen er dette et forsøk på å løse et strukturelt problem med agent-arbeidslaster: agenter bruker ofte 30-70 prosent av kjøretiden på å vente på svar fra språkmodeller, verktøykall eller eksterne API-er, mens infrastrukturen likevel holdes fullt reservert og betalt for.
Ifølge AWS sin offisielle “What’s New”-melding er V2 tilgjengelig i fem regioner ved lansering: us-east-1, us-east-2, us-west-2, eu-west-1 og ap-northeast-1. For norske selskaper betyr det at nærmeste tilgjengelige region er Irland (eu-west-1), ikke Stockholm eller Frankfurt, noe som kan påvirke både latens og datasuverenitet-vurderinger for team som allerede kjører i AWS sine nordeuropeiske regioner.
Tallene: kaldstart, minne og pris
Den mest siterte forbedringen er kaldstarttiden. Uavhengige målinger publisert kort tid etter lanseringen viser en P75-kaldstart på rundt 1,8 til 2,0 sekunder for V2, for kontainerbilder fra 200 MB til 2 GB, mot mellom 5,4 og 30 sekunder på V1 avhengig av bildestørrelse og samtidighet. AWS beskriver selv, i den offisielle lanseringsbloggen, målet som konsistente oppstarter uavhengig av bildestørrelse eller samtidig belastning, altså en jevnere ytelseskurve snarere enn bare et gjennomsnittlig hurtigere resultat.
Prisbildet er mer sammensatt. Ifølge tidlige tredjepartsrapporter om lanseringen ligger V2 sine listepriser i us-east-1 på 0,1276 dollar per vCPU-time og 0,0169 dollar per GB-time, en økning fra V1 sine 0,0895 dollar per vCPU-time og 0,00945 dollar per GB-time. Minnegjenvinningen inntrer først etter omtrent 120 sekunder med inaktivitet. Det betyr at V2 kan bli dyrere, ikke billigere, for korte økter som aldri når 120-sekundersgrensen for inaktivitet. Gevinsten materialiserer seg primært for langvarige eller sesjonsbaserte agenter der minnet står ubrukt i lange perioder mellom verktøykall.
Det finnes også operasjonelle endringer som er lette å overse. Miljøvariabler er begrenset til 1,5 KB for direkte kodedistribusjoner og 2,5 KB for kontaineragenter, ned fra 4 KB-grensen i V1. Ved lansering manglet både AWS CloudFormation og AWS CDK støtte for å sette platformVersion, ifølge dokumentasjon publisert samme dag som lanseringen. Og fordi AWS må forberede og ta øyeblikksbilde av miljøet ved opprettelse, kan det ta flere minutter før en ny V2-runtime blir klar, selv om påfølgende oppstarter er raskere.
| Egenskap | Runtime V1 | Runtime V2 |
|---|---|---|
| Kaldstart (P75, 200 MB-2 GB image) | 5,4-30 sekunder | 1,8-2,0 sekunder |
| Pris CPU (us-east-1) | 0,0895 USD/vCPU-time | 0,1276 USD/vCPU-time |
| Pris minne (us-east-1) | 0,00945 USD/GB-time | 0,0169 USD/GB-time |
| Minnegjenvinning | Ikke tilgjengelig | Etter 120 sekunder inaktivitet |
| Grense miljøvariabler (kode) | 4 KB | 1,5 KB |
| Grense miljøvariabler (kontainer) | 4 KB | 2,5 KB |
| Regioner ved lansering | Alle støttede Bedrock-regioner | 5 regioner (us-east-1, us-east-2, us-west-2, eu-west-1, ap-northeast-1) |
| Standardvalg | Ja (utelatt felt = V1) | Nei, må aktiveres eksplisitt |
Historisk kontekst: fra Bedrock til AgentCore
Bedrock AgentCore ble tatt til generell tilgjengelighet 18. august 2026 som AWS sin samlede plattform for å bygge, distribuere og kjøre AI-agenter, med integrasjoner mot DynamoDB og vektorsøk for agent-minne. Bare fem uker senere fulgte AWS opp med en fullstendig omarbeidet kjøretidslag i form av Runtime V2. Tempoet illustrerer hvor raskt de store skyselskapene nå iterer på agent-infrastruktur sammenlignet med tradisjonelle skytjenester, der store arkitekturendringer historisk har tatt kvartaler, ikke uker.
Mønsteret går lenger tilbake enn 2026. Da AWS lanserte Lambda i 2014, definerte selskapet i praksis den serverløse kategorien: betal kun for kjøretid, null forvaltning av servere. AI-agenter bryter imidlertid med Lambda-modellen fordi de sjelden er stateless og korte. En agent som skal utføre en flertrinns oppgave, kan holde en økt åpen i minutter eller timer mens den venter på svar fra en språkmodell, kaller eksterne verktøy, eller venter på et menneske i loopen. Det gamle “betal per forespørsel”-prinsippet fra Lambda passer dårlig til denne profilen, og det er nettopp dette gapet AgentCore Runtime V2 prøver å tette med elastisk minne og gjenbrukbare øyeblikksbilder.
Konkurrentbildet: Azure AI Foundry og Google Vertex AI
AWS er ikke alene om å bygge administrerte kjøretidsmiljøer for agenter. Microsoft tilbyr Azure AI Foundry Agent Service, som er tettere integrert med Azure sin identitets- og governance-stack enn med en isolert kjøretidsoptimalisering slik AWS nå leverer. Google har tilsvarende Vertex AI Agent Builder og Agent Engine, som legger vekt på integrasjon med Googles egne modeller og datatjenester.
Prissammenligninger fra tidlig 2026 pekte på at AWS sin opprinnelige AgentCore-prising ga et strukturelt fortrinn ved at ventetid på modellsvar og API-kall ikke ble fakturert, mens konkurrentene i større grad fakturerer løpende kompute. Google Vertex AI ble beskrevet med en runtime-pris på rundt 0,0864 dollar per vCPU-time pluss 0,25 dollar per 1000 lagrede økt-hendelser, og med en gratis kvote på 180 000 vCPU-sekunder og 360 000 GiB-sekunder per måned, noe AWS ikke tilbyr for AgentCore. Azure sin modell ble beskrevet som en kombinasjon av pris per token og pris per verktøykall, en annen kostnadslogikk enn både AWS og Google.
Det viktige poenget for nordiske IT-innkjøpere er at de tre plattformene nå konkurrerer på ulike akser samtidig: AWS optimaliserer for kjøretidseffektivitet og minnebruk, Microsoft for virksomhetsintegrasjon og styring, Google for tett kobling mot egne modeller og datatjenester. Det gjør en ren pris-til-pris-sammenligning vanskelig, og det øker risikoen for at selskaper velger plattform basert på eksisterende skyavtale fremfor faktisk teknisk egnethet for sin agent-arbeidslast.
| Leverandør | Produkt | Kjerneoptimalisering | Prismodell (rapportert) |
|---|---|---|---|
| AWS | Bedrock AgentCore Runtime V2 | Elastisk minne, snapshot-oppstart | 0,1276 USD/vCPU-t + 0,0169 USD/GB-t, ingen gratis kvote |
| Microsoft | Azure AI Foundry Agent Service | Virksomhetsintegrasjon og styring | Pris per token pluss pris per verktøykall |
| Vertex AI Agent Builder / Agent Engine | Modell- og dataintegrasjon | ~0,0864 USD/vCPU-t + 0,25 USD/1000 økt-hendelser, gratis kvote inntil 180 000 vCPU-sek/mnd |
Kostnadsfellen: når V2 blir dyrere enn V1
Det mest oversette elementet i lanseringen er at V2 ikke er billigere krone for krone. Listeprisene per vCPU-time og GB-time er høyere enn V1, og gevinsten kommer kun gjennom minnegjenvinning etter 120 sekunders inaktivitet. For en kort chatbot-agent som svarer på noen sekunder og aldri ligger inaktiv lenge nok til å utløse gjenvinningen, blir nettoresultatet en ren prisøkning uten kompenserende besparelse.
For team som vurderer migrering, er anbefalingen å modellere den faktiske øktprofilen før man bytter plattformversjon. Agenter med lange, sesjonsbaserte samtaler, agenter som venter på asynkrone verktøykall, eller agenter som brukes sjelden men må være raskt tilgjengelige, er de mest sannsynlige vinnerne. Korte, høyfrekvente forespørsler risikerer å bli dyrere uten målbar brukeropplevelsesgevinst, siden latensforskjellen på et par sekunder sjelden merkes av sluttbrukeren i en kort interaksjon.
Markedseffekt: agent-skyen som egen infrastrukturkategori
Lanseringen bekrefter det bransjeanalytikere har omtalt som “agent-skykrigen” gjennom 2026: en konkurranse mellom AWS, Microsoft og Google om å eie infrastrukturlaget der AI-agenter faktisk kjører, atskilt fra laget der de trenes eller finjusteres. Dette er en strategisk endring fra 2023-2024, da skyleverandørenes AI-satsing i hovedsak dreide seg om tilgang til grunnmodeller gjennom API-er som Bedrock, Azure OpenAI Service og Vertex AI.
Nå bygges det egne, spesialiserte kjøretidslag med funksjoner som minnehåndtering, øktisolasjon, verktøykatalog-integrasjon og observabilitet skreddersydd for agenter. For nordiske skyarkitekter betyr dette at valg av agent-runtime i praksis er et infrastrukturvalg på linje med valg av databaseleverandør eller meldingskø, ikke bare et valg av hvilken språkmodell man bruker. Feilvalg her kan bli dyrt å reversere når agent-arbeidslaster først er bygget rundt en spesifikk leverandørs kjøretidssemantikk.
Sikkerhet og pålitelighet: hva snapshot-modellen krever
Ingen bekreftet sikkerhetssårbarhet er rapportert i Runtime V2 ved lansering, men snapshot-basert gjenoppretting reiser spørsmål som sikkerhetsteam bør stille før de ruller ut V2 i produksjon. Når AWS gjenoppretter et miljø fra et lagret øyeblikksbilde i stedet for å starte helt på nytt, må man sikre at prosesstilstand, midlertidige legitimasjoner, sockets og bufrede data ikke lekker mellom økter eller gjenbrukes etter at de er utløpt.
Kode som antar en helt fersk prosess, unik oppstartstid, eller engangs-initialisering ved hver kjøring, kan oppføre seg annerledes etter en snapshot-gjenoppretting enn ved en tradisjonell kaldstart. Agenter som cacher korttidslegitimasjon, verktøykataloger fra AgentCore Gateway, eller tilfeldige frø for kryptografiske operasjoner i minnet, bør gjennomgås spesifikt med tanke på om denne tilstanden er trygg å gjenbruke etter en gjenoppretting. Kombinert med at CloudFormation og CDK ennå ikke støtte plattformversjonen fullt ut, øker dette risikoen for konfigurasjonsdrift dersom team ruller ut V2 manuelt uten infrastruktur-som-kode-dekning.
Hva dette betyr for norske og nordiske skyteam
Norske selskaper som allerede har flyttet AI-arbeidslaster til AWS, står nå overfor et konkret valg: eu-west-1 i Irland er nærmeste V2-region, ikke en nordisk region. For selskaper med strenge krav til datalokasjon i Norge eller EØS for øvrig, kan dette bety at man må vente på regional utvidelse før man kan dra nytte av V2 sine ytelsesforbedringer i produksjon, eller akseptere at agent-arbeidslasten kjører med data som krysser til Irland.
For finanssektoren og andre regulerte bransjer i Norden, som allerede balanserer EU sin AI-forordning mot skyleverandørenes internasjonale infrastruktur, legger dette nok et lag med kompleksitet til beslutningen om hvilken skyplattform som skal bære agent-arbeidslaster fremover. Valget handler ikke lenger bare om hvilken språkmodell som gir best svar, men om hvilken kjøretidsarkitektur som gir riktig balanse mellom kostnad, latens og geografisk plassering av data.
Slik migrerer team fra V1 til V2
AWS har designet V2 som en opt-in-endring for å unngå brå brudd på eksisterende produksjonssystemer. Den praktiske migreringsveien starter med å identifisere agenter som passer profilen for gevinst: lange økter, periodisk inaktivitet over 120 sekunder, og toleranse for noen minutters forsinket klargjøring ved første oppstart av en ny runtime-versjon.
aws bedrock-agentcore-control update-agent-runtime \
--agent-runtime-id MY_RUNTIME_ID \
--platform-version V2 \
--region eu-west-1Etter å ha satt plattformversjonen, bør team kjøre kontrollerte kanarien-utrullinger fremfor å bytte alle agenter samtidig, gitt at oppsettstiden for en ny V2-runtime kan ta flere minutter mens AWS forbereder og lagrer et øyeblikksbilde. Fordi CloudFormation og CDK-støtte ikke var komplett ved lansering, må mange team i praksis sette parameteren via AWS CLI eller SDK-kall inntil infrastruktur-som-kode-verktøyene tar igjen.
Fem spådommer for agent-runtime-markedet fremover
Basert på tempoet i utrullingen og konkurrentenes bevegelser, er det mulig å skissere hvor markedet for agent-kjøretid trolig beveger seg de neste 12-18 månedene.
- Microsoft og Google vil trolig svare med egne minneoptimaliserte kjøretidsversjoner innen første halvår 2027, gitt hvor raskt AWS fulgte opp AgentCore GA med Runtime V2 bare fem uker senere.
- Flere regioner, inkludert nordeuropeiske alternativer nærmere Norden enn Irland, vil trolig legges til i V2 i løpet av de kommende kvartalene etter mønsteret fra tidligere AWS-tjenestelanseringer.
- Committed-baseline-rabatter for forutsigbar agent-belastning vil sannsynligvis bli en standard prisfunksjon på tvers av alle tre store skyleverandører, ettersom kunder med jevn arbeidsmengde presser på for lavere effektiv pris enn ren forbrukstakst.
- Infrastruktur-som-kode-støtte gjennom CloudFormation, CDK, Terraform og Pulumi vil trolig komme innen utgangen av 2026, ettersom manuell konfigurasjon av produksjonskritiske agent-runtimer er en uholdbar driftsmodell i lengden.
- Flere selskaper vil sannsynligvis innføre formelle kostnadsmodeller for agent-økter, ettersom kombinasjonen av variabel øktlengde og ulike prismodeller på tvers av leverandører gjør det stadig vanskeligere å budsjettere AI-agent-drift uten dedikert FinOps-verktøy for nettopp denne arbeidslastkategorien.
Praktiske råd før du flipper bryteren til V2
Før noe team i Norge eller Norden setter platformVersion til V2 i produksjon, bør fire ting sjekkes. Først: mål den faktiske fordelingen av øktlengder for agenten det gjelder, siden gevinsten kun kommer med inaktivitet over 120 sekunder. Dernest: bekreft at agenten opererer i, eller kan flyttes til, en av de fem støttede regionene uten å bryte krav til datalokasjon. For det tredje: gjennomgå all kode som cacher tilstand, legitimasjon eller tilfeldige verdier i minnet, med tanke på snapshot-gjenoppretting. Til slutt: regn på totalkostnaden med de nye listeprisene, ikke bare den isolerte kaldstartgevinsten, siden en rask agent som koster mer per time ikke nødvendigvis er en god handel for virksomheten.
Konklusjonen: infrastruktur følger nå agentene, ikke omvendt
Bedrock AgentCore Runtime V2 er i seg selv en teknisk oppdatering av ett produkt fra én skyleverandør. Men lansert bare fem uker etter AgentCore sin generelle tilgjengelighet, og fulgt av rask tredjeparts benchmarking og allerede modne konkurrentprodukter fra Microsoft og Google, illustrerer den noe større: skyinfrastrukturen bygges nå eksplisitt rundt agentenes atferdsmønster, ikke lenger rundt gamle forutsetninger fra webapplikasjoner og batch-jobber. For nordiske team betyr det at valget av agent-runtime bør behandles som en arkitekturbeslutning med samme tyngde som valg av database eller meldingskø, ikke som en detalj man kan justere senere uten kostnad.
Ofte stilte spørsmål
Hva er Amazon Bedrock AgentCore Runtime V2?
Det er en ny plattformversjon av AWS sitt administrerte kjøremiljø for AI-agenter, lansert i generell tilgjengelighet 18. september 2026. Den bruker elastisk minnegjenvinning og gjenoppretting fra øyeblikksbilder for å redusere kaldstarttider, og aktiveres ved å sette platformVersion til V2.
Er V2 billigere enn V1?
Ikke nødvendigvis. Listeprisene per vCPU-time og GB-time er høyere i V2. Besparelsen kommer kun fra minnegjenvinning etter 120 sekunders inaktivitet, så korte, hyppige agentøkter kan faktisk bli dyrere.
Hvilke regioner støtter Runtime V2 ved lansering?
Fem regioner: us-east-1, us-east-2, us-west-2, eu-west-1 (Irland) og ap-northeast-1 (Tokyo). Ingen nordisk eller skandinavisk region er inkludert ved lansering.
Hvordan sammenlignes AgentCore Runtime V2 med Azure AI Foundry Agent Service?
Azure AI Foundry er tettere integrert med Azure sin identitets- og governance-stack og bruker en kombinasjon av pris per token og pris per verktøykall, mens AWS sin V2 er mer isolert fokusert på kjøretidseffektivitet gjennom minnehåndtering og snapshot-oppstart.
Hvordan sammenlignes den med Google Vertex AI Agent Builder?
Google tilbyr en gratis månedlig kvote på inntil 180 000 vCPU-sekunder, noe AWS ikke gjør for AgentCore. Vertex AI sin rapporterte pris ligger også noe lavere per vCPU-time enn AWS sin nye V2-takst, men prismodellene er ikke direkte sammenlignbare på grunn av ulik struktur for økt-hendelser.
Støtter Terraform eller CloudFormation V2 ennå?
Ved lansering manglet både AWS CloudFormation og AWS CDK støtte for å sette plattformversjon-parameteren. Team må derfor i praksis konfigurere V2 via AWS CLI eller SDK inntil infrastruktur-som-kode-verktøyene oppdateres.
Er det trygt å bruke V2 for agenter som håndterer sensitive data?
Ingen bekreftet sårbarhet er rapportert, men snapshot-gjenoppretting krever at team gjennomgår kode som cacher legitimasjon, tilstand eller tilfeldige verdier i minnet, for å unngå at utløpt eller delt tilstand gjenbrukes feilaktig etter en gjenoppretting.
Bør norske selskaper bytte til V2 med en gang?
Kun for agenter med lange, sesjonsbaserte arbeidslaster som jevnlig ligger inaktive i over 120 sekunder, og der eu-west-1 i Irland er en akseptabel region for databehandling. For korte, høyfrekvente agenter er gevinsten trolig for liten til å oppveie den høyere listeprisen.
