Cloud Infrastructure as Code: Classroom Bootcamp

An eight-hour classroom bootcamp on infrastructure as code with Terraform and Terragrunt, taught on the smarter-infrastructure repository, which builds Smarter’s complete AWS environment: the network, the Kubernetes cluster, ingress, certificates and the application’s resources. It is a real production configuration, not a teaching example: an EKS cluster on Spot capacity with the Cluster Autoscaler and roles for service accounts, Calico network policies, Traefik and cert-manager as Helm releases, and a root configuration that refuses to run against the wrong AWS account. Smarter itself goes on to manage infrastructure at run time, through a service layer that creates DNS records, certificates, ingresses and GPU node groups, with an in-memory provider in tests. Students read a real production configuration, plan it, estimate its cost, and write a module of their own. See Course Formats and Grading for the standard bootcamp day, the grading scale and the course policies, and Cloud Infrastructure as Code for an overview of the subject.

At a Glance

Students

Cloud, operations and platform engineers, and developers who deploy their own systems.

Deployment

Each student clones smarter-infrastructure and installs Terraform (or OpenTofu) and Terragrunt. Labs that run plan need a sandbox AWS account with read access; no lab in this bootcamp runs apply against the full stack.

Cost

Free if only plan is run. The optional module lab creates a few cents of resources and destroys them.

Warning

terraform apply creates real, billable cloud resources, and the full Smarter stack costs hundreds of dollars a month. Use a dedicated sandbox account with a billing alert, never a production account, and destroy what you create at the end of each session.

Learning Objectives

By the end of the bootcamp, students can:

  1. Explain the benefits of infrastructure as code: repeatability, review, history and drift detection.

  2. Read Terraform: providers, resources, data sources, variables, outputs, modules and state.

  3. Explain how Terragrunt keeps several environments consistent without duplicating code.

  4. Map a production AWS environment (VPC, EKS, ingress, certificates) to the modules that create it, and explain its security design.

  5. Plan infrastructure, read a plan, and estimate its monthly cost.

Technical Prerequisites

  • Required: the Linux or macOS command line, Git, and a text editor.

  • Required: cloud fundamentals: regions, virtual networks and subnets, identity and access management, and managed services.

  • Required: Docker and basic Kubernetes concepts (what a cluster, a node and an ingress are).

  • Required: reading JSON and YAML.

  • Required: Terraform (or OpenTofu), Terragrunt and the AWS CLI installed, and, for students who will run plan, a sandbox AWS profile set up, before the bootcamp.

  • Helpful: networking (CIDR blocks, routing, NAT, DNS) and some AWS console experience.

Schedule

The files that the lectures refer to are listed in full under Smarter in the Source Code.

Block

Min

Content

1

45

Lecture 1: Why infrastructure as code. Click-ops versus code, declarative versus imperative, and the lifecycle of init, plan, apply and destroy. State, and why it must be stored remotely and locked.

2

45

Lab 1: A first module. Write a tiny Terraform configuration that creates an S3 bucket with versioning and encryption in a sandbox account, plan it, apply it and destroy it. Produces Assignment 1.

3

45

Lecture 2: Reading real Terraform. A tour of smarter-infrastructure: the aws/terraform modules (vpc, kubernetes, kubernetes_ingress, kubernetes_cert_manager, kubernetes_descheduler and smarter), their variables and outputs, and how they depend on each other.

4

45

Lab 2: Map the stack. For each module, list the AWS and Kubernetes resources that it creates, and draw the dependency graph between modules. Produces Assignment 2.

5

45

Lecture 3: Terragrunt and environments. aws/terragrunt.hcl, global.hcl, the stack folder, and the alpha, local and prod environments. Keeping environments the same where it matters and different where it must be.

6

45

Lecture 4: Security by design. Why the cluster sits on a private network, public and private subnets, NAT, security groups, Calico network policies with default-deny ingress, IAM roles for service accounts, allowed_account_ids, least privilege, and the repository’s own unencrypted remote state as a finding to fix. Cloud Infrastructure.

7

45

Lab 3: Plan and price. Run terraform plan (or terragrunt plan) for the vpc and kubernetes modules against a sandbox account, read the plan, and estimate the monthly cost with Infracost or the AWS pricing calculator. Produces Assignment 3.

