AWS Backup Service Developer Guide

A comprehensive guide to AWS Backup prerequisites, encryption requirements, and service-specific configurations

📑 Table of Contents

• Welcome
• Core Requirements
  • Resource Tagging
  • CMK Encryption
  • Backup Architecture
• Best Practices
• Network Configuration
• Encryption Management
• Service-Specific Requirements
  • Amazon S3
  • Amazon EC2
  • Amazon EBS
  • Amazon RDS/Aurora
  • Amazon EFS
  • Amazon DynamoDB
  • AWS Storage Gateway
  • Amazon Redshift
  • AWS CloudFormation
• Non-Supported Resources
• Quick Reference
• Additional Resources

---

👋 Welcome, Developers

This is your quick guide to AWS Backup. Simply tag your resources with backup=enabled and encrypt them with a Customer Managed Key (CMK) shared with our central backup key. We handle the rest—scheduling, vaults, and cross-account replication. Focus on building; we've got your backups covered!

How It Works

• Automatic Backup Creation: Once tagged with backup=enabled, AWS Backup will automatically create backups in your local vault based on the schedule defined in the organization's backup policy (managed from the central backup administrator account).

• Cross-Account Copy: After backup creation, the backup is automatically copied to the central backup vault in the cbackupstorage-prod account for secure, long-term storage.

• Confirmation Step: You can confirm backup creation and copy status in the AWS Backup console in your source/member account.

---

📋 Core Requirements

1️⃣ Resource Tagging

Mark the resource as "no backup required"

simply add this AWS Resource Tag:

backup=disabled

Mark the resource as "we have a custom backup/restore solution"

simply add this AWS Resource Tag:

backup=custom

this is highly discouraged because in case of an account break, the backups are worthless!

To enable centralized backups, resources MUST have the tag:

backup=enabled

This tag triggers inclusion in the backup plan defined by the backup policy.

Details:

• Resource tagging is a fundamental way to organize and manage your AWS resources
• For AWS Backup, applying the backup=enabled tag acts as a signal to the pre-configured backup plan (defined via AWS Backup Policy)
• The backup policy uses tag-based resource selection, meaning only resources with this exact tag will be backed up

📖 Learn more about AWS Tagging for tagged-resources

2️⃣ CMK for Cross-Account & Central Vault Encryption

Resources must be encrypted with a Customer Managed Key (CMK) that is shared with the central backup KMS key to enable cross-account backup copies.

Single Central Encryption Key

This solution uses a central KMS key for encrypting backups, as recommended by AWS Control Tower. The key is accessible by members of the AWS organization to create and store backups in both member and central vaults.

Key Requirements for Backing Up Resources

• Resources must be encrypted with a Customer Managed KMS key (CMK)
• Unless the service supports full AWS Backup management (like S3 or DynamoDB with advanced features), ensure the central backup KMS key is shared with your member account's CMK
• The member account's key policy must allow the central backup storage account to use the key for encryption and decryption
• Note: Some services (like RDS) cannot change encryption on-the-fly; a newly encrypted snapshot must be created to switch keys

Key Policy Example

Add this statement to your member account's CMK policy to enable key sharing:

{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {
    "AWS": [
        "arn:aws:iam::<member-account-id>:user/KeyUser",
        "arn:aws:iam::692653576357:root"
    ]
  },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:DescribeKey"
  ],
  "Resource": "*"
},
{
  "Sid": "Allow attachment of persistent resources",
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "arn:aws:iam::<member-account-id>:user/KeyUser",
      "arn:aws:iam::692653576357:root"
    ]
  },
  "Action": [
    "kms:CreateGrant",
    "kms:ListGrants",
    "kms:RevokeGrant"
  ],
  "Resource": "*",
    "Condition": {
      "Bool": {
        "kms:GrantIsForAWSResource": true
      }
    }
}

📖 Learn more about CMKs
📖 Learn more about Cross-Account Backup Encryption

3️⃣ Overall Backup Architecture

Two-step process:

