Remember that Lambda function I built to work around EC2 Image Builder’s Distribution Settings wiping your Launch Template config? You can bin it. AWS have updated the Distribution Settings behaviour and it now preserves your existing Launch Template settings when it creates a new version. The custom Lambda updater is no longer required.

A quick recap

In Half Baked Images I walked through the pain of integrating EC2 Image Builder with Terraform-managed Auto Scaling Groups. The core issue was that when EC2 Image Builder distributed a new AMI and updated your Launch Template, it created a new version containing only the AMI ID and account ID. Everything else, i.e. instance profile, security groups, key pair, block device mappings was gone.

The result? Your ASG would scale up instances with no instance profile, no security groups, and none of the configuration you’d carefully defined. Not ideal.

My solution was a two-parter:

1. Use an SSM Parameter as the source of truth for the AMI ID, updated by Image Builder’s Distribution Settings.
2. Deploy a custom Lambda function, triggered by EventBridge, that would read the latest AMI ID from SSM and create a proper new Launch Template version. One that actually included all the important bits.

It worked. It was reliable. But it was also plumbing that shouldn’t have been necessary.

What changed?

AWS have updated the EC2 Image Builder Distribution Settings behaviour. The documentation now states:

When launchTemplateConfigurations are present during the distribution process, Image Builder creates a new version of the launch template that includes all of the original settings from the template, and the new AMI ID from the build.

The important bit there: All of the original settings from the template.

That’s the bit that was missing before. Previously, Image Builder would create a new Launch Template version with only the AMI ID, effectively a blank template with a picture attached. Now it carries forward your existing configuration and simply swaps in the new AMI ID.

This is exactly the behaviour I expected when I first configured the launch_template_configuration block in my distribution config. It’s what most people would reasonably expect. And now it actually works that way.

What does this mean practically?

If you followed my original approach, you can simplify things significantly.

What you can remove

• The Lambda function that created new Launch Template versions with the full configuration.
• The EventBridge rule that triggered that Lambda on successful image builds.
• The associated IAM roles and policies for the Lambda function.
• Any CloudWatch log groups you set up for the Lambda.

That’s a decent chunk of infrastructure that existed purely to work around a limitation that no longer exists.

What you should keep

• The SSM Parameter approach is still a good pattern. Having a single source of truth for your AMI ID that both Terraform and Image Builder can reference is clean and avoids the bootstrapping headaches I described in the original post.
• The lifecycle ignore on the SSM Parameter value in Terraform, this is still needed so Terraform doesn’t fight with Image Builder over who owns that value.

What to add back

You can now use the launch_template_configuration block in your distribution config with confidence:

resource "aws_imagebuilder_distribution_configuration" "dist" {
  name = "${var.project}-dist"

  distribution {
    region = var.region

    ami_distribution_configuration {
      name        = "${var.project}-{{imagebuilder:buildDate}}"
      description = "Custom built AL2023 image"

      ami_tags = {
        OS       = "AmazonLinux2023"
        Hardened = "true"
        Name     = "${var.project}-{{imagebuilder:buildDate}}"
      }
    }

    launch_template_configuration {
      launch_template_id = aws_launch_template.my_lt.id
      account_id         = local.account_id
      set_default_version = true
    }
  }
}

Note the set_default_version = true… this tells Image Builder to set the newly created version as the default. Combined with the preserved settings, this means your ASG will pick up the new AMI on the next scale event without any Lambda glue in the middle.

Updated lab

I’ve updated the autoscaling_with_imagebuilder lab to reflect this. The Lambda updater and its associated EventBridge rule have been removed. The distribution config now handles the Launch Template update natively, as it always should have.

If you previously deployed the lab with the Lambda approach, you can safely remove those resources and update your distribution configuration. The SSM Parameter pattern remains, it’s still useful for the Terraform bootstrapping needs.

Thoughts

I’ll be honest, this is a satisfying update to write. The original solution worked, and I do think it was a reasonable approach given the constraints at the time. But it always felt like I was compensating for something that should have been a native capability.

The fact that AWS have addressed this is a good sign. It suggests they listened to the feedback (and I suspect I wasn’t the only one who ran into this). It also validates the frustration I had - if the fix was to make Distribution Settings preserve existing config, then the previous behaviour was the problem, not my expectations.

One less Lambda in the world. Now if AWS could just make their Lifecycle Policies stop nuking AMIs that are still in use, I might be able to retire the other Lambda too. A man can dream.

Additional Resources

• Half Baked Images - original blog post
• Half Baked Lifecycles - follow up blog post
• Updated Auto Scaling Group with EC2 Image Builder Lab
• EC2 Image Builder - Configure AMI distribution with a launch template

This post is part of my AWS technical blog series. Found this helpful? Connect with me on LinkedIn or check back here for more AWS content and discussions.

AKA: Are you sure you want to read this?
Okay - so this isn’t my typical technical approach to blogging. This topic is regulatory heavy - unavoidably so if you’re to understand and navigate it. You have been warned :).

Intro

You might have noticed the world feels slightly less keen on being stable and predictable. Geopolitics, trade, and national interest are clashing more openly. Cloud computing is an area where we see some of the downstream consequences as a result. The ‘Cloud’ has a truly global presence, and so perhaps it’s unsurprising that it isn’t immune from politics. Companies like AWS made it possible for organisations of any size to start small and grow rapidly to a huge global scale - “reach your clients wherever they are” - that wasn’t by magic. It was because the cloud went global.

The cloud, being global by design, blurred many traditional boundaries. In doing so it made possible faster innovation and global reach to anyone with a good idea and the will to act on it. It also quietly blurred some legal and jurisdictional boundaries.

Over the past 10 years, laws like the CLOUD Act and before that, the PATRIOT Act, have forced business leaders and their legal teams to contemplate some uncomfortable, but legitimate, questions. e.g. “Who can access my data, and under what circumstances?”.

Some of these laws create the possibility that their corporate data, user data, or intellectual property held by a US based service provider, could be subject to a lawful access request from US legal authorities. Potentially without the client knowing.

Companies like AWS have offered strong assurances that they’ll challenge overreach and advise any clients when this happens if they’re legally permitted to. And they provide strong mechanisms to protect your data from unauthorised access, e.g. Nitro, which we’ll take about later. See “How does AWS handle Law enforcement requests?” in their CLOUD Act FAQs.

But AWS don’t need me to fight their corner. They have a few more resources than I have to throw at that.

Either way, Sovereign Cloud is here. It’s up to us as IT professionals to understand what that means for us, our employers, clients, and their users.

In this blog I’ll look at what Sovereignty is, what it’s not - and how to avoid common missteps, e.g. that data residency equates to digital sovereignty. It doesn’t.

Sovereignty

The Oxford English dictionary defines Sovereignty as…. no, that would be awful. :)

Digital Sovereignty is about a few things.

• Control - which outsiders can impact you, derail your business, or access your data?
• Jurisdiction - which legal systems have authority over your data, applications, and services?
• Auditability - who’s done what, where, and when - and can I prove that to auditors?
• Security - how do I protect my data and access to my systems?
• Accountability - who am I answerable to? Users, regulators, shareholders, etc
• Residency - where is my data located?
• Operations - who manages, operates, and maintains my systems?

You might be thinking, some of those overlap. Yup. The factors that contribute to Sovereignty do overlap somewhat.

So think about it this way:
If your important data is classified correctly, you know where it is and it’s confined to where you want it to be, you understand how to control access to it, you can audit who’s had access, you know who you’re subject to in terms of regulatory bodies & compliance frameworks, who needs access to your systems, who has access to your systems, then you’re in a good position.

If you answered positively to those then you’re well on the way to understanding what Sovereignty is, and which aspects apply to you.

What Sovereignty isn’t

Data residency (location) is not Digital Sovereignty. It’s likely that some clients will ask for Sovereign solutions when in actual fact, they’re really concerned about data residency and security. Helping those clients understand the difference between where data can be stored and secured (Residency) and who can legally compel access (legal Jurisdiction) is a difference to be understood.

Make my solution fully Sovereign - retrospectively
If a client states that they want to keep their existing solution but “make it Sovereign”… that’s not necessarily impossible, but it’s tricky. Sovereignty is a design time decision. To achieve the best possible sovereign posture for your solution, the design needs to factor in the Sovereignty objectives and address each where possible. (good luck with Supply Chain Sovereignty).

