Mix and Match: Serving an ADK Agent to AWS and Azure

8.3 relevance

Serving a Google ADK agent to AWS and Azure via A2A, highly technical and novel for multi-cloud agent interoperability.

Cloud dev.to

Answer the board on AI readiness

Arrive with evidence, not opinion. See how your foundation benchmarks against your peers, get a clear read, and leave with a ranked place to start.

Why It Matters

For platform engineers building multi-cloud agent systems, this reveals a critical gap in ADK's A2A implementation where first-party clients can't reach deployed servers, forcing reliance on third-party SDKs or manual URL overrides.

Key Takeaways

Patch the agent card's interface URL to the public endpoint before deploying ADK agents to Cloud Run, or use the agent-framework A2AAgent client which ignores the card's routing field.

Mix and Match: Serving an ADK Agent to AWS and Azure

Summary

Google's ADK agent, deployed on Cloud Run, can serve requests from AWS Bedrock and Azure Container Apps via the A2A protocol, but the ADK's own RemoteA2aAgent client fails because to_a2a() writes the internal bind address (0.0.0.0:8080) into the agent card instead of the public HTTPS URL. The error surfaces as a misleading AttributeError about status_code, masking the real transport failure. The project demonstrates multi-cloud agent interoperability using A2A v1.0 with no shared credentials, running three agents on three clouds coordinated by a single orchestrator.

Author

xbill