Choosing Between Packer's Amazon EBS and VirtualBox ISO Builders for Cloud vs Local Images

The decision you face

When you need a machine image, the first question is where that image will run. Packer offers two builders that cover the most common targets: amazon-ebs produces an AWS AMI ready for production, while virtualbox-iso creates a Vagrant box you can spin up locally in seconds. The choice determines cost, speed, credential requirements, and how closely your test environment matches production.

Constraints that drive the choice

• Output format – AMI for AWS vs. Vagrant box for VirtualBox.
• Credentials – amazon-ebs needs an AWS access key with EC2/AMI permissions; virtualbox-iso needs only a local VirtualBox install.
• Build time – Cloud builds typically take 5‑15 minutes (instance launch, provisioning, AMI creation). Local ISO builds finish in 2‑8 minutes.
• Cost – Cloud builds incur EC2 instance‑hour charges and AMI storage fees. Local builds are free aside from host resources.
• Parity – An AMI runs on the exact same hypervisor and kernel as production workloads. A VirtualBox image may differ in drivers, cloud‑init behavior, and network stack.

Side‑by‑side comparison

Feature	amazon-ebs	virtualbox-iso
Output	AWS AMI	Vagrant box
Primary use case	Production deployment	Local testing / CI
Typical build time	5‑15 min	2‑8 min
Credentials required	AWS key with EC2/AMI rights	None
Common post‑processors	ami, manifest	vagrant, manifest
Access method	SSH to temporary EC2 instance	SSH to local VM

Trade‑offs explained

amazon-ebs gives you a production‑ready artifact directly consumable by CloudFormation, Terraform, or the AWS console. The downside is the need for valid AWS credentials, the monetary cost of the temporary instance, and the latency of provisioning over the network. If you run many experimental builds, costs can accumulate quickly.

virtualbox-iso is ideal for rapid iteration: no cloud account, no network wait, and you can snapshot the VM at any point. However, the resulting box cannot be deployed to AWS without a manual import (e.g., via aws ec2 import-image), and differences in virtualization hardware may surface bugs that only appear on real EC2 instances.

Concrete implementation: Amazon EBS builder

The following HCL snippet defines a minimal amazon-ebs source and a shell provisioner that installs nginx. Save it as ubuntu-nginx.pkr.hcl.

source "amazon-ebs" "example" {
  ami_name      = "packer-example-{{timestamp}}"
  instance_type = "t3.medium"
  region        = "us-east-1"
  source_ami_filter {
    filters = {
      name                 = "ubuntu/images/*ubuntu-focal-20.04-amd64-server-*"
      virtualization-type = "hvm"
    }
    most_recent = true
    owners      = ["099720109477"]
  }
  ssh_username = "ubuntu"
}

build {
  sources = ["source.amazon-ebs.example"]
  provisioner "shell" {
    inline = [
      "sudo apt-get update",
      "sudo apt-get install -y nginx"
    ]
  }
}

Where to run: any workstation or CI runner with Packer ≥ 1.9 installed and the AWS CLI configured (or environment variables AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY). The IAM user must allow ec2:RunInstances, ec2:CreateImage, ec2:TerminateInstances, and ec2:Describe* actions.

Placeholders to adjust: region, instance_type, and the source_ami_filter owners/filters if you target a different base image.

Validation and verification steps

1. Syntax check – Run packer validate ubuntu-nginx.pkr.hcl in the same directory. Exit code 0 means the template is syntactically correct and all required plugins are present.
2. Build the AMI – Execute packer build -only=amazon-ebs.example ubuntu-nginx.pkr.hcl. Watch for the line:

   ==> Builds finished. The artifacts of successful builds are:
   --> amazon-ebs.example: AMIs were created:
   us-east-1: ami-0abcdef1234567890

   Copy the AMI ID (e.g., ami-0abcdef1234567890).
3. Cleanup (cost control) – Deregister the test AMI and delete the associated snapshot once you no longer need it: aws ec2 deregister-image --image-id ami-0abcdef1234567890 --region us-east-1 followed by aws ec2 delete-snapshot --snapshot-id snap-xxxxx --region us-east-1.
4. Functional test – Launch a temporary instance from the AMI, SSH in, and verify nginx:

   aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t3.micro --key-name my-key --region us-east-1
   # after instance is running, SSH
   ssh -i my-key.pem ubuntu@
   systemctl status nginx
   curl -s http://localhost | grep -c "Welcome to nginx"

   A non‑zero grep count confirms the provisioner succeeded.

Limitations and practical checks

• Cost awareness – Every amazon-ebs build spins up an EC2 instance. Use a dedicated sandbox AWS account or enable billing alerts.
• VirtualBox prerequisites – The host must have hardware virtualization (VT‑x/AMD‑V) enabled in BIOS/UEFI. Verify with lscpu | grep Virtualization on Linux or the Task Manager Performance tab on Windows.
• ISO integrity – When using virtualbox-iso, always set the iso_checksum and iso_checksum_type fields to avoid corrupted builds.
• Parity gap – Even with identical provisioners, cloud‑init behavior, network interface naming, and kernel parameters can differ between VirtualBox and EC2. Treat the VirtualBox image as a fast feedback loop, not a substitute for a final AMI smoke test.

Quick decision checklist

• Do you need an artifact that can be deployed to AWS today? → amazon-ebs.
• Are you iterating on provisioning scripts and want sub‑minute feedback? → virtualbox-iso.
• Is your CI pipeline running on a machine without AWS credentials? → virtualbox-iso (or a self‑hosted runner with credentials).
• Do you have a strict budget that forbids any EC2 usage? → virtualbox-iso for development, promote to amazon-ebs only for release candidates.

Diagram labels

• Builder selection flow
• Amazon EBS build steps
• VirtualBox ISO build steps
• Validation checklist