Transition to CloudFormation

[wizage]

Is your feature request related to a problem? Please describe.
Using Lambda's to deploy Elemental services is only a work around is not maintainable for new feature releases. Transitioning to CloudFormation deployment instead of Lambda deployment will provide more clear deployment and updating of infrastructure.

Describe the solution you'd like
To use just CloudFormation to deploy Elemental services instead of using Lambda to deploy the Elemental service.

Additional context
Waiting for service team.

[smp]

mediastore launched cloudformtion support: https://aws.amazon.com/about-aws/whats-new/2019/05/aws-elemental-mediastore-now-supports-aws-cloudformation/

[wizage]

Looking over MediaLive and MediaPackage they both have configurations that can be unique.

For MediaLive you can specify the output type, the current templates for the HLS out are:
full.json
hd.json
mobile.json
sd.json

Should we move forward with migrating these templates over to the new MediaLive CloudFormation or should we look at refactoring them?

MediaPackage outputs today are dynamically create from gop size, gop per segment, segment per playlist. Should we become more prescriptive with those and follow more of a template approach and allow people to edit the templates themselves instead of some of the variables like gop size.

@smp your thoughts would be great.

[smp]

For MediaLive, I think we should refactor into a single, well documented/understood profile that we think will be "good" for the majority of use-cases and then have a really simple way to customize the resource. This way, we're not getting too deep into the maintenance of each set of profiles.

MediaPackage is a bit more tricky because there's a lot of things users might want to do that we don't expose at all today, which, actually, makes me wonder why we even implement it at all. For instance, is there anything you can do with mediapackage from Amplify Video that separates it from MediaStore? Or are we just allowing it because it's there?

If we want to expose management/config of mediapackage through amplify video, that would be awesome, but we should take that in bite-sized chunks working backwards from user needs. Endpoint Config (multi-drm/protocol/filttering), Harvest Jobs, and VOD all seem like sprints, not just in terms of how to control/config them, but in how we expose them through the CLI.

I wouldn't be mad if we set mediapackage aside until

1. it has cfn support
2. it supports a workflow/user story that we're aiming to support
3. we have a clear way of managing the entire resource directly from the amplify project

[wizage]

Should also work on this #152