I want to increase my Sovereignty without compromise
For some clients, the appeal of being sovereign and independent from foreign owned companies will be appealing.

EU Sentiment

I won’t spend time talking about the Schrems II ruling, but I’d recommend having a look into that for some context - it gets to the heart of some of the trust issues that are at the centre of the CLOUD Act, conflicting national interests, and the EU position on the subject.
Suffice it to say, the EU have been concerned for some time about their belief that a lack of equivalence exists in data protection laws between the EU and US, and this creates risk for EU based organisations using US based cloud providers.

On the point of trust — it’s an important distinction to make, but the European Commission created the EU Sovereign Cloud framework because the EU considers foreign legal reach to be a risk that could undermine things like GDPR, not because it distrusts cloud technology.

Organisations that are subject to foreign legal obligations, such as the US CLOUD Act, may be viewed through a sovereignty lens as presenting a potential avenue for legal overreach.

Enter the EU Cloud Sovereign Framework

It’s no surprise then that the EU decided to produce a framework that helps organizations assess their current sovereignty posture and to provide some clear guidance and metrics in the form of the EU Cloud Sovereignty Framework.

What does the framework define

It’s definitely worth reading the framework, it’s actually very concise considering what it is, but in the meantime, I’ll summarise here:

SEAL scores

The document explains the concept of SEAL scores - Sovereignty Effectiveness Assurance Level.
There are eight contributing ‘Sovereignty Objectives’, and a related formula that accounts for different weightings, that provide the inputs for calculating the SEAL score of a platform or solution.

Sovereign Objectives (the factors)

• Strategic Sovereignty - This assesses the supplier’s ownership stability, governance influence, & alignment with EU Strategic priorities.
• Legal & Jurisdictional Sovereignty - Evaluates the legal environment, exposure to foreign authority, & enforceability of rights.
• Data & AI Sovereignty - Focuses on how data and AI services are secured, protected, controlled, where they’re located, and where they’re processed from.
• Operation Sovereignty - Assess the ability of EU based organizations to support, patch, maintain, service, and evolve a technology or solution independent of non-EU control.
• Supply Chain Sovereignty - Evaluates the geographic origin, transparency, and resilience of the supply chain, with a specific focus on the extent critical components are or aren’t controlled by the EU.
• Technology Sovereignty - Considers the degree of transparency and independence in the technology stack. Can EU organizations, operate the technology, audit it, and evolve it without lock-in to foreign owned systems.
• Security & Compliance Sovereignty - Assesses the extent to which security operations, compliance obligations, and resilience are controlled within the EU, without reliance on foreign jurisdictions.
• Environmental Sustainability - This assesses the autonomy & resilience of cloud services over the long term in relation to energy usage, dependency, and raw material security. (aka - can you be Sovereign if you’re not energy independent and someone else can switch off the lights?)

The framework goes into more detail about some of the specific examples and criteria they look for and assess in each of those factors. At this stage I just wanted to give you some relevant context to frame the Hyperscaler response, where it works and where it doesn’t.

Hyperscaler response

I’ve stated outright that I personally operate in the AWS arena - other hyperscalers are taking this seriously too - but I’ll talk about how AWS are now facing up to the sovereignty challenge in the EU.

Enter EU AWS Sovereign Cloud.

AWS first announced plans for their EU Sovereign Cloud business in October 2023. In January 2026, following €8 billion investment, AWS formally announced general availability of its EU Sovereign Cloud located in Germany.

“The AWS European Sovereign Cloud is a new, independent cloud for Europe entirely located within the European Union (EU), designed to help customers meet their evolving sovereignty requirements.”

AWS conceived and built the EU Sovereign Cloud to be “Sovereign-by-design”. AWS have worked with various EU organizations to gather the needs of clients who are interested in Sovereign Cloud. In that sense it’s a genuine attempt at a purpose built Sovereign Cloud. You can see the thought that’s gone into that when you look at service availability. For example, at the time I write this there are only two Foundational Models available in eusc-de-east-1 under Amazon Bedrock - ‘Nova Lite’ and ‘Nova Pro’.
Is that just taking time to roll out services and features, or is it regulation making vendors think carefully and seriously about risk, compliance, & governance?

If you’re already familiar with AWS, then EU Sovereign Cloud won’t initially look any different. In many respects it looks and behaves like any other AWS Region. As with AWS Regions, there’s variation in number of Availability Zones (eusc-de-east-1 has two), variation in service/feature availability, and pricing differences.

The sole purpose of AWS’s investment in the EU Sovereign Cloud is to offer, as close as is achievable, a truly sovereign platform for the EU. In their words, from the

Does it manage that? Let’s look first at how AWS’ EU Sovereign cloud measures up to the framework:

Strategic Sovereignty

AWS EU Sovereign Cloud is owned by “AWS European Sovereign Cloud GmbH”, a German registered company - who are themselves 100% owned the US based Amazon. Although, the AWS EU board is entirely based in the EU though and comprised of EU Citizens. This means they’ll be able to get involved in EU initiatives, and they’ll be able to sustain the service in the EU even if the US government did something unthinkable like instructing Amazon to stop offering services in the EU. AWS have made some pretty firm and public commitments here, saying:

“AWS established an independent advisory board for the AWS European Sovereign Cloud, legally obligated to act in the best interest of the AWS European Sovereign Cloud. Reinforcing the sovereign control of the AWS European Sovereign Cloud, the advisory board will consists of five members, all EU citizens residing in the EU, including at least two independent board members who are not affiliated with Amazon. The advisory board will act as a source of expertise and provide accountability on sovereignty-related aspects of the AWS European Sovereign Cloud operations, including strong security and access controls and the ability to operate independently in the event of disruption.”

Therefore, compared to AWS Public Cloud, AWS EU Sovereign Cloud offers a significant improvement in this regard, but it wouldn’t score as highlight as truly owned EU organization with no ties or ownership outside of the EU.

Legal & Jurisdictional Sovereignty
AWS have done a good job of keeping the “AWS European Sovereign Cloud GmbH” entity at arm’s length. Physically and logically isolated from wider AWS. All staff are EU residents, and the board are entirely EU citizens. AWS state in their Sovereign Cloud overview that:

As part of the technical design, access to the AWS European Sovereign Cloud physical infrastructure and logical system is managed by Qualified AWS European Sovereign Cloud Staff and can only be granted to Qualified AWS European Sovereign Cloud Staff located in the EU. AWS European Sovereign Cloud restricted data will not be accessible, including to AWS employees, from outside the EU.

So only AWS staff employed in the EU have any sort of access.
Is that enough to say there isn’t a loophole that means the FBI can’t petition AWS in the US to get at data? It appears that would require compelling EU employees to brake local law, which doesn’t seem likely.
Truthfully - I think we’ll need to see this tested in the courts to know whether this is as robust as we hope or not, but we might be waiting a while…

The CLOUD Act has resulted in zero disclosures of AWS enterprise or government customer content stored outside the U.S. to the U.S. government, since we started reporting the statistic in 2020.

Data & AI
AWS EU Sovereign Cloud offer a lot to assure clients in this respect, whether on AWS EU Sovereign Cloud or AWS Public Cloud. There are strong controls in places to allow clients to secure access and auditing to their data to a high degree. Factor in things like AWS Nitro which provides strong isolation between tenants. In fact, Nitro Isolation prevents anyone other than the client accessing instances - even AWS Staff have no access to customer Instances. Nitro offloads networking, storage, and management functions to dedicated hardware, it significantly reduced the attack surface of the Hypervisor, and all admin access is prohibited.
AWS EU Sovereign Cloud is independently audited and verified to various compliance standards - including attestations for Nitro.

Operational Sovereignty
AWS EU Cloud staff is entirely comprised of EU residents, and AWS have committed that this will be EU citizens located in the EU shortly. No non-EU residents will have access to the EU Sovereign Infrastructure.

Who clients choose to support the solutions they deploy on EU Sovereign Cloud is entirely in their control - but AWS have closed the door on this one.

Supply Chain Sovereignty
Okay. This is a difficult one to check and satisfy. The EU framework refers to a few aspects of supply chain including where key components are manufactured. But it doesn’t clarify what it means by key.
Think of all the devices involved in a typical solution (regardless of where it is) - cpu, PSU, motherboards, network cards, storage devices, adapters, cables, switches, firewalls, gpus, etc - and how many chips and electronics in each of those?