1. Local Backup Creation: Backup created in source account's local vault with short retention (typically 1 day)
2. Cross-Account Copy: Backup copied to central cbackupstorage-prod account vault with longer retention

Architecture Details

Step 1 - Local Backup Creation: The backup plan creates a recovery point of your tagged resource in the local backup vault within your AWS account (source account). This local vault has a short retention period to minimize costs.

Step 2 - Cross-Account Copy: Through a copy job, AWS Backup copies the recovery point to the central cbackupstorage-prod account's backup vault. The central vault has a longer retention period for secure, long-term storage.

Why this design? This ensures backups are stored independently in a separate account. If your account is compromised, backups remain safe in the central account. Local backups are automatically deleted after the short retention period to avoid additional costs.

📖 Learn more about Cross-Account Backup

---

🔐 Best Practices

🔑 KMS Key Best Practice

✅ Best Practice: Use separate CMKs for resources, central key for backups only

❌ Not Recommended: Using central key to encrypt your resources

Note: Keep your resource encryption keys separate from the central-backup encryption key to maintain proper security boundaries and simplify key management.

---

🌐 Network Configuration - S3 VPC Gateway Endpoint

📋 Overview & Background

Required for all member accounts in the Prod OU

AWS Backup is a fully managed AWS service — it operates at the AWS service layer and does not run inside your VPC. The backup jobs and cross-account copies to the central vault will continue to work regardless of whether you have an S3 VPC Gateway Endpoint or not.

However, your VPC-hosted workloads — EC2 instances, ECS tasks, Lambda functions inside a VPC, and any other compute running inside a VPC subnet — that directly read from or write to the S3 buckets tagged for backup will, without a Gateway Endpoint, route that S3 traffic via your NAT Gateway or Internet Gateway instead of the AWS private network. This leads to:

• Unnecessary NAT Gateway data processing costs — NAT Gateway charges ~$0.045/GB for all data processed, including S3 traffic that could otherwise be free via a private endpoint route
• Security / compliance risk — S3 traffic from your workloads is not confined to the private AWS network

An S3 VPC Gateway Endpoint is a horizontally-scaled, redundant VPC component that adds a route to your selected route tables, directing all S3-bound traffic from within the VPC to the AWS internal network — bypassing the NAT/IGW entirely.

• Cost: Free — no hourly charge, no data-processing fee
• Availability: Highly available by default (no single point of failure)
• Impact: Non-breaking; existing S3 traffic is automatically rerouted through the endpoint once route tables are updated
• Backup continuity: No impact on AWS Backup jobs or cross-account copies — these continue unchanged

You are responsible for creating the endpoint(s) in your own member account. This is a one-time, free, and non-disruptive change.

🗺️ Regions You Must Cover

The centralised backup plan currently runs in the following regions. You must create an S3 Gateway Endpoint in each region where you have VPCs and S3-backed workloads:

Region Code	Location
eu-central-1	Frankfurt
eu-west-1	Ireland
eu-west-3	Paris
ap-southeast-1	Singapore
us-east-1	Virginia

✅ Prerequisites

Before you start, gather the following from your member account:

1. The VPC ID(s) in each affected region where S3-backed workloads or backup-tagged resources run
2. The Route Table IDs associated with the subnets where those workloads live (private subnets especially)
3. Ensure that the IAM user, role, or pipeline you are using to deploy the change in your member account has the following permissions (these are standard VPC management permissions — all VPC API calls in AWS use the ec2: namespace):
   • ec2:CreateVpcEndpoint — to create the gateway endpoint
   • ec2:ModifyVpcEndpoint — to associate/disassociate route tables with the endpoint
   • ec2:DescribeVpcEndpoints — to verify the endpoint exists and is in available state
   • ec2:DescribeRouteTables — to identify which route tables to associate

Note: These permissions are only required by the person or pipeline deploying the endpoint in the member account. No changes are needed to the central backup account, the central vault, or the aws-controltower-BackupRole — those are managed by AWS Control Tower and this repo respectively, and are not affected by this change.

🛠️ How to Create the Endpoint

Option A — Terraform

