Author: Renato Losio

AWS recently introduced Console-to-Code, offering a new capability to transform actions executed in the console into reusable code for AWS CDK and CloudFormation. This generative AI feature is currently in preview, supporting only Amazon EC2, and provides a guided path for creating resources and testing prototypes.

Designed to get started with automation code, Console-to-Code records all the actions and generates code in different infrastructure-as-code (IaC) formats: the service currently supports outputs for the CDK (in Java, Python, or TypeScript) and CloudFormation, both JSON and YAML. The documentation warns:

You then use the code as a starting point for your automation scripts. You’ll need to validate that the code meets your intent and that the parameters will configure your resources as expected. You’ll need to customize the code to make it production-ready for your use case. Once you’re satisfied with the code, you can use it in your automation scripts.

The cloud provider released an animation to showcase how to generate code using Console-to-Code in the EC2 console. David Jennings, Python developer and DevOps engineer, comments:

Oh God, this is going to make my life so much easier. It’s been a long time since I’ve genuinely been excited about a new AWS thing.

Matt Lloyd, technical lead at Thoughtworks, adds:

This is exactly what I was hoping AWS would create. Console to code, so your console actions can be converted to CDK. So many teams struggle with infra as code, so revert to the console. Now you can have the best of both worlds. Excited to play with this!

In the “Console-to-Code Preview: Test Drive, Bright Future” article, Jon Holman, solutions architect at Groundswell, considers different use cases for the new product:

Using this tool, newcomers can more easily adopt the best practice of using Infrastructure as Code (IaC). This tool can even help seasoned IaC professionals create new templates while adding rarely used resource types.

The ability to generate code for console actions gained positive reactions in the community, but the limited scope of the preview raised some doubts. Holman writes:

I thought creating an EC2 instance with all default settings except my key pair would be a simple test of this new feature. However, after needing to fix the provided template over six iterations to deploy successfully, I conclude that this feature is unfortunately not ready to be used. It is fun to play with, though. I understand this feature is still in preview, but what can this current version successfully do? The current version is limited in scope to the EC2 console. In the EC2 console, what is more fundamental than creating an EC2 instance?

Based on generative AI, Console-to-Code is still in preview and supports a maximum of 5 actions for a single transformation. The feature is limited to the Amazon EC2 console and only available in the Northern Virginia region. There are no additional costs for using it.

AWS recently announced that Amazon CloudWatch alarms now support AWS Lambda functions as an action for state changes. This new feature enables developers to automate remediation actions when detecting an unhealthy resource.

Designed to be the easiest way to automate custom actions on alarm state changes, the new option allows developers to invoke a Lambda function directly when a CloudWatch alarm changes to an OK, ALARM, or INSUFFICIENT_DATA state.

The PutMetricAlarm now supports invoking the latest version of a Lambda function (arn:aws:lambda:region:account-id:function:function-name), a specific version of the function (arn:aws:lambda:region:account-id:function:function-name:version-number) or using an alias (arn:aws:lambda:region:account-id:function:function-name:alias-name). According to the documentation, when a Lambda function is configured as an alarm action, CloudWatch delivers a JSON payload to the Lambda function when it invokes it, including alarmData, previousState, and configuration information.

Invoking a Lambda function is not the sole option available in CloudWatch Alarms: notifying one or more people or services by sending a message to an SNS topic remains the most popular choice. Additionally, alarms can perform actions to scale an Auto Scaling group and alarms based on EC2 metrics can execute EC2 actions, such as stopping, terminating, rebooting, or recovering an instance. Finally, when alarms go into an ALARM state, they can create operational work items in Systems Manager Ops Center or incidents in the Systems Manager Incident Manager.

The cloud provider emphasizes the ability to combine this new option with existing ones:

You can use the fact that multiple actions are allowed for an alarm to send an email when a threshold is breached, and then another when the breaching condition ends. This helps you verify that your scaling or recovery actions are triggered when expected and are working as desired.

The community’s response has been overwhelmingly positive, with Luc van Donkesgoed, Principal Engineer at PostNL, writing:

Another loooooong (like 9 years long) awaited feature is here: CloudWatch Alarms can now directly call Lambda Functions!

Antonio Lagrotteria, principal cloud engineer and architect at Nordea, describes it as one of the “top 3 post-reinvent announcements that people have been waiting for almost a decade and should shadow most of reinvent announcements.” On a Reddit thread, user yourparadigm suggests instead that the change is not significant and emphasizes that it was already possible to trigger a Lambda function indirectly:

