AWS Secrets Manager vs Infisical: which to choose

Which secrets manager fits a team spanning AWS and other environments

AWS Secrets Manager fits when most of your workloads, identities and secrets already live in AWS, IAM is the access model your teams know, and per-secret and per-call charges are an acceptable line in the cloud budget. Self-hosted Infisical fits when the same secrets must reach AWS, other clouds and on-premises systems through one control point, when the data has to stay in infrastructure you control, and when you want machine identity authentication that works outside AWS as well as inside it. For a team spanning several environments, the second case is usually the one to test, but only after you have checked the AWS-side behavior you depend on.

Start with the AWS integrations you cannot give up. Infisical's AWS machine identity authentication and secret syncs can push values into AWS, but you should confirm in a proof of concept which AWS services, Regions and IAM patterns your pipelines, Lambda functions and ECS or EKS workloads need, and whether the sync direction and conflict handling match how your teams already change secrets. Where a service reads directly from AWS Secrets Manager through its native integration, that path keeps working regardless of what you run alongside it, so plan for both stores during any transition period.

The decision turns on four things: how many secrets and environments you run, how often applications and pipelines read them (call volume drives the AWS bill in a way that is hard to predict), where your workloads actually run, and who will operate the platform. Infisical's self-hosting documentation notes that enterprise features such as SSO or gateways need an enterprise license, so confirm which controls you require before costing the option. Ask your team who will patch, back up and upgrade the instance, and whether that effort is realistic for them or better contracted, since operating cost is the component most often underestimated.

Which option fits each scenario

This table compares AWS Secrets Manager and self-hosted Infisical across common team setups, naming the better fit and the condition that makes it so. Read each row against your own account layout, network boundaries and staffing, since the answer often changes when one of those conditions changes.

Scenario	Better fit	Condition that makes it hold
All workloads in one AWS account	AWS Secrets Manager	Services already use IAM roles, KMS and CloudTrail, and no system outside AWS needs to read the secrets.
Workloads across AWS, other clouds and datacenters	Self-hosted Infisical	One store must serve several clouds through machine identity methods such as AWS, GCP, Azure, Kubernetes or OIDC, rather than per-cloud stores.
On-premises or air-gapped systems	Self-hosted Infisical	Hosts cannot reach AWS Region endpoints, so the instance must run inside your own network with no dependency on a vendor cloud.
Teams pushing values to GitHub or Vercel	Self-hosted Infisical	Secret syncs to platforms such as GitHub, Vercel and AWS are part of the daily workflow. Confirm current sync targets in the Infisical documentation.
Teams needing PKI or privileged access alongside secrets	Self-hosted Infisical	You want X.509 certificates with ACME or EST enrollment, a key management service and session-recorded privileged access in one platform. Confirm which features need enterprise licensing.
Teams with no platform staff	AWS Secrets Manager	No one can own a self-hosted server, its upgrades, backups and database. Managed service fees may be simpler than operating effort, so compare with a quote.
Teams that must keep secrets in one license-clear codebase	Self-hosted Infisical	Your legal review accepts MIT Expat for the core, with separate terms for any enterprise directories. Check the ee license before deployment.

Where the data lives and who controls the platform

AWS Secrets Manager is a regional service. Secrets are stored in the AWS Region where you create them and are reached through that Region's API endpoints, and values are encrypted at rest with AWS Key Management Service. You choose between an AWS-managed key and a customer managed KMS key, which gives you key policies and the ability to disable or schedule deletion of the key. Your operators still depend on AWS for the service itself, its availability and the underlying infrastructure.

Regional scope: Each secret lives in one Region, so cross-Region copies and replicas are a deliberate design choice you must document.
Encryption at rest: Values are encrypted with KMS, and the key policy determines which principals can decrypt them.
Vendor operations: AWS runs the control plane, patching and infrastructure, which you do not operate but also cannot inspect.
Network path: Access normally crosses the public AWS API endpoints unless you configure VPC endpoints and private DNS.
Key ownership: A customer managed key keeps key administration in your account, but the service itself remains AWS-operated.

Confirm with AWS which Regions and replication options apply to your account, and check your KMS key policies against your separation of duties model.