I couldn’t find much clarity in AWS published material on this point. AWS does publish Supply Chain Standards which includes relevant information - but it’s quiet on where components come from.

My personal belief is that this is a complicated topic even for behemoth organizations like AWS - and the reality is the growing demand for full digital sovereignty shines on a light on an interconnected, complex, global supply chain - which means this is currently an extremely difficult lens to be viewed as Sovereign.

Organizations will have to make individual decisions about how far they progress in this direction, or except their partners and suppliers to.

Technology Sovereignty
Transparency, auditability, and avoiding proprietary lock in is the objective here. i.e. Are you using software that can be transparently audited? Can you influence the direction of the code. Could someone else prevent you using that code?

Many AWS services are based on Open Source software, or software that has functional Open Source equivalents, and lock-in is something to be managed anyway when deploying to a cloud - but there are ways to manage that so you’re not entirely dependent on a cloud platform - especially for containerised workloads.

But AWS in the USA are still responsible for the upstream code. So even though the EU is independent in some ways, it’s still seen to be reliant on the US entity for that upstream code.

Again, Organizations will have to decide on the right balance of convenience and compliance in terms of transparency, and whether the improved independence of the AWS EU Sovereign cloud is sufficient.

Security & Compliance Sovereignty
AWS have traditionally done well in this space. The AWS EU cloud is no exception. It has the same security and permissions models as the AWS Public Cloud. e.g. IAM, Organizations, SCPs, etc - but is regionally scoped, implemented, and operated.

Services like Amazon GuardDuty & Security Hub are partially available - some features are on tap today; others planned for the EU Cloud. Check Builder Centre for service/feature availability in eusc-de-east-1.

Amazon Nitro enables no operator access - coupled with no access to anyone outside the EU - this is a strong position for AWS EU Sovereign Cloud.

Environmental Sustainability
AWS do well here also. AWS have a strong message on circular economy, energy efficient data centre, and sustainability. They’re on track to meet targets to be water positive by 2030 and net-zero carbon by 2040.

This is an area that’s weighted lowly in the EU framework though - at only 5%.

AWS EU Sovereign Cloud vs AWS Public Cloud

How do the two platform compare then?
As already pointed out, where a service exists on EU Sovereign Cloud, it’s

Feature / usage comparison

At a high level some of the differences appear quite quickly:

Sovereignty Effectiveness Assurance Level

The formula to calculate SEAL Scores is explained in the EU Sovereign Compliance Framework - refer to that for details. To my mind scoring is subjective to a point You can review the framework, review the platform capabilities, and decide how close you feel there are or aren’t and score accordingly.

I won’t show my working here for various mandated commercial reasons - but I’ll share the outcomes. My personal opinion after consideration resulted in me viewing the platforms to be:

• AWS Public Cloud - SEAL 2
• AWS EU Sovereign Cloud - SEAL 3

Final thoughts

The AWS EU Sovereign Cloud is a strong option for clients with strong Sovereignty requirements, but it isn’t the right choice for everyone. It’s not a one-size-fits-all solution.

Given AWS prices usually fluctuate by region, it’s difficult to accurately compare the cost difference with EU cloud. I deploy in eu-west-1 & eu-west-2 a lot, so I compared with my costs there and found the price was in the region of 15-20% more in eusc-de-east-1. That’s enough to be noticed and given the improved Sovereignty posture over AWS Public cloud, that feels reasonable to me. It also feels just high enough that it’ll help AWS clients decide if they want improved compliance, security, and data control (which they could likely do in their existing environments) or whether they really need a full sovereign platform.

The highest SEAL rating is ‘4’. I think as we see other platforms being assessed - 4 will be awarded rarely. The framework doesn’t easily allow for that in a global economy with global supply chains.

Both AWS Cloud and Sov Cloud lose points in ‘Strategic’, ‘Supply chain’, and ‘Technology’ sovereignty objectives.
However, AWS EU Sov cloud does significantly improve the position on ‘Legal & Jurisdictional’, ‘Operational’, & ‘Data & AI’ sovereignty objectives.

The small caveat is that the scoring of these is somewhat subjective (hence I stressed above my personal opinion) and clients will decide themselves what they need. It’s our job to understand the differences, articulate those, and design & build accordingly.

Additional Resources

• EU Cloud Sovereignty Framework
• Five facts about how the CLOUD Act actually works
• Overview of the AWS EU Sovereign Cloud

This post is part of my AWS technical blog series. Found this helpful? Connect with me on LinkedIn or check back here for more AWS content and discussions.

In my previous post, Half Baked Images I walked through building hardened AMIs using Amazon EC2 Image Builder, automating the pipeline, and wiring it into Launch Templates for Auto Scaling Groups. I touched on some aspects that felt almost, but not quite useful. In this post I’ll talk about my attempts to keep on top of the images produced and why (spoiler!) I ultimately chose Lambda over built-in Image Builder functionality.

Task: Stop AMIs and snapshots from piling up

AWS has an answer for that, of course: Image Builder lifecycle policies.
This should be easy (AKA Foreshadowing).

When asked “What does Lifecycle management in Image Builder do?”, Amazon Q gave this answer:

“The lifecycle manager implements automated rules to manage your image resources throughout their lifecycle, helping ensure image freshness while minimizing costs for underlying infrastructure like snapshot storage for AMIs or ECR repository storage for container images.”

I understand all those words so this is going to be easy peasy.

Lifecycle management made… confusing.

What I didn’t anticipate was how surprisingly awkward it would be to implement what felt like a very simple solution.

Unfortunately, the behaviour of those policies was less intuitive than the name suggested… to me at least.

This post is about the assumptions I made, why they were wrong, what Image Builder lifecycle actually does, and why I ultimately replaced it with a small Lambda function that behaved better for my use case.

Initial approach

I started with a simple goal:

Retain the last 5 AMIs produced by Image Builder.
Delete anything older, including associated snapshots.

Image Builder has a native lifecycle feature. Terraform exposes it cleanly. This felt so obvious that I didn’t question it. The console UI even said things like:

So I configured a lifecycle policy in terraform like this:

resource "aws_imagebuilder_lifecycle_policy" "retain_5_images" {
  name           = "${var.project}-lifecycle-policy"
  description    = "Retain only the 5 most recent AMIs created by Image Builder"
  execution_role = aws_iam_role.imagebuilder_role.arn

  resource_type = "AMI_IMAGE" 

  resource_selection {
    tag_map = {
      Project   = var.project
      ManagedBy = "AWSImageBuilder"
    }
  }

  policy_detail {
    action {
      type = "DELETE"
      include_resources {
        amis       = true
        containers = false
        snapshots  = true
      }
    }

    filter {
      type  = "COUNT" # or "COUNT"
      value = "5"
    }
  }
}

Note: This wasn’t my first attempt, this was the first that ran correctly.
It took me a week to get it to run. See Assumption #1.

Even now, recovering from the savage AMI cull of ‘25, I still read that code and think the policy should:

• Take the DELETE action for resources type “AMI_IMAGE”…
• also including resource types AMIs and snapshots, for those AMI_IMAGEs that matched…
• tags Project & ManagedBy, whilst retaining…
• Filter: COUNT = 5

Therefore I expected the outcome to be:

Find Images were Project = var.project and ManagedBy = "AWSImageBuilder"
If there are ≤5 images that match that criteria → delete nothing
If there are 6 → delete the oldest 1
If there are 18 → delete the oldest 13

etc. Simple. Predictable. Safe.

That is not what happened.
But what went wrong?

Assumption is the mother of all… fowl ups.

Assumption #1

My first assumption was that I would have some control over when the lifecycle management would run. Similar to controlling the pipeline schedule, I’d be able to control a lifecycle management schedule.

e.g. I’d be able to define a cron schedule or trigger it to run immediately after a new image became AVAILABLE. Nope.

Image Builder Lifecycle policies run on an internal AWS schedule, completely decoupled from the triggers or control I expected. There is also no “Run now” button to force an evaluation.

This had two consequences that significantly impacted my use case:

1. Testing is non-linear.
   Unsurprisingly my lifecycle didn’t work on the first try. So, when I attempted to fix it, I had to wait 24 hours to see if that had worked.
   Testing, that could have taken a couple of hours, took days to work through as a result of this approach.

2. Troubleshooting was complex and misleading
   I was working on a few aspects of the code simultaneously, so by the time my lifecycle ran each day I had usually made several changes.

   • Tags had been added or changed
   • IAM permissions were tightened
   • Images components were changing, meaning recipes had been updated.

