Imagine the situation: a long-awaited marketing campaign is launching, website traffic increases fivefold, and exactly at the moment of peak sales, the server stops responding. The cart hangs, the database crashes under the number of transactions, and the business loses tens of thousands of dollars an hour. A familiar pain?

For many growing e-commerce projects, there comes a moment when the old architecture becomes the main brake on business development. In this material, we will analyze in detail our AWS migration case — a story about how a large Ukrainian online store gave up rented virtual servers. We will show step-by-step why moving to the cloud became the only right decision, what architecture we chose, and how we managed to achieve 99.9% availability (SLA) without astronomical infrastructure bills.

Initial data: why VPS could no longer cope

Our client was a retailer from the top 20 of the Ukrainian e-commerce segment (clothing and accessories). Before the start of the project, the infrastructure was based on two powerful but static VPS servers from a local provider.

Tech stack before migration:

• Frontend/Backend: Monolithic PHP application (Laravel)
• Database: MySQL (on the same server as the backend)
• Caching: Redis (basic settings)
• Media files: Stored locally on server disks

Main “pains” of the IT department and business

1. Downtime during sales periods (Black Friday, Cyber Monday). Vertical scaling (adding CPU and RAM) required rebooting machines and took hours. During peak moments, the servers simply could not withstand I/O operations.
2. Lack of fault tolerance (High Availability). The failure of the main server meant a complete shutdown of the business until manual restoration of backups.
3. Slow loading of static assets. Users from other regions and countries complained about the long loading time of product photos.
4. Security issues. The lack of a modern WAF (Web Application Firewall) made the site vulnerable to DDoS attacks at the application level (Layer 7).

It became obvious to the Chief Technology Officer (CTO) that classic hosting had exhausted itself. A full move to the cloud was required.

Project goals: what did we want to achieve by moving to the cloud?

Before starting planning, we, together with the business, set KPIs for the new infrastructure:

• Availability (Uptime): No less than 99.9% over the year.
• Scalability: Automatic launch of new instances when CPU growth > 70% within 2 minutes.
• Performance: Server response time (TTFB) < 200 ms.
• Security: Protection against bots, scrapers, and DDoS attacks “out of the box”.
• Cost Optimization (FinOps): The infrastructure must scale down at night and during periods of low activity so as not to pay for idle capacity.

Architecture choice: which AWS services we used

A successful cloud migration is not just moving virtual machines “one-to-one” (the Lift-and-Shift approach). To get real value from Amazon Web Services, we used the Re-platforming approach, adapting the architecture to cloud-native services.

1. Compute

Instead of bare servers, we implemented Auto Scaling Groups (ASG) based on Amazon EC2. The application was packaged into Docker containers, and orchestration was configured via Amazon ECS (Elastic Container Service). This allowed us to forget about manual machine management. Traffic between containers was distributed by an Application Load Balancer (ALB).

2. Database

Managing MySQL independently is always a risk. We moved the database to Amazon Aurora (MySQL Compatible).

• Why Aurora? It automatically distributes data across three Availability Zones and provides I/O speed up to 5 times faster than standard MySQL. We configured Read Replicas to remove the load from the master during complex search queries in the catalog.

3. Media storage and caching

All product images (over 500 GB) were moved to Amazon S3 object storage. To distribute them quickly worldwide, we connected a CDN — Amazon CloudFront. The Redis role was taken over by the fully managed Amazon ElastiCache service, which relieved the DevOps team of the task of monitoring cache RAM.

4. Security and network

The entire infrastructure was deployed inside an isolated Amazon VPC (Virtual Private Cloud). Only the load balancers (ALB) had public access, while databases and application servers were in private subnets. Traffic at the entrance was filtered through AWS WAF.

Step-by-step AWS migration: the case in detail

Any large business moving to the cloud is fraught with the risk of losing data or crashing the site in the process. We broke the project into 4 stages to minimize risks.

Stage 1: Infrastructure as Code (IaC)

We categorically refused to click on resources manually in the AWS console. The entire architecture was described using Terraform. This gave us a huge advantage: we could spin up an exact copy of the production environment for testing in just 15 minutes, and after tests — delete it just as quickly without overpaying for rent.

