Chapter 9 — Infrastructure as Code

Day 1 — CloudFormation Against Floci

1. Concept Primer

CloudFormation declares infrastructure as a template (JSON/YAML); a stack is one deployed instance of that template. Since Floci speaks the real CloudFormation API, templates you write here are the same templates you'd point at a real account — only the endpoint changes.

2. Hands-on Exercise

Write a template that creates an S3 bucket and a DynamoDB table together, deploy it as one stack, then tear it down.

3. Exact Commands

floci start && eval $(floci env)

cat > stack.yaml << 'EOF'
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  NotesBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: notes-bucket-day1
  NotesTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: NotesTable
      AttributeDefinitions:
        - AttributeName: NoteId
          AttributeType: S
      KeySchema:
        - AttributeName: NoteId
          KeyType: HASH
      BillingMode: PAY_PER_REQUEST
EOF

aws cloudformation deploy \
  --template-file stack.yaml \
  --stack-name day1-stack

aws cloudformation describe-stacks --stack-name day1-stack \
  --query 'Stacks[0].StackStatus'

aws s3 ls
aws dynamodb list-tables

aws cloudformation delete-stack --stack-name day1-stack

4. Gotchas

• aws cloudformation deploy is a higher-level wrapper that handles changesets for you; if you want to inspect the diff before applying, use create-changeset + describe-change-set instead.
• Delete order matters conceptually even though CloudFormation handles it for you here — dependent resources (e.g. things referencing the table) must be gone before the table itself can be removed.

5. Self-Check

What's the benefit of deploying S3 + DynamoDB together as one stack instead of running the individual aws s3 mb / aws dynamodb create-table commands separately?

---

Day 2 — Terraform Pointed at Floci

1. Concept Primer

Terraform's AWS provider can target any endpoint via its endpoints block — pointing all services at http://localhost:4566 turns your existing Terraform code into something you can plan/apply entirely offline, before it ever touches a real account.

2. Hands-on Exercise

Write a minimal Terraform config for an S3 bucket, targeting Floci, and apply it.

3. Exact Commands

eval $(floci env)

mkdir -p tf-day2 && cd tf-day2
cat > main.tf << 'EOF'
provider "aws" {
  region                      = "us-east-1"
  access_key                  = "test"
  secret_key                  = "test"
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true

  endpoints {
    s3 = "http://localhost:4566"
  }
}

resource "aws_s3_bucket" "day2" {
  bucket = "day2-tf-bucket"
}
EOF

terraform init
terraform plan
terraform apply -auto-approve

aws s3 ls

4. Gotchas

• Every service you use in the Terraform config needs its own line in the endpoints block (dynamodb, lambda, iam, etc.) — a missing entry means that resource type will try to reach real AWS and fail on the dummy credentials.
• skip_credentials_validation, skip_metadata_api_check, and skip_requesting_account_id are all necessary locally — without them the provider tries real AWS account-verification calls that will fail against Floci.

5. Self-Check

If you added an aws_dynamodb_table resource to this config without adding a dynamodb line to the endpoints block, what would you expect to happen on terraform apply?