DEV Community: William Collins

Using Terraform Import Blocks with Alkira

William Collins — Thu, 13 Jul 2023 16:37:12 +0000

For many moons, importing existing infrastructure (that is to say, infrastructure running outside of Terraform state), has not been a trivial task. Historically, Terraform did not generate any configuration. You would have to write the infrastructure-as-code in a manner that reflects how it was deployed. Then, to make matters not easier, you would fetch the 'ol shovel and dig out the unique resource identifiers to feed through the command line. Handling a single resource in this manner is pretty simple. Wrangling 20+ resources like this is not. Last month, Terraform v1.5.0 was released, offering the ability to use import blocks. Let's test this new feature on my favorite infrastructure provider, Alkira.

Why is this Useful?

This feature shifts import from a CLI driven approach to configuration-driven and plannable actions for adopting existing resources. Here are the key takeaways:

Configuration-Driven: You can now declare imports within your Terraform configuration files using an import block, making the process more streamlined and part of the initial planning.
Plannable Action: Terraform treats importing as part of a standard plan. Running terraform plan will show a summary of the resources that Terraform intends to import, along with other planned changes.
Preservation of existing CLI command: The existing terraform import CLI command remains unchanged and can still be used separately.
Support for Generating Configuration for Imported Resources: This feature, used in conjunction with the import block, enables templating of configuration when importing resources. A new flag -generate-config-out=PATH is added to terraform plan. When this flag is set, Terraform generates an HCL configuration for any resource included in an import block that doesn't already have an associated configuration, writing it to a new file at the specified PATH.

A Common Scenario

In this scenario, I'll build an AWS VPC and connect it to Alkira using the alkira_connector_aws_vpc resource. This is a pretty common scenario I see with our customers. They begin a proof-of-concept for a particular use case and do most of the testing via Alkira's excellent user interface. Instead of building a new environment for production however, a lot of times, they will want to take the proof-of-concept to production. From here, they need to import what has already been built into the appropriate Terraform State file.

Building some Infrastructure

I'm going to mock-up the infrastructure we will import using Terraform.

Importing that Infrastructure Somewhere Else

Now that we have some infrastructure to work with, along with the resource identifiers, let's put import blocks to the test. First, we create an import block for the Alkira connector in a file called imports.tf in a separate directory. I defined the connector_id returned from the previous configuration into a new variable called var.connector_id:

Next, we initialize this separate directory containing the new Terraform configuration. Once everything is initialized, we can run -generate-config-out=main.tf which generates the following:

Conclusion

This is a great feature that saves time. If I had to guess, as more functionality and polish is added, you'll see modules popping up that leverage import blocks and provide a simplified way to import larger swaths of infrastructure. Some tools exist out there to do this today. Last year, I wrote about one such tool - Azure Terrafy. The difference is that since this is now integrated with the Terraform configuration and planning process, it can keep all of the logic in the HashiCorp ecosystem. No messing around with fetching binaries or needing to do any third-party tricks.

AWS DC Summit - Recap

William Collins — Tue, 20 Jun 2023 18:57:49 +0000

What fits somewhere in between re:Invent and Community Day events? That would be the AWS Summits! This year, I got to experience a double dose of fun by representing Alkira at our booth and presenting at the AWS Community Developer Lounge. I may be biased, but I believe the Alkira team is the best in the world.

It was a blast getting to talk about cloud networking with event attendees while getting a glimpse of how the public sector is adapting to change. And, for my first time presenting at a Summit, I thought it fitting to do a live demo. Why not pull in some advanced concepts and do it all live with semi-flaky internet and see how it goes? Leeroy Jenkins would be proud.

Highlights

My favorite highlights included:

Team Alkira

Whether it was the many engaging conversations we had with event attendees at the booth, the unplanned team-building exercise of scooting through the D.C. bike lanes or seeing the Washington Nationals get smashed, I wouldn't pick any other team to do it with. What made this event great was the fantastic questions we got from event attendees. As it turns out, great questions lead to great conversations!

Keynote

At the keynote, we got to hear from the CIA's first CTO, Nand Mulchandani. Keeping your ears open will teach you something new every day. For me, it was that researchers at the CIA created the lithium-iodine battery. I guess this shouldn't come as a surprise, given the need for long-lasting battery power and the nature of surveillance.

