Setting up the Accounts APIs

cd mfe-accounts
amplify import auth
amplify add api
  • our backend-config.json got updated with 3 new sections, api, auth and function.
  • A folder api. It contains CloudFormation templates responsible to create the API gateway and IAMs roles required to access Lambda functions.
  • A folder auth, with imported Cognito users pools.
  • A folder function. It manages the business logic for the Lambda function handler (under src folder), by provisioning resources with a CloudFormation template, which we will modify later in order to access the Aurora cluster.
  • A simple, yet incomplete REST API is exposed on an available URL via API Gateway:
amplify push

Hammering (and understanding) generic CORS errors

  • After above fix, CORS was still appearing but for a different reason, as shown in the x-amzn-ErrorType response header about an IncompleteSignatureException. According to AWS documentation, that error was due as it expected a Credential parameter. This made me think that the API Gateway was not setup correctly. Indeed, as shown below, API Gateway used an IAM role for authorizing requests, rather than Cognito. Let’s then create a Cognito authorizer, which allows you to control access to your API access. I had to set it to use the mfe-parent Cognito user pools, force to use the Authorization token claim to check user identity and associate it with the API Gateway accounts resource’s method execution. You can see these action sin the gif below.

Aurora cluster deep-dive with CloudFormation

Aurora logo
  • Update our backend-config.json to support our new rds custom resource, which we call accountsCluster.
  • Create a rds folder under amplify folder with below content containing a Paraments.json and a template.json files.
  • The Parameters.json is used as input parameters for the upcoming CloudFormation template and contains configurable information such as username to use to log in to the DB instance inside the Aurora cluster and the cluster name.
  • Template.json file contains this CloudFormation template, which creates an Aurora cluster with a DB instance named accountsDatabase. The template will leverage AWS Secret Manager to authenticate to the cluster. It is important to note that Aurora can be launched only in an AWS Virtual Private Network where its subnets span across at least 2 AZs and are defined as part of a DB Subnet Group associated with the DBSubnetGroupName identifier. Below you can see Aurora master and replicas DB instances available on a multi-AZ default configurationand their connection with the cluster.
  • Our Lambda requires access to Aurora. We can achieve that by leveraging the AWS Data API and setup a few IAM roles so that we can connect to the Aurora cluster. To do that we update our backend-config.json to add a dependsOn section specifying we rely on the accounts Cluster for our Lambda function.
  • We will use AWS Secret Manager to securely connect our Lambda to the Aurora cluster. To do that, we need to provide resource and secret arns so that our NodeJs function can have those info exposed and retrievable in the code. Below extract (full version here) allows the Lambda function get retrieve this info and to get the right permissions to both execute SQL statements against the cluster and access the secrets from Secret Manager.

Hook RDS with Lambda

amplify env checkout dev
amplify push

Accounts tree user interface





Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Antonio Lagrotteria

Antonio Lagrotteria

Engineering Manager | Architect | Team/Tech Lead with a passion for frontend, backend and cloud | AWS Community Builder