DEV Community: AnanyaDasgupta

Terraform 101: Creating Secure Subnets in Your VPC

AnanyaDasgupta — Thu, 25 Apr 2024 12:11:37 +0000

Welcome to Part 2 of the series: Terraform for Beginners

Previously, we learned how to create a VPC in AWS using Terraform. In this blog, we'll learn about subnets and how to create them using Terraform.

What is a subnet?

According to AWS documentation,

A subnet is a range of IP addresses in your VPC. You can create AWS resources, such as EC2 instances, in specific subnets.

Here's a breakdown of the key aspects of a subnet:

Segmentation: Subnets allow you to partition your VPC into isolated units. This enhances security by restricting resources within one subnet from directly accessing resources in another subnet by default. If needed, you can configure specific routing rules to allow controlled communication between subnets.
Placement: You can create multiple subnets within your VPC, each with its own CIDR block (a range of IP addresses). When launching resources like EC2 instances within your VPC, you can specify their subnet. This placement determines their network access and security posture.
Public vs. Private: A common practice involves creating two main types of subnets:
- Public Subnet: Resources placed in a public subnet have direct access to the internet. This allows them to receive inbound traffic from the internet and potentially send outbound traffic. Public subnets are suitable for resources like web servers that need to be accessed publicly.
- Private Subnet: Resources in a private subnet don't have direct internet access by default. This improves security for resources that don't require exposure to the internet. However, if these resources need controlled outbound access (e.g., downloading updates), you can leverage a NAT Gateway (Network Address Translation Gateway) to provide it.

Let's look at the architecture diagram.

We have to create a public and private subnet inside the vpc we created in the previous blog.

Prerequisites

Complete the tutorial for creating a vpc as we will continue from there.
You can check out the tutorial here

Terraform Code to create Subnet in AWS

Step 1: In your vpc.tf file copy and paste the following piece of code:

resource "aws_subnet" "public_subnet" {
  for_each                = var.public_subnet
  vpc_id                  = aws_vpc.vpc.id
  cidr_block              = each.value.cidr_block
  availability_zone       = each.value.availability_zone
  map_public_ip_on_launch = true
  tags = {
    Name         = "${var.env}-${local.project}-${each.key}"
    CreatedByTer = true
  }
}

resource "aws_subnet" "private_subnet" {
  for_each          = var.private_subnet
  vpc_id            = aws_vpc.vpc.id
  cidr_block        = each.value.cidr_block
  availability_zone = each.value.availability_zone
  tags = {
    Name          = "${var.env}-${local.project}-${each.key}"
    CreatedByTer  = true
  }
}

Explanation:

for_each allows you to create multiple subnets with varying configurations based on the data provided in the variables named public_subnet and private_subnet.
cidr_block = each.value.cidr_block.
- This line defines the CIDR block for the subnets. However, it uses a dynamic approach by referencing each.value.cidr_block. This suggests that var.public_subnet and var.private_subnet is a map or list containing key-value pairs where the key is used for iteration (each.key) and the value (each.value) contains a nested object with a cidr_block key. This allows you to define multiple CIDR blocks for different subnets within the loop.
availability_zone = each.value.availability_zone
- Similar to the cidr_block, this line defines the availability zone for the subnets using a dynamic reference to the availability_zone key within the nested objects. This allows you to distribute your resources across zones for redundancy.
map_public_ip_on_launch
- This line sets the map_public_ip_on_launch attribute to true or false. When set to true, any EC2 instances launched within that subnet will automatically receive a public IP address, allowing them to be accessed directly from the internet. Similarly, when set to false, the instances will not be assigned a public IP during creation.

You will get an error as we have not yet created the public_subnet and private_subnet variables.

Step 2: In your variables.tf file copy and paste the following code:

variable "public_subnet" {
  type        = map(any)
  description = "Public Subnets to be created"
}
variable "private_subnet" {
  type        = map(any)
  description = "Private Subnets to be created"
}

Explanation:

This code block defines two Terraform variables named "public_subnet" and "private_subnet". It specifies that the variables will hold a collection of data in the form of a map.
While 'any' allows for flexibility, using more specific data types within the map can improve code readability and catch potential errors during configuration.

