The Simplest Way to Make Bitbucket EC2 Systems Manager Work Like It Should

Most teams hit the same wall. You need to run deployments from Bitbucket to your EC2 fleet, but the credentials never age well. Static keys leak, roles get tangled, and half the time someone from ops is still clicking around in the AWS console. Bitbucket EC2 Systems Manager can fix that, if you wire it correctly.

Bitbucket is great at orchestrating pipelines. AWS Systems Manager (SSM) is great at controlled access into EC2 without SSH keys. Together, they let you run build artifacts and commands across instances with almost no human access paths. Security teams sleep better, and developers stop asking for temporary IAM tokens every other day.

At its core, this integration uses SSM to assume roles for EC2 instances, then extends those permissions to Bitbucket via federated identity. Instead of storing AWS keys in repository variables, Bitbucket pipelines request short-lived credentials from SSM through AWS Identity and Access Management (IAM). Each job runs in a least-privileged context and leaves behind complete audit trails. The whole thing hinges on identity-derived access, not secret sprawl.

Here’s the gist: map Bitbucket’s OIDC provider to your AWS account. In IAM, define a trust policy allowing Bitbucket to assume an SSM role scoped to the actions your deployments need—probably RunCommand, StartSession, or ParameterStore reads. From there, your pipeline just triggers an AWS CLI call using the signed OIDC token. AWS verifies, issues temporary creds, and executes your commands directly through Systems Manager. No SSH. No long-term keys. No cleanup chores.

A few best practices smooth out the edges. Keep the IAM policy narrow; one command too many can open data movement paths you did not intend. Rotate instance profiles often, even though SSM automates key management behind the scenes. And log every session to CloudTrail, which pairs neatly with Bitbucket’s pipeline logs for full traceability.

Benefits worth noting:

• Stronger access boundaries without overlapping credentials
• Reduced manual approvals and context-switching
• Instant audit visibility for compliance frameworks like SOC 2 and ISO 27001
• Faster deploy times because pipelines connect securely by default
• Happier developers who no longer babysit AWS tokens

Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Instead of hand-coding IAM constraints for each project, you define once and let identity-aware proxies apply them across environments. It’s like self-service infrastructure with brakes installed.

How do I connect Bitbucket and EC2 Systems Manager in practice? You configure Bitbucket’s OIDC identity as a trusted provider in AWS IAM, link a role with SSM permissions, and let pipelines exchange the signed ID token for temporary credentials. That’s the entire security handshake. No shared secrets, no manual provisioning.

The developer experience improves right away. Onboarding new projects means fewer environment variables, fewer API keys, and no approval waiting. Even AI copilots that automate build or test steps benefit, since they operate inside a verified identity chain instead of plain text credentials.

Bitbucket EC2 Systems Manager is not a new concept, but when done right it turns infrastructure from a security liability into an observable service network. Replace keys with identity. Replace guesswork with logs. The pipeline gets faster, and your cloud gets quieter.

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.