Proposed Solution Architecture for XYZ

Objective
Based upon the review of the current architecture, there are a few things which we would like to get
your attention upon. The current architecture solution has a challenge to grow and accommodate new
users as the application becomes a hit and more and more users start using the application. This might
impact the experience of the existing customers also, resulting the top and bottom line of the company.

This solution architecture will try to address the challenges faced in the application and also the
requirements as per our earlier discussions, by recommending a manageable, secure, scalable,
performance efficient, elastic, highly available and fault tolerant architecture. The proposed architecture
will be based on the ‘5 Pillars of the AWS Well-Architected Framework’.

We would be approaching in a “Lift and Shift” manner as discussed later and slowly allow for the
architecture to evolve in an incremental fashion. This will enable to the application to be moved to the
Cloud ASAP with minimal or no changes and also let the users of the application consume it. In the
later phases, the application would be integrated with various other AWS services like Pinpoint, EKS,
AppSync, DynamoDB, DeviceFarm and others to leverage the advantages provided by them like
scalability, targeted advertising, rapid deployment etc.

Assumptions
- The current architecture as-is is not scalable and the new architecture should address the
challenges and the requirements discussed and documented earlier.

- There is a clear segregation between the presentation and the business logic layer. This
will enable exposing the business logic layer to the mobile application and also later on the
same business logic layer can be easily ported to the Microservices based architecture.

- The presentation and the business logic layer are stateless, this would allow them to scale
horizontally by adding more and more virtual machines using the AWS AutoScaling feature.

- It is also assumed that there is a plan to provide Mobile as another channel for the
customers to engage with the application, the same has been considered in the application
architecture.

- Upon further analysis, we would evaluate to identify if any of the existing licenses and
subscriptions can be leveraged during the migration process to the Cloud. For ex., if the
domain name has been purchased then there is no need to buy it again from Route53.
 Proposed Solution Architecture for XYZ

Architecture
Below is the final TO-BE proposed architecture leveraging different AWS Services, based on
the initial discussions between us. The proposed architecture would be fine-tuned upon further
discussions on the same. The application will be refactored in a phased manner to this
architecture. AWS has a wide range of Services which are modular and doesn’t enforce the
user to use them at once.

2
 Proposed Solution Architecture for XYZ

The application architecture has been split into three tiers a) Web Application Tier b) Business Logic
Tier and c) Data Tier. All the tiers except the Database tier are stateless, which allows the Web
Application Tier and the Business Logic Tier to scale horizontally as the per the resource usage. This
enables proper utilization of the resources and hence savings on the cost.

Web Tier
This layer deals with the presentation of the content and the interaction with the user. The existing
application should be able to run with minimal or no changes in this tier. The only change which might
be required is for the interaction with Cognito for sign-up, sign-in and access control.

The EC2 compute instances along with the web application will be deployed in Multi-AZ and Multi-
Region configuration to provide High Availability (HA) by providing redundancy at different levels.
Redundancy leads to additional cost, but the level of redundancy (Regional or Zonal) will be fine-tuned
as per level of HA required. We would also be using AutoScaling along with CloudWatch to monitor
the resource usage in this tier to scale-up and scale-down the EC2 instances.

All the EC2 instances are front-ended by the Elastic Load Balancer (ELB), which will automatically
distribute the incoming traffic across multiple EC2 instances. If one of the EC2 instance is down for
some reason, the health check will fail and the ELB will stop distributing the traffic to that particular
instance. This makes the application HA.

Amazon CloudFront (CDN – Content Distribution Network) will be used used to deliver the data,
media, APIs to customers all over the world with low latency and high transfer speeds. This will
definitely improve the user experience and also increase the page ranking across search engines
because of the faster webpage load times.

With the proliferation of ways to access the applications via various devices, AppSync along with
GraphQL will be leveraged for data synchronization and also to enable working in the offline mode.

Failures happen all the time, Route53 will be used for failover routing along with domain name
resolution and name mapping. Failover routing allows to route traffic when the resource is healthy and
to a different resource when the first resource is unhealthy.

Business Logic Tier

This layer encodes the real-world business rules. Initially the application would be migrated to the
Cloud as-is. In the subsequent phases, it is recommended to use the Microservices based architecture
using Containers enabling loosely coupled and independently deployable Services. The same
Microservices would be consumed by the Web Tier and the Mobile applications, which avoid
duplication of the business logic.

3
 Proposed Solution Architecture for XYZ

The Microservices based architecture allows more fine-grained granularity for the auto-scaling of the
Services. The Services would be able to scale independent of each other, ultimately leading to proper
utilization of the underlying resources.

The existing applications can be easily refactored as Microservices to be managed by Kubernetes for
Orchestration. AWS provides EKS (Amazon Elastic Container Service for Kubernetes) and ECS
(Elastic Container Service) to easily deploy, manage and scale containerized applications.

