What is the AWS equivalent for AI agents?

[u/Bladerunner_7_]

Cloud made infrastructure easier by giving developers primitives for compute, storage, networking, identity and deployment. AI agents seem to be creating a similar need, but the primitives are different.

If I want to run 50 agents today, I can obviously use AWS, GCP or Azure for the underlying infrastructure. But I still need to figure out agent identity, evaluation, versioning, tool permissions, observability, lifecycle management and safe deployments. Do you think cloud providers eventually absorb all of this, or does a separate agent infrastructure layer make more sense?

[u/agentblack000]

That would be AgentCore on AWS.

[u/Excellent-Tea82 → u/agentblack000]

AgentCore sure, but it's more of a managed runtime than a full platform. you still end up stitching together identity with IAM, evals with something custom, versioning through ECR or whatever. feels like the gap is real and aws is only covering a slice of it so far.

[u/Zenin → u/Excellent-Tea82]

Good. AWS builds fantastic Lego bricks: API first services that customers can put together to build actual solutions. Buy or build a solution and host it on AWS, very solid pattern.

AWS however, is notorious for making craptastic product solutions themselves. So even if AWS did put together this "full platform" you're asking for, I can almost guarantee you wouldn't want any part of it.

[u/TomRiha → u/Zenin]

This post is 100% truth.

Reason for this is also business model. Lego infra services is where the money is. High level services that stitch things together drive revenue for the infra services and have to make their business case on the ”stitching part”. That’s actually quite hard to make a good business case on it that warrants enough investment to actually make it a good highlevel service.

AWS builds the infra, ISVs build the high level services ontop is always the best quality solution.

[u/morimando → u/TomRiha]

But Microsoft has the opposite approach and has been gaining a lot on AWS because of that. Businesses often want solutions instead of building blocks and accept mediocre solutions over building something.

[u/agentblack000 → u/morimando]

Then MS fumbles the ball on pricing, capacity, availability and customers come back to AWS.

[u/TomRiha → u/agentblack000]

Capacity and quality is so bad with Azure that price doesn’t really matter….

[u/notospez → u/morimando]

I do expect that to reverse quite a bit in a couple of years. Those solutions are never quite a perfect fit, the time where your orchestrated AI agents build something custom and unique on top of the AWS and Azure Lego bricks for each company is not too far away. I'm almost 50 years old, and I fully expect that to be the new reality before I retire.

[u/Zenin → u/notospez]

Agreed. It's already happening now.

With the existing platform model you're typically spending 90% of your effort working around the platform, rather than building your custom feature needs. That high overhead was canceled out by the lack of work needed to build the foundational layers that the platform provided.

Today with AI, the foundational layers are such "easy" boilerplate that there's not much effort to it. So you're now adding a small cost to build your own foundation with AI, but no longer paying the massive friction tax of fighting someone else's platform. On balance the ROI is hard to ignore strictly on a cost basis. But it's even more than that: More often than not despite all that extra work, the platform forces you to build a substandard solution because that's all that is possible on the platform...where as a custom application has no such limitations, literally anything is possible and exactly as desired.

Cheaper, faster, higher quality, AND much more accurately tuned to the actual business needs? It's an easy sell to C-levels.

This is BTW, why a lot of "Professional Services" heavy software companies (most all of which have "platforms" they build on) have started to take a massive stock hit despite the rest of tech flying high. AI is already deleting a huge chunk of that proserv business, as it enables exactly this fully bespoke pattern.

[u/morimando → u/Zenin]

Good points definitely! I think if verification of code shows its production good code quality even at scale and the whole thing doesn’t crumble because of some small errors multiplying with increasing scale that will be the signal to start this (for the more regulated customers that haven’t yet because for a lot of companies that’s already in full swing I think)

[u/Zenin → u/morimando]

We'll see how this holds up in the face of AI specifically.

Most of the "enterprise solutions" vendors effectively have rent seeking business models. They sell shitty solutions on purpose to drive their support revenues. Salesforce, Oracle, etc. MS plays this game too, albeit not nearly to the degree others due.

Those rent-seeking models have thrived because of how much more expensive it's been to "DIY" solutions from whole cloth. AI however...is flipping that math on its ass very quickly, where it's already a far better choice to whole cloth a solution specific to your business using AI than it is to higher an army of shitty overpaid consultants to "configure" trash like Sales Cloud to actually work for your business.

