Answers: <p>The short answer is "you don't have to".</p>
  
  <p>The long answer is I was doing it wrong. Here's what was wrong and what I learned.</p>
  
  <p>After working through <a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-cli-tutorial-fargate.html" rel="nofollow noreferrer">tutorials</a>, RTFMing and re-building my ECS configuration I found that I actually <strong>wasn't launching via Fargate</strong>. I had made a mistake during the initial <code>configure</code> command, so the default config was using EC2 launch type. When making the cluster it created an Autoscaling Group template with t2.micro in it, and then it was using this to launch the initial instance. I didn't think this was unusual, as I read that Fargate managed your EC2's for you, which I presumed was what was happening. No, this was "traditional" EC2 creation via a scaling template.</p>
  
  <p>I figured out the mistake by viewing the config file. I noticed <code>ecs-cli</code> doesn't have any "view config" commands - they only write to the config, so it feels a bit mysterious when you are issuing later commands, especially as <a href="https://github.com/aws/amazon-ecs-cli#configuring-defaults" rel="nofollow noreferrer">you are encouraged to set lots of defaults</a> (presumably to simplify the CLI commands which get long and cumbersome).</p>
  
  <pre><code>less ~/.ecs/config 
  
  version: v1
  default: MY-TRIAL-CONFIG
  clusters:
    MY-TRIAL-CONFIG:
      cluster: MY-TRIAL-CLUSTER
      region: ap-southeast-2
      default_launch_type: ""      &lt;= this was the problem
    tutorial:
      cluster: tutorial
      region: ap-southeast-2
      default_launch_type: FARGATE
  </code></pre>
  
  <p>So I then tried the EC2-only parameter:</p>
  
  <pre><code>ecs-cli up --instance-type "t2.small" --capability-iam
  </code></pre>
  
  <p>and this changed the Autoscaling Group and indeed launched a t2.small. So I now know how to do it the EC2 way.</p>
  
  <p>To do it properly as I had originally intended with Fargate, I needed <code>default-launch-type FARGATE</code>:</p>
  
  <pre><code>ecs-cli configure --cluster MY-TRIAL-CLUSTER --region ap-southeast-2 --default-launch-type FARGATE --config-name MY-TRIAL-CONFIG
  </code></pre>
  
  <p>Now the config looks like this:</p>
  
  <pre><code>less ~/.ecs/config 
  
  version: v1
  default: MY-TRIAL-CONFIG
  clusters:
    MY-TRIAL-CONFIG:
      cluster: MY-TRIAL-CLUSTER
      region: ap-southeast-2
      default_launch_type: FARGATE
    tutorial:
      cluster: tutorial
      region: ap-southeast-2
      default_launch_type: FARGATE
  </code></pre>
  
  <p>After doing this, <code>ecs-cli compose service up</code> works very differently from the observed ECS launch flow.</p>
  
  <ol>
  <li>it doesn't create any Autoscaling stuff</li>
  <li>it doesn't launch any EC2 instances (I thought Fargate did, but managed it for you, but you don't get to see the container hosts)</li>
  <li>It created a Cloudformation Stack instead (interestingly with a t2.micro EcsInstanceType parameter)</li>
  <li>It's very clearly labelled on the Cluster home page: there's a row for EC2 launch types below the FARGATE row. </li>
  </ol>
  
  <p>e.g.</p>
  
  <pre><code>MY-TRIAL-CLUSTER &gt;
  FARGATE
  1          0             1
  Services   Running tasks Pending tasks
  
  EC2
  0        0             0                                              0
  Services Running tasks Pending tasks CPUUtilization MemoryUtilization Container instances
  </code></pre>
  
  <p>It's very clear now I see it. There are no instances for Fargate services.</p>
  
  <p>You can also watch Fargate re-start the task-containers if they fail, either in the control panel, or with <code>ecs-cli compose service ps</code> and <code>ecs-cli logs --task-id XXX --follow</code>, to get a feel for the magic and how the Docker Compose features are being performed.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-12-13T23:18:15.993Z