The combination of those two realities made it very difficult to figure out cause and effect: Was lifecycle management failing because I’d borked the config? Was it related to my tagging changes? or the new recipe?
sigh.

Assumption #2

My second assumption was that the lifecycle policy in Image Builder relates to the images built by Image Builder… that is to say - the AMIs.

Sensible assumption? I thought so… and if you did too… join me in my pit of despair because, as we’ll get to in a moment, this was not the case.

Assumption #3

My third, and what proved to be my most costly assumption, was that I’d provided enough details to safely identify the images to be deleted and that only those Images would be deleted. That this turned out to be incorrect was the real sore point - this one wasn’t easy to predict or see coming until it went wrong.

So what actually happened?

When my lifecycle policy ran, it removed all AMIs. Everything.
Including AMIs still in use by my Auto Scaling Group’s Launch Template.
Nothing useful remained. Zero AMIs, zero snapshots.

Thankfully this occurred in a lab environment so wasn’t too impactful… but it did give me chills. I looked over the code, at the resources, and the lifecycle policy in the console, etc. It all looked correct. It seemed to make sense - but here I was with no useable images left.
And at the moment of discovering this issue, even from that point, it took a good few hours to understand why it had gone so badly wrong.

To say I was a bit surprised at the outcome is putting it mildly.
This could not be allowed to happen in an environment that matters to me.

Where did the assumptions fall down?

1. Not having control over the scheduling of the lifecycle policy was simultaneously a relatively minor issue and almost enough to be a deal breaker on its own. Who’s happy waiting 24 hours to test configuration changes in a lab? Fail fast isn’t an option, if you have to wait 24 hours to test each change.

2. My assumption that my lifecycle policy was targeting my AMI’s directly was incorrect. This one really mattered.
   EC2 Image Builder Lifecycle Policies target Image builder resources, e.g. things with arns like arn:aws:imagebuilder:eu-west-2:123456789012:image/custom-linux-build/1.0.6/3.
   This is a subtle but important distinction to understand when you’re thinking about how Image Builder Lifecycle policies identify targets. You can, as I did in the code above, state that it should include amis = true & snapshots = true. But, again, the AMIs and snapshots are secondary in this.

3. Assuming I’d provided the correct selection criteria was compounded by the previous assumption about what the lifecycle policies target.
   I mentioned that after my lifecycle policy ran I had zero AMI’s and zero snapshots.
   But I did still have 5 “images”. I still had 5 Image Builder Image’s retained. Although the AMI’s that they pointed to were gone.

Yup, I swore inwardly at this point.

Bringing it home

I asked Amazon Q why it would do this (to me), and in its reply it had this little unhelpful truth bomb:

“Even if the Image Builder Image resources were retained, if your policy had:"includeResources": { "amis": true, "snapshots": true } This would delete the underlying AMIs and snapshots while potentially keeping the Image Builder metadata.”

I swore outwardly at this point. Loudly.

This ia an awful failure condition by any stretch. I accept that this was my configuration, and I am responsible for this, it still feels like this was a booby trap waiting to go off rather than something you could reasonably foresee & avoid.

So what did I do about it

After a fair amount of frustration, confusion, and lost AMIs I decided to abandon the Image Builder lifecycle policy approach and turned to AWS Lambda - what can’t Lambda fix?

I created a small function that I deployed using Terraform, as follows:

import os
import json
import boto3
import logging
from datetime import datetime, timezone

logger = logging.getLogger()
logger.setLevel(logging.INFO)

ec2 = boto3.client("ec2")

RETAIN_COUNT = int(os.getenv("RETAIN_COUNT", "5"))
PROJECT_TAG_VALUE = os.getenv("PROJECT_TAG_VALUE", "labpoc")
MANAGED_BY_VALUE = os.getenv("MANAGED_BY_VALUE", "AWSImageBuilder")
LAUNCH_TEMPLATE_ID = os.getenv("LAUNCH_TEMPLATE_ID")  # required for protection
DRY_RUN = os.getenv("DRY_RUN", "true").lower() == "true"


def _parse_dt(s: str) -> datetime:
    return datetime.fromisoformat(s.replace("Z", "+00:00")).astimezone(timezone.utc)


def _list_matching_amis():
    filters = [
        {"Name": "tag:Project", "Values": [PROJECT_TAG_VALUE]},
        {"Name": "tag:ManagedBy", "Values": [MANAGED_BY_VALUE]},
        {"Name": "state", "Values": ["available"]},
    ]
    resp = ec2.describe_images(Owners=["self"], Filters=filters)
    images = resp.get("Images", [])
    images.sort(key=lambda i: _parse_dt(i["CreationDate"]), reverse=True)  # newest first
    return images


def _snapshots_for_ami(image: dict) -> list[str]:
    snaps = []
    for bdm in image.get("BlockDeviceMappings", []):
        ebs = bdm.get("Ebs")
        if ebs and ebs.get("SnapshotId"):
            snaps.append(ebs["SnapshotId"])
    return snaps


def _summarise_images(images: list[dict], max_items: int = 50) -> list[dict]:
    out = []
    for img in images[:max_items]:
        out.append({
            "ImageId": img.get("ImageId"),
            "CreationDate": img.get("CreationDate"),
            "Name": img.get("Name"),
        })
    if len(images) > max_items:
        out.append({"note": f"truncated: showing {max_items} of {len(images)}"})
    return out


def _amis_referenced_by_latest_lt_versions(launch_template_id: str, protect_versions: int) -> set[str]:
    """
    Protect AMIs referenced by the *latest N* launch template versions.
    """
    protected = set()

    # Fetch versions (we'll sort and take the latest N)
    versions = []
    paginator = ec2.get_paginator("describe_launch_template_versions")
    for page in paginator.paginate(LaunchTemplateId=launch_template_id):
        versions.extend(page.get("LaunchTemplateVersions", []))

    if not versions:
        return protected

    # Sort by VersionNumber descending and take latest N
    versions.sort(key=lambda v: v.get("VersionNumber", 0), reverse=True)
    latest = versions[:protect_versions]

    for v in latest:
        data = v.get("LaunchTemplateData", {})
        image_id = data.get("ImageId")
        if image_id:
            protected.add(image_id)

    return protected


def lambda_handler(event, context):
    logger.info(
        "Starting AMI retention. retain=%s project=%s managedby=%s dry_run=%s lt_id=%s",
        RETAIN_COUNT, PROJECT_TAG_VALUE, MANAGED_BY_VALUE, DRY_RUN, LAUNCH_TEMPLATE_ID
    )

    if RETAIN_COUNT < 1:
        raise ValueError("RETAIN_COUNT must be >= 1")

    images = _list_matching_amis()
    total = len(images)
    logger.info("Found %s matching AMIs.", total)
    logger.info("Matched AMIs (newest->oldest): %s", json.dumps(_summarise_images(images)))


    if total <= RETAIN_COUNT:
        logger.info("<= %s matching AMIs; deleting none.", RETAIN_COUNT)
        return {"statusCode": 200, "body": json.dumps({"matching": total, "deleted": 0})}

    protected = set()
    if LAUNCH_TEMPLATE_ID:
        protected = _amis_referenced_by_latest_lt_versions(LAUNCH_TEMPLATE_ID, RETAIN_COUNT)
        logger.info("Protected AMIs referenced by latest %s Launch Template versions: %s",
                RETAIN_COUNT, list(sorted(protected)))
    else:
        logger.warning("LAUNCH_TEMPLATE_ID not set; NOT protecting in-use AMIs (not recommended).")

    # Keep newest RETAIN_COUNT (always)
    keep_newest = {img["ImageId"] for img in images[:RETAIN_COUNT]}

    # Eligible = older than newest RETAIN_COUNT AND not protected by LT
    older = images[RETAIN_COUNT:]
    candidates = []
    for img in older:
        ami_id = img["ImageId"]
        if ami_id in protected:
            continue
        candidates.append(img)

    logger.info("Candidates for deletion (older than newest %s, not referenced by LT): %s",
                RETAIN_COUNT, len(candidates))

    deleted = []
    for img in candidates:
        ami_id = img["ImageId"]
        snaps = _snapshots_for_ami(img)

        logger.info("Deleting AMI %s (snapshots=%s)", ami_id, snaps)

        if not DRY_RUN:
            ec2.deregister_image(ImageId=ami_id)
            for snap_id in snaps:
                ec2.delete_snapshot(SnapshotId=snap_id)

        deleted.append({"ami": ami_id, "snapshots": snaps})

    logger.info("Done. Deleted %s AMIs.", len(deleted))
    return {"statusCode": 200, "body": json.dumps({"matching": total, "deleted": len(deleted), "items": deleted})}

