AWS Cloud Development Kit (AWS CDK) is a powerful tool that allows developers to define cloud infrastructure in code using familiar programming languages like TypeScript, Python, and Java. However, as with any infrastructure-as-code tool, it’s important to ensure that the resulting infrastructure adheres to security and compliance best practices. This is where cdk-nag comes in.
In part one of this series we looked at Jedis as the Java-based Redis driver when used in combination with ElastiCache for Redis in clustered mode. We learned that during a failover Jedis takes some time to figure out what the new primary is before it can restore the connection to the ElastiCache cluster. In this post, I’ll share some of the lessons learned from switching to Lettuce as the driver for our Java-based application.
In my day-to-day job, I support teams at different organizations and help them with their AWS challenges. One of the teams I recently supported, was using Amazon ElasticCache for Redis as a storage/caching layer for their primary workload. They were validating their production setup and testing several failure scenarios. In this post, I will share some of the lessons learned. Keep in mind that the cases described in this post are very context-specific and might not reflect your use case, so my advice is to always do your own tests.
In general, AWS Lambda functions are triggered by some sort event. Most common use cases are an event from EventBridge, SQS, or an event created by a call to API Gateway in case you have a REST/HTTP API based on an AWS Lambda function. However, the other day I was looking for an option to execute my Lambda function immediately after it was created and/or updated while deploying my Infrastructure as Code with AWS CDK. I wanted it to work without manually executing a CLI command or calling an HTTP endpoint. It needed to be based on the CDK / CloudFormation deployment. A couple of use cases we had was triggering an import process or running a liquibase/ flyway script to populate a database.
A couple of weeks ago I was working on some AWS CDK based code and I was trying to figure out how to configure auto-scaling for the provisioned concurrency configuration of an AWS Lambda function. We wanted to run some performance tests on our service and were wondering how scaling provisioned concurrency would impact our overall latency. We tried with the default configuration but also wanted to experiment with a bit more aggressive scaling policy so we had to provide our own metric configuration. In this post, I will explain what provisioned concurrency is and how to set up an auto-scaling configuration for it using AWS CDK. We’ll be looking at using predefined metric configurations, but also how to do it with a custom metric.