CloudWatch settings

Different logging settings can be applied for each API stage. That is why we find the CloudWatch settings under Stages -> [stage name] -> Logs/Tracing.

For CloudWatch logs we can select from two logging levels: INFO to generate execution logs for all requests or ERROR to generate execution logs only for requests that result in an error.

We have the option to log full requests/responses data by selecting the appropriate checkbox.

Also here we can enable detailed CloudWatch metrics.

Let’s say we have never enabled API logging before. In this case, when trying to save our changes we will get the following error:

CloudWatch Logs role ARN must be set in account settings to enable logging

CloudWatch permissions

The above error appeared because we have not yet set up the CloudWatch log role ARN under Settings.

Keep in mind that API settings are global. They apply to all of our gateways. Changing the CloudWatch log role ARN in one API Gateway will change it on all of our gateways provided that we are using the same region!

Let’s try adding our previously created role: simple-api-role ARN. You get the ARN from the IAM console -> Roles, and then selecting simple-api-role.

Upon adding our ARN we get another error:

The role ARN does not have required permissions configured. Please grant trust permission for API Gateway and add the required role policy.

Our role is not yet configured to write to CloudWatch. Let’s go back to IAM and update our simple-api-role with the proper permissions.

First, we need to attach the AmazonAPIGatewayPushToCloudWatchLogs policy to our role. We have done adding policies to roles before. If you have stuck go back to the Adding a new Lambda function to an API Gateway post where I described how to attach a new policy to an existing role. But we are not done yet…

On the Trust relationships tab click Edit trust relationship and add apigateway.amazon.aws.com. If you only used Lambda with this role this example policy document will work for you:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
            "lambda.amazonaws.com",
            "apigateway.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Now that the permissions are properly configured we can go back to the API Gateway and add the role without any errors.

Finish

We have set up the CloudWatch log role ARN now it’s time to enable logging in our API Gateway.

When we enable logging in the /aws/apigateway/welcome log group we will see a new log entry: Cloudwatch logs enabled for API Gateway. This means we have done a great job! Unfortunately, the log message doesn’t say for which gateway but based on the timestamp we can double-check if this our gateway.

The Amazon API Gateway will generate a new log group based on the following format: API-Gateway-Execution-Logs_apiId/stageName. Here we can find the log entries for our API Gateway.

We are almost finished with our API Gateway series. But we have the most important task to last: Documentation.

A Enable logging in API Gateway bejegyzés először Road to AWS-én jelent meg.

Cognito User Pools

Amazon Cognito is a simple and Secure User Sign-Up, Sign-In, and Access Control tool. It can manage User Pools and Identity Pools. User pools are user directories that provide sign-up and sign-in options for your app users. Identity pools provide AWS credentials to grant your users access to other AWS services.

For our API Gateway, we will create a Cognito User Pool that will handle all of our authorization tasks, including managing usernames, passwords, and access tokens.

Let’s start with Cognito and selecting Manage User Pools. Here we Create a user pool. We name our pool simple-api-AUTH and review the Step through settings as we customize our pool. Remember that we cannot change these attributes after we have created the pool. Policies and other pool settings can be changed later but attributes cannot. When we are at the “App client” settings we create a new app client for our API Gateway.

Here we set up our App client. For simplicity, we will uncheck the Generate client secret option and enable the ALLOW_ADMIN_USER_PASSWORD_AUTH that we will need for our Lambda function to access.

Our User Pool is now ready. It’s that easy.

Adding a user to a Cognito User Pool

We have several options to create users in our user pool. The default settings allow users to sign themselves up. We can create a simple UI or enable other identity providers like Facebook or “Sign in with Apple”. For simplicity, we will create the user manually under Users and groups.

After we have created the user the user will receive an Email with the following information:

Your username is misi and temporary password is 00eEhtI;.

It looks like everything is ready in Cognito but if we look closely we see that the user is not yet activated. The account status is: FORCE_CHANGE_PASSWORD

We cannot change this in the Cognito UI so we will do this in Lambda instead.

Connecting our API Gateway to Cognito

