Troubleshooting AWS Backup failures using Kiro CLI

Protecting business-critical data with AWS Backup is essential for operational resilience, regulatory compliance, and ransomware recovery. However, when backup or restore jobs fail, the root cause often spans multiple AWS services—AWS Identity and Access Management (IAM) role permissions, AWS Key Management Service (AWS KMS) key policies, backup vault access policies, and AWS Organizations trust configurations. A single misconfiguration in any of these layers can silently break your data protection strategy.

Diagnosing these failures requires correlating configurations across the AWS Backup console, IAM policies, KMS key policies, and CloudTrail logs—demanding deep expertise across multiple services. Kiro CLI is an AI-powered command-line tool that simplifies this process by automatically analyzing service configurations, policies, and permissions in a single workflow. In this post, we extend that approach to AWS Backup—walking through three real-world scenarios where Kiro CLI identifies why backup jobs fail, restore operations are blocked, and cross-account copies don't complete.

Solution overview

This solution uses Kiro CLI to diagnose AWS Backup failures by analyzing the complete permission chain across multiple services:

• Backup job failures — Traces IAM service role permissions, resource-level policies, and tag-based access controls
• Restore job failures — Analyzes KMS key policies, grant mechanisms, and service role permissions
• Cross-account copy failures — Evaluates AWS Organizations settings, destination vault access policies, and cross-account IAM trust

Kiro CLI automatically correlates findings across these layers, identifies the specific policy statement or missing permission causing the failure, and provides actionable remediation with exact policy JSON you can apply.

Prerequisites

To get started, complete the following prerequisite steps:

1. If you're new to Kiro CLI, refer to Get started in the Kiro documentation for initial setup guidance.
2. Install Kiro CLI:
   • Follow the installation steps in the documentation based on your operating system
   • Verify the installation by running kiro --version in your terminal
3. AWS credentials configuration:
   • Configure your AWS credentials using aws configure
   • If you want to use a profile other than the default, you can reference specific profiles within your queries
   • If you're troubleshooting permissions for a different role, verify that your credentials can describe that role's policies
4. Required IAM permissions for troubleshooting (read-only):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "backup:DescribeBackupJob",
        "backup:DescribeRestoreJob",
        "backup:DescribeCopyJob",
        "backup:GetBackupVaultAccessPolicy",
        "backup:ListBackupVaults",
        "backup:ListProtectedResources",
        "iam:GetRole",
        "iam:GetRolePolicy",
        "iam:ListAttachedRolePolicies",
        "iam:GetPolicy",
        "iam:GetPolicyVersion",
        "kms:DescribeKey",
        "kms:GetKeyPolicy",
        "kms:ListGrants",
        "ec2:DescribeVolumes",
        "rds:DescribeDBInstances",
        "organizations:DescribeOrganization",
        "cloudtrail:LookupEvents"
      ],
      "Resource": "*"
    }
  ]
}

Although this post uses IAM user credentials for simplicity, production environments should use temporary credentials, such as AWS IAM Identity Center or AWS Security Token Service (AWS STS) assume-role, with MFA enabled.

Important: Kiro CLI can suggest policy changes and request permission to implement them; you can approve or deny each change. Always review suggested changes carefully, test in non-production environments, and follow your security review processes before applying to production. This post demonstrates Kiro CLI's diagnostic capabilities only, not automated remediation.

Launch Kiro CLI

Open your terminal, verify your AWS identity, then launch Kiro CLI:

$ aws sts get-caller-identity
{
    "UserId": "AIDAEXAMPLEID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/backup-admin"
}

$ kiro-cli chat

During diagnosis, Kiro CLI requests permission to run AWS commands. We recommend using y (yes) instead of t (trust) to validate each command before execution:

Kiro wants to run: aws backup describe-backup-job --backup-job-id "B1234567-89AB-CDEF-0123-456789ABCDEF" --region us-east-1
Allow? (y/n/t):

---

Scenario 1: Troubleshoot backup job failure — IAM service role missing permissions

A DevOps engineer notices that nightly Amazon Elastic Block Store (Amazon EBS) backup jobs have been failing for three days. The AWS Backup console shows:

Backup job ID: B1234567-89AB-CDEF-0123-456789ABCDEF
Status: FAILED
Status message: Access denied performing ec2:CreateSnapshot on resource
  arn:aws:ec2:us-east-1:123456789012:volume/vol-0abc123def456789

