COS20019 – Cloud Computing Architecture

Assignment 3
Serverless/Event-driven Architecture Design Report

Abstract design can be provided.

Cloud computing has gained increasingly 2. Business Scenario

popularity for developing online architecture.
Platform like Amazon Web Service allows The Photo Album application has experienced tremendous
developers to leverage managed services that success and requires further development to meet the
handle the underlying infrastructure, allowing increasing demand. The following requirements and
them to focus on application logic rather than problem have been identified and measures have to be
server, networking equipment , and system taken to leverage these matters so as to provide the
configuration. This paper will propose a design customers with the best experience:
and implementation for a serverless/event- 2.1 Infrastructure management:
driven architecture to improve the performance
and efficiency of a business based on their • Use managed cloud services to minimize in-house
scenario. The paper will leverage AWS Lambda, system administration and storage.
API Gateway, DynamoDB, SQS and other AWS
services. Apart from proposing an architecture 2.2 Scalability:
design, the paper will also discuss the design
• Design architecture have to cope with expected
rationale regarding the design and justification
growth.
for such design. Finally, the paper will look
through some noticeable alternative regarding • Adopt a serverless/event-driven solution.
the proposed architecture.
2.3 Database optimization:
Keywords: Cloud computing, AWS,
Serverless/Event-driven, business scenario, • Explore cost-effective options for the relational
.rationale design. database.

1. Introduction 2.4 Cross-region performance:

Digital technologies play an increasingly important • Improve global responses times.

role in every operation of business nowadays.
2.5 Media processing evolution and optimization
Cloud computing has developed to provide both
business owner and the developer with a new tool • Handle video media in the future.
to establish business foothold online. Cloud
computing has revolutionized the way business • Automatically produce various media versions upon
approach online architecture, providing a cost- media upload.
effective and efficient solution for managing
infrastructure. It has shortened the gap between • Ensure extensible architecture for media processing.
creating and managing a website on-premises and
in the cloud, offering a more worriless web • Ensure the architecture is effectively decoupled to
operating experience. Furthermore, the avoid overloading.
independence nature of AWS’s services has created The following design will address the above requirement
the opportunity for serverless/event-driven and further discussion will justify the effectiveness as well
approach to increase efficiency and flexibility of as the performance of the design.
web operation.
This paper proposes a serverless/event-driven
architecture design and implementation using AWS
services, aimed at improving the performance and
efficiency of a business based on their specific
scenario. Therefore, the business scenario of the
company should be thoroughly examined before the
 3. AWS Architecture Diagram

Figure 1: AWS Architecture Diagram

This diagram can be divided further into 4 smaller a well-regarded identity on the internet using a well-suited
parts so as to provide a better explanation and Domain Name Server.
operation of the architecture.
In addition, our website can utilize a Cloud-based media
3.1 AWS Content Delivery System streaming service similar to that of Google Drive for video
and image content. This entails the use of AWS
The ever-growing popularity of the website require CloudFront to provide media to users via the nearest edge
an equally efficient content delivery system so as to location. In instances where the media is not available in
provide the best experience for the user as well as the CloudFront cache, the service will issue a request to
upkeeping a competitive edge over the competitors. our web server to retrieve the designated media. This
This can be achieved using AWS DNS resolution approach ensures fast and efficient delivery of content to
such as AWS Route 53 and AWS Content Delivery users, improving their overall experience on our website.
Service such as AWS CloudFront:

3.2 AWS Serverless Three-Tier Architecture

The most widely used implementation of a multi-tier
architecture is the three-tier architecture, which is
composed of three distinct layers: the presentation tier,
logic tier, and data tier.

Figure 2: AWS Content Delivery System

