13.3 Secure Data Lifecycle, Cross-Account Replication & Backup Vault Lock

13.3 Secure Data Lifecycle, Cross-Account Replication & Backup Vault Lock

Enterprise data resilience requires a multi-layered defense model combining continuous data replication, automated lifecycle hygiene, and immutable backup protection. A comprehensive security posture ensures that data is not only safeguarded against regional data center catastrophes and hardware failures, but also fortified against insider threats, credential theft, and sophisticated ransomware attacks that deliberately attempt to destroy recovery points.

To achieve this defense-in-depth posture, cloud security engineers must master three core AWS capabilities: Amazon S3 Replication (CRR and SRR) with cross-account KMS cryptographic mapping, automated storage hygiene via S3 Lifecycle Policies, and enterprise-wide immutable recovery through AWS Backup Vault Lock and Amazon Data Lifecycle Manager (DLM).

---

Amazon S3 Replication Architecture: CRR & SRR

Amazon S3 Replication enables automated, asynchronous copying of objects across Amazon S3 buckets. Organizations implement Cross-Region Replication (CRR) to satisfy geographic redundancy and disaster recovery mandates, and Same-Region Replication (SRR) to aggregate logs across multiple accounts or maintain distinct production and test sandboxes within the same AWS region.

Loading diagram...

Mandatory Architectural Prerequisites

1. S3 Versioning Enabled: S3 Versioning must be explicitly enabled on both the source bucket and the destination bucket.
2. IAM Execution Role: Amazon S3 requires an IAM service role (s3.amazonaws.com) possessing permissions to read from the source bucket and write to the destination bucket.
3. Network & Region Independence: Replication functions across different AWS regions (CRR) or within the same region (SRR), and between distinct AWS accounts.

---

Replicating Encrypted Objects with AWS KMS

By default, Amazon S3 replication does not replicate objects encrypted with AWS KMS. Replicating SSE-KMS encrypted objects requires explicit configuration across three architectural checkpoints:

1. Replication Rule Configuration

Within the bucket replication rule, the administrator must explicitly enable replication for KMS-encrypted objects and specify the destination AWS KMS Customer Managed Key (CMK) ARN:

• Set SourceSelectionCriteria.SseKmsEncryptedObjects.Status to Enabled.
• Specify the EncryptionConfiguration.ReplicaKmsKeyID pointing to the destination KMS key.

2. IAM Replication Role Permissions

The IAM replication role in the source account requires permissions to decrypt source objects and generate new data keys using the destination KMS key:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSourceKMSDecrypt",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:us-east-1:111122223333:key/12345678-1234-1234-1234-123456789012"
    },
    {
      "Sid": "AllowDestinationKMSEncrypt",
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "arn:aws:kms:us-west-2:444455556666:key/87654321-4321-4321-4321-210987654321"
    }
  ]
}

3. Destination KMS Key Policy (Cross-Account)

In cross-account replication, the destination Customer Managed Key in Account B must include a key policy statement explicitly allowing the source account's IAM replication role to call kms:Encrypt and kms:GenerateDataKey:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSourceReplicationRoleToEncrypt",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/S3ReplicationExecutionRole"
      },
      "Action": [
        "kms:Encrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "*"
    }
  ]
}

Exam Trap: SSE-C Is Replicated as Is: Amazon S3 replication does replicate objects encrypted with customer-provided keys (SSE-C), with no extra configuration, because it copies the encrypted object without decrypting it. The destination bucket must allow SSE-C (since April 2026 SSE-C is blocked by default on new buckets), and readers still need the original customer key.

---

Cross-Account Object Ownership & S3 Object Ownership

Historically, when objects were replicated across AWS accounts, the replicated object remained owned by the source AWS account that authored the object, preventing the destination bucket owner from accessing or managing the replica without cumbersome ACL grants.

The Modern Standard: BucketOwnerEnforced

AWS introduced S3 Object Ownership with the setting BucketOwnerEnforced (the default for all new S3 buckets):

