Forem: Matt Lewis

Moving from Node Groups to NodePools on Amazon EKS

Matt Lewis — Sat, 21 Feb 2026 17:38:16 +0000

Background

In November 2019, AWS introduced the concept of Amazon EKS Managed Node Groups. With this, Amazon EKS would provision and manage the underlying EC2 instances as worker nodes, as part of an EC2 Auto Scaling Group. You could create, update or terminate a node with a single operation. When updating or terminating a node, EKS would handle these operations gracefully by automatically draining nodes to ensure applications stayed available. Futher enhancements allowed for node configuration and customisation through EC2 Launch Templates and custom AMIs, alongside support for EC2 spot instances.

However, the modern trend in Kubernetes is moving away from static node groups to dynamic node provisioning with tools like Karpenter for more flexible and cost-effective infrastructure management. With Amazon EKS Auto Mode, the recommendation is no longer to create traditional node groups. Instead, you create a Karpenter NodePool that defines the compute requirements. Amazon EKS Auto Mode provides two built-in node pools - system and general-purpose - which you cannot modify, but you can enable or disable. The general-purpose node pool provides support for launching nodes for general purpose workloads. It supports only amd64 architecture and uses only on-demand EC2 capacity in the C, M or R instance families.

What happens if you want to take advantage of spot instances?
What happens if you want to take advantage of Graviton?

Let's show how you can create a node pool to do just that.

Creating a Karpenter NodePool

The complete configuration files for this post can be found in the k8s\node-pool section of the code repository here. We can create it using the following command.

$ kubectl apply -f arm-nodepool.yaml
nodepool.karpenter.sh/arm-mixed-capacity created

The start of the arm-nodepool.yaml configuration file is as follows:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: arm-mixed-capacity

This tells us we are using the NodePool API with Karpenter. This uses the nodepools.karpenter.sh CRD which is installed by default with Auto Mode. The spec element provides the contract with Karpenter. It has the following high-level structure, and we will go through each one in order.

spec:
  disruption:   # when and how nodes can be replaced
  template:     # what a node looks like
  limits:       # optional safety rails
  weight:       # optional priority

Disruption

The disruption section describes the ways in which Karpenter can disrupt and replace nodes. This is used when Karpenter wants to remove empty nodes, replace under-utilised nodes with better fitting ones, or shrink the cluster to save money.

  # Disruption settings for node lifecycle management
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 10m  # Wait 10 minutes before consolidating

    # Disruption budgets to control how many nodes can be disrupted
    budgets:
      # During business hours: more conservative
      - nodes: "2"
        schedule: "0 9 * * mon-fri"  # 9 AM Mon-Fri
        duration: 8h
      # Outside business hours: more aggressive
      - nodes: "10%"

The consolidationPolicy describes which types of nodes Karpenter should consider for consolidation. There are 2 options:

WhenEmptyOrUnderutilized - Karpenter will consider all nodes for consolidation and attempt to remove or replace nodes when it discovers that the node is empty or underutilised and could be changed to reduce cost
WhenEmpty - Karpenter will only consider nodes for consolidation that contain no workload pods

The consolidateAfter field is the amount of time Karpenter should wait to consolidate a node after a pod has been added or removed from the node. We set this to 10 minutes to make sure the behaviour is not too aggressive, and gives the scheduler time to stabilise.

Disruption budgets are used to control how many nodes can be disrupted. There are two rules defined in this section. The first rule states that between 09:00 and 17:00 on Monday to Friday, Karpenter may disrupt at most 2 nodes at a time. The second rule states that Karpenter may disrupt up to 10% of all nodes at any time. This will not apply between 09:00-17:00 on Monday to Friday as the first rule is more restrictive and so wins out.

Template

The template section defines the exact shape, rules and constraints of every node that Karpenter is allowed to create as part of this NodePool.

  # Node template specification
  template:
    spec:
      # Termination grace period (24 hours)
      terminationGracePeriod: 24h

      # Node requirements
      requirements:
        # ARM architecture
        - key: kubernetes.io/arch
          operator: In
          values: ["arm64"]

        # Support spot and on-demand (prefer spot for cost)
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]

        # ARM instance types (Graviton) - diverse selection
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            # General purpose (M7g)
            - "m7g.medium"
            - "m7g.large"
            - "m7g.xlarge"
            - "m7g.2xlarge"
            # Burstable (T4g) - cost-effective for variable workloads
            - "t4g.medium"
            - "t4g.large"
            - "t4g.xlarge"
            # Compute optimized (C7g)
            - "c7g.large"
            - "c7g.xlarge"
            # Memory optimized (R7g)
            - "r7g.large"
            - "r7g.xlarge"

      # Node class reference (Auto Mode creates this automatically)
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default


      # Taints (optional - for dedicated ARM workloads)
      taints:
        - key: arch
          value: arm64
          effect: NoSchedule

The terminationGracePeriod field defines the amount of time that a node can be draining before Karpenter forcibly cleans it up.

The spec.requirements section provides more details about the nodes that can be created. There are a specified here as an example.

The kubernetes.io/arch key sets out the architecture for the node. Karpenter supports amd64 and arm64 nodes. This is how we support Graviton.

The karpenter.sh/capacity-type key is analogous to EC2 puchase options. The general-purpose NodePool only supports on-demand as a value, whereas he we specify both spot and on-demand. As multiple capacity types are specified, Karpenter will prioritise spot where available, but fallback to on-demand.

Note: AWS automatically applies Amazon EC2 Reserved Instance discounts to matching running on-demand EC2 usage, regardless of how these instances were launched. This means that you will get these discounts for instances launched by Karpenter

There are a number of instance type options

key: node.kubernetes.io/instance-type
key: karpenter.k8s.aws/instance-family
key: karpenter.k8s.aws/instance-category
key: karpenter.k8s.aws/instance-generation
key: karpenter.k8s.aws/instance-capability-flex

Note: Generally, instance types should be a list and not a single value. Leaving these requirements undefined is recommended, as it maximizes choices for efficiently placing pods.

Each NodePool must reference a NodeClass. A Node Class defines infrastructure-level settings that apply to groups of nodes in your EKS cluster, including network configuration, storage settings, and resource tagging. When you need to customize how EKS Auto Mode provisions and configures EC2 instances beyond the default settings, creating a Node Class gives you precise control over critical infrastructure parameters. For example, you can specify private subnet placement for enhanced security, configure instance ephemeral storage for performance-sensitive workloads, or apply custom tagging for cost allocation. In this case, we just reference the default Auto Mode NodeClass.

There is also an example shown on how to apply a taint to a NodePool. When a taint is applied to a NodePool, Karpenter will only place pods on the nodes that explicitly tolerate the taint. In the example, Karpenter will only place a workload on the node that explicitly states that it supports the ARM architecture.

# Toleration for the taint (if you added one)
tolerations:
- key: arch
    operator: Equal
    value: arm64
    effect: NoSchedule

Limits

The limits section is used to constrain the total size of the NodePool. The limits that are set prevent Karpenter from creating new instances, once they have been exceeded. This is done to prevent runaway costs.

  # Limits for this node pool
  limits:
    cpu: "1000"
    memory: 1000Gi

Weight

The weight field controls prioritisation when Karpenter has multiple NodePools to choose from for scheduling a pod. When multiple NodePools can satisfy the requirements for a pod, Karpenter will give priority to the NodePool with the highest weight. If the weight attribute is not specified, it will default to 0.

  # Weight for prioritization (higher = preferred)
  weight: 10

Karpenter will look to choose the cheapest feasible instance. It prefers NodePools where it can pack the pod more efficiently with other pending pods, and minimise wasted CPU / memory on the node.

Note: Based on the way that Karpenter performs pod batching and bin packing, it is not guaranteed that Karpenter will always choose the highest priority NodePool given specific requirements. For example, if a pod can’t be scheduled with the highest priority NodePool, it will force creation of a node using a lower priority NodePool, allowing other pods from that batch to also schedule on that node. The behavior may also occur if existing capacity is available, as the kube-scheduler will schedule the pods instead of allowing Karpenter to provision a new node.

Targetting the NodePool with a Deployment

In order to test the NodePool and show it working, we created a Deployment, which is a simple Nginx container. It can be deployed using the following command from the code repository.

$ kubectl apply -f arm-deployment.yaml
deployment.apps/arm-app created

We define a Deployment and give it the name of arm-app, which is also assigned a label of the same name.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: arm-app
  labels:
    app: arm-app

The next part of the manifest file tells Kubernetes to run 3 copies of the application, and to make sure they are labelled as app=arm-app

spec:
  replicas: 3
  selector:
    matchLabels:
      app: arm-app
  template:
    metadata:
      labels:
        app: arm-app

The manifest file then defines a nodeSelector which is a rule that states that these pods can only run on nodes with an architecture type of arm64. This matches the architecture of our NodePool. Kubernetes will only schedule the Pod onto nodes that match the labels specified.

# Node selector for ARM architecture
nodeSelector:
  kubernetes.io/arch: arm64

The next part of the manifest file moves onto affinity. Node affinity functions like the nodeSelector field but is more expressive and allows you to specify soft rules. In this case, we use preferredDuringSchedulingIgnoredDuringExecution with a weight of 100 to state that we want the Pod to run on a Spot instance, but if this cannot be scheduled, then it is fine to drop back to on-demand. This means that the Pod will not remain in a pending state if a Spot instance was not available, and so it is considered a soft rule.

# Prefer spot instances for cost savings
affinity:
nodeAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      preference:
        matchExpressions:
          - key: karpenter.sh/capacity-type
            operator: In
            values: ["spot"]

Finally, we use the containers section to say that we want to run a copy of nginx in each Pod, which half a CPU and 512 MB of memory reserved, but this can grow to a whole CPU and 1 GB or memory.

containers:
  - name: nginx
    image: nginx:latest  # Multi-arch image supports ARM64
    ports:
      - containerPort: 80
        name: http
    resources:
      requests:
        cpu: 500m
        memory: 512Mi
      limits:
        cpu: 1000m
        memory: 1Gi

We open up a number of additional terminal windows as we apply the Deployment, to give us more information on what exactly is happening in the background.

The first command lists all the nodes in the EKS cluster including a column showing their architecture and a column showing their capacity type. We can see that a node is in the Ready state which uses ARM and is a spot instance.

$ kubectl get nodes -L kubernetes.io/arch,karpenter.sh/capacity-type
NAME                  STATUS   ROLES    AGE     VERSION               ARCH    CAPACITY-TYPE
i-0d336c28e588123ae   Ready    <none>   2m22s   v1.34.3-eks-3c60543   arm64   spot

The second command lists the NodeClaim resources. A NodeClaim is a custom resource created by Karpenter. Here we can see the generated NodeClaim name is taken from the name of the NodePool with a random suffix. We can also see it is using spot capacity, and a supported instance family type.

kubectl get nodeclaims
NAME                       TYPE         CAPACITY   ZONE         NODE                  READY   AGE
arm-mixed-capacity-zw6vh   m7g.xlarge   spot       eu-west-2a   i-0d336c28e588123ae   True    3m

The next command describes all pods that have the label app=arm-app. This is the label that gets applied as part of the deployment. It filters the output to show the pod lifecycle events. Again, we can see from this that the pod is running on an ARM-based Graviton spot instance. The event timeline shows the lifecycle involved here. The pod is bound to a compatible node, it then downloads the latest nginx image from the container registry, the container is then created, and finally started.

kubectl describe pod -l app=arm-app | grep -A 20 Events

Name:             arm-app-6674bd9849-ld6fm
Namespace:        default
Priority:         0
Service Account:  default
Node:             i-0d336c28e588123ae/10.1.3.225
Start Time:       Tue, 27 Jan 2026 11:42:06 +0000
Labels:           app=arm-app
                  pod-template-hash=6674bd9849
Annotations:      <none>
Status:           Running
IP:               10.1.3.97
--
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  2m14s  default-scheduler  Successfully assigned default/arm-app-6674bd9849-ld6fm to i-0d336c28e588123ae
  Normal  Pulling    2m12s  kubelet            spec.containers{nginx}: Pulling image "nginx:latest"
  Normal  Pulled     2m9s   kubelet            spec.containers{nginx}: Successfully pulled image "nginx:latest" in 3.874s (3.874s including waiting). Image size: 61200811 bytes.
  Normal  Created    2m8s   kubelet            spec.containers{nginx}: Created container: nginx
  Normal  Started    2m8s   kubelet            spec.containers{nginx}: Started container nginx

We ran a similar command to list all of the pods running, and to show that the 3 replicas as specified in the deployment are running.

kubectl get pods -l app=arm-app -w
NAME                       READY   STATUS             RESTARTS   AGE
arm-app-6674bd9849-ld6fm   0/1     Pending             0          0s
arm-app-6674bd9849-76wzg   0/1     Pending             0          0s
arm-app-6674bd9849-2vnwx   0/1     Pending             0          0s
arm-app-6674bd9849-ld6fm   0/1     ContainerCreating   0          0s
arm-app-6674bd9849-76wzg   0/1     ContainerCreating   0          0s
arm-app-6674bd9849-2vnwx   0/1     ContainerCreating   0          0s
arm-app-6674bd9849-2vnwx   0/1     Running             0          7s
arm-app-6674bd9849-ld6fm   0/1     Running             0          7s
arm-app-6674bd9849-76wzg   0/1     Running             0          7s
arm-app-6674bd9849-ld6fm   1/1     Running             0          13s
arm-app-6674bd9849-76wzg   1/1     Running             0          13s
arm-app-6674bd9849-2vnwx   1/1     Running             0          13s

Get started with the Argo CD EKS Capability

Matt Lewis — Fri, 23 Jan 2026 14:49:00 +0000

Argo CD Overview

EKS Capabilities was announced at re:Invent 2025. These are Kubernetes-native platform features managed by AWS, that provide higher-level functionality. This post looks at the Argo CD capability.

Argo CD is a GitOps based continuous deployment tool. Your git repository becomes the source of truth, and Argo CD ensures that your cluster state matches what you have defined in git. AWS have been consistently guiding their customers towards GitOps for a number of years. AWS describe GitOps as being like a reference implementation of best practice with these 4 characteristics:

Desired state expressed declaratively
Desired state is immutable and versioned
Desired state is automatically applied from source
Desired state is continuously reconciled

Argo CD is used by most of AWS customers practicing GitOps in 2025, and has really emerged as its own de facto standard. More than 45% of Kubernetes end-users reported production or planned production use of Argo CD in the 2024 CNCF survey.

Setting up Argo CD Capability via Console

The quickest way to get up and running with Argo CD is via the console. In the EKS console there is a capabilities tab that shows which managed capabilities are deployed in the cluster and which are available.

From here, we can click the Create capabilities button, and tick the checkbox against Argo CD in the Deployment section, before clicking next.

This brings up the page where we configure the selected capabilities. The first thing to do is to either select an existing role for the capability role, or select the button to create a new role.

Finally, the Argo CD managed capability integrates with AWS Identity Centre for authentication, and uses RBAC roles for authorization. You select the existing instance of IAM Identity Centre which should be pre-populated when you click the drop down. The next step is to assign RBAC roles. This involves specifying an AWS user or group from AWS Identity Centre and assigning them to an Argo CD RBAC role of "Admin", "Editor" or "Viewer".

At this point, you can review and create the managed capability for Argo CD. To understand this process in more detail, we can step through how to setup the capability using IaC.

Setting up Argo CD Capability via IaC and CLI

The code samples required for this section are contained in the CloudFormation section of this GitHub repository.

Create an IAM Capability Role

The first step is to create an IAM Capability Role. EKS Capabilities use this role to act on your behalf, running controllers in EKS. EKS Capabilities introduced a new service principle called capabilities.eks.amazonaws.com. When you create the capability role, you need to ensure the trust policy trusts this new service principle. An example of the required trust policy is shown below which is available in a file named "argocd-trust-policy.json":

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "capabilities.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

We can create an IAM role with this trust policy using the following command:

aws iam create-role \
  --role-name ArgoCDCapabilityRole \
  --assume-role-policy-document file://argocd-trust-policy.json

Next we need to attach permissions to this Capability IAM Role based on the capability needs and what integrations are required. For example, for Argo CD you may need to give permissions to ecr or codecommit or codeconnection, depending on where your source is coming from. When choosing "Create Argo CD role" through the console, an IAM role with the AWSSecretsManagerClientReadOnlyAccess managed policy pre-selected is created. This managed policy provides read access to all secrets stored in Secrets Manager in your AWS account and is intended for getting started quickly. You have the flexibility to modify these permissions by unselecting this policy or adding different policies as needed.

We can this managed policy to the created role by using the following command:

aws iam attach-role-policy \
  --role-name ArgoCDCapabilityRole \
  --policy-arn arn:aws:iam::aws:policy/AWSSecretsManagerClientReadOnlyAccess

We can achieve the same in CloudFormation but in a single template. The AWS::IAM::Role config required is shown below, although we will use this as part of the CloudFormation template that creates the EKS Capability, so we can control it in a single stack.

  # IAM Capability Role for ArgoCD
  ArgoCDCapabilityRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: "RoleName"
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: capabilities.eks.amazonaws.com
            Action:
              - sts:AssumeRole
              - sts:TagSession
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AWSSecretsManagerClientReadOnlyAccess

Create EKS Capability

Finally, we can create the EKS Capability for Argo CD itself. The Argo CD capability is integrated with AWS Identity Centre (IDC). This ensures that single sign-on is enabled for the fully managed and hosted Argo UI instance and for Argo CLI. For this, you need to ensure that your identity centre configuration is passed into the capability when creating it.

The Argo CD IDC instance identifies the name of the IAM Identity Center instance that is used by your organization to get permissions for Argo CD to access your EKS cluster. Once the capability has been created, the Argo CD IDC instance cannot be edited.

We can retrieve the IDC Instance ARN directly from the console, or by running the following command:

aws sso-admin list-instances --region eu-west-2 --query 'Instances[0].InstanceArn' --output text

We need to identify the users or groups that should be assigned to be a particular Argo CD role. The users and groups you identify from your IDC instance defines the permissions that the Argo CD capability has to access your EKS cluster. In the command below I retrieve the User ID for the user called mattlewis:

aws identitystore list-users \
  --region eu-west-2 \
  --identity-store-id $(aws sso-admin list-instances --region eu-west-2 --query 'Instances[0].IdentityStoreId' --output text) \
  --query 'Users[?UserName==`mattlewis`].UserId' --output text

If I wanted to assign a Group rather than a User, then I need to retrieve a Group ID from Identity Centre. The following command retrieves the Group ID for a group called Admin:

aws identitystore list-groups \
  --region eu-west-2 \
  --identity-store-id $(aws sso-admin list-instances --region eu-west-2 --query 'Instances[0].IdentityStoreId' --output text) \
  --query 'Groups[?DisplayName==`Admin`].GroupId' \
  --output text

There is a JSON file called aws-identity-centre-configuration.json which is made available for convenience. The configuration below assigns the User ID to the Argo CD role of ADMIN, and the Group ID to the Argo CD role of VIEWER.

{
    "argoCd": {
      "awsIdc": {
        "idcInstanceArn": "REPLACE_WITH_IDC_INSTANCE_ARN",
        "idcRegion": "REPLACE_WITH_REGION"
      },
      "rbacRoleMappings": [{
        "role": "ADMIN",
        "identities": [{
          "id": "REPLACE_WITH_USER_ID",
          "type": "SSO_USER"
        }]
      },{
        "role": "VIEWER",
        "identities": [{
          "id": "REPLACE_WITH_GROUP_ID",
          "type": "SSO_GROUP"
        }]
      }
    ]}
  }

We can then create the Argo CD capability using the following AWS CLI command:

aws eks create-capability \
  --capability-name argocd-capability \
  --cluster-name eks-test-cluster\
  --type ARGOCD \
  --role-arn arn:aws:iam::{ACCOUNT_ID}:role/ArgoCDCapabilityRole \
  --delete-propagation-policy RETAIN \
  --configuration file://aws-identity-centre-configuration.json

This is equivalent to the following that can be used in a CloudFormation template.

ArgoCDCapability:
  Type: AWS::EKS::Capability
  Properties:
    CapabilityName: !Ref CapabilityName
    ClusterName: !Ref ClusterName
    Type: ARGOCD
    RoleArn: !GetAtt ArgoCDCapabilityRole.Arn
    DeletePropagationPolicy: !Ref DeletePropagationPolicy
    Configuration:
      ArgoCd:
        AwsIdc:
          IdcInstanceArn: !Ref IdentityCenterInstanceArn
          IdcRegion: !Ref IdentityCenterRegion
        RbacRoleMappings:
          - Identities:
              - Id: !Ref AdminUserId
                Type: SSO_USER
            Role: ADMIN
          - Identities:
              - Id: !Ref ViewerGroupId
                Type: SSO_GROUP
            Role: VIEWER

You can deploy the full CloudFormation stack using the following command:

aws cloudformation create-stack \
  --stack-name argocd-capability-stack \
  --template-body file://argocd-capability.yaml \
  --parameters \
    ParameterKey=ClusterName,ParameterValue=eks-test-cluster \
    ParameterKey=IdentityCenterInstanceArn,ParameterValue=arn:aws:sso:::instance/ssoins-{REPLACE} \
    ParameterKey=IdentityCenterRegion,ParameterValue=eu-west-2 \
    ParameterKey=AdminUserId,ParameterValue={REPLACE_WITH_USER_ID} \
    ParameterKey=ViewerGroupId,ParameterValue={REPLACE_WITH_GROUP_ID} \
  --capabilities CAPABILITY_NAMED_IAM \
  --region eu-west-2

Some of the properties include:

Type - This defines the type of EKS Capability to create with valid values of
- ACK - Amazon Web Services Controllers for Kubernetes (ACK), which lets you manage resources directly from Kubernetes
- ARGOCD – Argo CD for GitOps-based continuous delivery
- KRO – Kube Resource Orchestrator (KRO) for composing and managing custom Kubernetes resources
DeletePropagationPolicy - This only supported value is RETAIN, which keeps all resources managed by the capability when the capability is deleted
Configuration - This property defines the configuration settings, with the structure depending on the capability type
Role - The role under the RbacRoleMappings property defines the Argo CD role to be assigned. The value values are:
- ADMIN - Full administrative access to Argo CD
- EDITOR - Edit access to Argo CD resources
- VIEWER - Read-only access to Argo CD resources

Once the capability has been created (which will take a while), the capabilities tab for the cluster in the EKS console will provide the Argo API endpoint and a link to go to the managed hosted Argo UI:

We can click on the link to open up the managed Argo UI. At this point, we will need to click the button to LOG IN VIA SSO.

In most cases, this will automatically log you directly into the console. At this point, we can see there are no applications currently available.

We can also check the Argo CD Role Based Access Control (RCAC) assignments in the console, and make sure that it matches what we set up in the previous JSON file or in the CloudFormation template.

Argo CD Capability

Now that the Argo CD capability has been created, we can take a quick look at the same of the changes that have been made to our cluster.

Firstly, we run a command to look at the EKS Access Entries for the cluster.

aws eks list-access-entries \
  --cluster-name eks-test-cluster

EKS Access Entries are the recommended way to grant users access to the Kubernetes API. Fundamentally, it associates a set of Kubernetes permissions with an IAM identity such as an IAM Role. Running the command above generated the following output.

{
    "accessEntries": [
        "arn:aws:iam::{ACCOUNT_ID}:role/ArgoCDCapabilityRole",
        "arn:aws:iam::{ACCOUNT_ID}:role/aws-reserved/sso.amazonaws.com/eu-west-2/AWSReservedSSO_Developer_b664db2de4791f77",
        "arn:aws:iam::{ACCOUNT_ID}:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
        "arn:aws:iam::{ACCOUNT_ID}:role/eks-test-cluster-eks-auto-20260116165710199100000002"
    ]
}

We can see that four access entries currently exist in the cluster:

The SSO Developer role entry, which is the role I assumed to create the EKS cluster
An EKS Auto Mode generated role that is used to enable Auto Mode to make authenticated Kubernetes API calls
An EKS service-linked role that is used to manage the control plane and AWS-side resources of the cluster
The ArgoCDCapabilityRole role entry, which has been created when enabling the Argo CD EKS Capability which allows the capability to authenticate to the cluster

You can see the permissions that have been automatically granted to each entry in the console.

By enabling the EKS Argo CD Capability, the following Custom Resource Definitions (CRDs) have been added to the cluster.

kubectl get crds | grep argo  

applications.argoproj.io                        2026-01-16T17:10:56Z
applicationsets.argoproj.io                     2026-01-16T17:10:56Z
appprojects.argoproj.io                         2026-01-16T17:10:57Z

Deploy a sample application

Register your EKS cluster with Argo CD

In order to deploy a sample application, the first step is to register the EKS cluster where we want to deploy an application. We do this by by creating a Kubernetes secret, and passing the label of argocd.argoproj.io/secret-type: cluster. We give the cluster a name, and this is where the mapping between the actual cluster and the ARN happens. With EKS Capabilities you only need to provide the ARN and not the Kubernetes API Server URL as with a self-managed instance. In our case, we are registering a local cluster, as it is the same one as Argo CD is running. The following manifest file is found in the code repository under k8s/argocd.