There are two methods by which the user may user
the website’s services, the user can browse our
website via a Domain Name Server after which,
they will be routed to our website hosted on AWS
Amplify with the help of Route 53. AWS Route is
an amazing service for business owners to maintain. Figure 3: AWS Serverless Three-Tier Architecture
In the above architecture, static web content is stored information, see Appendix A.
on Amazon S3 and hosted on Amazon Amplify,
which will make up of our presentation tier. The To provide an overview of the architecture’s function and
logic tier consists of API Gateway and Lambda feature, see the UML diagram of the architecture at
functions to provide dynamic content for our Appendix B.
website. Finally, the data tier will utilize AWS 4. Design Rationale
DynamoDB as our persistent storage. Various users’
request can be supplemented with this architecture: Having completed our discussion on the AWS architecture,
we can proceed to examine how this design is capable of
satisfying the pain points that have been identified in the
business scenario described above. Further discussion
above alternative solution and design criteria will also be
included.
4.1 Alternative design
There are two versions of the AWS architecture that was
created during the architecture building phase; the original
architecture (Appendix C) used more simple AWS
services; however, it is fundamentally more complex than
the alternative, which is the currently used architecture.
Figure 4: Web architecture UML Diagram
Viewing and Uploading media.
Using a serverless three-tier architecture on AWS
Users who want to view media in the initial architecture
offer several key advantages, including high
will be routed via CloudFront to an EC2 instance that hosts
availability, reliability, and flexibility for future
the website; the website is in a private subnet, so it is only
scalability and evolution.
visible to the user via a NAT gateway.
3.3 Reliable Fanout Architecture
Fanout architecture is a common design pattern in
AWS that allows for efficient distribution of data to
multiple downstream services or systems.

Figure 6: View Website on instance

In the second architecture, the user will access the website
with its source code stored in the S3 Bucket via AWS
Amplify. The process of the second architecture is more
straightforward than that of the first one, as there is no
need for instances or gateways; this also reinforces the high
availability advantage of this architecture.

Figure 5: Fanout Architecture

This architecture involves using an event-driven
approach where a single event is triggered and then
distributed to multiple recipients. Particularly, in
this system, this is achieved using Amazon SNS,
AWS SQS, and AWS Lambda.
API calls from previous process will trigger AWS
SNS to publish messages to a topic, AWS SQS is
Figure 7: Website on AWS Amplify
then used to queue messages, and AWS Lambda is
used to process the messages. This architecture As per the process of uploading media to the website, the
allows for decoupling of application components, initial design sends the original media to the S3 bucket,
scalability, and reliability. which triggers the step function to process the media and
send the processed media back to the bucket. As the media
3.4 Media Processing Steps
is uploaded into the bucket, its metadata will then be sent
Finally, after being queued for processing, the to the database; the same is true for metadata that the AWS
media will be sent to a Media Processing Steps by Transcoder processes.
AWS SQS and a Step Function will be provoked to
handle this processing procedure. For more
 Performance

Figure 8: Process upload media

The process for uploading is somewhat different in
the second alteration; as the media passes through
AWS Amplify, it will trigger API to send a put Table 1: Performance criteria
request to the ServiceCategorizer, and the
categorizer will send the media to the Reliable Scalability
Fanout process that handles the media’s type.

Figure 9: Decouple media.

VPC vs. Serverless three-tier architecture
The serverless three-tier architecture is chosen
for its ease of management, as AWS will Table 2: Scalability criteria
automatically do some of the management, like
scaling and ensuring security. In a VPC like Reliability
the original architecture, even though there is
an auto-scaling group, the admin must watch
for the instances and the bastion host, as they
might need to be updated. With the serverless
architecture, however, AWS Amplify will be
the one to do all the scaling; this gives the
admin much more time to improve and ensure
performance, rather than spending much time Table 3: Reliability criteria
monitoring scaling. Security

Security is also a hassle within the VPC

environment; each item in the original VPC
must be configured as a security group or
NACL by the admin manually, which can be
frustrating and challenging to figure out. For
the architecture in use, however, AWS
Amplify will provide security through
authentication, authorization, and data Table 4: Security
encryption, giving it an edge over VPC-based
applications. Additional security is granted via
the IAM role.
It is important to note that the serverless three-tier
architecture has limitations regarding infrastructure;
however, it is not the primary concern so it can be
negligible.
4.2 Design Criteria
After careful consideration of services provided by
AWS, the following tables will discuss the design
criteria for each pillar of well-architecture
framework.
 Cost architecture for the business, the use of DynamoDB, which
