How to Move Your E-Commerce Website to Amazon Web Services

If you are serious about your e-commerce business, you must acknowledge that every element of its infrastructure can fail.

Promises made by the service provider will always be empty if you do not protect yourself seriously, starting with duplicating each element of the store and ending with maintaining a copy of the site in a different location than the original, ready to run in the event of a total failure.

Adjusting the infrastructure to the load, which is variable for each store, will remain a separate issue. You can start with small resources and add more elements as your business grows, gaining more scalability and platform reliability.

Let's see what it can look like on the example of the largest infrastructure as a service (IaaS) cloud provider, Amazon Web Services (AWS).

In this article, you will learn:

• How the cloud scales its "power" depending on needs
• How to build an e-commerce store cloud infrastructure
• How your infrastructure at Amazon Web Services can evolve as your business grows
• How much it costs to transfer an online store to the cloud

There are a number of ways to get your applications to the cloud. No matter which way you choose, Hostersi's particular approach is to do it right because there are no shortcuts.

Step 1: A Single Instance in AWS

The infrastructure constitutes a reflection of one server, or a virtual private server (VPS).

This is the first step because you can benefit from transferring an online store hosting to the cloud; at any time, you can:

• Increase the resources of the instance
• Add more central processing units (CPUs) or cores and random-access memories (RAM)
• Expand the disk

All this will make the store unavailable for only a few minutes, and you do not need to migrate, move, copy, or ask for help.

You can save time and costs this way because you can make the change at any time, and you pay only for the resources actually used.

Step 2: A Single Instance in AWS and a Database in RDS

This is where we can really start taking advantage of the benefits of cloud computing.

We attach a database to our single instance, located in the Amazon RDS (Relational Database Service).

In this stage, you don’t have to install MySQL, Postgres, or another database (Amazon Aurora, Oracle, MSSQL, MariaDB); we select it as a service because we are interested only in data.

RDS allows us to choose the right resources and easily scale them if necessary. In addition, we can easily create backups automatically (even independently) and save them in a different region in the S3 basket, to which only we have access and can guarantee that nobody will suddenly delete all this data.

This stage deals with serving the site, and a store application (e.g. Prestashop or Magento) works to connect the database to the RDS service.

A database constitutes one of the most-loaded places in an online store, so you not only divide the load into two services but also make diagnosing problems and loading easier.

You can also change and add resources in the same way. So, when you expect more traffic for a specific unit of time, you simply buy more resources without paying for infrastructure you won’t use most of the year. 

Step 3: A Single Instance, RDS, and Static Files Stored in S3

Our store will gain flexibility and the ability to change its infrastructure at the same time when you get rid of recording important data within the instance itself.

We can achieve this by transferring the store files to Amazon S3. This is the essence of Amazon Web Services, historically the first web service, and is a file space that is easy to use with no limit on quantity or space.

The S3 bucket is scalable and possesses incredible redundancy and record reliability. At the same time, we do not have to reserve anything or look at the limits. We pay only for the amount of data and number of transfers, file readings, and saves.

AWS guarantees the availability of S3 99.9% of the time. You save files such as pictures and photos, while store, customer, and purchase data are stored in the RDS database. In terms of an instance, you have only store code files that can be uploaded anytime.

When you get to this place, scaling the site in the cloud will open up to you.

Step 4: A Single Instance, RDS, Static Files stored in S3, and Sessions in Amazon ElastiCache

No service today can exist without sessions, and saving them in a database or in S3 is not a good idea for performance reasons.

The ideal place to save a database is Redis. However, if something causes the data’s loss, change of instance, or restart, the sessions are gone. That is why the Amazon ElastiCache service was created.  

The ElastiCache is like an RDS but with Redis. Once again, AWS handles the resources, operation, and availability, and there is no server – You simply save data at the indicated address, and that's it.

Each element works independently, and each component can be scaled and analyzed separately. 

Step 5: A Single Instance, RDS, and Static Files Stored in S3 With VPC with VPN to Increase Security

It's time to improve security. Since we have all the data in the AWS services and only our instance has access to them, it would be ideal if nothing else was visible on the internet directly with the public IP address.

AWS provides a nice VPC service (Virtual Private Cloud), a logically separated part of the network, within which our services work with their own range of private IP addresses, subnetworks, and routing.

All services get private IP addresses, and the entire infrastructure can only be accessed via VPN (secure encrypted connection). Don’t worry; it’s not difficult to put together a connection, and the developer will get to the data to develop the online store.

Step 6: Two Instances, Database in RDS, Files in S3

Everything in this stage is stateless and secured by VPC. Sometimes this service is needed to increase resources permanently, sometimes only during a period of increased purchases.