The engineer uses Kiro CLI to diagnose the issue:

> My EBS backup job B1234567-89AB-CDEF-0123-456789ABCDEF failed with
  "Access denied performing ec2:CreateSnapshot." The backup was working
  fine until 3 days ago. Help me find the root cause.

Kiro CLI root cause analysis:

## Analysis Summary

Root Cause: Backup service role is missing the AWS managed policy for EBS backups.

### Permission Chain Analysis

1. Backup Job Details:
   • Resource: arn:aws:ec2:us-east-1:123456789012:volume/vol-0abc123def456789
   • IAM Role: arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole
   • Status: FAILED since 2026-05-01

2. Backup Vault Access Policy (NOT BLOCKING):
   • No restrictive access policy on vault

3. IAM Service Role (BLOCKING):
   • Attached policies:
     - AWSBackupServiceRolePolicyForRestores ✓
     - AWSBackupServiceRolePolicyForS3Backup ✓
     - AWSBackupServiceRolePolicyForBackup ✗ MISSING
   • Policy was detached on 2026-05-01 at 14:23:07 UTC

4. CloudTrail Evidence:
   • Event: DetachRolePolicy
   • Time: 2026-05-01T14:23:07Z
   • Principal: arn:aws:iam::123456789012:user/terraform-deployer
   • Source: Terraform apply

### Resolution
Re-attach the managed policy:

  aws iam attach-role-policy \
    --role-name AWSBackupDefaultServiceRole \
    --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup

Update Terraform to prevent future drift:

  resource "aws_iam_role_policy_attachment" "backup_policy" {
    role       = aws_iam_role.backup_service_role.name
    policy_arn = "arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup"
  }

Kiro CLI identified the missing policy and traced the exact CloudTrail event that caused the change, giving the team the information needed to fix both the immediate issue and the infrastructure-as-code drift.

---

Scenario 2: Troubleshoot restore job failure — KMS key policy blocks the backup service

A database administrator needs to restore an encrypted Amazon Relational Database Service (Amazon RDS) instance from a recovery point. The restore fails with a KMS error—demonstrating how encryption permissions for restore differ from backup. A successful backup does not guarantee a successful restore.

Restore job ID: R9876543-21AB-CDEF-0123-456789ABCDEF
Status: FAILED
Status message: KMS key arn:aws:kms:us-east-1:123456789012:key/mrk-abc123
  is not accessible. Ensure the backup service role has kms:CreateGrant permission.

The administrator uses Kiro CLI:

> My RDS restore job R9876543-21AB-CDEF-0123-456789ABCDEF failed with
  "KMS key is not accessible." The backup completed successfully last night
  but I can't restore from it. Why does backup work but restore doesn't?

Kiro CLI root cause analysis:

## Analysis Summary

Root Cause: KMS key policy allows kms:Decrypt (needed for backup) but does NOT
allow kms:CreateGrant (needed for RDS restore).

### Permission Chain Analysis

1. IAM Service Role Permissions (SUFFICIENT):
   • Has AWSBackupServiceRolePolicyForRestores ✓
   • Policy includes: kms:CreateGrant ✓ (in IAM policy)

2. KMS Key Policy (BLOCKING):
   • Key: arn:aws:kms:us-east-1:123456789012:key/mrk-abc123
   • Key policy grants to backup role:
     - kms:Decrypt ✓
     - kms:DescribeKey ✓
     - kms:GenerateDataKey ✓
     - kms:CreateGrant ✗ NOT GRANTED

3. Why Backup Works But Restore Doesn't:
   • Backup: Requires kms:Decrypt + GenerateDataKey → ALLOWED
   • Restore: Requires kms:CreateGrant (RDS uses grant mechanism
     for new instance encryption) → DENIED

   The KMS key policy is authoritative—both IAM AND key policy
   must allow the action.

### Resolution
Update KMS key policy to include CreateGrant:

  {
    "Sid": "AllowBackupServiceGrant",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole"
    },
    "Action": [
      "kms:CreateGrant",
      "kms:Decrypt",
      "kms:DescribeKey",
      "kms:GenerateDataKey"
    ],
    "Resource": "*",
    "Condition": {
      "Bool": {
        "kms:GrantIsForAWSResource": "true"
      }
    }
  }