Note: the environment vars, you can set these in terraform when you specify your aws_lambda_function

  environment {
    variables = {
      RETAIN_COUNT       = tostring(var.ami_retain_count)
      PROJECT_TAG_VALUE  = var.project
      MANAGED_BY_VALUE   = "AWSImageBuilder"
      DRY_RUN            = "true" # flip to false when confident it's working
      LAUNCH_TEMPLATE_ID = aws_launch_template.wafr_lt.id
    }
  }

This Lambda function is, in many ways, much simpler than what I thought I’d been doing with the Image Builder Lifecycle Manager… This function:

• Lists AMIs by tag (Project, ManagedBy)
• Sorts them by creation date
• Keeps the newest N (defined by Terraform variable ami_retain_count)
• Deregisters anything older
• Deletes the snapshots referenced by those AMIs
• Never deletes AMIs currently referenced by the latest N Launch Template (also defined by ami_retain_count.)

This runs on a schedule I control. And understand!
It’s observable, repeatable, and it can be run in dry-run mode while testing.

Most importantly, the behaviour can be explained in one sentence:

“We keep the 5 newest AMIs for this project, and we never delete one that’s in use.”

That is the rule I thought I was configuring when I attempted to enable lifecycle retention — but now it’s actually true!

Why a custom solution won (& why I’m okay with that)

After working through this in detail, I came to a conclusion that surprised me:
Image Builder lifecycle policies are not a good fit for intuitive AMI retention.

They are:

• metadata-centric
• recipe-scoped
• on their own schedule
• capable of deleting artifacts without leaving usable AMIs behind (talk about sharp edges!)

This doesn’t mean lifecycle policies are broken — but it does make them dangerous if your mental model is “Keep the last N usable AMIs.”

In my experience this model doesn’t map cleanly to how Image Builder lifecycle works.

By contrast my Lambda function is:

• explicit - I could set my own boundaries that did what I expected them to do.
• controlled - it runs when i want.
• able to add clear and simple guardrails - e.g. don’t delete any AMIs still in use, regardless of other filters.
• Auditable - see what’s going on easily in the execution logs.
• Test friendly. Flip “dry-run” to ’true’ to test what would be deleted before you take the training wheels off.

The result was a solution that worked as I expected, trimmed my AMIs and Snapshots to the number I wanted, and stopped my bill from growing forever with the ghost of a million unused snapshots, allowed me to safely test changes when I wanted. And it only cost only a tiny amount in Lambda usage. Worth it.

Final thoughts

EC2 Image Builder is excellent at building & customising images.
EventBridge and Lambda are excellent at reacting to them.

But AMI retention is an operational concern, not a build concern — and once I treated it that way, the solution became simpler, safer, and easier to understand.

If you’re currently using Image Builder lifecycle today and it works for you, that’s great.

If, however, your mental model is “keep the last N usable AMIs”, it’s worth pausing and double-checking that the system is actually doing what you think it is.

Sometimes the most robust solution is the one you can explain easily — and without waiting 24 hours to see what it decided to do.

Additional Resources

• Complete EC2 Image Builder with Lifecycle Management Example
• Amazon EC2 Image Builder
• AWS Lambda
• Half Baked Images - previous blog post

This post is part of my AWS technical blog series. Found this helpful? Connect with me on LinkedIn or check back here for more AWS content and discussions.

Using Terraform to deploy and manage an Auto Scaling Group that utilises custom AMIs built by EC2 Image Builder and dealing with the limitations of EC2 Image Builder’s native capabilities for managing Launch Templates.

What were we asked?

I’ve recently worked on a project that required an Auto Scaling Group of EC2 instances that utilised custom-built AMIs produced by EC2 Image Builder. The requirement was to have an EC2 Image Builder pipeline produce weekly images based on Amazon Linux 2023, with various custom components applied.
It’s quite straightforward to do this in Terraform, so happy days!

If you’ve used Terraform to manage Auto Scaling Groups in AWS, you’ll know that this is relatively straightforward too. There are lots of examples and use cases out there to draw from.
So it should be super simple to marry those two concepts together into one simple, happy, solution you’d think.
Yeah right!

If you want to skip the dramatic retelling of my pain and just get the answer, skip to the solution

What’s the problem? Go!