With EKS a highly available Control Plane (master nodes) is managed by AWS on a low per hour cost,
which the Data Plane (worker nodes) have to managed by the user. This architecture also makes the
testing, securing and monitoring the Microservices easy with AWS AppMesh.

Data Tier
To start, Amazon Database Migration Service will be used to quickly and seamlessly migrate the
Database from the MySQL to AWS RDS (Aurora). This enables minimal changes to the application, the
modification to the Database Connect String in the application should be good enough.

It is recommended to use DynamoDB at a later stage. DynamoDB is a NoSQL database delivering

single-digit millisecond performance at any scale. It’s designed for multi-region and multi-master to
provide high-availability. To make the database even faster, DAX (DynamoDB Accelerator) a fully
managed caching service can also be used in front of the DynamoDB tables.

Also, all the media would be stored in S3 and ‘S3 Object Lifecycle Management’ would be used to
transition the media to a different storage class based on the age of the data. For example, data would
be by default stored in S3 Standard and moved to Standard IA after 30 days and moved to Glacier after
120 days. This helps to further save cost around storing of the data.

Security
Security should be at the core of any application architecture. The data at rest would be encrypted
while using S3, RDS and DynamoDB using the industry standard AES-256 encryption algorithm. Also,
SSL/TLS will be used to create an encrypted channel between any two layers (ex., web client and the
web server) to protect the data in transit from being eavesdropped.

IAM (Identity and Access Management) along with Systems Manager (SSM) will be used to
securely access control access to AWS resources. For example, access to production EC2 instances
would be given to the Production Support Team and similarly access to the development EC2
instances to the Development Team.

4
 Proposed Solution Architecture for XYZ

A VPC with a private a public subnet will be used to host the Web Tier and the Business Logic Tier
respectively. This is the recommended approach to run a public-facing web application, while
maintaining back-end servers that aren’t publicly accessible.

Upon further analysis AWS Shield (DDOS protection), Macy, GuardDuty and WAF can be easily
integrated into the application at a later stage.

Analytics
By integrating Amazon Pinpoint in the Mobile and Web Application it would be possible to get insights
and visualizations on the user level engagement, purchase activity within the application and also the
customer demographics. We can figure out how many users open the application each day, the time
the user opens the application and a lot of other interesting data.

The above-mentioned data can be used for targeted campaign and also to increase the stickiness to
the application. Also, Pinpoint allows to figure out how effective the campaigns are, allowing to fine tune
the budget allocated to the different marketing channels.

Automation
CloudFormation provides a “Infrastructure As Code” will be used to setup the AWS resources required
for the application, this way less time would be spent on creating the AWS resources and so more time
on the application. Also, with CloudFormation production like environments can be created for the sake
of pre-production/stress testing and teared down once the testing is done.

Once the infrastructure in AWS has been created by CloudFormation, the operational tasks like OS
configurations, patching up and more can be easily done by OpsWorks.

Roadmap
While moving the application to the Cloud, as mentioned earlier we would be leveraging the “Lift and
Shift” approach and later incrementally leverage the above-mentioned Cloud features in a phased
manner. This will allow to get started get started with the AWS quickly and also allow the Customers to
use the application immediately.

Phase I
This phase is planned so as to require minimum changes to the application code as in the “Lift and
Shift” approach.

- EC2 – Virtual Servers in the Cloud

5
 Proposed Solution Architecture for XYZ

- ELB – Elastic Load Balancer

- RDS – Relational Database Service
- Route53 – DNS Web Service
- CloudFront – Content Distribution Network
- S3 and Glacier – Object Storage and Archival
- SNS – Notification Service
- IAM – Identity and Access Management
- CloudFormation and OpsWorks – Infrastructure as Code and Operation Management

Phase II
This phase involves migrating to DynamoDB, a NoSQL database of KV-Document type. Use of Cognito
for Authentication and Authorization. And finally, Pinpoint for sending customized messages to
customers across various channels.

- DynamoDB – NoSQL Database

- AppSync – Data Synchronization across Channels
- Cognito – Signup, Sign in and Access
- Pinpoint – Analytics, User engagement with targeted messages
- DeviceFarm – Mobile Application Testing Service

Phase III
In this phase the Business Logic Layer of the application would be moved to the Microservices based
architecture. This gives an opportunity to deploy changes to the application in short cycles enabling to
push new features to the customers rapidly.

- EKS (Elastic Container Service for Kubernetes) – Container Orchestration

Conclusion
Cloud obviously provides a quick bootup for start-ups by requiring less CAPEX, less infrastructure to
manage, high degree of automation. On top of this AWS has a wide variety of services enabling quick
and efficient porting of the application from on-prem to AWS Cloud.

The above-mentioned architecture tries to address the challenges currently faced and is also future-
proof to include additional AWS Services to make the application even better and further save costs.
This architecture also leverages some of the best practices and patterns as mentioned in the ‘AWS
Well-Architected Framework’ guidelines.

We wish you a success and would hope to be your partner for all your future endeavours.