We now head back to our API Gateway and select Authorizers. Here we Create New Authorizer.

We select the type to be Cognito and select our Cognito User Pool that we have created earlier. You can name your token source whatever you like but for following standards, we name it Authorization.

Securing an API method with Cognito

Let’s start securing our methods with Cognito authorization. I will select the GET method inside the hello resource that we have created earlier. We have set up API Keys before for this method so I will remove the API Key required option and select Cognito for our Authorization.

If we check out our method we now see that Cognito is the Authorizer.

Preparing our auth function for authentication

When we added a new Lambda function to our API Gateway we have created an auth method for our gateway. We will use this for authentication. It’s a good idea to rely on the features that Amazon API Gateway already has, including request validations. The API Gateway can validate the query string, the headers, and the body. The latter we will discuss in a later post because it requires creating a model. Setting up query string parameters is much more simple.

Let’s supply username and password as URL Query String Parameters and mark them Required. Under the Request Validator select Validate query string parameters and headers.

The AWS API Gateway will now check for these parameters and if they don’t exist the gateway will throw an error to the user.

Don’t forget to Deploy the API.

Setting up the necessary permission for Lambda

Our Lambda function needs to access our Cognito user pool. Yes, you guessed right we are going to IAM.

There is no default policy for the permissions we would like to issue so we will create a new policy for it. We need AdminInitiateAuth and AdminSetUserPassword permissions for our Lambda function to manage our Cognito user pool.

Under Policies we “Create policy” and at services, we select Cognito User Pools. Under Action we select the two permissions and under Resources we add the ARN of the Cognito User Pool.

We then create this policy and attach it to our simple-api-Role as we learned in the previous post.

Confirming the user

Let’s go back to Lambda and get rid of that pesky “FORCE_CHANGE_PASSWORD” status. For this, we will write a simple Lambda function that will change the password of our user.

This is the code I used to verify the user:

const params = {
    Password: 'password',
    UserPoolId: 'Pool Id',
    Username: 'username',
    Permanent: true
};
    
await cognito.adminSetUserPassword(params).promise();

Run the code and if we set up everything correctly Cognito will show that the account status is now CONFIRMED.

Final touches

We are almost finished! We just have to write a small code that will call Cognito for authorization. Luckily we already have a sample Lambda function that we can modify: simple-api-auth

Replace the code we had earlier with this sample code:

const aws = require('aws-sdk');
const cognito = new aws.CognitoIdentityServiceProvider();

exports.handler = async (event) => {
    const params = {
        AuthFlow: 'ADMIN_NO_SRP_AUTH',
        ClientId: 'App client id',
        UserPoolId: 'Pool Id',
        AuthParameters: {
            USERNAME: event.queryStringParameters.username,
            PASSWORD: event.queryStringParameters.password
        }
    };
    
    var authResponse = await cognito.adminInitiateAuth(params).promise();
    
    const response = {
        statusCode: 200,
        body: JSON.stringify(authResponse),
    };
    return response;
};

Deploy and we are done!

Testing our API Gateway authentication

Let’s go to Postman and see if everything is working as expected.

If we call our /hello method we will receive the following error:

“message”: “Unauthorized”

Great! We need an IdToken to access this method. Let’s call our auth method to get the token. API Gateway will check if we have the username and password params. If not, we will receive an error.

We received our token. Now if we go back to our /hello method and set the Authorization header we will have access to our function. Be sure to use the IdToken for Authorization.

And voila! Our API Gateway is now using Cognito for authentication.

A Controlling API Gateway access with Cognito bejegyzés először Road to AWS-én jelent meg.

Creating the Lambda function

First, we create a Lambda function as in the previous post but instead of selecting Use a blueprint we now select Author from scratch. We give our function a name. Under Permissions we won’t create a new role for this function, we will select our existing role that has been created by our blueprint.

After clicking Create function our Lambda code is created and is ready to be linked with our API Gateway. For this, we go into the API Gateway service.

We would like to use this function as a new resource so we create a new resource and in that a new method. On the method settings, we select our new Lambda function as we did before. We now can see in our API flow diagram how our newly created Lambda function is executed.

