Update AMI for EC2 hosts

[MikeTheCanuck]

After deploying a test instance of the CF stack I noticed the following complaint about the ECS Agent version:

We spent a bunch of time last year manually updating ECS and Docker agent versions, but for whatever reason we didn't "twig" to the idea of just using newest AMI.

I'm looking into this for two reasons:

1. It's unlikely we'll have time to tackle migrating all the existing containers to Fargate - we need to deploy the new containers there first, which'll be time-consuming enough - so we need to have a stable EC2-based ECS infrastructure.
2. More urgently, we're having trouble getting requests to respond from the containers in a test instance of this stack, and it's hardly outside the realm of possibility that the agent versions are so old that they're incompatible with ALB.

[MikeTheCanuck]

Looking back through the reference architecture's PRs I am piecing together the evolution of the CF configuration to AWS Linux 2-based AMIs that require less manual tracking and updating:
https://github.com/aws-samples/ecs-refarch-cloudformation/pulls?utf8=%E2%9C%93&q=is%3Apr+ECSAMI

Our AMIs are horribly out of date - looks like they're still using AWS Linux 1, with AMI versions that are well over a year old, using the old AMI naming scheme, and are still hard-coded to the template.

It appears that the latest approach pulls the latest ECS-optimized AMIs from an SSM parameter, obviating the need to hard-code and periodically update the AMIs in the templates themselves:
https://github.com/aws-samples/ecs-refarch-cloudformation/blob/a257e226b33bd9d2a721e5afd9d7e8b66dbacfdc/infrastructure/ecs-cluster.yaml#L35

The only question I have about this approach is whether that SSM parameter is globally available - is. the /aws/ namespace something we have to add to our own SSM parameter store, or is this (like S3 buckets) something that gets defined in one place and doesn't have to be replicated in every AWS account?

[MikeTheCanuck]

Hey! I noticed that @iant01 had already logged an issue for this:
hackoregon/civic-devops#173

Wish I'd understood the solution earlier, but alas I'm a little slow some days.