ec2-instance

aws.ec2.instance (single VM — advanced)

One virtual machine that boots Docker (user-data) and runs the app's container. Cheapest fixed-cost compute: a t3.small is ~$15/mo flat, no per-request pricing — undercuts managed compute for steady hobby/MVP traffic.

When to use (opt-in only)

• OPT-IN ONLY: propose it only when interactionMode is collaborative/expert AND the user signals they can operate a server (or asks for EC2 by name). Guided users get aws.apprunner.service instead. The user owns the box: patching, restarts, manual updates, downtime on instance loss.

App compute only

• APP COMPUTE ONLY. Never self-host stateful infrastructure on it — no Postgres, Kafka, Redis, or Mongo in the container. A single-instance database or broker loses data when the instance dies. Use the managed equivalents (aws.rds.postgres, aws.sqs.queue/aws.sns.topic, aws.elasticache.redis) and say why.

Single point of failure (no HA)

• Single point of failure by design: no autoscaling, no failover. If the user needs HA or more than one instance, that is aws.alb → aws.ecs.service — do NOT stack multiple EC2 nodes or put EC2 behind an ALB (the v1 compiler doesn't wire instance target groups; the lint will warn).

What the v1 compiler emits

• Security group open on HTTP:80 to the world with the container port mapped to 80; wired env vars written to /etc/app.env; least-privilege IAM instance role for S3/SQS/DynamoDB/SNS/Lambda/Secrets edges; SSM Session Manager access (shell via aws ssm start-session — no SSH keys, no port 22); an Elastic IP as the stable public address.
• TLS is not emitted (HTTP:80 only). Cheapest production path: put aws.cloudfront.distribution in front, or run a reverse proxy with a certificate — note it in agentNotes either way.

Updates

• Changing the image template parameter replaces the instance with one running the new image (1–3 min downtime); day-to-day, the user or their coding agent can aws ssm start-session, then sudo docker pull + restart. Spell the chosen update path out in agentNotes.