We have reached the point where we appreciate the advantages of hosting an online store in the Amazon Web Services cloud, but it is time to build a high-availability environment and increase the number of instances.

It is here that traffic jams will most often appear. However, we can expand every element without any changes in the stateless application.

In each region, AWS possesses at least two access zones, like separate data centers that are distant from each other and possess their own infrastructure and power supply but stay connected through a super-fast link.

All services can be arranged between these zones (two or three), some manually and some like S3 or ELB (Load Balancer) are arranged automatically.

So, we add a second instance for the service, and ELB (or ALB) on their front, which will deal with dividing traffic.

At the same time, we gain a higher level of security, because from now on, instances do not have to have public addresses. Without VPN access, it is no longer possible to even access the “www” instance. No outsider will be able to navigate to that instance or page.

Step 7: Two Instances, a Database in RDS Multi-AZ, Files in S3

In the previous version, we gained redundancy of “www” servers, and now it's time for the database.

The RDS service also appears in the multi-AZ option, meaning that it may possess its copy in the second zone of availability.

Not only will it protect us against failures, but it is also going to allow us to change RDS resources without interrupting the operation of the website.

Step 8: Two Instances, a Database in RDS Multi-AZ, Files in S3, Sessions in Amazon ElastiCache With HA

We've reached the last element without high availability (HA). In terms of our stateless architecture, the last remaining element is the place for sessions, meaning the AWS ElastiCache.

This service is also available in the multi-AZ version; we compile the Redis cluster and can freely scale the service without affecting the website operation.

Redundancy not only protects you against failures, but it also allows you to perform service updates and changes in configuration and resources without affecting the operation of the online store. From here, you can really sleep peacefully.

Your online store now has little chance to stop working due to hosting problems. 

Step 9: Use Route 53 and the Amazon CloudFront CD

The infrastructure is now very secure, and there is little chance that something will surprise us. But sometimes a service failure occurs when nobody expects it.

Clients will reach the site provided that your DNS server responds to queries. Unfortunately, DNS problems occur with local domain providers. Therefore, to make this element independent from the problems of local domain providers, take advantage of the AWS DNS Route 53 service.

Not only do we gain great operational confidence, but we also shorten the response time of the DNS server by locating servers closer to the recipients.

The second element – CloudFront – is already designed to lightly ease the infrastructure load and speed up the loading of static content. This will prove useful with more shoppers accessing your site from different locations around the world.

The CDN CloudFront is a cache that stores the most-loaded elements of a website and serves them from its memory, bypassing their downloading from servers. This makes it faster and cheaper.

Step 10: Run Autoscaling

Each service has moments when it is more or less loaded. In traditional services, we buy a server with a reserve that "gets bored" most of the time.

AWS possesses mechanisms that allow us to take specific actions based on the instance's load.

The web server has a load of over 65% for 5 minutes; start another one and join the load balancer. Not enough? Join another one.

For example, you notice that each day from 6 p.m. until 11 p.m., there is a spike in traffic; you can automatically add a few instances more to accommodate this traffic boost. You pay for those instances only for those 5 hours.

Another example is if you know there will be a week-long discount; manually launch a few additional instances. You can do almost anything if you've built a stateless application and infrastructure based on AWS services in advance. 

Interestingly, these are not all of the possibilities. In many cases, you can completely get rid of server resources and use only AWS services by building a serverless solution.

How Much Does It Cost to Transfer a Store to the Cloud?

The cost of transferring your store to the cloud depends on the store.

Assuming you have 50 GB of data, 10 GB of database, 100 GB of transfer, see below how much it costs to have more peace of mind. For a medium infrastructure, we assume 100 GB of data, 25 GB of base, and 500 GB of transfer.

These are only estimates; sometimes the resources will be larger and sometimes smaller.

In addition, there are a number of methods to reduce these costs in the long run (e.g., resource reservation, payment for a year, use of external CloudFlare services). But this is a separate topic.

Have Peace of Mind With Amazon Web Services

Moving your e-commerce store to AWS will help your business grow, scale, and become safer and more reliable.

If you move your store to the cloud, you can rest easy knowing your site can perform well and encounter fewer problems.

Tomasz Dwornicki - expert with over a dozen years of experience in the field of efficiency of websites and online shops, migration to the cloud and design of server architectures. He created the first most popular Polish web 2.0 websites, including fotosik.pl and sms.pl. Currently he manages Hostersi, classified in "Top 15+ Cloud Computing Consultants in Poland" according to The Manifest. Hostersi are AWS Advanced Consulting Partner and Channel Partner.