New task type to allow cross-account deployment as a StackSet

[eduardomourar]

To leverage using more native AWS services, it would be nice if during a stack update we could run in StackSet mode. Here would a possible task using a ~~proposed UseStackSet boolean property~~ new task type called update-stackset:

RoleStackSet:
  Type: update-stackset
  Template: ./role.yml
  StackName: role-stackset
  DefaultOrganizationBindingRegion: us-east-1
  DefaultOrganizationBinding:
    IncludeMasterAccount: true
    Account: '*'
  Parameters:
    roleName: 'admin'

Where the actual deployment would become this in the end:

AWSTemplateFormatVersion: '2010-09-09-OC'

Parameters:
  roleName:
    Type: String

Resources:

  WrapperStackSet:
    Type: AWS::CloudFormation::StackSet
    OrganizationBinding:
      IncludeMasterAccount: true
    Properties:
      StackSetName: role-stackset
      PermissionModel: SELF_MANAGED
      AdministrationRoleARN: !Sub 'arn:aws:iam::${ManagementAccount}:role/${ManagementAccount.BuildAccessRoleName}'
      ExecutionRoleName: !GetAtt CurrentAccount.BuildAccessRoleName
      Capabilities:
        - CAPABILITY_NAMED_IAM
      Parameters:
        - ParameterKey: roleName
          ParameterValue: !Ref roleName
      TemplateBody: !ReadFile ./role.yml
      StackInstancesGroup:
        - DeploymentTargets:
            Accounts: Fn::EnumTargetAccounts DefaultOrganizationBinding ${account}
          Regions: Fn::EnumTargetRegions DefaultOrganizationBinding ${region}

[OlafConijn]

what you are describing i think sounds like "transpiling org-formation into stacksets". i guess you would want to do this entirely under the covers.

now, StackSets have positives and negatives as does org-formation. you would probably be combining a lot of these positives as well as the negatives... what are the positive aspects that this approach would bring and does it way up against the negatives?

does it depend on the usecase? or do you think this would always be a good idea?

i would probably think about this more as a Type: update-stackset than an attribute that i would seemingly be able to toggle on/off. just because there is not the possibility to change from update-stack to update-stackset and back.

[eduardomourar]

I think there are situations where it is not possible to use stacksets (e.g. completely asymmetrical deployments). But they are a good idea for very straight forward cross-account deployments. This would be a different way of achieving the same result, so not really positive vs. negative aspects.

I like the idea of creating a separate task type as long as the properties are kept in sync with the update-stacks.

[eduardomourar]

Just to clarify, not transpiling, because I would not expect to have the actual stackset template. Instead just let orgformation push to cloudformation hidden from the user (just like update-stacks where you don't the see the parameters values that were passed to cloudformation).

[eduardomourar]

Because we will be using the SELF_MANAGED model, this stackset can be deployed to any account in your organization and its instances can be deployed even to the your organization management account.