The Infisical repository is licensed under the MIT Expat license, except for content in any ee directory, which falls under a separate license in ee/LICENSE. Your legal team should read both files, because the boundary determines which features you may run without a commercial agreement. The self-hosting documentation states that enterprise features such as SSO or gateways require enterprise licensing, so those capabilities should be costed as separate items.

Core code: MIT Expat covers the core platform outside the ee directory.
Enterprise directories: Code under ee is governed by its own license file.
SSO and gateways: The documentation says these require enterprise licensing.
Release tracking: Each release may change the license boundary or feature placement, so record the version you deploy.
Vendor relationship: Support, licensing and roadmap commitments come from the vendor, not from the open-source community.

Confirm the current license terms in the repository and in writing with the vendor before you build dependencies on any enterprise-only feature.

How secret syncs and machine identities reach AWS workloads

The core decision in this section is which direction secrets flow between Infisical and AWS. Infisical's secret syncs can push values from an Infisical project and environment out to destinations, and the documented targets include AWS. In that design, Infisical stays the system where engineers edit and approve values, while AWS services such as Lambda or ECS read copies in their native store. Before you commit to this, confirm in the current Infisical documentation which AWS destinations are supported, whether a sync is one-way, and how it handles deletions and failed pushes. Also confirm how a sync authenticates to AWS, since that identity needs write permissions on the target and should be scoped to the specific secrets it manages.

Machine identity auth is where the AWS integration removes stored credentials. Infisical's documented machine identity methods include AWS auth, which lets an EC2 instance, Lambda function or other IAM principal log in with its own AWS identity and receive a short-lived Infisical token, so no long-lived access key has to be placed in configuration or an environment variable. Check which IAM principal types and STS calls your Infisical version accepts, and restrict the identity to the projects and environments it needs through RBAC. Pair this with the access request and approval workflows described in the README so that a new workload cannot read production values without a recorded approval.

For Kubernetes, the Infisical operator delivers secrets into the cluster and can reload a deployment when those values change, which removes the manual rollout step after a rotation. Test this path in a non-production cluster: confirm which resource types trigger a reload, how long a rollout takes under your replica and disruption settings, and what happens when the operator cannot reach Infisical. If AWS Secrets Manager stays in your design as the destination for some workloads, for example services with native integrations that cannot read Infisical, document that split explicitly, because each copy of a value becomes another place that must be rotated and audited.

What each option costs to run and what drives the bill

AWS Secrets Manager bills by secret and by API call, so its cost moves with inventory and traffic. Self-hosted Infisical moves the bill to infrastructure, database operations and staff time, plus any enterprise licensing you need. The cards below separate one-time from recurring items so you can ask each vendor or partner for the same breakdown.

AWS per-secret and per-call fees

AWS Secrets Manager charges a monthly fee for each secret and a separate charge for every 10,000 API calls, with no upfront costs or long-term contracts, according to the AWS pricing page. Both lines recur every month. Secret count drives the first line and call volume drives the second, so a fleet that polls values on every deploy or every request can cost more in calls than in storage. Pull a month of billing data and split it into these two lines before comparing.

Batch reads and call reduction

The BatchGetSecretValue API returns up to 20 secrets per call, and it logs a CloudTrail GetSecretValue entry for each secret it returns. Batching can lower the per-call count, but it does not reduce audit volume, so CloudTrail storage and analysis costs remain. Check how your workloads cache values and how often they refresh them, because caching changes call volume more than any other setting.

Infisical licensing and enterprise features

The Infisical core is MIT Expat licensed, with content in any ee directory under a separate license. The self-hosting documentation states that enterprise features such as SSO or gateways need enterprise licensing. Ask the vendor which features your requirements depend on, whether that licensing is annual or per seat, and whether it covers self-hosted upgrades. This is the main recurring vendor cost in an otherwise open-source stack.

Servers, PostgreSQL and Redis

A self-hosted Infisical deployment runs on compute you pay for, whether that is a single Docker host, a Docker Compose stack or a Kubernetes cluster. The official Helm chart bundles PostgreSQL and Redis, but bundled databases still need storage, backups and capacity planning as secret counts grow. Ask for sizing based on your secret count, environments, replicas and regions, and confirm whether the chart's bundled databases are supported for production or only for evaluation.

Backups, upgrades and monitoring

