Same agent, two clouds: where the agent runs on AWS and Azure

“Should we build our agents on AWS or Azure?” usually gets answered with a list of models. That stopped being a useful answer this year. Claude has been generally available in Microsoft Foundry since June, both catalogs are broad, and the model you want is very likely on both.

The real differences are in the platform around the model: where the agent loop runs, how it remembers, who it is when it calls your systems, and how it’s billed. That’s what this series compares. I take the support agent from ATC-001 and build it on both clouds, one layer at a time. This first part covers the runtime.

The short version

• Both clouds now offer the same two shapes. You can define an agent with configuration (model, instructions, tools) and let the platform run the loop. Or you can bring your own code in any framework and let the platform host it.
• Both isolate every session, both trace with OpenTelemetry, and both speak MCP and A2A.
• The real fork is identity. Azure puts agents into your Entra directory. AWS gives agents their own workload identity and connects to whatever identity provider you already use.
• Billing differs in the details. List prices for hosted compute are close. What differs is what you’re billed for and when.

The layer map

AWS

Azure

• Define it with configuration

  AWS: AgentCore harness Model, tools, skills, instructions. GA June 2026.

  Azure: Prompt agent Model, instructions, tools. GA with the new Agent Service, March 2026.

• Run your own code

  AWS: AgentCore Runtime Any framework. A microVM per session, up to 8 hours.

  Azure: Hosted agent Any framework. A sandbox per session. GA July 2026.

• Very long or heavy sessions

  AWS: Runtime on Instances EC2 in your account, GPU options, sessions up to 14 days.

  Azure: Long-running agents Crash recovery and steerable sessions. Preview.

• Conversation state

  AWS: AgentCore Memory, short-term Events per session, billed per GB.

  Azure: Conversations and items Built into the Responses API.

• Long-term memory

  AWS: AgentCore Memory, long-term Extraction strategies, including episodic.

  Azure: Memory store User profile, summaries, procedural. Preview.

• Identity

  AWS: AgentCore Identity Workload identity, token vault, any OIDC provider.

  Azure: Microsoft Entra Agent ID The agent is an identity in your directory.

• Tools

  AWS: AgentCore Gateway APIs and Lambda functions exposed as MCP tools.

  Azure: Toolboxes, API Management One governed MCP endpoint per tool set.

• Tracing

  AWS: AgentCore Observability CloudWatch, OpenTelemetry.

  Azure: Foundry tracing Application Insights, OpenTelemetry.

• Safety and policy

  AWS: Guardrails and AgentCore Policy Cedar rules checked on every tool call.

  Azure: Foundry guardrails Content Safety and Prompt Shields. Tool-call checks in preview.

Two ways to define an agent

With configuration. The AWS harness, generally available since June, lets you declare the model, tools, skills and instructions, and AgentCore runs the loop. Each session gets its own microVM with a filesystem and a shell. You can switch models mid-session, and you can export the agent to Strands code if you outgrow configuration. Azure’s equivalent is the prompt agent: model, instructions and tools, versioned, running on the Responses API.

For the support agent, either is enough. It has two tools, a short system prompt and no unusual control flow. I’d start with configuration on whichever cloud you choose, and only move to code when the configuration fights you.

There’s one billing difference worth knowing. On Azure, prompt agents carry no runtime charge. You pay for model tokens and the tools they use. On AWS, the harness is free as a feature, but its sessions run on AgentCore Runtime, so you pay Runtime compute. For a chat agent that spends most of its time waiting on the model, that compute is small. It isn’t zero.

With your own code. AgentCore Runtime runs a container or a code package built with any framework: Strands, LangGraph, the OpenAI Agents SDK, the Claude Agent SDK, or your own. It speaks HTTP, WebSocket, MCP, A2A and AG-UI. Each session gets a dedicated microVM for up to 8 hours, with a 15-minute default idle timeout. The new Runtime version, released in September, starts sessions from a snapshot, bringing typical cold starts down to about two seconds, and bills for memory actually used instead of peak. For multi-day jobs or GPU work, Runtime can now run on EC2 instances in your own account, with sessions of up to 14 days.

Azure’s hosted agents, generally available since July, take the same approach. You bring a container or a package built with Agent Framework, LangGraph, the OpenAI Agents SDK, the Claude Agent SDK or the GitHub Copilot SDK, and each session gets its own sandbox. The detail I like is what happens when a session goes idle. After a configurable timeout (2 to 60 minutes, 15 by default) the compute is released and the session’s files are saved. Calling again with the same session ID restores it, and sessions are only deleted after 30 days without use. Sizes go up to 2 vCPUs and 4 GiB per session. Hosted agents speak the OpenAI-compatible Responses protocol, plain HTTP and WebSocket, A2A, and Microsoft’s Activity protocol for Teams.

Memory: built in on one side, a separate service on the other

On Azure, conversation state comes with the API. A conversation holds items, every turn is a call against it, and you don’t build anything. Long-term memory is a separate Memory store, still in preview. It can keep a user profile, chat summaries and, new this year, procedural memory: what worked last time for this kind of task.

On AWS, memory is its own AgentCore service, with short-term events for the conversation and long-term records extracted by strategies you choose. It’s more explicit and more configurable, and it’s billed directly. Since October 6, short-term memory is billed per gigabyte ingested, retrieved and stored; long-term memory is billed per thousand records.

For the support agent, short-term conversation memory is all you need on day one. Add long-term memory when you have a reason, like remembering a customer’s preferences across tickets, and a way to check it isn’t remembering the wrong things.

Identity is the real fork

