DEV Community: anil augustine chalissery

Is Terraform better than AWS CloudFormation?

anil augustine chalissery — Wed, 21 Sep 2022 07:23:41 +0000

Is Terraform better than AWS CloudFormation?

Let's outline some of the key differences between Terraform and AWS CloudFormation.

Introduction

When asked about the best tools to automate infrastructure provisioning, two prevalent names come to mind: Terraform and AWS CloudFormation. Infrastructure-as-Code (IaC) has become fundamental to businesses in their cloud journey. As the name implies, IaC provides the ability to define your infrastructure, typically cloud infrastructure, as code. In today’s world, where we are surrounded by companies heavily relying on cloud providers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud, Building and managing cloud infrastructure manually can be quite the task and even more challenging when you’re operating as a distributed team.

Cloud providers typically offer a native infrastructure as code language that exclusively supports the deployment of resources to their cloud platform. For AWS, that offering is a service called AWS CloudFormation. There are other tools on the market, some of which are sometimes described as “cloud agnostic” due to their ability to support the deployment to multiple cloud providers. Terraform by HashiCorp is one of the most common IaC tools which is “cloud agnostic”.

What is Terraform?

Terraform is an open-source, cloud-agnostic infrastructure management tool developed by HashiCorp that enables modular configuration of infrastructure, thereby allowing you to use AWS modules and third-party modules in the same infrastructure. Terraform utilizes a syntax called the HashiCorp Configuration Language (HCL), which allows users to define their infrastructure programmatically.

In addition to the “multi-provider” support that Terraform provides, there are other benefits to consider as well such as its ability to dynamically create resources using its for_each or count features and the ability to dynamically configure properties of a resource with the dynamic block functionality. Additionally, Terraform supports built-in functions that can be called and used within your code, which become very useful for everyday tasks.

What is AWS CloudFormation?

Amazon CloudFormation is a fantastic tool that gives the development and operations team the liberty to automate AWS’s infrastructure provision easily. It is a managed AWS service that allows you to design and provision AWS and third-party resources for your cloud environment. Cloudformation handles the configuration in a JSON or YAML format called templates. These templates enable the user to attain re-usability and scalability of infrastructure. In addition to this, AWS Support will probably be more capable of assisting you with issues when you need help. AWS Support is essential for large enterprises, particularly those new to the cloud or slow to adopt.

The comparison

Now that we’ve defined these two IaC platforms, let’s review some of the key differences in more depth. When trying to determine the better of the two, you might be overwhelmed with the features they both offer. One of them could be better than the other depending on how they suit your infrastructure’s needs.

1. State Management

Both tools need to keep track of all the resources under management. CloudFormation is managing its state with so-called stacks. By default, Terraform is storing its state on disk. Terraform is offering remote state as well, for example, based on S3 and DynamoDB or Terraform Cloud. It is advisable to use a remote state when multiple users are working on the same infrastructure in parallel. CloudFormation manages state within the managed service out-of-the-box, which is a small plus compared to Terraform, where you need to configure remote state yourself.

2. Cost and Support

The best part about both these tools is that both are free of cost. Both of these tools have large communities with a lot of support and examples. Cloudformation is not billed. The only fee that users incur is the cost of AWS service provisioned by CloudFormation. Terraform is a free and open-source tool. Terraform however offers a paid enterprise version that has additional collaboration and governance options. The AWS support plans include support for CloudFormation. Hashicorp, the company behind Terraform, is offering support plans as well.

3. Cloud Providers

AWS CloudFormation, as the name suggests, is specific to Amazon Web Services. You can theoretically achieve deployment to third-party resources through the use of custom resources, but this is rather hacky, and at the end of the day those third-party resources are not truly supported by CloudFormation. On the other hand, Terraform allows you to deploy to other cloud providers as well. Granted, you won’t be able to re-use the same codebase from one cloud provider to another. At the very least, when using Terraform, you’ll have familiar syntax and methods for deploying to different cloud providers. For some companies this is a significant benefit, as being able to use the same syntax and deployment methods to deploy to multiple cloud providers is a clear plus.

4. Modularity

