AWS Solution Architect Program

Problem statement

The scenario involved a startup struggling with several issues on their web application, which is a Single Page Application (SPA) developed with React, Python, and Flask, and uses PostgreSQL for its database. Their setup was currently running on a single AWS EC2 instance (t3.medium with 4GB of RAM). The main problems they were encountering included:

• Slow response times during peak periods.

• Server crashes due to memory exhaustion.

• Downtime during deployments.

• Lack of a disaster recovery plan.

Expected Outcome

Given these challenges, My task was to design a scalable and stable solution, detailing the software's structure and characteristics, and provide cost estimates and budget forecasts to my client.

---

Approach

The solution is based around Elastic Beanstalk which brings together HTTP load balancing, application servers and database servers under one umbrella. After setting up these services using Elastic Beanstalk, they can be scaled independently. For example, we can increase the resources available to the database server without affecting the app server, and vice versa.

I recommended using Elastic Beanstalk for the following reasons:

• Elastic Beanstalk supports Python applications, making it a suitable choice for their Flask-based backend.

• The ability to automatically scale resources up or down based on traffic was crucial for handling peak periods and preventing server crashes.

• Elastic Beanstalk’s Blue/Green deployment strategy could help eliminate downtime during updates, ensuring a smoother user experience.

In addition to Elastic Beanstalk, I selected the following AWS services to enhance the overall solution:

• Route 53 : We will set up applications DNS in AWS Route 53, AWS’s DNS management system. This will allow your DNS to tie into the load balancer and make routing changes automatically.

• Elastic Load Balancing (ELB): To distribute incoming traffic across multiple instances, improving availability and fault tolerance.

• Amazon RDS (Relational Database Service): To manage the PostgreSQL database with built-in replication and automated backups, addressing the lack of a disaster recovery plan.

• Amazon S3 (Simple Storage Service): For storing and serving static content like images, CSS, and JavaScript files.

• AWS CodePipeline: To automate the deployment process, integrating with Elastic Beanstalk for continuous integration and continuous delivery (CI/CD).

Architecture Diagram

Implementation Steps

1. VPC Setup:

   • VPC Creation: Create a VPC with public and private subnets across 2 Availability Zones.

   • Public Subnets: Place the Internet Gateway and NAT Gateway in these subnets.

   • Private Subnets: Place your EC2 instances and RDS in these subnets.

2. Elastic Beanstalk Configuration:

   • Environment Creation: Create an Elastic Beanstalk environment and configure it to use the VPC, ensuring that the EC2 instances are launched into the private subnets.

   • Load Balancer: Elastic Beanstalk can automatically configure an ELB in the public subnet if needed.

3. CodePipeline Configuration:

   • Pipeline Stages: Set up the source, build, and deploy stages. Ensure that CodeBuild, if used, operates within the VPC.

   • Deployment: The deploy stage will deploy your application to the Elastic Beanstalk environment, which operates within the VPC.

4. Security and Access:

   • Security Groups: Define rules to control access to Elastic Beanstalk instances, RDS instances, and any other resources.

   • Network ACLs: Set up Network ACLs to manage traffic at the subnet level.

Cost calculation

• VPC Creation: No direct cost for creating a VPC itself.

• Public IP Addresses: Costs for Elastic IP addresses (if used) are based on whether they are associated with running instances.

• NAT Gateway: Charged based on the hours the NAT Gateway is provisioned and the amount of data processed.

• Data Transfer: Costs for data transferred in and out of the VPC, especially for data transferred through NAT Gateways or to/from the internet.

Amazon Elastic Load Balancer (ELB)

• Hourly Charges: Charged per hour or partial hour for each load balancer.

• Data Processed: Charged based on the amount of data processed by the load balancer.

Amazon Elastic Beanstalk

• EC2 Instances: Charged based on the EC2 instances that Elastic Beanstalk provisions for your environment.

• ELB: Included if Elastic Beanstalk provisions an ELB.

• Other Resources: Any additional AWS resources such as S3, RDS, etc., used by your application.

Amazon RDS

• Instance Cost: Charged based on the RDS instance type and size.

• Storage Cost: Charged for the amount of data stored.

• I/O Requests: Cost for database I/O operations, if using provisioned IOPS.

• Backup Storage: Charged for backup storage beyond the free backup storage provided.

Amazon S3

• Storage: Charged based on the amount of data stored per month.

• Requests: Charged per request (PUT, GET, etc.).

• Data Transfer: Costs for data transferred out to the internet.

AWS CodePipeline

• Pipeline Charges: Charged per active pipeline per month.

While we can’t provide concrete pricing numbers until we know the exact resource requirements, but we can give guidelines on how it can change in the future, plus work with them to get some ballpark figures.

Conclusion

The AWS virtual job simulation was a tremendous learning experience, showcasing the power of AWS services in transforming and optimizing web applications.This hands-on exercise not only deepened my understanding of AWS solutions but also reinforced the importance of tailored, strategic planning in solving complex technical challenges.