Rory  West

Rory West

1624465440

Creating AWS Storage Gateway Module with Terraform

Cloud computing is the on-demand delivery of IT resources over the Internet with pay-as-you-go pricing. Instead of buying, owning, and maintaining physical data centers and servers, you can access technology services, such as computing power, storage, and databases, on an as-needed basis from a cloud provider like Amazon Web Services (AWS).

Creating infrastructure is a painful process as we have to create it manually and removing infrastructure is also the same, this is where terraform comes into play.

Now what is terraform and how do we make modules in terraform to do so.

#aws #terraform #aws storage

What is GEEK

Buddha Community

Creating AWS Storage Gateway Module with Terraform
Rory  West

Rory West

1624465440

Creating AWS Storage Gateway Module with Terraform

Cloud computing is the on-demand delivery of IT resources over the Internet with pay-as-you-go pricing. Instead of buying, owning, and maintaining physical data centers and servers, you can access technology services, such as computing power, storage, and databases, on an as-needed basis from a cloud provider like Amazon Web Services (AWS).

Creating infrastructure is a painful process as we have to create it manually and removing infrastructure is also the same, this is where terraform comes into play.

Now what is terraform and how do we make modules in terraform to do so.

#aws #terraform #aws storage

Ruby  Schmitt

Ruby Schmitt

1597945860

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

Kole  Haag

Kole Haag

1603213200

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 main.tf file which contains all of my configuration except for the variables and outputs. The main.tf has a few parts to it.

AWS Instance Code

The first section is the instance resource code

#AWS Instance

resource "aws_instance" "example" {
     ami = data.aws_ami.windows.id
     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

Rory  West

Rory West

1619263860

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

How to easily create a HTTP 301 redirection with AWS API Gateway

Use Case

The use case is pretty explicit, every request you need to do a redirect.

I needed to do this because of a Gateway restriction where the root of a {proxy+} resource can’t be include in the {proxy+} itself

What I mean here is if you have the following structure

/docs won’t be included in the lambda targeted by the proxy. My suggestion is to simply create a 301 from /docs to /docs/index.html.

#terraform #aws-lambda #aws-api-gateway #http-redirect-301 #aws