CloudFormation uses sets of “nested stacks” or templates as modules. These nested stacks act as building blocks for your infrastructure and allow you to import and export standard configuration settings. For example, you might have multiple configurations of resources used for different applications or infrastructure. In these cases, you can create a dedicated template for such resources that you can then import into every stack that needs the resource.

Terraform outstands when considering its modularity. HashiCorp built Terraform to be cloud-agnostic and be able to incorporate any resource. Terraform includes native support for many third-party modules. It accomplishes this via “providers,” or plugins that implement resource types. You can add any resource, AWS or third-party, by adding a provider to your configuration.

Terraform also uses modules to organize configurations. Modules allow complex configurations to remain readable by managing related parts. You can also use modules to reuse and share common configurations. Reusing modules causes fewer errors and less time to rewrite your configurations. Terraform practitioners often publish modules online. The vast community that Terraform has built allows you to tap into community knowledge and experience and dramatically reduces the time you’d spend writing and debugging configuration files.

5. Rollback

When CloudFormation fails to modify your infrastructure, it rolls back to the previous working state automatically. Terraform does not support rollbacks out of the box. Either you decide to fix the problem and deploy it again, or you have to apply the previous configuration yourself. You can also prevent a rollback by using the command terraform plan that outputs a list of all upcoming changes before actually executing them. You can also use terraform plan to complete dry runs of an update, double-check the output to ensure all changes are as expected, and then commit your changes.

Both CloudFormation and Terraform support a “prevent from deletion” feature. This safeguard ensures that you cannot delete resources in use as dependencies in other applications, thereby dramatically reducing your chances of accidentally breaking your infrastructure!

6. Built-in Functions

The ability to use built-in functions within your code can have tremendous benefits. In Terraform, you have access to many different types of functions. A few example categories of Terraform functions include numeric, string manipulation, encoding, date/time, and filesystem — and this is not the complete list! In comparison, CloudFormation is extremely limited, providing less than 15 intrinsic functions in total. The lack of helper functions can lead to annoying, complicated situations for basic tasks. For example, if you’re simply looking to obtain the date or time within your CloudFormation template, there’s no built-in function for this. Instead, you’ll need to create a custom resource within your template that calls a lambda function that returns the information you need.

The final decision on Terraform vs CloudFormation

Before determining between using CloudFormation or Terraform, consider your infrastructure’s needs and your organizational needs. Both CloudFormation and Terraform are flexible and powerful tools and offer comprehensive state management and automated logging. But they also provide different features that suit your infrastructure needs differently. If you’re mainly working with AWS resources, CloudFormation might work best for you. If your infrastructure relies on many third-party resources, Terraform might be a better fit.

Reference

Monitor Linux Memory Metrics in AWS CloudWatch

anil augustine chalissery — Wed, 14 Sep 2022 12:50:13 +0000

How to install the CloudWatch agent in Ubuntu 20.04 and how to get memory metrics in the CloudWatch console

In AWS, for the EC2 instance, we won't get memory metrics by default in CloudWatch. So one way to get this done is with the CloudWatch agent. By getting the memory metrics in AWS CloudWatch we can set up an Alarm to trigger notifications or any action. In this post, we see how the CloudWatch agent is installed in Ubuntu 20.04 and how to get memory metrics in the CloudWatch console.

Step 1: Create an IAM role

As we use CloudWatch we need to authenticate to push metrics. If you are planning to implement this in an on-premise Ubuntu server, we can do this with IAM users, with programmatic access. As our instance is in EC2 we create an IAM role with the following steps.

Note : if you already have an IAM role attached to instance then just attach CloudWatchAgentServerPolicy policy to that role

Step 1.1: Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.

Step 1.2: In the navigation pane of the IAM console, choose Roles, and then choose to Create role.

Step 1.3: For Select trusted entity, choose AWS service.

Step 1.4: Choose the use case as EC2. Then, choose Next.

Step 1.5: In Permission policies search for CloudWatchAgentServerPolicy and select that, then click Next

Step 1.6: Give a name for the role created here we provide the name as EC2CloudWatchAgentRole. Below that we can review the things we created and, then click Create role

Now we have created our IAM role.

Step 2: Launch an EC2 with Ubuntu 20.04 ami

If you already have an EC2 launched you can skip this step. If you are doing this on an on-premise instance you can skip this step(See this).

Step 2.1: Provide any name of the instance.

