AWS Fargate, a fully managed compute engine for containers, provides a scalable, cost-efficient, and secure alternative to managing EC2 instances for AWS ECS clusters. Terraform is an Infrastructure-as-Code tool that allows you to define and provision cloud infrastructure resources using simple and declarative configuration files. By migrating to Fargate, businesses can save time and money while enabling development teams to focus solely on developing applications. This blog will explore how Terraform can automate your migration from EC2 to Fargate.
What is AWS Fargate?
AWS Fargate eliminates the need to manage servers or clusters and simplifies the process of building and deploying applications. Fargate supports Amazon ECS, Amazon EKS, and Amazon ECR to deploy container-based applications. It’s a serverless computing engine for containers without you having to provide an underlying EC2 instance for running containers. Serverless computing is an innovative cloud-based architecture that allows developers to build and run applications without managing infrastructure.
Fargate manages the underlying compute resources, allowing you to focus on building, running, and scaling applications. With Fargate, you can specify the CPU and memory resources needed for your tasks and applications. Fargate also supports auto-scaling, allowing applications to scale up or down based on demand.
Running ECS with Fargate eliminates the need to configure and scale any underlying EC2 instances. You create a cluster, add packaged application containers, specify the resource CPU and memory requirements, define networking and IAM policies, and launch the application. Each Fargate task has its own isolated space and does not share the kernel, elastic network interface (ENI), CPU, or memory resources with other tasks.
Make Your AWS Fargate Journey Easier with Automation
Assuming that you use one of the popular infrastructure provisioning tools like Terraform, CloudFormation, or Pulumi to automate your ECS services deployment. In this blog, we guide you through the required changes in the migration script.
When you work with Terraform, implemented configurations are reusable and can be shared across various projects. An application inside a container can be launched, lifted, and managed quickly and easily using AWS Fargate and Terraform. You can write code that describes the desired state of your infrastructure and then apply that code to create the resources needed to automatically support your applications. This includes everything from EC2 instances to load balancers, security groups, and more.
Terraform provides several additional benefits to ease migration. For example, it allows you to apply version control to your infrastructure code, which makes it easier to collaborate on changes and roll back to previous versions if needed. Terraform also enables you to test changes to your infrastructure in a staging environment before deploying to production, so you can catch issues early and reduce the risk of downtime. It also integrates with other tools like AWS CodePipeline to create a streamlined, automated deployment pipeline that can further simplify the migration process.
Personally, I prefer Terraform for infrastructure automation. It is a powerful Infrastructure-as-Code (IaC) tool and the developers use it to gain prominence in the industry. Many learning materials are available online and the Terraform offers good community support.
Getting Started
Migrating your container from ECS to Fargate is relatively easy. First and foremost, modify some fields to say “FARGATE.” Now, let’s guide you through the required changes in a Terraform script for the migration.
- Launch type
- Networking
- CPU and Memory settings
- IAM roles and Permissions
- Load balancer’s Target Type
- Logging
- Volumes
To migrate Amazon ECS service to Fargate, you have two launch-type options: EC2 and Fargate. The default launch type is EC2; it offers greater control over your infrastructure servers. These servers are EC2 instances that you manage. You need to specify “Fargate” as the launch type. This field change allows you to deploy containerized applications to ECS without managing the underlying EC2 instances.
“requiresCompatibilities” is an optional parameter with its value set to “FARGATE.” It ensures that the Fargate task definition parameters are compatible with the specified launch type. If no value is specified, it defaults to “EC2.”
An important change when migrating to Fargate is the network configuration. The default value of the “networkMode” property is “bridge,” which is used by ECS. Fargate works only with “awsvpc” network mode. You must change the value to “awsvpc” in your task definition.
This means that every task has its own Elastic Network Interface (ENI). Tasks will also have their own IPv4 address from the deployed subnet. This address assignment allows multiple applications or copies of a single application to run on the same port number without conflicts. Also, you can assign different security groups to each task at the container level, which gives you more fine-grained security. You can assign an application just the minimum permissions it needs, greatly enhancing security.
The Fargate launch type CPU and memory are defined at the task level. This definition is typically the maximum amount of memory and CPU usage your task or container can consume. The values depend on each other, so check this link for supported combinations. A memory allocation of at least 512MB or greater is required for each task. If you are unsure about CPU or memory requirements, start with a bigger size, watch your application usage in Cloudwatch, and adjust the size accordingly.
Check if your ECS instance uses a service-linked role named “AWSServiceRoleForECS.” This service usually already exists in your AWS account and might end up attached to your ECS service. Please remove it, as it is not needed anymore.
With a Fargate launch type task, your need to specify the execution role in the task definition. The role labeled “execution_role_arn” is what you need to launch the task by Fargate. Amazon ECS provides the managed policy named “AmazonECSTaskExecutionRolePolicy” which contains the set of permissions required to interact with other AWS services, such as Amazon ECR and CloudWatch, among others.
Here’s the updated terraform block with changes highlighted in green:
To use the AWS managed ECS task execution role you would do something like this:
The default target type of the load balancer “TargetGroup” is instance. You must change the “TargetType” to “IP” when deploying to Fargate. Also, verify that the port of the “TargetGroup” is now the same as your container port.
The updated terraform block with changes highlighted in green:
If you’re using the Fargate launch type for your tasks, the tasks cannot talk to any other container or process on the same host while using a third-party tool to handle logging or metrics. An example of this type of tool is DataDog, a platform for IT infrastructure and application performance monitoring.
If that is the case, you can add these agents to your task definition and run them as “sidecars,” or you can use an AWS Lambda function to forward logs from CloudWatch.
To turn on the Fargate-supported log drivers, you need to add the required “logConfiguration” parameters to your task definition for the logging. Examples of log drivers include “awslogs,” which sends container logs to CloudWatch, or “splunk,” or “awsfirelens.”
Add the below log configuration to your container definitions:
“Volume” is an optional parameter that you can specify to add volumes to your containers. A container volume is a logical storage unit in a container platform used to store and manage application data. Fargate supports non-persistent empty data volumes for containers.
This is what our container definition looks like after migrating to Fargate:
Post migration, your platform looks like this:
Benefits of Migration
Migrating from Amazon EC2 to Amazon Fargate offers many business benefits, such as cost savings, improved scalability and availability, enhanced security, and simplified management.
- No more EC2 instances to manage: There are no EC2 instances for you to manage, maintain, and patch. Also, you’ll have no AMI or security updates, which means zero management overhead for developers. You will get more time to focus on developing applications.
- Cost savings: Fargate is highly cost-effective as you pay for what you use, and there is no over-provisioning. You will be charged for only running containerized tasks as the service uses CPU and memory resources-based pricing.
- Scaling: Scaling your Fargate tasks is almost instantaneous. You can dynamically scale your running tasks based on CPU, memory, and other metrics. You no longer have to deal with scaling EC2 “fleets” for your containers or taking care of bin packing to get your instance to run cost-effectively.
- Compliance and security: Using Fargate gives you out-of-the-box security. Containers running on the AWS Fargate Launch Type now meet the criteria for ISO, PCI, SOC 1, SOC 2, and SOC 3 compliance, along with the requirements for HIPAA eligibility.
Conclusion
AWS Fargate offers businesses a powerful combination of scalability, cost-efficiency, and improved security. By migrating from EC2 to Fargate, companies can simplify the process of building and deploying applications, free up valuable developer time, and reduce costs.
Migrating from AWS ECS to Fargate is straightforward when you use Terraform or similar automation tools. You just need to change a few fields and configuration parameters in the Terraform script to move your service to Fargate. ECS running on Fargate can deliver a serverless experience, significantly changing how you build, deploy, and scale your applications. We hope this guide has provided valuable insights and guidance for your migration journey and look forward to seeing its positive impact on your business.
Ravi Kant
Practice - Application Development
Published Jun 06 2023