Backups, upgrades and monitoring are recurring operating tasks that AWS performs for you in its managed service but that your team owns with Infisical. Plan for database backup and restore tests, a regular upgrade cadence against the latest Infisical releases, and alerting on availability. Confirm with the vendor how versioning and point-in-time recovery behave during database restores, because those tests should run before go-live.

Staff time and implementation

Staff time is the largest cost that is hard to see on an invoice. It covers initial setup, identity integration for AWS and other clouds, sync configuration, rotation design and on-call coverage. Implementation is usually a one-time cost and operating the platform is recurring. Request a written scope listing deliverables, responsibilities and handover terms from DeployOpen or another partner, and ask each one to state which tasks it would perform and which would stay with your team.

What moving from AWS Secrets Manager to Infisical involves

The sequence takes secrets and their consumers out of AWS Secrets Manager and into a self-hosted Infisical instance, with both systems running side by side until each workload has been verified and the AWS copies can be safely retired.

Inventory secrets, consumers and rotation logic
List every secret in AWS Secrets Manager, the Region and account it lives in, the workloads, Lambda functions, pipelines and AWS services that read it, and any rotation Lambda attached to it. Your platform or security team owns this list, and it is done when each secret has a named owner, a consumer list and a rotation status. Flag secrets that feed resource policies, KMS grants or CloudFormation stacks, because those dependencies break first when values move.
Read secret values with BatchGetSecretValue
Use the BatchGetSecretValue API to retrieve the SecretString or SecretBinary of up to 20 secrets per call, selected by name, ARN or filter. The reading principal needs IAM permission for the call and for the KMS keys that encrypt the secrets. Each secret read logs a CloudTrail GetSecretValue entry, so the export itself is auditable. It is complete when every value is held in a restricted staging location, with a count that matches your inventory.
Stand up Infisical in the chosen topology
Deploy Infisical in the topology your inventory supports, such as a single Docker container, Docker Compose, or the official Helm chart with bundled PostgreSQL and Redis on Kubernetes. Confirm which self-hosting features you need, since the self-hosting documentation says SSO and gateways require enterprise licensing. Put the instance behind TLS, restrict network access, and set up backups of its database. It is done when the instance answers health checks, admin accounts are created and backup restores have been tested.
Recreate projects, environments and access policies
Create Infisical projects and environments that mirror how your teams split their secrets, such as one project per application with separate development, staging and production environments. Assign roles through RBAC and decide where temporary access or approval workflows are required. Confirm the mapping with each owner from step one. It is done when every secret from the inventory has a destination path and an owner with the right role.
Load values and configure secret syncs where needed
Import the staged values into Infisical, then choose per secret whether the application reads from Infisical directly, through the Kubernetes operator or the injection agent, or whether Infisical should keep pushing the value to AWS through a secret sync. Sync to AWS only for consumers that cannot yet switch, and record that choice as temporary. It is done when a test read of each secret returns the expected value in every environment.
Move workloads to machine identity authentication
Replace long-lived AWS access keys and IAM-based secret reads with Infisical machine identities. Infisical supports AWS, Kubernetes, GCP, Azure, OIDC and Universal Auth, so choose the method that matches each workload's platform. Grant each identity the narrowest project and environment access it needs. It is done when each workload authenticates with its identity in a non-production environment and no application still depends on the old IAM read path.
Replace rotation Lambdas with Infisical rotation or dynamic secrets
For each secret that a rotation Lambda managed, decide whether Infisical's secret rotation or dynamic secrets for a supported database such as PostgreSQL or MySQL fit the workload. Where no supported integration exists, keep a documented manual rotation runbook and record the gap. Test the new rotation path against a non-production database before it touches production. It is done when every rotated secret has a tested replacement or a recorded exception with an owner.
Run both systems in parallel, then decommission AWS
Keep AWS Secrets Manager running alongside Infisical while production workloads are switched and watched, reviewing CloudTrail and application logs for failed reads. Once no consumer reads from AWS, remove the sync destinations and disable rotation. Delete AWS secrets only after the recovery window you configured has been considered, since deleted secrets can be restored only within that window. It is done when CloudTrail shows no GetSecretValue calls from workloads for an agreed observation period and the deletions are recorded in your change log.

Risks to plan for before cutover

Moving from AWS Secrets Manager to self-hosted Infisical changes more than the storage location. Rotation logic, licensing, database support, operations, AWS integrations and IAM-based access each need an owner and a check before any workload switches over. The cards below cover the points most likely to cause an outage or a compliance gap.