Add the following resource to your Terraform configuration. Use a for_each or a module call to repeat it across all required regions:

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = var.vpc_id
  service_name      = "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"

  route_table_ids = [
    aws_route_table.private.id,   # add all relevant route table IDs
  ]

  tags = {
    Name = "s3-vpc-gateway-endpoint"
  }
}

Repeat per region using a module or for_each over the region list above.

Option B — AWS CDK (TypeScript)

If your account infrastructure is managed with CDK, add the following to your VPC stack:

import * as ec2 from 'aws-cdk-lib/aws-ec2';

// Assumes `vpc` is an existing ec2.Vpc or ec2.Vpc.fromLookup(...) reference
vpc.addGatewayEndpoint('S3GatewayEndpoint', {
  service: ec2.GatewayVpcEndpointAwsService.S3,
});

When no subnets parameter is specified (as above), CDK associates the endpoint with all route tables in the VPC by default. If you need to scope it to specific subnet groups only, pass the optional subnets parameter. Deploy the stack in each region listed above.

Option C — Manual (AWS Management Console)

1. Open the VPC console → Endpoints → Create endpoint
2. Set Service category to AWS services
3. Search for and select the service named com.amazonaws.<region>.s3 — make sure Type shows Gateway
4. Select your VPC
5. Under Route tables, tick every route table whose subnets need private S3 access (typically all private subnet route tables)
6. Leave Policy as Full access (you can restrict it later if needed)
7. Click Create endpoint

🔍 Verification

After creation, confirm the following:

1. Endpoint status — navigate to VPC → Endpoints in the console; the status should be Available
2. Route table entries — open each associated route table; you should see a new entry with destination pl-xxxxxxxx (S3 prefix list) and target vpce-xxxxxxxx
3. No internet-routed S3 traffic — optionally use VPC Flow Logs to confirm S3 traffic is no longer going through an internet or NAT gateway

📝 Important Notes

• Multiple VPCs in the same region: Create a separate endpoint for each VPC — endpoints are VPC-scoped
• Default VPC: If your workloads run in the default VPC, create the endpoint there too
• Endpoint policy: Leaving the policy as Full access is fine. Restrictive endpoint policies can break required S3 API access unless all necessary buckets/actions are explicitly allowed
• This does not replace IAM permissions: An endpoint is a network-layer control; IAM policies still apply as normal

📖 AWS Docs — Gateway VPC Endpoints for S3

---

🔑 Understanding AWS Backup Encryption Management

📋 Encryption Types Overview

Full AWS Backup Management (Independent Encryption)

Some services support independent encryption where AWS Backup can encrypt backups using the backup vault's KMS key, regardless of the source resource's encryption.

These services include:

• Amazon S3
• Amazon DynamoDB (with Advanced Features)
• Amazon EFS
• AWS CloudFormation

Inherited Encryption

Other services inherit the encryption settings from their source resource.

These services include:

• Amazon EC2
• Amazon EBS
• Amazon RDS/Aurora
• Amazon DynamoDB (without Advanced Features)
• AWS Storage Gateway
• Amazon Redshift

⚠️ Important: For services with inherited encryption (non-fully managed), ensure that the central backup KMS key is shared with your member account's CMK used to encrypt the specific resource. This key sharing is essential for cross-account backup operations to succeed.

---

📦 Service-Specific Requirements

Click on any service below to view detailed backup requirements and configuration:

📦 Amazon S3

Purpose: Ideal for highly available, scalable object storage with robust versioning and lifecycle management. Perfect for static assets, media, and data lakes.

Prerequisites

• Bucket versioning must be enabled
• AWS Backup only supports versioned S3 buckets
• An S3 VPC Gateway Endpoint must be present in the VPC(s) of the member account — see the Network Configuration section for step-by-step instructions

CMK Requirement

Optional, but a Customer Managed Key (CMK) is strongly recommended if default encryption is enabled on the bucket to ensure cross-account copy compatibility.

Backup Details

• Backup Type: Object-level and Snapshots
• Mechanism: AWS Backup utilizes S3's native versioning for object-level backups
• Encryption Management: ✅ Full AWS Backup Management (Independent Encryption)