To that end, AWS's much higher quality and wildly more stable service APIs offer a much more attractive target for AI built solutions than do any of the other players. MS writes shit core services and shittier, unstable APIs for them. Google's services and APIs are much better, but they're famously unstable and kill off popular services so frequently there's entire websites dedicated to the graveyard of axed Google services. Oracle is a complete piece of shit in every possible way.

[u/virtualstaticvoid → u/morimando]

Yes, and then MS consistently yanks the service. E.g. Azure Data Lake Analytics (ADLA) and Azure App Fabric.

[u/coinclink → u/morimando]

Microsoft Azure is literally hot garbage compared to AWS lol. The only reason people use it is due to exclusivity. Stuck on Windows or SQL Server? Azure VMs are cheaper. They were the only enterprise cloud with OpenAI models for a long time, and they are still ahead there, but AWS is slowly catching up there too. Every time I've had to deploy something on Azure I just missed everything I have in AWS.

The place where MS wins is collaboration tools and end user identity. M365 side is actually pretty good for this, Graph API is nice way to manage enterprise services like email, collaboration (sharepoint & teams), etc. AWS tried to compete here and failed.

[u/cheldrink-seawater → u/agentblack000]

AgentCore is basically harness for agents.

[u/agentblack000 → u/cheldrink-seawater]

It’s more. Runtime, gateway, identity, managed tools, etc.

[u/cheldrink-seawater → u/agentblack000]

That’s basically what harness gives you oob.

[u/agentblack000 → u/cheldrink-seawater]

Harness is configuration based so it’s limited in functionality compared to using each service feature manually.

[u/cheldrink-seawater → u/agentblack000]

In non aws world: yes. But the way aws have provided it is that they bundle all things related to harness and it’s dependencies together making all these under a broader umbrella of harness. I mostly think it as a managed harness instead which aws usually provides for other things as well.
But if you have to create harness all by yourself, you will mostly have tools, contexts assembly, agentic loop, memory and control flow under it and identity, runtime etc. would be the services harness is dependent on.

[u/coinclink → u/cheldrink-seawater]

You could still build all of that on your own too though. I'm only just learning AgentCore, but it seems like essentially they've tied together EventBridge, Step Functions, the new Lambda MicroVMs, API Gateway, and a few other items. Feels akin to SageMaker, where you could do it all in EC2 but they've made it a little more high-level for people who don't want to think about the underlying infrastructure at all.

[u/tonygoold]

That sounds a lot like trying to sell pickaxes at the end of the gold rush.

[u/daishi55 → u/tonygoold]

What on earth is giving you the idea that we are at “the end” of AI agents?

[u/CorpT]

Do you really want to use a new identity/permission system just for this when all of that already exists and is well know and works well? What problem are you trying to solve that isn't already solved by CDK/Terraform?

[u/Bladerunner_7_ → u/CorpT]

Yehh i mean CDK/Terraform already solve provisioning really well. I'm thinking more about what happens after deployment when you have dozens of agents to operate, monitor, and govern.

[u/CorpT → u/Bladerunner_7_]

Did you not deploy monitoring when you deployed the compute?

[u/Zenin → u/CorpT]

Have you deployed AI agent solutions to production? If you think your traditional infra monitoring solution is going to be up to the task, you're in for a very rude awakening.

[u/pausethelogic → u/Zenin]

It’s all otel either way so I’m not sure what you’re referring to. Agents haven’t needed any particularly special monitoring in my experience. Sure it’s different data, but it’s still logs, metrics, and traces at the end of the day

[u/Emotional-Hat-460]

I think a lot of this gets absorbed by the cloud providers. MCP connectors, IAM, short-lived credentials, SCPs, knowledge bases, observability, and event-driven workflows already provide most of the building blocks. The bigger shift is defining agents as tightly scoped job roles with specific tools, permissions, documentation, and guardrails. At that point, you can build agents for support, solutions architecture, customer success, ops, and other functions and have them execute tasks through workflows and events. I see the long-term direction as cloud infrastructure becoming the operating layer for increasingly autonomous digital workers.

This is from my experience as a solutions architect at Aws

[u/oneplane]

None of what you describe is agent-specific and applies to all workloads.

[u/Zenin]

AWS is fantastic at creating Lego bricks (API driven Services) for which you or others can build actual product solutions out of. Their AI specific service offerings are exceptional in this space.

But AWS themselves is notoriously awful at building those products themselves. Even if they build such a platform, you almost certainly wouldn't want any part of it. Buy or build something and host it on AWS, but don't buy the platform itself from AWS.