apiVersion: v1
kind: Secret
metadata:
  name: local-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
stringData:
  name: local-cluster
  server: arn:aws:eks:eu-west-2:{ACCOUNT_ID}:cluster/eks-test-cluster
  project: default

We then apply this to the cluster

kubectl apply -f local-cluster.yaml

Register an Argo CD Application

Now we can register an Argo CD application. In this case, we will use the guestbook example from the Argo CD project itself.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps
    targetRevision: HEAD
    path: guestbook
  destination:
    server: arn:aws:eks:eu-west-2:{ACCOUNT_ID}:cluster/eks-test-cluster
    namespace: default

This is a Kubernetes manifest file for a custom resource (an Argo CD Application). Our cluster knows how to handle this as it has installed the CRD when deploying the capability itself. This application tells Argo CD to deploy the guestbook application from the specific public Git repository into the default namespace of the EKS cluster. We can run this file using the following command.

kubectl apply -f guestbook-application.yaml

We should get back the information that the application has been created application.argoproj.io/guestbook created.

At this point we can log in to the Argo UI, and see something similar to the following:

If we go into settings, we can see there is a failed connection status with our cluster.

And if we go further and click into the application itself, we see that there are 3 errors in the application conditions.

The issue here is that Argo CD cannot build its cache of what exists in the cluster, because it does not have permission to list the cluster-scoped resource PersistentVolume. It also cannot list resource "ingressclassparams" in API group "eks.amazonaws.com" at the cluster scope to connect to the cluster.

Associate an access policy

This issue is caused because the two access policies associated with the Argo CD Capability role (AmazonEKSArgoCDPolicy and AmazonEKSArgoCDClusterPolicy) do not give the required permissions to access or mutate the cluster resources.

The best practice in this case is to determine the minimum permissions required, and add these to an access policy. However, the fastest solution is to add the AmazonEKSClusterAdminPolicy with cluster scope to the access entry, which we can do using the following command:

aws eks associate-access-policy \
  --cluster-name eks-test-cluster \
  --principal-arn arn:aws:iam::424727766526:role/ArgoCDCapabilityRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

Once we have run this command, Argo CD will now be able to connect successfully to the cluster:

And the application can be synced and is healthy.

AWS Certified Machine Learning Engineer Core Concepts

Matt Lewis — Sat, 04 Oct 2025 13:32:38 +0000

Overview

Earlier this year I passed the AWS Machine Learning Engineer - Associate exam. I spent time making sure I understood the core concepts before taking the exam, and made a lot of notes. The intent of this post is to summarise the concepts essential to pass the exam. Based on my experience, knowing these concepts will get you at least half way there. Layer on knowledge of the AWS AI Services, and focus on SageMaker and all its capabilities, and the certification will be yours.

Data Preprocessing
SageMaker Built-In Algorithms
Model Development
Evaluating Model Accuracy
Improving Model Accuracy
Additional Topics to Study
Other Study Guides

Data Preprocessing

Data preprocessing ensures that data is in the right shape and of the right quality to be used for training.

Labelling data is important for models to learn effectively, and this is where services such as Mechanical Turk and SageMaker Ground Truth come in. Mechanical Turk is an online marketplace to access an on-demand global workforce. SageMaker Ground Truth provides built-in workflows to automate data labelling, and can use your own workforce, third-party vendors from the AWS marketplace, or Mechanical Turk.

Cleaning data can include removing outliers and duplicates, replacing inaccurate or irrelevant data, and correcting missing data.

Approaches for inputting missing data include:

Mean replacement – replacing the missing values with the mean value from the rest of the column. The mean value is the average, which means it can be distorted by outliers. Therefore, the median value (which is the middle value when data is sorted) may be a better choice
KNN (K-Nearest Neighbour) – Find the ‘K’ nearest’ most similar rows and average their values. This assumes numeric data.

Balancing data (for datasets with underrepresented categories) can be achieved using one of the following methods:

Random oversampling – this method randomly duplicates samples from the minority category. For example, if you were building a fraud detection model and you had 1000 examples of normal transactions and only 50 of fraudulent transactions, you would duplicate the fraudulent transactions until you had an equal proportion
Random Undersampling – this method randomly removes samples from the overrepresented category to achieve the equal proportion. This would typically be used when you have a large dataset, or you would want to reduce the size of your dataset to make training the model quicker
Synthetic Minority Oversampling Technique (SMOTE) – this approach generates new synthetic samples of the minority category by interpolating between existing samples using nearest neighbours.

Encoding is the concept around converting data (typically categorical data where the data represents a category or group) into a numerical format that can be well understood by a model. The main types of encoding are the following:

Label Encoding – assigns each category a unique number e.g. Red=0, Green=1, Blue=2. There is no order implied by this encoding
One-Hot Encoding – creates binary columns for each category. This means if there is a category called colour there would be additional columns created for each unique value such as a column for Red and one for Blue and for Green. The value for each column would be assigned 1 if it is true, else 0.
Ordinal Encoding – this is similar to label encoding but is used when there is a ranked ordering between values in a category. For a category called ‘size’ you could map Small to 0, Medium to 1 and Large to 2.

Outliers are data points in a data set that deviate significantly from the general patterns. One way of detecting outliers in training data is to measure how many standard deviations a data point is from the mean of a dataset. This is often called a z-score or standard score. Data points that lie more than one standard deviation from the mean can be considered unusual.

Outliers can be handled in different ways:

Delete the record - if the outlier is clearly an error and there is enough training data, you can just delete that record.
Feature scaling or normalisation – this aims to transform the numeric values so that are all values are on the same scale, often between 0 and 1. This rescaling makes the values more comparable
Standardisation – is similar to normalisation but instead of scaling values from 0 to 1, it rescales the features to have a mean of 0 and standard deviation of 1
Binning – takes a continuous numerical feature and splits into a set of intervals or bins. Each value is then assigned to a bin which can cover up imprecision or uncertainty e.g. someone aged 110 could end up in a bin which is “70+”.

After data has been cleaned up and encoded, you can fine tune or create new features in your dataset through feature engineering. There are other methods such as bag-of-words and N-gram that can be used to extract key information from text data.

In machine learning, dimensionality refers to the number of features in your dataset. If you have a dataset with 3 features (age, income and height), it exists in a 3-dimensional space. The curse of dimensionality refers to the problems that arise when you have too many features. When this happens, the data becomes sparse (e.g. spread out too thinly in the feature space), and it is hard to find meaningful patterns.

There are a number of unsupervised reduction techniques that can help to distil many features into a smaller more manageable number:

Principal component analysis (PCA) – this technique retains most of the variation in the original features but reduces the overall number of features. It works by transforming features into a new set of features called principal components
K-Means – this technique uses a clustering algorithm to group similar data points into K clusters. It does not create new features but assigns a cluster label to each data point.

SageMaker Built-In Algorithms

Before you can train your model, you need to select a machine learning algorithm to use. Amazon SageMaker provides a suite of built-in algorithms, pre-trained models, and pre-built solution templates to help data scientists and machine learning practitioners get started on training and deploying machine learning models quickly. It is worth understanding each of these algorithms at a high-level, understanding which ones are used for supervised versus unsupervised learning, and their main uses.

Linear Learner - A supervised learning algorithm suited for general classification (Logistic Regression) and regression (Linear Regression) tasks. It makes predictions based on labelled data. In simpler terms, the model is given examples where each example has some features (like size, price, or age) and an outcome (like a house price or a category). For classification tasks, the model sorts data into categories, such as whether a house is expensive or not. For regression tasks, it predicts a specific value, like the actual price of a house. It assumes linear regression and must pre-process missing values.

K-Means - An unsupervised algorithm designed for clustering or grouping data points based on their features (chosen attribute), without needing labelled data

BlazingText - A supervised algorithm used for Natural Language Processing tasks like text classification.

Seq2Seq - A supervised algorithm specifically designed for sequence-to-sequence tasks, such as predicting the next word in a sequence, making it ideal for tasks like language translation or text generation

DeepAR - A supervised algorithm used to forecast time-series predictions by using recurrent neural networks (RNN)

XGBoost - A supervised learning algorithm used for both classification and regression tasks — especially when you care about speed and performance. It is an optimized, scalable implementation of gradient boosting that builds an ensemble of decision trees in a sequential manner. Often outperforms other models in competitions (e.g., Kaggle)

Random Cut Forest - An unsupervised algorithm used to identify abnormal data points within a data set e.g. anomaly detection

Semantic Segmentation - A supervised algorithm that provides pixel-level classification but does not label objects with bounding boxes. It is typically used to classify individual pixels by tagging each pixel with a specified class

Principal Component Analysis (PCA) - An unsupervised algorithm used for dimensionality reduction

Image Classification - A supervised algorithm that is used to label entire images, not individual objects. It simply assigns a single label to an entire image, categorising it based on the predominant features. It cannot identify or count multiple objects within a single image.

Object Detection - A supervised algorithm used to identify and classify multiple objects within an image, assigning bounding boxes and confidence scores. It draws bounding boxes around detected objects and classifies them into different categories, making it very useful for tasks where you need to recognise what is in the image and determine the exact location of each object. This algorithm is well-suited for scenarios that require counting specific items, such as animals, in drone imagery, as it can distinguish between individual objects even in complex scenes.

Object2Vec - A supervised algorithm primarily used to learn vector embeddings of discrete objects. Its typically used in recommendation systems, document classification or semantic similarity tasks, not computer vision or image processing.

IP Insights - An unsupervised algorithm used to detect anomalies in IP address usage patterns. It captures associations between these IP addresses and various entities, such as user IDs or account numbers. For instance, you can use it to detect a user attempting to log into a web service from an anomalous IP address. Additionally, it helps identify accounts that create computing resources from unexpected IP addresses.

Latent Dirichlet Allocation (LDA) - An unsupervised learning technique designed to represent a collection of documents as a combination of various topics. LDA is primarily used to identify a specified number of topics within a set of text documents. The LDA algorithm is a powerful tool for text mining and natural language processing tasks. It allows companies to sift through vast amounts of textual data and discern patterns that might take time to be apparent. Since LDA is an unsupervised method, the topics are not specified up front, and the discovered topics may not necessarily match human categorisations. Instead, LDA learns the topics as a probability distribution over the words in the documents, and each document is characterised as a mixture of these topics.

Neural Topic Model (NTM) - An unsupervised algorithm used for organising documents into topics. It is just like LDA — but it's based on neural networks rather than probabilistic graphical models.

Factorization Machines - A supervised algorithm designed to handle sparse data, making it ideal for recommendation systems where user-item interactions are often sparse. It is primarily used for recommendation systems and ranking predictions.

Text Classification – TensorFlow algorithm - A supervised algorithm designed to classify text into predefined categories.

Model Development

Hyperparameters are external configuration variables used to control a training model, improve model performance and the model outcome. Hyperparameters are set before training. This can be done manually, although SageMaker offers an intelligent version of hyperparameter tuning methods based on Bayesian search theory designed to find the best model in the shortest time. Amazon SageMaker AI automatic model tuning (AMT) finds the best version of a model by running many training jobs on your dataset. Amazon SageMaker AI automatic model tuning (AMT) is also known as hyperparameter tuning and supports Hyperband, a new search strategy.

Common hyperparameters include:

Epoch – the number of times the entire training dataset is shown to the network during training. A smaller epoch value means faster training, but the model might not learn enough patterns and end up underfitting. A larger epoch value gives more opportunity to refine weights and give better convergence, but will take longer to train and may end up memorising training data and so overfitting
Learning rate – the rate at which an algorithm updates estimates. Too high a learning rate means you might overshoot the optimal solution. Too small a learning rate will take too long to find the optimal solution
Batch size – how many batch training samples are used within each batch of each epoch. Large batch sizes are faster per epoch as it will fill the GPU, but risk worse generalisation and can end up getting stuck in the wrong solution. Small batch sizes are slower per epoch but can provide better generalisation.

Note that hyperparameters are not related to inference parameters. Inference parameters are settings you can adjust during inference, that influence the response from the model. The most common are:

Temperature: Temperature is a value between 0 and 1, and it regulates the creativity of the model's responses. Use a lower temperature if you want more deterministic responses, and use a higher temperature if you want creative or different responses for the same prompt
Top K: The number of most-likely candidates that the model considers for the next token. Choose a lower value to decrease the size of the pool and limit the options to more likely outputs.
Top P: The percentage of most-likely candidates that the model considers for the next token. Choose a lower value to decrease the size of the pool and limit the options to more likely outputs.

Evaluating Model Accuracy

Metrics are used to measure the performance and accuracy of a machine learning model. These metrics can typically be broken down into classification metrics and regression metrics.

With classification, the goal of the model is to predict a label or class (category) for the given input. With binary classification, there are only two possible outputs (positive or negative). This is used to predict whether an image is a dog or not, or whether an email is spam or not. With multi-class classification, there are more than two possible outputs, such as predicting whether an animal is a dog, cat or cow.

With regression, the goal of the model is to predict a numerical value. This could be predicting a house or stock price, or a person's annual income given certain inputs.

Classification Metrics

The confusion matrix is a great way to help understand common classification metrics.

Recall - Recall is the percentage of positives correctly predicted. It is focused on how many of the actual positives did the model get right. You use it when you prefer to catch as many positives as possible, even if some are incorrect. It is a good metric when false negatives are costly e.g. fraud detection or cancer screening where it is better to flag more cases (even if some are wrong) than to miss a true positive

It is calculated as: Recall = TP / (TP + FN)

Precision - Precision is all around correct positives. All positive predictions include both true positives and false positives (those predicted as positive but are actually negative). This means it is a good metric when false positives are costly e.g. spam email when you don't want to mark legitimate emails as spam, or object detection in autonomous vehicles, where a false positive can induce sudden unnecessary braking.

It is calculated as: Precision = TP / (TP + FP)

A model with high precision and low recall catches few positives but is rarely wrong.

A model with high recall and low precision catches most positives but includes many false alarms.

F1 Score - The F1 Score is the harmonic mean of precision and recall. It is used when you need a balance betweeb both.

It is calculated as: F1 Score = 2 x ((Precision x Recall) / (Precision + Recall))

Accuracy - Accuracy measures overall correctness — how often the model was right, regardless of class. It considers all predictions (true positives, true negatives, false positives, and false negatives).

It is calculated as: Accuracy = TP + TN / TP + TN + FP + FN

AUC and ROC - The ROC curve is a graphical plot that helps visualise how well a binary classification model performs across different threshold values. It is a plot of true positive rate (recall) versus false positive rate and helps you see this trade off between True Positives and False Positives.

The Area under the Curve (AUC) is a single scalar value between 0 and 1 of how well the classification model can separate the positive and negative predictions. A value of 0.5 means the model performs no better than a random classifier. A value of 1.0 is a perfect classifier.

Regression Metrics

If you are using regression where you are predicting a number and not just a classification, then there are other metrics:

Mean Absolute Error (MEA) - MEA measures the average absolute difference between the predicted values and the actual values. It tells you on average, how much your models predictions are off from the true values. A lower score means a better model. It is simple to understand and is not affected by outliers. MAE is robust to outliers because it handles them linearly, not exponentially. This makes it a good choice when you don’t want a few bad predictions to dominate the error metric.

Mean Squared Error (MSE) - MSE averages the squared difference between actual and predicted values. Because it squares the values, outliers become amplified. This makes MSE more sensitive to outliers. You would choose MSE (Mean Squared Error) over MAE (Mean Absolute Error) when you want to penalize large errors more heavily and are more concerned with model performance on extreme values.

RMSE (Root Mean Square Error) - RMSE is a metric used to measure the differences between predicted values and actual values in a regression problem. It calculates the square root of the average squared differences between the predicted and actual values. A lower Root Mean Square Error value indicates better model performance. Since the errors are squared before averaging, larger errors have a bigger impact (this makes RMSE sensitive to outliers).

You would use RMSE (Root Mean Squared Error) over MSE (Mean Squared Error) when you want the error metric to be in the same units as the target variable, making it more interpretable. For example, if you're predicting house prices in dollars, RMSE is in dollars, while MSE is in squared dollars, which is less intuitive.

R Squared - R-Squared measures the square of the correlation coefficient between observed outcomes and predicted. It measures how well your regression model explains the variability of the target (dependent) variable. A score of 1 means the model explains all the variance perfectly. A score of 0 means the model explains none of the variance.

Improving Model Accuracy

Understanding model fit is important when understanding the root cause for poor model accuracy.

Two common terms that come up to describe model performance are:

Overfitting – a model that is overfitting has learned patterns in the training data that don’t generalise out to the real world. This means that it has high accuracy on the training data set, but lower accuracy on evaluation data sets
Underfitting – a model that is underfitting performs poorly on the training data and in the real world. This is because the model is unable to capture the relationship between the input examples and the target values.

Regularization techniques are intended to prevent overfitting. Common techniques include:

Dropout – this is a technique where random neurons are temporarily dropped out (e.g. ignore) during each training iteration. This means the network can’t rely too heavily on any specific neuron or connection
Early Stopping – this is a technique where you stop training the neural network before it overfits the training data. It works by monitoring validation loss and accuracy and stopping training when the model stops improving.
L1 and L2 Regularization

L1 and L2 Regularization are techniques used to prevent overfitting by penalising large model weights. In a machine learning model, a weight is a numeric parameter that connects an input feature to an output. A large weight value means the model is putting an extremely strong emphasis on that specific feature, which means the model becomes very sensitive to small changes in inputs, which can lead to overfitting. These techniques add a penalty term to the loss function to discourage large weights:

L1 Regularization (Lasso) – the penalty is the sum of the absolute value of the weights. It shrinks some weights entirely to zero to create sparse models. This is a form of feature selection (removing irrelevant features). You should use this when you suspect only a few features are important. It is computationally inefficient.
L2 Regularization (Ridge) – the penalty is the sum of the square of the weights. This shrinks the weights but does not make them zero. It helps keep the model simpler and reduces sensitivity. It is computationally efficient.

Additional Topics to Study

The two other main topic areas you need to understand are:

AWS AI Services - these are the managed AWS services that offer a simpler entry point than building your own model. You will need to a good understanding of each service and what it is used for, so you can distinguish between Amazon Lex and Amazon Polly, and between Amazon Translate and Amazon Transcribe.
Amazon SageMaker - Amazon SageMaker is a service that provides a whole host of features and capabilities you need to be aware of. You need to understand which feature you can use to detect bias; which to import, prepare and transform data; which to share curated features, and so on.

Other Study Guides

AWS Certification Page - the AWS certification home page for this exam includes the study guide and links to additional resources
AWS SkillBuilder - the AWS official learning plan which is available for free alongside an official set of practice exam questions. Additional material including longer review sections, extra questions and labs are available with a subscription.
Udemy - the certification course provided by Stephane Maarek and Frank Kane comes highly recommended
Pluralsight - this certification course by Pluralsight also includes labs. Pluralsight offer a 10 day free individual trial and monthly subscriptions which may work for some
Tutorials Dojo - this set of practice questions is a great way to get used to the style of exam in various modes

Next Gen Developer Experience with Amazon Q Developer

Matt Lewis — Thu, 08 May 2025 08:55:15 +0000

There have been massive advances in the capabilities and features supported by Amazon Q Developer over the last few months. A number of these really stood out for me:

At the beginning of March the new enhanced Amazon Q Developer CLI agent was released with the power of Claude 3.7 Sonnet step-by-step reasoning. This also gave the agent access to tools such as the AWS CLI. Read more in the blog post
At the end of April the Amazon Q Developer CLI was further enhanced with support for Model Context Protocol (MCP) to provide even more context. Read more in the blog post
At the beginning of May, Amazon Q Developer support was integrated into GitHub in preview. Read more in the blog post

With all of these improvements, I wanted to see if there was a way of bringing them together to meet a coherent use case. This use case was to:

Take a task assigned to me from a Jira Kanban board
Implement the requested functionality
Push the code up to GitHub as the source code repository
Run a check for security vulnerabilities and code quality issues
Raise a Pull Request
Move the task along on the Kanban board

The goal was to show how these tools can make life easier for a software engineer, and greatly increase their productivity. Let's see how I got on.

Step 1: Set up Jira

I am using a hosted version of Jira Cloud using the free tier provided by Atlassian. The first thing I did was to create a new Jira project that sets up a Kanban board using a software development supporting template.

Next I created a new Jira task. The task was to "create a classic snake game written in python using pygame", and I assigned it to myself. Although this is a contrived example, you could easily equate this to a new feature on an existing service.

Once created, we can see this task in to "To Do" section of the Kanban board.

I also created a new GitHub repository which is cloned to my workspace.

Step 2: Configure MCP Servers

The next step was to setup the Amazon Q CLI to access both Atlassian and GitHub. Amazon Q CLI acts as an MCP Client, and it can access MCP Servers that have been configured in a mcp.json file. This files needs to be located in ~/.aws/amazonq. You can find out more details in this blog post by Ricardo Sueiras.

I want to run these MCP Servers in a container, and without access to Docker Desktop I configure them to use Podman. My configuration is shown below.

{
  "mcpServers": {
    "github-mcp-server": {
      "command": "podman",
      "args": [
        "run",
        "--rm",
        "--interactive",
        "--env",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {"GITHUB_PERSONAL_ACCESS_TOKEN": "github_pat_xxx"}
    },
    "mcp-atlassian": {
      "command": "podman",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e", "JIRA_URL",
        "-e", "JIRA_USERNAME",
        "-e", "JIRA_API_TOKEN",
        "ghcr.io/sooperset/mcp-atlassian:latest"
      ],
      "env": {
        "JIRA_URL": "https://xxx.atlassian.net/",
        "JIRA_USERNAME": "xxx@email.com",
        "JIRA_API_TOKEN": "XXXXX"
      }
    }
  }
}

This required creating a Personal Access Token in GitHub, and an API Token in Atlassian.

Step 3: Run Amazon Q Developer CLI

After making the changes to the mcp.json configuration, I launched Amazon Q CLI from the terminal window in my Visual Studio Code IDE. You can see that the two MCP Servers have been loaded and are accessible.

I start by asking the Amazon Q CLI to “get the latest task from Jira that is assigned to me”. The Amazon Q CLI returns wanting to know more details, before it can use the configuration to retrieve information about the task.

I tell the Amazon Q CLI that I am using Jira Cloud and to search across all projects. I am then told that the Amazon Q CLI wants to run a tool provided by the mcp_atlassian MCP Server. I am prompted to either press t to always trust the tool for the session, y to allow the tool to be executed this time without trusting for the session, or n to not let the tool be executed. I will be answering y to all of these prompts.

After running the tool, the Amazon Q CLI has found the task and displays all of the details.

I ask Amazon Q CLI to help me implement the functionality, and it goes away and generates all the code required. At this point, the code is in memory, and I am asked if I want to save the code to a file in my current directory.

I tell the Amazon Q CLI to create a new branch and add the file to this new branch. After running the relevant git commands to create a new branch, the Amazon Q CLI switches to this branch, and then writes the code to a new file in this branch.

After successfully writing the code to a new branch, the Amazon Q CLI commits the changes with a message referencing the specific Jira task number that it still has in its current session context.

At this point, I could prompt to make more enhancements to the game. The Amazon Q CLI even gives suggestions of areas of the game it could improve. Instead, I just ask it to update the README file with instructions on how to play the game, and then make another commit.

The Amazon Q CLI now asks if I want to make any other changes. I'm happy with those that have been made so far, so ask it to make a pull request for these. Notice the first request to create a pull request fails. Amazon Q CLI apologises, and tries another approach, this time pushing the branch to GitHub and then creating the pull request which succeeds.

After creating the pull request, the Amazon Q CLI knows from its session context and its reasoning, that we should also update the original task in Jira. It interacts with tools in the Atlassian MCP Server to transition the task to the "In Progress" state and add a relevant comment.

Step 4: Jira Kanban Board

At this point in time, I go across to the Kanban board in Jira and can see that the task has been transitioned to "In Progress".

Clicking into the task, I can see the comment that has been added to the task. This gives details about the functionality implemented to meet the task description, alongside a working link to the open PR in GitHub.

Step 5: Code Scanning in GitHub

The final task I wanted to carry out was to run a check for security vulnerabilities and code quality issues. I have already configured my GitHub account with the Amazon Q Developer application. This means that as soon as the pull request was raised, the amazon-q-developer application automatically scanned the changes in the PR. Happily, there were no security or code quality issues found. If there were, the new application would have automatically generated code suggestions to fix the findings.

Conclusion

I can't remember the last time I tested out new features and services and genuinely felt so convinced we are now starting to see a change in how we will engineer applications in the software industry. The value of software engineering still remains, even more so when working on complex problems for which generative AI solutions do not have the corpus of knowledge to be trained on. However, this showed to me how these new capabilities can help in reducing the context switching, and the need to move between various tools, copying data between them. The next generation of developer experience is well and truly upon it, so I'd urge everyone to try it out.

Biography

As Chief AWS Architect at IBM in the UK, I am responsible for growing the AWS capability and community within one of the fastest growing AWS consulting partners globally. This often gives me the opportunity to try out the latest features in preview before they go into general availability. You'll often find me blogging about my experience, but please reach out if there are services you'd like to know more about.

Java code transformation using the Amazon Q Developer GitHub Integration

Matt Lewis — Tue, 06 May 2025 10:30:37 +0000

AWS have launched the Amazon Q Developer integration with GitHub. I was keen to try this out, and in this post, I walk through how to get started and use the integration to upgrade a Java project.

Getting Setup

The first step is to install the Amazon Q Developer application from the GitHub Marketplace found at this URL - https://github.com/apps/amazon-q-developer.

Then click on Install and select which repositories you want to allow the application to access.

You can also optionally register the application installation with your AWS account to increase your usage limits. This is a two-step process. A landing page in your AWS console allows you to authorise Amazon Q Developer to access your GitHub account.

This redirects you to GitHub to complete the authorisation process.

You are then returned the AWS Console to provide a registration name and complete the registration process.

Setup GitHub Actions

Before you can get started on running a transformation request, you need to enable GitHub Actions for the repository and ensure a runner is available online.

This involves creating a main.yml file within a .github/workflows/ folder structure. The workflow I used is shown below:

name: Q Code Transformation

on:
  push:
    branches:
      - 'Q-TRANSFORM-issue-*'

env:
   MAVEN_CLI_OPTS: >-
     -Djava.version=${{ contains(github.event.head_commit.message, 'Code transformation completed') &&  '17' || '11' }}

jobs:
  q-code-transformation:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-java@v3
        with:
          java-version: ${{ contains(github.event.head_commit.message, 'Code transformation completed') && '17' || '11' }}
          distribution: 'adopt'

      - name: Build and copy dependencies
        run: |
          mvn ${{ env.MAVEN_CLI_OPTS }} clean install -U
          mvn ${{ env.MAVEN_CLI_OPTS }} verify
          mvn ${{ env.MAVEN_CLI_OPTS }} dependency:copy-dependencies -DoutputDirectory=dependencies -Dmdep.useRepositoryLayout=true -Dmdep.copyPom=true -Dmdep.addParentPoms=true

      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: q-code-transformation-dependencies
          path: dependencies

This creates a workflow named Q Code Transformation that is triggered when code is pushed to a branch that matches the pattern Q-TRANSFORM-issue-*. The job itself runs on Ubuntu, and starts by checking out the code in the repository into the GitHub Action runner.

It then installs and sets up a Java installation using the AdoptOpenJDK distribution on the runner. The choice of Java version is chosen dynamically. If the commit message contains "Code transformation completed", Java version 17 is installed, else Java 11.

The script then uses maven commands to clean and rebuild the project, builds the projects and runs all tests, and finally copies all project dependencies into a specific folder. These are then uploaded as a project artifact from the runner machine into GitHub.

Triggering the Code Transformation

Triggering the Java code transformation is as simple as raising a GitHub issue, and applying the Amazon Q transform agent label to the issue.

The amazon-q-developer application then takes over, adding comments to the issue to keep you up to date. It starts by running the GitHub Actions workflow required to transform the code. You can view the progress of the runner in the Actions tab.

Once successful, your code to be transformed is uploaded, and a transformation plan created. This code transformation plan sets out the changes that the agent is initially expecting to apply.

The agent then starts upgrading the code to Java 17. Once complete, the agent updates the issue with a comment and opens a pull request.

Viewing the transformed code

The pull request opened by the agent starts off with a code transformation summary detailing the changes made during the transformation process.

One area that the transform agent has significantly improved over the past few months is in summarising these changes. Not only are these nicely laid out in a list format, but for each significant change, there are details provided why it has been made and the benefits it offers.

Security vulnerabilities and code quality issues

One benefit that the GitHub integration brings is the scanning of all pull requests for security vulnerabilities and code quality issues. The application will raise a comment in the pull request, and then highlight any findings it discovers. In my case, the application generates a high severity warning.

For each vulnerability found, a detailed description of the fix needed alongside code that can be committed is provided.

If multiple issues are discovered, you can go into the Files Changed and select to batch up all of the suggestions into a single commit.

Observations and Conclusion

There are a few areas that are worth drawing out that initially caught me out.

Supported Target Code Versions
The transform agent in the IDE currently only supports Java 17. The transform agent in the IDE has recently enabled support for Java 21 as a target code version as well as Java 17.
Code Review
The code review run on the pull request is only carried out against the changes made in the diff, and not against unchanged content in these files, or the entire repo. To do this, you will need to go back to the IDE and run the /review agent. It would be great to trigger a full code review on an entire repo through the GitHub integration
Code Suggestions for Security Vulnerabilities
Ironically, as the code review is only carried out against new changes, the vulnerability detected by the agent is against code that the agent itself created. I'm not entirely sure how I'm supposed to feel about this. In fairness, its most likely a reflection of the wider codebase and the code suggestion following the existing styling. In addition, the code suggestion made to resolve the security vulnerability which I automatically accepted failed compilation. This was detected almost straight away as it triggered another run of the GitHub Action. It turned out simpler to fix this compilation error manually and add this as a commit to the pull request. I'm not sure why this was the case, but I feel confident this will be fixed soon.

For Java transformations this now provides an alternative approach to using the agent in the IDE. Using the transform agent in the IDE feels more synchronous, as you watch the progress taking place in the Transformation Hub terminal. I really enjoyed the asynchronous nature of the GitHub integration. I can simply create a new issue, use a label to assign to the transform agent, and then wait for the email notification that it is complete. This frees up time to carry on with other value add activities.

Running the transform agent in the IDE, you are also responsible for creating a separate branch, committing the changes to this branch, and raising the PR, all of which is taken care of for you with the GitHub integration. Even better, once merged into the main branch, the full conversation history is still maintained in the closed Pull Request for transparency.

The project I used can be found here - https://github.com/mlewis7127/bicycle-licence-GH-integration. If you have a requirement to transform old Java code projects, I would definitely recommend checking out this integration, and see how it fits into your developer workflow.

Biography

Amazon Q Developer transform for .NET

Matt Lewis — Mon, 20 Jan 2025 10:19:13 +0000

Introduction

A fantastic use case for AI Coding Assistants is upgrading applications to modern and supported versions of programming languages, libraries and frameworks. All too often, engineering effort is spent building new features, whilst existing applications are left untouched, until they become unsupported with all kinds of inherent vulnerabilities.

Amazon Q Developer introduced a code transformation agent for Java when launched in preview back in November 2023. This agent has undergone multiple iterations and become more accurate and powerful since then. On 3rd December 2024 at AWS re:Invent, the public preview of new transformation capabilities for .NET, mainframe, and VMware workloads was announced.

In this blog post, I take a look at the .NET transformation capability to get a better understanding of how it works. This feature is available in the Visual Studio IDE. However, Visual Studio for Mac has been retired, which gave me an opportunity to try out the Amazon Q Developer transformation web experience.

Why port .NET Framework?

.NET Framework is the original implementation of .NET by Microsoft. It supports running websites, services, desktop apps and more, but only on Windows.

.NET (sometimes called .NET Core) is a more modern, open-source version of .NET that can run on multiple operating systems including Windows, Linux and MacOS. The reasons to continue using .NET Framework are specific and limited according to Microsoft, and relate to use cases where your application is using third-party libraries or NuGet packages or .NET Framework technologies that are not available for .NET.

Where possible you should look to utilise .NET.

Getting started with web experience

To get started with the web experience, I had to subscribe to Amazon Q Developer from your management (root) account, as it is not currently possible to use a delegated administrator account. Note that you need to be in the us-east-1 region at this point.

This takes you to a Getting started with Amazon Q page. I was prompted to switch back to my home region (eu-west-2) which then automatically connected my AWS Organization instance of IAM Identity Center to Amazon Q. At this point, I clicked the button to "subscribe" and added a user from IAM Identity Center. It is also possible to add a Group instead of an individual user or users.

This successfully created an Amazon Q Developer Pro subscription for my chosen user. At this point, I clicked on the button which took me to the Amazon Q Developer console to complete the setup.

Opening up Amazon Q Developer in the AWS Console gave the option to click on a settings button.

In the settings, I enabled the transform settings, which is required to give access to the transformation web experience.

At this point, I navigated in a browser window to https://transform.developer.q.aws.com/ and signed in using IAM Identity Centre.

Once logged in, I was presented with the option of creating my first transformation job with Amazon Q.

Running transformation for .NET

Once I asked Q to create a transformation job, I was given the choice of the type of transformation to work on. There are three options available:

Modernize .NET applications to cross-platform .NET
Migrate VMware applications to Amazon EC2
Perform mainframe modernization (z/os to AWS)

I chose the option to modernise a .NET application. Amazon Q then populated a number of details about the .NET modernisation project. I could change these details, or in this case, confirm they are correct and let Amazon Q create the job itself.

At this point I had to connect Amazon Q to my source repository for the project I want to transform. I have forked the SharpZeroLogon GitHub repository to my own profile. This is an archived repository that was a rework of the NCC Group's tool specifically for .NET Framework 3.5.

The connection is made using AWS CodeConnections. Within an AWS account, you use CodeConnections to create a connection to a third party Git-based source provider. Currently, the only supported provider is GitHub. To create a connection, you need to go to AWS CodeArtifact, click on Settings and then Connections. I am using GitHub which installs the AWS Connector for GitHub as an application in GitHub. You can configure the connector with access to only specific repositories.

To setup the Amazon Q transformation job you first specify the account number for the AWS account where the connection is configured.

You then specify the AWS CodeConnection ARN.

You then go back into the AWS console to approve this connection request.

Once the connection request has been approved, you click on Send to Q, which will allow Amazon Q to access the repositories in the connected account.

Amazon Q analyses all of the repositories it has access too, to discover which ones run a .NET Framework application that is capable of being transformed. Amazon Q Developer transformation capabilities for .NET supports porting C# code projects of the following types: console application, class library, unit tests, web API, Windows Communication Foundation (WCF) service, and business logic layers of Model View Controller (MVC) and Single Page Application (SPA). Types of jobs that Amazon Q currently cannot transform include WebUI, SQLServer and ASP.NET.

In my example, the SharpZeroLogin repository has been detected as a supported project, and I am given the option to specify a target version (.NET 8.0). I can also specify the name of the new branch that will be created or keep the default.

Note that the web experience gives you the option of carrying out a .NET transform of multiple repositories. This is something not available within the IDE, which only allows one .NET solution at a time.

Amazon Q now automatically ports the selected .NET application to the target version following a transformation plan it has created. It commits all of the transformed code to a new branch in my GitHub repository, preserving the original source code.

I can click on the Dashboard tab to monitor the progress. In this case, I am told that the application has been transformed with no issues.

I can now go to my GitHub repository and look at the new branch that has been created. I can also view the diffs to see what changes have been made. In the file below, we can see that the target framework version has been updated from "3.5" to "net8.0".

Conclusion

The goal of this blog post is to show you how to simple it is to get up and running with the new Amazon Q Developer transformation web experience. If you have existing .NET Framework applications that you want to port to .NET to gain performance improvements and cross-platform support, it is definitely worth giving this feature a go.

Amazon GuardDuty Extended Threat Detection

Matt Lewis — Mon, 02 Dec 2024 15:19:53 +0000

Introduction

I was lucky to get the opportunity to try out the new "Extended Threat Protection" feature for Amazon GuardDuty whilst in beta. With the announcement of this new feature, I wanted to share more around my experience, and the value this new feature brings. Before jumping into this, let's start by providing some background to Amazon GuardDuty and the benefits it provides, to those who may not be familiar with the service.

Why Amazon GuardDuty?

Amazon GuardDuty is a threat detection service that continuously monitors, analyses and processes AWS logs and other data sources for malicious and abnormal activity. It uses its own internal feeds, alongside other intelligence feeds from CrowdStrike and Proofpoint to detect the latest threats and attack techniques. As someone who has worked for many years in heavily regulated industries processing sensitive data sets in areas of critical national infrastructure, I have been a huge advocate of Amazon GuardDuty.

In modern cloud environments, the quantity of logs and events that is captured is enormous. When it comes to threat detection, you require real-time and accurate visibility into this data. When your workloads reside on AWS, shipping this data externally to another cloud provider or back on-premises adds significant egress costs and latency. This is why I always look to use GuardDuty, so the data can be analysed at source, and threat detection can be consumed as a managed service.

GuardDuty uses a baseline of foundational data sources, and processes these logs using independent streams of data so it does not affect existing configurations. These foundational data sources are:

AWS CloudTrail - showing a history of AWS API calls and management events.
VPC Flow Logs - showing details of IP traffic going to and from network interfaces attached to your EC2 instances.
Route 53 Resolver DNS logs - showing a history of DNS queries.

On top of this baseline, you have the option to enable protection plans, which are specialised features within GuardDuty that provide enhanced threat detection for specific AWS services, such as:

S3 Protection - helps detect risks such as data exfiltration and destruction in your S3 buckets.
EKS Protection - monitors EKS audit logs to identify potential security issues such as unauthenticated actor attempts to collect secrets or AWS credentials, and suspicious container deployments with images not commonly used in the cluster.
Runtime Monitoring - observes and analyses operating-system level, networking, and file events to help detect potential threats for EC2 instances and container workloads in EKS and ECS including Fargate.
Malware Protection for EC2 - detect the potential presence of malware by scanning the EBS volumes attached to EC2 instances.
Malware Protection for S3 - detect the potential presence or malware by scanning newly uploaded objects to selected S3 buckets.
RDS Protection - profile and monitor access activity to Aurora databases in your AWS account without impacting database performance, to detect potential threats such as high severity brute force attacks, suspicious logins, and access by known threat actors.
Lambda Protection - identifies potential security threats when an AWS Lambda gets invoked in your AWS environment by monitoring Lambda network activity logs.

Integration with AWS Services

Amazon GuardDuty is tightly integrated with other AWS services to enable fast responses.

Amazon Detective

Amazon Detective ingests GuardDuty findings and allows you to quickly analyse and investigate these events.

AWS Security Hub

AWS Security Hub is a cloud security posture management (CSPM) service. It collects findings from the security services enabled across your AWS accounts, such as intrusion detection findings from GuardDuty, vulnerability scans from Inspector, and sensitive data identification findings from Macie. It runs continuous and automated account and resource-level configuration checks against the controls in the AWS Foundational Security Best Practices standard and other supported industry best practices and standards such as NIST and PCI DSS. The screenshot below shows GuardDuty findings in Security Hub.

Amazon EventBridge

GuardDuty creates an event whenever a new finding occurs. These are routed to the default event bus in Amazon EventBridge. You can configure an EventBridge rule with a pattern that listens for GuardDuty findings in order to automatically respond to these events.

Common use cases include sending automatic alerts for high severity findings, or automating remediation (e.g. disabling a compromised access key)

Extended Threat Detection with Attack Sequences

GuardDuty Extended Threat Detection is a new feature of Amazon GuardDuty that uniquely identifies attack sequences spanning multiple AWS data sources and resources within a 24-hour time window within an AWS account.

This addresses the risk where an attack could be comprised of a number of related suspicious activities over a period of time. Each of these suspicious activities may generate their own individual finding. However, these may be of a lower severity and act as a weak signal, and so not seen as presenting a real threat. However, when these weak signals are considered together, and the sequence of these activities align to a more suspicious activity, GuardDuty will generate an attack sequence finding.

In this case, we have triggered a finding of type AttackSequence:IAM/CompromisedCredentials. We can see looking at the summary of findings that this has been given a critical severity level.

Clicking into the finding and selection "View details" brings up the overview page. This provides a compact view of the attack sequence details, including signals, MITRE tactics, and potentially impacted resources. In the screenshot below, (1) shows the signals, (2) shows the MITRE tactics, and (3) shows the indicators.

Signals displays a timeline of events that are involved in the attack sequence. Each individual signal could be an API activity or finding that GuardDuty used to detect the attack sequence. Each signal, that is a GuardDuty finding, has it's own severity level and value assigned to it. In the GuardDuty console, you can select each signal to view the associated details.

One of my favourite aspects of the new feature is the mapping of the finding to both MITRE ATT&CK(™️) tactics and techniques. This "compromised credentials" attack sequence was comprised of the following 3 MITRE ATT&CK tactics. GuardDuty uses the MITRE ATT&CK framework to add context to the entire attack sequence. The colours GuardDuty uses to specify the threat purposes used by the threat actor, align with the colours that indicate the critical, high, medium, and low findings severity level.

The indicators section shows observed data that matches the pattern of a security issue, and is the reason why this collection of signals was identified as an attack sequence. For example, the "High risk API" indicator is flagged as the cloudtrail:DeleteTrail and iam:CreateUser API calls were made, which are actions commonly used by threat actors.

I setup a rule in EventBridge to capture an attack sequence finding. A small subset of the JSON event message is shown below. This message also provides details of the associated signals.

Overall, this is a fantastic new feature in GuardDuty and I am excited to see more attack sequence detections being added over time.

Accelerating builds with Amazon Q Developer Agent

Matt Lewis — Thu, 21 Nov 2024 12:07:45 +0000

Background

I have been using the Amazon Q Developer Agent for software development for some time, looking at ways to get the agent to consistently generate more accurate output. This has highlighted the importance of the prompt, as the primary way of instructing the agent about the type and style of content to be generated. I have found the more precise guidance the prompt contains, the better the output. However, crafting these prompts can be time consuming. This leads to another challenge of ensuring that prompts are used in a consistent fashion across all engineers in a team.

In this post we look at a simple way of introducing “prompt templates” as a better way of ensuring the accuracy of content generated. The goal is to generate a complete project using a number of AWS services written in Python, with the infrastructure managed and provisioned by Terraform. This is being carried out with limited knowledge of these languages.

Bootstrapping our project

We start off by bootstrapping the project with just 2 files:

requirements.md - a markdown file containing our requirements in terms of programming languages and other guidance. This acts as our prompt template
architecture.puml - a Plant UML diagram with the design of the application we want to build

From here, we can now pass in a simple prompt to the Amazon Q Developer Agent:

“Create a complete project implementation including source code, unit tests and a requirements.txt file that meets all of the project requirements as set out in the requirements.md file. Use Terraform following standard best practice to define and deploy all services as detailed in the Plant UML diagram format below:”

I have not found an accurate way of getting Amazon Q Developer to recognise the .puml file, so for the moment, I copy and paste the Plant UML diagram content into the prompt:

The Amazon Q Developer Agent for software development plans out all the steps it needs to take to meet the ask. In the very first step, the agent states:

I need to open requirements.md to review the project requirements. Based on Plant UML diagram, I can see it's an AWS serverless architecture with an API Gateway, Lambda functions and DynamoDB. I'll first create the necessary project structure

The complete summary of changes are shown in the screenshot below. It is interesting to see the agent is clever enough to recognise that some of the imports are not working correctly, and it continually iterates after each change, until it is confident that the requirements have been met.

I accept the proposed code changes, and now I have a full project structure that has been created for me, with a README.md file that gives me more details about the project.

Running the application

Next we want to get the application up and running. I recorded a video to show this working. There were no code changes needed. I just needed to execute a python script to package up the source code for each Lambda function into a Zip file. I also used the inline chat functionality of Amazon Q Developer to output the API endpoint URL so I could run some cURL commands.

Design versus Build Comparison

The only details of what AWS services that made up the application were shown in the Plant UML diagram. What I found most impressive was how accurately the software development agent created the infrastructure to match the design.

The design shows 4 individual AWS Lambda functions called CreateItem, ReadItem, UpdateItem and DeleteItem. These are the exact names of the Lambda functions created.
The design shows the HTTP verbs (POST, GET, DELETE) and the URL Path Notation. These have been created in API Gateway exactly as they are shown in the diagram.
The design shows a DynamoDB table called Item with a partition key of id. This has also been created exactly as shown in the diagram

In addition, we can see that the code generated conforms to the specification set out in the requirements file, being written in Python with headers and comments and meaningful variable names.

Conclusion

I am really excited to see the potential that exists today with the approach taken here. I love seeing how visual design artefacts can be taken and converted directly into the underlying infrastructure on AWS. This helps to provide a seamless transition between design and build. It also solves another challenge of adopting a prompt template that can be used consistently by engineers within a team and across teams in an organisation. This approach allows for the consistent generation of code artefacts that meet organisation guidelines, by ensuring that project repositories are bootstrapped when created with a standard requirements file.

Amazon Q Developer Agent for Code Transformation

Matt Lewis — Mon, 18 Nov 2024 09:56:30 +0000

Background

Here in the UK, the National Cyber Security Centre (NCSC) is the 'technical authority' for cyber incidents with a view that:

patching remains the single most important thing you can do to secure your technology, and is why applying patches is often described as 'doing the basics' blog post

All too often, all engineering effort is spent building new features, and existing applications are left untouched, until they are running out of date versions of libraries and frameworks with all kinds of inherent vulnerabilities. This is where the Amazon Q Developer Agent for Code Transformation comes into its own. In this article, we take the agent for a spin looking to upgrade a Java 11 application to Java 17.

Bicycle Licence Application

In March 2020, I presented an online AWS tech talk demonstrating features of Amazon QLDB in an application written in Java 11 and Spring Boot. In the past couple of months, I have replaced Amazon QLDB with Amazon DynamoDB, and made sure that it is simple to start up and run as a Java 11 application. This is now a great project to test out the code transformation agent. It is a more complex application with around 750 lines of code than a basic "Hello World" application, but not so large it is difficult to understand. You can clone this project yourself here.

Setting up the Java 11 application

All screenshots are taken using the Intellij IDEA. The first step is to clone the repository and open as a new project. Make sure the project structure is setup to use version 11 of the Java SDK:

The application requires a DynamoDB table with a Global Secondary Index to be setup in the eu-west-1 region, and there is a CloudFormation template provided you can use to set this up. I couldn't remember the exact command to use, but luckily Amazon Q on the command line came to the rescue.

Run a mvn clean and then a mvn compile, which will compile all of the code successfully. You can then launch the application using a new Spring Boot configuration:

Creating a new Bicycle Licence record

Once launched, the application will be running at http://localhost:8080/. Opening this in a browser window will render the landing page for the application:

From here, you can start by creating a new fictitious bicycle licence by specifying a name, telephone number and email address:

Once created, you can go into the view/update licence tab and add some points to the licence:

Finally, you can click in the history tab and view all the events that have taken place against that record:

Now we have this up and running as a Java 11 application, we want to look to migrate to Java 17.

Running the code transformation agent

The first step in running a code transformation is to type /transform into the Amazon Q chat window.

From here, Amazon Q will analyse the open workspace to identify if there is a module available running Java 8 or Java 11 that can be transformed. It will automatically recognise the bicycle-licence-ui module, and pre-select this for you. We can simply confirm we want to transform this module to JDK17.

There is also an option for the agent to build your module with or without running unit tests. The default is to run tests, and a number of unit tests are included as part of the project to show this feature working.

The first step is that Amazon Q builds your module locally, downloading all dependencies, and then running the unit tests. Assuming this is successful, Amazon Q will then scan the project files and get ready to start the job. To do this, the project artifacts are uploaded to a managed secure build environment on AWS.

Once the files have been uploaded, the transformation job has been accepted and is ready to start. The application is built again using Java 11. Following this, the code is analysed in order to generate a transformation plan.

This is the plan used by the agent to transform your code. The whole concept of an agent is that it can run autonomously to complete a complex task, and take actions based upon its findings as it progresses, without direct human intervention. The agent can make use of RAG and custom models, which are all abstracted away from the end user. It does mean that the final code updates may end up being slightly different than the initial plan, as the agent will continue to re-evaluate its progress after each step.

The most impressive feature for me is watching the agent apply the updated dependencies and code changes, and then building the module in a Java 17 environment. You can see from the screenshot below that each time updated dependencies were added, the application failed to compile. When this took place, the agent is able to access other underlying models to work out what further changes are required, until eventually the application can now be built successfully in Java 17.

After just over 12 minutes, the transformation job was complete, and it was time to review the code diff and see the proposed changes:

Clicking "view diff" opens up a new window highlighting the files that have been modified:

You can click on each one, to see these changes. In the example below, we can see that a new method has been added to the BicycleLicenceDynamoDBRepository.java class. This is because the CrudRepository interface provided by Spring Data that this class implements has had this new method added to it in the version upgrade.

You can also view the Code Transformation Summary provided by Amazon Q. This provides details around how many lines of code were analysed, how many files have been changed, how many planned dependencies have been added and so on. It also provides a build log summary. In this case, I can see that all source files were successfully compiled and 6 tests ran without any failures, errors or skips.

We are now in a position where we can test the application after it has been transformed to Java 17. After accepting the code changes, we run an mvn clean and mvn compile and reload all project dependencies. It also involves making sure the project structure is setup to use version 17 of the Java SDK, alongside the Run Configuration.

Running the Java 17 application

After making the previous changes, we run the application and can interact with the bicycle licence with no issues. However, one thing we notice is a warning message in the console that the AWS SDK for Java 1.x has entered maintenance mode and will reach end of support on December 31, 2025.

In reality, it's a little disappointing that the AWS SDK library was not updated as part of the code transformation. The reality is that there are significant changes involved, and the AWS SDK for Java 2.x is a major rewrite of the 1.x code base. Out of curiosity, I wanted to see how the software development agent would handle this.