Encryption Process

• Stage 1 (In-Account): The backup process uses the KMS key specified in the member account's backup vault. The backup is always encrypted, even if the source bucket is not.
• Stage 2 (Cross-Account): When copied to the central account, the backup is re-encrypted using the central backup vault's Customer Managed Key (CMK).

Cross-Account Status

✅ Works seamlessly

Restore

You can restore selected objects to the original bucket, a new bucket, or another existing bucket. The restore process leverages versioning and supports filtering by prefix.

💻 Amazon EC2

Purpose: Provides resizable compute capacity in the cloud. Use it to host web servers, run batch jobs, or perform high-performance computing tasks.

Prerequisites

• The EC2 instance must be in a running or stopped state
• The backup process captures the attached EBS volumes and the instance's launch configuration to create an Amazon Machine Image (AMI)

CMK Requirement

CMK encryption is Required. If any attached EBS volumes are encrypted, they must be encrypted with a Customer Managed Key (CMK) to allow for cross-account copying.

Backup Details

• Backup Type: EBS-Snapshot and AMI
• Mechanism: AWS Backup automates the creation of an AMI and snapshots of all attached EBS volumes when you select an "EC2 instance" for backup
• Encryption Management: ❌ Inherited Encryption (snapshots inherit from source EBS volumes)

Encryption Process

• Stage 1 (In-Account): The created AMI itself is unencrypted. However, the underlying EBS snapshots will inherit the encryption status from their source EBS volumes.
• Stage 2 (Cross-Account): The cross-account copy operation follows the same constraints as EBS volume backups; the destination vault must use a CMK. Ensure the central backup KMS key is shared with your member account's CMK.

Cross-Account Status

✅ AWS Backup does not back up the EC2 instance as a single resource. Instead, it creates an AMI that bundles the instance's launch data with snapshots of its attached EBS volumes.

Restore

A restore operation creates a new EC2 instance from the stored AMI and EBS snapshots. You will need to configure details for the new instance, such as instance type, VPC, and subnet.

💾 Amazon EBS

Purpose: Provides persistent block storage volumes for use with EC2 instances. Essential for databases, file systems, and boot volumes for your servers.

Prerequisites

The EBS volume must be in an "in-use" or "available" state.

CMK Requirement

Required if the volume is encrypted. Using an AWS-managed key (e.g., aws/ebs) is not permitted for cross-account operations.

Backup Details

• Backup Type: Snapshot
• Mechanism: AWS Backup manages the creation and lifecycle of incremental EBS snapshots
• Encryption Management: ❌ Inherited Encryption (snapshots inherit from source EBS volume)

Encryption Process

• Stage 1 (In-Account): The backup snapshot inherits its encryption from the source EBS volume. This encryption cannot be overridden during the backup creation process.
• Stage 2 (Cross-Account): Copying the backup to a central vault requires the destination vault to be encrypted with a Customer Managed Key (CMK). Ensure the central backup KMS key is shared with your member account's CMK. AWS-managed or Backup-managed keys are not supported for this step.

Cross-Account Status

✅ Works. It's recommended to have the EBS encrypted with CMK before creating a backup in source account.

Restore

A restore operation creates a new EBS volume from the selected snapshot. This new volume can then be attached to an EC2 instance, either manually or as part of the restore configuration.

🗄️ Amazon RDS / Aurora

Purpose: Managed relational database service for MySQL, PostgreSQL, Oracle, SQL Server, and Amazon Aurora. Simplifies setup, operation, and scaling of databases.

Prerequisites

• Automated backups enabled (or AWS Backup creates initial full snapshot, followed by incremental snapshots)
• DB engine version supported by AWS Backup

CMK Requirement

The source database must be encrypted with a Customer Managed Key (CMK) so that it stays encrypted after copying over to central backup account vault.

Notes

• With Amazon Aurora MySQL or PostgreSQL, copying Multi-AZ clusters across regions or accounts is possible, but not with Amazon RDS
• RDS Multi-AZ database instances can be copied, but Multi-AZ clusters do not currently support cross-Region or cross-account copy