Rotation logic inside Lambda functions

Many AWS Secrets Manager rotations run as Lambda functions that change a password in the database and then update the secret. Those functions do not move with the secret values. Infisical offers rotation and dynamic secrets for databases such as PostgreSQL and MySQL, but each existing rotation must be mapped to an Infisical equivalent and tested against the real database account. Inventory every rotation function, its trigger and its failure handling before you export anything. Treat any rotation you cannot map as a blocker for that workload.

Enterprise features gated by licensing

Infisical's repository is MIT Expat licensed, except for code in ee directories, which fall under a separate license. The self-hosting documentation states that enterprise features such as SSO and gateways require enterprise licensing. If your access model depends on SSO for operators or gateways for private networks, confirm the license terms and cost with the vendor before you design around them. Ask for the written scope of what the community edition includes.

Unverified rotation support for specific databases

Infisical documents dynamic secrets and rotation for PostgreSQL and MySQL. If your estate runs other engines, such as SQL Server, Oracle or a managed database service with its own password policy, do not assume support. Test each engine in a non-production account, confirm how credentials are revoked, and check how applications reconnect when a credential changes. Services that rely on a fixed username may need a different pattern than dynamic credentials.

Operating a stateful platform

A self-hosted Infisical instance holds encrypted secret data, and its deployment depends on PostgreSQL and Redis. The official Helm chart bundles both, but bundled databases still need backups, restore tests, patch windows and monitoring that you own. Upgrades should follow the release notes, since the latest published release at the time of writing was v0.166.8. Define the recovery point and recovery time objectives for the secrets store before cutover, and rehearse a restore.

AWS integrations that reference secret ARNs

Lambda functions, ECS task definitions, CloudFormation stacks and EKS add-ons often reference secrets by ARN or by name. Those references break when the secret moves, and an empty value can fail a service without a clear error. Find every reference with resource searches or AWS Config queries, then decide whether each consumer reads from Infisical through the agent, the Kubernetes operator or an API call. Keep the AWS secret in place until every consumer is confirmed.

IAM-based access model changes

Today, many workloads receive secrets because an IAM role allows secretsmanager:GetSecretValue. Infisical machine identities authenticate through AWS, Kubernetes, GCP, Azure, OIDC or Universal Auth, and access is governed by its own RBAC and approval workflows. Map each IAM role to an Infisical identity and project role, and confirm that the AWS authentication method accepts the same roles. Review who can read which secret in both systems during the parallel run, because permissions can drift.

Questions buyers ask before choosing or hiring help

How does AWS Secrets Manager cost compare with running Infisical yourself?

AWS Secrets Manager bills per secret per month plus per 10,000 API calls, with no upfront costs or long-term contracts, according to the AWS pricing page. Self-hosted Infisical has no per-secret or per-call license fee in its open-source edition, so your cost is the infrastructure it runs on, the database and cache, backups, and the staff time to operate it. The comparison turns on three things: how many secrets and how many calls your workloads make, how many environments you run, and how much platform time your team can spare. Enterprise features such as SSO or gateways need enterprise licensing, so price those separately. Ask any implementation partner for a quote that lists infrastructure, one-time setup, recurring support and licensing as separate lines.

How long does a migration from AWS Secrets Manager to Infisical take?

The timeline depends on how many secrets you hold, how many applications read them, and how many of those reads are wired to AWS-native integrations such as Lambda rotation, ECS or EKS injection, and CloudFormation references. Teams usually move in stages: stand up Infisical, bring one non-production project across, switch its workloads to machine identity auth, then repeat for each project and environment. Secret syncs can keep values flowing back to AWS during the transition, so you do not need a single cutover date. No duration is fixed in our researched facts, so ask for a written timeline tied to a defined scope before work starts.

What does our team need to provide for a migration?

A migration needs named owners on both sides and access to the systems that depend on secrets. In practice that means:

An inventory of secrets, the projects and environments that use them, and the AWS accounts and Regions involved.
IAM permissions to read secret values and CloudTrail records, plus the KMS permissions your secrets use.
A list of rotation functions, consuming services and deployment pipelines, so each can be switched over.
A decision on who approves access, which sets how RBAC and approval workflows are configured.
Time from application owners to test each switch in a non-production environment.