This is where the two clouds genuinely disagree.

Azure makes the agent an identity in your directory. With Microsoft Entra Agent ID, an agent identity is a special kind of service principal, created from a blueprint that describes a class of agents. In Foundry, unpublished agents share a project identity, and each published agent gets its own. You grant access to that agent identity the same way you’d grant it to anything else in Entra. In production, it authenticates through a federated credential from the project’s managed identity, so no secret is stored anywhere. Agents can act on behalf of a signed-in user, carrying both identities, or on their own with app-only access.

If your company already runs on Microsoft 365 and Entra, this matters a lot. Your security team governs agents with the tools and processes they already use, and publishing an agent into Teams or Microsoft 365 Copilot is generally available. One thing to check: extending Conditional Access and identity protection to agents requires a Microsoft Agent 365 license.

AWS gives the agent a workload identity and acts as the broker. AgentCore Identity issues each agent a workload identity and keeps OAuth tokens and API keys in a token vault encrypted with KMS. Inbound, it accepts JWTs from any OAuth or OIDC provider: Okta, Entra ID, Cognito or your own. Outbound, it handles machine-to-machine and user-consent OAuth flows, with built-in providers such as Google, GitHub, Slack, Salesforce and Atlassian. Since April it can exchange a user’s token for a narrower one that carries both the user’s and the agent’s identity.

Put simply, Azure folds agents into the enterprise directory, and AWS makes the agent platform its own identity layer that plugs into whichever directory you have. Neither is better in the abstract. It depends on where your people and your access policies already live.

Watching it run

Both platforms trace with OpenTelemetry. AWS sends traces to CloudWatch and works with external tools such as Datadog and Langfuse. Azure sends them to Application Insights, and its trace format extends the OpenTelemetry generative-AI conventions with spans for agents, workflows and tool calls.

On safety, AWS has a head start on one specific thing: AgentCore Policy, generally available since March, checks every tool call against rules written in Cedar before the call runs. Since June, it can also run Bedrock Guardrails on the inputs of every gateway call and the outputs of the actions it authorizes. Azure’s Foundry guardrails cover the familiar content risks and prompt attacks through Azure AI Content Safety, and its agent-level checks on tool calls are still in preview. The next part of this series covers this layer in detail.

What it costs to run

Models and tools are billed separately on both clouds, and for most agents they’re the bigger number. For the hosted-code option, here’s one session with 1 vCPU and 2 GB of memory running for an hour, at published US rates:

Runtime	vCPU-hr	Memory-hr	Example hour
AgentCore Runtime, original	$0.0895	$0.00945	$0.108
AgentCore Runtime, new	$0.1276	$0.0169	$0.162
Foundry hosted agent	$0.0994	$0.0118	$0.123

AWS bills memory per GB-hour, Azure per GiB-hour; the difference is too small to matter here.

The rates are close. The billing rules matter more than the rates:

• AWS doesn’t bill CPU while the agent waits on I/O. An agent spends most of its life waiting on a model or a tool, so the effective cost is often well below the list rate. The new Runtime version also bills memory actually used rather than peak, so compare the two versions on your real usage, not on list rates.
• An idle session can keep holding compute until its idle timeout. The exception is AWS’s new Runtime, which reclaims idle memory after two minutes. For chat-style agents, keep the timeout short. A conversation that comes back later can restore its state: on Azure through saved session files, and on AWS through AgentCore Memory or session storage, which is still in preview.
• For configuration-defined agents, Azure adds no runtime charge. The AWS harness runs on Runtime compute.

For the support agent in ATC-001, all of this is a few dollars a month next to the model bill. Runtime pricing starts to matter for long-running agents that do real compute work between model calls.

What changed this year

If you built agents on either cloud before 2026, some of what you know is out of date.

• AWS: the original Bedrock Agents service is now called Agents Classic. It went into maintenance mode and closed to new customers on July 30, 2026. New work goes on AgentCore, where simple agents map to the harness.
• Azure: the Agent Service moved from the old threads-and-runs model to conversations and responses, and old thread data isn’t migrated. Classic connected agents weren’t carried forward; agent-to-agent calls now go through the A2A tool. The visual workflows in the Foundry portal are being retired on December 1, 2026, in favor of Microsoft Agent Framework workflows.

Which one for this agent?

Choose Azure if your company lives in Microsoft 365 and Entra, if the agent should show up in Teams or Copilot, or if you want configuration-defined agents with no runtime charge.

Choose AWS if your systems and data are already on AWS, if you need long or heavy sessions (8 hours, or up to 14 days on instances), or if you want deterministic policy checks on every tool call that are generally available today.

Or use both. Both platforms speak MCP and A2A, so a Teams-facing agent on Foundry can call an agent on AWS over A2A. That costs you a second control plane and some cross-cloud networking. Do it when there’s a real reason, not just because you can.

For a 15-person business with one support agent, the deciding question isn’t models or price. It’s where the helpdesk and your staff’s identities already live. Build the agent there.

Next in the series: tools and MCP, meaning how each cloud connects an agent to your systems and where the guardrails sit.

---

Status and prices as of October 2026. Several pieces mentioned here are in preview and will change. Primary sources: Amazon Bedrock AgentCore pricing, AgentCore Runtime sessions, the new AgentCore Runtime, AgentCore harness GA, Bedrock Agents Classic maintenance mode, Foundry Agent Service overview, Foundry hosted agents, Foundry agent identity, Microsoft Entra Agent ID, Foundry migration guide, Foundry workflows. Azure hosted-agent rates are from the Azure Retail Prices API.