S3 hosting works very well until you have to interact with protected APIs. In order for your website to be seen by everyone, the S3 bucket where the website is hosted has to be publicly accessible. AWS warns us with this message:

When you turn off block public access settings to make your bucket public, anyone on the internet can access your bucket. We recommend that you block all public access to your buckets.

We can’t store any access keys, secrets, passwords because this will compromise the security of the services that we intend to use.

The solution to this problem is hosting with AWS Amplify. Everything you need is to connect your repository and configure build settings.

In the example below I will show how I store credentials for calling lambda function from React App.

Creating .env file

The first thing we need to do is to create a .env file with our credentials in the root directory of the application:

cd your_app_directory
touch .env
echo "REACT_APP_AWS_ACCESS_KEY=some_access_key" >> .env
echo "REACT_APP_AWS_SECRET_KEY=some_secret_key" >> .env
echo "REACT_APP_LAMBDA_API='https://lambda_api_link.com'" >> .env
echo "REACT_APP_AWS_REGION=some_region" >> .env

Modifying code to use environment variables

Here is how environmental variables are used in the code for calling lambda function:

useEffect(() => {
    const aws = new AwsClient({
        accessKeyId: process.env.REACT_APP_AWS_ACCESS_KEY,
        secretAccessKey: process.env.REACT_APP_AWS_SECRET_KEY,
        region: process.env.REACT_APP_AWS_REGION
    })

    async function invokeMyLambda(event) {
        const res = await aws.fetch(`${process.env.REACT_APP_LAMBDA_API}`)
        return res.json()

    }

    invokeMyLambda({my: 'event'}).then(json => {
            if(json.body.undefined !== true){
                ...do something here...
            }
        }
    ).catch(err => console.log(err))

}, [])

Adding .env file to .gitignore

After creating .env file and modifying code, don’t forget to add .env file to .gitignore. If you do forget, the whole thing we do here is pointless :D

echo ".env" >> .gitignore

We are ready to push our repository to git and proceed to AWS Amplify now

Configuring AWS Amplify

After signing into your AWS account, choose the AWS Amplify service.

Click on the “New app” button and choose the “Host web app” option

As you can see, you can connect to various repository hosting services

After GitHub authorization, we can select our repository and the branch that should be deployed

In the next step, we have to configure our build, replace the default build file’s content with the next one:

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - yarn install
    build:
      commands:
        - yarn build 
        - echo "REACT_APP_AWS_ACCESS_KEY=$REACT_APP_AWS_ACCESS_KEY" >> /.env
        - echo "REACT_APP_AWS_SECRET_KEY=$REACT_APP_AWS_SECRET_KEY" >> /.env
        - echo "REACT_APP_LAMBDA_API=$REACT_APP_LAMBDA_API" >> /.env
        - echo "REACT_APP_AWS_REGION=$REACT_APP_AWS_REGION" >> /.env
        - echo "PUBLIC_URL" >> /.env
  artifacts:
    baseDirectory: build
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

As you can see, what we do here is installing dependencies (yarn install)and building our app for production(yarn build), and copying environment variables to the .env file

In the “Advanced settings” tab key all of your credentials

In the last step review settings and hit the “Save and deploy” button

Now just wait for build and deploy to finish, and your application will be available at the link provided under the picture.

Just with few clicks, we have our application hosted, our credentials stored securely, plus we’ve got continuous deployment. Every time we push to the master branch, Amplify will build the app automatically, how cool is that?

AWS Amplify offers much more - website monitoring, creating alarms on various events, creating deployment notifications, you can create a test environment for your dev branch deployments, add a custom domain, etc.

Price

As you can see, we are charged based on storage, the amount of GB we serve, and durations of or builds.

During the active development phase, I can see that I used 28 minutes of build and had 0.02 GB stored and served 0.017 GB. The total cost is less than 50 cents per month :O

One thing to note is that some services are billed additionally to Amplify.

For example, if you add a custom domain, you will pay for AWS CloudFront, for added build notifications, you’ll pay for AWS SNS, metrics alarms billed under AWS CloudWatch, etc.

Before adding anything, make sure that you read carefully and understand which service you will be using, so later when receiving your bill statement, you will not be surprised :)

As documentation suggests, the basic way of protection is using IAM authentication to control who can invoke an API, and:

Requests are not charged for authorization and authentication failures.

This will not defend against DDoS attack, but for sure this defend your credit card :D

Enabling IAM authentication is pretty simple, all you need is to click a few buttons in the console:

After saving and deploying API, we can try to access it :

What we need next is to create an IAM user who will be able to invoke API.

In the IAM console click on Users > Add user, select Programmatic access as access type:

In the second step create Group and attach AmazonAPIGatewayInvokeFullAccess policy, don’t forget to add our user to a group by check-marking:

you may add tags in the next step if you wish. In the last step save credentials, as notification suggests, it is the last time you see it :D

Now we can try to access our API with credentials through Postman.

On the Authorization tab, set Type to AWS Signature. For AccessKey and SecretKey, enter credentials from the last step, and set AWS Region to a region, where your API is located.

Now we can stop worrying about the next bill statement :D

AWS IAM is free of charge, and I think it is a good habit to always enable IAM authentication for every API you create.

One more option

Another thing I explored while researching, is AWS Web Application Firewall(WAF). This service can actually protect your API(and other services) from DDoS attacks.

You can create rules to allow or block requests from specified IP address ranges, requests from CIDR blocks, requests that originate from a specific country or region, requests that contain malicious SQL code, or requests that contain malicious script.

