Migrating Redis OSS Across AWS Accounts — Real Issues Faced and the Production-Safe Solution

Migrating Redis OSS data across AWS accounts sounds simple:

Export snapshot → Restore in another account.

In practice, it is not that straightforward.

In this case, we migrated Redis OSS from Account A to Account B in the same region (ap-south-1) using default encryption (SSE-S3).

This post documents:

• Why snapshot export initially failed

• Why cross-account restore failed

• What actually worked

• The production-safe migration pattern

No assumptions. Only what was tested and validated.

---

1. Architecture Overview

Source Account (Account A)
Redis OSS → Manual Snapshot → Export to S3

Target Account (Account B)
S3 (copied snapshot) → Restore Redis OSS

Key constraint:
No public bucket. No insecure workaround. Production-safe design.

---

2. Phase 1 — Snapshot Export to S3 (Why It Failed)

When exporting the snapshot from ElastiCache to S3, we encountered:

ElastiCache was unable to validate the authenticated user has access to the S3 bucket

At that time:

• Bucket existed

• Same region (ap-south-1)

• Block public access enabled

• SSE-S3 encryption enabled

• Bucket policy configured

Yet export failed.

---

Root Cause

In standard AWS regions, ElastiCache export and seed operations commonly require ACL-based grants using the service Canonical ID.
In opt-in regions, AWS also documents a bucket policy–based approach using the elasticache-snapshot service principal.

Modern S3 guidance promotes disabling ACLs, but Redis export requires:

• ACLs enabled

• ElastiCache Canonical ID added

Without ACL configuration, export validation fails.

---

Correct Export Configuration

Step 1 — Enable ACLs

S3 → Bucket → Permissions → Object Ownership

Change from:

Bucket owner enforced

To:

ACLs enabled (Bucket owner preferred)

Save changes.

---

Step 2 — Add ElastiCache Canonical ID

S3 → Bucket → Permissions → ACL → Edit

Add Canonical ID:

540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353

Grant:

• Objects → List, Write

• Bucket ACL → Read, Write

Important:

• Block Public Access remained enabled

• No “Everyone” permission added

After this configuration, the snapshot export succeeded.

For standard (non-GovCloud) AWS regions, ElastiCache uses the same Canonical ID. Only GovCloud regions use different Canonical IDs. Always verify from AWS official documentation before configuring.

---

3. Phase 2 — Cross-Account Restore Attempt

Snapshot successfully exported to:

s3://redis-oss-backup-bucket/redis-oss-backup-0001.rdb

The next step was restoring in Account B.

The restore operation is executed by the ElastiCache service in the target account, and cross-account restore requires exact service principal and permission configuration, and our bucket policy did not satisfy those requirements.

---

Attempt — Cross-Account Bucket Policy

We initially configured a bucket policy allowing the ElastiCache service principal access. However, snapshot seeding requires the correct regional elasticache-snapshot service principal and specific permissions (including s3:GetBucketAcl). Our configuration did not match the documented requirement, which contributed to restore failure.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowElastiCacheFromAccountB",
      "Effect": "Allow",
      "Principal": {
        "Service": "elasticache.amazonaws.com"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::redis-oss-backup-bucket",
        "arn:aws:s3:::redis-oss-backup-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "ACCOUNT_B_ID"
        }
      }
    }
  ]
}

Restore failed with:

No permission to access S3 object

Even though:

• Region matched

• Object key was correct

• SSE-S3 encryption used

• Service-linked role existed

Restore did not succeed.

---

Why It Failed

In our tested configuration, cross-account restore required more precise service principal permissions than our implementation provided.

The restore process expects:

• Bucket ownership alignment

• Same-account execution boundary

In our tested implementation, the cross-account restore failed with the bucket policy configuration we applied. Rather than iterating further on service-layer permission nuances, we adopted a production-safe pattern: copy the snapshot into an S3 bucket owned by the target account and restore from there.

---

4. Diagnostic Test — Public Object

To isolate the issue, we temporarily made the object public.

Restore succeeded immediately.

This confirmed:

• Snapshot file was valid

• Region correct

• Encryption is not the issue

• The permission boundary was the root cause

Public access is not production-safe and was used only for troubleshooting.

---

5. Final Production-Safe Migration Pattern

Instead of forcing cross-account restore, we redesigned the architecture.

Correct Approach

Account A
Export snapshot → S3 bucket A

↓

Secure object copy

↓

Account B
Restore from S3 bucket B

This ensures ownership alignment and eliminates the cross-account restore boundary.

---

6. Implementation Steps

Step 1 — Create S3 Bucket in Account B

• Region: ap-south-1

• Block Public Access: Enabled

• Object Ownership: Bucket owner enforced

• Default Encryption: SSE-S3

---

Step 2 — Copy Snapshot Securely

aws s3 cp s3://redis-oss-backup-bucket/redis-oss-backup-0001.rdb \
s3://redis-oss-backup-bucket-b/redis-oss-backup-0001.rdb \
--source-region ap-south-1 \
--region ap-south-1

After copy:

• Object owner becomes Account B

• No cross-account policy required

Ownership alignment resolves the restore issue.

---

Step 3 — Restore in Account B

Use:

redis-oss-backup-bucket-b/redis-oss-backup-0001.rdb

Restore completed successfully.

---

7. When to Use Replication Instead

If the requirement is disaster recovery or continuous synchronization:

Use S3 Cross-Account Replication.

For one-time migration, manual secure copy is simpler and cleaner.

---

8. Key Engineering Takeaways

1. In standard regions, Redis OSS export typically requires ACL configuration with the ElastiCache Canonical ID.

2. Cross-account restore requires precise configuration of the service principal and permissions.

3. Ownership alignment via secure object copy eliminates cross-account complexity and reduces operational risk.

4. SSE-S3 simplifies cross-account migration.

5. Public object works but is insecure.

6. Ownership alignment is the key requirement.

7. Secure object copy is the cleanest production solution.

---

Final Principle

When migrating workloads across AWS accounts:

Do not force cross-account service execution boundaries when the service is not designed to support them.

Move the data.

Align ownership.

Restore cleanly.

That is production-grade cloud engineering.