Spring Cleaning: A Start-to-Finish Guide on Tidying up Your AWS Elastic Container Registry

Have you peeked inside your AWS Elastic Container Registry (ECR) lately? Any old or untagged images cluttering up the place? Don‘t fret – it happens to all of us container users!

Not keeping your ECR repositories spic and span can really bog down DevOps workflows. But have no fear! By the end of this guide, you‘ll have the confidence and know-how to whip those repositories back into shape!

First off, we‘ll go over exactly what ECR provides and why you‘d use it in the first place. Then we‘ll highlight the critical importance of staying on top of image removal. Finally, we‘ll roll up our sleeves and dig into multiple methods for taking out the trash – manually, via lifecycles, or even across all your repositories at once!

So grab your favorite cleaning playlist – it‘s time for some fun spring cleaning!

What is AWS ECR…and Why Should You Care?

Before we declutter anything, we need to level set on what this "ECR" is that I keep mentioning!

Amazon Elastic Container Registry (ECR) is AWS‘s managed Docker registry service. Let‘s break that down…

First, Docker registry:

  • Stores Docker container images
  • Enables teams to collaborate on building images
  • Handles image distribution to multiple hosts

And the managed service piece means:

  • AWS takes care of provisioning and configuring the registry infrastructure
  • Handles scalability and availability needs
  • Provides integrated access controls

Now, you may be using ECR if you have containerized applications running on services like:

  • Amazon ECS for hosting containers
  • Amazon EKS for running Kubernetes
  • AWS Lambda functions packaged as containers
  • Batch jobs built as Docker images

ECR provides a high performance home for the container images powering all these compute solutions while offloading the administration burden.

Why Image Management Matters

So now we know ECR is a secure, highly scalable place to store Docker images. But like any storage, it can fill up!

Accumulated images from months of builds can outlive their usefulness but continue accruing storage charges. They can also pose risks from potential vulnerabilities.

Here are 4 key drivers for actively expiring old images:

  1. Cost Savings – deletes reduce monthly storage bills!
  2. Security – outdated images may contain vulnerabilities
  3. Performance – bloated repositories slow deployments
  4. Recovery Support – minimizes backup/restore needs

Letting old images pile up leads to higher costs, security gaps, sluggish deploys, and recovery headaches.

Now are you ready to do some housecleaning? Fantastic! 🧹

Manual Image Removal

For one-off image removal, manual deletion may be the simplest approach. Here are a few methods for manual ECR image pruning:

1. Using the AWS Management Console

The ECR console provides an easy point-and-click way to delete selected images as needed:

  1. Login to your AWS account
  2. Navigate to the ECR Dashboard
  3. Select the repository containing images you wish to remove
  4. Check boxes next to any untagged images or those with outdated tags
  5. Click "Delete" and confirm the operation

However, this can be time consuming for repositories with hundreds of images.

2. From the AWS Command Line Interface

For more scalability, the AWS CLI can script image deletion tasks:

Prerequisites:

  • AWS CLI installed and configured
  • IAM permissions to delete ECR images

Example:

aws ecr batch-delete-image --repository-name myrepo --image-ids imageTag=app-v1

The CLI makes it easy to incorporate image removal into automation scripts!

3. Calling the API via Script

For maximum control, directly call the API via a script:

import boto3 

client = boto3.client(‘ecr‘)
images = client.list_images(repositoryName=‘myrepo‘)[‘imageIds‘]

for image in images:
   if image[‘imageTag‘].startswith(‘app-v‘): 
      client.batch_delete_image(repositoryName=‘myrepo‘, imageIds=[image])

This scripts deletes all images starting with app-v.

The scripting approach provides the most flexibility to target images via age, size, label etc.

Next we‘ll look at how defining lifecycle rules can really amplify our spring cleaning! 🧽

Automating Expiration with Lifecycle Rules

Manually managing deletions can become unscalable and tedious over time. A better long-term approach is to define lifecycle policies that trigger automatic cleanup.

Anatomy of a Lifecycle Rule

ECR lifecycle policies contain rules that expire images meeting defined criteria over time.

Components of a rule include:

  • Rule Priority – Rules execute in priority order
  • Description – Optional text on rule‘s purpose
  • Selection Criteria – Image age, count, or tag requirements
  • Action – Action when criteria met (expire, stop, etc)

For example, a rule could expire untagged images older than 30 days. Pretty handy!

Creating Lifecycles in the Console

The ECR console simplifies policy generation through a user friendly UI:

  1. Choose Lifecycle Policy from the left nav
  2. Click Create rule
  3. Enter selection criteria like "Delete untagged images > 30 days old"
  4. Select Expire for the action
  5. Click Save

Additional rules can build on the policy to meet other conditions like total repository disk usage.

Via the AWS CLI

The CLI can also define policies using a JSON file:

aws ecr put-lifecycle-policy \
    --repository-name myrepo
    --lifecycle-policy-text file://policy.json

Where policy.json contains your defined rules.

In Code with Boto3

For maximum control, codify policies via Boto3:

policy = {
  "rules": [ 
    {
     "rulePriority": 1,
     "selection": {
       "tagStatus": "untagged",
       "countType": "sinceImagePushed",
       "countUnit": "days",
       "countNumber": 30  
     },
     "action": { "type": "expire" } 
   }
 ]
}

client.put_lifecycle_policy(
    repositoryName=‘myrepo‘,
    lifecyclePolicyText=json.dumps(policy)
)

Here we generate a JSON policy on the fly before PUTing to the API.

Apply Your Magic Across All Repositories

Maintaining policies individually for every repo gets tedious quickly. Instead, automatically propagate a single policy across all repositories in bulk:

import boto3

session = boto3.Session()  
client = session.client(‘ecr‘)
repos = client.describe_repositories()[‘repositories‘]

policy_text = # my json policy   

for repo in repos:
   client.put_lifecycle_policy(
        repositoryName=repo[‘repositoryName‘], 
        lifecyclePolicyText=policy_text  
    )

Now a single policy json can be applied to unlimited repositories in one shot! 💥

Additional Tips for Container Tidiness

Here are some closing tips for amplifying your ECR spring cleaning:

🌟 Use image tags to make production images easy to identify

🌟 Set retention periods wisely – don‘t over-optimize if rollbacks are common

🌟 Monitor expiration metrics and tweak rules as needed

🌟 Integrate cleanup into CI/CD release pipelines

🌟 Leverage Docker system prune before pushing images

💡 Pro tip – combine lifecycles with IAM resource policies and repository immutability for maximum security!

After following the techniques in this guide, you should now have a slimmed down, organized, and secure ECR repository – nicely done! Give yourself a pat on the back!

Remember to keep monitoring those images counts and tuning your lifecycle rules when needed. Contact me with any other questions on elevating your ECR best practices!