Skip to content

Terraform Infrastruktur Repositories

Terraform is a tool for defining infrastructure as code (IaC). Instead of clicking through the AWS console to create resources, you describe what you want in .tf files and Terraform provisions it for you. Each time you push a change, a CI/CD pipeline runs to make the real infrastructure match your code.

In Byks, Terraform is the primary way teams provision AWS resources. Most teams do not write raw Terraform. Instead, they call the Byks module, a Terraform module that configures ECS services, Lambda functions, CloudFront distributions, and more with sensible defaults and security built in.

The structure of a Terraform repository

A Terraform repository organizes infrastructure into environment folders, each holding one or more service folders. Each service folder contains these files:

A terraform environment folder
└── <example>/eu-west-1/
    ├── <service-1>/
    │   ├── account-defaults.tf # symlink
    │   ├── environment.tf      # symlink
    │   ├── main.tf
    │   ├── route53_provider.tf # symlink
    │   ├── ses_provider.tf     # symlink
    │   ├── state-init.conf     # symlink
    │   └── state.tf    
    ├── <service-2>/
    │   ├── ...
    │   └── ...
    ├── ...
    └── environment.tf

environment.tf: Variables and AWS provider

environment.tf declares the input variables for this environment: environment (development, test, or production), team, application_name, region, and so on. It also configures the AWS provider, setting the default region and applying standard BYM resource tags to every AWS resource Terraform creates in this service.

The file at the environment-folder level is symlinked into each service folder beneath it. All services in the same environment share the same variable defaults and provider configuration. Changing the file in one place updates all services.

main.tf: Calling the Byks module

main.tf is where you call the Byks module. You pass the variables from environment.tf as required inputs, then add configuration blocks for the AWS resources your service needs—an ECS service, a Lambda function, a CloudFront distribution, and so on.

main.tf – calling the Byks module to provision an ECS service
module "application" {
  source = "git@github.com:BYM-IKT/terraform-byks-module.git?ref=v12"
  account_id       = var.account_id
  application_name = var.application_name
  environment      = var.environment
  team             = var.team

  ecs_services = {
    api = {
      port         = 8080
      ecr_uri      = "336385411112.dkr.ecr.eu-west-1.amazonaws.com/kattehotell-api-shared"
      image_tag    = var.environment
    }
  }
}

state.tf: Storing Terraform state

Terraform records what it has provisioned in your AWS account in a state file. state.tf configures the S3 backend and sets the key, a unique path in the state bucket, for this service's state file.

Each service folder has its own state.tf with a distinct key. Keeping state per service means a Terraform run on one service never touches the state of another.

state-init.conf provides the remaining backend settings: the S3 bucket name, region, and DynamoDB lock table. Symlinked from the environment folder, it applies to all services. The CI pipeline runs terraform init -backend-config=state-init.conf automatically when it detects changes in a service folder.

Where to commit your Terraform code

Terraform code in BYM lives in different types of repositories. Which one to use depends on what you are doing.

Your product's Infrastruktur repository

For application infrastructure such as ECS services, Lambda functions, CloudFront distributions, databases, and queues, use your product's dedicated Terraform Infrastruktur-repo. These repositories are named after the product, following the pattern <Name>Infrastruktur, for example KlagebehandlingInfrastruktur or GeodataInfrastruktur.

This is the repository you edit when following guides in this documentation. Most Byks guides refer to this when saying "add the following to your Infrastruktur repository".

If your product needs a new Terraform Infrastruktur-repo, contact Team Cloud by messaging the Slack channel #cloud-infrastructure.

Mock Repository Zip

A mock version of an Infrastruktur repository, using the fictional product "Kattehotell", can be downloaded here as a .zip-file. It has the same basic structure as all other Infrastruktur repositories, and can be used as a reference.

SharedKontoInfrastruktur

The SharedKontoInfrastruktur repository provisions infrastructure in the shared BYM AWS account, which exists outside any single team's environment.

Use this repository when you need an ECR container image repository. ECR repositories live in the shared account so that Docker images can be pushed once and pulled by any environment (test, production). The ECR setup guide walks through adding your application here.

Shared platform infrastructure such as DNS zones, SES, and integrations also lives in this repository.

SandboxInfrastruktur

The SandboxInfrastruktur repository contains two AWS sandbox accounts, DTI-Sandbox and DP-Sandbox. Only DP-Sandbox is available to all developers in BYM-IKT. Use SandboxInfrastruktur for experiments, testing infrastructure patterns, and prototyping before adding code to a production repository.

To get started:

  1. Duplicate the <example> folder inside the BYM-DP-Sandbox folder.
  2. Rename the <example> and <example>/eu-west-1/<service> folders.
  3. Rename the variables in eu-west-1/environment.tf, eu-west-1/<service>/main.tf and eu-west-1/<service>/state.tf to match your intended names.

Git workflows

Changes to Terraform files in an Infrastruktur repository trigger automated workflows.

These workflows are defined in the BYM-IKT/terraform-githubactions repository.

When creating a pull request

Opening a pull request runs the Terraform Plan workflow on every Terraform directory that contains changed files. It posts a comment on the PR with the planned changes. Review this comment before merging to confirm the changes match what you intended.

The workflow minimizes previous plan comments when new ones are posted, so the PR comment thread stays readable.

When merging

Merging a pull request to master triggers the Terraform Apply workflow. It retrieves the exact plan file saved during the plan step and applies it to your AWS account. The apply output is posted as a new comment on the PR.

Because the apply uses the saved plan file rather than a freshly generated one, what you reviewed before merging is exactly what gets applied.

Drift detection

The Terraform Check Drift workflow runs every weekday morning (Oslo time). It checks whether the real AWS infrastructure matches the Terraform state.

When the workflow detects drift, it creates a pull request in your repository with a small change and sends a Slack notification. Merge that PR to re-trigger the plan and apply cycle and correct the drift.