Using "--no-associate-public-ip-address" creates a cluster with no instances

[PettitWesley]

I ran the following:
ecs-cli up --keypair MyFirstKeyPair --capability-iam --size 2 --instance-type t2.medium --no-associate-public-ip-address --cluster ITHINKIFOUNDABUG

The command succeeded and everything seemed normal (no errors)- but when I checked my cluster there were no container instances present. I then ran ecs-cli up again without the --no-associate-public-ip-address flag and a cluster was successfully created and had container instances.

[PettitWesley]

This is not a bug with the CLI- it was a user error- the instances were correctly created. However, since the instances lacked public IPs, they were not discoverable by ECS, and thus I could not start tasks and the ECS Console displayed that there were no instances in the cluster.

This is because I had failed to set up my VPC properly. I should have set up a NAT Gateway to allow the ECS Agent on my instances to connect to the external internet. Creating a VPC with Public and Private Subnets (NAT)

It may be useful to add a simple validation in the ECS CLI (or at least something in the help text) that vpc and subnet flags must be present when the --no-associate-public-ip-address flag is used.

[petderek]

I ran into this too, even when using vpc and subnet flags. Your diagnosis is correct though. If we want --no-associate-public-ip-address to work correctly, end users need to set up a NAT.

It might be worth setting up a guard rail that prevents users from creating a cluster that has neither a public ip nor a NAT. In these cases, the ecs agent cannot communicate with the ecs service.

[desyncr]

A small warning when using --no-associate-public-ip-address without passing --subnets / --vpc flags would save novice users (like me!) a couple of hours.