Transform is not supported in SERVICE_MANAGED permission model

[PeterBengtson]

I'm trying to install the CloudWatch2S3-additional-account.template as a StackSet in eu-north-1 and us-east-1, but I get the following error message:

Transform is not supported in SERVICE_MANAGED permission model

Unfortunately there is no way to specify the permission model for StackSets.

Is this a known issue?

[kichik]

I have a feeling removing the last line of Transform: AWS::Serverless-2016-10-31 will fix the issue. I didn't see any usage of the transform but I only looked for a few seconds. Can you try removing that line and seeing if it works?

You may also have to remove this part:

  AWS::ServerlessRepo::Application:
    Author: CloudSnorkel
    Description: Logging source for CloudWatch2S3 from a separate AWS account. Deploy
      CloudWatch2S3 to your main account first.
    HomePageUrl: https://github.com/CloudSnorkel/CloudWatch2S3
    Labels:
      - cloudwatch
      - s3
      - export
    LicenseUrl: LICENSE
    Name: CloudWatch2S3-additional-account
    ReadmeUrl: README.md
    SemanticVersion: 1.0.0
    SourceCodeUrl: https://github.com/CloudSnorkel/CloudWatch2S3
    SpdxLicenseId: MIT

[PeterBengtson]

Removing those lines fixes the syntax, but running the template yields

ResourceLogicalId:Subscriber, ResourceType:Custom::Subscriber, ResourceStatusReason:Received response status [FAILED] from custom resource. Message returned: See the details in CloudWatch Log Stream: 2022/06/17/[$LATEST]128be64879a64b03a1bb02f4e84f679f (RequestId: 53503608-f253-4787-8855-c34afe996f0a).

... after which deployment stops, of course. And those logs are unfortunately not accessible.

[kichik]

You can choose to not rollback when deploying. Not 100% if that's possible with StackSets though.

[PeterBengtson]

I'll look into it, but meanwhile: is there anything you can suggest I do? Custom resources can be notoriously difficult to debug, because of the indirection. Grateful for any help; this will be used in a system of 500+ accounts, so StackSets are vital here.

[kichik]

That log is the only way to resolve it. That said, the log should still be there. Nothing in the stack deletes it on stack destruction. The log should stay behind after the stack is deleted.

[PeterBengtson]

The log doesn't give much information, but through experimentation I found that it had to do with not specifying the new account number in the main template.

The need to update things whenever a new account is created - which in our system will happen several times a day - is not a practical one. I'm thus modifying your code to allow the whole AWS Organization to stream logs using a Condition. This requires creating a Role specifically for this purpose. I'll let you know when I'm done adapting your code in case you want to use my changes

[kichik]

Oh yeah OU would be awesome here.

[PeterBengtson]

Hi, still working on the OU, but I thought I'd send you what I've got so far, as Ive solved the 6MB reingestion/retry problem in the Log Processor lambda. It's actually one of the Lambda Blueprints - AWS Support pointed me in the right direction. I've enclosed an archive with a couple of extra files - the lambda code in the template has been stripped of comments, but you can find them in the loose file. Cheers, / Peter

[PeterBengtson]

The Log Processor role needed a couple more permissions. New archive enclosed.

[kichik]

Where have you enclosed the archive? I can't see it.