We use Nix + system-manager to bake reproducible Amazon Linux 2023 AMIs. There's a shell script snippet in this GitHub issue: https://github.com/aws/ec2-image-builder-roadmap/issues/110

# Switch from ssm-user to the default user.
sudo su ec2-user

# Install RPM packages.
sudo dnf install --assumeyes curl-minimal git

# Install Nix.
curl --fail --location https://install.determinate.systems/nix/tag/v3.1.1 --proto '=https' --show-error --silent --tlsv1.2 | sh -s -- install --no-confirm
. /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh

# Setup Nix flake registry.
nix registry add nixpkgs github:NixOS/nixpkgs/{Git revision hash}
nix registry add system-manager github:numtide/system-manager/{Git revision hash}

# Install Nix packages.
nix profile install system-manager

# Apply system-manager configuration (installs system-wide packages and sets up systemd units).
sudo $(command -v system-manager) pre-populate --flake 'git+{Git HTTPs URL}&rev={Git revision hash}#{system-manager flake output key}'

CloudFormation templates are generated with the AWS CDK. The infrastructure code essentially:

• Locks an Amazon-managed AMI ID from their SSM public parameters into the cdk.context.json file.
• Calls nix flake metadata to get the flake's Git hash and construct a flake URL for the flake itself and some inputs needed in the script (we run Nix eval on a system in a VPC with company network connectivity).
• Generates an SSM document with the aforementioned script.
• Sets up the EC2 Image Builder infrastructure that auto-builds an AMI on CloudFormation stack deploys.
• Reference the AMI in a launch template which is then used in an auto-scaling group.
• Use CloudFormation rolling update to bounce the auto-scaling group (until ASG instance refresh is supported in CloudFormation).

Once the CloudFormation image import situation is improved, we'll move the non-bootstrap stuff to use NixOS disk images created with the systemd-repart helpers.

This ends up being fully reproducible because Amazon Linux 2023 locks the Amazon Linux package repository version (these are globally versioned now), so any Nix dependencies like curl and git are locked by the base Amazon Linux 2023 AMI itself.

We use Nix + system-manager to bake reproducible Amazon Linux 2023 AMIs. There's a shell script snippet in this GitHub issue: https://github.com/aws/ec2-image-builder-roadmap/issues/110

# Switch from ssm-user to the default user.
sudo su ec2-user

# Install RPM packages.
sudo dnf install --assumeyes curl-minimal git

# Install Nix.
curl --fail --location https://install.determinate.systems/nix/tag/v3.1.1 --proto '=https' --show-error --silent --tlsv1.2 | sh -s -- install --no-confirm
. /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh

# Setup Nix flake registry.
nix registry add nixpkgs github:NixOS/nixpkgs/{Git revision hash}
nix registry add system-manager github:numtide/system-manager/{Git revision hash}

# Install Nix packages.
nix profile install system-manager

# Apply system-manager configuration (installs system-wide packages and sets up systemd units).
sudo $(command -v system-manager) pre-populate --flake 'git+{Git HTTPs URL}&rev={Git revision hash}#{system-manager flake output key}'

CloudFormation templates are generated with the AWS CDK. The infrastructure code essentially:

• Locks an Amazon-managed AMI ID from their SSM public parameters into the cdk.context.json file.
• Calls nix flake metadata to get the flake's Git hash and construct a flake URL for the flake itself and some inputs needed in the script (we run Nix eval on a system in a VPC with company network connectivity).
• Generates an SSM document with the aforementioned script.
• Sets up the EC2 Image Builder infrastructure that auto-builds an AMI on CloudFormation stack deploys.
• Reference the AMI in a launch template which is then used in an auto-scaling group.
• Use CloudFormation rolling update to bounce the auto-scaling group (until ASG instance refresh is supported in CloudFormation).

Once the CloudFormation EC2 disk image import situation is improved, we'll move the non-bootstrap stuff to use NixOS disk images created with the systemd-repart helpers.

This ends up being fully reproducible because Amazon Linux 2023 locks the Amazon Linux package repository version (these are globally versioned now), so any Nix dependencies like curl and git are locked by the base Amazon Linux 2023 AMI itself.

urgh:

https://github.com/aws/amazon-ec2-metadata-mock/issues/234

I don't know if the IMDS team themselves own EC2 metadata mock. If it is, they're probably dealing with a lot of internal IMDS development work.

If not, it's probably something more owned by solutions architects (e.g. most stuff under the aws-labs GitHub org like coldsnap) who are also working on many other things.

I don't know if the IMDS team themselves own EC2 metadata mock. If it is, they're probably dealing with a lot of internal IMDS development work.

If not, it's probably something more owned by solutions architects (e.g. most stuff under the awslabs GitHub org like coldsnap) who are also working on many other things.

I don't know if the IMDS team themselves own EC2 metadata mock. If they do, they're probably dealing with a lot of internal IMDS development work.

If not, it's probably something more owned by solutions architects (e.g. most stuff under the awslabs GitHub org like coldsnap) who are also working on many other things.

I don't know if the IMDS team themselves own EC2 metadata mock. If they do, they're probably dealing with a lot of internal IMDS development work (it's an eternal cycle of dealing with new EC2 instance type bringups).

If not, it's probably something more owned by solutions architects (e.g. most stuff under the awslabs GitHub org like coldsnap) who are also working on many other things.

I don't know if the IMDS team themselves own EC2 metadata mock. If they do, they're probably dealing with a lot of internal IMDS development work (it's an eternal cycle of dealing with new EC2 instance type bring ups and fire fighting for most EC2 Nitro teams).

If not, it's probably something more owned by solutions architects (e.g. most stuff under the awslabs GitHub org like coldsnap) who are also working on many other things.