is a fully managed NoSQL database service, will ensure
According to the provided information, the demand automatic scaling of resources based on spike and decline
for the application has been doubling every 6 of visit. Meaning that application can adapt to scalability
months, and it will continue to grow under that and inflexibility. The serverless nature of DynamoDB will
trend for the next 2 or 3 years. To predict how also be a cost-effective solution to our architecture, as
much it will cost to run the website in the future, DynamoDB will charge based on the amount of data stored
cost summaries for total media upload sizes at and the throughput consumed according to the application.
50GB, 100GB and 200GB are shown below: The replication of data across multiple availability zone of
The total cost of operation for the architecture for DynamoDB will also ensure the best user experience and
50GB will be $124.54182. This cost has included ease of operating for the business owner. AWS RDS, on
the Content Delivery Network, Web architecture, the other hand, requires manual scaling and maintenance of
and the media processing procedure. Detailed cost resources.
of each feature can be view via Appendix D. Therefore, the use of DynamoDB instead of RDS provides
Similarly, the forecast for 100GB and 200GB in the a cost-effective, scalable, and highly available database
upcoming year would be $308.88364 and solution for our web application.
$744.38528 respectively. For more information, see d) Cross-region performance
Appendix E and Appendix F.
As the popularity and service reliability of the website
4.3 Fulfillment of the business scenario continue to grow inland and offshore Australia, the need
requirements and justification for designed for catering the user experience of offshore customers is
architecture also required.
a) Infrastructure management In the proposed architecture, the use of AWS CloudFront
The architecture utilizes AWS managed cloud and AWS Amplify can significantly improve cross-region
services, such as AWS S3, AWS Amplify, AWS performance for our business requirements. The content
CloudFront, AWS DynamoDB, and AWS Lambda delivery network that caches and delivers content from the
to minimize the need for in-house system closest location to the user by using CloudFront ensure
administration and storage. Security and minimized latency and faster content delivery for our users.
Monitoring services provided by AWS also play an AWS Amplify, furthermore, is integrated with AWS
important role in easing the burden of business CloudFront, as the static assets and contents are
owners allowing them to focus on other aspects of automatically distributed by AWS CloudFront. Therefore,
the business. Overall, the architecture’s use of the use of these services will ensure that our web
managed cloud services can bring significant application can handle cross-region traffic without any
improvements in scalability, reliability, and cost- issue, leading to greater user satisfaction, improved
effectiveness, solving the pain point for business outcomes and an “edge” advantage against our
infrastructure management. competitor.

b) Scalability e) Media Processing evolution and optimization

With the constant growth of the website biannually, As the size of our website developed, so does its features to
the proposed architecture above is designed to maintain a competitive advantage in the market as well as
address the need to cope with expected growth by preserving and upholding the visitor retention rate. The
adopting a serverless/event-driven solution. proposed architecture aims to optimize the current features
as well as revolutionize the procedure of which media are
This is done via adopting various managed cloud being processed.
services, such as AWS Lambda functions, which
can automatically scale up or down based on the Specifically, the fanout architecture is a distributed
incoming traffic. Accordingly, the used of AWS S3 computing pattern that is built to efficiently process large
to store static web content and AWS DynamoDB as volumes of data in parallel, allowing for media processing
a persistent storage solution ensures that the web tasks to be distributed across multiple processing nodes.
application can handle a high volume of request This will allow our architecture to scale up or down based
without any decrease in performance. on the current demand.

In addition, the event-driven approach of the The proposed media processing procedure is a
architecture using AWS SNS, AWS SQS ,and AWS serverless/event-driven approach that utilized AWS
Lambda, ensures that the application components Lambda functions to automatically process media files
are decoupled, which in turns will increase the upon upload. This will ensure that media files are
scalability and reliability of the architecture. automatically processed without any manual intervention.
This process can easily scale depend on the spike and
Overall, this approach allows the architecture to decline of the time. Furthermore, the procedure is create
handle expected spike and decline in traffic without decoupled to guarantee reusability and feature evolution.
requiring on-premises system administration. Meaning that, should new business requirements arise, new
features and additional services can be added to this
c) Database optimization procedure without worrying about interfering with the
existing functions.
Instead of previous use of AWS RDS in the old
 The improvement is brought about using fanout [6] Y. Sharma, "Publish-Subscribe/Fan-out Pattern in
architecture and new media processing procedure Serverless Architectures using SNS, SQS and
ensure significant improvement in scalability, Lambda," Medium, June 22, 2018. [Online].
reliability, and reusability to the web application. Available: https://medium.com/aws-lambda-
5. Conclusion serverless-developer-guide-with-hands/publish-
subscribe-fan-out-pattern-in-serverless-architectures-
In conclusion, a serverless/event-driven architecture using-sns-sqs-and-lambda-bccaa3abac9e . [Accessed:
on AWS can greatly benefit business that require April 9, 2023].
scalable and cost-effective solution. AWS services
such as AWS Lambda, Amazon SNS, and Amazon
SQS can respond to real-time events without the [7] "Video on Demand - AWS Solutions," Amazon
need of manual management, allowing the business Web Services, Inc. [Online]. Available:
owner to pay more resources on bringing business https://www.amazonaws.cn/en/solutions/video-on-
value to the customers. demand/ . [Accessed: April 9, 2023].

