DEV Community: Jeroen Reijn

Amazon ECS Express Mode from an IaC perspective

Jeroen Reijn — Sat, 20 Dec 2025 21:34:14 +0000

Amazon recently launched a new feature for Amazon ECS called ECS Express Mode. While reading the announcement, I got curious as I use ECS on a regular basis. In this post, we'll look at what ECS Express Mode is, how you can use it from Infrastructure as Code by means of AWS CDK, and what the limitations are.

Most posts I’ve seen look at ECS Express Mode from an AWS Console (ClickOps) or AWS CLI perspective. The AWS Console is an easy way to get going, but in my experience, most engineers in larger organizations use Infrastructure as Code (IaC) tools like AWS CDK or Terraform for creating resources in AWS. Before we dive into the IaC part, let’s first take a closer look at ECS Express Mode.

What is ECS Express Mode?

Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service that helps you easily deploy, manage, and scale containerized applications. With ECS you can run all kinds of container based workloads. You can run container instances for data processing, web applications or spin up containers based on events.

ECS Express Mode is a new feature of Amazon ECS with the promise to go from container image to a fully operational ‘production grade’ web application without thinking too much about infrastructure. The intended promise is to let application development teams focus on the application and let AWS apply the best practices around container infrastructure, scaling, and deployments. It will simplify the process of getting started with ECS and all the different components outside of ECS you will need to set up to run, for instance, a public accessible web-application.

ECS Express Mode is focused on deploying web applications and APIs. It provides a fully integrated set of AWS resources out of the box. Resources that you would normally have to define, configure, and wire together manually using infrastructure as code. If you’re an experienced ECS user, you’ll immediately appreciate how much heavy lifting Express Mode handles for you.

When you create your first Express Mode service, ECS automatically provisions and configures the following resources:

ECS Cluster - A default cluster based on Fargate is created for you if you don’t provide an existing cluster.
ECS Task Definition - Defines the container image, resource requirements, environment variables, and runtime configuration.
ECS Service - Manages task lifecycle, placement, and health checks.
Rollback alarm - When the service starts throwing a larger amount of 40X or 50X response codes after a new deployment, it can revert the deployment
Canary Deployment strategy - By default, the service uses a canary deployment mechanism to deploy the service.
Application Load Balancer (ALB) - Provides HTTP-based load balancing for your service. A single ALB will serve up to 25 ECS express services; when that limit is exceeded, Express Mode automatically provisions an additional ALB.
ALB Target Groups - Route traffic from the load balancer to the running tasks of your service.
Route 53 Records (AWS-managed) - Express Mode assigns an AWS-managed domain name that is not visible in your account but is automatically wired to your load balancer.
ACM Certificates - An SSL/TLS certificate is created for each service to enable HTTPS. These certificates are managed in your account.
Security Groups - Security groups are created for each layer of the network stack (load balancer, tasks, etc.). They follow the principle of least privilege—you only configure the application port once, and Express Mode manages the rest.
Application Auto Scaling - A default auto scaling policy is created along with the necessary CloudWatch alarms. By default, scaling is based on CPU utilization, but you can switch to memory utilization or request count.
Cloudwatch Logs - A new CloudWatch log group is created for your service. You can configure the log group and change the prefix if you want.

One of the great benefits is that ECS deploys all these resources in your account, which means you can see all individual components, view the configuration, and make changes to the existing configuration if required.

As you can see from the above list, that’s quite a list of things to configure if you had to do this manually. If you are a user new to ECS and see a lot of unknown elements in the above list, ECS Express mode might be a great fit for you. To get started with ECS Express Mode, you only need three things:

An existing container image
An infrastructure role - an IAM role that lets the ECS provision (non-ECS) resources in your account.
A task execution role - an IAM role that gives the container permissions to interact with other AWS services

Creating an ECS Express Mode service in AWS CDK

ECS Express mode has support for CloudFormation and therefor also support in AWS CDK. The ECS Express Mode service takes care of provisioning all of the resources for you, so there is only a few CloudFormation resources for the express mode service itself. Let's take a look at what using AWS CDK to provision an ECS Express Mode service looks like.

IAM roles and permissions

Let's first start with creating a task executions role with the required permissions for our task. In this post, we will use a simple nginx service to show how the service works, so we don't need a lot of permissions. You can get started with the default provided managed policy for ECS tasks: AmazonECSTaskExecutionRolePolicy.