The first two parts are straightforward - the ASG definition and EC2 Image Builder pipeline setup in Terraform. As is the rest of the Terraform really. Working with my buddy we quickly had IaC that would deploy the VPC that would host our Auto Scaling Group, the Launch Template that would complement that ASG, and the EC2 Image Builder components, recipe, pipeline, and distribution, etc. As well as all the trimmings, IAM policies, security groups, KMS keys, etc, etc.
During the initial deploy attempt we encountered our first red flag. We had valid Terraform code, but it threw up this error:

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: Your query returned no results. Please change your search criteria and try again.
│
│   with data.aws_ami.latest_custom,
│   on data.tf line 486, in data "aws_ami" "latest_custom":
│  486: data "aws_ami" "latest_custom" {
│

I’d used a data source to capture the ID of the latest image that EC2 Image Builder would produce, but of course that hadn’t run yet.
I thought I’d been smart, I had foreseen the bootstrapping issue, and thought I’d get around it by temporarily pointing the image_id at an AWS managed SSM parameter that stores the Amazon Linux 2023 AMI ID.

resource "aws_launch_template" "my-cool-project-resource" {
  name_prefix            = "my-cool-project-name-lt-"
  #image_id               = data.aws_ami.latest_custom.id
  image_id               = data.aws_ssm_parameter.al2023.id

This didn’t prevent the error above. To my shame (not really, I’m actually quite pragmatic) I commented out the data source for my latest custom image and was able to successfully deploy my infrastructure. I immediately reversed the commented out sections. data.aws_ami.latest_custom was reinstated, and the Launch Template was reverted back to image_id = data.aws_ami.latest_custom.id and all worked well. Sorted.

+5 influence points if you see where this is going

It wasn’t sorted. Not completely.
I could now successfully deploy the infrastructure reliably, I’d hacked my way past the bootstrapping issue, but comforted by my solemn vow to myself that I’d go back and fix that. Scout’s honour.

The situation was better but not quite what we needed. We had an EC2 Image Builder pipeline that ran to a schedule and worked as expected. Our Launch Template looked good but it wasn’t using the most recent image. It was using the most recent -1. Consider this sequence of events:

1. Terraform deploys IaC, creating ASG, Launch Template, and EC2 Image builder pipeline.
2. EC2 Image Builder was triggered manually to confirm it was working.
3. EC2 Image Builder produces a new version of the AMI.
4. Launch Template is still running the TF deployed AMI version and doesn’t know about the one EC2 Image Builder produced.

This surfaced what might have been obvious to you dear reader, that the Launch Template must be built before we’ve built any images.
Also that our Pipeline would run independently of our Terraform code - and so our Launch Template would never know about the latest image until we next ran Terraform to update the Launch Template. That’s not ideal as the intention was to set up a CI/CD pipeline to run the Terraform code upon merges to the main branch.

I was opposed to the idea of scheduling the Terraform code to run after the pipeline schedule. That wouldn’t be pragmatic, that would be messy.

Why don’t you just update the LT natively from EC2 Image Builder?

Reasons!
Mostly that I didn’t know that was a thing at this point. I started looking at how other people have solved this, because surely using custom-built AMIs in Auto Scaling Groups is super common? It kinda is, but so is this challenge.

In actual fact, the distribution settings within EC2 Image Builder allow for updating a Launch Template with the latest AMI… directly. It’s explained nicely here.

So that resulted in me adding this launch_template_configuration block to my distribution config:

resource "aws_imagebuilder_distribution_configuration" "dist" {
  name = "${var.project}-dist"

  distribution {
    region = var.region

    ami_distribution_configuration {
      name        = "${var.project}-{{imagebuilder:buildDate}}"
      description = "A descriptive description describing things"

      ami_tags = {
        OS       = "AmazonLinux2023"
        Hardened = "true"
        Name     = "${var.project}-{{imagebuilder:buildDate}}"
      }
    }
    launch_template_configuration {
      launch_template_id = aws_launch_template.my-cool-project-resource.id
      account_id         = local.account_id
    }
  }
}

My distribution would now update the Launch Templates with details of the new AMI ID.
And it did.

Half Baked Images!

This was a step forward, if you’d first pivoted 180 degrees.
While it did solve the problem of the Launch Template not having the latest AMI - it absolutely did have the latest AMI now - it came at a price.

So, for some reason the documentation gods appear not to have fully explained (please tell me on Linkedin if I’m wrong) EC2 Image Builder Distribution Configuration can only configure some elements of the Launch Template, not all!

And it doesn’t update the Launch Template in the sense that it retains previous config and simply updates the AMI ID. It updates in the sense that it creates a new version with the details you’ve told it to. In my case the Account ID and the Launch Template to update with the AMI ID. That makes sense when you step back and think about it, but it also felt unintuitive.

Why is this bad?

Because the updated version of the Launch Template no longer contains several key details about the rest of the required configuration, Instance profile, Security groups, key pair, etc.

I’ll save you the suspense - I checked with Amazon Q to point me to the explanation, and it had this to say:

“Unfortunately, EC2 Image Builder cannot preserve existing Launch Template settings when updating the AMI. When EC2 Image Builder creates a new Launch Template version through its distribution settings, it only copies the AMI ID to the new version - it doesn’t inherit or preserve other configuration settings like instance profiles, security groups, or other parameters from your existing Launch Template…
…the limitations are not explicitly stated in the official AWS docs. The documentation focuses on how to configure EC2 Image Builder to update Launch Templates, but it doesn’t clearly specify what happens to existing Launch Template settings when it creates a new version.”

The result of this was that my ASG was now spinning up instances with no instance profile, which wasn’t the only misconfiguration introduced, but this alone was a show stopper.

So what was the solution?

The solution I settled on was a two-parter, but let’s start by recapping what we want to happen:

1. Using Terraform: deploy & manage infrastructure that will create an ASG, Launch Templates, and an EC2 Image Builder pipeline that will update images frequently.
2. Shared custody of the latest AMI ID & Launch Template configuration between EC2 Image Builder and Terraform. By that I mean:
   a. Terraform creates the infrastructure that holds the AMI details and doesn’t complain when…
   b. The Launch Template is always referring to the latest AMI ID.
3. The Launch Template is updated as soon as an updated image is produced, without waiting for Terraform.
4. Terraform won’t freak out when it realises the Launch Template is using a newer AMI ID than it was expecting.

So practically how do we do this?

Step 1 - Get the IaC correct

First of all, Terraform needs to create an SSM Parameter as shown in this example:

data "aws_ssm_parameter" "al2023" {
  name = "/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.1-arm64"
}

resource "aws_ssm_parameter" "custom_built_image_id" {
  name        = "/imagebuilder/${var.project}/custom_id"
  description = "SSM Parameter for storing the AMI ID of the image built from EC2 Image Builder"
  type        = "String"
  data_type   = "aws:ec2:image"
  value       = data.aws_ssm_parameter.al2023.value

  lifecycle {
    ignore_changes = [
      value
    ]
  }
}

So what did we accomplish with the SSM parameter definition in Terraform?
This is our source of truth for our AMI image.

• The Terraform definition for the Launch Template should retrieve the value stored here. Hence why it needs to be seeded with a real AMI ID to start with.
• Something (no spoilers yet) needs to update the Launch Template with the latest custom built AMI ID. Hence why we have the lifecycle policy ignoring changes to the value.
• Important 1 - The managed service role for EC2 Image Builder only has permissions to publish to items in Parameter Store that begin with the prefix /imagebuilder/ - see AWS docs on that point. i.e. You must use a name similar to the one in the example above.
• Important 2 - data_type = "aws:ec2:image" must be set otherwise the Distribution Configuration in EC2 Image Builder will fail to update the parameter. (Ask me how I know this!)
• Important 3 - Don’t forget to ignore changes to the value as shown above!

Now that we have somewhere to store the AMI ID, we need to make sure its referred to in our code, specifically in the Launch Template and the EC2 Image Builder distribution configs:

resource "aws_launch_template" "my_lt" {
  name_prefix            = "my-lt-"
  image_id               = aws_ssm_parameter.custom_built_image_id.value
  instance_type          = var.instance_type
  vpc_security_group_ids = [aws_security_group.private_sg.id]

  iam_instance_profile {
    name = aws_iam_instance_profile.custom_permissions.name
  }

  block_device_mappings {
    device_name = "/dev/xvda"
    ebs {
      volume_size = 20
      volume_type = "gp3"
      encrypted   = true
    }
  }

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name    = "NamingIsHard"
      Project = var.project
    }
  }
}

resource "aws_imagebuilder_distribution_configuration" "dist" {
  name = "${var.project}-dist"

  distribution {
    region = var.region

    ami_distribution_configuration {
      name        = "${var.project}-{{imagebuilder:buildDate}}"
      description = "Custom built AL2023 image"

      ami_tags = {
        OS       = "AmazonLinux2023"
        Hardened = "true"
        Name     = "${var.project}-{{imagebuilder:buildDate}}"
      }
    }

    ssm_parameter_configuration {
      parameter_name = aws_ssm_parameter.custom_built_image_id.name
      ami_account_id = local.account_id
    }
  }
}

So now the Launch Template is happy, because even at boot time we’ve given it a valid AMI ID.
EC2 Image Builder is no longer sabotaging our Launch Template and is instead updating the SSM Parameter Store.

Step 2 - Join the dots

So, thus far we’ve completed our deployment, but we still need something to handle the Launch Template updates. Cue EventBridge & Lambda.
Whereas the native option in EC2 Image Builder would allow us to create a new version of the Launch Template with the new AMI ID, it didn’t allow us to specify the other important requirements like security group, profile etc.
A custom Lambda function allows us to do exactly that.

e.g. We can take this function, deploy it using Terraform…

import boto3
import os

ssm = boto3.client("ssm")
ec2 = boto3.client("ec2")

PARAM_NAME = os.environ["SSM_PARAM_NAME"]
LT_ID = os.environ["LAUNCH_TEMPLATE_ID"]
INSTANCE_TYPE = os.environ["INSTANCE_TYPE"]
SECURITY_GROUP_ID = os.environ["SECURITY_GROUP_ID"]
IAM_INSTANCE_PROFILE = os.environ["IAM_INSTANCE_PROFILE"]

def handler(event, context):
    # Get latest AMI from SSM
    response = ssm.get_parameter(Name=PARAM_NAME)
    ami_id = response["Parameter"]["Value"]

    # Create new Launch Template version
    ec2.create_launch_template_version(
        LaunchTemplateId=LT_ID,
        SourceVersion="$Default",
        LaunchTemplateData={
            "ImageId": ami_id,
            "InstanceType": INSTANCE_TYPE,
            "SecurityGroupIds": [SECURITY_GROUP_ID],
            "IamInstanceProfile": {"Name": IAM_INSTANCE_PROFILE}
        }
    )

    # Set the new version as default
    latest = ec2.describe_launch_template_versions(
        LaunchTemplateId=LT_ID,
        Versions=["$Latest"]
    )["LaunchTemplateVersions"][0]["VersionNumber"]

    ec2.modify_launch_template(
        LaunchTemplateId=LT_ID,
        DefaultVersion=str(latest)
    )

    print(f"Updated LT {LT_ID} to use {ami_id}")
    return {"statusCode": 200, "ami_id": ami_id}

What will this function do?

It takes five environment variables that are used to ensure all the required data for creating a useful new version of the Launch Template is included, but simply put it’s doing three things:

• It obtains the latest AMI ID - that EC2 Image Builder’s Distribution config applied to the SSM Parameter.
• Create a new version of the Launch Template, passing in the required details, image ID, instance type, security group(s), & Instance profile for permissions.
• It updates the Launch Template to set the latest version it just created as the default version.

How do we trigger that function?

Now that we have the function to handle the updates, we just need to trigger it appropriately. We do that using EventBridge, and we can also deploy this from Terraform using something like this:

# This is used to trigger Lambda to update the ASG Launch Template when there's a new AMI available.

resource "aws_cloudwatch_event_rule" "imagebuilder_completed" {
  name          = "${var.project}-imagebuilder-completed"
  description   = "Trigger on successful image builds"
  event_pattern = <<EOF
{
  "source": ["aws.imagebuilder"],
  "detail-type": ["EC2 Image Builder Image State Change"],
  "detail": {
    "state": {
      "status": ["AVAILABLE"]
    }
  }
}
EOF
}

