# Architect for EC2 capacity for Amazon ECS
<a name="launch-type-ec2"></a>

Use EC2 capacity for large workloads that must be price optimized.

When considering how to model task definitions and services using EC2, we recommend that you consider what processes must run together and how you might go about scaling each component.

As an example, suppose that an application consists of the following components:
+ A frontend service that displays information on a webpage
+ A backend service that provides APIs for the frontend service
+ A data store

For this example, create task definitions that group the containers that are used for a common purpose together. Separate the different components into multiple task definitions. The following example cluster has three container instances that are running three front-end service containers, two backend service containers, and one data store service container. 

You can group related containers in a task definition, such as linked containers that must be run together. For example, add a log streaming container to your front-end service and include it in the same task definition.

After you have your task definitions, you can create services from them to maintain the availability of your desired tasks. For more information, see [Creating an Amazon ECS rolling update deployment](create-service-console-v2.md). In your services, you can associate containers with Elastic Load Balancing load balancers. For more information, see [Use load balancing to distribute Amazon ECS service traffic](service-load-balancing.md). When your application requirements change, you can update your services to scale the number of desired tasks up or down. Or, you can update your services to deploy newer versions of the containers in your tasks. For more information, see [Updating an Amazon ECS service](update-service-console-v2.md).

![\[Application architecture example with three instances. Instance 1 has a Front-end service container and a database service container. Instance 2 and Instance 3 have a front-end service container and a backend service container.\]](http://docs.aws.amazon.com/AmazonECS/latest/developerguide/images/application.png)


# Container image pull behavior for EC2 and external instances on Amazon ECS
<a name="pull-behavior"></a>

The time that it takes a container to start up varies, based on the underlying container image. For example, a fatter image (full versions of Debian, Ubuntu, and Amazon1/2) might take longer to start up because there are a more services that run in the containers compared to their respective slim versions (Debian-slim, Ubuntu-slim, and Amazon-slim) or smaller base images (Alpine).

When the Amazon ECS agent starts a task, it pulls the Docker image from its remote registry, and then caches a local copy. When you use a new image tag for each release of your application, this behavior is unnecessary. 

The `ECS_IMAGE_PULL_BEHAVIOR` agent parameter determines the image pull behavior. The following options are available:
+ `ECS_IMAGE_PULL_BEHAVIOR`: `default`

  The image will be pulled remotely. If the pull fails, the cached image in the instance is used.
+ `ECS_IMAGE_PULL_BEHAVIOR`: `always`

  The image will be pulled remotely. If the pull fails, the task fails.

To speed up deployment, set the Amazon ECS agent parameter to one of the following values: 
+ `ECS_IMAGE_PULL_BEHAVIOR`: `once`

  The image is pulled remotely only if it wasn't pulled by a previous task on the same container instance or if the cached image was removed by the automated image cleanup process. Otherwise, the cached image on the instance is used. This ensures that no unnecessary image pulls are attempted. 
+ `ECS_IMAGE_PULL_BEHAVIOR`: `prefer-cached`

  The image is pulled remotely if there is no cached image. Otherwise, the cached image on the instance is used. Automated image cleanup is turned off for the container to ensure that the cached image isn't removed. 

Setting the `ECS_IMAGE_PULL_BEHAVIOR` parameter to either of the preceding values can save time because the Amazon ECS agent uses the existing downloaded image. For larger Docker images, the download time might take 10-20 seconds to pull over the network.