Kiro CLI explained the critical distinction between backup and restore KMS requirements. The kms:GrantIsForAWSResource condition restricts grants to AWS service operations only, preventing the role from creating arbitrary grants.

---

Scenario 3: Troubleshoot cross-account backup copy failure — organizational trust gap

A security team configured a centralized backup account with a logically air-gapped vault for ransomware protection. Backup copy jobs from workload accounts to the central vault are failing:

Copy job ID: C5555555-AAAA-BBBB-CCCC-DDDDDDDDDDDD
Status: FAILED
Status message: Insufficient privileges to perform cross-account copy to
  destination vault arn:aws:backup:us-east-1:999888777666:backup-vault:
  central-air-gapped-vault

The administrator uses Kiro CLI:

> Cross-account backup copy job C5555555-AAAA-BBBB-CCCC-DDDDDDDDDDDD failed
  with "Insufficient privileges to perform cross-account copy." I'm trying to
  copy backups from account 123456789012 to the air-gapped vault in our
  security account 999888777666. What's blocking this?

Kiro CLI root cause analysis:

## Analysis Summary

Root Cause: TWO issues found.
(1) Destination vault access policy does not allow source account
(2) Cross-account backup not enabled in destination account

### Permission Chain Analysis

1. Source Account (SUFFICIENT):
   • Backup plan has cross-account copy action ✓
   • Service role has backup:CopyIntoBackupVault ✓
   • Cross-account backup enabled ✓

2. Destination Vault Policy (BLOCKING — Issue #1):
   • Only allows local account (999888777666)
   • Does NOT allow source account or organization

3. Organization Settings (BLOCKING — Issue #2):
   • Cross-account backup: ✗ NOT ENABLED in management account

### Resolution

Fix #1 — Update destination vault access policy:

In account 999888777666:

  aws backup put-backup-vault-access-policy \
    --backup-vault-name central-air-gapped-vault \
    --policy '{
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Principal": "*",
        "Action": "backup:CopyIntoBackupVault",
        "Resource": "*",
        "Condition": {
          "StringEquals": {
            "aws:PrincipalOrgID": "o-abc123def4"
          }
        }
      }]
    }' \
    --region us-east-1

Fix #2 — Enable cross-account backup from the management account:

  aws backup update-global-settings \
    --global-settings isCrossAccountBackupEnabled=true

Or via console: AWS Backup → Settings → Cross-account backup → Enable
(must be logged in with management account credentials)

Security Note: Vault lock settings remain unchanged.
Retention policies and deletion prevention still enforced.

Kiro CLI identified that cross-account backup failures require fixes in both the destination account (vault policy) and the management account (global settings)—a common point of confusion because the error appears in the source account. It also recommended aws:PrincipalOrgID rather than individual account ARNs for scalability.

---

Conclusion

Each scenario addressed a different layer of the permission stack:

• Scenario 1 — IAM service role misconfiguration caused by infrastructure-as-code drift
• Scenario 2 — KMS key policy gap where backup succeeds but restore fails
• Scenario 3 — Cross-account trust requiring coordinated changes in both accounts

Key takeaways:

1. Backup success does not guarantee restore success — Test restores regularly, especially for KMS-encrypted resources that require kms:CreateGrant
2. Monitor IAM role changes — Use AWS CloudTrail alerts for DetachRolePolicy events on backup service roles
3. Cross-account backup requires bilateral configuration — Both the source and destination accounts must be configured correctly
4. Use organization-level conditions — aws:PrincipalOrgID in vault policies scales better than individual account ARNs

To get started with Kiro CLI for your own backup troubleshooting, install Kiro CLI following the installation guide, configure read-only credentials spanning Backup, IAM, KMS, and CloudTrail, and provide the job ID and error message in natural language when a backup job fails.

Try Kiro CLI for your own AWS Backup troubleshooting scenarios, and share your questions and feedback in the comments.

---

TAGS: AWS Backup, Kiro CLI, resilience, encryption, cross-account, troubleshooting

---

Related AWS Storage Blog posts

• Troubleshooting Amazon S3 access denied errors using Kiro CLI
• Streamline ransomware protection while reducing cost with AWS Backup logically air-gapped vault primary backup
• Encrypt AWS Backup logically air-gapped vaults with customer-managed keys
• Scan backups for malware with Amazon GuardDuty Malware Protection for AWS Backup
• AWS Backup 2025 year in review: advancing recovery resilience

---