Seems we forgot to enable it in one region or so. Let's fix this

Not needed for correctness but makes CI 40 seconds faster

Will this new AMI include ssm-agent package by default? I see from the files in this repo that you're currently including the newer EC2 Instance Connect but nothing on ssm-agent. Will there be a choice to choose which one?

I'm coming from this issue: NixOS/nixpkgs#222637

the AMI does not come up properly with IPv6.

Neither is an IP picked up through DHCPv6 (amazon doesn't do SLAAC) nor does our user data scripts work as they don't go over ipv6LL

I've been running various versions of the 23.11 AMIs on t4g.micro instances and struggle with two issues:

• /boot fills up after a while due to the number of kernels
• Instance crashes in the midst of nixos-rebuild due to out of memory (micro has 1GB)

So: Would it be possible to specify the /boot partition size, as well as adding a swap partition?

The second can of course be worked around by adding a swap file (which I did) or adding a second EBS and partition it as swap.

Setting IMDS to a minimum of v2 breaks any expression using fetchurl to read meta-data, instead you get a 401 response:

nix-repl> builtins.readFile (builtins.fetchurl "http://169.254.169.254/latest/meta-data")
error:
[...]
       error: unable to download 'http://169.254.169.254/latest/meta-data': HTTP error 401

The only way it can be turned off down-stream is via the instance configuration. There is no way (that I can find) to clear that setting when making a new image. (Nor can it be cleared on any image that I own: https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ResetImageAttribute.html only allows launchPermission to be reset.) I'm using Hashicorp Packer, but a quick look at the source suggests it won't try and set it unless my configuration specifies it. So my guess is that the attribute is getting copied from the source image,

I'm rather surprised by the AWS "set only" behaviour here; but that's what we've got to live with. So I think it would be better if we leave requiring IMDSv2 as a decision for instance configuration. (Or downstream image creators.)

botocore.exceptions.WaiterError: Waiter InstanceRunning failed: Waiter encountered a terminal failure state: For expression "Reservations[].Instances[].State.Name" we matched expected path: "terminated" at least once

See https://github.com/NixOS/amis/actions/runs/7892798614/job/21540408580

https://aws.amazon.com/marketplace/partners

We need to create an AWS Marketplace account with the NixOS Foundation legal entity. Need help from the foundation for this

@garbas asked me if I could upload 23.11 AMIs and as a one-off put those in https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/amazon-ec2-amis.nix
so that they show up on the current website

For 24.05 we can use https://nixos.github.io/amis or equivalent

Always publish latest image. Weekly. Keep 2 older images around.

# TODO: This currently fails with exit code 1 and no helpful error message.

https://github.com/arianvp/amis/blob/8eb2b2e2c3bd567f9df2a0757284e45140a4216a/packages/ec2-instance-connect.nix#L14

    # TODO: For some reason /public-keys/ returns a 404 shortly after boot.

https://github.com/arianvp/amis/blob/705248be274f4d57bc03a94aca2fe61c5da36191/modules/amazon-profile.nix#L48

Something wrong with escaping?

This does work for other AMIs

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html is kinda vague about how these logs are collected

For Linux/Unix, the instance console output displays the exact console output that would normally be displayed on a physical monitor attached to a computer. The console output returns buffered information that was posted shortly after an instance transition state (start, stop, reboot, and terminate). The posted output is not continuously updated; only when it is likely to be of the most value.

I have a feeling that NixOS' headless mode is messing with things here.

We should make the bash more robust. it doesn't fail early on HTTP errors

People might want to do an ec2:CopyImage on our AMIs. e.g. to backport an old AMI to a new region. For this they need access to the backing EBS snapshot. So for this we need to make the snapshots public too

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html#copy-ami-across-accounts