Guide · Teaching

Teach AWS without an AWS account

Hands-on AWS labs usually need an account per student, a payment card behind each one, and someone watching the bill. HomeCloud runs the AWS APIs on a machine you control, so students can use the real AWS CLI, boto3, Terraform and a familiar console with no AWS account at all.

HomeCloud v0.4.0Updated 2026-10-117 min read

This page is for instructors and lab staff. It describes what HomeCloud is good at in a classroom, how to set up one IAM user per student, and the limits you should tell your students about. HomeCloud is a young open-source project (first released in September 2026), so try a lab end to end before you put it in front of a class.

What students get

  • The real tools. HomeCloud speaks the AWS wire protocols, so students learn the actual aws CLI, boto3 and the hashicorp/aws Terraform provider, not a lookalike. Commands they learn in the lab work on AWS later, with a different endpoint and credentials.
  • IAM that says no. Every request goes through the same policy evaluator, with conditions, roles, permissions boundaries and iam:PassRole. An AccessDenied in the lab is a real lesson about least privilege, not a misconfigured emulator.
  • Things that actually run. An RDS instance is a PostgreSQL, MySQL or MariaDB they can connect to; a Lambda function runs on AWS's runtime image and logs to CloudWatch; an EC2 instance is a container they can open a shell in, and two images boot real virtual machines.
  • A console modeled on AWS's. Built into the binary, so it works without internet access. You can show it in class from the in-browser demo before anyone installs anything.
  • No bills. There is no metering and no payment card. A forgotten database costs a little memory on your server, nothing more.

Two ways to set up a lab

One shared server

One HomeCloud on a lab server, with an IAM user per student. This is the better fit for a class: one machine to prepare, students only need a browser and the AWS CLI. Size it for what students will run at the same time; the self-hosting guide covers sizing, TLS and backups. The server guide calls 4+ vCPUs and 8–16 GB comfortable; how many students that serves depends on the exercise. S3, IAM, SQS and DynamoDB calls are light, while every database, Lambda environment and instance is a container of its own, so a lab where thirty students each start a database needs far more memory than one about bucket policies.

shelllab server
curl -fsSL https://homecloud.pages.dev/scripts/install.sh | sh
homecloud serve --addr 0.0.0.0:8443 --public-host lab.cs.example.edu --tls-self-signed

Browsers warn about a self-signed certificate until students trust it; a reverse proxy with a real certificate avoids that, as described in the server guide.

One per student laptop

Each student installs HomeCloud and runs it locally, as root of their own account. Nothing is shared and nothing goes over the network. It needs Docker (Docker Desktop or OrbStack on macOS and Windows) and a laptop with at least 8 GB of memory to be comfortable. It also means supporting Docker on thirty different machines, which is its own lesson.

An IAM user per student

On a shared server, all students are users in the same account. Policy variables let one policy give each student a private namespace. For example, each student may only touch buckets that start with their user name:

student-s3.json
{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" },
    { "Effect": "Allow", "Action": "s3:*",
      "Resource": ["arn:aws:s3:::${aws:username}-*",
                   "arn:aws:s3:::${aws:username}-*/*"] }
  ]
}
shellinstructor, on the server
homecloud iam create-policy StudentS3 --document @student-s3.json

for n in $(seq -w 1 30); do
  pw=$(openssl rand -base64 12)
  homecloud iam create-user student$n --password "$pw" --policy StudentS3
  echo "student$n $pw" >> students.txt
  homecloud iam create-access-key student$n >> students.txt   # the secret is shown once
done

Keep students.txt private and hand each student their own lines. Students sign in to the console with their user name and password, and use their access key from the CLI:

shellstudent
export AWS_ENDPOINT_URL=https://lab.cs.example.edu:8443
export AWS_CA_BUNDLE=./lab-cert.pem             # the server's self-signed certificate
export AWS_ACCESS_KEY_ID=HCIA... AWS_SECRET_ACCESS_KEY=... AWS_REGION=us-east-1
aws sts get-caller-identity
aws s3 mb s3://student07-notes                 # allowed
aws s3 mb s3://student08-notes                 # AccessDenied

Write similar policies per lab: AWSLambda_FullAccess plus a role students may pass for a functions lab, AmazonDynamoDBFullAccess scoped to ${aws:username}-* tables, and so on. Give an exercise on policies its own sandbox user. Remember that names are shared across the account, so prefixes avoid collisions, and that list operations show other students' resource names, as they would in a shared AWS account.

Checking work

CloudTrail records every AWS API call with the calling user, kept for 90 days. That makes it straightforward to see what a student did, or why they are stuck:

shellinstructor
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=student07 \
  --query 'Events[].[EventTime,EventName]' --output table

homecloud iam simulate student07 s3:PutObject --resource 'arn:aws:s3:::student07-notes/*'

Before and after a session, homecloud backup takes a snapshot of the whole installation, and homecloud restore --force, with the server stopped, puts it back. That is a quick way to reset a lab to a known state.

Offline and air-gapped labs

The console and API need no internet access. The services do need their container images (MinIO, database engines, Lambda runtime images) on the Docker host, and HomeCloud builds a small helper image on first use. Run each lab once on the lab machine while it is online; after that the images are cached and the lab works without a connection.

What to tell students

  • It is not AWS. HomeCloud covers about 30 services and a subset of operations in each; Kinesis, EKS, Athena, REST API Gateway and many others are missing. Check the compatibility reference for your labs.
  • There is one region (us-east-1) and one account, so multi-region and AWS Organizations topics cannot be taught with it.
  • Network ACLs and NAT gateways are recorded but not enforced; security groups are enforced. Do not teach VPC routing from it.
  • Cognito and SNS do not send e-mail or SMS; codes and messages go to the server log.
  • Whoever administers HomeCloud controls the Docker host. Students get IAM users, never the root password or shell access to the server.

The trade-offs against a real AWS account, LocalStack and others are laid out in the comparison. For a Terraform module in your course, see running Terraform against a local AWS.