1. Table of Contents

1. Service Direction / Introduction / Scope
2. Service Transparency
3. Definitions
4. Description of Content / Step-by-Step Guide
5. Common Mistakes
6. Responsibility Breakdown
7. Limitations
8. FAQ
9. Summary
10. Use Case

2. Service Direction / Introduction / Scope

This article explains how AWS Auto Scaling manages different components of a dynamic website—such as PHP application files, MySQL databases, uploaded images, user sessions, and cache—when running across multiple servers. Understanding these components is crucial during migration from traditional hosting to a scalable cloud environment.

3. Service Transparency

In an Auto Scaling environment, multiple servers may be created or removed at any time based on traffic volume. Because of this, hosting components cannot rely on local server storage. Every part of the website must be structured to work across multiple instances simultaneously. This ensures stability, avoids data loss, and prevents inconsistent behaviour such as random logout or missing uploaded files.

4. Definitions

Auto Scaling: The automatic process of adding or removing server instances based on real-time traffic.

Distributed Architecture: A setup where multiple servers work together to handle website load.

Centralized Storage: Storage services like S3, RDS, EFS used to ensure data consistency across servers.

Stateless Application: A system where the application does not rely on local data, making scaling seamless.

5. Description of Content / Step-by-Step Guide

Handling PHP Application Files

In Auto Scaling, every server must have the exact same PHP code. Use a Git-based CI/CD deployment or attach a shared EFS storage so new servers receive identical code instantly.

Handling MySQL Database

The database must not reside inside the Auto Scaling servers. Instead, use a managed database service such as Amazon RDS or Aurora. This ensures all servers share the same database safely and reliably.

Handling Images & Uploaded Files

User uploads, media files, and product images must be stored in Amazon S3. Storing them on local server disk is not possible since servers can be terminated anytime. S3 ensures all servers access the same files consistently.

Handling Cache

Cache must be centralized. Use Amazon ElastiCache (Redis or Memcached). Local server cache will cause inconsistent behaviour and slowdowns during scale-out events.

Handling PHP Sessions

Sessions must not be stored locally. Instead, store them in Redis or DynamoDB. This prevents random logout issues when a load balancer sends users to different servers.

Handling Static Files (CSS, JS, Themes)

Static frontend assets should be served from S3 or deployed to each instance using CI/CD. Optionally, use CloudFront CDN for global speed improvement.

Handling Cron Jobs

Cron jobs must not run on every Auto Scaling server. Use EventBridge, Lambda, or a dedicated worker server to avoid duplicate execution.

6. Common Mistakes

• Storing uploaded files on local disk instead of S3.
• Saving PHP sessions in /tmp, causing random logout.
• Running MySQL on the same server as the application.
• Using local cache instead of centralized Redis.
• Allowing Cron Jobs to run on every server simultaneously.
• Deploying code manually to each server instead of using CI/CD or EFS.

7. Responsibility Breakdown

iCoreHosting Responsibilities:
- Provide Auto Scaling architecture recommendations.
- Ensure load balancer and infrastructure are correctly scaled.
- Advise best practices for distributed environment configuration.

Client Responsibilities:
- Ensure application code is compatible with Auto Scaling.
- Move uploads, sessions, and cache to proper shared storage.
- Approve required AWS services (S3, RDS, Redis, CloudFront).

8. Limitations

Auto Scaling does not fix inefficient code, slow database queries, or poorly optimized images. Websites must follow proper coding and database optimization practices to achieve maximum performance.

9. FAQ

Q: Will my website break if I keep files on local storage?
A: Yes. New servers will not have the same files. All uploads must be stored in S3.

Q: Why can’t I store sessions locally?
A: Users will be logged out randomly because different requests hit different servers.

Q: Do I need to change my MySQL setup?
A: Yes. MySQL must be hosted externally on RDS or Aurora for scaling to work.

Q: How do I handle heavy cache usage?
A: Use Redis (ElastiCache). Local cache is not suitable in a multi-server environment.

Q: Can I continue using cPanel?
A: Auto Scaling typically does not use cPanel. Deployment switches to Git CI/CD or EFS.

10. Summary

AWS Auto Scaling provides stable and scalable performance by automatically adjusting server count during peak and low traffic. To work correctly, all website components—uploads, images, sessions, cache, PHP code, and database—must be stored in centralized services such as S3, RDS, EFS, and Redis. This ensures reliability, consistency, and smooth scaling regardless of traffic volume.

11. Use Case

This architecture is suitable for:

• E-commerce websites with promotional spikes
• Online forums and large community platforms
• News portals and high-traffic media websites
• Seasonal or school-holiday-driven websites
• Booking, reservations, and event systems
• Websites handling user uploads or large media files
• Any platform expecting rapid or unpredictable growth