8

45

Lecture 5: Infrastructure inside the application. How Smarter manages DNS records, certificates and Kubernetes objects at run time through its infrastructure service layer (smarter/smarter/apps/infrastructure/), with an AWS provider in production and an in-memory provider in tests. Infrastructure Services.

9

45

Lab 4: Static analysis. Run tflint and Checkov on the repository, and triage the findings. Ungraded.

10

45

Lecture 6: Working as a team. Code review of plans, CI for infrastructure, drift, importing existing resources, and the terraform apply safety rules.

11

30

Capstone kickoff. Students choose a capstone and plan it.

Smarter in the Source Code

Every lecture, lab and assignment in this course rests on the files below, in two repositories: smarter-infrastructure, the Terraform and Terragrunt that build Smarter’s AWS environment, and smarter, the application that manages infrastructure of its own at run time. Every reference is to the main branch, so that students can open each one during class.

The Terraform Stack

Module

What it creates

Where to look

vpc

The network: public and private subnets, NAT and routing, and the Route53 zone that the platform uses.

aws/terraform/vpc/

kubernetes

An EKS cluster built with the community terraform-aws-modules/eks module, with roles for service accounts (IRSA), managed node groups on Spot capacity that scale from 0 to 15 nodes, the Cluster Autoscaler, the CoreDNS, VPC CNI and EBS CSI add-ons, and persistent storage.

aws/terraform/kubernetes/main.tf, config/cluster-autoscaler.yaml.tpl

Network policies

With enable_enhanced_security on, Calico as the network policy engine, default-deny ingress for MariaDB, Redis and the application, and egress from the application limited to the database ports.

aws/terraform/kubernetes/network_policy.tf

kubernetes_ingress and kubernetes_cert_manager

Traefik as the ingress controller, its DNS records, and cert-manager for TLS certificates, each installed as a Helm release from a values template.

aws/terraform/kubernetes_ingress/, aws/terraform/kubernetes_cert_manager/

kubernetes_descheduler

The descheduler, which moves pods to rebalance the cluster’s nodes.

aws/terraform/kubernetes_descheduler/

smarter

Each environment’s own resources: certificates, CloudFront, an ECR repository, IAM, S3, SES for email, Route53 records, a bastion host, Kubernetes secrets and ingresses.

aws/terraform/smarter/

Terragrunt and Environments

Topic

How it is done

Where to look

The root configuration

Generates the AWS provider with allowed_account_ids, a guard that refuses to run against any other account, and the remote state: an S3 bucket per account and a DynamoDB lock table.

aws/terragrunt.hcl

Shared values

Region, domain, cluster name and tags, each read from the environment with a default.

aws/global.hcl, .env.example

The shared stack

The cluster’s version, node group sizes, and the AMD64 and Graviton instance types, once for every environment.

aws/stack/stack.hcl, aws/stack/

Environments

alpha, local and prod, each a short terragrunt.hcl that points at the smarter module and merges the shared values.

aws/environments/

Something to question

The remote state sets encrypt = false, and a comment in the root configuration marks a known naming problem as a FIX NOTE. Real code has debts, and finding them is part of reading it.

aws/terragrunt.hcl

A guide

A getting-started guide for Terraform, written for this repository.

doc/TERRAFORM_GETTING_STARTED_GUIDE.md

Infrastructure Inside the Application

Python paths are under smarter/smarter/ in the smarter repository.

Topic

What Smarter does

Where to look

One facade

All DNS, certificate, Kubernetes and email work goes through infrastructure.dns, .certificates, .kubernetes and .email. The application never calls the AWS SDK directly. Infrastructure Services.

infrastructure/services/__init__.py, infrastructure/services/

Providers

Route53 and Certificate Manager in production, and an in-memory provider that tests use instead, behind one CloudProvider interface that another cloud could implement.

infrastructure/providers/aws/, providers/memory.py, providers/base.py

Declarative at run time

Deploying an LLMClient creates its DNS record, certificate and Kubernetes ingress from a template, in Celery tasks.

llmclient/k8s/ingress.yaml.tpl, llmclient/tasks/deploy_default_api.py

Node groups on demand

Serving a self-hosted model creates an EKS managed node group of the right GPU or CPU nodes, starting at zero, and removes nodes safely.