Backup Details

• Backup Type: Snapshot
• Mechanism: AWS Backup creates automated snapshots per backup plan schedule using incremental backup strategy if the automated backups are enabled
• Encryption Management: ❌ Inherited Encryption (snapshots inherit from source database)

Encryption Process

• Stage 1 (In-Account): The backup snapshot inherits its encryption settings directly from the source database instance.
• Stage 2 (Cross-Account): Snapshots encrypted with AWS-managed keys (like 'aws/rds') cannot be shared or copied across different AWS accounts. Customer-managed KMS keys required for cross-account operations. Ensure the central backup KMS key is shared with your member account's CMK for encrypting and decrypting backups.

Cross-Account Status

• ✅ Works with RDS Single Instances, Aurora MySQL, PostgreSQL
• ❌ RDS Multi-AZ Clusters cannot be copied cross-account

Restore

A restore operation creates a new database instance from the selected snapshot. You must configure its new settings, such as instance class, parameter group, and subnet group.

📁 Amazon EFS

Purpose: Scalable, elastic file storage for use with AWS Cloud services and on-premises resources. Ideal for big data analytics, media processing, and content management.

Prerequisites

• The EFS file system must be in the "available" state
• Must be properly tagged for the backup policy to apply

CMK Requirement

CMK encryption is Optional, if the file system has encryption at rest enabled.

Notes

Ensure the file system is encrypted with a Customer Managed Key (CMK) and is shared with Central Backup KMS Key to facilitate seamless cross-account operations.

Backup Details

• Backup Type: File System Backup
• Mechanism: AWS Backup performs native, file-level backups of the EFS file system
• Encryption Management: ✅ Full AWS Backup Management (Independent Encryption)

Encryption Process

• Stage 1 (In-Account): The backup is always encrypted using the KMS key specified in the member account's backup vault.
• Stage 2 (Cross-Account): When copied, the backup is re-encrypted using the Customer Managed Key (CMK) of the central vault.

Cross-Account Status

✅ Works seamlessly

Restore

You can restore to a new EFS file system or to the original one. When restoring to the original, AWS Backup performs a file-level restore, so existing data that is not part of the recovery point is not overwritten.

⚡ Amazon DynamoDB

Purpose: Fast, flexible NoSQL database service for single-digit millisecond performance at any scale. Great for mobile, web, gaming, and IoT applications.

Prerequisites

Advanced Features for DynamoDB must be enabled for Cross-Region and Cross-Account copy of the backups via AWS Backup service.

CMK Requirement

Optional CMK encryption for source tables. If the table is encrypted and needs to be copied cross-account, it will either way be re-encrypted via central backup key.

Notes

DynamoDB backup capabilities depend on Advanced Features being enabled.

Backup Details

• Backup Type: Table Backup
• Mechanism: AWS Backup provides full management with vault KMS encryption, enabling cross-Region/cross-account copy, cold storage tiering, and centralized billing under "Backup" service
• Encryption Management:
  • ✅ With Advanced Features: Full AWS Backup Management (Independent Encryption)
  • ❌ Without Advanced Features: Inherited Encryption

Encryption Process

• Stage 1 (In-Account):
  • Without Advanced Features: Inherits table encryption
  • With Advanced Features: Uses backup vault KMS key and supports cross-account operations
• Stage 2 (Cross-Account):
  • Without Advanced Features: Cross-account copy will fail
  • With Advanced Features: Re-encrypts with central vault CMK for cross-account storage

Cross-Account Status

• ❌ Without Advanced Features: Cross-account and Cross-region backup not supported
• ✅ With Advanced Features: Works seamlessly and provides cost savings through tiering backups to cold storage, cost allocation tagging, cross-region copy, and cross-account copy capabilities

Restore

A restore operation creates a new DynamoDB table. You must provide a new table name. The restore can be done to the same region, a different region, or a different account (with Advanced Features enabled).

🔗 AWS Storage Gateway

Purpose: Connects on-premises software appliances with cloud-based storage to provide seamless integration with AWS storage services. Useful for hybrid cloud storage.