Upon clicking on Test we can test our new API call and everything looks okay. Are we sure?!

Is everything okay?

Remember, that we selected to use an existing role for our new Lambda function. Does our role have all the required permissions?

If we go back to Lambda and check out the Monitor section we see no errors.

But upon clicking View logs in CloudWatch we get an error.

This means that logging doesn’t currently work on our new Lambda function. We have to manually create a log group and allow our role to write to this log.

In the CloudWatch console, we select Log groups and click on Create log group and name our log group exactly as in the error message. In our case: /aws/lambda/simple-api-auth

When the log group is created remember to note down its ARN because we will later need it.

Now, to allow our role to write to this log group, we have to go to IAM and modify our role. We see that the CloudWatch permissions are in the AWSLambdaBasicExecutionRole policy.

We now select this policy and click on Edit policy. Under the resources section, we click on Add ARN and add our newly created log groups ARN. Save the policy.

And we are done! We have added a new function to our API Gateway and set up the necessary permissions.

Takeaways:

• Keep your permissions maintained in IAM. Specify resources and only allow policies that are required.

A Adding a new Lambda function to an API Gateway bejegyzés először Road to AWS-én jelent meg.

AWS recommends using an API for most of your tasks because it would be easier later to scale your cloud infrastructure. In this example, we will create a simple API that calls a Lambda function.

I recommend starting with a simple blueprint, in this way all the necessary resources will be created automatically and linked together. Later you can modify these settings.

Starting with a blueprint

Let’s start with the AWS Management Console. Select Lambda from the services and click on Create function.

Under Create function select Use a blueprint and filter for the word “api” under Blueprints. Select the microservice-http-endpoint blueprint and click Configure.

On the next screen, we configure the Lambda and API Gateway. Name your Function under Function name and set a role name under Role name. Under the API Gateway trigger select Create an API and select REST API as the API type. AWS recommends using the HTTP API because of its performance, but currently, the REST API has more features. You can see a full comparison between HTTP and REST API on this page: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html
For security reasons, we select API key under Security. At a later stage, we will change this to Cognito but for now, API keys are the way to go because they are really easy to manage and provide basic security.

The Lambda and the API Gateway are now created and linked together. Great job!

Configuring the API Gateway

Let’s start configuring the API Gateway first. Select API Gateway from the services in the AWS Management Console and select the newly created API. The API is now active and open: it will accept any connection and won’t require an API key. Since we don’t need it first we delete the GET method under our sample API.

Let’s create a resource called “hello”. Select your API root (in our case simple-api) and under Actions select Create Resource. Name your resource “hello”.

Under this resource we then create a GET method. Be sure to check “Use Lambda Proxy Integration” because that is how we will read the resource name from Lambda. Also, select the Lambda Function that has been created by the blueprint automatically.

Now let’s apply some security to our API. Select our newly created GET method and click on Method Request. Here we change API Key Required to true.

We are almost done with our API Gateway configuration! But here comes the most important part. We should deploy our API. Under Action select Deploy API.
Before leaving our API service we should write down some important information: our Invoke URL and API key. Under Stages select your default stage, where you can find the invoke URL. Under API Keys you find the simple-api-Key which is your API key. Now we can go back to Lambda.

Configuring Lambda

The blueprint created a Dynamo DB example. We won’t use Dynamo DB for now. Replace the default code with this one. And click Deploy. Now we can test our API!

const AWS = require('aws-sdk');

exports.handler = async (event, context) => {
    
    var response_status, response_body; 
    
    if (event.resource.endsWith('hello')) {
        response_status = 200;
        response_body = "Hello from Lambda";
    }
    else {
        response_status = 200;
        response_body = "Unsupported resource";
    }

    const response = {
        statusCode: response_status,
        body: JSON.stringify(response_body),
    };
    return response;
};

The best tool to test APIs is Postman. You can create an account for free.

In postman test your newly baked API. Be sure to set your API key.

Well done! You now have a fully working API with basic security.

A Creating a simple API Gateway on AWS bejegyzés először Road to AWS-én jelent meg.