Step 3: In your terraform.tfvars file copy and paste the following code block

public_subnet = {
  public-subnet-1 = {
    cidr_block        = "10.0.101.0/24"
    availability_zone = "ap-south-1a"
  }
}
private_subnet = {
  private-subnet-1 = {
    cidr_block        = "10.0.1.0/24"
    availability_zone = "ap-south-1a"
  }
}

Explanation:

The value of the public_subnet and private_subnet variables are defined here.
This configuration defines the above variables as map of a map.
public-subnet-1 is the name of the first child map of the variable public_subnet. It consists of two key-value pairs:
- cidr_block specifies the CIDR range for the subnet
- availability_zone specifies the AWS availability zone the subnet will reside in. Here we are creating the subnet in the _Mumbai _region.
Similarly, private-subnet-1 is the name of the first child of the variable private_subnet. It consists of the same key-value pairs.

Deploy infrastructure to AWS

Follow the steps here to deploy the changes to AWS.

Congratulations! You have successfully created subnets in AWS using terraform.

Up next: Internet Gateway! Stay tuned. 👋

Terraform for Newbs: Launching a Simple AWS Backend (Welcome to the Series!)

AnanyaDasgupta — Wed, 17 Apr 2024 10:25:26 +0000

In today's world, code can be used to achieve remarkable feats, from building complex applications to managing your infrastructure across cloud providers like AWS, Azure, and GCP. While manually provisioning resources through a cloud console might be feasible for small-scale projects, large production applications require a more robust and scalable approach.

The following scenarios are just some of the many nuances of manual resource provisioning:

Configuration Drift: Over time, configurations can diverge between development, testing, and production environments if managed manually. This inconsistency can lead to unexpected behavior and troubleshooting challenges.
Human Error: Manual configuration is prone to typos and errors, potentially leading to security vulnerabilities, service outages, or wasted resources due to misconfiguration.
Limited Collaboration: Sharing and collaborating on infrastructure configurations can be difficult with manual provisioning. Centralized code repositories become less practical, hindering collaboration between developers and infrastructure teams.

This is where Infrastructure as Code (IaC) comes into play. IaC allows developers to define and provision infrastructure resources using code. One such widely used IaC tool is Terraform.

This article is the first in a series of articles where I will discuss how to provision a simple backend architecture in AWS using Terraform.

Note: Terraform uses HCL (HashiCorp Configuration Language), a domain-specific language (DSL) to define and configure infrastructure resources.

Prerequisites:

AWS Account with necessary permissions to create resources in it.
AWS IAM user with access credentials.
VS Code or any other code editor.

Architecture Diagram

Components:
- VPC
- Subnets (One each for Public and Private)
- Internet Gateway
- Route Table
- NAT Gateway
- EC2 instances
- Application Load Balancer
- Auto Scaling Groups

Here is a brief intro to the components. I will suggest referring to the AWS documentation to learn about them in detail.

VPC(Virtual Private Cloud): The foundation of your isolated network. It is a virtual network that is hosted within a public cloud. It provides a level of isolation between different organizations that use the resources.
Public Subnet: A subnet within the VPC that resides in a public availability zone. It has a route table configured to allow access from the internet. This subnet typically houses the application load balancer.
Private Subnet: A subnet within the VPC that resides in a private availability zone. It has a route table configured to restrict access from the internet. This subnet houses your EC2 backend servers for security reasons.
Internet Gateway: An internet gateway attached to the VPC, enabling resources in the public subnet (like the load balancer) to access the internet
NAT Gateway (Optional): A NAT Gateway in the public subnet can act as an internet gateway for the private subnet, allowing outbound traffic from your backend servers for updates or external service communication (e.g., downloading updates from a public repository).
Application Load Balancer: Distributes incoming traffic from the internet across healthy backend servers in the private subnet.
EC2 Instances: Backend servers running your application code. They reside in the private subnet for security purposes.
Auto Scaling Groups: A group that manages backend servers. It can automatically scale the number of EC2 instances up or down based on pre-defined policies (e.g., CPU utilization).

In this article, I will focus on creating the infrastructure for a standalone VPC.

Directory Setup

