DEV Community: Saurabh Kumar Singh

Difference between AWS Security Groups and NACL

Saurabh Kumar Singh — Wed, 25 Dec 2024 22:38:51 +0000

Hi Techie,

Today, we will discuss the most common topics in AWS: security groups and NACL. A common interview question is, “What is the difference between Security Groups and NACL?” So, let’s discuss both topics in detail.

Basic Architecture of Security Group and NACL in AWS

Security Group

Security Group is a stateful firewall for the EC2 instances to control inbound and outbound traffic. It acts like a virtual firewall that can be attached to the instance or instances.

Below are the basic attributes of security groups:

For inbound and outbound traffic we can put separate rules.
There are no inbound rules for the newly created security group. To allow communication from another host to your EC2 instance, you need to add them to the inbound rules of a security group.
By default, all the outbound traffic is allowed in a newly created security group. However, you can remove this and set outbound rules as per your requirement.
security group rules are always permissive i.e You can not specify deny rules, you need to always define allow rules.

How newly added security group looks like in AWS:

Security Group Inbound and Outbound Rule Fields:

Both the Inbound and Outbound rules have almost the same rule fields.

**Type: **Type of traffic which can be SSH, SMTP, ICMP, etc. It also has a Custom Protocol option, which allows you to select other port range.
Protocol: Same like type it could be autofill based on Type selection or can be specific custom.
Port Range: You can specify a single port or a range of port e.g. 5001 – 6000
Source (Inbound rule): It could be single IP, anywhere (0.0.0.0/0) or CIDR range.
Destination (Outbound rule): It could be single IP, anywhere (0.0.0.0/0) or CIDR range.
Description: This is an optional field but recommends adding a description that helps the team to understand the purpose of the rule.

Network Access Control List

NACL is a stateless virtual firewall that works at the subnet level. Everything both Inbound and Outbound traffic is allowed in default NACL. In NACL you need to specify explicitly what to block in Inbound and Outbound Rules.

A default NACL will be created when we create a new VPC and it allows ALL Inbound Traffic and Outbound Traffic. If we don’t associate a Subnet to a user-defined NACL then default NACL will be attached to that Subnet. A default NACL looks like this :

NACL Inbound and Outbound Rule Fields

Rule Number: Rules are evaluated starting with the lowest numbered rule. If a rule matches, it gets executed without checking for any other higher-numbered rules.
**Type: **Type of traffic which can be SSH, SMTP, ICMP, etc. It also has a Custom Protocol option, which allows you to select other port range.
Protocol: Same like type it could be autofill based on Type selection or can be specific custom. Port Range: You can specify a single port or a range of port e.g. 5001 – 6000
Source (Inbound rule): It could be single IP, anywhere (0.0.0.0/0) or CIDR range.
Destination (Outbound rule): It could be single IP, anywhere (0.0.0.0/0) or CIDR range.
Description: This is an optional field but recommends adding a description that helps the team to understand the purpose of the rule.
Allow/Deny: Specifies whether to allow or deny traffic.

Now the question is “What is the difference between Security Group and NACL?”

Firewall behavior is the major feature that will make security groups different from NACL. A security group is stateful while NACL is Stateless.

Stateful: Security Group is called a Stateful Firewall because SG maintains the state of a connection that means if an instance sends a request, the response traffic from outside is allowed back irrespective of the inbound rules and vice versa.

Example:- Let suppose In the security group you have blocked all the inbound traffic and allows all the outbound traffic. Now I visit a website on my ec2 instance, the response from the WebServer back to my ec2 instance will be allowed even you have set no traffic for an inbound rule.

Security group achieves this by Connection Tracking. Security Groups use Connection Tracking to keep track of connection details that flows in and out of an ec2 instance, this information includes – IP address, Port number, and some other metadata.

Stateless: NACL does not maintain connections detail, which means it is stateless. if some traffic is allowed in NACL Inbound Rule, the response Outbound traffic is not allowed by default unless specified in the Outbound Rules.

Key Differences between Security Group and NACL :