Step 2.2: Select Ubuntu Server 20.04 LTS AMI

Step 2.3: Choose t3a.micro or any instance type.

Step 2.4: Choose a key pair or create a new one if you don’t have access to existing key pairs.

Step 2.5: Keep Network settings default if you are new to VPC or customise as required

Step 2.6: Allocate more space if required. Suppose it's for testing purposes 8GB is enough.

Step 2.7: Once reviewed you can click on launch instance.

Now we have created the instance.

Step 3: Attach the IAM role to the instance

Now we attach the IAM role created in Step 1

Step 3.1: Select instance click Actions then from Security select Modify IAM role

Step 3.2: Now from the drop-down you can select the role we created earlier

Select the role and click Save

Step 4: Let's install and configure CloudWatch Agent

Let's run this as root so we could avoid sudo in every command.

sudo su -

Step 4.1: Download the CloudWatch agent:

wget [https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb](https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb)

Step 4.2: Install the package:

dpkg -i -E ./amazon-cloudwatch-agent.deb

This will create a user cwagent, group with relevant permissions and installs the CloudWatch agent

Now lets packages

 apt-get update

Step 4.3: Create the CloudWatch Agent Configuration File
We could do this in two ways:
1) Create this config.json file directly
2) Create the CloudWatch agent configuration file with the wizard

For automating purposes I would suggest the First option. If you choose the second option, the wizard would create the config.json for you, which also can be modified.

Creating config.json file directly

Create a file named config.json in this path /opt/aws/amazon-cloudwatch-agent/bin/config.json and paste this JSON there

{
 "agent": {
  "metrics_collection_interval": 60,
  "run_as_user": "cwagent"
 },
 "metrics": {
  "aggregation_dimensions": [
   [
    "InstanceId"
   ]
  ],
  "metrics_collected": {
   "mem": {
    "measurement": [
     "mem_used_percent"
    ],
    "metrics_collection_interval": 60
   }
  }
 }
}

NOTE : This policy is sending only memory metrics in every 60s. we have other intervals as 1s, 10s, 30s, and 60s. This metrics is fetched as cwagent

Create the CloudWatch agent configuration file with the wizard

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

The questions and options are as follows

On which OS are you planning to use the agent?

Linux
Windows
Darwin default choice: [1]:

Trying to fetch the default region based on ec2 metadata… Are you using EC2 or On-Premises hosts?

EC2
On-Premises default choice: [1]:

Which user are you planning to run the agent?

root
cwagent
others default choice: [1]:

Do you want to turn on StatsD daemon?

yes
no default choice: [1]:

Do you want to monitor metrics from CollectD? WARNING: CollectD must be installed or the Agent will fail to start

yes
no default choice: [1]:

Do you want to monitor any host metrics? e.g. CPU, memory, etc.

yes
no default choice: [1]:

Do you want to monitor CPU metrics per core?

yes
no default choice: [1]:

Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available?

yes
no default choice: [1]:

Do you want to aggregate ec2 dimensions (InstanceId)?

yes
no default choice: [1]:

Would you like to collect your metrics at high resolution (sub-minute resolution)? This enables sub-minute resolution for all metrics, but you can customize for specific metrics in the output JSON file.

1s
10s
30s
60s default choice: [4]:

Which default metrics config do you want?

Basic
Standard
Advanced
None default choice: [1]:

After answering this series of questions it will create a config.json at the same path as above.

Step 4.4: Check the status of the agent

To check the status of the CloudWatch agent.

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status

Step 4.5: To start the CloudWatch agent

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

You can check the status again to verify its running

Step 5: Let's verify memory metrics are arriving in the CloudWatch console

Now to check in the AWS console, you can go to CloudWatch console, then metrics -> custom metrics -> host

That’s how we monitor Ubuntu memory utilisation with CloudWatch. Even though we used Ubuntu 20.04 this should also work in other Debian-based OS. In case you don’t find metrics in the CloudWatch console double-check the role and its access.

References

AWS VPC Traffic Mirroring

anil augustine chalissery — Tue, 06 Sep 2022 16:46:55 +0000

In this post, we will explore how to gain insight into your network traffic using Amazon VPC Traffic Mirroring. We will learn how to copy network traffic from an elastic network interface (ENI) from your EC2 instances into your VPCs and send it to the security and monitoring appliances.