Reference
[1] “What is a Content Delivery Network
(CDN)? – Amazon Web Services,” Amazon
Web Services, Inc., 2021. [Online]. Available:
https://aws.amazon.com/what-is/cdn/ .
[Accessed: April 9, 2023].

[2] A. Xu, "System Design Interview: An

Insider's Guide," v. 1, System Design Interview:
An Insider's Guide, Independently Published,
2020, ISBN: 9798664653403. [Online].
Available:
https://books.google.com.vn/books?id=TZWmz
QEACAAJ . [Accessed: April 9, 2023].

[3] "Introduction - Amazon CloudFront Developer

Guide," Amazon Web Services, Inc. [Online].
Available:
https://docs.aws.amazon.com/AmazonCloudFront/lat
est/DeveloperGuide/Introduction.html . [Accessed:
April 9, 2023].

[4] "Serverless Logic Tier - Build a Serverless

Web Application," Amazon Web Services, Inc.
[Online]. Available:
https://docs.aws.amazon.com/whitepapers/latest
/serverless-multi-tier-architectures-api-gateway-
lambda/serverless-logic-tier.html . [Accessed:
April 9, 2023].

[5] "QSRsoft Launches Digital Huddle Board in

3 Months with AWS Serverless and Fire
Devices," Amazon Web Services, Inc., October
22, 2020. [Online]. Available:
https://aws.amazon.com/blogs/architecture/qsrs
oft-launches-digital-huddle-board-in-3-months-
with-aws-serverless-and-fire-devices/ .
[Accessed: April 9, 2023].
 Appendix A: Media Processing Step Procedure

Figure 10: Media Processing Step Procedure

In this procedure, SQS queue will invoke a step function that will start by using AWS Lambda function to create
thumbnail for the uploaded media and store it alongside with its original media into the original media folder in S3. The
second step is performed by another Lambda function that prepares the media file for the transcoding process. This could
involve checking the available formats that the website can transcode and generating metadata for the transcoded file.
After that, Elastic Transcoder will transcode the media into designated format and finally send it to the publishing
lambda function. Our process will end by storing the transcoded media into TranscodedMedia folder in S3 and store the
metadata of the transcoded media into DynamoDB.
This processing procedure is highly reusable and flexible, allowing for the addition of new processing steps or the
modification of existing ones to meet changing requirements. Suppose we want to implement AI detection into our
processing Step, simply add another Lambda function into the existing step wherever needed.

Figure 11: Alternative Media Processing Step Procedure

Additional services and steps may be needed for additional features; however, it can be added into this procedure with
ease. Allowing our website reusability and flexibility with little overhead burden on existing featur
 Appendix B: UML Diagrams for the function and features of the architecture

a. Viewing UML

Figure 12: User view website

Users who browse the website will be routed to the nearest edge location via CloudFront, and AWS Amplify
will display the website and some media stored in the bucket. The process differs a bit for viewing uploaded
media as the user will be routed to CloudFront through Route 53 first. AWS Amplify will send a request to
get the metadata for a specific media type to the API Gateway; the API then send a request to get the
metadata requested from the database via the help of the Categorizer function.
b. Uploading UML

Figure 13: User Uploading file

When the user wants to upload a piece of media, the media will be sent through Route 53 and CloudFront to AWS
Amplify, and then AWS Amplify issue an upload request to API, which will trigger the PUT method. The media
coming out of the API will then be sent to the Service Categorizer function, where it will be assigned a topic based on
its media type (i.e. image_topic, video_topic, etc.). The topic will let AWS SNS knows where the media should go, and
then AWS SNS sends the media towards AWS SQS to queue for processing. From that point, the original media, as
well as its thumbnail, will be uploaded on S3 because of the create thumbnail function, then the media is transcoded
with AET, and the metadata will be produced; the transcoded media will then be sent to S3 again while its metadata will
be stored in the DynamoDB database.
 Appendix C: Initial version of the architecture

Figure 14: Traditional Web Architecture

Appendix D: Detailed cost of operation for 50GB of media upload

Services Cost of each feature Total
• Write Request Unit (WRU): Each WRU = 1
write operation for 1 item with size up to 1kB. 50
x 10242 / 1000000 x $1.25 = $65.536
• Read Request Unit (RRU): Each RRU = 1 read
DynamoDB operation for 1 item with size up to 4kB. $65.536 + $3.2768 + $6.25 =
50 x 10242 / 1000000 / 4 x $0.25 = $3.2768 $75.0628
• Data Storage (per month): 25 x 0 + 25 x $0.25 =
$6.25
• Data Transfer IN: $0
• Data Transfer OUT (per month): $0
Assume all the media uploaded are images and each
image’s size is 150kB.
• Hosted zone (per month): $0.50
Route 53 • Standard Queries (per month): 50 x 10242 / 150 / $0.50 + $0.14 = $0.64
1000000 x $0.40 = $0.14

Assume the price in Australia is the average price.

• Data Transfer Out (per month): $0.114 x 50 =
$5.7 Up to $5.7 + $1.31072=
CloudFront
• Assume that the average size of images uploaded $7.01072
to the website is 150kB, and all the media
uploaded are images. Assume that each image
 will be associated with 3 HTTPS requests. The
price for HTTPS requests will be up to: 50 x
10242 / 150 / 10000 x 3 x $0.0125 = $1.31072
• S3 Standard - Infrequent Access: $0.0125 x 50 =
$0.625
S3 • Data Transfer IN: $0 $0.625 + $4.5 = $5.125
• Data Transfer OUT (per month): $0.09 x 50 =
$4.5
Amplify It’s free for the first 12 months, so the cost here is $0. $0
Assume all the media uploaded are images and each
image’s size is 150kB.
API Gateway $1.2233
• API Calls (per month): Up to: 50 x 10242 / 150 /
1000000 x $3.50 = $1.2233
The endpoint is Simple Queue Service (SQS), so it is free
SNS $0
for using SNS.
Assume all the media uploaded are images and each
image’s size is 150kB.
• FIFO Queues (per month): $0
SQS $4.5
• Data Transfer IN: $0
• Data Transfer OUT (per month): $0.09 x 50 =
$4.5
• Assume all of 50GB is used for uploading video,
Elastic and all of them are 720p videos, their length will
Up to $6
Transcoder be about 200 minutes. The cost for Elastic
Transcoder will be up to $0.03 x 200 = $6
Assume all the media uploaded are images and each
image’s size is 150kB; assume that each image is
associated with 4 requests.
Lambda • Requests: 50 x 10242 / 150 / 1000000 x 4 x $0.20 $0.28 + $5.5 = $5.78
= $0.28
• Memory: $5.5

There are 8 Lambda function. Assume each of them is

CloudWatch associated with 8 metrics. $19.2
• Metrics (per month): 8 x 8 x 0.3$ = $19.2
Total $124.54182

Table 5: Cost of operation for 50GB

Appendix E: Detailed cost of operation for 100GB of media upload
Services Cost of each feature Total
• Write Request Unit (WRU): Each WRU = 1
write operation for 1 item with size up to 1kB.
100 x 10242 / 1000000 x $1.25 = $131.072
• Read Request Unit (RRU): Each RRU = 1 read
operation for 1 item with size up to 4kB.
DynamoDB $131.072 + $6.5536 + $93.75
100 x 10242 / 1000000 / 4 x $0.25 = 6.5536
= $231.3756
• Data Storage (per month): Up to now, the total of
data is about: 50 x 6 + 100 = 400 GB.
25 x $0 + 375 x $0.25 = $93.75
• Data Transfer IN: $0
• Data Transfer OUT (per month): $0
Assume all the media uploaded are images and each
Route 53 image’s size is 150kB. $0.50 + $0.28 = $0.78
• Hosted zone (per month): $0.50
 • Standard Queries (per month): 100 x 10242 / 150
/ 1000000 x $0.40 = $0.28

Assume the price in Australia is the average price.

• Data Transfer Out (per month): $0.114 x 100 =
$11.4
• Assume that the average size of images uploaded
CloudFront to the website is 150kB, and all the media
uploaded are images. Assume that each image Up to $11.4 + $2.62144 =
will be associated with 3 HTTPS requests. The $14.02144
price for HTTPS requests will be up to: 100 x
10242 / 150 / 10000 x 3 x $0.0125 = $2.62144
• S3 Standard - Infrequent Access: $0.0125 x (50 x
6 + 100) = $5
S3 • Data Transfer IN: $0 $5 + $9 = $14
• Data Transfer OUT (per month): $0.09 x 100 =
$9
Amplify It’s free for the first 12 months, so the cost here is $0. $0
Assume all the media uploaded are images and each
image’s size is 150kB.
API Gateway $2.4466
• API Calls (per month): Up to: 100 x 10242 / 150 /
1000000 x $3.50 = $2.4466
The endpoint is Simple Queue Service (SQS), so it is free
SNS $0
for using SNS.
Assume all the media uploaded are images and each
image’s size is 150kB.
• FIFO Queues (per month): $0
SQS $9
• Data Transfer IN: $0
• Data Transfer OUT (per month): $0.09 x 100 =
$9
• Assume all of 100GB is used for uploading
video, and all of them are 720p videos, their
Elastic
length will be about 400 minutes. The cost for Up to $12
Transcoder
Elastic Transcoder will be up to $0.03 x 400 =
$12
Assume all the media uploaded are images and each
image’s size is 150kB; assume that each image is
associated with 4 requests.
Lambda • Requests: 100 x 10242 / 150 / 1000000 x 4 x $0.56 + $5.5 = $6.06
$0.20 = $0.56
• Memory: $5.5