Step 1: Create a folder in your local environment named backend.
Step 2: Open the folder in a code editor of your choice. I will use VS Code for this project.
Step 3: Open the terminal in your code editor and run the command mkdir vpc
Step 4: In your terminal run the command cd vpc

Before we start with Terraform, we need to configure our AWS credentials so that Terraform can be deployed to AWS from our local environment.

In your terminal, run aws configure. Set the AWS Access Key ID, AWS Secret Access Key, Default region name, and Default output format. Press enter for the default values.

Terraform Code to create a VPC in AWS

Step 1: Create provider.tf

Inside the vpc folder create a file named 'provider.tf'. Paste the following code block inside it.

terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
        source = "hashicorp/aws"
        version = ">= 4.66.1"
    }
  }
}

provider "aws" {
  region              = "ap-south-1"
  allowed_account_ids = [local.aws_account_id]
}

A provider in Terraform is a plugin that enables interaction with an API. This file contains the details of all the providers used in the project.

Terraform Provider Configuration Breakdown:

required_version: This specifies the minimum Terraform version required to execute this configuration. Ensure you have Terraform version 1.0 or above installed to work with this code.
required_providers: This block defines the required providers and their versions. Here, we specify the AWS provider with a minimum version of 4.66.1. A specific version ensures compatibility between your Terraform configuration and the provider's functionalities.

AWS Provider Configuration Breakdown:

provider "aws" Block: This block configures the AWS provider itself.
region: This specifies the AWS region where your infrastructure will be deployed. In this example, we're using "ap-south-1" which corresponds to the Asia Pacific South (Mumbai) region.
allowed_account_ids: (Optional) This restricts Terraform to managing resources only within the specified account IDs. Here, we're referencing a variable named aws_account_id defined in a separate variable file. This helps ensure Terraform only manages resources within your authorized accounts.

We will get this error: "No declaration found for "local.aws_account_id". To solve this we have to create the locals.tf file

Step 2: Create "locals.tf":

Terraform locals define and assign values within your terraform configuration. These values can be reused throughout your code, making your configuration more concise and easier to maintain.

Inside the vpc folder create a file named "locals.tf". Paste the following code in it.

locals {
  project = "demo"
  aws_account_id = xxxxxxxxxxxx
}

Replace the value of the aws_account_id variable with your own AWS account ID.

Locals Configuration Breakdown:

project: This local value assigns the string "demo" to the name project. You can use this value throughout your Terraform configuration wherever you need to reference your project name (e.g., naming resources).
aws_account_id: This local value assigns the 12-digit AWS account ID to the name aws_account_id.

Step 3: Create variables.tf and terraform.tfvars:

Terraform variables are a powerful mechanism for defining configuration values outside your Terraform code. They act as placeholders that can be assigned values later, typically through a separate file named 'terraform.tfvars'.

variables.tf

variable "env" {
  type = string
}

variable "vpc_conf" {
  type = map(any)
}

Explanation of variables.tf code:

env: This variable has a type of string, indicating it will hold a textual value. You can use this variable throughout your Terraform configuration to reference the environment (e.g., "dev", "staging", "production").
vpc_conf: This variable has a type of map(any), which essentially defines a key-value dictionary. This allows you to define multiple configuration options for your VPC in a structured manner.

terraform.tfvars

env = "dev"
vpc_conf = {
  cidr_block           = "10.0.0.0/16"
  instance_tenancy     = "default"
  enable_dns_hostnames = true
  enable_dns_support   = true
}

Explanation of terraform.tfvars code:

env = "dev": This line assigns the string value "dev" to the env variable.
vpc_conf block: This block defines key-value pairs for the vpc_conf variable:
- cidr_block = "10.0.0.0/16": This defines the CIDR block for your VPC.
- instance_tenancy = "default": This defines the tenancy for your VPC instances (Default value is "default". The only other option is "dedicated").
- enable_dns_hostnames = (Optional) A boolean flag to enable/disable DNS hostnames in the VPC. Defaults to false.
- enable_dns_support = (Optional) A boolean flag to enable/disable DNS support in the VPC. Defaults to true.

Refer to the official terraform documentation here to learn more about the attributes used.

Step 4: Create vpc.tf:

The vpc.tf file defines an AWS VPC resource using the aws_vpc resource block provided by the Terraform AWS provider. This block creates a virtual private cloud (VPC) within your AWS account.

resource "aws_vpc" "vpc" {
  cidr_block           = var.vpc_conf.cidr_block
  instance_tenancy     = var.vpc_conf.instance_tenancy
  enable_dns_hostnames = var.vpc_conf.enable_dns_hostnames
  enable_dns_support   = var.vpc_conf.enable_dns_support
  tags = {
    Name          = "${var.env}-${local.project}-vpc"
    CreatedByTer  = true
  }
}

The code demonstrates how to leverage variables defined in variables.tf. Notice how it references the vpc_conf map and accesses specific configuration values using the dot notation (e.g., var.vpc_conf.cidr_block). This approach keeps your Terraform code clean and avoids hardcoding configuration details.

Explanation of vpc.tf code:

cidr_block = var.vpc_conf.cidr_block: This line sets the CIDR block for the VPC using the value assigned to the cidr_block key within the vpc_conf variable map (defined in terraform.tfvars).
instance_tenancy = var.vpc_conf.instance_tenancy: This line sets the instance tenancy for the VPC using the value assigned to the instance_tenancy key within the vpc_conf variable map.
enable_dns_hostnames = var.vpc_conf.enable_dns_hostnames: This line enables DNS hostnames for the VPC resources based on the value assigned to the enable_dns_hostnames key within the vpc_conf variable map.
enable_dns_support = var.vpc_conf.enable_dns_support: This line enables DNS support for the VPC based on the value assigned to the enable_dns_support key within the vpc_conf variable map.

Adding tags:

Name = "${var.env}-${local.project}-vpc": This line dynamically creates a tag named "Name" using string interpolation.
CreatedByTerraform = true: This line assigns a tag named "CreatedByTerraform" with a " true " value, indicating this VPC was created using Terraform.

Step 5: Create backend.tf:

This code snippet defines a Terraform backend using the backend block. By default, Terraform stores the state of your infrastructure (information about created resources) in a local file named terraform.tfstate within your project directory. This local state file is not ideal for production environments due to limitations like:

Single Point of Failure: If the local file is lost or corrupted, you might lose track of your infrastructure state.
Collaboration Challenges: When working with multiple collaborators, sharing and managing the state file becomes cumbersome.

Using S3 Backend:

To address these limitations, we are going to configure an S3 backend. This instructs Terraform to store the state information in an Amazon S3 bucket. Here's a breakdown of the configuration:

backend "s3": This line declares the backend type as "s3", indicating we'll use an S3 bucket to store the state.
bucket = "terraform-demo-state-files": This line specifies the name of the S3 bucket where Terraform will store the state file. It's recommended to choose a descriptive name for your bucket.
region = "us-east-1": This line specifies the AWS region where the S3 bucket resides. It is generally recommended to have the S3 bucket where your Terraform state is stored.
key = "state": This line defines the key (filename) within the S3 bucket where Terraform will store the state information. You can customize this key name if needed.

Deploy infrastructure to AWS

Now that we've defined our infrastructure using Terraform code, it's time to deploy it to AWS!
Here's a typical workflow for deploying Terraform code:

Initialize Terraform: Open the terminal of code editor, and navigate to the 'vpc' directory. Run terraform init. This downloads and installs any required plugins (like the AWS provider) based on your configuration.

Review Changes: Before applying, run terraform plan to see a preview of the changes Terraform will make to your AWS environment. This allows you to verify the planned actions before actual creation.

Apply the Configuration (Optional): Once you are satisfied with the plan, run terraform apply to create the resources in your AWS account. If you're using a basic Terraform setup, you might see a prompt like "Do you want to apply these changes?" Carefully review the prompt and answer "yes" only if you intend to proceed.

Congratulations! You have successfully created a vpc in AWS using Terraform. Open the console, and examine the infrastructure that we just created. Notice that a route table has been created. To ensure basic functionality within your VPC, AWS automatically creates a main route table when you create a VPC.

Up next: Terraform 101: Creating Secure Subnets in Your! Stay tuned. 👋

Deploy a web application with AWS Lambda

AnanyaDasgupta — Wed, 17 Apr 2024 05:59:27 +0000

