Description of project and tasks

This module is 3 hours - Serverless Architecture.

The goal of this project is to deploy an online concert ticket sales web application organized by Sound
Wave Production promoter. You are required to deploy the front-end application and implement a
serverless architecture on the backend side in accordance with the system design created by the
development team. You must also apply a serverless architecture that is reliable, secure,
highperforming, and cost-efficient.

Task
1. Read the documentation thoroughly (Outlined below).
2. Please read and understand the application architecture in the Architecture section.
3. Please carefully read the technical details section.
4. Please carefully read the application details.
5. Log in to the AWS console.
6. Set up your VPC configurations. The VPC configuration details are in the Network Architecture -
Service Details section.
7. Set up relational database and non relational database. You can read more in Database – Service
Details and DynamoDB – Service Details section.
8. Set up a security group. You can read security additional rules in Security – Service Details section.
9. Implement decoupled architecture. You can read more detail in SQS – Service Details section.
10. Set up the Lambda Function to perform serverless architecture. You can read more in Lambda –
Service Details section.
11. Set up the API Endpoint and Websocket. You can read more in API Gateway – Service Details
section.
12. Prepare the IAM and SSM Parameter Store to provide access and configuration for the application.
13. Prepare and install Front-end application.
14. Configure necessary application monitoring and metrics in CloudWatch.

Technical Details
1. The goal of this project is to deploy the serverless application that has been developed until it runs
successfully.
2. All your service must be place in region us-west-2.
3. All services needed in this project can assume the LabRole IAM role.
4. All the necessary resource source code is available on GitHub at
https://github.com/handipradana/lks-serverless.git.
5. This project places a strong emphasis on high-level security to safeguard sensitive data and
mitigate potential threats effectively.
6. Every service you have created must use the "lks-" naming format (e.g., "lks-allow-http," "lksauth,"
"lks-apiGateway," etc.). The judges will only consider work that follows this recommended naming
format.
7. Ensure that you label each AWS service you create, except for those that were automatically
generated. Paying attention to these details will contribute to earning more points.
8. Remember to fill in each description and tag of the services.
9. Remove unnecessary service items, keep your work clean for easy assessment by the judge, and
avoid potential point deductions.
10. The programming language utilized in this project is JavaScript, using the NodeJS version 16
runtime.

Architecture

The above example illustrates one possible architectural design for the Concert Ticket Application. This
is not the final architecture that you may follow. This architecture shows the design system built by the
application development team to make it easier to comprehend how the application operates. Please
read the Application detail.

Application Details
In this project, you will deploy a web application for concert tickets that implements a serverless
architecture on the backend. You are required to deploy the frontend with backend serverless
applications until they are running and can be used properly.
The frontend and backend are separated into different projects. The developer team has developed
the frontend application using Vue.js version 3 as the JavaScript framework. You can deploy the
frontend application using the AWS Amplify service.
The backend application has already been developed to supports a serverless architecture with lambda
functions. All lambda functions needed for the backend application are already available. You may only
need to write a few lines of your own lambda function code according to the architecture
requirements. The architecture diagram is provided in the Architecture section. The source code you
can access from the repository

Service Details
Networking (VPC)
Although this is a serverless application, in this case, you still need to build network infrastructure for
the database tier and front-end. You must create a VPC in the specified region with CIDR 15.32.0.0/16.
You are required to create 2 public subnets and 4 private subnets in just 2 Availability Zone, Each subnet
requires only 200 IP addresses. If you need to link a private subnet to another AWS service, choose the
most cost-effective option.

Security
Security is the most important aspect to consider when building a serverless architecture. In this case,
you are required to secure the API gateway from public access, make sure your API is private and just
can be access from front-end application. You are also required to secure the RDS database, ensure
that the RDS can only be accessed by lambda functions that require a connection to the database and
ensure that the database cannot be accessed publicly, you also need to consider the security of other
services used in this project. Use exist AWS IAM to provide policies that meet all your service needs in
this project.

SSM Parameter Store

Every lambda function in this project that performs CRUD (Create Read Update Delete) operations on
AWS RDS will retrieve database configuration data from the SSM Parameter Store using the path
/lks/database/{{KEY}}. The key must be the same as the name of the required database configuration.
The following keys must be created in the parameter store:
Key Type Description
dbname String Database name
username String Database username
password SecureString Database password
endpoint String Database host endpoint

Relational Database
In this project, the backend application uses the RDS service as its primary database. Create a database
with PostgresQL as the engine type that supports this backend application. The database settings can
be found in the connection.js file in the service folder at the provided source code. Setup username,
password and initial database name that are required for backend and store to SSM Parameter store,
please read SSM Parameter service details. The database must be configured to be highly available,
scalable, and secure.

