Alrighty then! Left off with the an ECS cluster up and running, now it’s time to verify it’s working as expected then begin to lock it down. I’ve attached a load balancer in front of the container. Verification will occur by ensuring an HTTP response from the container responds as expected. Hmm, bad news kids: the load balancer isn’t balancing correctly. Application nodes respond in the expected manner. Happy that everything is still open for testing. Once we get the bastion host in place we will need to figure out how to provide a similar level of verification.

Turns out I didn’t set a security group so by default the load balancer was uanble to receive or transmit. Easy enough to fix with a security group. One catch I did run into was for the first time I had to specify a VPC ID for the group. I assume the load balancer uses the VPC to determine AZs to deploy to.

Now with the LBs working as I expect it is time to start locking down the docker hosts. The hosts need to connect to the orechestration system (Amazons), the registry, and allow traffic to the load balancer. One of the permissions, ec2:AuthorizeSecurityGroupIngress, allows the containers to modify the ingress rules for a security group. I’m guessin this allows the container to register with the load balancer. Although I’m a little uneasy about which security grou pit will modify I’ll have to accept it for now. Moving on, the load balancers really belong in the overlap between two regions on the graph: the reverse proxies target and the ingress into teh application pool.

I’m going to begin targeting the service to lock down then work my way out to the load balancers. This way I can make sure everything works in place and I don’t have to guess what went wrong. Probably would be better to work at it the other way, but time will tell.