Before we begin we briefly go over what a network can look like and what are different native traffic monitoring capabilities available within AWS cloud.

What is Traffic Mirroring?

Traffic Mirroring is an Amazon VPC feature that you can use to copy network traffic from an elastic network interface of Amazon EC2 instances. You can then send the traffic to out-of-band security and monitoring appliances for:

Content inspection
Threat monitoring
Troubleshooting

Traffic Mirroring concepts

The following are the key concepts for Traffic Mirroring:

Source — A network interface with the type instance.
Target — The destination for mirrored traffic.
Filter — A set of rules that defines the traffic that is copied in a traffic mirror session.
Session — An entity that describes Traffic Mirroring from a source to a target using filters.

Get started with Traffic Mirroring

Now we will setup traffic mirroring for a desired source and look at the captured packet on desired target. From this post you will learn how to successfully configure following components required for setting up Amazon VPC Traffic Mirroring:

Traffic mirror target
Traffic mirror filter
Traffic mirror session

Step 0: Prerequisites

Make sure that the traffic mirror source and traffic mirror target are in the same VPC, in different VPCs that are connected via VPC peering or a transit gateway.
Make sure that the traffic mirror target instance allows traffic to UDP port 4789.
Make sure that the traffic mirror source has a route table entry for the traffic mirror target.
Make sure that there are no security group rules or network ACL rules on the traffic mirror target that drop the mirrored traffic from the traffic mirror source.

We will need the following resource before proceeding

VPC
IGW
Public route table
Public subnet
Three EC2 instances

Acting as client(optional we can use our local machine as client.)
Acting as server
Acting as destination for mirrored traffic

Step 1: Create the traffic mirror target

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/
1. In the Region selector, choose the AWS Region that you used when you created the VPCs.

On the navigation pane, choose Traffic Mirroring, Mirror Targets.
Choose Create Traffic Mirror Target.
For Name tag, enter a name for the traffic mirror target.

(Optional) For Description, enter a description for the traffic mirror target.

For Target type, choose the traffic mirror target type.

Here we use Network Interface as we are creating a target to an EC2 instance.

For Target, choose the traffic mirror target.

From the drop down select the ENI of our target instance(destination of mirrored traffic). We can see our ENI of instance in instance description in EC2 console. Click on Network Interface eth0 and it will display the ENI.

(Optional) Add or remove a tag.

[Add a tag] Choose Add tag and do the following:

For Key, enter the key name.
For Value, enter the key value.

[Remove a tag] Next to the tag, choose Remove tag.

Choose Create.

Step 2: Create the traffic mirror filter

A traffic mirror filter contains one or more traffic mirror rules, and a set of network services. The filters and rules that you add define the traffic that is mirrored. Now we will create traffic mirror filter

On the left navigation pane, scroll down and choose Traffic Mirroring, Mirror Filters:
Choose Create Traffic Mirror Target:

Enter value as show below and choose create traffic mirror filter:

We are going to mirror port 80 traffic ingressing on the server(source), hence we have created inbound rule for port 80. If you want to mirror traffic egressing from the server (source) outbound traffic, you need to create outbound rule as well.

we can also get all traffic mirrored without providing port range also CIDR as 0.0.0.0/0

Choose Create.

Step 3: Create the traffic mirror session

On the left navigation pane, scroll down and choose Traffic Mirroring, Mirror Session
Choose Create Traffic Mirror session:

For Name tag, enter a name for the traffic mirror session.

For Description, enter a description for the traffic mirror session.

For mirror source, choose the network interface of the instance that you want to monitor. We will need the ENI of source instance so get the ENI as we did before
For mirror target, choose the traffic mirror target. From the drop down we can select the target we created in step 1
For Session number, enter the session number.

Use 1 for the highest priority.

Keep all other values as default as its optional to know more about the other optional values refer this

At this point you should have your filter successfully created

Step 4: Mirror traffic

As now our traffic mirroring target, session and filter is done now let check how to mirror traffic. In perquisite we creates three Amazon EC2 instances, they serve following purpose:

as Client instance: (optional as we can curl from our local too. I would be good to know our public ip prior so we can verify from logs)

