The Cloud Giants Enter the Arena
Every major cloud provider now has an AI agent platform:
- AWS: Amazon Bedrock Agents
- Microsoft Azure: Azure AI Agent Service (now part of Microsoft Foundry Agent Service, renamed January 2026)
- Google Cloud: Vertex AI Agent Builder
These platforms promise easy deployment of AI agents with enterprise-grade infrastructure. And for many organizations, they’re the default choice — you’re already on AWS/Azure/GCP, so why not use their agent platform?
But default choices aren’t always optimal choices. This comparison examines what each platform offers, where they fall short, and when an open, cloud-agnostic approach makes more sense.
Amazon Bedrock Agents
Strengths
Deep AWS Integration: Native connections to S3, Lambda, DynamoDB, and other AWS services. IAM-based access control. CloudWatch for monitoring.
Knowledge Bases: Built-in RAG capabilities with S3/OpenSearch/Pinecone integration. Automatic chunking, embedding, and retrieval.
Guardrails: Content filtering, PII detection, configurable denied topics, response grounding checks.
Limitations
AWS Lock-In: Agents run only on AWS. Heavy dependency on Lambda, S3, and other AWS services. Migration to another cloud requires complete rebuild.
Model Restrictions: Limited to models available in Bedrock (Claude, Llama, Titan, Mistral). No OpenAI GPT-4 option. Can’t use self-hosted models.
Framework Lock-In: Must use Bedrock’s agent definition format. Can’t bring LangChain/CrewAI agents directly.
Testing Gaps: No built-in load testing, systematic evaluation, or adversarial testing.
Azure AI Agent Service
Strengths
Enterprise Compliance: SOC 2, HIPAA, FedRAMP certifications. Formal SLAs and enterprise support contracts.
Multi-Language SDKs: C#, Python, Java support. Strong .NET ecosystem integration.
Microsoft Ecosystem: Deep integration with Azure OpenAI, Microsoft 365, Dynamics, Active Directory.
Limitations
Azure Lock-In: Azure-first architecture. On-premises is secondary. Multi-cloud not well supported.
Framework Coupling: Optimized for AutoGen/Semantic Kernel. Bringing other frameworks is possible but not native.
Cost Complexity: Multiple Azure services contribute to cost. Enterprise agreements add procurement complexity.
Google Vertex AI Agent Builder
Strengths
Native Multimodal: Gemini models with native image/video/audio understanding. Long context windows (up to 2M tokens).
Google Search Grounding: Factual responses grounded in Google Search. Citation support for transparency.
Conversation Design: Strong NLU heritage from Dialogflow. Visual conversation flow builder.
Limitations
GCP Lock-In: Runs only on Google Cloud. Deep dependencies on GCP services.
Model Focus: Optimized for Gemini models. Other providers not first-class.
Enterprise Maturity: Historically more developer-focused. Enterprise features catching up.
The Open Alternative: Cloud-Agnostic Agent Platforms
An open, cloud-agnostic approach separates your agent platform from any specific cloud provider:
- Runs anywhere: Kubernetes on any cloud or on-premises
- Any framework: LangChain, CrewAI, custom — your choice
- Any model: OpenAI, Anthropic, Google, or self-hosted
- No cloud lock-in: Move between clouds without rebuilding
Key Differences
| Capability | AWS Bedrock | Azure AI | Google Vertex | Open/K8s-Native |
|---|---|---|---|---|
| Runs on | AWS only | Azure only | GCP only | Any K8s cluster |
| On-premises | No | Limited | No | Yes (first-class) |
| Air-gapped | No | No | No | Yes |
| Framework | Bedrock SDK | AutoGen/SK | Agent Builder | Any |
| Models | Bedrock models | Azure OpenAI | Gemini-first | Any (including self-hosted) |
| Testing | Basic | Basic | Basic | Integrated (load + eval + red-team) |
Where Cloud Platforms Fall Short
The Lock-In Problem
Cloud provider agent platforms create deep lock-in at multiple levels:
Code Lock-In: Provider-specific SDK calls. Moving to another cloud requires complete rewrite.
Infrastructure Lock-In: Lambda for AWS, Azure Functions for Azure, Cloud Functions for GCP. Each requires different tooling and operational knowledge.
Data Lock-In: Knowledge bases in provider-specific formats. Vector stores with proprietary APIs. Logs and metrics in provider-specific systems.
The Self-Hosted Gap
For organizations that need self-hosted deployment:
| Requirement | AWS | Azure | Open/K8s | |
|---|---|---|---|---|
| On-premises | No | Limited | No | Yes |
| Air-gapped | No | No | No | Yes |
| Self-hosted LLMs | No | Complex | No | Yes (Ollama, vLLM) |
For defense, government, and highly regulated industries, cloud-only isn’t an option.
The Testing Gap
This is where cloud platforms are weakest. None of them have integrated load testing, systematic evaluation, or adversarial/red-team testing. You need external tools with custom integration — or go without.
When Cloud Platforms Make Sense
Choose AWS Bedrock when you’re deeply committed to AWS, want managed infrastructure, and lock-in risk is acceptable.
Choose Azure AI when you’re a Microsoft enterprise shop needing compliance certifications and Microsoft ecosystem integration.
Choose Google Vertex AI when multimodal capabilities are critical and you’re invested in GCP.
When Cloud-Agnostic Makes Sense
- Multi-cloud strategy: Prevent per-cloud agent implementations
- Self-hosted requirements: Defense, government, healthcare with strict data requirements
- Framework investment: Existing LangChain/CrewAI agents deploy directly
- Model flexibility: Best model for each use case without constraints
- Testing requirements: Systematic load testing, evaluation, and red-teaming
- Cost optimization: Cheapest suitable model per task, no per-step platform fees
The Hybrid Approach
Some organizations use both — cloud providers for model APIs (Bedrock for Claude, Azure for GPT-4, Vertex for Gemini), but run their agent platform on cloud-agnostic Kubernetes. You get model access without platform lock-in.
The Bottom Line
Cloud provider agent platforms offer convenience at the cost of flexibility. For organizations deeply committed to a single cloud, they reduce operational burden.
For organizations that need multi-cloud, self-hosted, or framework flexibility, cloud-agnostic alternatives provide capabilities the cloud platforms don’t. The right choice depends on your constraints — but make it deliberately, not by default.
Key Takeaways
- Cloud platforms create deep lock-in: Code, infrastructure, data, and operational patterns
- Framework flexibility is limited: Bringing your own LangChain/CrewAI agents isn’t straightforward
- Self-hosted is an afterthought: None of the cloud platforms prioritize on-premises or air-gapped
- Testing is the biggest gap: No cloud platform has integrated load testing, evaluation, and red-teaming
- Cloud-agnostic alternatives exist: Kubernetes-native platforms run anywhere with any framework
- Hybrid approaches work: Use cloud model APIs without cloud platform lock-in