• ACLs Disabled Completely: All access control lists (ACLs) are deactivated and ignored.
• Automatic Ownership Transfer: The destination bucket owner automatically becomes the sole owner of all objects written or replicated to the bucket.
• Unified IAM Governance: Access is governed exclusively through IAM policies and S3 bucket policies, eliminating legacy ACL permission drift.

For legacy environments where ACLs remain enabled, the replication rule must configure Ownership Overwrite (account: <destination-account-id>) to transfer ownership of replicated objects to the destination bucket owner.

---

Replication Behaviors for Deletions & S3 Replication Time Control (RTC)

Understanding how deletions propagate during replication is a major exam focus:

1. Delete Markers: If a user issues an unversioned DELETE request (without specifying a version ID), S3 creates a Delete Marker on the source bucket. By default, delete markers are not replicated. However, replication rules can be explicitly configured to enable Delete Marker Replication.
2. Version Deletions (Permanent Purges): If a user executes a DELETE request specifying a specific version ID, S3 permanently purges that version from the source bucket. Amazon S3 replication NEVER replicates permanent version deletions to the destination bucket. This architectural safeguard ensures that a malicious insider or compromised credential performing a mass purge in the primary account cannot cascade destruction to the replica archive.
3. S3 Replication Time Control (RTC): For mission-critical compliance and business continuity, S3 RTC provides an SLA guaranteeing that 99.99% of new objects are replicated within 15 minutes. S3 RTC exposes CloudWatch metrics for ReplicationLatency, BytesPendingReplication, and OperationsPendingReplication, allowing security teams to alarm on replication lag.

---

Amazon S3 Lifecycle Policies & Storage Hygiene

S3 Lifecycle policies automate data movement across storage classes to optimize cost and enforce data retention limits. A comprehensive lifecycle policy manages two operational categories: Transition Actions and Expiration Actions.

Managing Noncurrent Versions

When versioning is enabled, modifying or deleting objects accumulates noncurrent versions over time. Without lifecycle management, storage consumption and costs grow unboundedly. Security teams define lifecycle rules to retain noncurrent versions for disaster recovery while purging older versions:

• NoncurrentVersionTransition: Moves noncurrent versions to low-cost archive tiers (such as S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive) after a set duration (e.g., 30 days).
• NoncurrentVersionExpiration: Permanently deletes noncurrent versions after a designated retention period (e.g., 90 days), while optionally configuring NewerNoncurrentVersions to ensure that a minimum number of recent versions (e.g., 3 versions) are always retained.

The Critical AbortIncompleteMultipartUpload Hygiene Rule

When client applications upload large files using the S3 Multipart Upload API, the upload splits the object into multiple chunks. If an upload stream is interrupted due to a network timeout, client crash, or process abort, Amazon S3 stores the completed parts indefinitely.

• Security & Cost Threat: Incomplete multipart uploads consume storage capacity and incur ongoing storage charges every month, yet the partial objects are completely invisible to standard S3 bucket listings (s3:ListObjects).
• Mandatory Hygiene Rule: Every production S3 bucket must implement an AbortIncompleteMultipartUpload lifecycle action that automatically aborts incomplete multipart uploads and permanently deletes orphaned chunks after a specified number of days (e.g., 7 days).

{
  "Rules": [
    {
      "ID": "CleanIncompleteMultipartUploadsAndOldVersions",
      "Status": "Enabled",
      "Filter": {},
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 90,
        "NewerNoncurrentVersions": 3
      }
    }
  ]
}

---

AWS Backup: Centralized Governance Across AWS Organizations

AWS Backup provides a fully managed, policy-driven backup service that centralizes and automates data protection across AWS services: Amazon EBS volumes, Amazon EC2 instances, Amazon RDS databases, Amazon Aurora clusters, Amazon DynamoDB tables, Amazon EFS file systems, Amazon FSx, Amazon S3, and AWS Storage Gateway.

Centralized Multi-Account Governance

Through native integration with AWS Organizations, security teams implement centralized backup governance:

• Central Backup Policies: Defined in the AWS Organizations management account or delegated administrator account, and attached directly to organizational units (OUs) or member accounts.
• Immutable Policy Enforcement: Member account administrators cannot disable, alter, or override backup policies assigned by corporate security.
• Cross-Account & Cross-Region Backup Copies: Automated backup plans can schedule backups in member accounts and automatically copy the recovery points to an isolated, centralized backup vault in a dedicated security or disaster recovery account. This isolates backups from production account compromises.