There are 8 Lambda function. Assume each of them is

CloudWatch associated with 8 metrics. $19.2
• Metrics (per month): 8 x 8 x 0.3$ = $19.2
Total $308.88364

Table 6: Cost of operation for 100GB

 Appendix F: Detailed cost of operation for 200GB of media upload
Services Cost of each feature Total
• Write Request Unit (WRU): Each WRU = 1
write operation for 1 item with size up to 1kB.
200 x 10242 / 1000000 x $1.25 = $262.144
• Read Request Unit (RRU): Each RRU = 1 read
operation for 1 item with size up to 4kB.
DynamoDB $262.144+ $13.1072 +
200 x 10242 / 1000000 / 4 x $0.25 = 13.1072
$268.75 = $544.0012
• Data Storage (per month): Up to now, the total of
data is about: 50 x 6 + 100 x 6 + 200 = 1100 GB.
25 x $0 + 1075 x $0.25 = $268.75
• Data Transfer IN: $0
• Data Transfer OUT (per month): $0
Assume all the media uploaded are images and each
image’s size is 150kB.
• Hosted zone (per month): $0.50
Route 53 • Standard Queries (per month): 200 x 10242 / 150 $0.50 + $0.56 = $1.06
/ 1000000 x $0.40 = $0.56

Assume the price in Australia is the average price.

• Data Transfer Out (per month): $0.114 x 200 =
$22.8
• Assume that the average size of images uploaded
CloudFront to the website is 150kB, and all the media
uploaded are images. Assume that each image
Up to $22.8 + $5.24288 =
will be associated with 3 HTTPS requests. The $28.04288
price for HTTPS requests will be up to: 200 x
10242 / 150 / 10000 x 3 x $0.0125 = $5.24288
• S3 Standard - Infrequent Access: $0.0125 x (50 x
6 + 100 x 6 + 200) = $13.75
S3 • Data Transfer IN: $0 $13.75 + $18 = $31.75
• Data Transfer OUT (per month): $0.09 x 200 =
$18
Assume web app size = 100MB, average size of page
requested = 1.5 MB
Assume that average build time = 3 minutes each day.
Assume that daily active users = 10000.
Amplify $0.9 + $65.918 = $66.818
• Build & Deploy: 3 x 30 x 0.01 = $0.9
• Data storage: 100 / 1024 x $0.023 = $0.00225
• Data Transfer Out: 10000 x (1.5 / 1024) x 30 x
$0.15 = $65.918
Assume all the media uploaded are images and each
image’s size is 150kB.
API Gateway $4.8932
• API Calls (per month): Up to: 200 x 10242 / 150 /
1000000 x $3.50 = $4.8932
The endpoint is Simple Queue Service (SQS), so it is free
SNS $0
for using SNS.
Assume all the media uploaded are images and each
image’s size is 150kB.
• FIFO Queues (per month): $0
SQS $18
• Data Transfer IN: $0
• Data Transfer OUT (per month): $0.09 x 200 =
$18
• Assume all of 200GB is used for uploading
Elastic
video, and all of them are 720p videos, their Up to $24
Transcoder
length will be about 800 minutes. The cost for
 Elastic Transcoder will be up to $0.03 x 800 =
$24
Assume all the media uploaded are images and each
image’s size is 150kB; assume that each image is
associated with 4 requests.
Lambda • Requests: 200 x 10242 / 150 / 1000000 x 4 x $1.12 + $5.5 = $6.62
$0.20 = $1.12
• Memory: $5.5

There are 8 Lambda function. Assume each of them is

CloudWatch associated with 8 metrics. $19.2
• Metrics (per month): 8 x 8 x 0.3$ = $19.2
Total $744.38528

Table 7: Cost of operation for 200GB