Modular Data Center

Back in February AWS announced their Modular Data Center for U.S. Department of Defense Joint Warfighting Cloud Capability. This only available to government customers under the JWCC Contract and is currently supported in the AWS GovCloud (US-West) and (US-East) regions.

You could rely on limited infrastructure. You could also procure, build, and provision infrastructure yourself. Why not just deploy a self-contained and modular data center? In isolated environments, it can securely store, analyze, and interpret petabytes of data in real-time. I got to walk through one of these at the summit and my nerd senses were tingling.

Snowblade Announcement

Want compute and storage amongst other hybrid services in remote locations, including Denied, Disrupted, Intermittent, and Limited (DDIL) environments? If you are a (JWCC) contract customer, take a look at AWS Snowblade. This tech extends AWS infrastructure to the tactical edge and meets U.S. Military Ruggedization Standards (MIL-STD-810H). Snowblade is available in the AWS GovCloud (US-West) region.

Presenting in the Dev Lounge

Through the amazing AWS Community Builders program, I got to present in the Dev Lounge. Many folks wanting to enter tech seem to go the software engineering route by default. Serverless and AI/ML are also newer and much more shiny than networking. Throughout my time in tech, there appears to be a waning interest in network engineering.

One of my goals in the community is to show that networking is equally exciting in the cloud, especially when paired with awesome tools like Terraform. In this Dev Chat, I started with some theory and real-world problems and then ran a live demonstration on how you could solve some of those problems by combining the power of AWS Transit Gateway and Terraform. The slides and code I ran for the demo can be found here.

Properly designed and executed network and security is the solid foundation on which many of the newer and trendy technologies run atop. If you drive a Ferrari, you can reach your destination quickly (I wish I had a Ferrari). If the highway isn't in place, however, and you were driving on rugged terrain, can you imagine what the experience would be like? Imagine also if an optimal interconnection of highways didn't exist between you and your destination.

Conclusion

This AWS Summit was a whirlwind of learning, engagement, and networking - literally and figuratively! Representing Alkira and having the opportunity to educate attendees on our product led to many deeper discussions around the state of networking in the cloud. It was a blast to discuss cloud networking, interact with various individuals, and offer a different perspective on a field often perceived as a thing I want to get out of the way.

Can ChatGPT Terraform Simple Networking In AWS?

William Collins — Wed, 29 Mar 2023 12:42:54 +0000

Usually, when it comes to technology, my grandmother doesn't know much because she doesn't care. What is the cloud? How to install a new browser on her laptop? What is 2FA? I might be speaking French to her as I discuss these things. Yet, she knows what ChatGPT is. This shows the vast amount of publicity, hype, and polarization that has ensued since November 2022. I tend to avoid AI fear-mongering and focus more on, how could a tool like this help enhance my daily grind? Can ChatGPT write Terraform as elegantly as a poem written from the perspective of Samuel L. Jackson in Pulp Fiction? Let's take it for a spin on AWS using infrastructure-as-code.

Create a VPC and Two Subnets

Let's ease in gently. Just like when my wife says she is making cookies, I tell myself I will keep things simple and only have one. My first request for ChatGPT is a simple one: Create a VPC and two subnets in AWS using Terraform.

Observations
That was pretty seamless. I provided little detail in my first request, but ChatGPT filled in all the required arguments added tags for the Name of each resource, and even put my subnets in separate availability zones.

Does it Work?

Whenever the cookies come out of the oven, I am overcome with a sense of responsibility to test them out before anyone else eats any (maybe I run this test 3 or 4 times depending on the cookie). Like those cookies, ChatGPT isn't getting any favors from me. Let's test:

Updating our Request

I'm always down for a good conversation when I'm eating cookies. Let's talk a little more to ChatGPT and request an update to our Name tags for our resources:

Captivating Conversation
Asking ChatGPT to update Name tags was successful. Not only did I get the updated code, but comments were added to the code file to show what changes were made. This conversational style is very intuitive. If I don't get what I need, or maybe the output clues me into something additional I need to add, I need but ask. This generative pretrained transformer is starting to win my heart over, just like cookies do.

Going Beyond Basics

