Reference amazon created ipv6 cidr block with smaller prefix

I want to create vpc with amazaon provided ipv6 cidr_block and then create smaller subnet (/64, since amazon provided subnets are /56) and assign this smaller cidr_block to subnet inside vpc, below is my code, it throws an error

│ Error: “2406:da1a:415:1800::/56/64” is not a valid CIDR block: invalid CIDR address: 2406:da1a:415:1800::/56/64

│ with aws_subnet.dbvpczsrdstestvpcanil_cmcsubnetexternal_4F398891,
│ on cdk.tf.json line 415, in resource.aws_subnet.dbvpczsrdstestvpcanil_cmcsubnetexternal_4F398891:
│ 415: “ipv6_cidr_block”: “${aws_vpc.dbvpczsrdstestvpcanil_cmcvpc_10707888.ipv6_cidr_block}/64”,

Can someone look into the code and tell me how can i achieve the above requirement.

test_vpc=Vpc(
                self,
                "test-vpc",
                cidr_block="10.10.0.0/16",
                enable_dns_hostnames=True,
                tags={**DEFAULT_TAGS, "Name": f"{stack_id}-test"},
                assign_generated_ipv6_cidr_block=True,
            )
Subnet(
                self,
                "subnet-external",
                tags={**DEFAULT_TAGS_CMC, "Name": f"{stack_id}-external"},
                cidr_block="10.10.0.0/16",
                availability_zone="ap-south-1",
                vpc_id=vpc.id,
                map_public_ip_on_launch=False,
                depends_on=[test_vpc],
                ipv6_cidr_block=test_vpc.ipv6_cidr_block.split("/")[0] + "/64"
            )

The above appears to be the main issue.

I also note you are using JSON HCL based upon this in the error │ on cdk.tf.json line 415

JSON HCL doesn’t have its own expression syntax, it sends the string through to be handled via the native syntax.

So test_vpc.ipv6_cidr_block.split("/")[0] + "/64"
should be something similar to: "${split(\"/\", test_vpc.ipv6_cidr_block)[0]}/64"

See the below code. You should be able to paste this into a .json.tf file and run terraform apply to see the outputs.
Note: TF doesn’t appear to support JSON comments the way I have done them, so you will need too remove all “//” prefixed lines.

I have also provided some alternative ways to obtain the CIDR networks using the cidrsubnet and cidrsubnets function, which could be more robust / reliable than the string interpolation approach.

{
    "locals": {
        // This is the supernet that we will be working with
        "supernet" : "2406:da1a:415:1800::/56", 

        // Used below in the output section
        "slash64_listofsubnets" : "${cidrsubnets(local.supernet,8 ,8 ,8)}"  
    },
    "output": {
        // JSON HCL doesn't have its own expression syntax, it sends the string through to be handled via the native syntax. 
        // Therefore the native syntax of the split function is required: split(separator, string)
        // Also note that JSON escapes are required here to pass the / character through to the native syntax surrounded by "".
        "network_part": {
            "value": "${split(\"/\", local.supernet)[0]}"
        },
        "mask_part": {
            "value": "${split(\"/\", local.supernet)[1]}"
        },
        "new_network_via_interpolation" :{
            "value": "${split(\"/\", local.supernet)[0]}/64"
        },

        // The below examples use the cidrsubnet function to create individual /64 subnets from the supernet
        // instead of using string manipulation as above.
        "slash64_subnet0" : {
            "value": "${cidrsubnet(local.supernet, 8, 0)}"
        },
        "slash64_subnet1" : {
            "value": "${cidrsubnet(local.supernet, 8, 1)}"
        },
        "slash64_subnet2" : {
            "value": "${cidrsubnet(local.supernet, 8, 2)}"
        },

        // The below example uses the cidrsubnets function to create a list of /64 subnets from the supernet
        // Which can then be referenced by index.
        "slash64_listofsubnets" : {
            "value": "${local.slash64_listofsubnets}"
        },
        "first_from_listofsubnets" : {
            "value": "${local.slash64_listofsubnets[0]}"
        }
    }
}

Using the JSON HCL format is unusual and typically used when generating portions of a configuration programmatically. Is this the case here? If not then for accessibility and familiarity (and the ability to get examples of code more readily usable) adopting the native HCL format might be worth considering.

Hope that helps.

Happy Terraforming

@ExtelligenceIT I am not using json hcl, the cdk for terraform allows to write code in python,typescript and it gets transpiled into hcl, I have pasted the infra code above which is in python Again for your reference

class DbVpcStack(TerraformStack):
    def __init__(
        self,
        scope: Construct,
        stack_id: str,
        region: str,
        dbvpc_cidr_block: str,
    ):
        super().__init__(scope, stack_id)
test_vpc=Vpc(
                self,
                "test-vpc",
                cidr_block="10.10.0.0/16",
                enable_dns_hostnames=True,
                tags={**DEFAULT_TAGS, "Name": f"{stack_id}-test"},
                assign_generated_ipv6_cidr_block=True,
            )
Subnet(
                self,
                "subnet-external",
                tags={**DEFAULT_TAGS_CMC, "Name": f"{stack_id}-external"},
                cidr_block="10.10.0.0/16",
                availability_zone="ap-south-1",
                vpc_id=vpc.id,
                map_public_ip_on_launch=False,
                depends_on=[test_vpc],
                ipv6_cidr_block=test_vpc.ipv6_cidr_block.split("/")[0] + "/64"
            )

Ah, that explains why it looked so unfamiliar. Thanks for clarifying.
Unfortunately python is somewhat outside my skillset. Is it possible to paste the transpiled JSON or HCL?

Aside from that, given the error you provided:

│ Error: “2406:da1a:415:1800::/56/64” is not a valid CIDR block: invalid CIDR address: 2406:da1a:415:1800::/56/64
│
│ with aws_subnet.dbvpczsrdstestvpcanil_cmcsubnetexternal_4F398891,
│ on cdk.tf.json line 415, in resource.aws_subnet.dbvpczsrdstestvpcanil_cmcsubnetexternal_4F398891:
│ 415: “ipv6_cidr_block”:

This part: 2406:da1a:415:1800::/56/64 looks like it is being incorrectly interpolated somewhere in your code. The /56 not being split and removed from the original CIDR string, prior to the /64 being appended.

Cheers!