const taskExecutionRole = new Role(this, 'executionRole', {
    roleName: 'cdk-ecs-express-demo-execution-role',
    assumedBy: new ServicePrincipal('ecs-tasks.amazonaws.com'),
    description: 'ECS Task Execution Role',
    managedPolicies: [ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonECSTaskExecutionRolePolicy')]
});

The next role we create will be for the ECS service to create the resources in our account. Luckily AWS, has provided a default managed policy which we can use: AmazonECSInfrastructureRoleforExpressGatewayServices.

const infrastructureRole = new Role(this,'infrastructureRole', {
    roleName: 'cdk-ecs-express-demo-infrastructure-role',
    assumedBy: new ServicePrincipal('ecs.amazonaws.com'),
    description: 'ECS Task Infrastructure Role',
    managedPolicies: [ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonECSInfrastructureRoleforExpressGatewayServices')]
});

Upon closer inspection, you can imagine this policy contains quite a list of permissions as it needs to cover a lot of services. It's worth inspecting the policy when your first start to use it. I won't copy it here as it contains about 280 lines or JSON at the moment.

Defining the ECS Gateway Service

Now that we've set up the roles with the correct permissions, we can move to the final step, which is to create the ECS Express Mode Service. Currently (as of the beginning of december there is a level 1 CDK construct available, which maps directly to the CloudFormation resource. The resource is named CfnExpressGatewayService.

let cfnExpressGatewayService = new CfnExpressGatewayService(this, 'ExpressServiceNginx1', {
    primaryContainer: {
        image: 'nginx:latest',
    },
    executionRoleArn: taskExecutionRole.roleArn,
    infrastructureRoleArn: infrastructureRole.roleArn,
});

In general, that's it. That's all you need to run your web app container service in ECS, which I think is pretty great. Now, how can you reach the service?

Accessing the service

The ECS express mode service will handle DNS for you. The DNS records are the only thing that are not created within your own account, as far as I could tell (the ACM certificates are though). According to the documentation, the service name and region should be enough to determine the URL of the service.

So if we define the service as:

let cfnExpressGatewayService = new CfnExpressGatewayService(this, 'ExpressServiceNginx1', {
    serviceName: 'demo-express-service'
    primaryContainer: {
        image: 'nginx:latest',
    },
    executionRoleArn: taskExecutionRole.roleArn,
    infrastructureRoleArn: infrastructureRole.roleArn,
});

and we follow the pattern mentioned in the docs:

https://<service-name>.ecs.<region>.on.aws/

should have resulted in the service being accessible from https://demo-express-service.ecs.eu-west-1.on.aws/.

That made me wonder if the service name is unique, just like with an S3 bucket name, but when I tried specifying the serviceName property of the CfnExpressGatewayService the resulting URL would return a 404. The only way I've found to determine the correct URL for the service is by using the Endpoint return value from the CloudFormation resource.

new CfnOutput(this,"service1url", {
    key: 'service1url',
    value: 'https://'+ cfnExpressGatewayService.getAtt("Endpoint").toString()
})

Which results in the following output:

https://ng-e6840bdfebb54e28bb5c3c9bd7c1f5fa.ecs.eu-west-1.on.aws

As you can see there, is no mention of the service name in the generated endpoint. It does seem the first two letters of the domain are coming from the service name, but that might be a coincidence.

Once the service is up and running, you can inspect all the different components.

Configuring alternative settings

We've looked at the minimum configuration. Now let's take a look as some more configuration options.

Specifying your own ECS cluster

By default, the service creates an ECS cluster in your default VPC with the cluster name default. If you don't have a default VPC or want to have more control over your cluster, you can configure your own cluster.

const cluster = new Cluster(this, 'Cluster', {
    vpc: vpc,
    clusterName: 'cdk-ecs-express-demo-cluster',
})

let cfnExpressGatewayService2 = new CfnExpressGatewayService(this, 'ExpressServiceNginx2', {
    cluster: cluster.clusterName,
    primaryContainer: {
      image: 'nginx:latest',
    },
    executionRoleArn: taskExecutionRole.roleArn,
    // other optional configuration options
    healthCheckPath: "/",
    serviceName: 'express-service-nginx-2',
    infrastructureRoleArn: infrastructureRole.roleArn,
    // Autoscaling configuration
    scalingTarget: {
        minTaskCount: 1,
        maxTaskCount: 3,
    },
    // cpu: '512',
    // memory: '512',
});

According to the CloudFormation documentation, you can specify either the cluster name or the cluster ARN. However, when I tried the ARN, CloudFormation returned with an error.

Resource handler returned message: "Invalid request provided:
Invalid identifier: Unexpected number of separators (Service: Ecs, Status Code: 400, Request ID: ee074322-e841-4256-8bb7-2b2014b9c76e) (SDK Attempt Count: 1)" (RequestToken: ec5bfa00-2c43-db0f-3b7c-6374d0a33f5a, HandlerErrorCode: InvalidRequest)

I'm not sure if that's a problem in the documentation or if I misconfigured something. I advise you to stick to the clusterName, which seems to work.

Alternative configuration options

The express mode service we created previously uses AWS best practices. If you have slightly different requirements, you can change specific parts of the configuration. For your container you can change for instance the cpu and memory requirements.

By default the ECS server will run in the default VPC and in a public subnet. You can specify alternative network settings for your service depending on your requirements. For instance your can switch to a different VPC and subnet. Because you can change the ECS cluster, you can probably also use Fargate Spot or EC2 based compute instead. I have not tested that though, and it might be something for another blog post.

Some settings can't be changed right now. Canary deployment for instance is the only supported deployment strategy. I think it's a great default, but I hope they will add linear or blue/green deployment as these strategies are now ECS supported deployment strategies.

ECS Express mode only allows you to configure a single container. If you’re currently using ECS and are using a sidecar container for for instance observability purposes, you won’t be able to do that during creation with ECS express mode. You might want to consider using an Open Telemetry library, which integrates with your application framework. If you really need a sidecar container you can import the task definition into your stack, after it has been created. Express Mode will keep ‘manual’ changes during additional deployments / updates.

Configuring a WAF for your ECS service

In all cases where I use ECS with a public ALB, I always add a Web Application Firewall (WAF). I also tried this for the ECS Express mode service, but while trying this, I learned there things to consider. There is currently no out-of-the box experience for attaching the WAF to the load balancer created by the ECS service. The CloudFormation resource AWS::ECS::ExpressGatewayService does expose some return values after the resource has been created, which you can use to get the load balancer ARN.

With the return value for the ALB ARN, you can assign the WebACL to the created Load balancer.

const cfnWebACLAssociation = new CfnWebACLAssociation(this, 'ALBWebACLAssociation', {
    resourceArn: cfnExpressGatewayService.getAtt("ECSManagedResourceArns.IngressPath.LoadBalancerArn").toString(),
    webAclArn: wafV2.attrArn,
});

// Don't forget to add a dependency, otherwise this association might happen before the service has been created.
cfnWebACLAssociation.addDependency(cfnExpressGatewayService);

There is a tricky problem I foresee, which is when you hit the 25 services limit and a new Application Load Balancer is created. ECS Express Mode handles this by itself, and if you don't have all 25 services defined in the same CDK stack, it gets hard to track if you'll need to create a new WebACL Association.

Resource state management

After playing with ECS Express Mode for a while, it made me think. Who is in control of the resources created in your account? Who is responsible for its state? According to the ECS team they are not using CloudFormation internally, but are working with the direct APIs and use their own internal state for managing all resources. If you want to change specific parts of the default generated solution, you can import resources into CloudFormation/CDK and change them, but the ECS service will always be the owner of the resources. In an enterprise context where I see a lot of infrastructure as code, I wonder about the developer experience and aspects like compliance rules.

CDK L3 constructs vs ECS Express Mode

If you're an experienced ECS and AWS CDK user you might question how Express Mode compares with, for instance, the ApplicationLoadBalancedFargateService construct. I think it comes quite close to what ECS express mode delivers. However, express mode also adds autoscaling, deployment rollbacks, canary deployment, smart load balancer sharing, default HTTPS, and domain management out of the box. If you're an experienced CDK user, you can get very far with the CDK provided L3 construct(s). You might even consider creating one that does something similar. The advantage of that would be that you have all AWS resources defined in your in CDK/CloudFormation and you have full control over all your resources. The ExpressGatewayService is a single AWS resource, which means it's tool agnostic and delivers the same level of business value if you use CDK, CloudFormation, Pulumi, Terraform, or any other kind of IaC tool. You're not depending on Terraform modules, CDK L3 constructs, or any other kind of configuration elements when working with IaC tools.

Closing Thoughts

I like what the ECS team has created with ECS Express Mode. It's really great to go from a container image to a production like environment in a matter of minutes. This is going to work great for demo's and quick PoCs. Looking at this from an infrastructure as code perspective it feels a bit unnatural though as the ExpressGatewayService hides a lot of other AWS resources. If you're already a heavy CDK user, you might feel you have too little control over your resources. You can get a similar experience with creating your own L3 construct or using an existing one like the ApplicationLoadBalancedFargateService.
There are still some cases I want to explore further to see how ECS express mode compares to a set of L2/L3 constructs and how to handle changes to the individual components created by the express gateway service. The service is quite new, therefor I hope it will get some nice updates in the near future, like more deployment strategies, and perhaps custom domain support. If you've not looked at ECS Express Mode before I think it's definitely worth to take a look and see if it works for your specific use case.

Further resources

Build production-ready applications with Amazon ECS Express Mode (Containers from the Couch)
Build production-ready applications without infrastructure complexity using Amazon ECS Express Mode (AWS Blog)
From image to HTTPS endpoint in one step with ECS Express Mode
GitHub repository containing an ECS Express Mode sample CDK application with code mentioned in this blogpost.

Improve observability for Windows EC2 instances with the CloudWatch Agent

Jeroen Reijn — Sat, 04 Oct 2025 19:28:00 +0000

Amazon CloudWatch monitors Windows EC2 instances out of the box, but only gives you basic host-level metrics like CPU and network usage. In this post, you’ll learn how to extend observability with the Amazon CloudWatch Agent. We will use AWS CDK in TypeScript to automatically deploy an example instance with an installed and configured CloudWatch Agent.

Default collected metrics

Elastic Compute Cloud (EC2) instances send a set of predefined metrics to CloudWatch. Most of these metrics are system related and focus on CPU and Networking metrics. Under the monitoring tab in the AWS EC2 Console you can get a quick overview of some of out of the box available metrics for your EC2 instance.

It’s a great starting set, but what if you need more? What if you need metrics from inside of the VM?

Gathering additional metrics

If you need more system or application level metrics you can make use of the Amazon CloudWatch Agent. The CloudWatch agent is service which you can run on the EC2 instance and it’s great for:

Collecting system-level metrics (CPU, memory, disk, network)
Gathering custom metrics from your application(s)
Collecting and centralizing logs from various sources
Monitoring both AWS and on-premises environments with a single tool

For a high-level overview of the CloudWatch Agent and how it interacts with an EC2 instance and the CloudWatch service is shown in the following diagram.

You can install the CloudWatch agent via EC2 user data, AWS Systems Manager, or via the AWS EC2 Console. In this post we will install the CloudWatch Agent and its configuration using the user data feature of an EC2 instance. Before we can actually install the agent, we first need to create a CloudWatch Agent configuration, which we can use later on during the installation.

Create a CloudWatch Agent Configuration

The CloudWatch Agent configuration file is a JSON file with four sections:

agent - includes fields for the overall configuration of the agent
metrics - specifies the custom metrics for collection and publishing to CloudWatch
logs - specifies what log files are published to CloudWatch Logs. This can include events from the Windows Event Log if the server runs Windows Server.
traces - specifies the sources for traces that are collected and sent to AWS X-Ray

As you can see there is a lot you can do with the CloudWatch agent. However, in this post we will focus only on metrics.

Let’s take a look at an example configuration:

const cwAgentConfig = {
 agent: {
   metrics_collection_interval: 60
 },
 metrics: {
   namespace: "CWAgent",
   append_dimensions: {
     InstanceId: "\${aws:InstanceId}",
   },
   metrics_collected: {
     LogicalDisk: {
       measurement: [
         {name: "% Free Space", unit: "Percent"},
         {name: "Free Megabytes", unit: "Megabytes"},
       ],
       "resources": [
         "*"
       ]
     },
     Memory: {
       metrics_collection_interval: 60,
       measurement: [
         {"name": "% Committed Bytes in Use", "unit": "Percent"},
       ],
       "resources": [
         "*"
       ]
     }
   }
 }
};
// Stringify the JSON
const configJson = JSON.stringify(cwAgentConfig);

In the above example configuration we specify that the CloudWatch Agent needs to collect metrics every 60 seconds. If you gather more than just metrics you can also specify collection intervals per section (metrics, logs, traces).

For clarity the namespace is explicitly set to CWAgent , but if you omit the namespace all metrics will be stored in the CWAgent namespace by default. You can of course set your own custom namespace.

For each collected metric an additional dimension is added for the InstanceId. When collecting metrics for EC2 instances you can also think of other dimensions like InstanceType, AutoScalingGroupName or ImageId which would reflect in the JSON as:

"append_dimensions": {
 "InstanceId": "${aws:InstanceId}",
 "InstanceType": "${aws:InstanceType}",
 "AutoScalingGroupName": "${aws:AutoScalingGroupName}"
}

Looking at the metrics metrics_collected section you can see we want to collect metrics for the Windows Performance object LogicalDisk and Memory. If you’re doing this for the first time you might wonder what other performance objects and metrics are available. You can see the performance objects by running the following command on your Windows instance.

Powershell:

Get-Counter -ListSet *

Command-line:

TypePerf.exe –q

Running one of the above command will return quite a list of performance objects and corresponding metrics. You can expect to see all kinds of different objects. From SQL Server to Windows Events.

Now let’s take a closer look at the measurement section in which the metrics are defined that we want to store. For each metrics you can explicitly specify a metric name and unit the metric needs to be stored as (Percentage, MegaBytes. etc). If you leave out the unit type the agent will try to pick the right one.

Due note that all metrics collected with the CloudWatch agent are considered custom metrics and are billed separately. A custom metric costs about $0.30 per metric per month (depending on your region), so costs can add up quickly.

Storing the configuration in Systems Manager Parameter store

While implementing this I ran into all kinds of issues with the JSON format of the configuration file. Creating the JSON file in typescript, passing it to Powershell, writing it to disk, and reading the file took me multiple attempts to get right. An easier approach is to store the JSON configuration in Systems Manager Parameter Store and just pass the parameter when configuring the agent.

const cwAgentConfigParam = new StringParameter(this, 'cw-agent-config', {
 parameterName: '/ec2/cw-agent-config.json',
 stringValue: configJson
});

For the instance to be able to fetch the parameter we will need to make sure we set the proper IAM permissions for the instance role. Let’s create a new IAM role and add the required permissions.

const role = new Role(this, "instance-role", {
 assumedBy: new ServicePrincipal("ec2.amazonaws.com")
});

// required for the CloudWatch agent to send data to cloudwatch
role.addManagedPolicy(ManagedPolicy.fromAwsManagedPolicyName("CloudWatchAgentServerPolicy"));

// required for SSM to manage the instance
role.addManagedPolicy(ManagedPolicy.fromAwsManagedPolicyName("AmazonSSMManagedInstanceCore"));

// Don't forget to add the permissions to read the agent configuration parameter
cwAgentConfigParam.grantRead(role);

Now that we’ve configured IAM and stored our agent configuration, let’s create a Windows EC2 instance to attach and monitor.

Creating a Windows Server EC2 instance

When creating a Windows instance in AWS CDK you will need to place the instance in one of the subnets of your VPC. Pick a specific Windows AMI like Windows Server 2022 and make sure to reference our IAM instance role, otherwise a default role is created without the proper permissions.

// Create a Windows based EC2 instance
const instance = new Instance(this, "windows-demo-instance", {
  vpc: demoVpc,
  instanceType: InstanceType.of(InstanceClass.BURSTABLE3, InstanceSize.SMALL),
  machineImage: MachineImage.latestWindows(WindowsVersion.WINDOWS_SERVER_2022_ENGLISH_FULL_BASE),
  securityGroup: securityGroup,
  role: role,
  keyPair: keyPair,
  associatePublicIpAddress: false,
  vpcSubnets: {subnetType: SubnetType.PRIVATE_WITH_EGRESS},
  detailedMonitoring: true,
})

securityGroup.addIngressRule(Peer.anyIpv4(), Port.tcp(3389), "Allow RDP Connections")

Make sure to allow remote desktop access if you want to connect with remote desktop. I usually use the Systems manager Fleet manager to connect with Remote Desktop. Keep in mind that Amazon provided Windows AMI’s have the Systems Manager Agent installed. If you use your own AMI you will need to make sure you install the Systems Manager agent yourself.

Installing the CloudWatch Agent on deployment

As mentioned before in this post we will install the CloudWatch Agent, required for gathering our metrics, during the instance deployment by means of instance userdata. The latest version of the CloudWatch Agent is published by Amazon into an S3 bucket so all we need to do is request it and run the installer.

When starting the agent make sure you reference the configuration based on its SSM parameter name. We do so by specifying the ssm: prefix/protocol. The CloudWatch Agent, if given the permissions to fetch the parameter, will read the parameter from parameter store during startup

// Write config to disk and install agent
instance.userData.addCommands(
 // Install CW Agent via MSI
 `powershell.exe -Command "Invoke-WebRequest https://s3.amazonaws.com/amazoncloudwatch-agent/windows/amd64/latest/amazon-cloudwatch-agent.msi -OutFile C:\cwagent.msi"`,
 `msiexec /i C:\cwagent.msi /qn /l*v C:\cwagent-install.log`,
 // Wait for installation to complete
 `timeout /t 30`,
 // Start the agent with proper PowerShell execution
 `powershell.exe -ExecutionPolicy Bypass -Command "& 'C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1' -a fetch-config -m ec2 -c ssm:${cwAgentConfigParam.parameterName} -s"`,
 // Wait for agent to start and load
 `timeout /t 30`,
 // check agent status
 `powershell.exe -ExecutionPolicy Bypass -Command "& 'C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1' -a status -m ec2"`,
);

Once the deployment is finished you should be able to see more metrics in the monitoring tab for the EC2 instance. By default it will check if there are metrics within the CWAgent namespace and if so add them to the monitoring screen.

If the agent doesn’t publish your custom metrics, login with remote desktop and check the CloudWatch Agent log file C:\ProgramData\Amazon\AmazonCloudWatchAgent\Logs\amazon-cloudwatch-agent.log for errors. If the file is not there it might be the case the CloudWatch Agent isn’t running, so you will need to troubleshoot that first.

Creating CloudWatch Alarms for proactive monitoring

Adding metrics is great for trend analysis, but really also want to have some alarms in place. Let’s look at the scenario in case the disk is running out of space. Let’s create an alarm for the “LogicalDisk % Free Space” metric.

// Low diskspace alarm for C drive
let lowDiskSpaceCVolumeAlarm = new Alarm(this, 'alarm', {
 alarmDescription: 'This metric monitors the amount of free disk space on the instance. If the amount of free disk space falls below 10% for 5 minutes, the alarm will trigger',
 metric: new Metric({
   dimensionsMap: {
     InstanceId: instance.instanceId,
     objectname: "LogicalDisk",
     instance: "C:"
   },
   statistic: "Average",
   namespace: "CWAgent",
   metricName: "LogicalDisk % Free Space",
   unit: Unit.PERCENT,
 }),
 threshold: 10,
 evaluationPeriods: 5,
 datapointsToAlarm: 5,
 comparisonOperator: ComparisonOperator.LESS_THAN_OR_EQUAL_TO_THRESHOLD,
 treatMissingData: TreatMissingData.MISSING,
});

lowDiskSpaceCVolumeAlarm.addAlarmAction(new SnsAction(topic));
lowDiskSpaceCVolumeAlarm.addOkAction(new SnsAction(topic));

This should result in an alarm that’s monitoring the amount of free disk space for the C: drive of our windows instance.

Now that the alarm is in place, CloudWatch will notify the subscribers of the SNS topic in case the alarm state is trigged.

Summary

In this post, we explored how to create metrics and alarms for Windows based EC2 instances by leveraging the CloudWatch Agent and CloudWatch alarms. We’ve used AWS CDK for provisioning the infrastructure. Along the way, we covered some important topics like:

CloudWatch agent configuration
Windows Performance objects and metrics.
CloudWatch alarms for custom metrics

With these pieces in place, you’ll have a setup that alerts your team when your windows metrics exceed their threshold. Next, you could extend this setup with other instance metrics, application-level metrics and log collection.

A fully working CDK application with the code mentioned in this blogpost can be found in the following GitHub repo.

Enabling AWS Budget Notifications with SNS using AWS CDK

Jeroen Reijn — Mon, 25 Aug 2025 17:28:14 +0000

Keeping track of AWS spend is very important. Especially since it’s so easy to create resources. You might forget to turn off an EC2 instance or container you started, or remove a CDK stack for a specific experiment. Costs can creep up fast if you don’t put guardrails in place.

Recently, I had to set up budgets across multiple AWS accounts for my team. Along the way, I learned a few gotchas (especially around SNS and KMS policies) that weren’t immediately clear to me as I started out writing AWS CDK code. In this post, we’ll go through how to:

Create AWS Budgets with AWS CDK
Send notifications via email and SNS
Handle cases like encrypted topics and configuring resource policies

If you’re setting up AWS Budgets for the first time, I hope this post will save you some trial and error.

What are AWS Budgets?

AWS Budgets is part of AWS Billing and Cost Management. It lets you set guardrails for spend and usage limits. You can define a budget around cost, usage, or even commitment plans (like Reserved Instances and Savings Plans) and trigger alerts when you cross a threshold. You can think of Budgets as your planned spend tracker. Budgets are great for:

Alerting when costs hit predefined thresholds (e.g., 80% of your budgeted spend)
Driving team accountability by tying alerts to product or account owners
Enforcing a cap on monthly spend triggering an action and shutting down compute (EC2), if you go over budget (be careful with this)

Keep in mind that budgets and their notifications are not instant. AWS billing data is processed multiple times a day, but you might trigger your budget a couple of hours after you’ve passed your threshold. This is clearly stated in the AWS documentation as:

AWS billing data, which Budgets uses to monitor resources, is updated at least once per day. Keep in mind that budget information and associated alerts are updated and sent according to this data refresh cadence.

Defining Budgets with AWS CDK

You can create different kinds of budgets, depending on your requirements. Some examples are:

Fixed budgets : Set one amount to monitor every budget period.
Planned budgets : Set different amounts to monitor each budget period.
Auto-adjusting budgets : Set a budget amount to be adjusted automatically based on the spending pattern over a time range that you specify.

We’ll start with a simple example of how you can create a budget in the CDK. We’ll go for a fixed budget of about $100. The AWS CDK currently only has Level 1 constructs available for budgets, which means that the classes in the CDK are a 1 to 1 mapping to the CloudFormation resources. Because of this you will have to explicitly define all required properties (constructs, IAM policies, resource policies, etc), which otherwise could be taken care of by a CDK L2 construct. It also means your CDK code will be a bit more verbose. We’ll start by using the CfnBudget construct.

new cdk.aws_budgets.CfnBudget(this, 'fixed-monthly-cost-budget', {
 budget: {
     budgetType: 'COST',
     budgetLimit: {amount: 100, unit: 'USD'},
     budgetName: 'Monthly Costs Budget',
     timeUnit: 'MONTHLY'
 }
}

In the above example we’ve created a budget with a limit of $100 per month. A budget alone isn’t very useful. You’d still have to check into the AWS console manually to see what your spend is compared to your budget. The important thing is that we want to get notified in case we reach our budget or our forecasted budget will reach our threshold, so let’s add a notification and a subscriber.

new cdk.aws_budgets.CfnBudget(this, 'fixed-monthly-cost-budget', {
 budget: {
   budgetType: 'COST',
   budgetLimit: {amount: 100, unit: 'USD'},
   budgetName: 'Monthly Costs Budget',
   timeUnit: 'MONTHLY'
 },
 notificationsWithSubscribers: [{
   notification: {
     comparisonOperator: 'GREATER_THAN',
     notificationType: 'FORECASTED',
     threshold: 100,
     thresholdType: 'PERCENTAGE'
   },
   subscribers: [{
     subscriptionType: 'EMAIL',
     address: '<your-email-address>'
   }]
 }]
});

Based on the notification settings, interested parties are notified when the spend is forecasted to exceed 100% of our defined budget limit. You can put a notification on forecasted or actual percentages. When that happens an email is send to the designated email address. Subscribers, at the time of writing, can be either email recipients or a Simple Notification Service (SNS) topic. In the above code example we use email subscribers for which you can add up to 10 recipients.

Depending on your team or organization it might be beneficial to switch to using an SNS topic. The advantage of using an SNS topic over a set of email subscribers is that you can add different kind of subscribers (email, chat, custom lambda functions) to your SNS topic. With an SNS topic you have a single place to configure subscribers and if you change your mind you can do so in one place instead of updating all budgets. Using an SNS Topic also allows you to push budget notifications to for instance a chat client like MS Teams or Slack.

In this case we wil make use of SNS in combination with email subscribers. Let’s start by defining an SNS topic with the AWS CDK.

// Create a topic for email notifications
let topic = new Topic(this, 'budget-notifications-topic', {
 topicName: 'budget-notifications-topic'
});

Now let’s add an email subscriber, as this is the most simple way to receive budget notifications.

// Add email subscription
topic.addSubscription( new EmailSubscription("your-email-address"));

This looks pretty straight forward and you might think you’re done, but there is one important step to take next, which I initially forgot. The AWS budgets service will need to be granted permissions to publish messages to the topic. To be able to do this, we will need to add a resource policy to the topic which allows the budgets service to call the SNS:Publish action for our topic.

// Add resource policy to allow the budgets service to publish to the SNS topic
topic.addToResourcePolicy(new PolicyStatement({
  actions:["SNS:Publish"],
  effect: Effect.ALLOW,
  principals: [new ServicePrincipal("budgets.amazonaws.com")],
  resources: [topic.topicArn],
  conditions: {
    ArnEquals: {
     'aws:SourceArn': `arn:aws:budgets::${Stack.of(this).account}:*`,
    },
    StringEquals: {
      'aws:SourceAccount': Stack.of(this).account,
    },
  },
}))

Now let’s assign the SNS topic as a subscriber in our CDK code.

// Define a fixed budget with SNS as subscriber
new cdk.aws_budgets.CfnBudget(this, 'fixed-monthly-cost-budget', {
 budget: {
   budgetType: 'COST',
   budgetLimit: {amount: 100, unit: 'USD'},
   budgetName: 'Monthly Costs Budget',
   timeUnit: 'MONTHLY'
 },
 notificationsWithSubscribers: [{
   notification: {
     comparisonOperator: 'GREATER_THAN',
     notificationType: 'FORECASTED',
     threshold: 100,
     thresholdType: 'PERCENTAGE'
   },
   subscribers: [{
     subscriptionType: 'SNS',
     address: topic.topicArn
   }]
 }]
});

Working with Encrypted Topics

If you have an SNS topic with encryption enabled (via KMS) you will need to make sure that the corresponding service has access to the KMS key. If you don’t, you will not get any messages and as far as I could tell you will see no errors (at least I could find none in CloudTrail). I actually wasted a couple of hours trying to figure this part out.

I should have read the documentation as it is explicitly stated to do so. I guess I should start with the docs instead of diving right into the AWS CDK code.

// Create KMS key used for encryption
let key = new Key(this,'sns-kms-key', {
  alias: 'sns-kms-key',
  enabled: true,
  description: 'Key used for SNS topic encryption'
});

// Create topic and assign the KMS key
let topic = new Topic(this, 'budget-notifications-topic', {
  topicName: 'budget-notifications-topic',
  masterKey: key
});

Now let’s add the resource policy to the key and try to trim down the permissions as much as possible.

// Allow access from budgets service
key.addToResourcePolicy(new PolicyStatement({
  effect: Effect.ALLOW,
  actions: ["kms:GenerateDataKey*","kms:Decrypt"],
  principals: [new ServicePrincipal("budgets.amazonaws.com")],
  resources: ["*"],
  conditions: {
    StringEquals: {
     'aws:SourceAccount': Stack.of(this).account,
    },
    ArnLike: {
      "aws:SourceArn": "arn:aws:budgets::" + Stack.of(this).account +":*"
    }
  }
}));

Putting it all together

If you’ve configured everything correctly and deployed your stack to your target account you should be good to go. Once you cross your threshold you should be notified by email that your budget is exceeding one of your thresholds (depending on the threshold set).

Summary

In this post, we explored how to create AWS Budgets with AWS CDK and send notifications through email or SNS. Along the way, we covered some important topics like:

Budgets alone aren’t useful until you add notifications.
SNS topics need a resource policy so the Budgets service can publish.
Encrypted topics require KMS permissions for the Budgets service.

With these pieces in place, you’ll have a setup that alerts your team when costs exceed thresholds via email, chat, or custom integrations.

A fully working CDK application with the code mentioned in this blogpost can be found in the following GitHub repo.

Photo by Towfiqu barbhuiya on Unsplash

Multi-account DNS with AWS CDK

Jeroen Reijn — Mon, 10 Feb 2025 15:18:28 +0000

I was recently tasked with setting up DNS within an AWS organization structure. The idea was to use a single domain structure that would be able to support multiple environments (development, acceptance and production). In my actual use case it was a bit more complex, but in this post I'll keep it simple and show some example code how you can implement the solution with AWS CDK.

Setting the stage

In this post, we'll look at setting up multi-account DNS for our AWS accounts. It starts with having a central (network) account that owns the DNS for the root domain. ( exampledomain.com ). To let teams create their applications, manage their subdomains, and request SSL certificates from ACM (AWS Certificate Manager), we wanted to let them own and manage the subdomain for a specific environment. In essence, we would have 4 AWS accounts with their own DNS management.

Creating and Managing Hosted Zones

Implementing DNS in AWS is handled by the Amazon Route 53 service. To implement DNS in Route 53 we need to use a Route 53 hosted zone. A hosted zone is a container within Route 53 where you store and manage the DNS records for a specific domain or subdomain. There are two types of hosted zones:

Public Hosted Zone : Used to manage the DNS records for a domain or subdomain that is publicly accessible on the internet. Example: A website like exampledomain.com.
Private Hosted Zone : Used to manage DNS records for a domain within a Virtual Private Cloud (VPC). Example: Internal services accessed only within a private network, like internaldomain.com.

In our case, we want to create a public hosted zone for our top-level domain. To do that with AWS CDK you can use the PublicHostedZone construct.

const parentHostedZone = new PublicHostedZone(this, 
  'parent-hosted-zone', { zoneName: 'exampledomain.com',}
);

The above code should be part of the stack deployed to the central (networking) account. Now lets look at what is being created when we created our public hosted zone.

Types of DNS records in Route53

When you create a public hosted zone, you will by default get two DNS records as part of the hosted zone.

The hosted zone will contain both a NS record as well as a SOA record, but what do these records mean?

NS record - NS stands for 'nameserver,' and the nameserver record indicates which DNS server is authoritative for that domain (i.e. which server contains the actual DNS records). NS records tell the Internet where to go to find out a domain's IP address.
SOA record - The DNS start of authority (SOA) record stores important information about a domain or zone such as the email address of the administrator, when the domain was last updated, and how long the server should wait between refreshes.

To tell the client (for instance a web browser) where to resolve the subdomain, we can explicitly define in route53 that the authoritative domain servers for the subdomain are located elsewhere by adding an explicit NS record to the hosted zone of the root/parent domain.

Connecting the hosted zone in the central account with the hosted zone in the child account

To manage the DNS for the subdomain in the environment-specific account, we will need to also create a route 53 hosted zone in the environment specific (dev, staging, prod) account. Our next would be to specify that the environment specific account is responsible for the sub-domain we will need to explicitly state the relationship in the Route53 hosted zone of the central account.

The following table shows an example of how to define the authoritative NS servers for the subdomain dev.exampledomain.com. In the example we show a single value for the NS server, but when working with route53 you will always have four DNS servers.

Now, when a client tries to resolve the DNS for dev.exampledomain.com , it will first try to find the NS servers for .com , after which it will try to resolve exampledomain.com, followed by resolving the dev.exampledomain.com before reaching the correct authoritative domain servers. Adding an additional NS server will cause one additional hop before it can resolve the DNS, so keep that in mind when implementing this solution.

We could create the NS record(s) for the dev or staging account in the public-hosted zones of the central account via the AWS console, but ideally, you would want to automate the entire process.

Implementing Sub-zone DNS delegation

As mentioned before we wanted teams to be able to manage sub-domain records for their accounts. This would allow them to create applicationname.dev.exampledomain.com. Having control over the DNS for the subdomain within the corresponding account will make it easy for them to create specific domain names for applications, or create DNS-validated HTTPS certificates (big plus for automation compared to email-validated certificates). To be able to do so in AWS CDK the easiest way is to create an IAM role that the Dev account can assume when trying to insert/update the NS records for its subdomain in the hosted zone of the parent domain.

To create such a role in the central account you can choose to do this by using an organization(al unit) id or by using an account id. Lets take a look at some examples.

const role = new Role(this, 'ParentZoneOrganizationRole', { 
    assumedBy: new OrganizationPrincipal('o-xxxxxxx'),
    roleName: 'HostedZoneDelegationRole',
});

In the above example, we specify that any account being part of a specific organization or organizational unit can assume the role to perform the changes on the hosted zone. However, if you want to be specific you can also opt for creating a specific role per account that is allowed to perform this kind of changes.

const role = new Role(this, 'ParentZoneAccountRole', {
  assumedBy: new AccountPrincipal('123456789'), 
  roleName: 'dev-HostedZoneDelegationRole',
});

For the role name in this example Ive used the prefix part of the subdomain, but you can of course also use the AWS account id or something that shows for which subdomain the role is meant. To allow the role to change the hosted zone in the networking account a grant can be given by means of the grantDelegation method on the HostedZone construct.

parentHostedZone.grantDelegation(role);

This will add the permissions to add or change records of type NS in the parent hosted zone. However, when inspecting policies I found that the IAM permissions were a bit too permissive for my liking. The following code snippet is taken from the AWS CDK v2 source code (at Feb 5th 2024):

export function makeGrantDelegation(grantee: iam.IGrantable, hostedZoneArn: string): iam.Grant { 

  const g1 = iam.Grant.addToPrincipal({ grantee, 
      actions: ['route53:ChangeResourceRecordSets'],
      resourceArns: [hostedZoneArn], conditions: { 
        'ForAllValues:StringEquals': {
            'route53:ChangeResourceRecordSetsRecordTypes': ['NS'], 
            'route53:ChangeResourceRecordSetsActions': ['UPSERT', 'DELETE'], 
        }, 
      }, 
  }); 

  const g2 = iam.Grant.addToPrincipal({ grantee, 
    actions: ['route53:ListHostedZonesByName'], 
    resourceArns: ['*'], 
  }); 

  return g1.combine(g2);
}

As you can see the role allows all accounts (when used with an OrganizationPrincipal) to assume the role and allows these accounts to update NS records in the parent hosted zone without any strict validation on the subdomain (it does for record type). In my case, I want to limit that to a specific subdomain so that only the dev account can change the NS records in the parent zone for the dev.exampledomain.com subdomain and not for instance change the NS records for the prod.exampledomain.com subdomain. So how can we achieve this?

Limiting the delegation scope

To prevent this, a custom IAM policy needs to be created for the role that limits the scope to a specific subdomain.

// Validate this can only happen for the dev.exampledomain.com sub-domain

const conditions = { 
  'ForAllValues:StringEquals': {
    'route53:ChangeResourceRecordSetsRecordTypes': ['NS'],
    'route53:ChangeResourceRecordSetsActions': ['UPSERT','DELETE'],
    'route53:ChangeResourceRecordSetsNormalizedRecordNames': ['dev.exampledomain.com'] 
  } 
}; 
// Allow the role to perform the GetHostedZone and ChangeResourceRecordSets methods on the recordset for the subdomain. 

const recordSetPolicyStatement = new iam.PolicyStatement({
  actions: ["route53:GetHostedZone", "route53:ChangeResourceRecordSets"], 
  resources: [parentDomainHostedZone.hostedZoneArn], 
  conditions: conditions 
}); 

// Allow the role to list hosted zones by name 
const zoneListingPolicyStatement = new iam.PolicyStatement({  
  actions: ["route53:ListHostedZonesByName"], 
  resources: ["*"] 
}); 

const policyDocument = new iam.PolicyDocument({ 
  statements: [recordSetPolicyStatement, zoneListingPolicyStatement] 
});

Now that we've set up our policy all we need to do is assign that the IAM role.

// Set explicit inline policies for the 
const role = new Role(this, 'ParentZoneAccountRole', {
  assumedBy: new AccountPrincipal('123456789'), 
  roleName: 'dev-HostedZoneDelegationRole', 
  inlinePolicies: { 
    delegation: policyDocument 
  }
});

That it for the work we need to do in the central account. Now lets move on to what we need to do in the sub account.

DNS in the sub-account

In the sub accounts (dev, staging, prod) we will need to create a public hosted zone so we can manage subdomains for the applications living in the accounts.

const subDomainHostedZone = new PublicHostedZone(this, 'subDomainHostedZone', { 
  zoneName: 'dev.exampledomain.com'
});

Now that we've created the hosted zone we want to publish the NS record information into the central hosted zone, so we can perform the NS record delegation.

// construct the ARN for our cross account role 
const delegationRoleArn = Stack.of(this).formatArn({ 
  account: rootAccountId, 
  region: '', 
  resource: 'role', 
  resourceName: 'dev-HostedZoneDelegationRole', 
  service: 'iam', 
}); 
// Get the role by ARN 
const delegationRole = Role.fromRoleArn(this, 'DelegationRole', delegationRoleArn); 
// create a cross account hosted zone delegation record (NS) 

new CrossAccountZoneDelegationRecord(this, 'DelegationRecord', { 
  delegationRole, 
  subDomainHostedZone, 
  parentHostedZoneName: 'exampledomain.com' 
});

The CrossAccountZoneDelegationRecord is a CloudFormation CustomResource that will create assume the role and create the NS records in the hosted zone of the central account based on the NS servers of the hosted zone for the subdomain.

Now that we have the hosted zone in place for the sub-account it should be a matter of some simple lines of CDK code for generating DNS records and certificates for applications.

const certificate = new Certificate(this, 'appSubDomainHostedZoneCert', { 
  domainName: `applicationname.dev.exampledomain.com`,
  validation: CertificateValidation.fromDns(subDomainHostedZone),
});

Summary

Implementing DNS management in a multi-account setup can be a bit challenging at first if youve never done this before. Using of AWS CDK you can add the required constructs that will allow you to perform sub-zone delegation. Limiting down the scope of what the cross-account role can do takes a bit more effort. While writing this post I learned there is an open issue for implementing a similar behaviour for permission limitation registered in the AWS CDK project https://github.com/aws/aws-cdk/issues/28078. Lets hope it becomes part of the CDK, so it will save us some time.

AWS re:Invent 2024 Day 4

Jeroen Reijn — Mon, 09 Dec 2024 19:04:22 +0000

Thursday, the day of the highly anticipated Dr. Werner Vogels keynote. On Wednesday I already heard about the fact that you would probably have to be in the queue around 6.30-7.00 am to be able to get into the keynote room. Because I did not sleep very well over the last couple of days I decided to take a bit of time in the morning to have breakfast in the Caesars Palace and watch the keynote from my hotel room before heading out for my first session of the day.

Dr. Werner Vogels keynote

In his keynote Dr. Werner Vogels focussed on the concept of simplicity vs complexity.

Building systems requires constant thought and with the ongoing demand from businesses, systems are always changing. Over time you need to be aware of the growing complexity of the system(s) at hand. He highlighted some great examples i’ve seen in real-life:

Declining feature velocity
Time consuming debugging
Frequent escalation

The push for simplicity is important and he shared the lessons learned at Amazon.

Evolvability as a Requirement
Break Complexity into Pieces
Align Teams with Architecture
Organize into Cells
Automate Complexity
Design Predictable Systems

He continued his story with principles required to build evolvable systems. In his talk there are great examples of evolving systems like S3 and CloudWatch over time. There are many lessons to learn from this keynote as an engineer/architect/CTO, so if you havent seen it yet, I highly recommend watching it on Youtube.

During the keynote there were two great customer stories by Canva and Too Good To Go (TGTG). Both shared an incredible story about the growth they had and how their systems and architecture design needed to adapt. It was nice to hear the story from TGTG about their migration from PHP to Java with Spring Framework to achieve clear boundaries and more performance by o.a. the great off the shelf features of Spring, transactions, connection pooling, etc. The story was a good step up to Aurora DSQL as TGTG wanted to scale globally into different regions where they for now had to duplicate their architecture.

Werner continued with a deep dive on why they created Aurora DSQL (Distributed SQL) and how it can solve some of the challenges TGTG was facing during their growth phase.

Is your Serverless application ready for production? (SVS313)

In this chalk talk by Mark Sailes and Thomas Moore we looked at three different serverless architectures and evaluated the production readiness against 5 pillars of the Well Architected Framework. This was a really good session with lots of interaction with the audience. It was also great to finally meet Mark in person, after having multiple conversation on Twitter.

Optimize Amazon DynamoDB performance using AWS SDK for Java 2.x (DAT414)

For the final session of the day I went back to the Wynn for a code talk by Arjan Schaaf and Michael Shao. This session dived deep into using the Java SDK when using DynamoDB. We looked at several different factors like:

synchronous versus asynchronous clients
client initialisation
different http clients like Apache http, aws-crt and url-connection client
pre-initialisation of the data model
client side and server side metrics

This code talk showed some really nice and example and Arjan showed different steps with their impact on latency. Even though there are some sessions on Friday morning, this was my final re:invent session as on Friday we would be going home.

re:Play

Thursdays at re:invent end with a party at the Las Vegas festival grounds. After a busy week with connecting and learning it was time for some relaxation. There was so much to do like roller disco, great food, drinks and some great headline artists like Weezer and Zedd.

The party was great! I’m a big fan or EDM, so I really enjoyed Zedds performance!

AWS re:Invent 2024 Day 3

Jeroen Reijn — Mon, 09 Dec 2024 16:30:00 +0000

Day 2 ended with a great global AWS Community Builder mixer. On day 3 of re:invent I had to skip the opening keynote by Dr. Swami Sivasubramanian VP AI & Data, because I planned to start the day with “DAT404: Advanced data modelling with Amazon DynamoDB” by Alex DeBrie. Alex is a great speaker and author of the DynamoDB book, so I really wanted to attend this session in person. When I arrived at the session I quickly learned I wasn’t the only one skipping the keynote. The queue went around the corner, but luckily I had reserved a seat so I did not have to get into the Walk-up line.

Advanced data modelling with Amazon DynamoDB

Alex discussed a lot of different concerns when working with DynamoDB:

Data modelling basics (collections, denormalization, LSIs, GSIs)
DynamoDB + napkin math (always validate what working with DynamoDB will costs you)
DynamoDB Stream and how you can disconnect applications from having too many responsibilities like writhing to both DynamoDB and SQS as the same time.

Again I learned quite a few interesting lessons, so that talk was definitely worth it.

After the session I went to the AWS Community Hub to meet some fellow builders, watch the replay of the keynote, and finish my day 2 post. The Community Hub was located inside the Venetian shopping area which is a crazy place if you’ve never been to Vegas before. It contains some elements of actual Venice like a canal with gondola’s, palazzo’s, etc.

AI and Data keynote by Dr. Swami Sivasubramanian

The keynote showed some interesting new releases:

Amazon Bedrock:
- Bedrock Marketplace - provides generative AI developers access to over 100 publicly available and proprietary foundation models (FMs)
- Text-to-image models from Stability AI are added
- Generating high-quality video clips from text and images with the models from Luma AI are added to Bedrock
- Poolside's Assistant is added to Bedrock powered by its malibu and point models
- Prompt caching for supported models. Caches frequently used prompts across multiple API calls
- Prompt Routing - Uses prompt matching and model understanding techniques, Intelligent Prompt Routing predicts the performance of each model for each request and dynamically routes each request to the model that it predicts is most likely to give the desired response at the lowest cost
- Bedrock Knowledge Bases offers an end-to-end managed workflow for customers to build custom generative AI applications that can access and incorporate contextual information from a variety of structured and unstructured data sources
- Bedrock Knowledge Bases now supports GraphRAG, providing more accurate and comprehensive responses to end users by using RAG techniques combined with graphs.
- Bedrock Data Automation enables developers to automate the generation of valuable insights from unstructured multimodal content such as documents, images, video, and audio to build GenAI-based applications.
- Bedrock Guardrails Multimodel toxicity detection - enabling the detection and filtration of undesirable and potentially harmful image content while retaining safe and relevant visuals.
Amazon Q:
- Q Developer is now available in SageMaker Canvas
- Is now available in Quicksight Scenarios

Before heading out of to my next session, which was in the furthest away location, I decided to walk the expo a bit. The expo hall is HUGE with so many vendors promoting their products. It was great meeting many different vendors and catching up with great projects like LocalStack and Elastic, which I’ve used over the years.

Deep dive intro Amazon Aurora DSQL and it’s architecture

After the EXPO I took the transit to the Mandalay Bay convention center to attend Marc Brooker’s deep dive session on the architecture behind Aurora DSQL, the new serverless database introduced by AWS.

This was a very interesting break-out session (recording should be up soon) about the challenges of designing and running a distributed database. It was interesting to hear how they split of a traditional monolithic database into separate services with their own responsibilities. Marc has a series of blogs posts about DSQL, which I highly recommend reading if you’re interested in DSQL.

EMEA networking reception

The day ended with returning back to the Venetian before heading out to the Wynn for the EMEA networking reception in the XS night club. Finding your way around these hotels and convention centers can be a bit of a challenge, especially when it’s your first time. When I finally found the night club it was quite busy, as to be expected for a conference with about 60.000 people, and I enjoyed a nice evening with great food and nice music.

AWS re:Invent 2024 Day 2

Jeroen Reijn — Wed, 04 Dec 2024 20:00:44 +0000

Today was the second day of re:invent and the day was packed with exciting events. These days are full of sessions, social events and casual conversations at the Expo, Community Hub or just in line while waiting to get into a room.

The CEO keynote with Matt Garman

In the morning I kicked off the day with the keynote by AWS CEO Matt Garman. I quickly learned that walking up 30 minutes before isn't enough to get into the room. Who would have guessed right with 60.000 people attending re:invent. Luckily there are many overflow rooms available 😅 I thought Matt was killing it 🔥 during the keynote. He introduced some great new announcements and as expected the keynote contained quite some new innovations around Generative AI. However, I thought it was well positioned by talking about the use case and customer requests. It didn't feel like GenAI "because of GenAI" like last year.

There are definitely some announcements I want to explore further over the next period. Some of the highlights for me were:

The improvements for Amazon Q (unit test, documentation, code reviews, integration with GitLab Duo and transformations for .Net, VMWare and Mainframe).
The introduction of Amazon Aurora DSQL
The introduction of Amazon SageMaker Unified Studio
The introduction of Amazons own foundational models: Nova

If you want to see all announcements from re:invent don't forget to keep your eye on the top re:invents announcements blog.

Supercharge your Lambda functions with Lambda Powertools 🚀

Just after the keynote I attended the Dev session by Raphael Manke on Lambda Power Tools. Raphael gave one heck of a demo and showed how Lambda power tools can supercharge your lambda functions and help improve observability, idempotency, batch handling and much more.

The EMEA Community Builders Mixer

Next up was a EMEA community mixer in the Buddy V restaurant. It was great meeting many EMEA based Community Builders. I got to meet Lee Gilmore there who has an excellent newsletter called "Serverless Advocate" (be sure to check it out at). These mixer events are great for getting to know people and learn about what other community members are doing.

Mitigating noisy neighbour issues for multi-tenant SQS queues

After the mixer I headed to the MGM Grand together with Pubudu Jayawardana to attend a chalk talk about mitigating the noisy neighbours problem when having multi-tenant SQS queues.

They showed the following strategies:

Having a single queue per tenant
Separate queues for noisy neighbours
Sharding to different queues (for instance with a hash function)
Shuffle sharding
Dynamic overflow queues
Using SNS Topics and queues and downstream sources

It was my first chalk talk and I'm definitely going to attend more of these as I really liked the open format and white boarding with AWS specialists.

The Global AWS Community Builder mixer

After a quick workshop session on solving Idempotency issues in distributed systems it was time to head back for a Community Builders mixer with all community builders present at the AWS summit. It was great meeting Ayman Metwally, Jacob Verhoeks , Ivan Casco Valero, Rob Van Pamel, Fernando Paz, Jocelyn Poblete, Michael Liendo, Matt Bacchi, Arijita Mitra and Paloma Lataliza.

Jeff Bar was present and handed out some unique Builder Cards. For those of you who dont know, Jeff started the AWS blog about 20 years ago. It was also great to meet the people that bring this community together Jason Dunn, 🌤 Farrah Campbell and Thembile Martis!

Day two was another great day. The jetlag and long days are starting to wear on me a bit, but Im looking forward to day 3!

AWS re:Invent 2024 Day 1

Jeroen Reijn — Wed, 04 Dec 2024 06:35:29 +0000

Day 1 of AWS re:Invent just ended and I'm now writing this update while watching the replay of Monday Nights keynote with Peter DeSantis. I couldn't attend the keynote due to a customer survey session, but I always enjoy the balance of in depth knowledge on the latest development in compute.

Today was mixed with sessions and social events. For the sessions I tried to focus on non-breakout session and attended a couple of code talks which was great. Code talks focus on particular topics while diving into (example) code and are not recorded (most of the breakout sessions are) so you cant watch them after the conference. To not stick to what I know I explored some unfamiliar topics as well.

Sessions

During the day I attended several sessions which I want to share something about.

STG351 - Automate data protection at scale with AWS Backup

This was a great talk given by Khurram Nizami and Yangsoo(Leo) Park on AWS Backup in a Cross Account and Cross region setup. After applying tag based strategies for backup plans it introduced me to the concept of backup (test) validation. Overall very good session. You can find the git repo for the demo project on Github: https://github.com/aws-samples/backup-recovery-with-aws-backup

COP405 - Coding for account customizations with AWS Control Tower with Welly Siauw and Justin P.

Even though I dont work with AWS Control Tower in combination with the Account Factory for Terraform (AFT), this sessions was quite insightful. It gave me a good idea on the complexity of managing large organizations. You can find the sample repository here https://github.com/aws-samples/aft-workshop-sample.

COP318 - Streamlining incident response with AWS Systems manager with Jean Velez Torres and Raviteja Sunkavalli

Very interesting session which introduced me to Systems Manager Automation for building automated incident response handling. By means of SSM Automation they showed how to could build a workflow similar to AWS Step functions for mitigating failures. They did this all live which was pretty great to see. You can find the code for this session at https://github.com/sunkavar/reInvent2024-COP318

Taking a short break

After this session I took a bit of a breather and went to the AWS Community Hub. The Community Hub is a dedicated spot for AWS Community Builders, AWS Heroes and AWS Community Leaders to take a step back and relax. At the Community Hub I got to meet Johannes Koch, Julian Wood, Ran Isenberg, Raphael Manke and Faye Ellis in person. It's always great to meet people you follow or converse with online.

SVS401 - Best practices for Serverless developers with Ran Isenberg and Julian Wood

This breakout sessions was high on my wish list and looking at the walk-up line just before the session, I wasnt the only one. If youre into serverless or thinking about using serverless this is the session for you! The session was packed with valuable insights and I highly recommend 💯 watching this session when it becomes available (it was recorded) ! It was great watching this talk with Karl Robinson whose podcast I regularly consume on my daily commute.

Reflecting on the day

I ended my day in the Expo hall and it was great to connect with Martijn van Dongen, Pubudu Jayawardana, Carlo Vollebregt and Nova Lailatul Rizkiyah.

While doing some mid night snack shopping on the way to the hotel I ended up having a lovely conversation with Camille Nigon about what it feels like to attend re:invent for the first time. A lot of people had warned me about how massive and impressive it is, but you only know what it feels like when you actually attend.

My Journey with AWS CDK and Java: What You Need to Know

Jeroen Reijn — Mon, 02 Sep 2024 09:25:25 +0000

One of the first decisions you’ll need to make when working with the AWS Cloud Development Kit (CDK) is choosing the language for writing your Infrastructure as Code (IaC). The CDK currently supports TypeScript, JavaScript, Python, Java, C#, and Go. Over the past few years, I’ve worked with the CDK in Typescript, Python and Java. While there is ample information available online for TypeScript and Python, this post aims to share my experience using Java as the language of choice for the AWS CDK.

Wait…. what? Using Java with the AWS CDK?

Some may say that Typescript is the most obvious language to use while working with the AWS CDK. The CDK itself is written in Typescript and it’s also the most used language according to the 2023 CDK Community Survey. Java is coming in 3rd place with a small percentage of use.

Image source https://matthewbonig.com/posts/community-survey-2023/

I do wonder if this still holds true given the number of responses to the survey. I’ve worked with small businesses and large enterprise organizations over the last years, and I see more and more Java oriented teams move their workloads to AWS while adopting AWS CDK as their Infrastructure as Code tool. Depending on the type of service(s) being built by these teams they may or may not have any experience with either Python or Typescript and the NodeJs ecosystem, which makes sticking to Java an easy choice.

General observations

From what I’ve seen, adopting the CDK in Java is relatively easy for most of these teams as they already understand the language and the ecosystem. Integrating the CDK with their existing build tools like Maven and Gradle is well documented, which leaves them with the learning curve of understanding how to work with infrastructure as code, how to structure a CDK project and when to use L1, L2 and L3 constructs.

Compared to Typescript the CDK stacks and constructs written in Java contain a bit more boilerplate code and therefor might feel a bit more bloated if you come from a different language. I personally don’t feel this makes the code less readable and with modern IDE’s and coding assistants I don’t feel I’m less productive.

The CDK also seems to become more widely adopted in the Java community with more recent Java frameworks like Micronaut even having built-in support for AWS CDK in the framework.

See for instance the following Micronaut launch configurations:

One of the advantages of Java is that it’s a statically-typed language, which means it will catch most CDK coding errors during compile-time. There are still some errors which you will only see during an actual cdk synth or cdk deploy. For instance, some constructs have required properties which will only become visible if you try to synthesize the stack, but in my experience, you will have that in other languages as well.

Performance wise it feels like the CDK in Java is a bit slower compared to using it Typescript or any other interpreted language. I’ve not measured this, but it’s more of a gut feeling. This might have to do with the static nature of Java and its corresponding build tools and compile phase. On the other hand it might be that the JSII runtime architecture also has an effect and how Java is interacting with a Javascript environment.

Java Builders

One of the biggest differences when using the AWS CDK with Java is the use of Builders. When creating constructs with Typescript you’re mainly using the props argument (map of configuration properties) while creating a construct. Let’s take a look at an example:

const bucket = new s3.Bucket(this,"MyBucket", {
    versioned: true,
    encryption: BucketEncryption.KMS_MANAGED
})

The Java version of the above snippet uses a Builder class that follows the builder pattern for constructing the properties. If you’re unfamiliar with the Builder pattern in Java I recommend to checkout this blog post about using the Builder pattern. Depending on the CDK construct you might be able to define a CDK resource in two different ways.

In the first example you use the Builder for the Bucket properties.

Bucket bucket = new Bucket(this, "MyBucket", new BucketProps.Builder()
                           .versioned(true)
                           .encryption(BucketEncryption.KMS_MANAGED)
                           .build());

The alternative is that constructs can have their own builder class, which makes it a little less verbose and easier to read.

Bucket bucket = Bucket.Builder
                           .create(this, "MyBucket")
                           .versioned(true)
                           .encryption(BucketEncryption.KMS_MANAGED)
                           .build();

IDE support

Overall IDE support is really great when working with CDK in Java. I use IntelliJ IDEA on a daily basis and auto completion really helps when using the Builder objects.

As the CDK documentation is also inside the CDKs Java source code, looking up documentation is really easy. It’s similar to how you would do it with any kind of other object or library.

Third party construct support

The CDK itself is written in Typescript and for each supported programming language a specific binding is generated. This means that when a new resource or feature for an AWS service is added in the Typescript variant of the CDK it’s also available to developers using a Java based CDK.

Besides the default CDK constructs there are also a lot of community generated constructs. Construct Hub is a great place to find them.

From what I’ve seen most constructs coming out of AWS will support Java as one of the default languages. Community supported constructs however might not. There are several popular constructs that only support Typescript and Python. Filtering on Construct Hub for AWS CDK v2 based constructs, sorted by programming languages results in the following data.

Language	Number of constructs libraries
Typescript	1164
Python	781
.Net	511
Java	455
Go	132

Depending on the type of infrastructure or third-party services you’re planning to use, you might not be able to use all available constructs. For instance, the constructs maintained by DataDog are only available in Typescript, Python and Go. In my personal experience though, most construct developers are open to support Java. Third party constructs are based on projen and jsii, which means that adding a Java based version is most of the time a matter of configuration in the package.json file of the project.

  "jsii": {
    "outdir": "dist",
    "targets": {
      "java": {
        "package": "io.github.cdklabs.cdknag",
        "maven": {
          "groupId": "io.github.cdklabs",
          "artifactId": "cdknag"
        }
      },
      "python": {
        "distName": "cdk-nag",
        "module": "cdk_nag"
      },
      "dotnet": {
        "namespace": "Cdklabs.CdkNag",
        "packageId": "Cdklabs.CdkNag"
      },
      "go": {
        "moduleName": "github.com/cdklabs/cdk-nag-go"
      }
    },
    "tsc": {
      "outDir": "lib",
      "rootDir": "src"
    }
  }

( An example of how JSII is configured for the CDK NAG project )

Once the configuration is in place and the artifacts have been pushed to for instance Maven Central, you’re good to go.

When thinking about it, I once had a 3rd party construct I wanted to use that did not support Java (yet). It got added quite quickly and there was also an alternative solution for it, so I can't remember having issues with the lower number of available constructs.

Examples, tutorials and documentation

I think it’s good to reflect on the fact that there are more CDK examples and tutorials available in Typescript and Python compared to Java. This reflects the findings in the usage chart from the CDK Community Survey. However, reading Typescript as a Java programmer is relatively easy (my personal opinion). If you’re new to the AWS CDK there is a ton of example code available on Github, Youtube, and in numerous blog posts and tutorials. If you’re already using the CDK in combination with Java, be sure to write some blog posts or tutorials, so others can see that and benefit from your knowledge!

Summary

Java is a very viable option when working with the AWS CDK, especially for workload teams already familiar with the language and its ecosystem. IDE support for the CDK is excellent with features like auto-completion and easy access to source code documentation.

All in all, the experience is really good. Keep in mind that picking Java for your infrastructure as code all depends on the context and the environment you’re in. I would suggest picking the language which is most applicable in your specific situation. If you still need to make the choice and are already working with Java, I definitely recommend trying it out!

Analyze and debug Quarkus based AWS Lambda functions with X-Ray

Jeroen Reijn — Tue, 06 Feb 2024 21:30:00 +0000

Serverless architectures have emerged as a paradigm-shifting approach to building, fast, scalable and cost efficient applications. While Serverless architectures provide unparalleled flexibility, they also introduce new challenges in terms of monitoring and troubleshooting.

In this blog post, we'll explore how Quarkus integrates with AWS X-Ray and how using a Jakarta CDI Interceptor can keep your code clean while adding custom instrumentation.

Quarkus and AWS Lambda

Quarkus is a Java based framework tailored for GraalVM and HotSpot, which results in an amazingly fast boot time while having an incredibly low memory footprint. It offers near instant scale up and high density memory utilization which can be very useful for container orchestration platforms like Kubernetes or Serverless runtimes like AWS Lambda.

Building AWS Lambda Functions can be as easy as starting a Quarkus project, adding the quarkus-amazon-lambda dependency, and defining your AWS Lambda Handler function.

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-amazon-lambda</artifactId>
</dependency>

An extensive guide on how to develop AWS Lambda Functions with Quarkus can be found in the official Quarkus AWS Lambda Guide.

Enabling X-Ray for your Lambda functions

Quarkus provides out of the box support for X-Ray, but you will need to add a dependency to your project and configure some setting to make it work with GraalVM / native compiled Quarkus applications. Let's first start with adding the quarkus-amazon-lambda-xray dependency.

<!-- adds dependency on required x-ray classes and adds support for graalvm native -->
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-amazon-lambda-xray</artifactId>
</dependency>

Don't forget to enable tracing for your Lambda function otherwise it won't work. An example of doing that is by setting the tracing argument to active within your AWS CDK code.

function = Function.Builder.create(this, "feed-parsing-function")
      ...
      .memorySize(512)
      .tracing(Tracing.ACTIVE)
      .runtime(Runtime.PROVIDED_AL2023)
      .logRetention(RetentionDays.ONE_WEEK)
      .build();

After the deployment of your function, and a function invocation, you should be able to see the X-Ray traces from within the Cloudwatch interface. By default it will show you some basic timing information for your function like the initialization and the invocation duration.

Adding more instrumentation

Now that the dependencies are in place and tracing is enabled for our function we can enrich the traces in X-Ray by leveraging the X-Ray SDKs TracingIntercepter . For instance for the SQS and DynamoDB client you can explicitly set the intercepter inside the application.properties file.

quarkus.dynamodb.async-client.type=aws-crt
quarkus.dynamodb.interceptors=com.amazonaws.xray.interceptors.TracingInterceptor
quarkus.sqs.async-client.type=aws-crt
quarkus.sqs.interceptors=com.amazonaws.xray.interceptors.TracingInterceptor

After putting these properties in place, redeploying and executing the function, the TracingIntercepter will wrap around each API call to SQS and DynamoDB and store the actual trace information along side the trace.

This is very useful for debugging purposes as it will allow you to validate your code and check for any mistakes. Requests to AWS Services are part of the pricing model, so if you make a mistake in your code and you make too many calls it can become quite costly.

// Detect dark theme var iframe = document.getElementById('tweet-1635244161778737152-958'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1635244161778737152&theme=dark" }

Custom subsegments

With the AWS SDK TracingInterceptor configured we get information about the calls to the AWS APIs, but what if we want to see information about our own code or remote calls to services outside of AWS?

The Java SDK for X-Ray supports the concept of adding custom subsegments to your traces. You can add subsegments to a trace by adding a few lines of code to your own business logic as you can see in the following code snippet.

public void someMethod(String argument)  {
  // wrap in subsegment
  Subsegment subsegment = AWSXRay.beginSubsegment("someMethod");
  try {
      // Your business logic
  } catch (Exception e) {
     subsegment.addException(e);
     throw e;
  } finally {
     AWSXRay.endSubsegment();
  }
}

Although this is trivial to do, it will become quit messy if you have a lot of methods you want to apply tracing to. This isn't ideal and it would be better of we don't have to mix our own code with the X-Ray instrumentation.

Quarkus and Jakarta CDI Interceptors

The Quarkus programming model is based on the Lite version of the Jakarta Contexts and Dependency Injection 4.0 specification. Besides dependency injection the specification also describes other features like:

Lifecycle Callbacks - A bean class may declare lifecycle @PostConstruct and @PreDestroy callbacks.
Interceptors - used to separate cross-cutting concerns from business logic.
Decorators - similar to interceptors, but because they implement interfaces with business semantics, they are able to implement business logic.
Events and Observers - Beans may also produce and consume events to interact in a completely decoupled fashion.

As mentioned, CDI Interceptors are used to separate cross-cutting concerns from business logic. As tracing is a cross-cutting concern this sounds like a great fit. Let's take a look at how we can create an interceptor for our AWS X-Ray instrumentation.

We start with defining our interceptor binding which we will call XRayTracing. Interceptor bindings are intermediate annotations that may be used to associate interceptors with target beans.

package com.jeroenreijn.aws.quarkus.xray;

import jakarta.annotation.Priority;
import jakarta.interceptor.InterceptorBinding;

import java.lang.annotation.Retention;

import static java.lang.annotation.RetentionPolicy.RUNTIME;

@InterceptorBinding
@Retention(RUNTIME)
@Priority(0)
public @interface XRayTracing {
}

The next step is to define the actual Interceptor logic, the code that will add the additional X-Ray instructions for creating the subsegment and wrapping it around our business logic.

package com.jeroenreijn.aws.quarkus.xray;

import com.amazonaws.xray.AWSXRay;
import jakarta.interceptor.AroundInvoke;
import jakarta.interceptor.Interceptor;
import jakarta.interceptor.InvocationContext;

@Interceptor
@XRayTracing
public class XRayTracingInterceptor {

    @AroundInvoke
    public Object tracingMethod(InvocationContext ctx) throws Exception {
        AWSXRay.beginSubsegment("## " + ctx.getMethod().getName());
        try {
            return ctx.proceed();
        } catch (Exception e) {
            AWSXRay.getCurrentSubsegment().addException(e);
            throw e;
        } finally {
            AWSXRay.endSubsegment();
        }
    }
}

An important part of the interceptor is the @AroundInvoke annotation, which means that this interceptor code will be wrapped around the invocation of our own business logic.

Now that we've defined both our interceptor binding and our interceptor it's time to start using it. Every method that we want to create a subsegment for, can now be annotated with the @XRayTracing annotation.

@XRayTracing
public SyndFeed getLatestFeed() {
    InputStream feedContent = getFeedContent();
    return getSyndFeed(feedContent);
}

@XRayTracing
public SyndFeed getSyndFeed(InputStream feedContent) {
    try {
        SyndFeedInput feedInput = new SyndFeedInput();
        return feedInput.build(new XmlReader(feedContent));
    } catch (FeedException | IOException e) {
        throw new RuntimeException(e);
    }
}

That looks much better. Pretty clean, if I say so myself.

Based on the hierarchy of subsegments for a trace, X-Ray will be able to show a nested tree structure with the timing information.

Closing thoughts

The integration between Quarkus and X-Ray is quite simple to enable. The developer experience is really good out of the box with defining the interceptors on a per client basis. With the help of CDI interceptors you can keep your code clean without worrying too much about X-Ray specific code inside your business logic.

An alternative to building your own Interceptor might be to start using AWS PowerTools for Lambda (Java). Powertools for Java is a great way to boost your developer productivity, but it can be used for more than X-Ray, so Ill save it for another post.

The Evolution of the AWS Community Builders Blogs Twitter Bot Architecture

Jeroen Reijn — Mon, 22 Jan 2024 15:11:15 +0000

In 2022, when I was accepted into the AWS Community Builders program, I was amazed by the abundance of high-quality content generated by the broader AWS community. While most community builders publish their blog content on personal websites, Medium, or Hashnode, it is common for this content to be (re)published on the dev.to platform within the AWS Community Builders organization. It currently acts as a hub for blog content created by AWS community builders.

I didn't frequently visit the dev.to platform and also was not really using an RSS reader anymore, so I began exploring alternative solutions. Most of the interesting articles I usually find on Twitter/X. I sought to find an existing Twitter account sharing the community builders content but was unsuccessful. Being a builder myself, I decided to create a fresh Twitter account (@aws_cb_blogs) and wanted to create a fully Serverless architecture. In this post I'll explain how the architecture has evolved over time and what are some of the things to come.

The initial idea

As a first iteration I decided to put something together rather quickly. I needed three component:

a component to read and parse the rss feed.
a component to turn posts into tweets.
a schedule to make sure new items are being picked up.

To initiate the entire process I needed to have a solution similar to a cron job (scheduled job). AWS offers this in the form of Amazon EventBridge Scheduler. Its a pretty straightforward service which allows you to easily create a scheduled call to more than 270 AWS services and over 6,000 API operations.

I decided to split the business logic of the application by responsibilities into different lambda functions and I ended up with the following architecture.

The Twitter API requires authentication with keys and I needed to store them in a secure place. Its better to not store them with(in) the Lambda, so I decided to put them into Systems Manager Parameter Store. For each cold start invocation of the Tweet function a call is made to parameter store to fetch the API credentials.

While building, I quickly realized I needed some persistent storage as the RSS feed could contain the same items during a consecutive fetch. I did not want the bot to repeat an already tweeted post so I needed some sort of storage for storing the tweetid for a specific post. I needed a simple persistent database and decided to use DynamoDB as the database for keeping track of the posts. The great thing about DynamoDB is that its a fully managed serverless databases and it offers a pay as you go model. Its really cheap for most cases and I only pay $0.01 a month for using it for this application.

Improving the design

A few weeks later I decided that I wanted to improve the architecture a bit and decided to decouple the two Lambda components by means of an SQS queue. The advantage of using the SQS queue is that when the function fails the item(s) being processed is not removed from the queue and will be retried at a later moment in time. For consecutive failures I added a dead letter queue (DLQ), so in case the messages on the queue can't be processed, they will be moved to the DLQ. If there is an error in the component or at the Twitter API I will be able to inspect the messages and re-drive them. You might think this is not necessary, but once Twitter announced their new API plans in March 2023 , the function that was responsible for tweeting was unable to send out tweets until I subscribed to the new usage plan. Because of the DLQ, it was a matter of re-driving the messages instead of trying to get the changes to propagate again.

New feature imposed more changes

Some authors on the dev.to platform have added their Twitter handle to their profile. I thought it would be great to be able to mention the author in the tweet when its send out. It gives the tweet a bit more body and the author is notified when the post hits the twitter platform.

// Detect dark theme var iframe = document.getElementById('tweet-1749107205444444636-737'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1749107205444444636&theme=dark" }

From the RSS feed only the dev.to username of the author. The twitter handle is only available on the post itself, so I decided to add a third component to get the Twitter handle for the author.

Whats next?

This architecture has been running fine for quite some time now and Ive even deployed the same stack for a bot for the posts by the AWS Heroes, but I still have some improvements in mind:

Replacing the SQS queue for the posts by DynamoDB Streams. The author enrichment function would only have react to events in the stream. That would remove a bit of complexity and responsibility from the feed parser function.
If I look at the flow it looks a bit like a workflow. I'm considering to replace the entire thing and with a step functions workflow.
Integrate with Amazon Bedrock for generating summaries of the posts the bot is posting to Twitter. It would improve the Twitter posts a bit instead of just mentioning the author and the title of the post.
Extend the bot to also publish to other platforms. Ive been looking into Threads, but it does not seem to have a public API yet. Not sure how big the AWS community is on other social platforms. Feel free to reach out if you prefer to follow all the great content on your social media platform of choice.

In a follow up post I will dive into the technical details of how the functions work and will take a look at some of the best practices for building Lambda functions. If you have some comments/ideas/feedback, feel free to reach out!

Develop and Test your Github Actions workflow locally with "act"

Jeroen Reijn — Mon, 03 Jul 2023 10:11:37 +0000

At work, I regularly train people on the subject of Continuous Integration and Continuous Delivery, where I predominantly utilize GitHub Actions for the workshop assignments. This choice is motivated by GitHub's extensive adoption within the developer community and the generous offering of approximately 2000 minutes or 33 hours of free build time per month.

During one of my recent workshops, a participant raised a question regarding the possibility of locally testing workflows before pushing them to GitHub. They pointed out the inconvenience of waiting for a runner to pick up their pipeline or workflow, which negatively impacts the developer experience. At that time, I was unaware of any local options for GitHub Actions. However, I have since come across a solution called "act" that addresses this issue.

What is "act"?

"act" is a command-line utility that emulates a Github Actions environment and allows you to test your Github Actions workflows on your developer laptop instead of in a Github Actions environment. You can install "act" by using for instance brew on the Mac.

$ brew install act

Running Workflows Locally

"act" enables you to execute and debug GitHub Actions workflows locally, providing a faster feedback loop during development. Running the "act" command line will pick up the workflows in your .github/workflows folder and try to execute them. Using "act" can be as simple as:

$ act

"act" uses Docker to create an isolated environment that closely resembles the GitHub Actions execution environment. This ensures consistency in the execution of actions and workflows. If you don't have Docker installed you can use Docker Desktop or use Colima, an easy way to run container runtimes on macOS.

Runners

When defining the workflow you can specify a runner based on a specific virtual machine/environment when performing your steps.

jobs:
  Build:
    runs-on: ubuntu-latest
    steps:
      ...

By default, "act" has a mapping to a specific docker image when you specify the ubuntu-latest runner. When running "act" for the first time it will ask you to pick a default image for ubuntu-latest. You can choose from 3 types of base images that can be mapped to ubuntu-latest:

Micro Docker Image (node:16-buster-slim)
Medium Docker Image (catthehacker/ubuntu:act-latest)
Large Docker Image (catthehacker/ubuntu:full-latest)

Don't worry if you're not happy with the one you selected, you can always change the default selection by changing the following file in your users home directory ~/.actrc.

The large docker image is around 18GB!! , so I initially picked the medium-sized image as it should contain most of the commonly used system dependencies. I soon learned that it contains quite some libraries, but when I tried to run a Java + Maven-based project I learned that it did not contain Apache Maven, while the normal ubuntu-latest on GitHub does have that.

[CI/Build] Run Main Build
[CI/Build] 🐳 docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/2] user= workdir=
| /var/run/act/workflow/2: line 2: mvn: command not found
[CI/Build] Failure - Main Build
[CI/Build] exitcode '127': command not found, please refer to https://github.com/nektos/act/issues/107 for more information

I didn't want to switch to an 18GB docker image to be able to just run Maven, so I ended up finding an existing image by Jamez Perkins. It simply takes the original "act" image ghcr.io/catthehacker/ubuntu:act-latest and adds Maven version 3.x to it. You can easily specify running your workflow with custom images by providing the platform parameter.

$ act -P ubuntu-latest=quay.io/jamezp/act-maven

After using that image my workflow ran without any errors.

Working with multiple jobs/stages

Your GitHub actions workflow usually consists of one or more jobs that separate different stages of your workflow. You might for instance have a Build, Test and Deploy stage.

Usually, you build your application in the build job and use the resulting artifact in the deploy job. Jobs can run on different runners, so in a GitHub Actions environment, you will probably be using the up/download artifact action which will use centralized storage for sharing the artifacts between different runners. When using "act" and sharing artifacts you will need to be specific about where the artifacts need to be stored. You can do so by providing a specific parameter named --artifact-server-path.

$ act -P ubuntu-latest=quay.io/jamezp/act-maven \
  --artifact-server-path /tmp/act-artifacts

Working with secrets

It's a good practice to always separate your secrets from your workflow definition and only reference them from a specific secret store. When using GitHub Actions you can store your secrets in the built-in secret management functionality.

To provide an action with a secret, you can use the secrets context to access secrets you've created in your repository.

jobs:
  staticanalysis:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        # Disabling shallow clone is recommended for improving relevancy of reporting
        fetch-depth: 0
    - name: SonarQube Scan
      uses: sonarsource/sonarqube-scan-action@master
      env:
        SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

"act" does not have a UI in which you can specify secrets, so you will need to provide those values explicitly from the command line or store them in a .env formatted file when testing your workflow. If you only have a few secrets you can easily add them by just providing the secret from the command line by using the -s option.

$ act -s SONAR_TOKEN=somevalue
$ act --secret-file my.secrets

Working with environment variables

Similar to secrets you sometimes make use of environment variables inside your workflow. For a single environment variable you can use --env myenv=foo or if you have a set of environment variables you can create a dotenv file and provide a reference to the file from the CLI by providing the --env-file parameter.

$ act --env-file my.env

The .env file is based on a simple standard file format which contains a set of key-value pairs divided by new lines.

MY_ENV_VAR=MY_ENV_VAR_VALUE
MY_2ND_ENV_VAR="my 2nd env var value"

Event simulation

Events are a fundamental part of workflows. Workflows will start due to some specific event happening within Github like a push, creation of a pull request, etc. With "act" you can simulate such an event to trigger your workflow(s). You can provide the event as an argument.

$ act pull_request

Events are usually more complex than just a simple string so if you want to be specific you can provide a reference to an event payload:

$ act --eventpath pull_request.json


{
  "pull_request": {
    "head": {
      "ref": "sample-head-ref"
    },
    "base": {
      "ref": "sample-base-ref"
    }
  }
}

By providing your events from the command line you can test different scenarios and observe how your workflows respond to those events.

Summary

Using "act" is straightforward and can significantly help in the initial phase of developing your workflow. "act" offers a significant advantage in terms of a swift feedback loop. It enables developers to perform tests locally and iterate rapidly until they achieve the desired outcome, eliminating the need to wait for GitHub's runners to finish the workflow.

"act" additionally aids developers in avoiding resource wastage on GitHub's runners. By conducting local tests, developers can ensure the proper functioning of their workflows before pushing code changes to the repository and initiating a workflow on GitHub's runners.

If you're working with GitHub Actions I would recommend to asses "act" as a tool for your development team.