Building serverless applications

1.1 — Open a browser and navigate to Amazon RDS console. If you already have an AWS account, login to the console. Otherwise, create a new AWS account to get started.

On the top right corner, select the region where you want to launch the Aurora DB cluster.

Already have an account? Log in to your account

Already have an account? Log in to your account

1.2 — Click on "Create database" in the Amazon Aurora window.

You'll find a "Create database" button on the RDS Dashboard page, and on the Databases page that lists your Aurora clusters and RDS instances.

The "Create database" workflow includes many options that you don't need to worry about for this tutorial. We'll only call out the options where you need to change the default setting or enter a specific value.

1.3 — Select "Standard create"

For this tutorial, we'll need to select some specific options. Thus, we choose "Standard create" to be able to pick from every available setting.

1.4 — On Database engine, select "Aurora (PostgreSQL Compatible)".

For this exercise, we'll use the default Aurora PostgreSQL version, which is 15.4 as of the time this tutorial is published. Here's the engine to choose:

And here's the version. Any higher version is OK too.

1.5 — Select "Dev/Test" under Templates.

1.6 — Choose an identifier for your Aurora DB cluster

For the examples in this tutorial, we'll use "MyClusterName" for this identifier.

1.7 — Select a username and password for your database.

For real world use, you would use robust credential management such as Secrets Manager, and having the system generate a strong password for you. For this tutorial, we'll use the simplest type of credential management because you'll delete the Aurora cluster at the end.

First pick "Self managed". Then enter a password of your choice for "Master password" and "Confirm master password".

Choose "Serverless v2" for the DB instance class. Doing so brings up fields where you can specify the minimum and maximum capacity of each DB instance in your cluster. For this tutorial, we'll use a single DB instance for simplicity.

For "Capacity range", enter 0.5 for "Minimum capacity (ACUs)" and 16 for "Maximum capacity (ACUs)". This will let your compute capacity scale between 1 GB of RAM and 32 GB, as needed to handle the current level of activity in the database.

For "Multi-AZ deployment", choose "Don't create an Aurora replica". For this exercise using a short-lived dev/test cluster, it's not important to have a second DB instance as a standby server.

1.8 — Select the VPC where you want to create the database.

The virtual private cloud (VPC) defines a set of IP addresses that you can use for related resources. It provides an extra layer of security for Aurora clusters that you designate as nonpublic. Note that once created, a database can't be migrated to a different VPC.

1.9 — Create a new DB subnet group

The DB subnet group defines how the storage for the Aurora cluster is spread across three Availability Zones (AZs) for durability. That way, the data is safe even if the DB instances experience issues, or even in the rare case of an AZ-wide outage. When you create a new VPC, you'll need a new DB subnet group to go along with it.

For this tutorial, we also turn off public access to the Aurora cluster. That way, any Linux servers, client applications, or other resources outside the VPC can't access the IP addresses of the Aurora cluster at all. Later, we'll use the RDS Query Editor to connect to the Aurora cluster and run SQL statements without needing to set up a client system inside the VPC.

1.10 — On VPC security group, select "create new".

The VPC security group defines which IP addresses are allowed to connect to which ports for the Aurora cluster. Again, we'll set up restrictive rules to minimize how many client systems can access the cluster, even from inside the VPC. And again, we'll use the Query Editor so that you, the owner of the cluster, can run SQL statements on it without extensive network setup.

For the new VPC security group name, type "MyClusterGroup".

If you already have a security group that allows incoming TCP  connections on port 5432, you can choose it instead of creating a new one.

1.11 — Enable the Data API.

The RDS Data API lets you submit SQL statements to an Aurora cluster and get back the results in your application, without the need to configure connectivity settings and database drivers. Enabling the Data API for an Aurora cluster lets you use the RDS Query Editor with that cluster.

1.12 - Make sure "Turn on Performance Insights" is unchecked

This is a valuable monitoring feature that you'll likely use in your own deployments. However, it adds a little continuous activity to the cluster that can prevent Aurora Serverless v2 from scaling down to very low capacity. Thus, for this exercise we'll turn it off.

After a quick review of all the fields in the form, you can proceed.

1.13 — Click on "Create database".

1.14 — Click on the Aurora cluster name.

1.15 — In the "Configuration" tab, copy the Cluster ARN and keep it handy. You will need it later.

Before you being these steps, wait until both the Aurora cluster and associated DB instance have the status Available in the RDS console. That's when you can connect and run SQL operations.

1.16 — Open the left panel and click on "Query Editor".

1.17 — Enter connection details for Query Editor

For Database instance or cluster, select "myclustername".

For Database username, choose "Enter new database credentials".

Enter "postgres" as the database username, and input the database password you created earlier.

Then enter "postgres" for the database name.

Finally, click on "Connect to database".

1.18 — You can now click "Run" and execute the sample query.

1.19 — Create a database by running the following query:

CREATE DATABASE tutorial;

1.20 — Click on "Change database".

1.21 — Change the database to the one you just created.

Now under "Database username", you can select the postgres user to log in with those saved credentials. This time, for the name of the database, enter "tutorial".