I think it is a great service to use if you have a public-facing API

The description sounds really cool but in my case using this service is redundant. Firstly, because the API I have is private, it handles only GET requests, and the second thing is the price. The minimum cost of AWS WAF is $6 per month. Knowing that cost of API itself approx. $5 per year, paying an extra $72 per year (20 large chicken shawarmas :D) doesn’t spark joy.

Securing API just with IAM authentication works for me since it protects from unplanned expenses, which was the initial requirement :)

What you will need:

1. Spotify Developer Account
2. AWS CLI
3. Docker running on your machine (optional)

The first thing you need is to get access and refresh tokens from Spotify, following this. (I assume you are familiar with OAuth 2.0 flow and can use curl or Postman :D)

Here is how our tiny architecture looks like:

As you can see from the diagram, we will use Lambda, API Gateway, and Secrets Manager.

AWS Secret Manager

Store a new secret with the next parameters: client_id, client_secret, access_token, refresh_token, and expires_at. You should already have all values from Spotify, except of expires_at. Set it to any date in the past

Name new secret and on the next step disable automatic rotation.

Automatic rotation enables the ability to schedule lambda invocations to refresh tokens. Spotify refresh tokens are valid forever until they are manually revoked. So in this case we can disable automatic rotation. But if you are integrating with a service providing expiring refresh tokens, this feature can be extremely useful.

After you created a secret, notice the sample code section, we will need it in the next step.

We are done here, we are moving to our lambda function next

AWS Lambda. Function

I’m most comfortable writing code in Ruby, so the next example will be on it :)

But you can choose anything from what Lambda offers -Java, Javascript, Go, Python, C#

Here is the ruby code for our Lambda function

Time to deploy and test!

AWS SDK for Ruby doesn’t include httparty gem, so we need to do a bit of extra work. It is possible to use standard Net::HTTP ruby library, but you know, these HTTP gems exist for a reason :D

This step is relevant to all languages if you have dependencies that are not included in AWS SDK.

AWS Lambda. Layer.

Lambda layers allow us to use libraries that are not included or run custom runtimes. With layers, we don’t need to include dependencies in the deployment package, which keeps it small.

First, we need to create a Gemfile with our dependencies on the local machine

cd your-directory
echo "source 'https://rubygems.org'
gem 'httparty'" >> Gemfile

Next, with help of Docker, we simulate a lambda environment to create a layer. More info here

docker run --rm -it -v $PWD:/var/gem_build -w /var/gem_build lambci/lambda:build-ruby2.7 bundle install --path=.

And the final step is to zip our created folder and publish it as a layer

zip -r gems.zip ./ruby/ -x ./ruby/2.7.0/cache/\*
aws lambda publish-layer-version \
         --layer-name gems\
         --region ap-southeast-1 \
         --compatible-runtimes ruby2.7 \
         --zip-file fileb://gems.zip

After this, you can click on the “Add a Layer” button and select the newly added layer from Custom Layers.

Layers are extracted to the /opt directory in the function execution environment. Each runtime looks for libraries in a different location under /opt, depending on the language. Structure your layer so that function code can access libraries without additional configuration.

Based on this, we need to set GEM_PATH as /opt/ruby/2.7.0/ in environmental variables:

AWS Lambda. Permissions

Before testing our function, we need to add Lambda permission to access Secret Manager

Go to Services > IAM > Policies > Create Policy

And create a policy with the next parameters:

Under resources specify ARN of Spotify secret stored in Secret Manager.

After that, navigate to Roles and click on yourLambdaName-role-xxxxx.

Click on the “Attach policies” and find SpotifySecretPolicy that we just created

Now we can finally test our lambda :D

We are almost there, now we need to make our lambda accessible through API.

AWS API Gateway

In the “Designer” tab click ton “Add trigger” button and select API Gateway with the next parameters:

Go to Resources and by clicking on the Actions button add the GET method, with Lambda function as an integration type, and don’t forget to pick your lambda from the dropdown below.

In the Resources navigation pane, choose Actions. From the Actions drop-down menu, choose Deploy API.

The last step — add permissions to lambda to be invoked by API.

Run this command on your local machine:

Replace arn:aws:execute-api:region:account-id:api-id/*/GET/lambdasv1 with the ARN of the API Gateway resource that invokes your function.

aws lambda add-permission --function-name my-function \
--statement-id api-gateway-invoke --action lambda:InvokeFunction \
--principal apigateway.amazonaws.com \
--source-arn "arn:aws:execute-api:region:account-id:api-id/*/GET/lambdasv1"

Return back to the API Gateway section. In the Stages navigation pane, click on the GET method and you will see the invoke URL highlighted in blue, click on it, and ta-da!

You’ve got your Spotify stats returned by AWS API, clap-clap!

Now let’s discuss the most interesting information — the cost :D

Cost Estimation

Since this API is built for a personal website, I assume there will be humble 1000 requests per month.

The prices listed are for the Singapore region. Lambda function runs 300ms on average and has 128 MB allocated memory.

As you can see, all the cost is based on the Secret manager price and it costs you less than 5 USD per year! Price of 1 big chicken shawarma in Malaysia (estimations in chicken shawarmas feel more tangible :D)

In the next post, I’m going to show how to protect your API from DDoS attacks, because the cost of an unprotected API can be unpredictable.

I hope I didn’t miss anything out and this noob-friendly guide was useful for you :)