Lambda is the serverless computing solution provided by AWS.
According to official AWS documentation,

“AWS Lambda is a compute service that lets you run code without provisioning or managing servers.”

Lambda follows the principles of serverless computing. In serverless computing, you don’t have to worry about server and operating system maintenance, capacity provisioning, automatic scaling, and logging.

AWS Lambda takes care of the provisioning of the underlying infrastructure. It ensures the code is run on a high-availability computing infrastructure and administers the solution.
The developer only needs to provide the codebase in one of the languages supported by AWS Lambda.
Refer to this link for the languages supported by Lambda.

In this blog post, I’ll guide you through the process of creating a simple Node.js API and deploying it using the Serverless Framework on AWS Lambda.

Prerequisites

Before we dive into the development and deployment process, make sure you have the following tools installed:

Node.js and npm
AWS CLI
Serverless Framework

Setting Up the Project

Initialize Node.js Project: Here, I am using VS Code to write the code. You can use any code editor of your choice.

  mkdir lambda-api
  cd lambda-api
  npm init -y

Install Dependencies:

npm install express aws-serverless-express serverless -S
Create a folder src in the root directory of your project. Navigate to the src directory and create a file named app.js

const express = require('express');
const awsServerlessExpress = require('aws-serverless-express');

const app = express();

app.get('/api/hello', (req, res) => {
  res.json({ message: 'Hello from your Lambda API!' });
});

module.exports.handler = (event, context) => {
   awsServerlessExpress.proxy(server, event, context);
};

This is a simple API that prints the message “Hello from your Lambda API!” on the browser.

Configure serverless.yml:

The serverless.yaml file is a configuration file used in serverless computing environments, particularly with the Serverless Framework.
The serverless.yaml file is used to define various aspects of your serverless application, such as functions, events, resources, and provider-specific settings.

service: lambda-api

provider:
  name: aws
  runtime: nodejs14.x

functions:
  app:
    handler: src/app.handler
    events:
      - http:
          path: /
          method: ANY
          cors: true
      - http:
          path: /{proxy+}
          method: ANY
          cors: true

Here’s a general overview of theserverless.yaml file:

Service Information:

service: Specifies the name of your service.
provider: Defines the cloud provider (AWS, Azure, Google Cloud, etc.).
runtime: Specifies the runtime for your functions (Node.js, Python, Java, etc.).

service: lambda-api

provider:
  name: aws
  runtime: nodejs14.x

Functions:

Describes the functions in your serverless application.
Specifies the handler (entry point) for each function.

functions:
      app:
        handler: src/app.handler

Events:

Defines events that trigger your functions (HTTP events, S3 events, etc.).

functions:
      app:
        handler: src/app.handler
        events:
          - http:
              path: /
              method: ANY
              cors: true
          - http:
              path: /{proxy+}
              method: ANY
              cors: true

Configure AWS CLI:

Install the AWS CLI on your machine and configure it with your AWS Access Key ID, Secret Access Key, default region, and output format using the following command:

aws configure

Deploying to AWS Lambda

`npx serverless deploy --stage dev --region ap-south-1`

This command deploys your Lambda function and provides an endpoint URL. The Serverless Framework automatically configures API Gateway as part of the deployment process.

API Gateway is a fully managed service by AWS that makes it easy to create, publish, maintain, monitor, and secure APIs at any scale. When you deploy a Serverless Framework project, it creates an API Gateway endpoint, and you can find the URL of this endpoint in the output of the deployment process.

[https://ixnjy43dxk.execute-api.ap-south-1.amazonaws.com/dev/](https://ixnjy43dxk.execute-api.ap-south-1.amazonaws.com/dev/) is the API Gateway endpoint that was created for this Lambda function.
You can use the endpoint created for your function to access your API and test your deployed Lambda function. It’s the entry point for your serverless application from the internet.

Conclusion

You’ve successfully created a simple Node.js API and deployed it using the Serverless Framework on AWS Lambda. Serverless architecture provides a powerful and scalable solution for various applications, and with the right tools, the development and deployment process becomes seamless.

Feel free to explore additional features and integrations, and share your experience with the Serverless community. Happy coding!