Using curl, we will send port 80 traffic from client to server

Server instance:

It is running web server and returns a basic hello html page. It will respond to client instances’s curl request. An Linux with Nginx or Apache would do this trick.
This is also acting as a source. We are going to mirror port 80 traffic ingressing on the server.

Destination instance:

Mirrored traffic is send to this instance

So lets Begin

From destination instance start capturing traffic with the following command > sudo tcpdump -nnni ens5 udp port 4789

Send port 80 traffic from client to server. You need to be on client instance terminal for this

curl
Now in destination instance you will be getting the traffic mirrored

That’s it now traffic mirroring works fine.

You can use open-source tools to monitor network traffic from Amazon EC2 instances. The following tools work with Traffic Mirroring:

Zeek — For more information, see the Zeek Network Monitor Security website.
Suricata — For more information see the Suricata website.

Reference :

ECS Fargate with mounted EFS

anil augustine chalissery — Wed, 31 Aug 2022 05:17:19 +0000

Amazon Elastic File System (Amazon EFS) provides simple, scalable file storage for use with your Amazon ECS tasks. With Amazon EFS, storage capacity is elastic, growing and shrinking automatically as you add and remove files. Your applications can have the storage they need, when they need it.

You can use Amazon EFS file systems with Amazon ECS to access file system data across your fleet of Amazon ECS tasks. That way, your tasks have access to the same persistent storage, no matter the infrastructure or container instance on which they land. When you reference your Amazon EFS file system and container mount point in your Amazon ECS task definition, Amazon ECS takes care of mounting the file system in your container. The following sections help you get started using Amazon EFS with Amazon ECS.

This feature is supported by tasks that use both the EC2 and Fargate launch types, however this tutorial will use an Amazon ECS task that uses the Fargate launch type. This tutorial is also meant to be followed step by step, however if you already have some of these resources created on your account then you may be able to skip some steps.

The following resolution applies to the Fargate platform version 1.4.0 or later, which has persistent storage that you can define at the task and container level in Amazon ECS. Fargate platform versions 1.3.0 or earlier don’t support persistent storage using Amazon EFS.
Amazon EFS may not be available in all Regions. For more information about which Regions support Amazon EFS, see Amazon Elastic File System Endpoints and Quotas in the AWS General Reference.

Before you complete the steps , you must have the following:

Create and configure an Amazon EFS file system

Create an Amazon EFS file system, and then note the EFS ID and security group ID.

Note: Your Amazon EFS file system, Amazon ECS cluster, and Fargate tasks must all be in the same VPC.

To allow inbound connections on port 2049 (Network File System, or NFS) from the security group associated with your Fargate task or service, edit the security group rules of your EFS file system.
Update the security group of your Amazon ECS service to allow outbound connections on port 2049 to your Amazon EFS file system’s security group.

Create a task definition

Open the Amazon ECS console.
From the navigation pane, choose Task Definitions, and then choose Create new Task Definition.
In the Select launch type compatibility section, choose FARGATE, and choose Next Step.
In the Configure task and container definitions section, for Task Definition Name, enter a name for your task definition.
In the Volumes section, choose Add volume.
For Name, enter a name for your volume.
For Volume type, enter EFS.
For File system ID, enter the ID for your Amazon EFS file system.

Note: You can specify custom options for Root directory, Encryption in transit, and EFS IAM authorization. Or, you can accept the default, where “/” is the root directory.

Choose Add.

In the Containers Definition section, choose Add container.
In the STORAGE AND LOGGING section, in the Mount points sub-section, select the volume that you created for Source volume in step 5.
For Container path, choose your container path.

(Optional) In the ENVIRONMENT section, for Entry point, enter your entry point.
For Command, enter the [df ,-h] command to display the mounted file system.

Note: You can use the entry point and command to test if your Amazon EFS file system is mounted successfully. By default, the container exits after the df -h command executes successfully.

Choose Add.
Fill out the remaining fields in the task definition wizard, and then choose Create.

Run a Fargate task and check your task logs

Run a Fargate task using the task definition that you created earlier.

Important: Be sure to run your task on the Fargate platform version 1.4.0.

To verify that your Amazon EFS file system is successfully mounted to your Fargate container, check your task logs.

The output of df-h looks similar to the following: