This message was deleted.

I’d love to be able to use awsx components as some of the heavy lifting is taken care of, but so far the only things I can think of is using pure

pulumi_aws

components and build each piece myself. Creating the VPC, then adding the additional cidr block, followed by the subnets, then everything else like nat gateway and internet gateway.

@icy-dress-83371 how would this look in terraform? How would you instantiate the module?

My invocation of the module would looks something like this:

locals {
  cluster_name = "${var.name}-${var.environment}"
  region       = var.aws_region
  sliced_azs   = slice(data.aws_availability_zones.available_azs.zone_ids, 0, var.number_of_azs)
  subnet_group_count  = 3

  tags = {
    Environment         = var.environment
  }
}

data "aws_availability_zones" "available_azs" {
  state = "available"
  exclude_names = [ "us-east-1e" ] #us-east-1e was not supporting EKS deployment
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  name                  = "${var.name}-${var.environment}-vpc"
  cidr                  = var.primary_vpc_cidr
  secondary_cidr_blocks = [var.secondary_vpc_cidr]
  azs                   = local.sliced_azs
  enable_nat_gateway    = true
  single_nat_gateway    = true
  enable_dns_hostnames  = true

  private_subnets = [
    for netnumber in range(0, length(local.sliced_azs)): 
        cidrsubnet(var.primary_vpc_cidr, ceil(log(length(local.sliced_azs) * local.subnet_group_count, 2)), netnumber) 
  ]

  public_subnets = [
    for netnumber in range(length(local.sliced_azs), length(local.sliced_azs) * 2): 
        cidrsubnet(var.primary_vpc_cidr, ceil(log(length(local.sliced_azs) * local.subnet_group_count, 2)), netnumber)
  ]

  intra_subnets = [
    for netnumber in range(length(local.sliced_azs) * 2, length(local.sliced_azs)): 
        cidrsubnet(var.secondary_vpc_cidr, ceil(log(length(local.sliced_azs) * local.subnet_group_count, 2)), netnumber)
  ]

  tags = {
    "<http://kubernetes.io/cluster/${local.cluster_name}|kubernetes.io/cluster/${local.cluster_name}>" = "shared"
  }
  public_subnet_tags = {
    "<http://kubernetes.io/cluster/${local.cluster_name}-primary|kubernetes.io/cluster/${local.cluster_name}-primary>" = "shared"
    "<http://kubernetes.io/role/elb|kubernetes.io/role/elb>"                    = "1"
  }
  private_subnet_tags = {
    "<http://kubernetes.io/cluster/${local.cluster_name}-primary|kubernetes.io/cluster/${local.cluster_name}-primary>" = "shared"
    "<http://kubernetes.io/role/internal-elb|kubernetes.io/role/internal-elb>"           = "1"
  }
}

ah, I see. We don’t support secondary cidr blocks on

awsx.ec2.Vpc

as a native input. However, you should be able to do this, because it’s just a resource https://github.com/terraform-aws-modules/terraform-aws-vpc/blob/master/main.tf#L53

Yeah, I have tried to add it as an additional component in my code above as you can see, and that works fine, but then there is a circular dependency. The

aws.ec2.VpcIpv4CidrBlockAssociation

requires a vpc_id. But in order for the VPC to be built (at least using

awsx.ec2.Vpc

) I need to provide subnet specs. I also don’t see how I would set the actual cidr for each subnet, when it only seems to allow a cidr_mask.

You will likely have to define the intra subnet yourself, not as an isolated subnet within the awsx.ec2.Vpc resource

Maybe I am just looking at this the wrong way, and am trying to use awsx when I shouldn’t be? Is there a maor benefit to trying to use the awsx components rather than just rolling my own with aws classic?

awsx is meant to solve the problem of a fairly simple VPC with public and private subnets. For your use case, you can bootstrap the public and private with awsx and then add your intra subnets

Yeah, that makes sense. I guess my only question is, is it worth bootstrapping the first portions with awsx. I guess the only thing I am really gaining is the automatic creation of the route tables and NAT for the public and private.

if you’re happy creating your own vpc, you’ll get more flexibility doing it yourself

Yeah, it seems so. I think I was putting too much stake in the awsx side of things. Coming from a terraform world, I saw it as the alternative to TF modules. But I think it is really more of an “Easy Button” for the most basic implementation of that resource.

personally I never used terraform modules, they broke all the time and they essentially just plumb every possibly API element through to the user, so it ended up being harded to understand what was happening. But that’s just me..

Yeah, sometimes they aren’t great, the ones I used the most was the VPC, but I think that was just because I didn’t want to write all the rest myself.

ha! Briggs originates where I grew up, so run across a lot them. Where are you based?

Toronto, Canada, but my family comes from Scotland

welcome to the community in any case! Let me know how else we can help, and sorry for the delay initially