[Feature Request] Support VM Image Import in CloudFormation

Feature Request

Support VM image import in CloudFormation.

This also requires a few other things:

Allow for distribution-only image pipelines.
- The pipeline should have a recipe with no components (at least 1 is required today) or not require a recipe (might already be allowed today). This should skip instance launch and downloading AWSTOE onto the instance, going directly to distribution.
Expand ec2:ImportImage to support AArch64 images.
- This helps close the parity gap with ec2:ImportSnapshot + ec2:RegisterImage.
Make imagebuilder:ImportVmImage:
1. Accept ec2:ImportImage request parameters (e.g. as an ImageImportConfiguration subfield). The service:
  - Calls ec2:ImportImage, tracks the job in Image Builder, and returns.
  - Waits for the job to complete.
  - Imports the AMI into Image Builder.
2. Accept an ec2:ImportSnapshot task ID. The service:
  - Calls ec2:RegisterImage, imports the AMI into Image Builder, and returns.
3. Accept ec2:ImportSnapshot request parameters (e.g. as a SnapshotImportConfiguration subfield). The service:
  - Calls ec2:ImportSnapshot, tracks the job in Image Builder, and returns.
  - Waits for the job to complete.
  - Calls ec2:RegisterImage.
  - Imports the AMI into Image Builder.

Users should be able to have a CloudFormation template like this:

Resources:
  ImportedAMI:
    Type: AWS::ImageBuilder::Image
    Properties:
      ImageImportConfiguration:
        Architecture: arm64
        ImageDiskContainers:
          - UserBucket:
              S3Bucket: cdk-{qualifier}-assets-${AWS::AccountId}-${AWS::Region}
              S3Key: {content hash}-vm-image-aarch64.raw

Alternatively if Image Builder offers a wrapper around ec2:ImportSnapshot + ec2:RegisterImage instead, the template would look like this:

Resources:
  ImportedAMI:
    Type: AWS::ImageBuilder::Image
    Properties:
      SnapshotImportConfiguration:
        Architecture: arm64
        SnapshotDiskContainer:
          UserBucket:
            S3Bucket: cdk-{qualifier}-assets-${AWS::AccountId}-${AWS::Region}
            S3Key: {content hash}-vm-image-aarch64.raw

This image should be targetable by Image Builder lifecycle policies. Today, this requires a recipe for resource selection.

Additional Context

EC2 Image Builder currently provides the only avenue for users to manage EC2 AMIs and AMI lifecycle policies purely through AWS-provided CloudFormation resources (e.g. AWS::ImageBuilder::Image, AWS::ImageBuilder::LifecyclePolicy).

In comparison, other AMI baking solutions such as S3 → VM image import or HashiCorp Packer require a lot of extra supporting infrastructure to properly track and clean up old AMIs.

In addition to AMI building functionality, Image Builder can also distribute AMIs as part of an image pipeline.

Users may want to only use Image Builder's AMI distribution functionality without using the AMI building functionality.

For example, users may have a setup where they build VM images locally and then upload them to the AWS CDK bootstrap stack's S3 asset bucket for ingestion with ImportImage (does the actual import) + ImportVmImage (registers the AMI in Image Builder as an ARN-able resource).

Since imagebuilder:ImportVmImage is done outside of CloudFormation's purview, the resulting ImageBuilder Image (an ARN-able resource separate from the AMI) isn't tracked by CloudFormation. As a result, CloudFormation isn't able to automatically delete it when a replacement is needed during a stack update.

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

aws / ec2-image-builder-roadmap