DEV Community

William Collins for AWS Community Builders

Posted on • Originally published at wcollins.io

3

The Best Terraform Feature Yet?

Optional attributes for object type constraints is almost here! I've been waiting for this feature to come along for a while. I have tested it extensively in -alpha, and I can confidently confirm that it is a game changer. This feature is long in the making, being discussed as far back as this thread in 2018. Today, it is now in beta, so the official release could be any day now. Let's demonstrate how this is useful and build some common AWS infrastructure.

Why it is Useful

Before this feature, you could resort to using tricks to make arguments in object variables optional. This usually included providing a null value for optional parameters and then doing some fancy lookup or conditional like so:

variable "some_var" {
type = object({
name = string
description = string
}
default = {
name = "william",
description = null
})
}
locals {
description = lookup(var.some_var, "description", "no_description") == "no_description" ? null : var.some_var
}

Now, we can make that individual attribute optional without any hackery involved. The first thing to know here is that when setting optional(string) without a default value as shown below, the default value is null.

variable "some_var" {
type = object({
name = string
description = optional(string)
})
}

While having the default value automatically set to null is helpful, it only solves half of the problem. What happens if we have a scenario where we still want to provide a value in the logic, even if one isn't supplied at runtime? Then we can set a default value with a second argument like this:

variable "some_var" {
type = object({
name = string
description = optional(string, "Can't stand Monopoly")
})
}

Building some Infrastructure in AWS

This feature comes in handy when building complex data types. Let's look at something as simple as building an AWS VPC. Your organization could be using VPC IPAM but may still need the option to pass in custom CIDRs at runtime. Or, other standard defaults may need to be set if not provided at runtime. Take the following example:

variable "vpc" {
description = "Default VPC object"
type = object({
name = string
cidr_block = optional(string)
ipv4_ipam_pool_id = optional(string)
ipv4_netmask_length = optional(number)
enable_dns_support = optional(bool, true)
enable_dns_hostnames = optional(bool, false)
instance_tenancy = optional(string, "default")
})
}
view raw variables.tf hosted with ❤ by GitHub

If only the cidr_block attribute is provided at runtime, then the IPAM attributes will be nullified. This simplifies our resource configuration as follows:

resource "aws_vpc" "vpc" {
cidr_block = var.vpc.cidr_block
ipv4_ipam_pool_id = var.vpc.ipv4_ipam_pool_id
ipv4_netmask_length = var.vpc.ipv4_netmask_length
enable_dns_support = var.vpc.enable_dns_support
enable_dns_hostnames = var.vpc.enable_dns_hostnames
instance_tenancy = var.vpc.instance_tenancy
tags = {
Name = var.vpc.name
}
}
view raw main.tf hosted with ❤ by GitHub

Test it Yourself!

Want to start testing? Grab v1.3.0-beta1 and setup your versions.tf like this:

terraform {
required_version = ">= 1.3.0"
experiments = [module_variable_optional_attrs]
}
view raw versions.tf hosted with ❤ by GitHub

Conclusion

AWS VPC is a simple example. This feature really shines when building reusable infrastructure-as-code for Network Firewall or even Network ACLs. Anything that simplifies something and reduces or eliminates any hacks required to reach a logical outcome is super valuable. Great work finally driving this one home HashiCorp.

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read more →

Top comments (0)

Best Practices for Running  Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK cover image

Best Practices for Running Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK

This post discusses the process of migrating a growing WordPress eShop business to AWS using AWS CDK for an easily scalable, high availability architecture. The detailed structure encompasses several pillars: Compute, Storage, Database, Cache, CDN, DNS, Security, and Backup.

Read full post