Protecting AWS CodeArtifact Repositories from Accidental Deletion

Why This Matters

A deleted CodeArtifact repository means:

• All packages in the repository are permanently lost
• CI/CD pipelines that pull from the repository immediately fail
• Republishing all private packages from source may require significant effort depending on the number of packages involved
• Production deployments are blocked until packages are republished

Organizations with hundreds or thousands of private packages in a single repository face significant recovery time if deletion occurs. Prevention is far simpler than recovery.

Protection Strategy

The following layers work together to prevent accidental deletion. Implement all three for defense in depth.

Layer 1: Domain Policy (Deny DeleteRepository)

The most effective protection is a domain-level policy that denies the codeartifact:DeleteRepository action for all principals. This prevents deletion regardless of IAM permissions.

Basic protection — deny repository deletion:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyRepositoryDeletion",
            "Action": [
                "codeartifact:DeleteRepository"
            ],
            "Effect": "Deny",
            "Resource": "*",
            "Principal": "*"
        }
    ]
}

Enhanced protection — also deny domain deletion and unauthorized policy changes:

While a domain cannot normally be deleted if it still contains repositories, adding codeartifact:DeleteDomain provides defense against edge cases (such as when the domain's KMS key becomes inaccessible). Denying PutDomainPermissionsPolicy and DeleteDomainPermissionsPolicy prevents unauthorized removal of the protection itself.

Note: The following is an enhanced example. Validate in a non-production environment before deploying. Adjust the admin role ARN to match your organization's access pattern.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyRepositoryAndDomainDeletion",
            "Effect": "Deny",
            "Action": [
                "codeartifact:DeleteRepository",
                "codeartifact:DeleteDomain"
            ],
            "Resource": "*",
            "Principal": "*"
        },
        {
            "Sid": "DenyDomainPolicyModification",
            "Effect": "Deny",
            "Action": [
                "codeartifact:PutDomainPermissionsPolicy",
                "codeartifact:DeleteDomainPermissionsPolicy"
            ],
            "Resource": "*",
            "Principal": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::*:role/CodeArtifactDomainAdmin"
                }
            }
        }
    ]
}

The second statement ensures only a designated admin role can modify the domain policy — preventing someone from removing the deletion protection without proper authorization.

When you need to intentionally delete a repository, use the designated admin role to temporarily update the policy, perform the deletion, then restore the original policy.

You can also apply deletion protection as a repository-level policy for more granular control — protecting high-value production repositories while leaving development repositories deletable.

See: Protect repositories from being deleted | Delete a domain

Layer 2: Service Control Policy (SCP)

For organizations using AWS Organizations, an SCP provides an additional guardrail that applies across all accounts in the organization or specific OUs. This is useful when you want to enforce protection centrally, regardless of individual account IAM policies.

Note: The following is an example pattern. Validate in a non-production environment before deploying to your organization. This policy only affects the codeartifact:DeleteRepository action and does not impact any other CodeArtifact or AWS operations.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyCodeArtifactRepoDeletion",
            "Effect": "Deny",
            "Action": "codeartifact:DeleteRepository",
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "aws:PrincipalArn": "arn:aws:iam::*:role/BreakGlassAdmin"
                }
            }
        }
    ]
}

This example denies repository deletion for all principals except a designated break-glass role. Adjust the condition to match your organization's emergency access pattern.

See: Service control policies (SCPs)

Layer 3: CloudTrail Alerting with EventBridge

Even with preventive controls in place, you should detect and alert on deletion attempts. CodeArtifact API calls are logged in AWS CloudTrail, and you can use Amazon EventBridge to trigger alerts when a DeleteRepository call is made — whether it succeeds or is denied by policy.

Note: The following is an example event pattern. Test in your environment before deploying. This rule is detection-only and does not block any operations.

Create an EventBridge rule matching CodeArtifact deletion events:

{
    "source": ["aws.codeartifact"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
        "eventSource": ["codeartifact.amazonaws.com"],
        "eventName": ["DeleteRepository"]
    }
}

Route this to an SNS topic or a Lambda function that notifies your security or platform team. This provides visibility even when the deletion is blocked by policy — repeated denied attempts may indicate a misconfigured automation or a compromised credential.

See: Logging CodeArtifact API calls with AWS CloudTrail

Additional Recommendations

IAM least privilege: Review which IAM roles and users have codeartifact:DeleteRepository permissions. In most environments, only a small number of administrative roles should have this permission. Remove it from developer and CI/CD roles that only need read/publish access.

Separate production from development: Use separate repositories (or separate domains) for production and development packages. Apply strict deletion protection to production repositories while allowing more flexibility in development environments.

Upstream repository pattern: Configure production repositories with upstream repositories. If a production repository only pulls from an upstream rather than hosting packages directly, the blast radius of any single repository deletion is reduced.

When to Intentionally Delete a Repository

If you need to delete a protected repository:

1. Use the designated admin role to update the domain policy, excluding the specific repository ARN from the deny statement
2. Delete the repository through the console or CLI
3. Immediately restore the original deny-all policy

Document this process in your team's runbook so it is not performed ad-hoc.

Summary

CodeArtifact repository deletion is permanent. A layered approach — domain policy, SCP, and CloudTrail alerting — provides defense in depth against accidental deletion. The domain policy is the simplest and most effective single control — and can be enhanced to also protect the domain itself and prevent unauthorized policy changes. Add SCPs for organizational enforcement and CloudTrail alerting for visibility into both successful and denied deletion attempts.

Resources

• Delete a repository
• Protect repositories from being deleted
• Delete a domain
• Repository policies
• Logging CodeArtifact API calls with AWS CloudTrail
• AWS CodeArtifact events in EventBridge
• Service control policies (SCPs)