resource "aws_cloudwatch_event_target" "trigger_lambda" {
  rule      = aws_cloudwatch_event_rule.imagebuilder_completed.name
  target_id = "LaunchTemplateUpdater"
  arn       = aws_lambda_function.update_launch_template.arn
}

This creates an EventBridge rule that is triggered every time your EC2 Image Builder pipeline successfully produces an AMI with a status of ‘AVAILABLE’.

That rule in turn triggers the Lambda function shown above. So now we’ll have this sequence:

1. EC2 Image Builder runs and produces a new Image
2. It also updates the SSM Parameter store with the latest AMI ID
3. When the new AMI is updated to be ‘AVAILABLE’, our EventBridge Rule is triggered.
4. The EventBridge rule in turn runs the Lambda function to retrieve this new ID and create a new Launch Template version.

The result is that when the ASG next scales up, it’ll use the latest AMI ID.
It also means that on the next Terraform run it’ll pull the latest AMI ID from SSM and recognise that no change is required.

Conclusion

If you want to use EC2 Image Builder to manage AMIs for an ASG, all but the most simple use cases will require some extra plumbing when it comes to handling the Launch Template configuration.
In those more advanced scenarios a method as highlighted here will be effective in handling the synchronisation between Terraform’s view of the world and ensuring the Launch Template is always up to date (with a useful Instance Profile.)

Additional Resources

• Complete Auto Scaling Group with EC2 Image Builder Example
• EC2 Image Builder & SSM

This post is part of my AWS technical blog series. Found this helpful? Connect with me on LinkedIn or check back here for more AWS content and discussions.

Inspired by the talented Chris Bingham, an AWS Ambassador here at Fujitsu, I recently set myself a new target: to apply for the Ambassador program myself. Chris spoke positively about the program, and it struck me as the kind of nudge I needed to step outside my comfort zone. It also felt like an opportunity to help bring positive attention to the good AWS work being done at Fujitsu.

However, there’s one glaring weakness with any application I might submit: I’ve never really shared knowledge publicly. So, I decided to start there. Build a habit of sharing knowledge regularly and then decide later whether I want to keep it up long-term and actually apply.

The next question to answer was, how would I share articles and opinions?
Enter Kiro.

What is Kiro?

Kiro is a new tool from AWS that promotes Spec Driven Development. It’s a forked version of Visual Studio Code, so it’s familiar and supports the same extensions.

The Spec driven Development approach that it encourages guides the user to plan out a project, quickly but thoroughly, before generating code. That’s a little different from some of the other AI-assisted coding tools out there that focus purely on code generation.

I managed to get onto the recent preview of Kiro — and so I wanted to use it in a way that would let me experience it fully.

I decided to use Kiro to plan, design, build, and deploy a blogging site to host my articles - this website. Well three out of four isn’t bad. ‘Deploy’ was achieved outside of Kiro, but I’ll explain that later.

What is Spec Driven development?

Spec Driven development (SDD) is a methodology that encourages the developer to use a coding assistant in the ‘right’ way. You start with a ‘specifcation’. Define what you want to achieve, inputs, outputs, etc.

SDD doesn’t immediately launch into generating code. It uses your prompt to build the spec. There are three main phases to the process that we’ll look at:

1. Create requirements - generate a well written project plan
2. Create the design - generate a design capable of meeting the plan
3. Create the tasks - generate the tasks capable of delivering your project

Start with a prompt:

The entirety of my prompt to Kiro was:

Create the requirements

As you can see, Kiro was happy to oblige and generated requirements.md, a list of high level requirements for my blog, written in the form of user stories with acceptance criteria.
For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

### Requirement 1

**User Story:** As an aspiring AWS Ambassador, I want to host my own blogging platform on AWS, so that I can publish technical articles and demonstrate my AWS expertise.

#### Acceptance Criteria

1. WHEN I access the blogging platform THEN the system SHALL be hosted entirely on AWS infrastructure
2. WHEN I create a blog post THEN the system SHALL support rich text editing with code syntax highlighting
3. WHEN I publish an article THEN the system SHALL make it publicly accessible with SEO optimization
4. WHEN visitors access my blog THEN the system SHALL provide fast loading times and high availability

In total, 5 requirements were created from my prompt. I changed only one. A line in one of the acceptance criteria from “generate CloudFormation or Terraform IAC”, to “generate Terraform IAC”.

Now, have a quick look at my original prompt again and consider this:
I received five, well written, comprehensive requirements from that prompt. There’s real value in going from a rough idea to a clear, and easily edited, list of requirements – something that gives ‘shape’ to the idea. It really accelerates the process of going from idea -> to POC -> to market.

Create the design

Kiro waited patiently for me to review the requirements and make any amendments I wanted. When I was happy with the requirements, Kiro then produced design.md. This is a proposed solution, including a summary of that solution, high level archtitecture, list of components, and other relevant details to my plan. Here’s a snippet of my design:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

## Overview

The AWS Blogging Platform is designed as a cost-effective, Hugo-based static site solution that demonstrates AWS best practices while providing excellent performance and SEO capabilities. The platform leverages Hugo static site generation with AWS hosting services to create an extremely affordable, fast, and secure blogging solution suitable for technical content creation and AWS expertise demonstration for Ambassador applications.

## Architecture

### Primary Architecture: Hugo Static Site Generator

**Selected Architecture**: Hugo-based static site with AWS hosting
- **Frontend**: Hugo-generated static site on S3 + CloudFront
- **Content**: Markdown files in Git repository
- **CMS**: Git-based workflow with GitHub repository
- **CI/CD**: GitHub Actions for automated builds and deployment
- **Cost**: ~$1-5/month for moderate traffic
- **Pros**: Extremely fast, cheapest option, Git-based content management, excellent SEO, perfect for technical blogging
- **Cons**: No dynamic features, requires Git knowledge, limited admin interface

In actual fact Kiro created three high level proposals:

1. Servers Static site using React/Node.js hosted on S3 + CloudFront, and using DynamoDB.
2. Container based solution - React app on ECS Fargate + RDS PostgreSQL
3. A Hybrid approach which didn’t fully make sense using API Gateway, Lambda, ECS, and RDS.

After some cherry picking on my part, I chose a design close to option 1 but dropped React/Node.js and DyanmoDB, and instead used Hugo to convert markdown to static HTML hosted on S3 + CloudFront.

During the review of design.md I spotted the only misunderstanding I encountered with Kiro. My prompt included: “I’d like to review architectural diagrams and assess their suitability” .

Kiro interpreted this as a request for my blog site to also have functionality and capability to receive architectural diagrams. I realised that when I spotted this in the original design.md:

### Architecture Review System
┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│  Architecture   │────│   Diagram        │────│   Cost          │
│  Generator      │    │   Renderer       │    │   Calculator    │
└─────────────────┘    └──────────────────┘    └─────────────────┘
         │                       │                       │
         │             ┌──────────────────┐    ┌─────────────────┐
         └─────────────│   Template       │────│   Validation    │
                       │   Library        │    │   Engine        │
                       └──────────────────┘    └─────────────────┘

That’s a lesson for me as a user of the tool about being clear and unambiguous. It’s also a reminder that you do actually need to review the requirements, designs, and tasks that it produces.

Pretty cool though! – I’ve added the idea to my backlog.

Create the tasks

As before, Kiro will wait for you to review, amend, and finalise the design before proceeding to the next step. That could be by either manually updating design.md yourself, or interacting with Kiro to describe the changes you want, and Kiro will update the design.

Once you’ve settled on the requirements, then the design, Kiro will generate tasks.md. This is a list of tasks that are all directly a result of, and therefore, linked back to, the requirements, for example:

These tasks are ‘clickable’. Where you now see Task completed, it orginially read start task. Clicking that was all that was required to complete the task(s). I had the choice of clicking 2. create aws infrastructure with Terraform to complete all of the tasks in step 2, or I could execute each one individually and review as I went.
I was moving quickly but also had short pauses to review what had been achieved in bite size chunks.

It felt fast and considered. What do I mean by that?

Having reviewed tasks.md and about to generate the code - I was less than 2 hours into the process. i.e. 2 hours prior I hadn’t submitted my request to Kiro.

