AWS::Batch::ComputeEnvironment - When setting the "Type" property to any value that isn't "MANAGED"(case sensitive), this results in a false positive drift result.

[morries4321]

Describe the bug

When defining the Type property for the AWS::Batch::ComputeEnvironment resource via the "ManagedEc2EcsComputeEnvironment" construct or the "CfnComputeEnvironment" construct, if the value isn't set to MANAGED (case sensitive), this will result in a false positive drift result for this resource.

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Version

No response

Expected Behavior

Setting the AWS::Batch::ComputeEnvironment Type property to managed instead of MANAGED should not result in a false positive drift result.

Current Behavior

Reproduction Steps

#CDK code python example:
...
        batch_comp_env = batch.CfnComputeEnvironment(
            self,
            'BatchComputeEnv',
            type='managed',
...

#Synthesized template:
...
  BatchComputeEnv:
    Type: AWS::Batch::ComputeEnvironment
    Properties:
      Type: managed
...

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.131.0

Framework Version

No response

Node.js Version

20.11.0

OS

Windows 10

Language

TypeScript, Python, .NET, Java, Go

Language Version

No response

Other information

No response

[ashishdhingra]

@morries4321 Good afternoon. Thanks for reporting the issue. Let's take CDK out of picture for now.

• Creating a new CloudFormation stack using the below template (some of the information is redacted):

  Resources:
    TestComputeEnvironmentSecurityGroupC4C9D43C:
      Type: AWS::EC2::SecurityGroup
      Properties:
        GroupDescription: CdktestStack/TestComputeEnvironment/SecurityGroup
        SecurityGroupEgress:
          - CidrIp: 0.0.0.0/0
            Description: Allow all outbound traffic by default
            IpProtocol: "-1"
        VpcId: vpc-<<REDACTED>>
    TestComputeEnvironmentA7E8D9BE:
      Type: AWS::Batch::ComputeEnvironment
      Properties:
        ComputeResources:
          MaxvCpus: 256
          SecurityGroupIds:
            - Fn::GetAtt:
                - TestComputeEnvironmentSecurityGroupC4C9D43C
                - GroupId
          Subnets:
            - subnet-<<REDACTED>>
            - subnet-<<REDACTED>>
            - subnet-<<REDACTED>>
          Type: FARGATE
        ReplaceComputeEnvironment: false
        State: ENABLED
        Type: MANAGED
        UpdatePolicy: {}

  creates the AWS Batch compute environment of type Managed.
• Modifying the template to below (just changeing the Type from MANAGED to managed):

    Resources:
    TestComputeEnvironmentSecurityGroupC4C9D43C:
      Type: AWS::EC2::SecurityGroup
      Properties:
        GroupDescription: CdktestStack/TestComputeEnvironment/SecurityGroup
        SecurityGroupEgress:
          - CidrIp: 0.0.0.0/0
            Description: Allow all outbound traffic by default
            IpProtocol: "-1"
        VpcId: vpc-<<REDACTED>>
    TestComputeEnvironmentA7E8D9BE:
      Type: AWS::Batch::ComputeEnvironment
      Properties:
        ComputeResources:
          MaxvCpus: 256
          SecurityGroupIds:
            - Fn::GetAtt:
                - TestComputeEnvironmentSecurityGroupC4C9D43C
                - GroupId
          Subnets:
            - subnet-<<REDACTED>>
            - subnet-<<REDACTED>>
            - subnet-<<REDACTED>>
          Type: FARGATE
        ReplaceComputeEnvironment: false
        State: ENABLED
        Type: managed
        UpdatePolicy: {}

  updates the CloudFormation resource. In CloudFormation console, the drift is detected as reported by you.
  

It appears that CloudFormation is detecting drift by comparing the template with the previous version, which is not controlled by CDK. Looks like that's the way the drift is detected and appears to be working fine. In case you have additional concerns around it, please use the Feedback link in the AWS CloudFormation page to report the behavior to the team.

Thanks,
Ashish

[rjuengling-hf]

@ashishdhingra Thanks for taking a look at this.

If you just use the second template (Type has value managed) to create a new stack, CloudFormation will report drift. That is the issue--CloudFormation reporting drift when there is none.

This issue was filed with CDK because the higher-level construct ManagedEc2EcsComputeEnvironment produces a template where Type has value managed. Users of CDK therefore see false positive stack drift.

[ashishdhingra]

Using the below simple code:

const vpc = ec2.Vpc.fromLookup(this, 'DefaultVpc', { isDefault: true });
new batch.ManagedEc2EcsComputeEnvironment(this, 'TestManagedEc2EcsComputeEnvironment', {
  vpc
});

generates the below CFN template using cdk synth:

Resources:
  TestManagedEc2EcsComputeEnvironmentSecurityGroupBA8B1046:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: CdktestStack/TestManagedEc2EcsComputeEnvironment/SecurityGroup
      SecurityGroupEgress:
        - CidrIp: 0.0.0.0/0
          Description: Allow all outbound traffic by default
          IpProtocol: "-1"
      VpcId: vpc-<<REDACTED>>
    Metadata:
      aws:cdk:path: CdktestStack/TestManagedEc2EcsComputeEnvironment/SecurityGroup/Resource
  TestManagedEc2EcsComputeEnvironmentInstanceProfileRoleF19F86FA:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Action: sts:AssumeRole
            Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
        Version: "2012-10-17"
      ManagedPolicyArns:
        - Fn::Join:
            - ""
            - - "arn:"
              - Ref: AWS::Partition
              - :iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
    Metadata:
      aws:cdk:path: CdktestStack/TestManagedEc2EcsComputeEnvironment/InstanceProfileRole/Resource
  TestManagedEc2EcsComputeEnvironmentInstanceProfile6933F110:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Roles:
        - Ref: TestManagedEc2EcsComputeEnvironmentInstanceProfileRoleF19F86FA
    Metadata:
      aws:cdk:path: CdktestStack/TestManagedEc2EcsComputeEnvironment/InstanceProfile
  TestManagedEc2EcsComputeEnvironmentB9F1E5A6:
    Type: AWS::Batch::ComputeEnvironment
    Properties:
      ComputeResources:
        AllocationStrategy: BEST_FIT_PROGRESSIVE
        InstanceRole:
          Fn::GetAtt:
            - TestManagedEc2EcsComputeEnvironmentInstanceProfile6933F110
            - Arn
        InstanceTypes:
          - optimal
        MaxvCpus: 256
        MinvCpus: 0
        SecurityGroupIds:
          - Fn::GetAtt:
              - TestManagedEc2EcsComputeEnvironmentSecurityGroupBA8B1046
              - GroupId
        Subnets:
          - subnet-<<REDACTED>>
          - subnet-<<REDACTED>>
          - subnet-<<REDACTED>>
        Type: EC2
      ReplaceComputeEnvironment: false
      State: ENABLED
      Type: managed
      UpdatePolicy: {}
    Metadata:
      aws:cdk:path: CdktestStack/TestManagedEc2EcsComputeEnvironment/Resource
  CDKMetadata:
    Type: AWS::CDK::Metadata
    Properties:
      Analytics: v2:deflate64:H4sIAAAAAAAA/2WPTQrCMBSEz+I+jTYLPUAp4kKQegBJX181bfNS8lORkLvb+rMQVwPzDcOM4Pk255uVvLsMmj4bVM3j2UvoWYXOBAvIZnaJtfRw4/EoSV6xKUGU4Aqjx+CxpElZQxrJs6KlfzcxBDHXIgSr/GNvTRiX5I+RmJKax8oMuLCvHsh5SYAna1o1YEov+JmWGJkGeefWkxB8N//onFKZDeSVRl699QnYpevw5AAAAA==
    Metadata:
      aws:cdk:path: CdktestStack/CDKMetadata/Default
Parameters:
  BootstrapVersion:
    Type: AWS::SSM::Parameter::Value<String>
    Default: /cdk-bootstrap/hnb659fds/version
    Description: Version of the CDK Bootstrap resources in this environment, automatically retrieved from SSM Parameter Store. [cdk:skip]

After deploying it using cdk deploy and initiating drift detection, displays the following drift:

To avoid false drift, we should change the Type to MANAGED here.