AWS SDK v1 to v2 upgrade with software development agent

With the AWS SDK for Java v1 already in maintenance mode and not updated by the code transformation agent, I wanted to see how the software development agent would handle the upgrade. I typed in \dev in the chat window, and entered the simple prompt of "Rewrite this application to use the AWS SDK for Java 2.x". The agent analysed the application and then worked through a whole set of changes

I really liked the fact that the developer agent created a migration plan which it then used iteratively to update all dependencies. This was a markdown file as shown below:

Although the developer agent came up with a large number of correct changes, there were still some errors left behind. This really helped to highlight the differences between the two agents currently available. The two key points for me are:

The software development agent does not allow you to test the generated code before it is accepted. This means that any issues such as compilation errors will need to be fixed manually (supported by the chat interface), or thrown back to the agent consuming another code generation from your quota
The code transformation agent uploads your artifacts to a secure build environment, and will continually try to build and compile your code, fixing any errors as it goes along, until it is complete.

Conclusion

The Amazon Q Developer Agent for code transformation is a great example of the value that agents can bring, and why I believe they are the future for coding assistants. It handles the complex task of upgrading an application from an older version to a newer version autonomously, significantly reducing developer effort.

The two main drawbacks I encountered are:

The agent did not look to transform the outdated AWS SDK for Java 1.x libraries to the latest AWS SDK for Java 2.x libraries
The target version is currently at Java 17. This is now outdated itself. Amazon Corretto 17 was released in September 2021, whilst Amazon Corretto 21 was released in September 2023 and Amazon Corretto 23 was released in September 2024, and hopefully we will see these more recent versions supported shortly.

Nevertheless, I really hope you try this agent out for yourself, and I'd love to hear your feedback.

Top tips to pass the AWS AI Practitioner Exam

Matt Lewis — Mon, 23 Sep 2024 10:27:15 +0000

I sat and passed the AWS Certified AI Practitioner exam last week. It’s currently still in beta, but that comes with the bonus of receiving an Early Adopter badge for anyone that is successful before Feb 15th, 2025.

It’s classed as a Foundational level exam, which puts it alongside the AWS Cloud Practitioner exam. But don’t let that fool you, a good general knowledge of AWS cloud helps, but you definitely need to freshen up on AI/ML terminology and concepts to be confident of a pass going into the exam.

Study Guides

Alongside the official exam guide, I used the following online resources:

Stéphane Maarek's online course on Udemy via a work subscription
The AWS official exam prep standard course on AWS Skill Builder
The AWS official Practice Question Sets on AWS Skill Builder

There are additional resources available on AWS Skill Builder for anyone with a subscription.

Top Tips

There is no shortcut to pass the exam, other than ensuring you have covered all of the material called out in the exam guide. However, the following are my top 5 topics to make sure you know well, to help maximise your chances.

Machine Learning Lifecycle

It is important to understand the various phases of the machine learning lifecycle and the order in which they take place e.g. feature engineering takes place before model training. There are more details provided in the Machine Learning Lens of the Well Architected Framework:

It is also important to understand what AWS services are available to help in each phase such as AWS Glue and Amazon SageMaker Data Wrangler.

Model Selection and Customisation

It is critical to understand the trade offs in time, effort and complexity in selecting an appropriate model and ensuring it meets your requirements. The following is a high level summary:

The simplest option is to use an AI/ML hosted service such as Amazon Comprehend or Amazon Rekognition. You will need to know about all of the AWS hosted AI/ML services and what their capabilities are at a high level e.g. text-to-speech and text translation.

Following this you can use pre-trained foundation models available in services such as Amazon Bedrock and Amazon SageMaker JumpStart or you can bring a model into Amazon SageMaker.

The recommended way to first customise a model is using prompt engineering. You need to understand about different types of prompting and the use of prompt templates. Remember that with prompt engineering, there is no change to the underlying model weights.

Retrieval-Augmented Generation (RAG) is another approach to improve responses, this time by referencing an external knowledge base that is outside of the LLM's training data. There are a variety of options in this space, most notably Amazon Bedrock Knowledge Bases, but it is possible to take advantage of vector databases such as Amazon OpenSearch or the pgvector extension for PostgreSQL to roll your own RAG solution.

Next up is fine-tuning, with a couple of different options dependent upon where your model is hosted. Remember that with fine-tuning you are changing the weights of the model. Amazon Bedrock supports fine-tuning and continued pre-training. There are important distinctions between these.

Fine-tuning relies on you providing your own labelled data set to the model. Be aware that if you only provide instructions for a single task, the model may lose its more general purpose capability and experience catastrophic forgetting.
Continued pre-training uses unlabelled data

After you have created your custom model, you need to purchase provisioned throughput to be able to use it.

Amazon SageMaker supports both domain-adaptation fine-tuning and instruction-based fine-tuning.

Domain adaptation fine-tuning allows you to leverage pre-trained foundation models and adapt them to specific tasks using limited domain-specific data.
Instruction-based fine-tuning uses labeled examples to improve the performance of a pre-trained foundation model on a specific task.

The choice comes down to whether you want to train a model around domain data or to follow instructions and perform a specific task.

Finally, the most time-consuming and costly approach is to create your own custom model with Amazon SageMaker.

Parameters

It is useful to understand what parameters are available to you. These fall into two distinct categories.

Hyperparameters are used to control the training process. The most common are:

Epoch: The number of iterations through the entire training dataset
Batch Size: The number of samples processed before updating model parameters
Learning Rate: The rate at which model parameters are updated after each batch

Inference parameters are settings you can just during inference, that influence the response from the model. The most common are:

Temperature: Temperature is a value between 0 and 1, and it regulates the creativity of the model's responses. Use a lower temperature if you want more deterministic responses, and use a higher temperature if you want creative or different responses for the same prompt
Top K: The number of most-likely candidates that the model considers for the next token. Choose a lower value to decrease the size of the pool and limit the options to more likely outputs.
Top P: The percentage of most-likely candidates that the model considers for the next token. Choose a lower value to decrease the size of the pool and limit the options to more likely outputs.

Amazon SageMaker Capabilities

Amazon SageMaker is a service that provides a whole host of features and capabilities you need to be aware of. The exam will test your awareness of all these such as:

SageMaker Clarify
SageMaker JumpStart
SageMaker Studio
SageMaker Data Wrangler
SageMaker Feature Store
SageMaker Model Cards
SageMaker Model Dashboard
SageMaker Model Monitor
SageMaker Ground Truth

Metrics

Finally, expect to see a number of question around model performance metrics, and which one is the most appropriate.

For classification tasks such as spam detection you have:

Accuracy: The ratio of correctly predicted instances to the total instances
Precision: How many of the predicted positive cases are positive
Recall: How many positive cases were predicted correctly
F1 Score: The F1 score combines precision and recall into a single metric

You should be aware of the confusion matrix, and when you might want to optimise for recall (life-saving tasks such as cancer diagnosis where you want to minimise false negatives) versus when you might want to optimise for precision (minimise false positives such as spam email detection)

Task generation metrics include:

ROUGE (Recall-Oriented Understudy for Gisting Evaluation): used to evaluate text generation or summarisation tasks
BLEU (Bilingual Evaluation Understudy Score): used for translation tasks
Perplexity: measures how well a model can predict a sequence of tokens or words in a given dataset.

You should also know how to interpret model performance. For example, if your model performs better on training data that on new data it is overfitting which is exhibiting high variance. If your model does not work well on training data or new data it is underfitting and exhibiting high bias. If there are disparities in the performance of your model across different groups then it is showing bias.

Taking the Exam

Congratulations if you have booked your exam. After having taken a number of AWS exams over the years, these are my top tips for the exam itself:

Don't panic. It's likely there will be one or two questions come up that confuse you. Simply flag them for review and move on.
Read the question carefully and pick out the key information it is asking for
If you don't know the answer for a question, you can often eliminate a couple of the possible options, which will help narrow it down.

Code Transformation with Amazon Q

Matt Lewis — Tue, 09 Jul 2024 09:24:42 +0000

Introduction

An exciting feature of Amazon Q is the concept of agents that autonomously perform a complex, multistep task from a single prompt. One of these agents is the "Developer Agent for Code Transformation" which automates the process of upgrading and transforming Java applications from Java 8 or Java 11 to Java 17, with more language support on the way.

I have previously demonstrated this capability using a simple Java 8 example. However, when I stumbled upon an old Java 11 Spring Boot application with thousands of lines of code, the build failed to compile on Java 17 with various upgrade issues, and it meant a time-consuming process to manually step through all of the problems.

Now, a few months on, I wanted to see whether any step change improvements had been made to the agent, so dug out the old codebase.

Setting up the Java 11 Bicycle Licence Application

In March 2020, I presented at an online AWS Tech Talk on new features of Amazon QLDB. To bring this to life, we built a quick demo using Java 11 and Spring Boot. You can find the code repository on GitHub here. The repository does require a QLDB Ledger and table to be set up in the eu-west-2 region, with more details provided in associated README.md file.

First create a new QLDB ledger in the eu-west-2 region:

And once created, open up the PartiQL editor and run a command to create a new table:

Then we create a new directory by cloning the repository using the following command:



git clone https://github.com/mlewis7127/bicycle-licence-ui-master.git

We will use the JetBrains Intellij IDEA for this transformation, and choose to open a new project and select the folder created in the previous step.

If a pop-up appears, enable annotation processing for Lombok. Make sure to set the project to use version 11 of the Java SDK. I am using Amazon Corretto for my distribution of the Open Java Development Kit (OpenJDK).

This is set for the project by selected File --> Project Structure, and select Project under Project Settings. Clicking on the SDK dropdown box, allows you to select Download SDK where you can specify the version and vendor of the JDK to download.

From here, run a Maven clean and then a Maven compile. In the screenshot below I am doing this from the Maven plugin, or you can run from the command line. This will compile all of the code successfully as shown below.

Now launch the application by running the BicycleLicenceApplication class in a new configuration.

This will start the application, which can be accessed in a browser window on http://localhost:8080/. I have put together a short video below showing the application running as a Java 11 application.

Using Amazon Q to automatically upgrade to Java 17

Now we have the application successfully running using Java 11, we want to upgrade to Java 17. We tell Amazon Q that we want to use the Code Transformation agent by opening a chat window and typing /transform and selecting the agent.

This launches the Developer Agent for Code Transformation. The bicycle-licence-ui module is automatically selected, and we press confirm to let the agent know we want to upgrade to Java 17.

Once we select transform, the agent takes over. It starts by building the Java module. Then it uploads the project artefacts that it has just built. Once these files have been uploaded, the code transformation job has been accepted, and the agent begins building the code in a secure build environment. Once built, Amazon Q begins analysing the code in order to generate a transformation plan.

Once created, you can see a summary of the transformation plan. In this case, we have an application with almost 2500 lines of code, in which we need to replace 2 dependencies, with changes made to 5 files.

A summary is also provided of the planned transformation changes.

The transformation plan generated follows a 3 step process:

Update JDK version, dependencies and related code
Upgrade deprecated code
Finalise code changes and generate transformation summary

This is where the massive improvements in code transformation shone. A few months ago, when the build of the application to Java 17 failed, the automated process abruptly ended. Now, the agent takes the compilation errors, and looks to make changes to fix the errors, before attempting to build the code again. You can see below it took several attempts, making changes each time, before the code could successfully build on Java 17. The key point is this was all automated, with no manual input required.

After just 16 minutes, the code transformation was complete and had succeeded.

Amazon Q lets us know about the planned dependency that it updated, with the other identified dependency having been removed.

As well as a number of additional dependencies that were updated during the upgrade

A pop up box allows you to see which files have been changed, and you can select each file individually and run a side by sided comparison to evaluate the changes.

As an example, I can see that all all references to javax.servlet.http.HttpServletRequest have been replaced by jakarta.servlet.http.HttpServletRequest as Spring Boot 3.0 has migrated from Java EE to Jakarta EE APIs for all dependencies. The agent had also implemented a new interface that was present in the latest Spring Framework version, that had not previously existed.

After this, we accept the automated updates, and run a Maven clean and a Maven compile before making sure we click on the top left button in the screenshot to reload the latest version of the dependencies:

We can launch and test the application which is now running on Java 17.

Final Observations

There has been a massive improvement in the capability of the “Developer Agent for Code Transformation” over the past few months. If you had tried and discounted the agent, you should definitely look to give it another go. As the underlying models improve, I think we will see further step change improvements happen in very short timescales on an ongoing basis.

Two areas to call out for me are:

Unit Testing
In the video above, the call to verify the digest failed with a java.lang.NoSuchFieldError in the logs. This is an example where despite having no compilation errors, we can still experience runtime errors. I have updated the GitHub repository with some unit tests as an example, which demonstrates how Amazon Q executes these tests as part of the code transformation.

We were able to fix the error by correcting a version mismatch between AWS SDK modules. This may not be found by unit tests, unless we were able to interact directly with AWS endpoints as part of these tests, and this is something being worked on. Nevertheless, ensuring there are sufficient unit tests to provide coverage of the core functionality will help to reduce examples of code compiling correctly but failing at runtime.

AWS SDK Upgrades
Although a number of libraries and frameworks were upgraded such as Spring and Log4j, the AWS SDK itself remained on Java 1.x. A big reason for this is the upgrade to AWS SDK for Java 2.x is a major rewrite that will typically require custom development to make work.

Watch the video below to see the agent in action and the steps it takes as described throughout this post

Using GenAI to improve developer experience on AWS

Matt Lewis — Fri, 23 Feb 2024 11:37:14 +0000

Background

Today, many developers find themselves working on multiple projects at the same time, often dealing with unfamiliar codebases and programming languages, and being pulled in many directions. This is backed up by the 2023 "State of Engineering Management Report" by Jellyfish which found that:

60% of teams reported being short of engineering resources needed to accomplish their established goals

This is an area where generative AI has the promise to add real value. The latest Gartner research backs this up, with the planning assumption that:

75% of enterprise software engineers will use AI coding assistants, up from less than 10% in early 2023

With this in mind, enterprises need to prepare now for the inevitable wide scale adoption of these tools, and start taking advantage of the benefits they can offer. In this post, we look at some of the core features of the GenAI services available today on AWS, that help to provide the next generation developer experience.

There are many capabilities available today, which has resulted in a lengthy blog post. These capabilities have been grouped into categories, and structured as follows:

Responsible AI
Code Creation
- Code Completion
- Code Generation
- Customizations
- Infrastructure as Code Support
- SQL Support
- CodeWhisperer on the Command Line
Application Understanding
- Explaining Code
- Application Visualisation
Application Modernisation
- Chat with Amazon Q
- Code Transformation
- Code Optimisation
- Code Translation
Feature Development
Code Vulnerabilities
Debugging and Troubleshooting
Conclusion

Responsible AI

Although not directly part of developer experience, the first area to address is Responsible AI. This is because the rise of generative AI has led to concerns around the ethics and legality of the content generated. The risk is heightened by the continuing legal actions taking place, including the ongoing class action lawsuit against GitHub, OpenAI and Microsoft claiming violations against open-source licensing and copyright law.

The professional tier of Amazon CodeWhisperer is covered by the "Indemnified Generative AI Services" from AWS. This means - quoting from the AWS Service Terms - that

AWS will defend you and your employees, officers, and directors against any third-party claim alleging that the Generative AI Output generated by an Indemnified Generative AI Service infringes or misappropriates that third party’s intellectual property rights, and will pay the amount of any adverse final judgment or settlement

Amazon CodeWhisperer provides a reference tracker that displays the licensing information for a code recommendation. This allows a developer to understand what source code attribution they need to make, and whether they should accept the recommendation.

However, to ensure that you are indemnified, you need to remain opted-in (default) to include suggestions with code references at the AWS Organization level within the CodeWhisperer service console.

AWS also address the toxicity and fairness of the generated code by evaluating it in real time, and filtering our any recommendations that include toxic phrases or that indicate bias.

Code Creation

One of the primary goals of AI Coding Assistants is to increase the productivity of developers in creating code. In this section, we break down this capability into different categories, separating out programming languages, from Infrastructure-as-Code tools, SQL and shell script commands in the console.

Code Completion

With code completion, CodeWhisperer makes suggestions inline as code is written in the IDE. This has been around for some time, and is known by the term IntelliSense in Visual Studio Code.

The challenge with code completion is that developers initiate the process by writing code and they are driving the implementation detail.

Code Generation

With code generation, a developer writes a comment in natural language giving specific and concise requirements. This information, alongside the surrounding code including other open files in the editor, act as the input context. CodeWhisperer returns a suggestion based on this context.
Amazon CodeWhisperer is trained on billions of lines of Amazon internal and open source code. This gives CodeWhisperer an advantage when it comes to making suggestions for using AWS native services. In the example below, CodeWhisperer understands from the input context that we want to create a handler for an AWS Lambda function, and suggests a correct signature and function implementation.

There are techniques to help you generate the best recommendation, and you can find out more details in this blog post on Best practices for prompt engineering with Amazon CodeWhisperer.

Customizations

The source code that Amazon CodeWhisperer is trained on is great for most scenarios, but does not help when an organization has their own internal set of libraries, best practices and coding standards that must be followed. This is where the customization capability comes in. With this capability, you create a connection to your code repositories (either third party hosted or via an S3 bucket), and then train a customization from this codebase. This capability is in preview and available only in the Professional tier.

When you create a customization and assign it to a user, they are then able to select that customization in the editor and this will then be used to generate code suggestions.

CodeWhisperer Customizations were designed from the ground up with security in mind. This blog post gives more detail in this space.

Infrastructure as Code Support

CodeWhisperer support for creating code extends beyond just programming languages and into Infrastructure as Code (IaC) tools such as CloudFormation, AWS CDK and Terraform. The screenshot below shows the specification of an RDS instance created as a resource in CloudFormation from a natural language prompt.

The example below uses a simple prompt to configure Terraform Cloud, and then create an EC2 instance using the AMI for Amazon Linux 2.

SQL Support

CodeWhisperer also supports the creation of SQL as a standard language for database creation and manipulation. This covers Data Definition Language commands (such as creating tables and views) as well as Data Manipulation Language commands (from simple inserts through to complex queries with joins across tables).

Generative AI can also help the developer by converting natural language to SQL across many AWS services. In the screenshot below, we are using Generative AI to generate queries from natural language against Amazon Redshift. These queries can be added directly to a notebook and then executed, all within the Redshift Query Editor V2.

It doesn't stop there - you can also use natural language to query Amazon CloudWatch Log Groups and Metrics, and AWS Config Advanced Queries.

CodeWhisperer on the Command Line

CodeWhisperer is also available on the command line. This allows you to write a natural language instruction which is converted to an executable shell snippet. It supports hundreds of popular CLIs. This reduces the overhead on the developer of having to remember these commands, or the context switching of navigating away from the IDE to look them up. You can also execute the commands directly, as we see below.

Application Understanding

One of the most valuable use cases for GenAI is helping to understand existing applications. A common problem is supporting an application with limited if any documentation, written in an unfamiliar programming language or style, and with no comments in the code.

Explaining Code

Working in combination with CodeWhisperer in your IDE, you can send whole code sections to Amazon Q and ask for an explanation of what the selected code does. To show how this works, we open up the file.rs file cloned from this GitHub repository. This is part of an open source project to host documentation of crates for the Rust Programming Language, which is a language we are not familiar with.

We select a code block from the file, right-click, and then send to Amazon Q to explain:

Amazon Q provides a detailed breakdown of the function that has been written in Rust, and the key activities that it carries out. What is really useful in this case, is Amazon Q suggests follow up questions to help you get an even better understanding of the code. This allows you to chat with and ask questions about the code segment:

Application Visualisation

A new feature that is incredibly useful is to visualise how an application is composed using Application Composer directly within the IDE. At the end of last year, Application Composer announced support for all 1000+ resources supported by CloudFormation.

This now works for any application running in AWS, even if not originally deployed through CloudFormation, with the introduction of the AWS CloudFormation IaC Generator (for more information see Infrastructure as Code Generator). This allows you to generate a CloudFormation template. Within VSCode, you can select the template, right-click, and select "Open with Application Composer".

The screenshot below uses the CloudFormation template from an AWS samples application in GitHub which can be found here.

Application Modernisation

A massive problem for organisations is the amount of technical debt growing in legacy applications. The challenge here is how to modernise these applications. The starting point is to make sure you understand the application in question using the approaches above. In addition, a number of other capabilities are available.

Chat with Amazon Q

Amazon Q is available in both the console and the IDE to answer questions around AWS. This allows you to ask questions about AWS services, limits and best practices alongside software development.

The generated content returned contains links to the source articles, that allow you to do more in-depth reading to validate the response. Again, when writing code in the editor, this allows the developer to remain in the IDE to ask these questions, reducing the distraction and the context switching.

Code Transformation

Code Transformation is a formal feature of Amazon Q. It is currently available in preview with support to carry out complete application upgrades from Java 8 or Java 11 to Java 17. Coming soon is support to perform .NET Framework to cross-platform .NET upgrades to migrate applications from Windows to Linux faster. The video below shows the steps involved to automatically update a Java application.

The internal Amazon results are impressive, with 1000 production applications upgraded from Java 8 to Java 17 in just two days, with an average of 10 minutes to upgrade each application.

Code Optimisation

Code optimisation is a concept supported by Amazon Q through its built-in prompts. In the example below, we have inefficient code with two loops that could be combined into a single loop. This is correctly detected with suggestions made to optimise the code.

Code Translation

Code translation is another concept support by Amazon Q through prompts. As always, the accuracy and quality of the code generation is dependent upon the size and quality of the training data. In this context, there is more support for languages such as Java, Python and JavaScript than C++ or Scala. In the screenshot below, we have taken an AWS Lambda function written in JavaScript and asked Amazon Q to translate to Python.

Feature Development

Feature Development is a formal feature of Amazon Q. You explain the feature you want to develop, and then allow Amazon Q to create everything from the implementation plan to the suggested code. For this example, we create an application using an AWS SAM quick start template for a serverless API. We then ask Q to create a new API for us.

Amazon Q uses the context of the current project to generate a detailed implementation plan as shown below.

By selecting 'Write Code', Amazon Q then generates the code suggestions, using the coding style as already set out in the current project.

This results in the proposed code suggestions, whereby you can choose to click on each file to view the differences, and finally choose whether or not to accept the changes.

This has the promise of a hugely powerful feature. In the screenshots above, we have shown how Amazon Q has taken a natural language instruction, and created everything from the Infrastructure-as-Code, function implementation, and unit tests.

Code Vulnerabilities

It is critical to prevent vulnerabilities being present in your application, and the earlier these are detected and resolved in the development life cycle the better. CodeWhisperer can detect security policy violations and vulnerabilities in code using static application security testing (SAST), secrets detection, and Infrastructure as Code (IaC) scanning.

Within CodeWhisperer, you can select to run a security scan.

This performs the security scan on the currently active file in the IDE editor, and its dependent files from the project.

Security scans in CodeWhisperer identify security vulnerabilities and suggest how to improve your code. In some cases, CodeWhisperer provides code you can use to address those vulnerabilities. The security scan is powered by detectors from the Amazon CodeGuru Detector Library.

In the screenshot below, we use sample code that contains a vulnerability to Cross Site Request Forgery (CSRF), and this is picked up by the scan.

Having detected there is an issue, we select the function with the vulnerability, and send it to Amazon Q to fix. Amazon Q generates code that we copy or insert directly into the editor, as well as providing details about the issue and resolution, and suggesting follow up questions if we want to learn even more.

Debugging and Troubleshooting

Moving outside of the IDE and into the AWS console, AWS now provide situations where generative AI capabilities can be used to help debug problems.

In the example below, we have tested an AWS Lambda function that is failing. This opens up a button we can select to get Amazon Q to help us with troubleshooting.

Amazon Q not only provides a summary of what the initial analysis of the problem is, but can then also be used to provide the steps required to resolve the issue.

Outside of the editor, Amazon Q can also help to troubleshoot network-related issues by working with Amazon VPC Reachability Analyzer. This allows you to ask questions in natural language as explained in this post introducing Amazon Q support for network troubleshooting.

Conclusion

The concept of generative AI is that the content generated is non-deterministic. This means the exact code suggested may be slightly different when executed against the same prompts. There are occasions when the suggested code may not compile or contain an invalid configuration. This means there is still a level of developer expertise required to drive the tooling and understand the content generated. There is also training required to understand how best to write comments to get the best suggestions, in effect a variation on prompt engineering. However, without question, the capabilities available today will increase your productivity when developing on AWS.

For edge cases, there are other alternatives available which is worth mentioning. CodeWhisperer abstracts away all of the complexity of dealing with LLMs. Amazon Bedrock allows you API access to supported models such as Claude and Llama 2. There are also open source code LLMs like StarCoder you can bring into Amazon SageMaker. This allows you more control on what dataset or instructions you might want to fine tune a base model, but brings with it higher cost and complexity.

Hopefully this post has given you a taster of many of the capabilities now available that form the next generation developer experience on AWS, and will encourage you to try it out for yourself.