Now I was generating complex code that was tuned to specific requirements and validated tasks – that’s undeniably fast. However, in that time I’d still had an opportunity to review the requirements and the subsequent designs, and to make changes. Therefore, the code I was about to create had been carefully considered.

Does SDD differ from Vibe coding?

Yes.

Vibe coding is fun. When done right, it’s a great way to experiment or knock out a quick fix. But it doesn’t ask you to stop and think about what your requirements actually are.
If you get distracted, you can easily lose your place. The “plan” (if you had one) lives only in your head, which makes it hard to share with others, human or AI. And if you don’t have a plan, how exactly do you measure progress, or build in testing?

Spec Driven Development (SDD) flips that around.
The small upfront investment of writing down your requirements pays off quickly. You’re forced to clarify your goals and capture them in a way that’s easy to edit later. Kiro can then update the design and tasks automatically. Your spec becomes a single source of truth that’s easy to share with colleagues, clients, or AI helpers. Testing stops being an afterthought, and becomes super simple to embed into the process from the start because your objectives are clear.

Why does that matter?

Bluntly - it offers significant time savings. Using Kiro and SDD I estimate that I saved at least 3 weeks on my project.

Consider this scenario. An account manager receives an opportunity to create a small static marketing website for a client wishing to reach customers with updates, announcements, and new offerings. The subsequent timeline might look like this:

• The account manager schedules a call with the project team (A project manager, solutions architect, and a couple of cloud engineers). Availability of the team means it’s two days before the call happens. (+2 days)
• After the call, the solution architect is tasked with documenting the requirements and circulating for review, correction, and agreement. (+1 day)
• The solution architect takes a day to generate a high level design (+1 day)
• Feedback from the team results in iteration over the next couple of days (+2 days)
• Once finalised, one of the cloud engineers works with the PM to create user stories in Jira. (+1 day)
• The cloud engineers begin the process of writing code in terrform to define the infrastructure hosting the environment. (+5 to 8 days)
• Deploying the infrastructure reveals some bugs and improvement opportunities (+2 days)
• The cloud engineers switch to generate the CICD pipelines in Github actions to test, build, and deploy the site content. (+5 days)
• Oops - that thing we forgot to account for (+ 1 day)

Does that sound familiar?
Thats roughly 18-21 working days involving 4-5 people. That’s approximately four working weeks. And of course in the real world that team won’t get four weeks uninterrupted to focus on that project - holidays, sickness, other priorities jumping the queue, etc. There will be additional delays, and the longer something runs, the more it’s affected by these sorts of delays and interruptions.

Outcomes and timeline

Those steps I described above are equivalent to what I undertook to create this blogging site, but it took me just 4 days to get the site up and running.

Approximately 3 days of that was spent fine tuning, tweaking, corrections, etc - but it took just 3 hours to achieve the following in Kiro:

• Confirm the project (my) requirements - requirements.md
• Plan the project, outline the steps involved
• Generate and propose four high level solutions with comparative pros and cons on cost and complexity
• Select one of the four options, iterate that design to get to a solution I was happy with
• Produce the high level design architecture for the chosen solution - design.md
• Define all of the steps needed to make the project a reality - tasks.md
• Generate the CICD pipeline workflows in GitHub Actions, to validate PR’s, perform build and integration tests, and deploy content to the solution.
• Generate the first draft of Terraform IAC including, S3, Cloudfront, OAC, SSL certs via ACM, IAM Roles + least privilege policies, CloudWatch, Budgets, Route 53, Notification integrations with Slack, etc.
• S3 bucket for content and state file backups.
• Create 2 repositories, one for the IAC, one for blogging content. Both with specific security scanning, pre commit hooks etc.

3 hours effort to do that? - It blew my mind.

Now as I’ve already said, I wasn’t finished in 3 hours, it was more like 4 days.
Having got to the first draft of Terraform code, I wanted to make some changes, validate what had been produced, customise to suit my needs, etc. I also had some corrections and customisations to make on the GitHub actions workflows.

That process took me a further 3 working days (approx. 20hrs effort) to deploy, fix, tweak, and iterate to get the platform working as you see it now.

So less than 5 days, for a solo experienced cloud architect/engineer to complete something that was ready for deploying and acceptance testing.
Realistically that traditionally might take a team 3-4 weeks.

What did I learn from this?

AI powered coding tools can accelerate individual tasks. e.g. writing scripts, or a Terraform module. These tasks could be chained to accelerate aspects of a project delivery, but that on it’s own lacks a cohesive approach in terms of project planning, and working to an agreed plan.

SDD accelerates the whole project. It does this by shaping requirements and design first. So you have a clear plan that you can act on and your code is generated in line with that.

I also learned to have a backup plan.
Having travelled at the speed of developer light for the first few hours I ran into this issue:

There was 10 days before I’d get new credits and having generated, but not yet deployed and tested, all of the code… I couldn’t sit around and wait for that.

Most of the heavy lifting was done though - I was at the stage of deploying, reviewing, correcting, until it deployed cleanly and my site looked sensible and stable. But at this juncture I switched to ChatGPT Codex, integrating that with my repos in GitHub to take me down the home straight.

Conclusion

As is hopefully evident, I found Kiro to be incredibly powerful and easy to use. It promoted good practice and made planning quick and easy, but also to the appropriate level, neither under nor over cooked. Although it was rapid - it never felt like I was cutting corners. Quite the opposite in fact, Kiro steers you to think about what you’re doing and helps you to do it quickly.

Working with Kiro is closer to working with people than other code generating tools. I was able to hand off tasks (literally tasks.md) to Kiro while I joined calls or responded to other requests. In that regard, Kiro was like having a team to hand things off to so I could focus on something else, then check in later and course correct.

Kiro’s SDD approach promotes a single source of truth that works for an individual or for a project team. Integrating new project requests would be simplified too - just update the spec and the plan adapts then generates updates for the code automatically.

Teams using Kiro’s SDD could be much more competitive in delivering solutions for clients, then can be faster and cheaper.

Business can benefit too. How often is innovation a challenge for organisations because of a lack of available resources? Kiro could allow teams to deliver much more quickly, freeing up time to focus on innovation, or to take on additional projects.

Pricing will be interesting. At the time I write this, pricing has only been known for a few days and it’s higher than expected. Already there are op-ed articles highlighting how the costs could potentially rise quickly.

I’m not massively put off by that yet - I feel like I accidentally stumbled across a viable solution in my own use case: i.e. Use Kiro to go as far as you can, at least completing the project plan, and getting to the generated code ready to test. Then if you’re out of credits, switch to another (cheaper) coding assistant that can focus just on generating good quality code.

I would have loved to have completed my blog journey exclusively in Kiro - but I’d seen enough in my use case to recognise that there is genuine game changing potential in Kiro’s approach.

Right now I’m in the early process of learning about two potential projects coming my way. Whether it’s one of those or something else, price permitting, I’d be very keen to use Kiro to move quickly and accurately.

Additional Resources

• Claude-4 from Anthropic
• Kiro Tiers and Pricing
• Getting started with Hugo

This post is part of my AWS technical blog series. Found this helpful? Connect with me on LinkedIn or check back here for more AWS content and discussions.

Welcome to my AWS technical blog! This platform serves as a showcase of AWS expertise and best practices, created as part of my AWS Ambassador application journey.

What You’ll Find Here

This blog focuses on:

• AWS Best Practices: Real-world implementations and lessons learned
• Architecture Patterns: Scalable and cost-effective cloud solutions
• Serverless Technologies: Lambda, API Gateway, and event-driven architectures
• Infrastructure as Code: Terraform and CloudFormation examples
• Cost Optimization: Strategies for efficient AWS resource usage
• Security: AWS security best practices and compliance

About the Author

I’m a cloud enthusiast passionate about helping others leverage AWS services effectively. Through this blog, I share practical insights gained from hands-on experience with AWS technologies.

Technical Details

This blog itself demonstrates AWS best practices:

• Static Site Generation: Built with Hugo for optimal performance
• AWS Hosting: S3 + CloudFront for global content delivery
• Infrastructure as Code: Terraform-managed AWS resources
• CI/CD: GitHub Actions for automated deployment
• Cost-Effective: Designed to operate under $5/month

Connect With Me

Feel free to reach out through the social links in the footer or engage with the content through comments and discussions.

Browse all posts from our AWS technical blog, organized chronologically with advanced filtering options to help you find exactly what you’re looking for.