Scope: CloudFormation is very powerful because it is developed and supported directly by AWS, but Terraform has a great community that always works at a fast pace to ensure new resources, and features are implemented for providers quickly.
Type: CloudFormation is a managed service by AWS, but Terraform has a CLI tool that can run from your workstation, a server, or a CI/CD system (such as Jenkins, GitHub Actions, etc.) or Terraform Cloud (a SaaS automation solution from HashiCorp).
License and support: CloudFormation is a native AWS service, and AWS Support plans cover it as well. Terraform is an enterprise product and an open source project. HashiCorp offers 24/7 support, but at the same time, the huge Terraform community and provider developers are always helpful.
Syntax/language: CloudFormation supports both JSON and YAML formats. Terraform uses HashiCorp Configuration Language (HCL), which is human-readable as well as machine-friendly.
Architecture: CloudFormation is an AWS-managed service to which you send/upload your templates for provisioning; on the other hand, Terraform is a decentralized system with which you can provision infrastructure from any workstation or server.
Modularization: In CloudFormation, nested stacks and cross-stack references can be used to achieve modularization, while Terraform is capable of creating reusable and reproducible modules.
User experience/ease of use: In contrast to CloudFormation, which is limited to AWS services, Terraform spans multiple cloud service providers such as AWS, Azure, and Google Cloud Platform, among others. This flexibility allows Terraform to provide a unified approach to managing cloud infrastructure across multiple providers, making it a popular choice for organizations that use more than one cloud provider.
Life cycle and state management: CloudFormation stores the state and manages it with the use of stacks. Terraform stores the state on disk in JSON format and allows you to use a remote state system, such as an AWS S3 bucket, that gives you the capability of tracking versions.
Import from existing infrastructure: It is possible to import resources into CloudFormation, but only a few resources are supported. It is possible to import all resources into Terraform state, but it does not generate configuration in the process; you need to handle that. But there are third-party tools that can generate configuration, too.
Verification steps: CloudFormation uses change sets to verify the required changes. Terraform has a powerful plan for identifying changes and allows you to verify your changes to existing infrastructure before applying them.
Rolling updates and rollbacks: CloudFormation automatically rolls back to the last working state. Terraform has no feature for rolling updates or rollbacks, but you can build a rollback system using a CI/CD system.
Multi-cloud management: CloudFormation is AWS-only, but Terraform supports multiple cloud providers and many more services.
Compliance integration: CloudFormation is built by AWS, so compliance is already assured, but for Terraform, you need to implement third-party tools yourself to achieve compliance.
Deployment type: CloudFormation has a built-in CI/CD system that takes care of everything concerning deployment and rollbacks. Terraform can be deployed from any system, but you need to build your CI/CD workflow or adopt a service that can fill the gaps.
Drift detection: Both tools have drift detection by default.
Cost: Using AWS CloudFormation does not incur any additional charges beyond the cost of the AWS resources that are created, such as Amazon EC2 instances or Elastic Load Balancing load balancers. In contrast, Terraform is an open source project that can be used free of charge. However, to obtain enterprise-level features such as CI/CD automation and state management, you may need to consider using additional services and systems provided by HashiCorp or third-party service providers. These additional services may come with their own costs.

You can use the AWS Management Console or the AWS CLI to create the cluster role.
AWS Management Console
Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Roles, then Create role.
Under Trusted entity type, select AWS service.
From the Use cases for other AWS services dropdown list, choose EKS.
Choose EKS - Cluster for your use case, and then choose Next.
On the Add permissions tab, choose Next.
For Role name, enter a unique name for your role, such as eksClusterRole.
For Description, enter descriptive text such as Amazon EKS - Cluster role.
Choose Create role.

We can scale up or scale down the resources through Auto scaling in AWS.

Auto scaling is classified as 3 parts:

* Auto Scaling group

* Launch Configuration/Template

* Scaling Policies 

Auto Scaling group : We can define a minimum and maximum require resources through Auto scaling group.

Launch Configuration/Template - Defined a AMI and other require resource parameter for the EC2 instance.

Scaling Polices: It is classified as 3 types:

* Manual - We can update the minimum and maximum resource requirement by manually or through CLI,

* Scheduling : We an schedule the desire resource requirement through crontab.

* Dynamic - It will increase the resource based on metrics.

* Network Load balancer
* Application Load balancer
* Classic Load balancer 

* Gateway Load balancer

Network Load balancer is routing the traffic through TCP/IP [Layer 4] & Application Load balancer is routing the traffic through https/http [Layer 7]

* ELB should have a minimum 1 listener is in active state, so that it will listen the traffic and routing into target group.

Class A - Address range [1 to 126] - Subnetmasking [255.0.0.0] - Used for large number of hosts
Class B - Address range [128 to 191] - Subnetmasking [255.255.0.0] - Used for medium size network
Class C - Address range [192 to 223] - Subnetmasking [255.255.255.0] - Used for local area network
Class D - Address range [224 to 239] - NA - Reserve for multi tasking
Class E - Address range [240 to 254] - NA - This is class is reserved for research and development purpose. 

Creating the VPC network:

Login into AWS console and navigate into VPC.

1)      Select the VPC only option.

We will get a more network option while selecting the VPC and more option. It will display the availability zone along with network CIDR.

2)      Select the IPv4 CIDR manual input in the IPv4 CIDR block section.

If there is an Amazon VPC IP address Manager (IPAM) address pool available in this region, you can get a CIDR from an IPAM pool. If you select an IPAM pool, the size of CIDR is limited by the allocation rules on the IPAM pool. The same will be applicable for IPv6 as well.

3)      Select a default zone, we can specific a different Tenant as well.

4)      Create a tag for grouping purpose and click on create VPC button.

We need to create a sub netmask according your requirement and mapped into VPC.

Click on subnet from the VPC dashboard.

Click on create subnet button and select the VPC which you want to create a sub netmask.

Define a subnet name and availability zone as per your requirement.

I can able to get 11 number of IP address as per my sub netmask and 5 IP address goes for reservation.

We need to create a internet gateway incase of access this machine from your system or outside world.

Creating an Internet Gateway:

Navigate into Internet gateway from left hand side of the VPC dashboard and clicked create Internet gateway button.

1) Community AMI
2) AWS Market place AMI
3) My AMI [User created image]