Hvad Der Blev Lanceret den 6. August, og Hvor
AWS' egen meddelelse beskriver Runtime instances som 'vedvarende, administreret EC2-infrastruktur til produktions-AI-agenter med multi-agent-samarbejde, GPU-understøttelse og sessioner, der varer op til 14 dage'. Det tal er hovedændringen: de AgentCore Runtime-microVM'er, AWS tidligere leverede, er begrænset til 8 timer pr. kald, hvilket er brugbart til en enkelt opgave, men ikke til en agent, der skal blive ved med at arbejde, overvåge eller vente på eksterne hændelser over flere dage.
Den regionale tilgængelighed ved lanceringen omfatter US East (Ohio, N. Virginia), US West (Oregon), Asien-Stillehavsområdet (Mumbai, Singapore, Sydney, Tokyo) og Europa (Frankfurt, Irland). For enhver EU-organisation, der skal holde databehandlingen af agentarbejdsbelastninger inden for EU af hensyn til residens eller kontraktlige krav, er tilgængeligheden af Frankfurt og Irland allerede ved lanceringen - ikke måneder senere - det bemærkelsesværdige detalje.
Hvordan Agenter Faktisk Taler Sammen: en Delt Mappe, Ikke en API
AWS' eget gennemarbejdede eksempel er konkret: en kodeskrivende agent gemmer sit output på en sti som /tmp/agentcore-session/{session-id}/code.py, og en anden, gennemgående agent læser fra netop den sti med samme sessions-ID, og koordinerer via det delte filsystem, en runtime-instans stiller til rådighed inden for en session, i stedet for via direkte API-kald mellem de to agenter.
Det er en væsentligt anderledes arkitektur end det forespørgsel-svar-mønster, de fleste rammer til agentorkestrering bruger, og det betyder mere end blot bekvemmelighed. En delt sessionsmappe er en delt tillidsgrænse: enhver agent med skriveadgang til den sti kan i princippet ændre, hvad en anden agent læser, hvilket udgør en lateral bevægelsesflade inden for det, AWS præsenterer som en enkelt isoleret session - noget en sikkerhedsgennemgang af AgentCore skal teste eksplicit i stedet for at antage.
Det Egentlige Skift: AI-compute Vises Nu på Regningen Som en Server
Prisfastsættelsen for Runtime instances er standard EC2-instanspris plus et ekstra AgentCore-orkestreringsgebyr, og AWS' egen eksempelkonfiguration - en c7g.2xlarge-instans med 8 vCPU'er og 16 GiB hukommelse, der kører Arm64 eller x86_64 Linux - læses som en serverspecifikation, fordi det er en. Sessioner kan stoppes og genstartes for at undgå at betale for inaktive perioder, men en provisioneret instans, der består i op til 14 dage, er et grundlæggende anderledes omkostningsobjekt end et tilstandsløst inferenskald faktureret pr. token.
For ethvert finans- eller platformsteam, der hidtil har budgetteret generativt AI-forbrug rent som en inferensomkostningspost, er dette punktet, hvor agentiske AI-arbejdsbelastninger begynder at opføre sig som resten af compute-parken: kapacitetsplanlægning, styring af inaktiv tid og valg af instanstype bliver igen aktive budgetspørgsmål, ligesom de var, før den serverløse model abstraherede dem væk.
Hvad en EU-køber Bør Tjekke Før Adoption af Runtime Instances
To spørgsmål er værd at afklare før en produktionsudrulning. For det første bør man for enhver arbejdsbelastning, der behandler personlige eller regulerede data, bekræfte, at tilgængelighed i Frankfurt eller Irland faktisk opfylder organisationens specifikke residens- og behandlingslokationskrav, da regional tilgængelighed af tjenesten ikke automatisk er det samme som en garanti for, hvor hvert stykke sessionsdata og hvert logoutput ender.
For det andet bør man ved enhver multi-agent-udrulning, der bruger mønstret med delt sessionsmappe, stille det samme spørgsmål, et sikkerhedsteam ville stille om enhver delt-filsystem-arkitektur: hvilke agenter kan skrive til den delte sti, hvad sker der, hvis en agents output er ondsindet eller korrupt, og om den isolation, AWS giver mellem separate sessioner, er den isolationsgrænse, organisationen faktisk har brug for mellem de enkelte agenter, der kører inden for en session.
Læs videre: Din beredskabsplan går ud fra, at regionen vender tilbage | MCP fjerner sessioner og flytter jeres inferensregning
