That depends on ones perspective; it was always possible to use `Transform:` and your own in-Account lambda to do whatever crazy stuff you wanted to the specifi

That depends on ones perspective; it was always possible to use `Transform:` and your own in-Account lambda to do whatever crazy stuff you wanted to the specified structure: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/transform-section-structure.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... ( and its friend https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-macros.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... ); two of the existing ones were AWS::Include and AWS::Serverless however, that placed the burden upon the user to (a) ensure said lambdas were deployed, in every account, and (b) that the lambda worked reliably for all possible inputs It'd be like if python started shipping with a binding to jq: great for the places where it's available, but otherwise you need to have a strategy for when it's not. Now, the "cloudformation standard library" includes it OOtB which can help things like Fn::ForEach::TheAZs: [ "MyAZ", { Ref: Fn::GetAZs }, ... ] which previously was monster stupid to work around