At some point (usually around Christmas / New Year's), I realize I have been eating way too many cookies. The cookies have failed me. Let's add more logic to see if ChatGPT fails me too. Since ChatGPT offered up handling availability zones without me asking, let's see what happens if I throw the count Meta-Argument in the mix?

Too Many Cookies
Anyone who has spent time writing Terraform would likely have spotted the problem before running the code. The 'count' Meta-Argument in Terraform works using an incrementing counter. With ChatGPT knowing all the "answers" and providing the availability zones as part of the configuration, it also decided to increment them in the same manner used with cidr_block and Name tag. Using this logic, it produced us-east-11, us-east-12, and us-east-13 which are not availability zones in AWS, thus causing my configuration to crash and burn. Time to go on a diet?

Conclusion

It is hard not to be impressed. The value goes beyond simply providing lines of code. With each update to my request, ChatGPT provided a clear explanation as to why it modified the logic in the manner that it did. Since I began experimenting in January, I have found many ways to get ChatGPT to produce wrong (sometimes laughable) code or configuration. Network gear, general-purpose programming, and infrastructure-as-code are complex things, though. Numerous complications, variables, versioning, and interpretation require adjusted expectations.

Evolution of AWS Site-to-Site VPN - Part 2

William Collins — Mon, 06 Feb 2023 13:01:59 +0000

In Part 1, we talked about the origins of the Site-to-Site VPN Service in AWS. As consumers began to scale in the early days, they faced tunnel sprawl, performance constraints, and the need for a simplified design. AWS responded with Transit Gateway. How did Transit Gateway simplify architecture leading to smoother operations, better network performance, and a scalable blueprint for the future network?

Pre Transit Gateway

Security teams in the early days would often balk at the idea of using VPC peering without having a centralized transit hub (where the hybrid connectivity was landed). Since VPC couldn't do any advanced packet forwarding natively, many designs would do transitive routing on the customer gateway. Traffic patterns looked something like this:

Observations

In this design, the tunnels exist from the customer gateway all the way to the VPC. In this one-to-one relationship, there is no intelligent way to manage the complexity of incremental connections as you grow. Traffic also exits AWS even when the destination is another VPC which is inefficient. Also, since one tunnel is actively forwarding traffic at a time, you are limited to ~ 1.25 Gbps.

Transit VPC

To solve some of the shortcomings with VPC peering and tunneling to each VPC directly, Transit VPC was born. This solution deploys a hub-and-spoke design that reminds me of my data center networking days when we connected sites to data centers with all the glory of active/standby and boxes everywhere. Want to connect another network? Deploy another few boxes! Sometimes this is unavoidable, but any opportunity I get not to manage additional appliances or agents, I take it.

When I prototyped this design for the first time, we used Cisco CSRs deployed in a Transit VPC. This acted as the hub, and each spoke VPC's VGW had two tunnels to the CSRs with BGP running over IPsec. Since VGW doesn't support ECMP, this gives us active/standby out of the box. This design does perform transitive routing in the hub which keeps spoke-to-spoke traffic in the cloud.

Appliance Sprawl

In this design, you are responsible for provisioning the appliances (across multiple availability zones in a given VPC). This means you have to do the routine software upgrades along with the emergency firefighting when new CVEs are uncovered. Also, running this design at scale is problematic. As the number of VPCs grow, the number of appliances grow. Imagine the above diagram with 60 VPCs attached.

Enter Transit Gateway

AWS Transit Gateway (TGW) works as a managed distributed router, enabling you to attach multiple VPCs in a hub + spoke architecture. These VPCs have reachability to each other (with the TGW doing the transitive routing). All traffic remains on the global AWS backbone. The service is regionally scoped; however, you can route between transit gateways in different AWS regions using Inter-Region Peering.

You connect various network types to TGW with the appropriate attachments. The various attachment types can be found here. Since we are talking about the evolution of site-to-site VPN design, we would use the TGW VPN Attachments to terminate our VPNs and TGW VPC Attachments for connecting VPCs.

Simplified Connectivity

Keeping things simple has a lot of benefits. This includes reducing the number of tunnels you have to manage while getting more from them. Sometimes you find that less is more, especially knowing that someone has to do operations!

Ludwig Mies van der Rohe

Ludwig was a German-American architect who adopted the motto less is more to describe the aesthetic of minimalist architecture. In the network, a design should be as simple as possible while meeting requirements.

When using Virtual Private Gateway (VGW), we know the tunnel spans from the customer gateway to redundant public endpoints in different AZs. With this new design, tunnels would land directly on the transit gateway. This also enables us to leverage a single VPN connection for all of our VPCs back to on-premises. We can also use ECMP to aggregate the bandwidth of both tunnels in the connection.

Accelerated Connections

When using transit gateway, you can enable acceleration when adding the TGW attachment. An accelerated connection uses AWS Global Accelerator to route traffic from your on-premises network to the closest AWS edge location. Your traffic is then optimized once it lands on AWS's global network. Let's examine using acceleration with TGW versus no acceleration with VGW:

When to Accelerate

If the sites being connected are close to a given AWS region where your resources exist, you will see similar performance between both of these options. As distance increases, additional hops over the public internet are introduced, which can increase latency and impact reliability.

This is where acceleration shines. It works by building accelerators that enable you to attach redundant anycast addresses from the edge network. These addresses act as your entrypoint to the VPN tunnel endpoints and then proxies packets at the edge to applications running in a given AWS region.

How much improvement?

AWS boasts up to 60% better performance for internet traffic when using Global Accelerator. You can learn more about how this is accomplished along with the criteria for measurement here.

Conclusion

Understanding your organization's goals and how the network needs to support them is no trivial task. This is where "it depends" rears its proverbial ugly head. In the world of cloud networking, complexity, data transfer, and compounding cost, it pays to think through the design and weigh the trade-offs. One thing is certain -- AWS's site-to-site VPN and other adjacent services have evolved, providing the means to construct high-performing networks with a global scale and amazing user experience.

AWS re:Invent 2022 - Recap

William Collins — Tue, 06 Dec 2022 14:20:08 +0000

As far as tech conferences are concerned, it's hard to find one as exciting as AWS re:Invent. Whether it's anticipation for new product announcements or connecting in person with the community, there is something electrifying about being at ground zero. And if you can make the trip, you will get a lot of great exercise too! I hit close to 100K steps or approx. 43 miles according to my Fitbit. What were some of my favorite highlights from re:Invent 2022?

Community

Jason Dunn put on a spectacular event for the AWS Community Builders. Intros were made to various members of the AWS team, community managers, topic leaders, developer advocates, and DevRel leadership. Even the legend, Jeff Barr, was there. The food was hot, the SWAG was hotter, and the conversation and networking was off the chain. These types of events are where major opportunities happen. Want to become a Community Builder? Check out our page.

Attendance

There were over 60K in attendance this year, and all the sessions I attended were excellent. You can find most of the events already available on the AWS Events YouTube channel.

Network Announcements

My favorite category, Networking & Content Delivery, saw a few new product launches. Let's dig in!

VPC Lattice

Want consistent network policy and traffic management across instances, containers, and serverless? A new full managed service called VPC Lattice is now in preview. This feels like a service-mesh "lite" aimed at scaling service-to-service connections while incorporating some zero-trust. Having visibility into service-to-service interactions is important.

Pricing

VPC Lattice Pricing is broken down into three components that ultimately decide how much that final bill will increase.

Per hour charge for each running service (that runs on instances, containers, or serverless). The price will differ per region, but for US East it is $0.0250/hr
Per GB charge for each gigabyte of data running through each service. Again, the price for US East is $0.0250/GB
Requests made to to each service are priced at a $0.10 per 1 million requests rate. You begin getting charged once you exceed the always free tier

Services are heavily restricted and controlled during Preview periods. VPC Lattice is only available in US West (Oregon) as of right now. You can get on the waitlist here. Preview is available for up to 5 AWS accounts at a time.

Verified Access

VPNs are getting a lot of hate these days, and ZTNA products are getting a lot of love. I'm not surprised to see AWS release Verified Access for secure access to corporate applications. Like the bulk of ZTNA products on the market today, Verified Access uses conditions based on identity data and device posture for application access.

Pricing

Verified Access is broken down into two components that make up the final bill.

Application Hours is an hourly charge for associated applications, which comes in at $0.27/hr for 1-148800 app-hours. If you surpass 148800 app-hours, this is reduced to $0.20/hr. Each partial application hour is rounded up and billed for the whole hour.
GB of data processed is a $0.02 per GB charge that gets processed for all data flowing between users and applications while using the service.

Visit Service Terms to learn more about the terms and conditions for all release types. Remember, Preview releases are not intended for production! You can check here to see if new services are available in a given region.

Other Big Announcements

This year seemed bigger than ever, and if I had to pick one category that commanded a lot of attention, it was data management. Nobody says this as elegantly as the CEO:

Adam Selipsky
"To unlock the full power, the full value of data, we need to make it easy for the right people and applications to find, access and share the right data when they need it — and to keep data safe and secure."

DataZone

DataZone aggregates data sources, sets up a data catalog of sorts, and allows you to define a taxonomy. You can then govern access to data in one place. Let's face it, data is heavy, hard to manage, and time-consuming to make sense of. Anything that streamlines and simplifies administration is winning.

Security Lake

Wherever there is data, security is not far behind. What happens when you combine data lakes and security? You get a purpose-built data lake for security-related data and name it Security Lake. On the surface, this looks pretty valuable as it appears to aggregate data from the cloud and on-premises security infrastructure and solutions and normalize it with the Open Cybersecurity Schema Framework (OCSF). In this long history of security and data, gathering tons of data was never a problem. Normalizing, understanding, and contriving value is.

CloudWatch - Internet Monitor

CloudWatch got a new feature called Internet Monitor which enables you to continually monitor internet availability and performance metrics. The monitoring happens through your VPC, CloudFront distributions, and Workspaces directories. The goal is to arm operations with insight into how internet issues impact the performance of applications hosted in AWS and end-users accessing those applications.

Conclusion

As always, re:Invent did not disappoint. There was a lot of post-pandemic excitement that was pretty contagious, and it was great to catch up with folks I hadn't seen in a while or had never met in real-life. When you get that many builders together, you know some magic is bound to happen.

Evolution of AWS Site-to-Site VPN - Part 1

William Collins — Tue, 22 Nov 2022 15:25:03 +0000

The necessity for protocols to keep communication secure has been around since the dawn of the internet. The first ever VPN was jointly developed by a vendor consortium (which included Microsoft) in 1996, and came in the form of Point-to-Point Tunneling Protocol. Although many are skeptical about the value of VPNs in 2022 and beyond, customer consumption of cloud provider VPN services have paved the way for additional features and exponential scale.

What impact do innovations like Transit Gateway and Accelerated VPN Connections have on design complexity, network performance, and operations? In this blog, I will look back at the first time I deployed a site-to-site VPN and then examine what is possible today when thinking through network design. This is going to be two parts.

My First Experience

Site-to-Site VPN in AWS is a fully managed and highly available service. This comes in the form of two endpoints on the AWS side (public IP addresses in different AZs per one VPN connection). This service is charged hourly per connection (plus data transfer charges). My first experience connecting on-premises to AWS looked something like this:

This was long before the public cloud had disrupted enterprise infrastructure. In this case, we had a single VPC that required connectivity back to on-premises. Since the application being developed wasn't production, we set up a single VPN connection to a single physical router in the Data Center. This was easy work since, as network engineers, we pushed VPNs like weights. And we had an existing B2B process in place, so our paperwork + process was ready. Somewhere along the way, though, this application went into production.

Making it Highly Available

Pre Transit Gateway, you would typically see a Virtual Private Gateway and VPN connection from each VPC back to on-premises devices. If you follow best practices and want the highest availability possible in this scenario, you will also have redundant devices on-premises. This means you would end up with 2x VPN connections, which totals 4x VPN tunnels per VPC. Once the application went past QA, to meet our requirements for Tier 0 infrastructure, we needed high availability.

Traffic Forwarding

One question I could always count on getting from developers when we would onboard this design was: "Since we have four tunnels here, why can't we forward traffic on all of them?" The simple answer is that you can override defaults and forward traffic across all tunnels to AWS from on-premises; however, the VGW will always select a single tunnel for return traffic.

Growth, Scale, and Operations

At some point, Digital Transformation (you may have heard of it) caused crazy fast growth. And with that growth came more VPCs. And with those VPCs came the necessity for connectivity back to on-premises. Say we add just two additional VPCs using the above methodology, and we end up with 6x VPN connections, bringing us to 12x VPN tunnels to manage.

How much growth?

The above example is single region with only 3 VPCs. The reality for many organizations using AWS is much larger. What would this design look like if we had 50 VPCs? What happens when we need to include multi-region for DR capabilities? How does it impact operations when an application has performance issues, and the network is getting blamed?

Conclusion

As we onboard more VPCs, it becomes apparent that the above design does not easily scale. Bandwidth is limited, tunnels increase exponentially, and operations will have limited success in diagnosing network problems (or proving the network is not the problem). In Part 2 we will dive into how Transit Gateway and Accelerated VPN Connections take this from an operational misstep to an enterprise success story.

Calculating Cost like a DevOps Boss with Infracost and AWS

William Collins — Wed, 05 Oct 2022 11:59:05 +0000

Blowing out cloud spend is an easy thing to do. This McKinsey Report notes that 80% of enterprises consider managing cloud spend a challenge. I recently presented at the Cloud Security Alliance in Kansas City and had the opportunity to network with some tremendous DevOps and Security professionals. One excellent side conversation somehow transitioned to a deep discussion on better ways to understand cost implications in the era of infrastructure-as-code. Shouldn't cost be someone else's problem?

Cost is a Shared Responsibility

As many organizations continue shifting workloads to the cloud, the cost impacts the bottom line. The responsibility of cost-management now transcends the CIO and accounting straight down to individual engineers. If this sounds scary, fear not. It is an incredible opportunity in the making.

Where do Engineers Work?

Engineers do not work in spreadsheets, nor do they work with accounting software. Most software engineers work day-to-day in version control. Furthermore, the centralized teams managing cloud infrastructure more broadly live in this world as well. Version Control often employs an approval process before a pull request is merged, and infrastructure is provisioned. What if you could see the cost impact right here? Yes, right where you, the engineer live? This is what Infracost does.

Prerequisites

First, follow the instructions found here to download and authenticate Infracost. This includes creating an org inside the platform, which is where you can fetch the API key. Then we need a quick way to spin up some small AWS instances and then quickly dial them up to more expensive options.

AWS Configuration

I'll be using the following Terraform configuration to build the AWS infrastructure. I'll keep the dynamic portions of the configuration in a separate locals block so we can easily adjust for testing.

Let's Test via CLI

First, let's do a terraform plan against the following criteria:

Running a Cost Estimate

Now, let's run a cost estimate with Infracost and provision an instance:

Once this is done, we can check out the results on the Infracost portal:

Running a Cost Diff

Bigger and more expensive is better, right? Let's update our configuration with a few changes. Let's switch that t2.micro to an m5.24xlarge, and let's see how much it would cost to provision four of them:

This time, we will tweak the command to generate a diff:

Once we navigate back to the portal, we can see the cost change. I have gone from a monthly cost of $9.27 up to a panic-inducing $13,449. Maybe I don't need the m5.24xlarge instances for this testing!

Testing with GitHub Actions

In the spirit of shifting-left, let's have a go with GitHub Actions running against every pull request. A lot of spending happens outside production, so this is an excellent way to control spending right at the source. If something doesn't get deployed, it can't cost you anything.

GitHub Actions Workflow

By default, it will execute the typical Terraform init and plan. Then it will run terraform show -json plan.tfplan and save the output to plan.json. Then, Infracost can run its calculations. This will be populated in the conversation log along with everything else being tested as part of the pipeline.

Creating a Pull Request

Once we create any pull request, the workflow will run and populate the cost details. At this point in the workflow, multiple approvals can be added. Three sets of eyes are better than one when spending so much with the click of a button! You can find the supported CICD platforms in the Infracost documentation.

Conclusion

Understanding TCO in the cloud is a deep topic that spans a whole organization. It can be easy to keep provisioning EC2 instances when you are disconnected from the cost. The ability to see the cost in the pipeline is a fantastic way to practice due diligence on the technical side of responsibility.

Arming engineers with the right tooling and knowledge will help drive cost-conscientious decisions. Small steps like this, along with driving continuous governance strategically, are significant steps in getting control of cloud spend.

The Best Terraform Feature Yet?

William Collins — Tue, 06 Sep 2022 14:36:11 +0000

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:

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.

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:

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:

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

Test it Yourself!

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

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.