Prerequisites

• Only Volume Gateway is supported (File Gateway is not)
• The gateway must be tagged properly

CMK Requirement

CMK encryption Required. The volumes must be encrypted with a Customer Managed Key (CMK) so that the backup stays encrypted after copying to central vault.

Backup Details

• Backup Type: EBS Snapshot
• Mechanism: Backups of Storage Gateway volumes are taken and stored in Amazon S3 as Amazon EBS snapshots
• Encryption Management: ❌ Inherited Encryption (snapshots inherit from source volume)

Encryption Process

• Stage 1 (In-Account): The backup inherits the encryption from the source volume. No separate Backup-managed key is used.
• Stage 2 (Cross-Account): The destination (central) vault must use a Customer Managed Key (CMK) for re-encryption during the copy. Ensure the central backup KMS key is shared with your member account's CMK.

Cross-Account Status

✅ Ensure that the encryption key used for the volumes is a CMK to allow for cross-account functionality and the Central Key is shared with existing Resource encryption key.

Restore

A restore operation creates a new EBS volume from the snapshot, similar to a standard EBS restore.

📊 Amazon Redshift

Purpose: A fully managed, petabyte-scale data warehouse service. Best for large-scale data analysis and business intelligence reporting.

Prerequisites

The Redshift cluster must be in the "available" state.

CMK Requirement

CMK Encryption Required. The cluster must be encrypted with a Customer Managed Key (CMK) for member-account backup as it is not supported for cross-account copying.

Notes

• Within source accounts, AWS Backup supports Redshift clusters, but not snapshot management directly
• Tables cannot be backed up by themselves; tables are backed up as part of a cluster when the cluster is backed up only via using the automated snapshot scheduler in Amazon Redshift

Backup Details

• Backup Type: Snapshot
• Mechanism: AWS Backup manages manual snapshots and serverless restore points
• Encryption Management: ❌ Inherited Encryption (snapshots inherit from source cluster)

Encryption Process

• Stage 1 (In-Account): The backup inherits the encryption from the source cluster.
• Stage 2 (Cross-Account): Cross-account copies are not supported.

Cross-Account Status

❌ Not supported for Cross-Account and Cross-Region AWS Backup purposes.

Restore

A restore operation creates a new cluster or namespace. Both manual and serverless recovery points are supported.

☁️ AWS CloudFormation

Purpose: Infrastructure as code service allowing you to model, provision, and manage AWS and third-party resources. Great for automating infrastructure deployments.

Prerequisites

While the stack itself is backed up, the primary requirement is that all the individual resources within the stack must meet their own backup prerequisites and be tagged correctly.

CMK Requirement

Depends on the included resources. If any resource requires a CMK for cross-account copy, it must be configured.

Notes

Ensure that each resource within the stack is properly tagged and meets its respective backup prerequisites.

Backup Details

• Backup Type: Composite recovery point
• Mechanism: AWS Backup creates a composite recovery point that includes the stack's template along with backups of the associated resources
• Encryption Management: ✅ Full AWS Backup Management (Independent Encryption)

Encryption Process

• Stage 1 (In-Account): The composite backup is encrypted using the KMS key of the backup vault, demonstrating independent encryption support.
• Stage 2 (Cross-Account): The copy to the central vault works as long as the vault is configured with a Customer Managed Key (CMK).

Cross-Account Status

✅ Works seamlessly

Restore

A restore operation launches a new CloudFormation stack using the stored template and the backed-up state of the nested resources. This is known as a composite restore; not all resource types may restore perfectly.

---

⚠️ AWS Backup Non-Supported Resources

The following AWS resources are currently not supported or have limitations with AWS Backup cross-account functionality:

• 🔐 AWS Secrets Manager
• 🔧 AWS Systems Manager Parameter Store
• 🗄️ RDS Multi-AZ Clusters
• 📊 Amazon Redshift (Cross-Account Copy not supported)

📝 Note: We are currently working on workaround solutions for these non-supported backup resources.

📖 For further information, please visit our Confluence documentation

