Vad Som Lanserades den 6 Augusti, och Var
AWS eget tillkännagivande beskriver Runtime instances som 'persistent, hanterad EC2-infrastruktur för AI-agenter i produktion med multiagentsamarbete, GPU-stöd och sessioner som varar upp till 14 dagar'. Den siffran är den viktigaste förändringen: de AgentCore Runtime-microVM:er som AWS tidigare levererade är begränsade till 8 timmar per anrop, vilket fungerar för en enskild uppgift men inte för en agent som ska fortsätta arbeta, övervaka eller vänta på externa händelser under flera dagar.
Den regionala tillgängligheten vid lansering omfattar US East (Ohio, N. Virginia), US West (Oregon), Asien-Stillahavsområdet (Mumbai, Singapore, Sydney, Tokyo) och Europa (Frankfurt, Irland). För varje EU-organisation som behöver hålla databehandlingen av agentarbetsbelastningar inom EU av lokaliserings- eller avtalsskäl är tillgängligheten i Frankfurt och Irland redan vid lanseringen - inte månader senare - detaljen värd att notera.
Hur Agenter Egentligen Pratar med Varandra: en Delad Katalog, Inte ett API
AWS eget utarbetade exempel är konkret: en kodskrivande agent sparar sin utdata på en sökväg som /tmp/agentcore-session/{session-id}/code.py, och en andra, granskande agent läser från samma sökväg med samma sessions-ID, och samordnar sig via det delade filsystem en runtime-instans tillhandahåller inom en session, i stället för via direkta API-anrop mellan de två agenterna.
Det är en väsentligt annorlunda arkitektur än det förfrågan-svar-mönster som de flesta ramverk för agentorkestrering använder, och det spelar roll bortom ren bekvämlighet. En delad sessionskatalog är en delad förtroendegräns: varje agent med skrivåtkomst till den sökvägen kan i princip ändra vad en annan agent läser, vilket utgör en lateral rörelseyta inom det AWS presenterar som en enda isolerad session - något en säkerhetsgranskning av AgentCore måste testa explicit i stället för att ta för givet.
Den Verkliga Förskjutningen: AI-kompute Dyker Nu Upp på Fakturan Som en Server
Prissättningen för Runtime instances är standardpris för EC2-instanser plus en extra AgentCore-orkestreringsavgift, och AWS egen exempelkonfiguration - en c7g.2xlarge-instans med 8 vCPU:er och 16 GiB minne, som kör Arm64 eller x86_64 Linux - läses som en serverspecifikation eftersom det är en. Sessioner kan stoppas och startas om för att undvika att betala för inaktiva perioder, men en provisionerad instans som består i upp till 14 dagar är ett fundamentalt annorlunda kostnadsobjekt än ett tillståndslöst inferensanrop som faktureras per token.
För varje finans- eller plattformsteam som hittills har budgeterat generativa AI-utgifter rent som en inferenskostnadspost är detta punkten där agentiska AI-arbetsbelastningar börjar bete sig som resten av kompute-parken: kapacitetsplanering, hantering av inaktiv tid och val av instanstyp blir åter aktiva budgetfrågor, precis som innan den serverlösa modellen abstraherade bort dem.
Vad en EU-köpare Bör Kontrollera Innan Runtime Instances Används
Två frågor är värda att lösa före en produktionsdistribution. För det första bör man för varje arbetsbelastning som behandlar personuppgifter eller reglerade data bekräfta att tillgänglighet i Frankfurt eller Irland faktiskt uppfyller organisationens specifika lokaliserings- och behandlingsplatskrav, eftersom regional tillgänglighet för tjänsten inte automatiskt är detsamma som en garanti för var varje sessionsdata och varje loggutdata hamnar.
För det andra bör man vid varje multiagentdistribution som använder mönstret med delad sessionskatalog ställa samma fråga som ett säkerhetsteam skulle ställa om vilken delad filsystemarkitektur som helst: vilka agenter får skriva till den delade sökvägen, vad händer om en agents utdata är skadlig eller korrupt, och om den isolering AWS tillhandahåller mellan separata sessioner är den isoleringsgräns organisationen faktiskt behöver mellan de enskilda agenterna som körs inom en session.
Läs vidare: Din återställningsplan förutsätter att regionen kommer tillbaka | MCP tar bort sessioner och flyttar er inferensräkning
