DEV Community: Trevor Roberts Jr

Automating EKS Auto Mode Pod Subnet Range Customization with EKS Node Classes, Karpenter Node Pools, and Terraform

Trevor Roberts Jr — Mon, 23 Jun 2025 14:00:00 +0000

Introduction

On June 13, 2025, the EKS Auto Mode Node Class feature was updated to include podSubnetSelectorTerms and podSecurityGroupSelectorTerms parameters to specify subnets for pod IP addressing. You can use an EKS Node Class with a Karpenter Node Pool to specify additional configurations such as which types of instances to use for your workloads. You can then specify that Node Pool in any pod manifests that you deploy to your EKS Auto Mode cluster.

EKS clusters have supported pod-specific subnets since around 2019/2020, and it is great to see this feature come to EKS Auto Mode clusters. Now, how do we simplify using this feature? Let's automate it!

EKS Node Class and Karpenter Node Pool Creation...powered by Terraform!

Prerequisites:

Deploy an EKS Auto Mode cluster with an authentication mode that includes the API option.
Create the subnets you want to use with your pods (I created a /21 in each of my availability zones).
(Recommended) Create a security group specifically for your pods rather than reuse your node's security group for the podSecurityGroupSelectorTerms parameter in the Node Class spec.
(Optional) Set a distinct tag in each of the pod subnets from step 2 to reference in the Node Class spec.

NOTE

The Node Class podSubnetSelectorTerms parameter requires you to either specify the subnet IDs you want to use with your pods or the tag you assigned to those subnets (see the documented example). I opted to use tags and assigned the tag of kubernetes.io/role/cni with a value of 1. The tag key and value do not matter; what matters is that the tag you specify in your Node Class spec matches the actual subnet tag.

For this blog, I will focus on the Terraform automation for the EKS Node Class and Karpenter Node Pool.

Feature Deployment Checklist

Before we write our Terraform, let's review the steps required to configure dedicated subnets for our pods.

Create a new IAM role and Instance Profile for the nodes that will run the pods with the custom IP addresses.
Create an EKS Access Entry for that IAM role that has the AmazonEKSAutoNodePolicy access policy.
Create your EKS Node Class with your podSubnetSelectorTerms and podSecurityGroupSelectorTerms parameters.
Create your Karpenter Node Pool to assign any other desired characteristics like instance types, spot vs on-demand, etc, and reference your Node Class in the Node Pool spec.
Deploy a sample workload that uses the Karpenter Node Pool.

Fortunately, the AWS and Kubernetes Terraform providers include all the necessary functionality to complete these tasks. All of my Terraform code for this blog can be found on GitHub, but I will focus on interesting code snippets here:

First, the Kubernetes nodes need IAM permissions to manage AWS resources including assigning the pod subnets:

resource "aws_iam_role_policy_attachment" "custom_nodeclass_worker_policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
  role       = aws_iam_role.custom_nodeclass_role.name
}

resource "aws_iam_role_policy_attachment" "custom_nodeclass_cni_policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
  role       = aws_iam_role.custom_nodeclass_role.name
}

resource "aws_iam_role_policy_attachment" "custom_nodeclass_registry_policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
  role       = aws_iam_role.custom_nodeclass_role.name
}

# VPC networking policy as well for the pod subnet functionality
resource "aws_iam_role_policy" "custom_nodeclass_vpc_policy" {
  name = "eks-t4g-nodeclass-vpc-policy"
  role = aws_iam_role.custom_nodeclass_role.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "ec2:DescribeSubnets",
          "ec2:DescribeNetworkInterfaces",
          "ec2:CreateNetworkInterface",
          "ec2:AttachNetworkInterface",
          "ec2:DeleteNetworkInterface",
          "ec2:DetachNetworkInterface",
          "ec2:ModifyNetworkInterfaceAttribute",
          "ec2:AssignPrivateIpAddresses",
          "ec2:UnassignPrivateIpAddresses"
        ]
        Resource = "*"
      }
    ]
  })
}

The Kubernetes nodes also need an EKS access entry with the AmazonEKSAutoNodePolicy access policy to join the EKS Auto Mode cluster:

resource "aws_eks_access_entry" "nodeclass_access_entry" {
  cluster_name      = local.cluster_name
  principal_arn     = aws_iam_role.custom_nodeclass_role.arn
  kubernetes_groups = []
  type             = "EC2"
}

resource "aws_eks_access_policy_association" "nodeclass_policy" {
  cluster_name  = local.cluster_name
  principal_arn = aws_iam_role.custom_nodeclass_role.arn
  policy_arn    = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy"

  access_scope {
    type = "cluster"
  }

  depends_on = [aws_eks_access_entry.nodeclass_access_entry]
}

Next comes the EKS Node Class and Karpenter Node Pool deployment. It is important to note that these are Kubernetes resources. As of this blog's publication date, it is not possible to use AWS APIs to create your Node Class nor your Node Pool. Hence we use the kubernetes_manifest resource type from the Terraform Kubernetes provider.

Notice the podSubnetSelectorTerm and the podSecurityGroupSelectorTerms parameters in the Node Class:

resource "kubernetes_manifest" "custom_nodeclass" {
  manifest = {
    apiVersion = "eks.amazonaws.com/v1"
    kind       = "NodeClass"
    metadata = {
      name = "t4g-nodeclass"
    }
    spec = {
      # Use the role NAME (not ARN)
      role = aws_iam_role.custom_nodeclass_role.name

      # Subnets for EC2 instances (nodes) - using tags for flexibility
      subnetSelectorTerms = [
        {
          tags = {
            "kubernetes.io/role/internal-elb" = "1"
          }
        }
      ]

      # Security groups for nodes
      securityGroupSelectorTerms = [
        {
          id = local.node_security_group_id
        }
      ]

      # Dedicated pod subnets - EKS Auto Mode will handle VPC CNI automatically
      podSubnetSelectorTerms = [
        {
          tags = {
            "kubernetes.io/role/cni" = "1"
          }
        }
      ]

      # Pod security groups (dedicated security group for pods)
      podSecurityGroupSelectorTerms = [
        {
          id = local.pod_security_group_id
        }
      ]

      # Let EKS Auto Mode manage networking automatically
      snatPolicy             = "Random"
      networkPolicy          = "DefaultAllow"
      networkPolicyEventLogs = "Disabled"

      # Ephemeral storage configuration optimized for t4g instances
      ephemeralStorage = {
        size       = "40Gi"
        iops       = 3000
        throughput = 125
      }

      # Tags for cost allocation and management
      tags = merge(
        local.common_tags,
        {
          NodeClass    = "t4g-nodeclass"
          InstanceType = "t4g-arm64"
          Purpose      = "general-workload"
        }
      )
    }
  }

  depends_on = [
    data.terraform_remote_state.eks_infrastructure,
    aws_eks_access_entry.nodeclass_access_entry,
    aws_iam_role.custom_nodeclass_role
  ]
}

# NodePool using the custom NodeClass
resource "kubernetes_manifest" "t4g_nodepool" {
  manifest = {
    apiVersion = "karpenter.sh/v1"
    kind       = "NodePool"
    metadata = {
      name = "t4g-nodepool"
    }
    spec = {
      template = {
        metadata = {
          labels = {
            nodepool-type = "t4g-arm64"
            billing-team  = local.project_name
            environment   = local.environment
          }
        }
        spec = {
          # Reference our custom NodeClass
          nodeClassRef = {
            group = "eks.amazonaws.com"
            kind  = "NodeClass"
            name  = "t4g-nodeclass"
          }

          # Requirements for t4g.small and t4g.medium only
          requirements = [
            {
              key      = "node.kubernetes.io/instance-type"
              operator = "In"
              values   = ["t4g.small", "t4g.medium"]
            },
            {
              key      = "kubernetes.io/arch"
              operator = "In"
              values   = ["arm64"]
            },
            {
              key      = "kubernetes.io/os"
              operator = "In"
              values   = ["linux"]
            },
            {
              key      = "karpenter.sh/capacity-type"
              operator = "In"
              values   = ["spot", "on-demand"]
            },
            # Distribute across all available zones
            {
              key      = "topology.kubernetes.io/zone"
              operator = "In"
              values   = local.availability_zones
            }
          ]

          # Node termination settings
          terminationGracePeriod = "30s"
        }
      }

      # Resource limits for the NodePool
      limits = {
        cpu    = "100"   # 100 vCPUs total limit
        memory = "400Gi" # 400 GiB memory total limit
      }

      # Disruption settings for cost optimization
      disruption = {
        consolidationPolicy = "WhenEmptyOrUnderutilized"
        consolidateAfter    = "30s"
        # expireAfter = "72h"  # Uncomment to auto-expire nodes after 72 hours
      }
    }
  }

  depends_on = [
    kubernetes_manifest.custom_nodeclass
  ]
}

Finally, I deploy a sample workload to verify that my pods get ip addresses from a different subnet than my nodes. Notice the nodeSelector parameter to specify our Node Pool:

resource "kubernetes_manifest" "test_deployment" {
  count = var.create_test_deployment ? 1 : 0

  manifest = {
    apiVersion = "apps/v1"
    kind       = "Deployment"
    metadata = {
      name      = "t4g-test-app"
      namespace = "default"
    }
    spec = {
      replicas = 2
      selector = {
        matchLabels = {
          app = "t4g-test-app"
        }
      }
      template = {
        metadata = {
          labels = {
            app = "t4g-test-app"
          }
        }
        spec = {
          # Node selector to target our t4g NodePool
          nodeSelector = {
            "nodepool-type" = "t4g-arm64"
          }

          containers = [
            {
              name  = "nginx"
              image = "nginx:alpine"
              ports = [
                {
                  containerPort = 80
                }
              ]
              resources = {
                requests = {
                  cpu    = "100m"
                  memory = "128Mi"
                }
                limits = {
                  cpu    = "200m"
                  memory = "256Mi"
                }
              }
            }
          ]
        }
      }
    }
  }

  depends_on = [
    kubernetes_manifest.t4g_nodepool
  ]
}

Verifying our work

If the configuration was successful, the terraform apply succeeds AND my pods and nodes are in different subnets. Let's use kubectl to verify.

Checking the Node

❯ kubectl describe node i-04ddfb1f83f3288fe
Name:               i-04ddfb1f83f3288fe
.
.
.
Addresses:
  InternalIP:   10.0.33.121
  InternalDNS:  ip-10-0-33-121.ec2.internal
  Hostname:     ip-10-0-33-121.ec2.internal

Checking the Pods

❯ kubectl get pods -o wide
NAME                            READY   STATUS    RESTARTS   AGE   IP            NODE                  NOMINATED NODE   READINESS GATES
t4g-test-app-5ccc4dcd59-6p5hp   1/1     Running   0          57s   10.0.41.144   i-04ddfb1f83f3288fe   <none>           <none>
t4g-test-app-5ccc4dcd59-8tfvx   1/1     Running   0          57s   10.0.41.145   i-04ddfb1f83f3288fe   <none>           <none>

Success! My node's subnet CIDR is 10.0.33.0/24, and my pods' subnet CIDR is 10.0.40.0/21; my node IP (10.0.33.121) and pod IPs (10.0.41.144 and 10.0.41.145) fit into their respective subnet IP ranges.

Wrapping Things Up...

In this blog post, we discussed EKS Auto Mode's support for pod-specific subnets by leveraging EKS Node Class and Karpenter Node Pool resources. Further, we demonstrated how to automate this process with Terraform.

If you found this article useful, let me know on BlueSky or on LinkedIn!

Allowing GCP Compute Resources to Assume AWS IAM Roles with Pulumi

Trevor Roberts Jr — Wed, 27 Dec 2023 18:35:19 +0000

Did you know that AWS IAM has built-in support for some well-known OIDC providers, including Google? Neither did I until I worked on a project that required GCP compute instances to securely access Amazon S3 buckets...

Introduction

Security is paramount in cloud native application design. This is especially true if you have resources running in multiple clouds that have interdependencies. I recently worked on such a project where GCP Compute Instances needed to access data in Amazon S3. For expediency, the GCP team requested static access keys, which I politely (I think 😅) refused. Instead, my team and I researched methods for GCP Compute Instances to use STS to dynamically-generate temporary credentials to assume an AWS IAM Role. We lucked out with this finding in the AWS documentation covering Creating Roles for OIDC Federated Identity Providers.

Out of the box, AWS IAM supports OIDC Federation with Amazon Cognito, Amazon.com, Facebook, and Google. It is possible to configure support for other Identity Providers (IdPs) besides these four (IF they offer federated OIDC), but that requires a little extra setup.

After reading the documentation I put together the high-level list of items I needed to configure and where:

GCP - create an IAM Service Account
GCP - deploy an Compute Instance
AWS - create an IAM Policy for Amazon S3 access
AWS - create an IAM Role with Trust configured to allow a web identity to assume it.

I enjoy pointing and clicking just about as much as you do. So, I used Pulumi to automate the creation of all four cloud resources along with an Amazon S3 bucket to validate that the policy worked properly.

Getting Started

First things first: ensure your AWS and GCP credentials are properly set in your development environment. Next, ensure Pulumi is installed and you can successfully run Pulumi's AWS Getting Started example. NOTE: I've been using Python recently. So, my example code will be in Python.

The Pulumi example only imports the AWS module for you. So, it will be necessary to import the GCP module as well. With Python, this can be accomplished by adding the GCP module to the requirements.txt file in the root of your Pulumi codebase:

pulumi>=3.0.0,<4.0.0
pulumi-aws>=6.0.2,<7.0.0
pulumi-gcp

Then, from the root of your Pulumi codebase, run pip install for the virtual environment generated during the Pulumi getting started example:

venv/bin/pip install -r requirements.txt

Finally, configure your GCP Project in your pulumi settings (NOTE: make sure you use the correct project id when you execute this command!)

pulumi config set gcp:project mahnamahna-muppets-196911

With these prerequisites out of the way, let's take a look at the code!

Imports

In an attempt to be minimalist, I only import the modules that I need.

import pulumi, json
from pulumi_aws import iam, s3
from pulumi_gcp import serviceaccount, compute

Create the GCP IAM Service Account

The first parameter is the name that Pulumi uses to identify the GCP resource it's creating. The account_id is what GCP will call the service account.

aws_service_access_sa = serviceaccount.Account("awsAccessServiceAccount",
    account_id="aws-service-access",
    display_name="AWS Service Access Service Account")

Create the GCP Compute Instance

With this Pulumi code, I create a simple GCP Compute Instance, and I make sure to assign the service account I created earlier.

aws_service_instance = compute.Instance("awsserviceaccess",
    machine_type="e2-micro",
    zone="us-east4-c",
    boot_disk=compute.InstanceBootDiskArgs(
        initialize_params=compute.InstanceBootDiskInitializeParamsArgs(
            image="debian-cloud/debian-11",
        ),
    ),
    network_interfaces=[compute.InstanceNetworkInterfaceArgs(
        network="default",
        access_configs=[compute.InstanceNetworkInterfaceAccessConfigArgs()],
    )],
    service_account=compute.InstanceServiceAccountArgs(
        email=aws_service_access_sa.email,
        scopes=["cloud-platform"],
    ))

Create the Amazon S3 bucket

Very simple Pulumi code to create an Amazon S3 bucket. PLEASE do not use the force_destroy parameter in production. This is my demo environment. So, I only used it for quick clean-ups.

# NOTE: Do not use the force_destroy option in PRODUCTION
#       I only used this setting because this is a demo environment.
aws_bucket = s3.Bucket('gcp-sa-access-bucket', force_destroy=True)

Create the AWS IAM Policy

This Pulumi code creates the AWS IAM Policy to allow access to the Amazon S3 bucket. Note that in Pulumi, we need to use the apply method when accessing the string value of a resource's output. This is due to Pulumi resource outputs being similar to a promise. You can read more in their documentation. TL;DR: you need to use the apply method to run a function that will insert the Pulumi resource output as a string into your code at runtime.

In this example, I am using the apply method with an anonymous function (aka Python Lambda) to insert the bucket's id instead of defining a separate function for this single purpose.

aws_iam_policy_bucket_read = iam.Policy("gcp-sa-access-bucket-read", policy=aws_bucket.id.apply(lambda name:
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:ListBucket",
                    "s3:HeadBucket"

                ],
                "Resource": [
                    f"arn:aws:s3:::{name}",
                    f"arn:aws:s3:::{name}/*"
                ]
            }
        ]
    }
))

Create the AWS IAM Role