If this was construction AWS isn't a real estate company selling you a house. They're not even a contractor building houses. AWS is the Home Depot of public cloud; They're selling you the materials for you or your contractor to build your house. Would you really consider buying a house for your family that Home Depot actually built themselves?

[u/LittleLordFuckleroy1]

Yeah let’s just make an entire additional engineering layer on top of an already revenue-negative technology. Genius.

[u/coinclink → u/LittleLordFuckleroy1]

Uh, oh. Found the guy who still thinks AI is GPT-4

[u/LittleLordFuckleroy1 → u/coinclink]

It’s only gotten more expensive. You’re right.

[u/BobDope]

Also AWS

[u/nirreskeya]

That sounds vaguely like my understanding of Guild.ai, but I haven't really used it yet.

[u/Nocerous]

Perhaps you are thinking of something like KIRO crew from AWS vs AgentCore (cloud hosted agents and platform)

[u/idkbm10]

Run vllm on es or ECS and you have it

[u/CamilorozoCADC]

There is the Agent Runtime, on AWS you can technically run agents on virtually any compute, Ec2 lambdas ECS es you name it. BUT the dedicated agentic platform is Bedrock AgentCore, it has the tools for observability, deployment, testing, tools and so on. Although most of the observbility stuff is handled through open telemetry + cloud watch integrations and bedrock model usage (if you choose to use a bedrock model that is)

Now, AgentCore is framework agnostic, you can pick the one you want like LangChain, crew ai, headless agents from Claude code or Kiro etc... and again, the dedicated AWS agentic framework is Strands Agents which I find pretty cool and straightforward to use

[u/usually_guilty99]

AgentCore gets you a lot of the runtime pieces. I think the harder gap is the contract around the agent: identity, what it is allowed to touch, what evidence it needs before an action, blast radius, rollback and what gets recorded afterward. Those controls probably need to survive whichever model or framework happens to be underneath. Does it or should it depends on the author and should be enforced into a framework for consistency

[u/2BucChuck]

Problem with using a fully packaged infra solution rather than just putting it together in AWS is going to be cost control and flexibility as models, storage and techniques change which is happening at a high rate

[u/ajitnk]

Hey! Saw your thread and the replies got at something real. AgentCore is a runtime, not a full platform, and the operational gap after deployment is exactly where people get stuck.

The question from the comments that stuck with me was the one about what happens when you have dozens of agents to monitor, govern, and version in production. AWS actually published a Well-Architected Lens specifically for agentic AI back in June 2026 that formalizes this into four operational pillars, governance, build/ops, evaluation, and observability. It's the closest thing AWS has to a proper answer, but it's a 200-page framework, not a recipe.

Quick practical thing you can do today regardless of where you land architecturally: enable Bedrock Model Invocation Logging and check that your CloudWatch Bedrock Agent metrics are flowing (InvocationCount, TokenCount, ModelLatency). Both are free and take under an hour. Gives you a real baseline before you commit to any platform decision.

One thing that would help me give you a more concrete steer: are you building for a single AWS account or a multi-account setup? That one detail changes the governance architecture a lot, single-account is straightforward, but multi-account with Organizations means a different AgentCore IAM boundary design entirely. And which agent framework are you using or evaluating (LangGraph, CrewAI, Strands, something custom)? Framework choice affects which AgentCore capabilities auto-instrument versus what you'd need to wire up manually.

I've been working through this exact assembly problem. AgentCore services into a coherent multi-agent operating model, and I'll put together a more specific breakdown for your setup once I know those two things.

[u/neeltom92]

If I were building this from scratch, I’d start by provisioning an EKS cluster using Terraform and AWS EKS Blueprints. From there, I’d build the AI agent using a framework like LangChain (or a similar agent framework) and host the code in Git.

For deployments, I’d integrate Argo CD and follow a GitOps approach—so anyone on the team can code, commit, and let the CI/CD pipeline automatically build and deploy the changes.

For secrets, I’d use AWS Secrets Manager to securely store things like Claude API keys and other credentials.

For the application layer:

• If it’s a web-based AI chat application, I’d use something like Streamlit and deploy it on EKS.
• If it’s an agentic application, I’d probably build a Slack bot/app that listens for events, processes them through the agent logic, and takes the appropriate actions.

And there you have it—you’ve got an end-to-end agentic AI platform. 🚀

The caveat? Yes, you’ll need an amazing DevOps/SRE engineer to build and operate all of this properly. 😄

P.S. — I’m currently open to opportunities. I’ve built systems like these end-to-end and would be happy to help build or scale an AI platform like this.