Migrating to Fargate from ECS with EC2
You’ve heard all the reasons why you should migrate to Fargate, but what do you need to think about when doing a migration?
You have two options for deploying a containerised application to AWS ECS. With the EC2 launch type you deploy your applications to a fleet of EC2 instances which you manage. The Fargate launch type was announced in November 2017 and allows you to deploy applications to ECS without managing the underlying EC2 instances.
So you’ve decided that you want to migrate from the EC2 launch type to Fargate. The good news is that it’s a relatively easy migration. The time it takes to migrate can therefore easily be justified when considered in relation to the future time saved by not having to manage underlying EC2 instances.
Here I’ll go through a few things you should think about as part of a migration.
Networking
The biggest change when migrating to Fargate is the network configuration. The chances are, if you’re using the EC2 launch type, you won’t have specified a network mode for the ECS tasks. In this situation the default network mode of bridge is being used.
With the Fargate launch mode awsvpc is the only supported network mode. This means that rather than placing your underlying EC2 instances into subnets and applying security groups there, this is instead configured at the container level.
The good news is that the awsvpc network mode can also be used for containers running with the EC2 launch type. So if you’re looking for a way to breakup a Fargate migration into smaller sprints then making the network changes prior to migrating to Fargate would be a sensible approach.
Memory Allocation
When running containers on EC2 there is a shared pool of memory available to containers at the instance level. You’re therefore able to specify any value, or none, for the memory allocation of a task. If you have a large number of small services running on ECS you might therefore set low values for the memory allocation of each task.
With the Fargate launch type each container requires its own memory allocation and the minimum that can be allocated for a task is 512MiB. If you are migrating a large number of services which have a memory allocation less than this you’ll therefore need to take this change into account when making your post-migration cost projections.
You should also consider that a memory allocation of at least 512 is required for each task in an ECS service. So if you’re task is deployed with any sidecars, then each of the sidecars will also require a memory allocation of 512 or greater. This is something else that you should factor into any cost estimates.
Logging
When using the EC2 launch type you can use different log configurations, allowing you to easily ship logs to other systems for processing.
With Fargate the only log drivers which are supported at the moment are awslogs (for sending logs to CloudWatch) or splunk. In order to view your logs in other services, such as Datadog, you would need to use a Lambda function to forward logs from CloudWatch.
For large applications which are logging a lot of information, you would then need to consider Lambda costs and limits as part of the migration.
The good news is that AWS Fargate Firelens is currently in developer preview. This will allow you to send logs to FluentBit, an open source log processor and forwarder which can forward logs to a number of endpoints. However, because this requires the use of a sidecar you will again have to consider this cost in your estimates.
Conclusion
Migrating to Fargate is well worth the time you’ll invest in it. Fargate lets you deploy applications to ECS without spending time managing the underlying EC2 instances. By thinking about the above changes in advance you can simplify the migration process and avoid any nasty cost-surprises once the migration has been completed.
If you’re considering a migration but want to make sure you’re getting it right first time, The Scale Factory offers Design & Build services to help you make sure your new infrastructure is scalable, secure, manageable and available.