These items drive most of the effort, so confirm them in the scoping stage.

Can our own engineers run this migration without a partner?

Yes, if your team has Kubernetes or Docker operations experience, can manage a PostgreSQL database and cache, and has someone who owns secrets policy. Infisical publishes a Docker container, Docker Compose setup, an official Helm chart with bundled PostgreSQL and Redis, and Linux packages, so a capable in-house team can deploy it without outside help. The harder parts are usually rotation rewrites, auth changes in each application, and running backups and upgrades on a schedule. A partner is most useful for that work or for a fixed-scope handover. Either way, decide before you start who will own the system after go-live.

Does Infisical work in an air-gapped network?

Infisical can be self-hosted, which is the prerequisite for running it on a network without internet access. Our researched facts do not confirm the full set of steps for an isolated environment, including how container images, Helm charts and dependencies are mirrored in, or how updates are delivered. Check the self-hosting overview and confirm with Infisical how each deployment option behaves offline before you commit to a design. Your air-gap plan should also cover how the system is patched and how its audit logs leave the network.

What does enterprise licensing cover in Infisical?

Infisical's repository is MIT licensed, except content in ee directories, which fall under a separate license. The self-hosting documentation says enterprise features such as SSO and gateways require enterprise licensing. Confirm the exact feature list and terms against the Infisical license file and with Infisical directly, because feature availability can change between releases. Ask whether the features you need for identity, access approval and audit are in the open-source edition or require a paid license.

Does DeployOpen provide audit reports for our secrets platform?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. What we can help with is configuring access controls, logging, rotation and backup so your auditor has consistent evidence to review, and documenting how those controls operate. Ask your auditor which evidence they need before scoping the work.

When a hybrid setup makes sense

A hybrid setup keeps AWS Secrets Manager for workloads that run only inside AWS and uses self-hosted Infisical for secrets that several environments need. The bridge is Infisical's secret syncs, which can push values into AWS so that Lambda functions, ECS tasks or other AWS-native consumers keep reading from the store they already use. The split is worth considering only when the AWS-only estate is large, well integrated and already governed by IAM and KMS policies that would be costly to rebuild, while on-premises systems, other clouds or CI runners also need the same credentials. For a small estate, one store is almost always easier to audit.

The cost of two stores is operational, not just financial. Each store needs its own access model, audit trail, rotation approach and backup plan, and engineers must know which store holds which secret. Syncs create a second copy of each value, so the sync direction, the target path in AWS and the owner of the source must be written down before go-live. Confirm whether the sync can be restricted to specific folders, environments and secret names, and whether a failed push is visible and alerted. Also check the IAM permissions the sync role needs, since an over-broad role in AWS becomes a path to every synced value. Before choosing this split, run an inventory: count the secrets read only by AWS-native services, list those shared with non-AWS systems, and note which ones rotate. Confirm with the Infisical self-hosting documentation which features your edition needs, because the vendor states that some enterprise features require enterprise licensing. Then decide who operates both systems, how a sync outage is handled, and when a secret moves fully into one store. A hybrid design should have a stated end state, not become permanent by default.

How DeployOpen helps you evaluate and move

DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For AWS Secrets Manager vs Infisical, we start with a written scope that shows which AWS workloads, other clouds and on-premises systems would depend on a self-hosted Infisical instance.

How we scope

We inventory secrets, AWS accounts, Regions and the workloads that read them through IAM today.
We define which Infisical deployment target fits your environment, such as Docker Compose, Kubernetes with Helm or Linux packages.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work starts.

How we build

We install and configure Infisical, then set up projects, environments and RBAC to match your team structure.
We test AWS IAM machine identity authentication, secret syncs and rotation or dynamic secrets against your own staging systems.
We document the configuration, backups and PostgreSQL and Redis dependencies so your operators can run the platform afterward.

How we hand over

We deliver runbooks for secret versioning, point-in-time recovery testing and restoring the database and key material.
We provide a cutover plan covering which secrets move, which AWS integrations keep working and which stay in Secrets Manager.
We prepare the access, audit and change evidence your compliance team or external auditor will request, without issuing any certification.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover tracking new Infisical releases, testing upgrades in staging and reviewing enterprise licensing needs.
Quotes follow from the written scope, so ask for each component (install, integration, testing, documentation and support) to be priced separately.

AWS Secrets Manager vs Infisical