The Perfect AWS Architecture For Magento Websites
Amazon Web Services (AWS) provides on-demand cloud computing in a robust, flexible, and affordable manner. A subscriber-based service is a way out of more conventional company hosting models. Not only do they provide the basics of hosting but they also provide a wide variety of options that are all built with different uses in mind.
When it relates to running an ecommerce platform, many of AWS' versatile and scalable qualities for different factors become convincing. For example, what easier way of handling the increase in traffic on Black Friday than being able to scale your web server to accommodate the extra load almost immediately.
Each ecommerce site is unique and the type of approach required varies tremendously depending on the project specifications but there are some staple elements within the AWS suite that are likely candidates for Magento.
I will run through these basic building blocks in this article, providing some more information on their purpose and demonstrating what a generic AWS / Magento architecture could look like.
This is not intended to be a catch-all tutorial but instead a gentle introduction to hosting Magento using AWS.
Walking Away From Traditional Hosting
First, let's begin to talk about how the pricing structure AWS on demand varies from conventional hosting.
Usually you would pay a specific amount for a given time with conventional hosting models, and you would get a 'bare metal' server for that price. If that server's capability is exceeded you'd have the option to add assets. This will result in a new or updated agreement with your vendor in most situations, and a few hours to days of time to allow the hosting company to take action on the upgrade.
This poses an underlying issue apart from the time cost of undertaking such an upgrade: You are paying for more than you need.
This article addresses the very core, but there are all sorts of reasons you can architect AWS for Magento from having several availability zones, attaching AWS Elastic Load Balancer (ELB) to a front end cache like Coating, the list goes on.
Hopefully this will provide a starting point for a deeper understanding of what is involved.
It's important to keep in mind at around this point that each and every site is distinct. Sites may get anything from a few to millions of SKUs, multiple compatibility criteria and varying rates of traffic.
Both have a significant effect on the hosting environment's configuration specifications, and on how it will need to expand over time. It is therefore important to begin with the existing specifications first and to design the proposal with this in mind, because there is no such thing as a one-size-fits-all solution.
Broadly speaking, the network has two ways to scale up:
Vertically: By attaching services to the current instance
To tackle the challenge of vertical scaling, you begin by decoupling your application rates. Application-levels are likely to have different resource needs and can develop at different rates. You may compose each tier using the most suitable type of instance based on specific resource needs by separating the thirds.
Now try to build your application in a decentralized manner, so it can work. You should be able to manage a request, for example, using any web server and create the same user experience. Store the application state separately, so that the same server will not have to manage subsequent requests.
If the servers are stateless, you can scale with the use of Elastic Load Balancing (ELB) by adding more instances to a tier and loading incoming requests through EC2 instances.
Horizontally: By adding additional instances your existing one
A system that is horizontally flexible is one that can expand efficiency by adding more computers to the network. This is in comparison to a "vertically scalable" system, which is limited to run its processes on only one machine; in these structures the one and only way to improve performance is to attach more assets to one machine in the form of faster (or more) CPUs, memory, or storage.
Horizontally scalable systems are also able to outperform vertically scalable systems by allowing simultaneous process execution and spreading workloads over several different computers.
There are both advantages and disadvantages, for instance vertical scaling means a single point of failure but is easy. Horizontal scaling adds complexity but has a major redundancy advantage.
AWS also offers the ability to scale the web server dynamically, automatically or with some extra effort. This helps you to add new technology from the comfort of the powerful control panel AWS offers.
Auto scaling is outside the reach of this article but understanding that as your store expands, the capacity is there can be helpful.
A Traditional Magento hosting architecture in AWS
Let's move on to some of the most useful AWS components with that covered, their purpose and how to host a Magento site.
Let's take a simple Architecture hosting AWS Magento and dive into the components.
RDS: RDS (Relational Database Service) is provided by AWS as the database. It is a solution out of the box that lets you configure databases without having to handle the program running directly on the case. The hope is that it reduces some of the difficulty of the finer information that is involved with managing yourself. This is sort of a black box.
It also comes with some very useful features such as updates to auto applications, logging, snapshots, and rollbacks.
In our case, as we are hosting a Magento account, we will have to install MySQL version 5.6 or higher and use some AWS protection groups to ensure that it can communicate effectively to your EC2 instance(s).
Now that we can go ahead with the basic web server and database, and add some peripheral components to enhance the setup.
The built-in caching of ELASTICACHE Magento helps speed up the web by saving data from previous users in a fast access cache and sparing load on the database.
By default this cache and user session data are stored on the web server file system. It is fine but can also be sluggish because of the latency of reading and writing from disk. That's why AWS provides a specially tailored service to deliver cached data at a quicker rate: Elasticache.
To use this, simply configure the Elasticache instances you need, and configure your Magento store to use this by changing your Magento main config file. This will tell Magento where to get the cached information from.
It can also be used to store site session data, with the same gain.
EC2: The key components according to the diagram above are EC2 RDS Elasticache Cloudfront EC2 This is the web server offered by AWS. They come in a variety of shapes and sizes and what you pick will depend on your site specifications but the best place to start is the Magento documentation on minimum criteria for specification.
You have full control of the operating system when configuring an EC2 instance (you can use Linux for Magento), as well as the option of hard drives and number of CPUs.
AWS also provides Amazon Machine Images (AMI) which are pre-built web server stack templates making it easy to create the web server you need in just a few simple steps.
AWS Elasticache offers both Redis and Memcached databases, so that you can use one or both depending on your preferences.
CLOUDFRONT CDN: Anyone serious about ecommerce would at least consider using a CDN to speed up asset distribution to the end consumer.
Natively, Magento allows you to serve both images and static CSS/Javascript files from different sources, making it easy to incorporate Amazon's Cloudfront CDN providing static-urls-admin-magento2.png The CDN can ensure that your site's static assets are distributed to your end user more easily by geographically positioning them closer to them.
It also has the extra credit for load reduction on the web server itself.
Standard Magento deployment for low-cost budgets: We can deploy the Magento website to the AWS Cloud Platform by choosing the right components for the network as per our wishes.
By integrating services such as-Auto scaling and multi AZs deployment, we will make the network highly accessible and scalable.
Services used in this deployment:
VPC: Amazon Virtual Private Cloud (Amazon VPC) helps you to launch the AWS services into a virtual network that you have built up. This virtual network closely resembles a conventional network you can run in your own data center, with the benefits of using AWS's scalable architecture.
Subnets: A subnet in your VPC is a collection of IP addresses. A table of routes includes a set of rules, called routes, used to decide where network traffic is being guided.
IGW: An Internet gateway is a VPC feature that is horizontally scaled, durable and highly available enabling communication between instances in your VPC and the Internet. Therefore it does not place any chance of availability or bandwidth limitations on your network traffic.
NAT Gateway: NAT Gateway is a highly accessible AWS-managed service that makes it easy for Amazon Virtual Private Cloud (Amazon VPC) to link to the Internet from instances within a private subnet. Previously you had to start a NAT instance to allow NAT in a private subnet for example.
EC2: Amazon Elastic Computing Cloud (Amazon EC2) is a cloud-based web service that delivers stable, resizable computing capability. It's planned to make cloud computing on a network scale simpler for developers. The simple web service interface of Amazon EC2 helps you to get and customize minimal friction power.
RDS: Amazon Relational Database Service is Amazon Web Services' distributed, relational database service. This is a "in the cloud" web service developed to automate the configuration, maintenance and scaling of a relational database for application usage.
AWS Elasticache: Amazon ElastiCache enables you to easily set up, run, and scale common cloud-compatible open-source in-memory data stores. Create data-intensive apps or improve performance of your current databases by recovering data from stores of high throughput and low latency data in memory. Amazon ElastiCache is a common option for Caching, Session Stores, Gaming, Geospatial Services, Real-Time Analytics, and Queuing for real-time use.
AWS S3: Amazon Simple Storage Service (Amazon S3) is a flexible, high-speed, web-based cloud storage service designed to back up data and applications to Amazon Web Services online and archive them. Amazon S3 was developed with a minimal set of characteristics and built to make computing on the web-scale simpler for developers.
AWS Cloudfront: Amazon CloudFront is a network of content delivery services (CDN) that Amazon Web Services provides. Content delivery networks provide a globally distributed network of proxy servers that store content more locally to users, such as online videos or other bulky media, thereby increasing accessibility speed for accessing the material.
AWS ELB: Elastic Load Balancing (ELB) is a load balancing service for deployments made by Amazon Web Services (AWS). ELB allocates the incoming traffic and adjusts services dynamically to meet traffic demands. ELB allows an IT team to change resources depending on the program and network traffic coming in.
Route 53: Amazon Route 53 is a widely accessible, scalable Internet service to the cloud domain name system (DNS). ... Using the easy visual editor of Amazon Route 53 Traffic Flow, you can easily control how your end-users are routed to the endpoints of your application — whether in a single AWS area or spread globally.
Estimated cost: In this architecture we found the web server tier to be m4.large, and database to be t2.medium. Monthly average costs can vary according to resource type.
With an On-Demand service model, this architecture with the above listed resources would cost around $250 per month.
Royex Technologies is one of the leading companies in Dubai for designing cloud servers and maintenance. For all AWS consulting and services, choose Royex. To get started, call for any inquiries at +971566027916 or mail at info@royex.net