EC2 Instances
What does zop.dev create for EC2 Instances?
zop.dev creates EC2 instances through its provisioner API from 3 required inputs (image_id, instance_type, and subnet_id), tags them as zop-managed, and filters list operations to that tag. Update is deliberately not implemented: changing the type or image means delete and recreate, so instances are treated as replaceable.
| Field | Value |
|---|---|
| Cloud | aws |
Amazon EC2 provides raw virtual machines for workloads that do not fit Kubernetes. zop.dev provisions and tracks zop-managed instances through its provisioner API, including instance-type discovery.
Instances tagged zop-managed and filtered on list
EC2 instances tagged as zop-managed; list operations filter to zop-managed instances only; GetNodeTypes supported for instance-type discovery.
Required image_id, instance_type, and subnet_id
Create requires image_id, instance_type, and subnet_id; companion ami resource type performs AMI lookup.Update is a stub in the provisioner
Update is not implemented in the provisioner (stub), so instances can be created, read, listed, and deleted, but not modified in place.
The tag is the management boundary
Instances created here are tagged as zop-managed, and list operations filter to that tag. The practical effect: zop.dev only ever shows and touches its own instances, and anything created by hand in the same account is invisible to it. That is the safe default, but it also means an existing instance is not adopted just by existing; without the tag, the platform does not know it is there.
No update path, on purpose
Create, read, list, and delete are implemented; update is a stub. There is no resize-in-place,
no image swap, no subnet move. Changing instance_type or image_id means deleting the
instance and creating a new one. That is the honest shape of EC2 anyway, since an AMI change
always requires a replacement and a subnet change means a new interface in a new place.
Treat these instances as replaceable. Anything worth keeping should live on a separate volume or outside the instance entirely, because the modification story is recreation.
Three inputs, each with a long shadow
image_id, instance_type, and subnet_id are required, and each decides something durable.
The subnet quietly fixes the availability zone forever: an instance never moves AZs. The image
sets the OS and patch baseline until replacement; the companion ami resource type exists to
keep it honest, resolving images by owner and name pattern instead of hardcoding per-region
IDs. The instance type is the bill: EC2 charges per second while the instance runs, at a rate
set entirely by this one field.
What keeps costing after you stop
Stopping an instance stops the compute meter but not the storage one. EBS volumes attached to a stopped instance keep billing per GB-month, and any allocated Elastic IP starts billing the moment its instance is off. Deletion is the only state with a zero bill.