The HashiCorp Terraform AWS provider team is:
- Kit Ewbank, Engineer - GitHub @ewbankkit
- Graham Davison, Engineer - GitHub @gdavison
- Dirk Avery (Federal), Engineer - GitHub @YakDriver
- Zoe Helding, Engineer - GitHub @zhelding
- Simon Davis, Engineering Manager - GitHub @breathingdust
- Kerim Satirli, Developer Advocate - GitHub @ksatirli
- Justin Retzolk, Technical Community Manager - GitHub @justinretzolk
The Cloud Control provider is wholly generated from AWS CloudFormation schema. This means no manual work is required to add new features or services to the provider, and practitioners can expect to use AWS services within days of the AWS's launch rather than potentially wait for community support to prioritize that feature for inclusion. The standard AWS Provider is manually written and is the product of thousands of contributors and years of work.
There are a few reasons why this might happen:
At present, we plan to release the provider weekly, rolling up any additions from AWS collecting over the preceding week. This means you could wait up to a week to see the service in the provider. We do plan to narrow this gap as the provider reaches GA status.
The Cloud Control API is only compatible with the latest version of the CloudFormation schema. While many CloudFormation resource schemas are now updated to use this latest version (and all new services will use it at launch), there will be a period where some AWS services still use the prior version. AWS are updating all services using the older schema to use the newer one. To see which services are supported you can refer to the provider documentation or use the following AWS CLI command:
$ aws cloudformation list-types --type RESOURCE --visibility PUBLIC --provisioning-type FULLY_MUTABLE --filters Category=AWS_TYPESThis command lists all AWS resources that are usable with Cloud Control.
It's possible that as AWS release new services, the code which generates the provider may contain bugs which prevent a specific resource to be added. It's also possible, that a CloudFormation resource schema exhibits a configuration that we haven't encountered before and requires special handling. We will exclude those resources until we are able to resolve those issues.
We release weekly on Thursday rolling up the preceding week's CloudFormation additions/enhancements. For this reason there may be a delay of up to a week before a feature available in AWS can be usable in the provider. We do plan to narrow this gap as the provider reaches GA status.
AWS are aiming for 100% coverage of their AWS service area in CloudFormation. New services will nearly always launch with CloudFormation support, and older services will be updated in time. Please refer to the CloudFormation Open Coverage roadmap for more details or to upvote the service you would like to see coverage for.
The CloudFormation schema doesn't cover all API actions, and I can’t do what I used to do with the classic provider?
CloudFormation takes a different approach to the existing Terraform AWS Provider and typically does not model more operational concerns in its schema focusing exclusively on configuration. At this time we do not intend to customize the generated resources to add this functionality, but this is under active consideration. We expect this to be a rare occurrence, but do want to hear from you if you feel this is impeding your usage.
The AWS Cloud Control provider is a great complementary provider to add to your existing Terraform configurations using the standard AWS provider. The standard AWS provider is relied on in production for thousands of companies and workloads, and most practitioners will have significant experience and established practices for using it. However, if a service is unavailable from the standard AWS Provider, you can easily add the AWSCC provider to their existing Terraform configurations alongside the standard AWS provider. The Cloud Control provider will give you close to day one access to the newest AWS services and features.
Not at this time. There are no plans to deprecate the existing provider at this time, and we plan to fully support it for the foreseeable future. We are actively researching possibilities to ease potential migrations.
Contributing to this provider will be very different from the prior AWS provider but we will accept PR’s to help with any aspects of code generation, runtime and documentation. We will not accept any PR’s which alter or modify the behavior of generated resources at this time, but would love to hear where you think this is necessary.