Vault and AWS Secrets Manager for Hybrid Secrets

Australian IT teams often connect on-premises applications in Sydney with cloud workloads in AWS, while Brisbane offices and Melbourne data centres add operational complexity. Integrating HashiCorp Vault with AWS Secrets Manager gives legacy systems a governed access path and gives AWS-native services a familiar secrets endpoint.

Vault should provide identity, policy, leasing and audit, while AWS Secrets Manager holds values needed by AWS workloads. The critical design choice is a single authoritative writer for each secret, preventing the two platforms from overwriting one another during rotation.

Treat the arrangement as a hybrid secrets lifecycle rather than a one-time copy. Plan source ownership, failover, credential revocation, regional placement and recoverability before any production secret moves.

Choose a clear trust model

Use Vault as the control plane for hybrid clients. Legacy applications authenticate to Vault and receive leased credentials; AWS workloads can use IAM roles to read AWS Secrets Manager directly or call Vault through the AWS auth method. Vault audit records and AWS CloudTrail then provide complementary evidence.

Where your Vault edition includes the relevant features, two common designs are available. The AWS Secrets Manager secrets engine lets Vault manage AWS-backed secret paths, while managed synchronisation can publish selected KV v2 paths into AWS. Confirm feature entitlements and version-specific commands before implementation.

Use a one-way flow for each secret: Vault to AWS, AWS to Vault, or direct cloud access. Bidirectional replication without conflict rules creates silent drift. Give the platform holding the canonical value responsibility for issuing and revoking every new version.

Prepare AWS Secrets Manager

Select a primary AWS region such as ap-southeast-2 in Sydney and define a recovery region, potentially ap-southeast-3 in Melbourne. Test whether regulated data may remain in those Regions and whether supporting logs, backups or support channels cross borders.

Adopt a naming standard such as prod/payments/db and apply environment, owner and rotation tags. Enable versioning, configure an appropriate KMS key where required, and include only the necessary GetSecretValue, PutSecretValue and DescribeSecret actions in workload roles.

Create the first non-sensitive test object from a controlled pipeline rather than a shell history. Verify access and service logging before connecting Vault:

aws secretsmanager describe-secret \
  --secret-id prod/payments/db \
  --region ap-southeast-2

aws secretsmanager get-secret-value \
  --secret-id prod/payments/db \
  --query VersionId \
  --output text \
  --region ap-southeast-2

Enable the Vault integration

Enable AWS authentication and bind it to the workload role expected by the application:

vault auth enable -path=aws aws

vault write auth/aws/config \
  bound_arns=arn:aws:iam::111122223333:role/payments-app

Create a Vault login role with a short TTL and a dedicated policy. The IAM principal still needs the required STS permissions, while the Vault server needs only the AWS Secrets Manager actions required by the selected pattern.

With ambient credentials supported by your release, configure the AWS Secrets Manager engine without embedding permanent access keys:

vault secrets enable -path=aws-sm aws-secrets-manager
vault write aws-sm/config region=ap-southeast-2

Attach a workload identity to the Vault node and prefer Vault Agent where local applications cannot reach the cluster. For managed synchronisation, create an AWS Secrets Manager destination, bind it to a narrowly scoped synchronisation role and test one KV v2 path before enabling the remainder.

Apply least-privilege access

Represent app permissions in a Vault policy, using the exact engine path and separating production from non-production:

path "aws-sm/store/prod-payments-db" {
  capabilities = ["read"]
}

If an AWS service reads AWS Secrets Manager directly, enforce a matching IAM resource policy for the exact secret ARN. Deny broad list operations, omit plaintext from logs, and review Vault audit events and CloudTrail records together. Every client should receive only the secret family it owns.

Design rotation and failure handling

Classify each value before automating rotation. Use Vault database or SSH backends for short-lived credentials, AWS-native IAM roles for AWS identities, and managed rotation for long-lived API credentials that cannot be leased.

Where AWS Secrets Manager owns a value, test the rotation Lambda through AWSCURRENT, AWSPENDING and AWSPREVIOUS before promotion. Where Vault synchronises into AWS, rotate in Vault and let the approved destination publish it; never perform concurrent writes from both systems.

Test Vault loss, revoked leases, stale cached secrets, KMS denial and an expired AWS session. A controlled break-glass procedure should identify the authorised Australian operator, capture an audit event and avoid leaving emergency credentials behind.

Roll out across Australian environments

Australian operations should use Sydney and Melbourne AWS Regions, account for AEST/AEDT daylight-saving transitions, and connect through Direct Connect or VPN rather than a public Vault endpoint. Align the design with ACSC guidance, including the Information Security Manual, where the organisation is in scope. Australian procurement often separates AWS consumption from locally delivered managed services, so contracts should state who owns policy, rotation and incident response. Teams can use IT Diversified’s AWS certification pathway to establish a shared AWS baseline before implementation.

Complete these checks before touching production:

• Confirm the Vault edition, feature entitlement and version-specific syntax.
• Assign one owner and one canonical store to each secret.
• Verify IAM, KMS, DNS, TLS and audit-event delivery.
• Test approved connectivity from Sydney, Melbourne and Brisbane.

During rollout, track operational outcomes rather than secret contents:

• Begin with a non-sensitive staging secret.
• Record version identifiers and hashes, never values.
• Exercise outage, revocation and session-expiry scenarios.
• Promote a canary workload before expanding access.

The resulting platform keeps one auditable owner for every secret while preserving the access patterns that hybrid and AWS-native workloads require.