TeckLearn A Data Science Enthusiast with in-hand skills in programming languages such as A Data Science Enthusiast with in-hand skills in programming languages such as A Data Science Enthusiast with in-hand skills in programming languages such as

Table of Contents

Migration of 3-tier e-commerce web application using Amazon web Services (AWS)

Consider a 3-tier e-commerce web application is current deployed on-premises and will be migrated to AWS for greater scalability and elasticity the web server currently shares read-only data using a network distributed file system. The app server tier uses a clustering mechanism for discovery and shared session state that depends on IP multicast. The database tier uses shared-storage clustering to provide database fall over capability, and uses several read slaves for scaling Data on all servers and the distributed file system directory is backed up weekly to off-site tapes In this case what will be the AWS storage and database architecture which will meets the requirements of the application.

Well the solution design to this scenario tier wise is as follows:

For Web servers: Store read-only data in S3, and copy from S3 to root volume at boot time.
For App servers: Share state using a combination of DynamoDB and IP unicast.
For Database: Use RDS with multi-AZ deployment and one or more Read Replicas.
For Database Backup: Web and app servers backed up weekly via AMIs, database backed up via DB snapshots.

Detailed Explanation for the above design is described below with benefits:

Amazon RDS Multi-AZ deployments provide enhanced availability and durability for Database (DB) Instances, making them a natural fit for production database workloads. When you provision a Multi-AZ DB Instance, Amazon RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different Availability Zone (AZ). Each AZ runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. In case of an infrastructure failure (for example, instance hardware failure, storage failure, or network disruption), Amazon RDS performs an automatic failover to the standby, so that you can resume database operations as soon as the failover is complete. Since the endpoint for your DB Instance remains the same after a failover, your application can resume database operation without the need for manual administrative intervention.

Benefits of this AWS storage and database architecture approach are:

Enhanced Durability

• Multi-AZ deployments for the MySQL, Oracle, and PostgreSQL engines utilize synchronous physical replication to keep data on the standby up-to-date with the primary. Multi-AZ deployments for the SQL Server engine use synchronous logical replication to achieve the same result, employing SQL Server-native Mirroring technology. Both approaches safeguard your data in the event of a DB Instance failure or loss of an Availability Zone.

• If a storage volume on your primary fails in a Multi-AZ deployment, Amazon RDS automatically initiates a failover to the up-to-date standby. Compare this to a Single-AZ deployment: in case of a Single-AZ database failure, a user-initiated point-in-time-restore operation will be required. This operation can take several hours to complete, and any data updates that occurred after the latest restorable time (typically within the last five minutes) will not be available.

• Amazon Aurora employs a highly durable, SSD-backed virtualized storage layer purpose-built for database workloads. Amazon Aurora automatically replicates your volume six ways, across three Availability Zones. Amazon Aurora storage is fault-tolerant, transparently handling the loss of up to two copies of data without affecting database write availability and up to three copies without affecting read availability. Amazon Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and replaced automatically.

Increased Availability

• You also benefit from enhanced database availability when running Multi-AZ deployments. If an Availability Zone failure or DB Instance failure occurs, your availability impact is limited to the time automatic failover takes to complete: typically, under one minute for Amazon Aurora and one to two minutes for other database engines (see the RDS FAQ for details).

• The availability benefits of Multi-AZ deployments also extend to planned maintenance and backups. In the case of system upgrades like OS patching or DB Instance scaling, these operations are applied first on the standby, prior to the automatic failover. As a result, your availability impact is, again, only the time required for automatic failover to complete.

• Unlike Single-AZ deployments, I/O activity is not suspended on your primary during backup for Multi-AZ deployments for the MySQL, Oracle, and PostgreSQL engines, because the backup is taken from the standby. However, note that you may still experience elevated latencies for a few minutes during backups for Multi-AZ deployments.

• On instance failure in Amazon Aurora deployments, Amazon RDS uses RDS Multi-AZ technology to automate failover to one of up to 15 Amazon Aurora Replicas you have created in any of three Availability Zones. If no Amazon Aurora Replicas have been provisioned, in the case of a failure, Amazon RDS will attempt to create a new Amazon Aurora DB instance for you automatically.

No Administrative Intervention

• DB Instance failover is fully automatic and requires no administrative intervention. Amazon RDS monitors the health of your primary and standbys, and initiates a failover automatically in response to a variety of failure conditions.

Failover conditions

• Amazon RDS detects and automatically recovers from the most common failure scenarios for MultiAZ deployments so that you can resume database operations as quickly as possible without administrative intervention. Amazon RDS automatically performs a failover in the event of any of the following:

a) Loss of availability in primary Availability Zone
b) Loss of network connectivity to primary
c) Compute unit failure on primary
d) Storage failure on primary

Note: When operations such as DB Instance scaling or system upgrades like OS patching are initiated for Multi-AZ deployments, for enhanced availability, they are applied first on the standby prior to an automatic failover. As a result, your availability impact is limited only to the time required for automatic failover to complete. Note that Amazon RDS Multi-AZ deployments do not failover automatically in response to database operations such as long running queries, deadlocks or database corruption errors.

Check out the AWS Solutions Architect Training by Tecklearn, a trusted online learning company with a network of satisfied learners spread across the globe. We are here to help you with every step on your journey, for becoming a besides this AWS Implementation scenario, we have come up with a curriculum which is designed for students and professionals who want to be an AWS Solution Architect.

Tecklearn’s AWS Architect Certification Training is curated by industry professionals as per the industry requirements and demands. The entire AWS training course is in line with the AWS Certified Solutions Architect exam. You will learn various aspects of AWS like Elastic Cloud Compute, Simple Storage Service, Virtual Private Cloud, Aurora database service, Load Balancing, Auto Scaling and more by working on hands-on projects and case studies. You will master AWS architectural principles and services such as IAM, VPC, EC2, EBS and elevate your career to the cloud, and beyond with this AWS solutions architect course.

What you will Learn in this Course?

• Overview of Cloud Computing and AWS
• Amazon Elastic Compute Cloud (EC2)
• Amazon Storage Services
• AWS Database Services
• Load Balancing in AWS
• Amazon Application Services
• AWS IAM
• Preparing for the AWS Solution Architect Associate Exam

1,252