AWS with Terraform (Day 12)

AWS Terraform Functions - Part 2 (Day 12)

This guide continues building practical Terraform skills by exploring a set of commonly used functions: variable validations, type conversions, numeric helpers, timestamp formatting, and file operations. The goal is to show how these functions help enforce inputs, transform data, perform calculations, and read configuration files safely and predictably.

Why use Terraform functions?

Functions let you validate and manipulate values before they reach resource creation. They reduce human error, make modules more robust, and keep your plans predictable. Instead of handling mistakes after apply, you can catch them early with variable validation and transform inputs into the exact shape needed for further logic.

Validation functions: guardrails for variables

Place validations inside the variable declaration using the validation block. Each validation requires a boolean condition and an error_message. Common checks include length, pattern matching, and required suffixes.

Length validation

To ensure a variable string length falls in a specific range, combine the length() function with logical operators. Example rule (conceptual): the instance type length must be between 2 and 20 characters.

Pattern validation with regular expressions

Use regular expressions to restrict allowed values. For instance, to allow only instance families that start with "t2" or "t3" followed by a dot and the instance size, build a regex like ^t[23]\. Remember to escape the dot when needed (for example with a backslash). Pair the regex check with an appropriate error message so users know why the input failed.

Other validation helpers

Built-in helpers such as endswith() make it easy to require a particular suffix. For example, ensure a backup name ends with -backup. If a validation fails, Terraform reports the custom error message and points to the file and line for quick fixes.

instance type must start with T2 or T3

Sensitive variables: hide outputs but be careful

Mark variables with sensitive = true to prevent their values from appearing on stdout or in plan outputs. If an output references a sensitive input, the output must also be annotated sensitive = true. This prevents casual exposure in logs, but note:

  • Terraform state still contains the value (encoded but not encrypted).
  • Treat sensitive variables cautiously and prefer secret managers or encrypted backends for real credentials.

Type conversion: lists, sets, and concatenation

Type conversion functions transform data structures so downstream logic behaves correctly.

Concatenating lists

Use concat() to combine multiple lists into one. This is useful to merge user-provided locations with default locations.

Removing duplicates with sets

Convert a list into a set (for example using toset()) to remove duplicate values. This is ideal when you want unique locations after concatenation.

Numeric functions and list processing

Common numeric tasks include converting negative values to positive credits, finding maxima and minima, summing elements, and computing averages. When working with a list or tuple of numbers, use a combination of for-expressions and numeric functions.

Convert values to their absolute (positive) form

Iterate with a for-expression and convert each element to its absolute value so all entries are positive before further calculation. Conceptually:

  • positive_costs = [for cost in var.monthly_costs : abs(cost)]

Sum, max, min, and average

After converting values to numbers, use sum() to get the total, max() and min() to find extremes, and compute the average as total divided by number of elements (length()). When calling functions like max() or min() on a list, expand the list into individual arguments (spread semantics) if the function expects separate parameters.

Timestamps and formatted names

Use timestamp functions to generate time-based identifiers or filenames. The pattern is:

  • timestamp() to get the current timestamp (unknown until apply when creating resources).
  • formatdate(format, timestamp) to format it into human-readable strings such as yyyy-MM-dd or custom patterns.

Combine a formatted timestamp with a prefix to create deterministic names, for example: backup-2025-03-12.

File handling: read and decode configuration files

Terraform provides file helpers to read local files and parse structured data.

Check file existence

Use a file-existence check (for example fileexists(./config.json)) before attempting to read. This prevents runtime errors when the file is optional.

Read and decode JSON

Read a file with a function like file() and decode JSON with jsondecode(). A conditional expression helps return parsed data only when the file exists:

  • config_data = fileexists(path) ? jsondecode(file(path)) : {}

This pattern keeps locals robust and avoids failing plans when the configuration file is missing.

Practical testing tips

  • Run terraform plan to see validation messages and unresolved values such as timestamps marked as "known after apply".
  • When a validation fails, Terraform prints the exact file and line number for quick debugging.
  • For sensitive outputs, you may need to annotate both the input and output as sensitive to avoid plan-time exposure.

Diagram:



Key takeaways

  1. Validation prevents incorrect inputs early and improves module reliability.
  2. Type conversion transforms data shapes (lists to sets) to get the behavior you expect, such as removing duplicates.
  3. Numeric processing often requires converting each element before aggregation; use for-expressions plus sum/min/max functions.
  4. Timestamps and formatdate help create readable, time-based identifiers for resources and backups.
  5. File functions let you incorporate local JSON/YAML configuration safely with file existence checks and decoding.

Try these patterns in real Terraform modules: validate inputs, transform lists into the correct types, convert and aggregate numerical data, append timestamps to names, and safely read configuration files. These small techniques build more predictable, maintainable infrastructure as code.

Here is my repo link: https://github.com/Mo-Adnan-Mo-Ayyub/Aws-with-Terraform/

Here is the session link:


Comments

Post a Comment

Popular posts from this blog

AWS with Terraform (Day 01)

Image
  Terraform Fundamentals – Day 01 (My Learning Notes as a DevOps Engineer) Today I wrapped up Day-01 of my Terraform with AWS series, and even with my DevOps background, this session helped me tighten my fundamentals and rethink how I approach cloud provisioning. Terraform is something I’ve used before, but today was more about understanding why IaC matters at scale and why Terraform continues to dominate in real-world DevOps ecosystems. Understanding Infrastructure as Code (IaC) As a DevOps engineer, IaC is not new to me. But today’s session broke it down in a way that clarified its real value. IaC = Infrastructure represented as code. Instead of building resources manually through AWS/Azure/GCP consoles, we define everything in .tf files. This ensures our setup is predictable, repeatable, and version-controlled. What I liked most is how clearly the contrast was shown: Cloud-Agnostic Tools (Terraform / Pulumi) Work across AWS, Azure, GCP, Kubernetes, GitHub, etc. ...
Read more

AWS with Terraform (Day 02)

Image
  AWS with Terraform – Day 02 Deep Dive into Providers, Versioning & the Real “Bridge” Between Code and Cloud Today’s session took me from simply writing Terraform code to actually understanding the engine behind it — the Provider layer . And honestly, once this clicks, Terraform stops feeling like just a tool and starts feeling like a real engineering system. Here’s what I learned and how I’ve started applying it. Providers: The Plugin That Makes Terraform Real The simplest way I now understand it: Terraform writes the story. Providers translate it into cloud actions. Before today, I treated the provider block as just two lines of mandatory code. Now I see it as the translator that turns HCL into actual AWS API calls . Example: I write: resource "aws_s3_bucket" "demo" { bucket = "my-app-demo" } The AWS provider turns that into the exact S3 API request. This layer saves us from manually hitting APIs, building payloads, or juggling ...
Read more

AWS with Terraform (Day 06)

Image
Mastering Terraform File Structure: Best Practices for Scalable AWS Infrastructure as Code You've built your first AWS resources with Terraform in one big main.tf file. It works fine at first. But as your project grows, that single file turns into a mess. Resources pile up. Variables hide in plain sight. Debugging takes forever. Good news. You can fix this now. Split your Terraform files the right way. Follow HashiCorp's tips for a clean setup. This boosts readability. It helps teams work together. Plus, it scales for big AWS setups like VPCs, EC2s, and S3 buckets. Stick with me. You'll see hands-on steps to organize your root module today. The Anatomy of a Well-Organized Terraform Root Module The root directory acts as your Terraform project's heart. It's the root module. Here, you keep all key files. No strict rules exist for names. But smart choices make life easier. Start simple. Break one fat main.tf into focused files. This stops resource clutter. You n...
Read more