I use another Python Lambda here to insert the GCP Service Account's unique id into the trust relationship policy. Notice the Action here is sts:AssumeRoleWithWebIdentity, and the Principal is accounts.google.com

aws_s3_read_only_role = iam.Role("awsS3ReadRole",
    assume_role_policy=aws_service_access_sa.unique_id.apply(lambda id:
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Federated": "accounts.google.com"
                },
                "Action": "sts:AssumeRoleWithWebIdentity",
                "Condition": {
                    "StringEquals": {
                        "accounts.google.com:aud": id
                    }
                }
            }
        ]
    }),
    managed_policy_arns=[
        aws_iam_policy_bucket_read.arn,
    ]
)

Thanks for sticking with me this far. Now, the fun starts as we run the pulumi up command. All the resources are deployed in less than 30 seconds.

To validate that everything worked correctly, I SSH'ed to my GCP Compute Instance, installed the AWS CLI, and ran the following command to generate my temporary credentials:

aws sts assume-role-with-web-identity \
    --role-arn arn:aws:iam::867530987654321:role/awsS3ReadRole-1969112 \
    --role-session-name "AWSS3access" \
    --web-identity-token $(gcloud auth print-identity-token) > assume-role-output

Finally, I exported my AWS access key, secret access key, and session token as environment variables and accessed my S3 content from my GCP Compute Instance!

export AWS_ACCESS_KEY_ID=ASIA**
export AWS_SECRET_ACCESS_KEY=82**
export AWS_SESSION_TOKEN=Fwo**

Even though my project used a GCP Compute Instance, this workflow is applicable to any GCP compute resource than can assume an IAM Service Account like your GKE Kubernetes Pods.

Wrapping Things Up...

In this blog post, we discussed how you can enable GCP compute resources to use the AWS IAM and STS services to securely access the AWS resources for which they have permissions. We used Pulumi to deploy the GCP IAM Service Account and Compute Instance and to deploy the Amazon S3 bucket and IAM Role and Policy. Finally, we demonstrated the GCP Compute Instance accessing the Amazon S3 bucket. If you would like take a look at the code, I hosted it on GitHub.

If you found this article useful, let me know on LinkedIn!

Modifying Application Behavior with Go Lambda Functions and AWS AppConfig Feature Flags

Trevor Roberts Jr — Fri, 07 Apr 2023 13:08:45 +0000

The Obi-Wan Kenobi series' depiction of the conflict between light and dark reminded me of a similar struggle faced by my favorite video game character: Cecil (Final Fantasy IV). I used AWS AppConfig Feature Flags to dynamically generate an information page about Cecil based on his decision...

Introduction

Developers can use AWS AppConfig for a simplified implementation of feature flags to alter an application’s behavior. My sample application displays information about a fictional character named Cecil. The displayed data varies according to Cecil's allegiance to the dark or to the light. If you don’t use feature flags today to modify your application behavior, read on to see how this feature may fit in with your upcoming projects!

What is AWS AppConfig?

AWS AppConfig is a capability built into AWS Systems Manager that allows developers to dynamically alter application functionality. In March 2022, the AWS AppConfig team made the Feature Flags capability generally available. This release added more functionality including setting constraints on the data types and acceptable values and rolling back feature flag updates based on CloudWatch alarms.

Why not use other services (ex: Amazon DynamoDB, Amazon S3, or Amazon ElastiCache)?

It is possible to use another service to manage your feature flag data. However, the advanced capabilties I mentioned earlier (i.e. feature flag validation and rollback) would need to be built into your application. When using AWS AppConfig, you can offload that complexity to AWS and focus on your core application code. To read more about AWS AppConfig's use cases, check out the documentation.

My Application

I created a simple web application that displays different character designs for Cecil depending on whether he remains a Dark Knight or becomes a Paladin.

Figure 01: Cecil Remains a Dark Knight

Figure 02: Cecil Becomes a Paladin

My application's frontend consists of an HTML page with an empty div tag that will be populated with code returned by a JavaScript query (credit to the AppConfig Feature Flags Workshop for the idea.)

The empty div tag:

    <div id="displayCecil">

    </div>

The JavaScript code to update the div content based on the Lambda function return data:

fetch('https://1234567890987654321abccba.lambda-url.us-east-1.on.aws/')
    .then(response => response.text())
    .then((data) => {
        document.getElementById("displayCecil").innerHTML = data;
        console.log(data);
    });

