[Feature Request] Support VM Image Import in CloudFormation

[commiterate]

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

[commiterate]

Spoke with an AWS PM for EC2 Image Builder.

Distribution-only image pipelines can be created today by creating a pipeline with an empty image workflow. Unlike image recipes, image workflows can do a no-op.

There are currently no plans to expand ImportVmImage which is likely required for supporting VM image import in CloudFormation.

[commiterate]

Spoke with a Principal Engineer for EC2 Image Builder.

The difficulty around expanding ImportVmImage functionality is generally around ownership. Both ImportImage and ImportSnapshot are APIs that are owned by another EC2 division and not Image Builder.

Since Image Builder doesn't own the APIs nor the ARN-less AMIs created by these APIs, they will need to work with the EC2 team that owns these APIs to expand their capabilities and also add CloudFormation support (might need to live as its own CloudFormation resource type instead of being part of the Image Builder image CloudFormation resource).

[commiterate]

Made a separate feature request to the AWS CloudFormation coverage repo for a separate AWS::EC2::Image resource.

https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/2175

@austoonz Do you know which EC2 team owns ec2:ImportSnapshot + ec2:ImportImage and their PoC for this feature request?

A separate AWS::EC2::Image resource should probably exist to avoid AWS::ImageBuilder::Image from spanning multiple services and to avoid region build concerns (since Image Builder is late in region build while AMIs are foundational).

[commiterate]

Closing in favor of the CloudWatch coverage roadmap issue.