Every DevOps engineer knows the frustration of juggling identities across platforms. One minute you’re debugging a stateless Cloud Run service, the next you’re trying to SSH into an EC2 instance managed by Systems Manager. Both environments are modern, flexible, and secure on their own. Yet without a shared access layer, it feels like you’re duct-taping two halves of a workflow together.
Cloud Run runs containerized workloads in Google Cloud, triggered by HTTP or event-based requests. EC2 Systems Manager gives AWS engineers centralized control of instances through automation and policy-driven sessions. Pairing them allows cross-cloud orchestration, consistent identity, and repeatable execution—ideal for organizations already juggling multi-cloud infrastructure.
Here’s the logic: let Systems Manager handle operational commands and patching for AWS resources while Cloud Run acts as the automation control plane. Cloud Run triggers actions securely using a scoped role in IAM and hands off requests through a managed identity that Systems Manager trusts. The result is zero shared credentials, auditable actions, and service-to-service communication that respects boundaries.
To make the integration clean, focus on identity flow. Tie Cloud Run’s service account to OIDC federation with AWS IAM. In AWS, configure a trust policy that allows Cloud Run to assume a role limited to Systems Manager actions. When Cloud Run invokes a command or automation document, that role executes under strict least-privilege rules. Nothing static, nothing stored, everything verified in real-time.
Best practices make the connection durable:
- Rotate service account keys out entirely. Use workload identity federation.
- Keep IAM policies narrow. Start with
ssm:SendCommand and expand only as required. - Log everything. Send both GCP and AWS audit logs to a single sink for review.
- Use environment variables to inject configuration, never secrets.
Teams report big wins from this pattern:
- Faster compliance because every access path is pre-approved.
- Reduced manual toil through automated patch cycles.
- Consistent identity across automation stacks.
- Clean, central audit trails that satisfy SOC 2 and ISO requirements.
- Fewer permission tickets and faster developer velocity.
For developers, the real joy is speed. Cloud Run CI jobs can now trigger EC2 updates through Systems Manager in seconds without waiting for human approval. No more bouncing between dashboards or reconfiguring roles mid-deploy. Debugging feels less like paperwork and more like engineering again.
Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Instead of writing brittle IAM glue code, hoop.dev connects identity providers like Okta and Google directly, transforming security rules into living automation that watches every endpoint across clouds.
How do I connect Cloud Run and EC2 Systems Manager?
Use workload identity federation to let Cloud Run’s service account assume an AWS IAM role through OIDC. That role should only allow Systems Manager operations defined in your automation scope. This setup removes static credentials and simplifies audit tracking across both clouds.
As AI assistants begin triggering deployment pipelines, cross-cloud identity becomes even more critical. You want guardrails that ensure automated agents only act inside approved scopes. Integrations like Cloud Run EC2 Systems Manager form that safe boundary where AI tools can operate with precision, not risk.
The takeaway is simple: make your automation predictable and secure. Connect smart identities, log everything, and trust no credential that lives longer than a job run.
See an Environment Agnostic Identity-Aware Proxy in action with hoop.dev. Deploy it, connect your identity provider, and watch it protect your endpoints everywhere—live in minutes.