Security Group	NACL
It works at instance level.	It works at subnet level.
All inbound traffic blocked by default.	All inbound and outbound traffic allows by default.
Only allow rule can be add	Allow and deny both the rules can be added
Stateful	Stateless
Multiple SGs can be associated with an ec2 instance	Only one NACL can be associated with a single subnet
Evaluates all Rules and finds the most permissive rule	Evaluates starting with the lowest numbered rule till a rule matches.

How to Estimate Cloud Costs with Terraform using Infracost

Saurabh Kumar Singh — Fri, 20 Dec 2024 16:47:43 +0000

Managing, optimizing and estimating cloud costs has become critical to running efficient and cost-effective operations in today’s cloud-centric world. As organizations increasingly rely on Infrastructure as Code (IaC) tools like Terraform to manage their cloud infrastructure, the need for integrated cost estimation and financial operations (FinOps) practices is more important than ever. This article explores leveraging Infracost for accurate cloud cost estimates and adopting FinOps best practices to streamline your Terraform-managed infrastructure.

The Importance of Cloud Cost Estimates

Understanding the cost implications of your infrastructure decisions is fundamental to effective cloud management. Accurate cloud cost estimates enable teams to:

Budget Accurately: Ensure that cloud expenses align with financial forecasts and budgets.
Optimize Resources: Identify cost-saving opportunities by analyzing spending patterns and optimizing resource utilization.
Promote Cost-Aware Culture: Embed a cost-conscious culture within development teams, ensuring cost considerations are part of the decision-making process.

How to use Infracost with Terraform?

Terraform is a widely used IaC tool that allows developers to define and provision cloud resources using declarative configuration files. By integrating Infracost, a tool designed for real-time cost estimation, into your Terraform workflows, you can gain valuable insights into the cost implications of your infrastructure changes before deployment.

Prerequisites

A machine (for this guide, I am using Amazon Linux )
Terraform CLI
An AWS account

STEP 1 – Install Infracost
Get the latest Infracost release. The simplest method is to use the installation script.

# Downloads the CLI based on your OS/arch and puts it in /usr/local/bin
curl -fsSL https://raw.githubusercontent.com/infracost/infracost/master/scripts/install.sh | sh

infracost --version # Should show 0.10.37

STEP 2 – Get the API key
Please register for a free API key, which the CLI uses to fetch prices from our Cloud Pricing API, such as retrieving prices for different instance types.
infracost auth login

You will be redirected to the Infracost login page, where you must complete the login process. Once done, the key will be stored on your server. You can retrieve the key by running the following command:

infracost configure get api_key 
# output should be ico-X8i4bg0xD6SBV9GT1QqtseF51S4V8Z0P

STEP 3 – Create a Terraform Configuration
Created a simple Terraform configuration file, which you can download from git [https://github.com/cloudcuddlers/infracost-terraform]

STEP 4 – Initialize Terraform and generate a plan
Run the command init and plan to generate a terraform plan for your infrastructure as code.

terraform init
terraform plan -out=tfplan.binary

STEP 5 – Generate Infracost Cost Estimates
Run Infracost to generate a cost estimate for your Terraform configuration:

infracost breakdown --path=tfplan.binary --project-name=cloudcuddler

Now if you want to compare the cost with the previous version and the current version then you need to save the output in JSON format with the mentioned command

infracost breakdown --path=tfplan.binary --project-name=cloudcuddler --out-file previous_version.json --format json

Now you have added one more EC2 instance in your Terraform configuration file and again run the command

infracost diff --path=tfplan.binary --compare-to previous_version.json --project-name=cloudcuddler

As you can see, by adding another EC2 instance, Infracost captures this change from Terraform, reflecting the resulting increase in monthly costs.

Conclusion

By integrating Infracost into your Terraform workflows, you can gain valuable insights into the cost implications of your infrastructure changes before deployment. This ensures that cost efficiency is considered at every development lifecycle stage. Implementing FinOps best practices with Infracost helps promote a culture of cost awareness and drives financial and operational excellence in your cloud journey.