llmhost/services/nodegroups.py

An inventory

Every cloud resource that the platform created or found, and whether it still exists.

infrastructure/models.py

Safety rules

Why tests fake every cloud call, and the tag that keeps tests that touch real infrastructure from running by default.

smarter-infrastructure-safety/SKILL.md

Graded Assignments

Assignment 1: A First Module

Students write a small Terraform configuration for an encrypted, versioned S3 bucket with a lifecycle rule, with variables and outputs, then plan, apply and destroy it.

Turn in: the configuration in a Git repository, and the plan, apply and destroy output.

Criterion

Pts

Exemplary

Developing

Correctness

6

Applies cleanly; bucket has encryption, versioning and the lifecycle rule.

Missing a requirement.

Structure

5

Variables, outputs and pinned provider versions.

Hard-coded values.

Hygiene

5

State and credentials not committed; resources destroyed.

State file committed, or resources left running.

Explanation

4

Explains the plan output.

Raw output only.

Assignment 2: Stack Map

Students map each module in aws/terraform to the resources that it creates, and draw the dependency graph between modules.

Turn in: a table and a diagram.

Criterion

Pts

Exemplary

Developing

Resource mapping

8

Every module’s main resources correctly identified.

Modules skipped or misread.

Dependencies

6

Graph shows which outputs feed which inputs.

Boxes without edges.

Security observations

4

Notes private subnets, network policies and roles.

None.

Clarity

2

Clear.

Cluttered.

Assignment 3: Plan and Price

Students run a plan for the vpc and kubernetes modules against a sandbox account, and estimate the monthly cost of the result, comparing it with the figures in Kubernetes for Running Applications at Scale.

Turn in: the plan summary, a cost table by resource, and a half-page comparison.

Criterion

Pts

Exemplary

Developing

Plan

5

Runs, and the summary is explained.

Does not run, or unexplained.

Cost estimate

7

Every billable resource priced, with assumptions.

Major items missing (NAT gateways, nodes, load balancer).

Comparison

5

Explains differences from the published figures.

No comparison.

Savings

3

Suggests one realistic saving and its trade-off.

None.

Capstone Projects

Students choose one. Capstones are due one week after the bootcamp.

Capstone A: A Reusable Module

Learning objective. Write a reusable, documented, tested Terraform module in the style of a real infrastructure repository.

Students write a module that a team like Smarter’s could use, for example an S3 bucket for database backups with encryption, lifecycle rules and a least-privilege IAM policy for a Kubernetes service account, or a CloudWatch billing alarm with email notification. It includes examples and automated checks.

What students turn in:

  • A Git repository with the module, an examples/ folder, a README.md generated with terraform-docs, and a CI workflow that runs terraform fmt, validate, tflint and Checkov.

  • Evidence of a plan, apply and destroy in a sandbox account.

How it is graded (100 points):

Criterion

Pts

Exemplary

Developing

Works

20

Applies and destroys cleanly.

Errors.

Interface

20

Clear variables with types, descriptions and validation; useful outputs.

Untyped, undocumented variables.

Security

20

Encryption, least privilege, no public access unless intended.

Wide permissions.

Automated checks

20

CI runs all four checks and passes.

Some checks, or failing.

Documentation

20

Generated docs and a working example.

Missing.

Capstone B: An Architecture and Cost Review

Learning objective. Review a real production infrastructure against a recognized framework, and make evidence-based recommendations.

Students review smarter-infrastructure against the security, reliability and cost optimization pillars of the AWS Well-Architected Framework, using the code, plans, static analysis and cost estimates as evidence.

What students turn in:

  • A review document (four to six pages): findings by pillar, each with evidence and a severity.

  • A cost model of the stack with at least two cost reduction options and their trade-offs.

  • Prioritized recommendations, at least one written as a code change (a diff).

How it is graded (100 points):

Criterion

Pts

Exemplary

Developing

Framework use

20

Findings organized by pillar and question.

Framework named only.

Evidence

25

Each finding cites code, plan output or tool results.

Opinions.

Cost model

20

Complete, with options and trade-offs.

Partial.

Recommendations

20

Prioritized, realistic, one as a diff.

Unprioritized.

Writing

15

Clear and concise.

Disorganized.

Further Study