Answers: 2018-12-13T23:18:15.993Z
Answers: scipilot
Body: <p>I am trialling AWS ECS for the first time. I've run through <a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-cli-tutorial-fargate.html" rel="nofollow noreferrer">the tutorials</a> and now I'm trying to deploy an existing Docker Compose suite which I've been using on Digital Ocean for some time.</p>
  
  <p>I have four containers in my composition, an ExpressJS app, NGinx, MemcacheD, and a Python Flask API. These work OK on a Digital Ocean 1GB RAM host. </p>
  
  <p>I've been following the guide and specs here: <a href="https://github.com/aws/amazon-ecs-cli#launching-an-aws-fargate-task" rel="nofollow noreferrer">https://github.com/aws/amazon-ecs-cli#launching-an-aws-fargate-task</a> and other general ECS CLI guides.</p>
  
  <p>I've got ECS to make the cluster+service from the docker YAML (with a few tweaks), but when I try to UP the service, I get an error that the t2.micro EC2 which Fargate boots isn't big enough:</p>
  
  <pre><code>INFO[0016] (service CI) was unable to place a task because no container instance met all of its requirements. 
  The closest matching (container-instance ...) has insufficient memory available. 
  For more information, see the Troubleshooting section of the Amazon ECS Developer Guide.
  </code></pre>
  
  <p>So I'd like to force it to boot an t2.small (2GB RAM) or higher.</p>
  
  <p>I see that you cannot directly tell Fargate to use a specific instant type from ECS - that setting is only for "EC2" direct, but I want to use Fargate to automate the instance management.</p>
  
  <p>I have tried using the <code>task_size</code> memory parameter (which I believe to be the correct way of informing Fargate of your application's requirements?) but this doesn't affect the choice of EC2 instance type which Fargate boots - it still boots the default t2.micro.</p>
  
  <p>I added this YML file with <code>--ecs-params</code>:</p>
  
  <pre><code>version: 1
  task_definition:
    task_size:
      cpu_limit: 512
      mem_limit: 2GB
  </code></pre>
  
  <p>When I rebuild my cluster from scratch with this definition, I can see the 2GB is correctly configured under the taskDefinition page (<code>console.aws.amazon.com/ecs/home#/taskDefinitions/...</code>) - so the configuration is provided OK, but when I view the instance it's booted, it's still a t2.micro with 1GB RAM.</p>
  
  <p>Am I misunderstanding the task_size.memory parameter?</p>
  
  <p>EDIT:<br>
  I was mistaken in thinking the 2GB setting would influence the host instance size. This is not the case: <code>ecs-cli up</code> brings up the cluster and instance long before the docker-specified services are created by <code>ecs-cli compose service up</code> which reads those task params.</p>
  
  <p>The task size parameter is per TASK which in Docker Compose terms are "services" (I think of them as containers plus exec params). So as I have four services, there will be four ECS tasks. To get the four tasks to fit inside a 1GB host therefore, task size should be 256MB (not 2GB!)</p>
  
  <p>task_definition:
    task_size:
      cpu_limit: 512
      mem_limit: 0.5GB</p>
  
  <p>This now gets further creating the services, without the memory error. I don't quite understand why (as 0.5GB x 4 is still too big). </p>
  
  <p>So while this has avoided the error, I still want to know how to create a larger instance when performing <code>ecs-cli up</code> with Fargate.</p>
  
Tags: <amazon-web-services><docker-compose><amazon-ecs>
Title: How do you instruct AWS FARGATE to provision a t2.small via ECS CLI instead of the default micro?
UserDisplayName: scipilot
ThreadText: # How do you instruct AWS FARGATE to provision a t2.small via ECS CLI instead of the default micro?
  
  (Asked by: username_0 on 2018-12-09)
  
  I am trialling AWS ECS for the first time. I've run through [the tutorials](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-cli-tutorial-fargate.html) and now I'm trying to deploy an existing Docker Compose suite which I've been using on Digital Ocean for some time.
  
  I have four containers in my composition, an ExpressJS app, NGinx, MemcacheD, and a Python Flask API. These work OK on a Digital Ocean 1GB RAM host.
  
  I've been following the guide and specs here: <https://github.com/aws/amazon-ecs-cli#launching-an-aws-fargate-task> and other general ECS CLI guides.
  
  I've got ECS to make the cluster+service from the docker YAML (with a few tweaks), but when I try to UP the service, I get an error that the t2.micro EC2 which Fargate boots isn't big enough:
  
  ```
  INFO[0016] (service CI) was unable to place a task because no container instance met all of its requirements. 
  The closest matching (container-instance ...) has insufficient memory available. 
  For more information, see the Troubleshooting section of the Amazon ECS Developer Guide.
  
  ```
  
  So I'd like to force it to boot an t2.small (2GB RAM) or higher.
  
  I see that you cannot directly tell Fargate to use a specific instant type from ECS - that setting is only for "EC2" direct, but I want to use Fargate to automate the instance management.
  
  I have tried using the `task_size` memory parameter (which I believe to be the correct way of informing Fargate of your application's requirements?) but this doesn't affect the choice of EC2 instance type which Fargate boots - it still boots the default t2.micro.
  
  I added this YML file with `--ecs-params`:
  
  ```
  version: 1
  task_definition:
    task_size:
      cpu_limit: 512
      mem_limit: 2GB
  
  ```
  
  When I rebuild my cluster from scratch with this definition, I can see the 2GB is correctly configured under the taskDefinition page (`console.aws.amazon.com/ecs/home#/taskDefinitions/...`) - so the configuration is provided OK, but when I view the instance it's booted, it's still a t2.micro with 1GB RAM.
  
  Am I misunderstanding the task\_size.memory parameter?
  
  EDIT:  
  I was mistaken in thinking the 2GB setting would influence the host instance size. This is not the case: `ecs-cli up` brings up the cluster and instance long before the docker-specified services are created by `ecs-cli compose service up` which reads those task params.
  
  The task size parameter is per TASK which in Docker Compose terms are "services" (I think of them as containers plus exec params). So as I have four services, there will be four ECS tasks. To get the four tasks to fit inside a 1GB host therefore, task size should be 256MB (not 2GB!)
  
  task\_definition:
  task\_size:
  cpu\_limit: 512
  mem\_limit: 0.5GB
  
  This now gets further creating the services, without the memory error. I don't quite understand why (as 0.5GB x 4 is still too big).
  
  So while this has avoided the error, I still want to know how to create a larger instance when performing `ecs-cli up` with Fargate.
  
  **Tags:** amazon-web-services, docker-compose, amazon-ecs
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2018-12-13. Score: 1 | Accepted answer
  
  The short answer is "you don't have to".
  
  The long answer is I was doing it wrong. Here's what was wrong and what I learned.
  
  After working through [tutorials](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-cli-tutorial-fargate.html), RTFMing and re-building my ECS configuration I found that I actually **wasn't launching via Fargate**. I had made a mistake during the initial `configure` command, so the default config was using EC2 launch type. When making the cluster it created an Autoscaling Group template with t2.micro in it, and then it was using this to launch the initial instance. I didn't think this was unusual, as I read that Fargate managed your EC2's for you, which I presumed was what was happening. No, this was "traditional" EC2 creation via a scaling template.
  
  I figured out the mistake by viewing the config file. I noticed `ecs-cli` doesn't have any "view config" commands - they only write to the config, so it feels a bit mysterious when you are issuing later commands, especially as [you are encouraged to set lots of defaults](https://github.com/aws/amazon-ecs-cli#configuring-defaults) (presumably to simplify the CLI commands which get long and cumbersome).
  
  ```
  less ~/.ecs/config 
  
  version: v1
  default: MY-TRIAL-CONFIG
  clusters:
    MY-TRIAL-CONFIG:
      cluster: MY-TRIAL-CLUSTER
      region: ap-southeast-2
      default_launch_type: ""      <= this was the problem
    tutorial:
      cluster: tutorial
      region: ap-southeast-2
      default_launch_type: FARGATE
  
  ```
  
  So I then tried the EC2-only parameter:
  
  ```
  ecs-cli up --instance-type "t2.small" --capability-iam
  
  ```
  
  and this changed the Autoscaling Group and indeed launched a t2.small. So I now know how to do it the EC2 way.
  
  To do it properly as I had originally intended with Fargate, I needed `default-launch-type FARGATE`:
  
  ```
  ecs-cli configure --cluster MY-TRIAL-CLUSTER --region ap-southeast-2 --default-launch-type FARGATE --config-name MY-TRIAL-CONFIG
  
  ```
  
  Now the config looks like this:
  
  ```
  less ~/.ecs/config 
  
  version: v1
  default: MY-TRIAL-CONFIG
  clusters:
    MY-TRIAL-CONFIG:
      cluster: MY-TRIAL-CLUSTER
      region: ap-southeast-2
      default_launch_type: FARGATE
    tutorial:
      cluster: tutorial
      region: ap-southeast-2
      default_launch_type: FARGATE
  
  ```
  
  After doing this, `ecs-cli compose service up` works very differently from the observed ECS launch flow.
  
  1. it doesn't create any Autoscaling stuff
  2. it doesn't launch any EC2 instances (I thought Fargate did, but managed it for you, but you don't get to see the container hosts)
  3. It created a Cloudformation Stack instead (interestingly with a t2.micro EcsInstanceType parameter)
  4. It's very clearly labelled on the Cluster home page: there's a row for EC2 launch types below the FARGATE row.
  
  e.g.
  
  ```
  MY-TRIAL-CLUSTER >
  FARGATE
  1          0             1
  Services   Running tasks Pending tasks
  
  EC2
  0        0             0                                              0
  Services Running tasks Pending tasks CPUUtilization MemoryUtilization Container instances
  
  ```
  
  It's very clear now I see it. There are no instances for Fargate services.
  
  You can also watch Fargate re-start the task-containers if they fail, either in the control panel, or with `ecs-cli compose service ps` and `ecs-cli logs --task-id XXX --follow`, to get a feel for the magic and how the Docker Compose features are being performed.
  
  
  ---
  
  