DynamoDB
A custom authorizer will be used in this serverless architecture to manage authorization security in API
Gateway by evaluating the permitted token and deviceid data. In DynamoDB, create a table called
"tokens" with the partition key "token" (S) and the sort key "deviceid" (S). Then, for RCU and WCU,
configure the token table to utilize provisioned mode with auto scaling enabled. Set the tokens RCU
min to 10 and max to 100 with an 70% utilization target. Also, set the tokens WCU min to 5 and max
to 25 with an 70% utilization target.

Object Storage (S3)

Object storage is required in this project to store payment transaction evidence that will be handled
by the payment system. Create an S3 bucket with the name "lks-YourName-YourProvince" in the format
" lks-YourName-YourProvince " and a folder called "proofOfPayment" within it. This folder will hold all
payment transaction evidence. Payment transaction proof data that has not been accessed in 6 months
will be put to Glacier Deep Archive automatically and will be deleted automatically after 1 year. When
a put data action is performed on a bucket in the proofOfPayment folder, the file metadata is saved in
SQS for processing by the payment lambda function.

Lambda Function
The detailed configuration for the lambda function can be found in the documentation of the source
code repository. Please make sure to follow lambda name from lambda setup table in github
repository.

API Gateway
API Gateway is a critical component of this project. You must carefully create API endpoints that adhere
to the architecture design of this project. Two types of API Gateway will be used in this project REST
API and Websocket API. The following is the API Gateway configurations required for this project.
1. REST API
The REST API must be accessible from frontend with a custom authorizer named lks-auth. The
authorizer invokes a Lambda function that contains the auth.js file. The authorizer is configured to use
the Authorization header and Deviceid as the identity source. The API Gateway will also accept file
uploads in base64 format. Use production as a stage name and perform caching. The following is a
table of REST API endpoints required:
Resource Method Authorizer CORS Service Type Execution
/token POST AWS IAM No Lambda lks-token
/event GET lks-auth Yes Lambda lks-read-event
/event POST,PUT lks-auth Yes Lambda lks-write-event
/event/{id} DELETE lks-auth Yes Lambda lks-write-event
/ticket POST, DELETE lks-auth Yes Lambda lks-ticket
/ticket/{id} DELETE lks-auth Yes Lambda lks-ticket
/order GET lks-auth Yes Lambda lks-read-order
/order POST lks-auth Yes Lambda lks-queue-order
/payment/{filename} PUT lks-auth Yes S3 Read SQS Section
For resource /payment/{filename} you need choose AWS service in interagion type and S3 as AWS
Service, Http Method is put
You may need some additional information for resource /payment/{filename}. This is some information
requirement when you create /payment/{filename} resource:
• Follow instruction for method and integration type from the API Table.
• You need to fill Path Override to “lks-app-2025/profOfPayment/{filename}”.
• Execution Role is use LabRole ARN, you can find the arn in AWS IAM in role section for LabRole.
• Add URL Path parameters name “filename” with Mapped from “method.request.path.filename”.
When every endpoint of the API is done creating. The first step you will need is to generate a token, by
accessing /token endpoint with the post method provide body parameters as explained in the API
Documentation. Also, you have to utilize AWS Signature for the authentication endpoint /token with
AccessKey, SecretKey and SessionToken to which is provided by AWS Detail Labs Academy. The /token
endpoint actions can illustrate through the API documentation. You may test the API Endpoint by going
to the API documentation at this link.
Note: You may need to enable CORS with Access-Control-Allow-Origin to * (all) and Access-Control-Allow-Headers has
Authorization and deviceid.

2. WebsocketAPI
The websocket in this project is used to provide asynchronous responses to the front-end when
messages on SQS have been successfully processed by the lambda consumer. The websocket has six
routes: $connect, $disconnect, $default, sendMessage, getConnectionId, and broadcastMessage. The
route selection expression for each route is $request.body.action. Each route invokes the lambda
function that contains the websocket.js file. Don’t forget to use prod stage as a production stage name.

Simple Queue Service (SQS)

In this project, you will implement a decoupled architecture using AWS SQS. Amazon Simple Queue
Service will be used to store every request from API Gateway when creating an order, and to store
metadata uploaded to S3 before being processed by payment. Every queue is processed sequentially.
Create 2 SQS with the following specifications:

1. Create an SQS named "lks-queue-order" to store data from API Gateway when creating an order.
This queue is used to handle ticket order queues in the order of order. Configure the SQS with high
throughput, a maximum message size of 256Kb, a visibility timeout of 30 seconds, a receive
message timeout of 5 seconds, and a message retention period of 4 days. Configure an event
consumer trigger for a lambda function that contains the writeOrder.js file. Apply a dead letter
queue to handle failed messages.
2. Create an SQS named "lks-queue-payment" to store metadata received from S3.This queue is used
to process all incoming transaction data. Configure the SQS with high throughput, a maximum
message size of 256Kb, a visibility timeout of 30 seconds, a receive message timeout of 10 seconds,
and a message retention period of 2 days. Configure an event consumer trigger for a lambda
function that contains the payment.js file. Apply a dead letter queue to handle failed messages.