Is putting an SNS Topic in front that big of a deal?

In a separate announcement, the cloud provider revealed that CloudWatch Network Monitor is now generally available. This new feature facilitates monitoring network availability and performance between AWS and on-premises environments and it supports hybrid monitors for networking built with AWS Direct Connect and AWS Site-to-Site VPN.

CloudWatch Alarms support for Lambda actions is available in all regions and standard Cloudwatch pricing applies.

Recently, AWS notified existing customers running Amazon Aurora that Serverless v1 support will be discontinued, with the service scheduled to shut down within a year. The absence of scaling to zero in the newer Aurora Serverless v2 has raised concerns within the community regarding potential increased costs and the absence of a ‘true’ serverless relational database on AWS.

Introduced in the summer of 2018, Aurora Serverless v1 lacks support for Multi-AZ clusters and does not incorporate the latest major releases of MySQL and PostgreSQL. However, clusters can automatically scale down to zero in the absence of activity. In the email to current customers, the cloud provider writes:

We are reaching out to let you know that as of December 31, 2024, Amazon Aurora will no longer support Serverless version 1 (v1). As per the Aurora Version Policy, we are providing 12 months’ notice to give you time to upgrade your database cluster(s). Aurora supports two versions of Serverless. We are only announcing the end of support for Serverless v1. Aurora Serverless v2 continues to be supported. We recommend that you proactively upgrade your databases running Amazon Aurora Serverless v1 to Amazon Aurora Serverless v2 at your convenience before December 31, 2024.

Ganesh Swaminathan, head of cloud solutions architecture at JPMorgan Chase & Co, comments:

Goodbye to a relational database that could idle down to zero on its own. Hello to double the bill (or more – instead of scale 2 zero idle to a higher minimum – v2 has lower min).

While Aurora Serverless v2 significantly narrows the feature gap with provisioned Aurora by introducing replicas, logical replication, and global databases, it cannot scale down to zero. This absence of a zero-scaling feature is important for development and test databases, which may experience extended periods of inactivity. Aurora Serverless v2 mandates a minimum of 0.5 Aurora capacity units (ACUs), resulting in constant charges and provisioning. In a popular Reddit thread, user zmose adds:

I am pretty disappointed that Aurora Serverless V2 cannot seem to scale to 0 ACU. Ya know, what “serverless” is supposed to mean? I think it ends up being around $50/month at minimum.

While most developers stress the price difference for small deployments, SteveTabernacle2 comments:

It is the principle. AWS marketed the “scale-down to zero” point hard. Watch any serverless re:Invent talk pre-2020 and it is likely mentioned within the first 5 minutes of the talk. This new crop of “serverless” offerings (Aurora v2, Elasticache, OpenSearch) should never have been called serverless.

The announcement of the long-awaited RDS Data API v2 is seen by some developers as an indication that the cloud provider is working to bridge the gaps between the two versions. Tim Gustafson, a principal database specialist solutions architect at AWS, instead explains how to upgrade from Aurora Serverless v1 to v2 with minimal downtime, taking advantage of blue/green deployments:

There is a new upgrade path for Aurora Serverless v1 that allows you to go from an Amazon Serverless v1 database to a provisioned Aurora cluster with only a 30-second failover, similar to what would happen if you promoted an Aurora read replica to be the new writer. Then you can use the new blue/green deployment feature to upgrade the database to a version supported by Aurora Serverless v2 and add a serverless instance to your cluster.

Noting that AWS rarely retires a service, Yan Cui, independent consultant and AWS Serverless Hero, points out:

Sadly, Aurora Serverless v1 is on the way out (…) It’s a rare incidence of AWS shutting down a service (I mean, SimpleDB is still around!).

As Aurora Serverless v1 and Aurora Serverless v2 support different versions of the MySQL and PostgreSQL engines, Gustafson warns:

Before we can migrate to Amazon Serverless v2, we need to upgrade the database to a version that Amazon Serverless v2 supports. (…) Doing a major version upgrade requires some planning, and should be done with the proper amount of testing.

Besides the email sent to existing users of Aurora Serverless v1, the cloud provider has not made any official announcements or shared a detailed roadmap regarding the retirement of the service.