The JavaScript code is using my Lambda function's URL to obtain the information about Cecil to display in the browser. The Lambda function changes what data it returns based on the current setting of the AppConfig feature flag. I'll step through the lines of code relevant to AppConfig since I've done a walkthrough of how to write a Lambda function in Go in a previous blog post:

First, I initialize a client for the AppConfig service specific to retrieving data:

    // Create a AppConfigData client from the AWS Session.
    svc := appconfigdata.New(mySession)

I obtain a token that is required to make a query of the AppConfig service. I must specify my AppConfig application, configuration profile, and environment identifiers that I created in advance in the AppConfig service. This ensures my application is reading the correct feature flag data.

    token, err := svc.StartConfigurationSession(&appconfigdata.StartConfigurationSessionInput{
        // The ApplicationIdentifier for the application that depends on the feature flag.
        ApplicationIdentifier: jsii.String(ApplicationIdentifier),

        // The configuration profile ID or the configuration profile name.
        ConfigurationProfileIdentifier: jsii.String(ConfigurationProfileIdentifier),

        // The AppConfig environment ID (ex: dev, beta, prod, etc.).
        EnvironmentIdentifier: jsii.String(EnvironmentIdentifier),
    })

I then use the token to make a GetLatestConfiguration API call to the AppConfig service. This returns whatever is the latest value that the feature flag is set to.

    result, err := svc.GetLatestConfiguration(&appconfigdata.GetLatestConfigurationInput{
        ConfigurationToken: jsii.String(*token.InitialConfigurationToken),
    })

Finally, I create structs for the JSON data returned by the AppConfig service, and I use the feature flag data (featureFlagResults.Allegiance.Choice) to determine which HTML code should be returned by the Lambda function invocation.

    type featureflagdata struct {
        Choice  string
        Enabled bool
    }
    type featureflag struct {
        Allegiance featureflagdata
    }
    var featureFlagResults featureflag
    json.Unmarshal(result.Configuration, &featureFlagResults)
    CecilsChoice := featureFlagResults.Allegiance.Choice
    if CecilsChoice == "paladin" {
        return fmt.Sprintf(htmlPaladinOutput), nil
    }
    return fmt.Sprintf(htmlDarkKnightOutput), nil

FYI, the complete Lambda source code can be found on GitHub.

My application's feature flag is initially set to darkknight. I then update my feature flag as follows in the AWS AppConfig console (you can make your update via API and CLI as well):

I click on my AppConfig Application (blogAppConfigGo)

Figure 03: AWS AppConfig Service Home Page

I click on my feature flag (whichSide)

Figure 04: AppConfig Application Details

I click on edit.

Figure 05: Feature Flag Details

Notice the constraint textbox which lists the acceptable values for the feature flags. I update to paladin and click Confirm

Figure 06: Updating the Feature Flag

I click on Save new version (Yes! your feature flags are versioned for simplified rollback)

Figure 07: Save a New Feature Flag Version

I click on Start Deployment

Figure 08: Start the Feature Flag Deployment

I select my environment (prod...why not?) and select a Deployment strategy that dictates how the feature flag should be rolled out to your environment. I click Start deployment

Figure 09: Confirm the Deployment Parameters

I observe the deployment progress

Figure 10: Feature Flag Deployment Progress

My deployment is complete, and the application is adjusted as shown in Figure 02 earlier in the blog

Figure 11: Feature Flag Deployment Complete

AWS AppConfig and Go Lambda Functions

The AppConfig service features a simple integration using Lambda Layers for multiple runtimes. The Go runtime isn’t on the supported list today. However, you can try out the Lambda Layer capability by running through the AWS AppConfig Feature Flags Workshop. If you are a Go developer and like the Lambda Layers approach, please be sure to let your AWS account team know!

What's Next?

When using this service, make sure to lockdown IAM permissions for AppConfig configuration profile updates. It is advisable to use automation tooling to update your feature flag to reduce human error. One more feature to be aware of is that you can trigger feature flag update rollbacks in response to CloudWatch Alarms. In my next blog post, I'll share how I automated the creation of my application's AWS AppConfig feature flag with Pulumi.

If you found this article useful, let me know on Twitter!