Why teams running multi-cloud and hybrid estates look for an AWS Secrets Manager alternative
Teams whose workloads span AWS, another cloud and their own datacenters usually end up with secrets in several places: AWS Secrets Manager for AWS workloads, a different store for the other cloud, and configuration files or a vault on premises. Each store has its own access model, its own rotation logic and its own audit trail. A self-hosted OpenBao or Infisical instance with cloud auth methods can serve all of these environments from one place. Workloads authenticate with the identity they already have, such as an AWS IAM role, a Kubernetes service account or an OIDC token, and the secrets live in a store the organization operates itself.
AWS Secrets Manager is reached through AWS Region endpoints, and it works best for workloads that run inside AWS and call it through the AWS SDK or native integrations. Teams outside AWS can call the same endpoints, but they then depend on AWS connectivity and IAM for every read, and they inherit per-Region and per-account operating boundaries. Before deciding, list the workloads by location and identity model, then confirm the current service quotas for secrets, API request rates and Regions in your accounts through the AWS Service Quotas console, since limits change and should be checked against your own setup rather than assumed.
The decision usually turns on three questions: how far the secrets need to reach, whether the quotas and cross-account patterns in your AWS estate will hold as secret counts grow, and which AWS-native integrations you cannot give up, such as Lambda rotation, ECS or EKS secret injection and CloudFormation references. Answer these first. Keeping AWS-native integrations working is often the hardest part of a move, so plan it as a separate workstream rather than an afterthought. The sibling pages on comparing the two products and on exporting secrets cover the detailed trade-offs and steps.
What a multi-cloud secrets manager has to do
A secrets manager that spans AWS, other clouds and your own datacenters has to act as one control point, authenticate workloads without static keys, separate access by environment and record every read. The cards below cover those requirements and the AWS-native integrations that must keep working during the move. Each one is a decision you can check against your current estate before choosing OpenBao or Infisical.
One control point across clouds
Today each cloud usually has its own secret store, its own console and its own audit trail, so a rotation or revocation has to be repeated in every place a value lives. A single self-hosted instance gives one policy model and one inventory for AWS, other clouds and on-premises systems. Before you consolidate, list every workload that reads secrets, the cloud or datacenter it runs in, and the network path it uses to reach the secrets service. Those paths decide where the instance must be reachable and how many replicas you need.
Workload identity without static keys
OpenBao documents auth methods including Kubernetes, JWT/OIDC, TLS certificates and AppRole, and Infisical lists Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth for machine identities. Use the method that matches the platform a workload already proves its identity to, so an EC2 instance, a pod or a CI job receives a short-lived token instead of a long-lived access key. OpenBao recommends AppRole for servers, so confirm the secret ID delivery path before you rely on it. Ask each team which identity they hold today and where that identity is issued.
Per-environment access control
Production, staging and development usually need different people and different workloads, and a shared store makes it easy for one team to read another team's values. Role-based policies scoped to a path or project keep those boundaries explicit and reviewable. Infisical also supports temporary access and approval workflows, which matter for break-glass reads. Check how your identity provider groups map to these roles, and who approves a change to a policy.
Audit every read
Compliance reviewers and incident responders need to answer who read which secret, from where and when, across every cloud. AWS logs each GetSecretValue call in CloudTrail, so a self-hosted replacement needs its own audit device forwarding to your SIEM. Decide where those logs are stored, how long they are kept and who can alter them. Test the pipeline by reading a secret and confirming the event appears in the central store.
Keep AWS-native reads working
Lambda, ECS and EKS workloads often read secrets through AWS SDK calls or through secret ARNs embedded in task definitions, so a cutover that ignores them breaks at deployment time. An AWS machine identity method or a sync that keeps values in AWS during transition lets those services keep running while you move them one at a time. Infisical's secret syncs can push values to AWS, which can serve as an interim step. Inventory every AWS principal that calls GetSecretValue or BatchGetSecretValue before scheduling any cutover.
Where AWS Secrets Manager reaches its limits outside AWS
Every read from AWS Secrets Manager is an AWS API call, which is the core limit for workloads that do not live inside AWS. The BatchGetSecretValue API returns the SecretString or SecretBinary of up to 20 secrets per call, selected by name, ARN or filter, and CloudTrail records a GetSecretValue entry for each secret returned. Inside AWS that is an advantage, since the audit trail is native and IAM controls the reads. For a workload in another cloud or a datacenter, every startup, refresh or rotation check becomes a network call to a regional AWS endpoint, with credentials that must be issued and scoped in AWS terms. Inventory which non-AWS systems read secrets, how often they read them, and whether they can tolerate an outage of the AWS endpoint or the network path to it.
The cost model also scales with use across environments. AWS Secrets Manager is priced per secret per month plus per 10,000 API calls, as stated on the AWS Secrets Manager pricing page. Each additional cloud, cluster or on-premises fleet adds secrets and calls, so the bill grows with the number of consumers rather than with the number of applications. Check the figures against your own usage reports and your current prices in the AWS billing console, since those numbers change and are not reproduced here.
Quotas are the third constraint to verify before designing a multi-cloud layout. Request rates, secret counts and cross-account access limits are set per account and per Region, and they appear on the Service Quotas page for your account. Pull those values for each account and Region that your non-AWS workloads would call, and compare them with your peak read volume during deployments and restarts. If your design depends on reading one secret from many accounts or Regions, treat the quota check as a gating item, and do not assume a default value applies to your account.
Which open-source option fits which multi-cloud pattern
This table compares OpenBao and Infisical on the features that matter when one secrets platform serves AWS, other clouds and on-premises systems. Read each row against your own workload pattern, and confirm per-cloud auth and plugin coverage with the vendor or in a proof of concept before you commit.
| Capability | OpenBao | Infisical |
|---|---|---|
| Cloud and workload auth methods | AppRole, JWT/OIDC, Kubernetes and TLS certificate auth are documented; confirm which AWS, GCP and Azure identity paths your teams need | Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth are documented for machine identities |
| Storage and high availability | Integrated storage (Raft) or PostgreSQL; PostgreSQL is described as easier to operate safely than Raft | Runs on Docker, Docker Compose or the official Helm chart with bundled PostgreSQL and Redis |
| Dynamic secrets | Documented for systems such as Kubernetes and SQL databases; check plugin support for each cloud service you need | Documented for databases such as PostgreSQL and MySQL; confirm coverage for other targets |
| Syncs to AWS and other platforms | No native sync feature described; AWS-native delivery would be built through your own pipelines or integrations | Secret syncs to platforms such as GitHub, Vercel and AWS are documented; confirm sync targets you need |
| Licensing | MPL-2.0 license, community-governed under the Linux Foundation's OpenSSF | MIT Expat for the repository, except content in ee directories, which uses the license in ee/LICENSE |
| Enterprise features | Core features are in the open-source project; confirm any add-on you plan to use | SSO and gateways require enterprise licensing according to the self-hosting documentation |
| Project maturity and stewardship | OpenBao is a Sandbox project of OpenSSF; review release cadence and support terms before adoption | Vendor-backed project with a hosted Infisical Cloud option; confirm support tiers for self-hosted installs |
| Fit for AWS-heavy hybrid estates | Suits teams that want one vault for cloud, Kubernetes and on-premises workloads and can run the operations themselves | Suits teams that want a dashboard, syncs and machine identities across clouds with less custom integration work |
Hub, spoke or per-region: choosing a deployment pattern
A single OpenBao or Infisical cluster serves every cloud and datacenter. Workloads in AWS, other clouds and on-premises systems all authenticate to the same endpoint, so policies, audit trails and secret paths live in one place. This is the simplest model to govern, but the hub becomes a critical dependency for every environment, so its network reachability and high availability design carry the most weight.
- Auth per platform: Use AWS IAM or EC2 auth for AWS workloads, Kubernetes auth for clusters, JWT/OIDC for other clouds that issue workload identity tokens, and AppRole for on-premises servers.
- Network path: Each cloud reaches the hub over private connectivity such as VPN or dedicated links, with firewall rules limited to the API port.
- High availability: Run an odd number of nodes on integrated storage (Raft) or PostgreSQL, which OpenBao lists as officially supported HA backends.
- Read scaling: Since v2.7.0 PostgreSQL standbys can serve read-only operations, which helps when many clusters read secrets at once.
- Failure domain: A hub outage affects all environments, so plan backups and a tested restore path.
Confirm with your network team which cloud regions can reach the hub, and what latency and failover behavior your links actually provide.
Each cloud region or environment runs its own cluster, and the clusters either replicate or stay independent. Regional placement keeps secret reads local and limits the blast radius of an outage. The cost is more instances to patch, back up and audit, and a need to decide which copy is authoritative.
- Auth per platform: Each region uses the auth method native to its platform, such as AWS IAM for regional AWS accounts and Kubernetes auth for local clusters, which keeps trust boundaries local.
- Network path: Clients talk only to their local cluster, so cross-region traffic is limited to any replication or sync you configure.
- Replication: Confirm with the vendor and your OpenBao version whether the replication features you need are available in your edition, and whether they are open source.
- High availability: Each cluster needs its own HA design and backup schedule, so staffing grows with the number of regions.
- Consistency: Define which cluster owns each secret path to avoid conflicting updates.
Ask for a written list of which secrets must be identical across regions and which can differ before choosing this pattern.
The instance runs in your own datacenter, and cloud workloads reach it over private links. This suits organizations whose system of record is on-premises or whose regulators expect key material to stay in controlled facilities. The datacenter becomes the trust anchor, so the cloud-to-datacenter path and its failure handling need the most design attention.
- Auth per platform: Cloud workloads use JWT/OIDC or cloud-native identity where their platform issues a verifiable token, and AppRole where it does not, with short token lifetimes.
- Network path: Use private connectivity from each cloud VPC or VNet to the datacenter, with no public exposure of the API.
- High availability: Spread nodes across racks or sites in the datacenter, and keep the PostgreSQL or Raft storage on hardware you control.
- Read scaling: Use standby read capacity from v2.7.0 for PostgreSQL to keep cloud read traffic from loading the active node.
- Dependency: Cloud workloads lose secret access if the private link fails, so cache policy and plan for graceful retries.
Check with your network and compliance teams how cloud-to-datacenter traffic is logged and whether your audit scope covers the links.
How to deploy one instance and keep AWS integrations working
This sequence moves secrets from several AWS Secrets Manager accounts and Regions into one self-hosted store that every cloud and datacenter workload can reach, while AWS consumers keep fetching their values without a code rewrite. Each step ends with a check you can confirm before moving on.
Inventory secrets and consumers per cloud
Start by listing every secret in each AWS account and Region, along with its owner, the workloads that read it and the cloud or datacenter where each workload runs. Include Lambda functions, ECS tasks, CodeBuild projects, EKS pods and any on-premises systems that call the AWS API today. Mark which secrets are rotated by Lambda functions, because those need a dynamic or static replacement rather than a straight copy. Done means you have one table that maps each secret to its consumers and its rotation method, reviewed by the application owners.
Choose storage and high availability design
Decide where OpenBao keeps its data. Integrated storage (Raft) and PostgreSQL are the officially supported high availability backends, and the OpenBao storage documentation describes PostgreSQL as easier to operate safely than Raft. Your platform team should decide how many nodes run in each location and where they sit relative to AWS, since a single cluster reached from several clouds depends on network paths that must stay up. Confirm the chosen design against the current OpenBao high availability and storage documentation, and record it in a design note that names the owner of backups and of the storage layer. Done means the design note is approved and the backend is chosen.
Install OpenBao or Infisical in your environment
For Kubernetes, install OpenBao with the OpenBao Helm chart, which requires Helm 3.6 or later. For Docker-based or non-Kubernetes hosts, Infisical offers a single container, Docker Compose, an official Helm chart with bundled PostgreSQL and Redis, and Linux packages. Install into a non-production environment first, check that the API answers from each network segment that needs access, and confirm that TLS certificates are issued by your internal certificate authority. Done means a test cluster or host responds to health checks from an AWS VPC, from another cloud and from one on-premises network.
Initialize and custody unseal keys
OpenBao starts sealed and needs its unseal material supplied before it serves requests. Decide how the unseal keys are split and who holds each share, and document the custody procedure in writing before any production secret is stored. Confirm with your security team whether auto-unseal through a cloud key service is acceptable for this environment, because a cloud dependency changes where the trust boundary sits. Store the recovery material separately from the cluster and test one restart before go-live. Done means the custody record lists each holder, the storage location and a successful restart test.
Configure cloud auth for each platform
Enable the auth methods that match each workload: the AWS auth method for EC2, ECS and Lambda identities, the Kubernetes auth method for clusters in each cloud, and JWT/OIDC for CI runners such as CodeBuild where the platform issues tokens. Use AppRole for servers and Userpass only for developer machines, as the OpenBao auth methods documentation recommends. Create one policy per application that grants read access to its own paths only. Done means a test workload in each cloud or datacenter authenticates, reads its own secret and is denied a neighbor's secret.
Migrate secret values and rebuild rotation
Read the values out of AWS Secrets Manager using BatchGetSecretValue, which returns up to 20 secrets per call, and write them into matching OpenBao paths. Replace each Lambda rotation with the OpenBao database secrets engine, using dynamic credentials where the application can renew them and static roles where a fixed username is required. Keep the source values in place until the cutover in the next step is complete. Done means every secret on the inventory has a destination path and a tested read, and each rotation has a documented replacement or an explicit exception.
Repoint AWS consumers and confirm CloudTrail and quota changes
Change Lambda functions, ECS task definitions and CodeBuild projects so they fetch from OpenBao using the auth method configured earlier, and remove direct calls to the AWS Secrets Manager API one workload at a time. Keep a rollback path for each workload. Before you close the cutover, confirm with your AWS team that the number of GetSecretValue and BatchGetSecretValue calls has dropped as intended, that CloudTrail still records the events you need for audit, and that any quota or throttling alarms tied to Secrets Manager are updated or retired. Done means each consumer reads from OpenBao in a test run, the audit trail is confirmed in the logging system you use, and the quota alarms reflect the new traffic.
Decommission AWS secrets after the recovery window
Once every consumer has run successfully against OpenBao for a period your change process sets, schedule deletion of the AWS secrets. AWS Secrets Manager uses a recovery window before permanent deletion, so confirm the window length in the current AWS documentation and keep the secrets recoverable until you are satisfied. Review IAM policies that granted access to the old secrets and remove them. Done means a change record shows the deletion date, the IAM cleanup is complete and no consumer logs show calls to the retired secrets.
Keeping AWS-native integrations working during the move
Keeping AWS-native integrations working comes down to one decision per consumer: whether it keeps reading from AWS Secrets Manager during a transition window, whether a sync keeps values flowing from OpenBao or Infisical into AWS, or whether the consumer itself is changed to authenticate to the new store. AWS services do not all behave the same way here. Amazon RDS can manage a database password in Secrets Manager, Lambda functions commonly receive secret values through environment configuration that points to a secret, and Amazon ECS can inject secrets into containers at task start. Each of these paths expects the secret to exist in Secrets Manager under a specific name or ARN, so removing the secret early breaks the service without a clear error in the application code.
Start by inventorying every reference to a secret ARN or name across your accounts, including IAM policies, CloudFormation or Terraform templates, ECS task definitions and Lambda configuration. For each one, confirm in your own environment whether the consumer resolves the secret at deploy time or at runtime, and whether the RDS managed-credential rotation is still active. A common pattern during a transition is to keep the AWS secret as a read path for a fixed window, with the value updated from OpenBao by a job you control, then retire the AWS copy once every consumer has moved. Another option is to use Infisical's AWS secret syncs to push values into Secrets Manager, but that keeps AWS as a copy of the source of truth and adds a sync to monitor. The third option, changing consumers to read from OpenBao through its AWS or Kubernetes auth methods, removes the dependency entirely but needs application or task changes and a test in each account.
Treat each integration as unverified until a test in a non-production account shows the workload starting, reading the value and rotating credentials cleanly. Confirm the behavior of your Lambda, ECS and RDS versions with AWS documentation or support, since managed behavior can change. Check that CloudTrail still records the reads you need for audit during the window, and that IAM roles still grant only the access each workload requires. The AWS Secrets Manager pricing page is useful when you estimate how long to run dual reads, because per-secret and per-call charges continue for as long as the AWS copy exists.
Evidence auditors and internal reviewers ask for
A self-hosted OpenBao or Infisical instance that serves AWS, other clouds and datacenters becomes one control point, so reviewers will ask for one consistent set of records rather than one per cloud. The four items below are the artifacts that tie access, logging, key custody and patching to that single instance. DeployOpen prepares these artifacts, but independent auditors and certification bodies issue any attestation.
Access policies per cloud identity
Reviewers want to see which workload identity from which cloud can read which secret path, and who can change those rules. In OpenBao, map each AWS, Kubernetes, OIDC or other cloud auth method to a named policy, and keep the mount-to-role mapping in version control. In Infisical, export the role assignments, temporary access grants and approval workflow settings for each project and environment. Check that no identity holds a broad read on every path, and that human operators use separate policies from workloads.
Audit logs across all clouds
Each cloud has its own logging, so the evidence for a secret read may be split across CloudTrail, cloud audit logs and datacenter systems. Decide where the OpenBao or Infisical audit device writes, who can read those logs and how long they are kept, and forward them to one log store that the security team controls. Confirm that the log records the requesting identity, the auth method and the secret path, and test that a sample read from each cloud appears in the central store. Confirm retention settings with your compliance lead, since the vendor defaults may not match your policy.
Unseal and key custody procedures
Auditors will ask who holds the unseal material or root key, where it is stored and how a recovery is authorized. Document the Shamir key split or auto-unseal design, the number of key holders, the custodian for each share and the steps for rotating the unseal key. Record each key ceremony with dates, witnesses and the location of sealed envelopes or hardware tokens. Where a cloud KMS performs auto-unseal, document the key policy and the account that owns it, because that account becomes part of the trust chain.
Upgrade and patch record
Keep a dated record of every OpenBao or Infisical version running in each environment, the release notes reviewed and the security fixes applied. Check the OpenBao releases page and the Infisical releases page on a set schedule, and note which minor line each environment follows. For OpenBao, record the migration path and any plugins that were skipped during an upgrade, because those mounts need a separate decision. Ask your team to confirm the patch cadence and approval steps in writing before an auditor asks for them.
Evidence ownership and review cadence
The four artifacts above go stale unless someone owns them and reviews them on a schedule. Assign an owner for access reviews, log review, key custody checks and patch records, and record who signed each review. Set the review cadence in your control documentation, and keep signed copies with the evidence. DeployOpen can help define the review checklists and the evidence folder structure, but the organization's own control owners must perform and sign the reviews.
Questions buyers ask before choosing a multi-cloud secrets manager
What drives the cost of replacing AWS Secrets Manager with a self-hosted secrets manager?
The largest cost is usually staff time, not servers. Self-hosting moves three recurring items onto your books: the servers or Kubernetes capacity that run OpenBao or Infisical, the storage and backups behind them, and the people who patch, monitor and unseal the cluster. AWS Secrets Manager is priced per secret per month plus per 10,000 API calls, with no upfront costs or long-term contracts, according to the AWS pricing page. So your comparison should multiply your real secret count and call volume against the fixed cost of running a highly available cluster. Ask any implementer for a written breakdown of one-time work (design, migration, hardening) and recurring work (upgrades, backups, on-call), and compare each line with your own usage data.
How long does a migration take, and what changes it?
Duration depends mainly on how many secrets exist, how many workloads read them, and how many secrets have rotation logic that must be rebuilt. A small estate with a few static secrets moves far faster than one with dozens of Lambda rotation functions and cross-account consumers. Consumers are the hidden variable: each service needs its auth method switched, tested and cut over, and each cutover needs a rollback path. Plan a parallel-run period where AWS and OpenBao or Infisical serve the same values. No duration should be committed until your inventory is complete, and a written scope from DeployOpen should state the secret count, consumer count and included environments that the timeline is based on.
What does our team need to provide before an engagement starts?
Expect to supply access and decisions more than code. You will need an inventory of secrets with owners, the workloads and platforms that read them (EKS, ECS, Lambda, EC2, on-premises VMs, CI runners), the IAM roles and policies currently granting access, and the database accounts behind any rotation. You also need to decide where the cluster runs, who holds unseal material or the root keys, which identity provider humans will use, and what your audit log retention must be. Confirm with your security team whether any secret must remain in AWS during transition, because some integrations may need a sync or a temporary bridge.
Can our own engineers deploy and run OpenBao or Infisical without a vendor?
Yes, both are open source and can be installed in your own accounts or datacenters. OpenBao is licensed under MPL 2.0 and documents a Helm chart for Kubernetes that requires Helm 3.6 or later. Infisical's repository is MIT licensed except for enterprise directories, and its self-hosting documentation lists Docker, Docker Compose, an official Helm chart and Linux packages. Self-deploying is realistic for a team with Kubernetes and PKI experience, but the hard parts are unseal key custody, backup and restore testing, upgrade planning and high availability. Some Infisical features such as SSO or gateways require enterprise licensing, so confirm which features your team needs before deciding.
How do AWS quotas and per-Region limits change after the move?
Moving off AWS Secrets Manager removes the per-Region and per-account constraints that shape its design, but it adds limits you now own. AWS documents BatchGetSecretValue as returning up to 20 secrets per call, and each secret read is logged in CloudTrail, which is useful for audit but also a source of throttling and log volume at scale. With a self-hosted cluster, the limits become your server capacity, database connections and network paths between regions and clouds. Check current AWS service quotas for your account and Regions, and load test the new cluster at your peak read rate before cutover. Keep AWS-native integrations such as ECS or Lambda working by confirming each auth path, including IAM-based login where Infisical or OpenBao supports it, against the current vendor documentation.
When should we choose OpenBao instead of Infisical for multi-cloud secrets?
Choose OpenBao when you need a Vault-style engine with dynamic database credentials, encryption as a service, a broad set of auth methods, and a governance model led by the Linux Foundation's OpenSSF. OpenBao is a fork of Vault, so teams already running Vault can migrate with a documented path from Vault Community 1.14.1 on Raft storage. Choose Infisical when developer experience matters most: project and environment dashboards, secret syncs to platforms such as GitHub, Vercel and AWS, a Kubernetes operator, and machine identities for AWS, GCP, Azure and Kubernetes. Infisical also bundles a private PKI, a key management service and privileged access management, which may reduce tool count if you need those features. Many organizations run one tool for platform secrets and reserve the other for application teams, and that choice should be tested in a pilot.
How DeployOpen deploys a multi-cloud secrets manager
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source secrets platforms inside your own cloud accounts, data centers or air-gapped networks. For multi-cloud and hybrid estates, we start from which workloads read which secrets from which clouds and datacenters, then design one OpenBao or Infisical instance around those paths.
How we scope
- We inventory which AWS accounts, other clouds and datacenters read secrets today, and how each one authenticates.
- The written scope names the chosen platform (OpenBao or Infisical), the auth methods per environment and the AWS integrations to keep.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the server, storage backend and high availability layout in the client's chosen accounts and regions.
- We configure cloud auth methods for AWS, Kubernetes and OIDC so workloads log in without long-lived static credentials.
- We test failover, unseal procedures, access policies and audit logging before any workload is moved over.
How we hand over
- We deliver runbooks covering unseal, backup, restore, upgrades and access requests, written for your operations team.
- We document the policies, auth roles and evidence your security and compliance teams need for review.
- Your team receives a walkthrough of the running system, and you confirm the handover criteria in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We track upstream security releases for the chosen platform and plan patch windows with your team.
- Ask us to confirm the scope of any retainer, response expectations and testing cadence in the written quote.
