Architecture overview and requirements
The following are the customer’s high-level requirements:
• 3-tier application architecture (Web, App, DB) to be implemented on AWS.
• Customers from different countries can see the items in their local currency, by detecting their geolocation information.
• The design should satisfy the following:
o High availability
o Scalability
o Security
o Cost optimization
o High performance
• A secure connectivity between the customer’s office and the new infrastructure on the public cloud should be implemented for the customers’ employees to manage the infrastructure.
• CI/CD for the application development.
• Observability: Monitoring and alerting for high observability.
Architecture
Architecture Description
• Region: We will choose the region of our architecture based on 4 factors.
• Compliance.
• Latency.
• Cost.
• Service and features.
• Availability Zones: We will build our architecture in 2 or more availability zones to make our architecture highly available.
• Private Subnets: We will Put all the 3 tiers including the frontend in private subnets to be more secure and we will use a load balancer to be internet facing.
• Public Subnets: We will use the public subnets only for Nat Gateway as we must put the Nat Gateway in the public subnets.
I will not use the Bastion hosts in our architecture as it will be high cost and it is not secure. I will replace it with Session manager, or I will use the new feature “EC2 instance Connect Endpoint”.
• Load balancers: these load balancers will be application load balancer. first load balancer will be internet facing. The second load balancer will be internal between frontend tier and backend tier.
• Frontend: Our frontend will be an Auto scaling group that will contain Ec2 instance distributed in the 2 availability zones that will make our high available and scalable.
Our scaling strategy will be chosen based on the website traffic and we will choose the most performance and cost-effective strategy.
• Backend: Our Backend will be an Auto scaling group that will contain Ec2 instance distributed in the 2 availability zones that will make our high available and scalable.
Our scaling strategy will be chosen based on the website traffic and we will choose the most performance and cost-effective strategy.
• Database: As the assignment, we consider that our database is relational database. So, we had 2 options RDS or Aurora. I chose the database to be RDS for two reasons.
• First, RDS supports 5 relational database engines unlike Auroura that now supports only 2 engines.
• Second, RDS will cost us 20% less than Aurora.
We will use RDS Multi-AZ. That will make our website highly available.
• Storage: we will use AWS EFS as a scalable network file storage for frontend and backend tiers. That will help us to share the data between all the tier instances and not to lose any data if a scale in process happened.
• Route53: We will use route53 as our DNS web service.
• CloudFront: we will use CloudFront for two reasons.
• First, we will use it as content delivery network to deliver or content to all our customers through edge locations near them that will reduce the latency.
• Second, we will use the geolocation headers from the cloud front to identify the country which the request has originated from so that we could show the items with the country local currency.
• Lambda@Edge: we will use Lambda@Edge in the process of showing and converting the currency to the local currency of the origin request country.
We can do the converting process with 2 ways using third party service API that will be used for real-time exchange rates. or using database with the currencies exchange rates stored in it.
• Security: we will use network access control list and security groups in the subnet and instance level with the concept of least privilege that will help us to secure our architecture.
• Observability: We will use Cloud watch for the process of collecting metrics and logs from all other services. Cloud trail will be used for collecting all action logs taken by a user, role, AWS services or any other API.
We will use cloud watch for centralized logs and metrics collections, and we could visualize it using cloud watch dashboard.
We will use the cloud watch alarms and other AWS services like SNS to cover the part of alerting.
With the process of monitoring and alerting I mentioned above we will achieve the high observability.
• Site-to-Site VPN: we have 2 ways to connect our office building to our architecture on cloud. The two ways are Direct Connect and Site-to-Site VPN.
We will use Site-to-Site VPN because it is less cost and less maintenance time to the Direct Connect.
Site-to-Site VPN is also highly available as it uses two tunnels across availability zones, and it is very secure as the connection will be encrypted.
For building Site-to-Site VPN we need two gateways, one in the office and it is called Customer Gateway and the other one in the cloud VPC and called Virtual Private Gateway.
• CI/CD: we will use AWS CI/CD for the application development with the help of these services.
• CodeCommit: we will use it as a source control service that we will store our codes in its repository.
• CodeBuild: we will use it as a continuous integration service that will run tests and make our environment ready to start deploying.
• CodeDeploy: we will use it to deploy our code to the frontend and backend.
• CodePipeline: we will use it as a continuous delivery service that will automate the steps we need to release our software updates.
Recommendations for the architecture
• Short-term recommendations: I recommend two things.
• First, to start using web application firewall to increase our website security.
• Second, if our database was MySQL or Postgre SQL I recommend using Auroura because of the high performance, automatic failover and other features.
• Long-term recommendations: I recommend to start converting our architecture to microservices by containerizing the frontend and backend tier and use ECS instead of EC2.
Top comments (0)