Create simple, high-level composable abstractions for AWS services

[lukehoban]

The abstractions for Services and Tasks in @pulumi/cloud are nice, but the focus on being cloud-neutral has led to severe limitations for users who are working in AWS.

We have had many requests for simple, high-level and composable abstractions for working with the building blocks of AWS ECS Services, but without sacrificing the ability to configure the full breadth of AWS capabilities and integrations. This is similar to, and builds on top of, the existing Network and Cluster abstractions, as well as being at the same level of abstraction as the API component in the AWS package.

While motivated by ECS, many of the required building blocks should be usable more generally as high level components that can be composed into other pieces of AWS infrastructure - much like Network is a general purpose building block today.

The areas we want to present simple higher-level APIs include the following (in roughly priority order):

• Network/VPC
• Vpc/Subnet-Placement
• Cluster
• TaskDefinition
• Service
• ECR-based Docker images
• Load Balancing/TargetGroups/Listeners
• SecurityGroups
• AutoScaling Groups
• IAM roles/policies
• Service Discovery
• Metrics
• Alarms
• Dashboard
• RDS/Aurora
• Move things out of 'x' namespace.
• Remove nonsensical instance methods.
• Update examples to not use 'Cloud'.
• Do not use 'instance' as the name of the underlying aws resource. Re-consider instance naming pattern #82

Initial focus is on enabling the same sorts of apps that can be built with cloudaws.Service to be expressed naturally in just a few lines of code using the above abstractions - but without any significant limitations on expressivity relative to AWS capabilities.

As part of this process, we also want to document the API design guidelines for these kinds of APIs to inform future expansions into additional areas of the AWS APIs (and Azure, GCP, Kubernetes and others).

[joeduffy]

We have made some great progress this sprint. Moving out of the current sprint.

[lukehoban]

#51 is merged now, which includes progress on the first 7 items above. @CyrusNajmabadi could you update this issue with status and open new issues to track remaining work on individual APIs?

[CyrusNajmabadi]

Will do.

[CyrusNajmabadi]

We need an appropriate 'vpcplacement' abstraction to make it trivial for clients of the VPC and other components (like Tasks/Services) to specify which subnets they want to use. Added this to the list. as part of this, we should also audit our existing 'defaults' decisions to make sure they are appropriate.

[CyrusNajmabadi]

Moving out to 0.21. The core set of abstractions are complete and are available in aws-infra. The remainder are still high value, but would be worth doing in the next milestone.

[lukehoban]

We're "done" with the initial wave of this. Opened #167 to track further areas we may expand into.