Stage 2: CI/CD setup and containerization

So that the client’s developers could deploy code several times a day without downtime (Zero-Downtime Deployment), we configured pipelines in GitLab CI. Docker images were built automatically, images were pushed to Amazon ECR (Elastic Container Registry), after which ECS smoothly updated the containers.

Stage 3: Data migration preparation

The most critical part is moving the database without stopping sales. We used the AWS Database Migration Service (DMS). First, we made a full dump of the old database on the VPS and deployed it in Amazon Aurora. Then AWS DMS connected to the old server in Continuous Data Replication (CDC) mode. It intercepted every new transaction (purchase, registration) on the old site and instantly copied it to the cloud. Thus, both databases were synchronized with a delay of less than a second.

Stage 4: Hour X — the final switch

The final move took only 15 minutes late at night:

1. We put the old site in “Read-Only” mode so that users could not create new orders at the moment of switching.
2. We waited until AWS DMS finished writing the last bytes of data to Amazon Aurora.
3. We changed the DNS records in Amazon Route 53, directing all global traffic to the new load balancer (ALB) in AWS.
4. We disabled “Read-Only” mode.

Not a single order was lost. Users didn’t even notice that the store “moved”.

Results: numbers that speak for themselves

3 months after the migration to AWS, we audited the results. The move to the cloud exceeded the business’s expectations.

The most important business indicator: During the next major sale, the store withstood 10x the normal traffic load. The infrastructure automatically spun up 15 additional containers, handled the flow, and then scaled back down to the baseline 3 containers.

FinOps: How we optimized AWS costs

A frequent fear of IT directors: “The cloud is expensive. We will go broke on bills from Amazon.” Yes, if you move servers “head-on,” the cost can increase. In our migration case, we applied three cost-cutting strategies:

1. Rightsizing: We refused to buy resources “with a margin”. The baseline load was provided by a minimum set of servers, and the rest was bought automatically only as needed.
2. Reserved Instances & Savings Plans: After analyzing the constant load (databases, cache), we reserved compute capacity for 1 year in advance. This provided a discount of up to 40% compared to On-Demand (pay-as-you-go) pricing.
3. Using Spot Instances: For background tasks (video processing, generating heavy reports for accounting), we used spot instances — spare AWS capacity sold at a discount of up to 90%.

As a result, the total cost of ownership (TCO) of the cloud infrastructure turned out to be 15% lower than maintaining the old fleet of VPS, taking into account the salaries of administrators for 24/7 support.

FAQ: Common questions about moving to the cloud

1. How long does a full AWS migration take? Timelines depend on application monolithicity and data volume. On average, for a large e-commerce project, audit, IaC preparation, testing, and the move itself take 2 to 4 months.

2. Is it safe to store client data in the public cloud? Yes, if the architecture is designed correctly. Amazon Web Services meets the strictest standards (PCI DSS, HIPAA, GDPR). The use of private subnets (VPC), data encryption at rest (KMS) and in transit guarantees security at the level of banking systems.

3. Do we need a permanent DevOps staff after the move? Using managed services (PaaS/SaaS) like Amazon RDS, ElastiCache, and ECS removes the routine of OS updates and server patching. You will need fewer “hands” for support, and the engineers’ focus will shift to product development and CI/CD.

4. Is AWS suitable for small startups? Absolutely. The main advantage of the cloud is the Pay-as-You-Go model. At the start, the infrastructure will cost pennies, but with explosive growth, it won’t crash and will easily scale along with the business.

Conclusion

Analyzing this AWS migration case, we see the main trend: today, server power is not hardware, it is a flexible tool for earning money. Using static servers for a dynamic business like e-commerce is like trying to win a “Formula 1” race on a tractor. You can move, but on the turns, your competitors will pass you.

The transition to cloud infrastructure allowed our client to forget about sleepless nights during releases, completely get rid of site crashes, and speed up page loading across the country.

Ready to transform your IT infrastructure? Stop losing clients due to slow database performance and server crashes. Entrust the audit and move to the cloud to professionals. Leave a request for technical consulting, and we will calculate the migration cost and potential savings for your business today!