Backup & Replication Requirements

This page summarizes what you need in place before enabling Cloudaware Backup & Replication across your environment.

Prerequisites

Before you begin, confirm that:

Cloudaware CMDB is populated.
Core AWS accounts and Google Cloud projects are onboarded so that instances, databases, buckets and disks appear in CMDB.
Cloud integrations are healthy.
AWS and Google Cloud integrations are configured with least‑privilege roles or service accounts that allow Cloudaware to discover resources, read tags, and create snapshots, images, and bucket copies as required.

For provider‑specific onboarding steps, refer to AWS and Google Cloud guides.

For AWS, the Cloudaware IAM role or user used by Backup & Replication typically requires:

EC2/EBS
- DescribeInstances, DescribeVolumes, CreateSnapshot, DescribeSnapshots, DeleteSnapshot.
- CreateImage, DeregisterImage for AMI management.
- Read and write access to backup and replication tags.
RDS
- DescribeDBInstances, DescribeDBSnapshots, CreateDBSnapshot, DeleteDBSnapshot.
S3
- ListBucket, GetObject, PutObject on source and target buckets involved in S3 backups.
- Bucket‑level permissions for replication and lifecycle configuration where used.
Cross‑region/cross‑account replication
- Permissions to copy AMIs and snapshots to target regions.
- Optional cross‑account roles if backup media is kept in dedicated backup accounts.

Review your current IAM policies with your Cloudaware representative to ensure they align with best practices.

Key constraints inherited from the underlying cloud platforms include:

Regions – all commercial AWS regions are supported, including GovCloud, where the Cloudaware integration is configured; similar constraints apply to other providers.
EC2 instance types – all EBS‑root instances are supported; instance‑store‑only instances and “S3‑backed” legacy instances are not.
Operating systems – all OS types supported by the cloud provider are generally supported for snapshot‑based backups.
RDS instance types – all standard RDS engines and instance families are supported via snapshots; engine‑specific limitations (for example, snapshot size or retention) still apply.
Policy types – daily, weekly, monthly retention policies are supported for snapshot‑based backups; some plug‑ins additionally support hourly backups.

Backup & Replication relies on standardized tags to understand backup intent. Typical patterns include:

A backup policy tag (for example, gig-backup) with values like 3d-10w-12m to indicate how many daily, weekly, and monthly backups to keep.
A replication policy tag (for example, gig-replicate) with values like 2@us-west-1;3@eu-west-1 to indicate how many recent images to replicate to each region.

These tags must be allowed by your tag governance and not blocked by SCPs or organization policies.

In addition to permissions, ensure that:

Cloudaware can reach cloud control plane APIs for the regions where you plan to run backups and replication.
Any OS‑level or database‑level backup plug‑ins can reach their targets over SSH or native protocols.
If you use cross‑account S3 backups, the Cloudaware IAM user or role has write access to the target bucket, and bucket policies allow the traffic.

Coordinate specific endpoints, proxies, and IP ranges with your security team if you operate under strict egress controls.

Cloudaware is designed to handle large environments:

Missing backup and replication alerts are emitted when assets that should be protected are missing recent backups or replication copies.
Concurrent backup jobs – Cloudaware can run many backup jobs in parallel but throttles concurrency to respect provider rate limits.
Concurrent replication jobs – EC2 and other image replications are throttled per account/region; some operations (such as RDS snapshot replication) may be effectively single‑threaded per account/region due to provider limits.

If you plan very large backup waves or heavy historical backfills, coordinate concurrency settings with Cloudaware Support.