1.22 — Create a table with this query:

CREATE TABLE sample_table(received_at TIMESTAMP, message VARCHAR(255));

By connecting to the database with the Query Editor, a Secret is created that you will use later on in your Lambda function. Leave this tab open, as you will need to run some queries at the end of the tutorial.

Open a new tab and head to the AWS Secrets Manager. Then follow the steps below to retrieve the Secret ARN.

1.23 — Find the secret containing the "RDS database postgres credentials for name_of_your_cluster".

1.24 — Click on the Secret name, then copy the Secret ARN and keep it handy.

You'll use this Amazon Resource Name to connect this set of credentials with the associated Aurora cluster. That way, you don't have to type, copy, or write down the user name and password when you're accessing the Aurora cluster through the Query Editor or a Lambda function.

2.2 — Under Trusted entity type, choose "AWS service".

2.3 — Under "Use case", choose Lambda and click on Next.

2.4 — Select the AWSLambdaBasicExecutionRole and AmazonRDSDataFullAccess managed policies, then click on Next.

2.5 — Enter the Role name AWSLambdaFunctionAuroraTutorial and then click on "Create role".

2.6 — Now the Roles screen will show a banner explaining that the role was successfully created.

3.2 — Select Author from scratch.

3.3 — In the Basic information pane, for Function name enter aurora-serverless-v2-test.

3.4 — For Runtime, choose Python 3.12

3.5 — Leave architecture set to x86_64

3.6 — Under Permissions, expand Change default execution role

Choose Use an existing role and from the dropdown select the IAM role AWSLambdaFunctionAuroraTutorial that you created earlier. Then click on Create function.

3.7 — Delete the code in the lambda_function.py file and in its place copy this sample code.

Replace the cluster_arn and secret_arn values with the Cluster ARN and Secret ARN values you obtained in previous steps.

3.8 - Deploy your Lambda Function by clicking on Deploy.

4.2 — Leave all the default values and click on "Create topic".

You will see a green banner indicating that the topic was successfully created.

4.3 — Copy the SNS ARN and keep it handy.

Keep this tab open, as you will use it to publish a message once the Lambda Function is configured to read from the topic you created.

5.2 — Type "SNS" and select the "SNS" services from the dropdown menu.

5.3 — In the "SNS Topic" field, enter the SNS ARN.

Then click on "Add".

6.2 — Enter any value for the “Subject” field.

6.3 — Enter any value for the “Body” field.

6.4 — Scroll down and click on "Publish message".

Once the message is published, your Lambda Function will consume it and process it. In the next section, you will verify how the data was written to your Aurora database.

6.5 — Go to the tab where you left the Query Editor open, connected to the tutorial database.

If you closed that tab, visit the RDS Dashboard and connect to the "tutorial" database in the Query Editor, as explained earlier.

6.6 — Select all the records from sample_table:

Run the following SQL query in the Query Editor window.

SELECT * FROM sample_table; 

6.7 — Click on "Run" and scroll down to see the results.

All should be working now. You can experiment by changing the messages you send via SNS, or you can alter the lambda_handler function any way you want.

7.2 — Visit the SNS Dashboard and click on "Topics" on the left panel.

7.3 — Select the topic you created in Step 5 and click on "Delete".

7.4 — You will be asked for confirmation. Type "delete me" to confirm and click on "Delete".

7.5 — Go to the Databases page in the Amazon RDS console.

From the Clusters list, select the Aurora Serverless v2 DB instance that's nested underneath your cluster.

If you called the cluster myclustername, the database instance name should be similar to myclustername-instance-1.

From the Actions menu, select Delete.

7.6  — When prompted, confirm deletion by typing delete me into the appropriate field.

If you set up a multi-AZ cluster or added any reader instances so that the cluster contains more than one DB instance, repeat this step for each DB instance in the cluster.

7.7. Once all DB instances in the cluster are in Deleting state, select the myclustername cluster, and from the Actions menu select Delete.

You don't need to wait until the DB instances are actually gone. The cluster item on the console page represents the storage for your database tables and other objects. The data in the cluster remains intact until you delete the cluster, regardless of how many instances are in the cluster.

7.8. Confirm that you really intend to delete the Aurora cluster.

Uncheck the box for Create final snapshot.

Select the acknowledgment checkbox to confirm it's OK to delete the data in the Aurora cluster.

If you created any information during your testing that you want to preserve, you can leave Create final snapshot selected. This will allow you to retrieve the data later in a new Aurora cluster.

Then, enter "delete me" to confirm deletion.

7.9 — Go to the AWS Secrets Manager, find the secret containing the "RDS database admin credentials for the name of your cluster", and click on the name of the secret.

7.10 — Click on "Actions > Delete secret".

7.11 — The secrets can't be deleted immediately. The minimum waiting period for a scheduled deletion is 7 days. Select 7 days and click on "Schedule deletion".

7.12 — Go to the AWS IAM console. Click "Roles" and search for the IAM role you created, AWSLambdaFunctionAuroraTutorial.

Select the role and click on "Delete role".

7.13 — To confirm deletion, enter the role name in the text input field.