---

AWS Backup Vault Lock: Immutable Ransomware Defense

Ransomware operators frequently compromise administrative credentials and systematically delete backups before deploying encryption payloads, neutralizing disaster recovery options. AWS Backup Vault Lock prevents this attack vector by enforcing WORM immutability on backup recovery points stored in backup vaults.

Loading diagram...

Operational Modes: Governance vs. Compliance

1. Governance Mode:
   • Vault locks can be deleted or modified by authorized IAM principals possessing the backup:DeleteBackupVaultLockConfiguration permission.
   • Ideal for operational testing, development environments, and internal governance where administrative flexibility is preserved.
2. Compliance Mode:
   • Permanent & Irreversible: Once locked and the grace period expires, NOBODY—including the AWS account root user, organization administrators, or AWS Support—can delete the vault lock configuration or reduce retention periods.
   • Zero Early Deletion: Recovery points stored within the vault cannot be deleted under any circumstances until their individual retention periods expire.
   • The Mandatory Grace Period (Cool-Off Period): When configuring Compliance Mode, administrators must specify a grace period of at least 3 days (72 hours). During this cooling-off window, the lock configuration can be modified or deleted. Once the grace period elapses, the lock transitions to locked and becomes completely immutable.
   • Min/Max Retention Days: Enforces boundaries on all backups written to the vault. Any backup job attempting to store a recovery point with a retention duration shorter than MinRetentionDays or longer than MaxRetentionDays is automatically rejected.

---

Amazon Data Lifecycle Manager (DLM) for EBS Snapshots

While AWS Backup provides unified multi-service backup policies, Amazon Data Lifecycle Manager (Amazon DLM) offers specialized, automated lifecycle management tailored specifically for Amazon EBS volumes and EBS-backed AMIs.

• Tag-Based Automation: DLM policies target EBS volumes based on resource tags (e.g., backup: daily-prod). Volumes bearing matching tags are automatically backed up on schedule without requiring manual snapshot creation.
• Automated Retention & Archiving: DLM enforces retention limits (count-based or age-based). Furthermore, DLM supports automated tiering to the EBS Snapshots Archive tier, lowering storage costs by up to 75% for snapshots retained for long-term compliance.
• Cross-Region and Cross-Account Copying: DLM policies can automatically copy snapshots to another AWS region or cross-account to a disaster recovery account, encrypting the copied snapshots with the destination account's KMS Customer Managed Key.

---

Specialty Exam Pitfalls & Architectural Traps

1. Blocked SSE-C on the Destination: S3 replication supports SSE-C objects, but if the destination bucket still has SSE-C blocked (the default for new buckets since April 2026), those replication requests fail with 403. Unblock SSE-C on the destination (BlockedEncryptionTypes set to NONE) or stop using SSE-C at the source.
2. The Destination KMS Key Grant Omission: In cross-account S3 replication with SSE-KMS, configuring the IAM replication role in Account A with kms:Encrypt on the Account B key, but forgetting to update the KMS key policy in Account B to trust Account A's replication role. Replication fails silently or logs AccessDenied in CloudWatch replication metrics.
3. Expecting Version Deletions to Replicate: Assuming that calling DeleteObject with a specific version ID on the source bucket will delete the corresponding version in the replica bucket. S3 replication deliberately never replicates permanent version purges to prevent cascading data destruction.
4. Ignoring Incomplete Multipart Uploads: Omitting the AbortIncompleteMultipartUpload lifecycle action on high-volume S3 buckets. Months of failed multipart uploads leave hundreds of gigabytes of hidden, unreferenced parts that inflate AWS storage billing.
5. The Backup Vault Lock Grace Period Window: Attempting to immediately test the irreversibility of AWS Backup Vault Lock in Compliance mode without accounting for the mandatory 72-hour grace period. The vault lock can still be deleted during the grace period; it only becomes permanently locked after the cool-off timer expires.