Skip to main content
Warning This document has not been updated for a while now. It may be out of date.
Last updated: 9 Jun 2020

govuk-aws: 24. AMI Lookups

Date: 2017-08-29




All of our launch configs require that an Amazon Machine Image (AMI) be specified. How the AMI ID is specified is the point of debate.

Currently we use the aws_ami data source to determine the newest AMI ID published by Ubuntu within a major version and use that in our launch configurations. This ensures we're always using newest version of Ubuntu when we spin up a new set of machines. On the downside, as this can change without our intervention, our terraform runs sometimes want to change more than we would expect:

  image_id: "ami-2944as50" => "ami-10c9asa9" (forces new resource)

In some cases this is fine but due to the legacy nature of our deployments it causes issues with machines that need a number of manual deployment steps applied to them. Examples of these include the app servers and the puppet master.

The other alternative is to specify a specific image name. This has the benefit that we know exactly which version we deploy and it cannot change without our intervention.


We override the instance_ami_filter_name parameter of the node_group module in all the projects. In the data directory, there is a common variable that sets the default value of the parameter for an environment. This can be customised per project in the project tfvars file.


Moving away from the dynamic AMI lookup means we might deploy auto scaling groups with an older version of the AMI that could have more security issues present. We'd work around this in the same way we do our other environments; by using the overnight security patching we deploy via puppet.