You have the template written, the stack diagram clear, and the AWS bucket mocking you from the other side of the cloud divide. You want Azure Bicep deploying infrastructure that speaks cleanly to S3, without the usual swamp of credentials and mismatched policies. It should just work. That’s what this setup fixes.
Azure Bicep defines infrastructure through declarative templates for the Azure platform. S3 is Amazon’s well-known storage service built around object-level access control. On paper, they live in different worlds. In practice, modern teams need both: Azure workloads pushing artifacts into S3, pipelines archiving logs there, or hybrid deployments that balance cost and scale. Getting these tools to cooperate efficiently means understanding how identity and authorization flow between clouds.
The key is minimal trust, not manual keys. Azure Bicep can provision Azure functions or containers with federated identities that use OpenID Connect (OIDC) to request short-term access to AWS. S3 grants that access through a role configured for cross-cloud federation. No long-lived secrets, no environment variables hanging around for someone to miscopy later. You apply infrastructure changes through Bicep, and those changes can trigger your automation to upload objects or fetch configurations from S3 securely.
How do you connect Azure Bicep and S3? You create an Azure-managed identity that maps to an AWS IAM role using OIDC. The identity is authorized for specific S3 actions like PutObject or GetObject. Then you reference that identity in your Bicep deployment logic. The workflow ensures only approved workloads talk to S3, and every request leaves an auditable trace.
When it breaks, look at trust policies or token expiry first. Keep scope narrow: grant only bucket-level access, rotate permissions often, and validate the OIDC issuer’s thumbprint. These details prevent midnight debugging sessions because someone forgot a trailing slash in a federated ARN.