Closed rjlohan closed 3 years ago
I like this explanation provided by @chgeorgeamzn
While custom resources have unfortunately already broken this assumption, I think it'd be simpler to avoid expanding to allow more uncommon unexpected resource type name patterns, especially since CloudFormation template recognition frequently relies on resource type patterns since AWSTemplateFormatVersion
is optional: https://github.com/aws-cloudformation/cfn-python-lint/issues/1171, https://github.com/aws-cloudformation/aws-cfn-lint-visual-studio-code/issues/99, https://github.com/aws/aws-toolkit-jetbrains/pull/1715#discussion_r421074217, https://github.com/github/super-linter/pull/231#discussion_r445708695, https://github.com/mwpearce/vscode-cfn-nag/issues/6, https://github.com/joenye/coc-cfn-lint/issues/3#issuecomment-678843159, https://github.com/aws-cloudformation/aws-cfn-lint-atom/issues/29
The public AWS::::Account
resource type will likely just be AWS::Organizations::Account
Some other resource types might be a bit more odd, but we should be able to find something suitable for them
To support certain partners or types where an Organization::Service::Resource namespace is hard to fulfil. Simple example;
AWS::::Account