---

🔗 Additional Resources

For more detailed technical documentation, architectural diagrams, and implementation guides, please refer to our Confluence page:

• AWS Centralized Backup + Architecture Diagram

---

📝 Quick Reference

Required Steps for Any Resource

1. ✅ Tag resource with backup=enabled
2. ✅ Encrypt resource with Customer Managed Key (CMK)
3. ✅ Share central backup KMS key with your member account's CMK (for inherited encryption services)
4. ✅ Verify backup creation in AWS Backup console
5. ✅ Confirm cross-account copy to central vault

Encryption Quick Reference

Service	Encryption Type	CMK Required	Cross-Account Support
Amazon S3	Independent	Optional (Recommended)	Yes
Amazon EC2	Inherited	Yes (if encrypted)	Yes
Amazon EBS	Inherited	Yes (if encrypted)	Yes
Amazon RDS/Aurora	Inherited	Yes	Yes (except Multi-AZ Clusters)
Amazon EFS	Independent	Optional	Yes
Amazon DynamoDB	Independent (w/ Advanced) / Inherited	Optional	Yes (with Advanced Features)
AWS Storage Gateway	Inherited	Yes	Yes
Amazon Redshift	Inherited	Yes	No
AWS CloudFormation	Independent	Depends on resources	Yes

---

💰 Frequently Asked Questions (FAQ)

📊 AWS Backup Cost Considerations

Backup Storage Pricing

• Vaults themselves are free - No cost for creating backup vaults
• Storage charges apply - You are charged per GB per month of backup data stored
• Pricing varies by resource type - Different AWS services have different backup storage costs

📖 For detailed pricing information: AWS Backup Pricing

Backup Cost Calculator

Planning your backup costs? Use the official AWS Cost Calculator to estimate expenses:

🧮 Calculate your backup costs: AWS Backup Cost Calculator

What it provides: - Cost estimations for using AWS Backup Services - Breakdown by service type and storage requirements - Monthly and yearly cost projections - Cross-region copy costs

Cost Optimization Tips

• Local vault retention: Keep short retention periods (1 day) in local vaults to minimize costs
• Central vault strategy: Longer retention only in the central backup account
• Resource selection: Only tag critical resources with backup=enabled
• Lifecycle policies: Leverage cold storage for long-term retention when available

🔗 Useful Resources & Links

GitHub Repository

📂 Source Code & Backup Infrastructure: aws-backup GitHub Repository

Repository contains: - CDK infrastructure code - Backup policies and configurations - Deployment workflows - Documentation and examples

Documentation Links

📚 Understanding AWS Backup Encryption: Encryption Management Guide

🔐 Key Requirements for Backing Up Resources: Key Requirements Guide

Support & Contact

• Technical Issues & Concerns: Reach out to the CDX Team

❓ Common Questions

Q: Do I need to configure anything in AWS Backup console?

A: No! Once you tag your resources with backup=enabled and ensure proper encryption, everything is handled automatically by our centralized backup policy.

Q: How do I check if my backups are working?

A: Check the AWS Backup console in your Prod AWS Account to see: - Backup jobs status - Recovery points created - Cross-account copy status

Q: What happens if my resource is not encrypted?

A: For services with inherited encryption (like EBS, RDS), the backup will fail cross-account copy. Always encrypt your resources with a Customer Managed Key (CMK) as well as add Central Backup Key ARN to the existing encryption key policy.

Q: Can I restore backups myself?

A: Please reach out to CDX Team for restoration of the backups from Central Backup Account's Vault.

Q: How much will backups cost for my resources?

A: Use the AWS Backup Cost Calculator to estimate costs based on your resource types and retention requirements.

Q: Which regions are supported?

A: The backup solution works across all AWS regions where your resources are deployed that includes: Frankfurt, Virginia, Singapore, Ireland, and Paris. Cross-region copying is also supported.

---

Last Updated: 3rd March 2026
Maintained By: CDX Team

---

Last updated: March 31, 2026 at 15:48

By: Syed Ali

📄 View source

Repository: PIT-Shared/aws-backup