How to export your data from AWS Secrets Manager without a bulk export
AWS Secrets Manager has no bulk export, so a team leaving for a renewal, a residency requirement or a move off AWS has to read each secret value out through the API. Secret values come back only from GetSecretValue or from BatchGetSecretValue, which returns the SecretString or SecretBinary of up to 20 secrets per call, selected by a list of names or ARNs or by up to 10 filters. Filter-based selection adds ListSecrets to the permissions list and uses NextToken pagination, so an inventory run should start by listing every secret in each Region and account in scope. The caller needs secretsmanager:BatchGetSecretValue plus secretsmanager:GetSecretValue on each secret, and kms:Decrypt for any secret encrypted with a customer-managed key. Confirm those grants in a dedicated export role before the run, because a missing key permission fails only for the secrets that use that key.
Three things do not come out through this path: the rotation Lambda functions that update values, the resource policies attached to secrets, and the configuration around each secret, such as tags, descriptions, version stages and replica settings. Those must be recorded separately from the API or from your infrastructure-as-code source, and the export is complete only for the values. Every retrieved secret also writes a CloudTrail GetSecretValue entry, so the export produces an audit trail that security and compliance teams will want to keep with the migration records. This page covers documented paths only: the AWS API reference, IAM and KMS controls, and CloudTrail. Confirm with AWS, through the BatchGetSecretValue reference, any limits that apply to your account before you plan the run.
Which secret data AWS Secrets Manager lets you read out
This table lists each kind of secret data you may need to move, the documented API call that returns it, the format it comes back in, and the request limits that shape your export. Read it as a checklist: anything not returned by these calls must be recorded from your own inventory or confirmed against the API reference before you decommission.
| Data type | Documented method | Format returned | Limits and notes |
|---|---|---|---|
| Secret values | GetSecretValue or BatchGetSecretValue | SecretString or SecretBinary, one value per staged version | BatchGetSecretValue returns up to 20 secrets per call, selected by names or ARNs or by up to 10 filters |
| Secret names and ARNs | ListSecrets or BatchGetSecretValue by name or ARN | Name and ARN strings | ListSecrets is needed when filters select secrets, and filtered results paginate with NextToken |
| Version identifiers and staging labels | GetSecretValue with a version ID or staging label | Version ID and labels such as AWSCURRENT and AWSPREVIOUS | Confirm in the API reference which version and label values each call returns for your secrets |
| Secret metadata | DescribeSecret | Description, KMS key reference, rotation settings, tags and timestamps | Metadata is not included in secret values, so export it separately and record it in your migration inventory |
| Access activity | CloudTrail GetSecretValue entries | One log entry per secret retrieved through BatchGetSecretValue | Retain these logs for your audit period, since they are the evidence of what was read during the export |
What does not leave AWS Secrets Manager and how to rebuild it
Secret values can be read out of AWS Secrets Manager, but the surrounding control plane cannot. Rotation functions, access policies, encryption keys, replication settings and audit history each need a deliberate decision before you decommission anything. The cards below set out what stays behind and what to build in its place in OpenBao.
Rotation Lambda functions and schedules
Rotation in Secrets Manager runs as Lambda functions on schedules you configured, and those functions and their triggers do not move with the secret values. Read each rotation schedule and the function it calls before you export, so you know which services depend on a password changing on a timer. In OpenBao, rewrite that logic in the database secrets engine, which issues short-lived credentials instead of rotating a shared password. Check which of your databases have a supported plugin, and plan static roles for any account that must keep a fixed username.
Resource policies and IAM permissions
Resource-based policies on each secret and the IAM policies attached to roles and users decide who can read a value. None of these carry over to OpenBao. Inventory every principal that calls GetSecretValue or BatchGetSecretValue, then recreate those grants as OpenBao policies bound to auth roles such as AppRole for servers or Kubernetes auth for pods. Test each binding with the workload's real identity before you remove the AWS permission, because a missed principal fails at runtime rather than at deploy time.
KMS key material and decryption
The KMS keys that protect your secrets cannot be exported, and their key material never leaves AWS. You can only read a value while the caller holds kms:Decrypt on a customer-managed key, so the export window closes when that access is revoked. Plan the read job to run while that permission still exists, and store the decrypted values only in OpenBao, where its own storage encryption and unseal process take over. Do not expect to carry a KMS key into OpenBao.
Replication and multi-Region copies
Secrets Manager can replicate a secret to other Regions, and that replica configuration is an AWS setting rather than part of the secret value. Record which secrets have replicas and which Regions hold them, because each replica is a separate copy that must be removed during decommissioning. Your OpenBao deployment replaces this with a single cluster design, so decide where OpenBao nodes run and how they reach each Region before cutting over. Confirm the replication behavior in the current AWS documentation for your account.
Tags and naming conventions
Tags on secrets drive cost allocation, ownership lookups and some IAM conditions, and they are not carried into OpenBao. Export your tag inventory to a file before deletion, then map each tag to an OpenBao path, a policy name or a metadata field. Path design matters more than the tag itself, because OpenBao policies match on paths. Use this step to retire names that no longer describe an owner or a system.
CloudTrail history as the audit record
CloudTrail logs a GetSecretValue entry for each secret read, including reads made through BatchGetSecretValue, and those entries stay in AWS after you leave. Keep the trail for as long as your retention policy requires, and treat it as the historical record of who read what before the migration. OpenBao keeps its own audit devices from the cutover onward, so keep CloudTrail as the record for the period before cutover and confirm with your auditors how both logs will be presented together.
Which IAM and KMS permissions the export job needs
The export job needs `secretsmanager:BatchGetSecretValue` to call the API at all, plus `secretsmanager:GetSecretValue` on each secret it reads, since BatchGetSecretValue still checks access per secret. If you select secrets by filter instead of by name or ARN, add `secretsmanager:ListSecrets`, because the filter lookup runs before any values are returned. Secrets encrypted with a customer-managed KMS key also need `kms:Decrypt` on that key, and the key policy must allow the role as well as the IAM policy. Secrets that use the default AWS managed key are decrypted without a separate grant, so check each secret's KMS key before you write the policy. Confirm the exact permission set against the BatchGetSecretValue API reference for your SDK or CLI version, because a missing grant often surfaces as a partial failure rather than a clear error.
Scope the role tightly. Create a dedicated, read-only export role in each account that holds secrets, and write its policy against explicit resource ARNs or, where your naming and tagging are consistent, a tag condition that matches only the secrets in the migration batch. Avoid wildcards on Resource and avoid attaching any write, rotation or delete actions to the role. Require that the role be assumed through a short session duration and that only the migration operator or pipeline can assume it. Review which principals already have broad secretsmanager:* access in the same account, because a tightly scoped export role does not stop a wider existing grant from reading the same values.
Treat the role as temporary. Delete the role and its inline or attached policies once the export is verified, and remove the KMS grants you added to customer-managed keys. Keep the CloudTrail records of each GetSecretValue call made during the export, since one entry is written per secret, and retain them according to your audit requirements. Before deletion, export a copy of the role's policy and the list of secrets it read so an auditor can match access to the migration plan. Ask your security team to confirm where those records are stored and who can read them, because the export log will list every secret name the job touched.
The sequence for a complete, verified export from AWS Secrets Manager
The sequence turns an unstructured set of AWS secrets into an encrypted, inventoried export where every value is accounted for, traceable in CloudTrail and proven to work in the target before the source is retired. It is designed so that a missing secret, a failed batch or an unexpected version is caught before any cutover.
Inventory every secret with ListSecrets
Run ListSecrets in each account and Region in scope, following NextToken until the list is complete, and record name, ARN, description, KMS key, tags, rotation settings and last changed date in a master inventory. The platform or security engineer who owns the migration does this work, and the step is done when the inventory count matches what the account owner expects and every page has been read. Confirm the request parameters and pagination behavior against the current API reference before you run it, since the reference is the authority for how the call is paged.
Classify secrets by owner and consumer
For each inventory row, assign a named owner, the workloads or pipelines that read it and whether it is static, rotated by a Lambda function or used by an application that expects a fixed name. Mark secrets with no identifiable consumer or owner for review rather than exporting them by default. The output is a classified inventory that tells the team which secrets move, which are retired and which need a rotation redesign before cutover.
Export values in batches of up to 20
Call BatchGetSecretValue with lists of up to 20 secret ARNs at a time, using the same identity that holds the required Secrets Manager and KMS permissions. Batch by inventory rows rather than by filter so the set read is exactly the set you classified. Log every batch response, including any entries returned in an error list, so that a partial failure is retried with a known set. The step is complete when every classified secret has either a returned value or a documented error.
Write output to an encrypted, restricted location
Write the returned SecretString or SecretBinary values directly to an encrypted store that only the migration role and a named reviewer can read, such as a customer-managed KMS key on a locked-down bucket or an encrypted volume on an isolated host. Do not write plaintext to laptops, tickets or chat channels, and delete any temporary copies once the import is verified. The check is that access logs show only the named identities touching the output.
Reconcile counts and checksums against the inventory
Compare the number of exported records with the inventory count from the first step, then compute a checksum for each value and store it alongside the secret name and ARN. Any mismatch, missing name or unexpected empty value stops the sequence and goes back to the owner. The output is a reconciliation report signed off by the migration lead, with every inventory row matched to exactly one exported record.
Record the version read for each secret
Capture the version ID and version stage (such as AWSCURRENT or AWSPREVIOUS) that each batch returned, and store them in the reconciliation record. This shows which version the target was seeded from and lets the team decide whether any value changed between the inventory and the export. The check is that every row has a version identifier and that any secret rotated during the window is re-read and re-reconciled.
Verify CloudTrail GetSecretValue entries
Query CloudTrail for GetSecretValue events tied to the migration role during the export window and match one event per secret to the reconciliation record. Each secret retrieved through BatchGetSecretValue produces its own entry, so the count and secret identifiers in the trail should agree with the export log. Keep these entries with the reconciliation report as the audit record of who read what and when, and confirm the trail's retention and delivery settings with your own logging team.
Confirm each value works in the target
Load the values into OpenBao, then have each consumer team read its secrets from the target in a non-production environment and run its own health check. Record a pass or fail per secret against the reconciliation record, and do not decommission the AWS source until every consumer has signed off. Illustrative example: a database password that authenticates against the target but fails on a service still pointing at a stale version should be traced back to the version record before the cutover is approved.
How to verify that every secret arrived intact
Reading secrets out of AWS Secrets Manager is only half the job. Each check below answers a different question: did every secret arrive, did its value arrive intact, did the right version arrive, and can you prove each read happened. Together they give you evidence to sign off before anything is deleted.
Count reconciliation against ListSecrets
Run ListSecrets across every Region and account in scope and compare the list with the names you exported. Include secrets that are scheduled for deletion, since they still appear with a deletion date and may need a decision rather than an export. Record each mismatch with its ARN. Because BatchGetSecretValue takes up to 20 names or ARNs per call, batches that silently drop an entry are easy to miss unless you count the output against the input. Ask whether anything was skipped on purpose and document the reason.
Per-secret checksum comparison
Hash each exported value at the source and again after it lands in the target, then compare the hashes one secret at a time. Treat SecretString and SecretBinary separately, because a binary value re-encoded as text will fail a comparison even when the content is correct. Store the hashes outside the export so a later reader can check them. Hashes prove the bytes match, so keep the values themselves encrypted in transit and at rest during the comparison.
Version and staging label matching
Secrets Manager keeps versions and staging labels such as AWSCURRENT and AWSPREVIOUS. An export that reads only the current value can leave out the previous value that a rollback or a still-running service depends on. For each secret, record which version each label points to and confirm the target holds the same mapping. Ask your application owners which labels their code reads, because a missing label often surfaces only during a failed deploy.
CloudTrail reconciliation per read
BatchGetSecretValue writes a GetSecretValue entry to CloudTrail for each secret it retrieves, so the log should contain one entry per exported secret. Match the trail entries against your export manifest by secret ARN and time window. A secret with an export record and no log entry is a red flag. A log entry with no export record points to a process you did not account for. Keep the trail for the whole migration window so this check can be run after the fact.
Questions teams ask before they export from AWS Secrets Manager
How long does an export from AWS Secrets Manager take?
The read itself is fast, so the duration is driven by preparation and coordination rather than by API throughput. BatchGetSecretValue returns up to 20 secrets per call, so the number of secrets sets how many calls a script makes. The larger effort comes from mapping which workloads read each secret, deciding which secrets become dynamic credentials instead of copied values, and scheduling cutovers. Teams with many secrets, filter-based selection, rotation Lambdas or tightly coupled applications should expect the planning phase to dominate. Ask any partner to show the inventory and cutover plan in the written scope before agreeing to a timeline.
What access and approvals does an AWS Secrets Manager export require?
The exporting identity needs secretsmanager:BatchGetSecretValue and secretsmanager:GetSecretValue on each secret, secretsmanager:ListSecrets if filters are used, and kms:Decrypt for secrets encrypted with customer-managed keys. Someone with IAM administration rights must create and scope that role, and the change should be recorded. Application owners must confirm which services read each secret, since their deployments will change at cutover. Plan change windows with those owners, and agree on a rollback path in case a workload fails after its credentials move to OpenBao.
Can our internal team export and migrate the secrets alone?
A capable platform team can read secrets with a scoped role and load them into OpenBao, and the reads themselves are not complex. The harder parts are rebuilding rotation logic, updating every consumer to use OpenBao authentication, and running OpenBao itself, including unseal key handling, high availability and backups. Teams without recent experience in those areas often use a partner for one part of the work. Whether to go alone depends on your secret count, your rotation dependencies and the staff time you can free up. Confirm your own environment before committing.
What does leaving AWS Secrets Manager cost, and what recurs?
Costs fall into three groups. AWS charges per secret per month and per 10,000 API calls, with no upfront costs or long-term contracts, so the export itself adds API calls while the secrets remain billable until you delete them. KMS requests for customer-managed keys also count during reads. On the OpenBao side, you pay for servers, storage, backups, monitoring and the staff who run the platform, and most of those recur. Staff time for migration is largely one-time, while operations are ongoing. Ask for a quote that separates one-time migration effort from recurring hosting and support, and states the assumptions behind the secret count and call volume.
Does CloudTrail record each secret we export?
Yes. According to AWS, BatchGetSecretValue writes a CloudTrail GetSecretValue entry for each secret it retrieves, so the export appears as one event per secret rather than one event per call. Keep these entries, since they show who read each value and when, and they are useful evidence for an internal review. Confirm that your trail covers the Region and account where the secrets live, and that retention meets your own policy. Export activity can also trigger alerts in your monitoring, so tell your security operations team before the run.
What should we ask a partner for in a written quote?
Ask for a scope that lists the secrets, workloads and rotation jobs in or out of the engagement, along with the deliverables for each. DeployOpen works from a written scope, and most engagements are fixed-scope, so the quote should follow from that document. Request the assumptions on secret count, filter use, KMS key types and workload coupling, plus the cutover plan, rollback steps and handover material. Ask whether post-migration support, upgrades and testing are included or offered as a separate retainer. Also ask who holds the unseal keys and how backups are verified.
Which secrets should we export as values, and which should we replace?
Export as values only the secrets that must keep a fixed value for a consumer you cannot change quickly, and move the rest to dynamic or short-lived credentials. Database passwords tied to a rotation Lambda are usually the best candidates for OpenBao's database secrets engine, while third-party API keys often have to be copied and updated. Review each secret with its owner and record the decision. Secrets read through BatchGetSecretValue by filter need the same review, because a filter can select secrets nobody has listed. Confirm the approach for each category in your own environment.
Where exported secrets land in OpenBao
Each value you read out of AWS Secrets Manager lands in an OpenBao key/value secret, which is encrypted before it is written to storage. Plan the mount layout before the first import: decide which paths hold application secrets, which hold platform credentials, and how each path maps to the AWS secret name you are retiring. Keep the original secret name in the path or in custom metadata so that a later audit can trace each OpenBao entry back to the AWS secret and its CloudTrail history. Note that secrets exported through BatchGetSecretValue arrive as plain values, so the import pipeline itself becomes a sensitive system that needs the same access controls as the vault.
Access to the imported paths should be granted through auth methods, not by sharing a root or admin token. The OpenBao auth methods documentation recommends Userpass for developer machines and AppRole for servers, and supports Kubernetes, JWT/OIDC and TLS certificates for workloads that already have an identity. Map each AWS IAM role that used to call GetSecretValue to one OpenBao role with a policy scoped to its own paths. Storage is the other decision that shapes operations. OpenBao documents integrated storage (Raft) and PostgreSQL as its supported high availability backends, and describes PostgreSQL as easier to operate safely than Raft. Confirm the current release, such as the latest entry on the OpenBao releases page, and check the OpenBao migration guide before you rely on it, because that guide covers upgrades from Vault rather than imports from AWS. Your import will be a new write path, so test it against a non-production instance first.
How DeployOpen scopes, delivers and supports an AWS Secrets Manager exit
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For an AWS Secrets Manager exit, that means treating the export as a controlled, logged and verified change to how credentials are read, stored and rotated, rather than a one-off script.
How we scope
- Inventory every secret, its KMS key, its rotation Lambda and the IAM roles that read it
- Map each workload to the access path it uses today and the OpenBao auth method it will use
- Agree the written scope, deliverables and timeline with you before any secret value is read
How we build
- Build the BatchGetSecretValue export with least-privilege IAM and KMS permissions, limited to the agreed secret list
- Deploy OpenBao in your environment and test dynamic secrets or static roles against non-production systems first
- Test the export and cutover in a staging copy, including CloudTrail entries and rollback steps
How we hand over
- Document the export procedure, access policies, rotation design and decommissioning steps in a runbook your team owns
- Deliver evidence of what was read, when and by which role, drawn from CloudTrail and OpenBao audit logs
- Walk your platform and security teams through operation, unseal procedures and recovery before handover
How we support
- Offer ongoing support, upgrades and continuous testing of the OpenBao deployment as a retainer
- Track OpenBao releases and plan upgrades against the security fixes each release carries
- Confirm with the vendor or your own environment which quotas, plugins and features apply to your setup
