Rory  West

Rory West


Terraforming on AWS with Modules

In this article, I will cover Terraform Module composition by provisioning EC2 instances on AWS. Module composition in terraform will help to arrange the configuration in a hierarchical structure rather than a normal flat structure. Each set of configuration/resources will be grouped into a module that can be invoked from root or child modules.

A simple modular structure would look something like below.

#cloud #cloud-computing #aws #terraform

What is GEEK

Buddha Community

Terraforming on AWS with Modules
Ruby  Schmitt

Ruby Schmitt


Terraform: Iterating through a Map of Lists To Define AWS Roles and Permissions

A few months ago, I was working on a Terraform module to manage all the roles and their permissions in our AWS accounts. This on the surface seems like a straight forward project, but there was a curveball that required some research, trial & error, and finesse to address.

The teams/permissions were not consistent across the AWS accounts. TeamA might have read/write access to s3 in account A, but only have read access to s3 in account B. Team A does not even exist in account C. Multiply this conundrum by 10+ teams across 10+ accounts.

In thinking about how to best tackle this issue, there were a couple bad ways to solve this that immediately come to mind:

  • Brute force — define the permission for every team in every environment.

This approach is horrible. It would have been tedious, hard to maintain, and the amount of repeated code would have been astronomical, but it would have worked.

  • Ask the business to standardize permissions.

This on the surface seems reasonable but it is not. First, your code is dictating business logic/function. Secondly, the principle of least privilege means that you should only allow enough access to perform the required job. Third, there are AWS accounts which certain teams should not have access to (e.g. secops, networking, & IT accounts). Last, the business would never agree to it.

The right approach needed to something that could account for all the variability across the accounts. Additionally, the end result needed to be clean, easy to maintain/update, and easy to use without requiring a deep understanding of how the module worked.

What I envisioned was something that allowed me to define the permissions as part of the config. This design addressed the variability issues across the accounts by allowing me to define the permissions per iteration of the module. Additionally, it was easy to understand and manage (even if you didn’t know what the module was doing).

This looked something like:

module usermap {
  source = "../modules/example-module"

  role_map_aws_policies = {
    TeamA = ["AdministratorAccess"]
    TeamB = ["AmazonS3FullAccess", "AmazonEC2FullAccess"]
    TeamC = ["AdministratorAccess"]
    TeamD = ["ReadOnlyAccess", "AmazonInspectorFullAccess"]

#aws #aws-iam #automating-aws-iam #terraform #terraform-modules

Rory  West

Rory West


Why Terraform? How to Getting Started with Terraform Using AWS

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

Traditional Infrastructure vs Modern Infrastructure

Traditional Infrastructure

  • Mutable
  • Operational Complexity
  • No Central Control on Infrastructure

Modern Infrastructure

  • Immutable
  • Less Operational Complexity
  • Faster time to the market
  • single point for state management

#terraform-aws #terraform #aws #aws-ec2

Rory  West

Rory West


Complete Guide to Terraform AWS

We’re continuing our series on Terraform AWS with a post that breaks down the basics. The world of Terraform AWS can be described as complex — from AWS storage to AWS best practices, there’s a depth of knowledge necessary to get familiar with Terraform AWS.

Whether you’re an expert at Terraform AWS or just getting started, it’s our goal at InfraCode to provide you with clear and easy-to-understand information at every level. The number of resources out there is abundant but overwhelming. That’s why we create simplified guides that are immediately usable and always understandable.

In this article, we’ll dive into:

  • A Beginner’s Overview to Terraform AWS
  • Managing AWS Storage
  • Terraform AWS Best Practices

#aws-ec2 #aws #terraform #terraform aws

Lindsey  Koepp

Lindsey Koepp


Terraform Imports: Resources, Modules, for_each, and Count

If you are developing Terraform you will at some point work with Terraform imports. A simple web search yields plenty of results for simple imports of Terraform resources. However, often missing are some of the more complex or nuanced imports one might encounter in the real world (such as importing modules or resources created from for_each and count).

This guide will quickly cover the generic examples you find easily on the web, focus on some more unique stuff usually hidden in forum posts, and provide a handful of techniques I’ve picked up since Terraform imports became a functionality.

This guide assumes the reader has a good understanding of Terraform, Terraform modules, state file manipulation, and CI/CD. I’ll be using AWS for the examples.

Resource Import

This is perhaps the most prevalent example when searching for Terraform imports. Quite simply you have a resource defined in your Terraform code, some infrastructure out in the environment matching your Terraform resource definition, and you want to import that infrastructure into your Terraform state.

This example is for an aws_iam_user. I’ve already created a user named “bill” via the AWS IAM console and I would like to import this user into my Terraform state. Easy enough!

My Terraform code:

resource "aws_iam_user" "bill" {
  name = "bill"
  tags = { "foo" = "bar" }

A simple command:

$ terraform import aws_iam_user.bill bill

#aws #terraform-import #infrastructure-as-code #terraform-modules #terraform

Kole  Haag

Kole Haag


Using Terraform to Create an EC2 Instance With Cloudwatch Alarm Metrics

Hey guys! I wanted to do a quick tutorial on how I created an EC2 module for Terraform. If you want to see the repository it is located in check it out here. This module will do a few things:

  1. Create an EC2 Instance
  2. Automatically look up the latest Windows Server 2019 AMI for the EC2 instance.
  3. Create and attach a additional drive.
  4. Create a Cloudwatch Alarm Metric to monitor CPU.

The folder structure looks like this:

Image for post

First things first… I created the file which contains all of my configuration except for the variables and outputs. The has a few parts to it.

AWS Instance Code

The first section is the instance resource code

#AWS Instance

resource "aws_instance" "example" {
     ami =
     instance_type = "t2.micro"
     availability_zone = var.availability_zone

You will notice a few things here.

  1. The instance type is set in the module to t2.micro
  2. availability_zone is set using a variable
  3. ami is set using data

We will get the the availability zone piece in just a bit, first we are going to tackle the data used for the ami argument.

Data for AMI Using a Filter

The next bit of code for the filter looks like this

#AMI Filter for Windows Server 2019 Base

data "aws_ami" "windows" {
     most_recent = true
     filter {
       name   = "name"
       values = ["Windows_Server-2019-English-Full-Base-*"]
     filter {
       name   = "virtualization-type"
       values = ["hvm"]
     owners = ["801119661308"] ## Canonical

The argument most_recent is set to true. This means that it will grab the most recent AMI that fits the criteria that we specify in our filter.

Next you will notice that in the name we set the value to *Windows_Server-2019-English-Full-Base- **with the star at the end. This lets Terraform know we don’t care about what text comes after that point and it was done because the standard format puts the date there. If we set the date the ami was created and set the most_recent argument to true it would not do us any good.

After that we set the virtualization-type to hvm. I am not going to go into a lot of detail here. Just know this is a good idea and do some additional research on hvm vs pv.

Last we set **owners **to 801119661308.

Now I am sure you are asking… how the heck do I actually get this information? Well you are going to have to run a quick command with the AWS cli.

First, login to AWS and get the ami you want to grab the information for. Here is an example:

Image for post

If you click on launch instance you can do a search.

#aws-ec2 #hashicorp-terraform #aws-cloudwatch #terraform-modules #terraform