THE STARTING POINT
A cheaper server would not solve the bigger risk
During an AWS cost optimisation project, Bytesol identified that a business-critical automotive application was running on a single t2.xlarge EC2 instance in one Availability Zone.
The platform used a .NET backend hosted in IIS, an Angular frontend and Amazon RDS for its database. Utilisation analysis showed that the production workload could operate on smaller EC2 instances.
Changing the existing server to a smaller instance would have reduced cost, but it would have left the application dependent on one machine. Maintenance, an unhealthy instance or another instance-type change could still interrupt production.
The opportunity was not simply to run a smaller server. It was to remove the server as a single point of failure.
THE DESIGN DECISION
Use rightsizing to improve resilience
Instead of replacing one large server with one smaller server, we redesigned production around a pool of replaceable t2.medium instances.
An Application Load Balancer became the public entry point. It routed requests through a target group to EC2 instances managed by an Auto Scaling group. A launch template based on the latest approved production image ensured replacement instances started with a consistent configuration.
A certificate managed through AWS Certificate Manager was attached to the load balancer, centralising HTTPS certificate management rather than configuring the public certificate separately on every EC2 instance.
WHY THE NEW MODEL MATTERS
Replace capacity gradually instead of stopping production
Under the original design, changing the EC2 instance type meant stopping the only production server. In the new design, capacity could be introduced and replaced progressively.
The load balancer sends new traffic only to healthy targets. This allows a replacement instance to be launched, checked and registered before an older instance is removed.
This does not make every change instant, but it reduces the operational risk created by one irreplaceable production machine. It also makes recovery easier because the Auto Scaling group can replace an unhealthy instance from the launch template.
THE HIDDEN APPLICATION PROBLEM
Multiple servers changed how sessions behaved
Introducing additional EC2 instances exposed the most important application-level challenge in the project: user sessions.
In the single-server environment, the application could keep a user session on the local EC2 instance because every request returned to that same server.
Behind a load balancer, consecutive requests may reach different instances. A user could sign in through the first server and then have their next request sent to the second server, which did not have the locally stored session.
A multi-AZ diagram can look resilient while the application still assumes it is running on one machine.
THE SESSION JOURNEY
A practical bridge, then the stronger solution
CAPACITY THAT FOLLOWS DEMAND
One instance after hours, two for normal business load
The Auto Scaling group was configured around the application's operating pattern. Production could run with one instance outside business hours and two instances during business hours, while CPU utilisation provided the signal for adding more capacity when required.
The maximum capacity of four instances created headroom for higher demand without paying for all four continuously.
This approach linked capacity more closely to business demand. Auto Scaling changed the number of running instances; the launch template defined the t2.medium instance configuration used when new capacity was created.
WHAT TEAMS OFTEN MISS
The architecture diagram is only the beginning
Local state
Uploaded files, cached data and temporary files stored on one EC2 instance will not automatically exist on another. This application did not depend on local files, but the check was essential.
Scheduled work
A task that safely ran once on one server could run multiple times after scaling. Jobs and background processing need to be reviewed before adding instances.
Health checks
A running virtual machine is not always a ready application. Target-group checks need to confirm that the application can genuinely serve traffic.
Burstable performance
T2 instances use CPU credits. CPU utilisation and credit behaviour should be monitored as smaller instances replace a larger one.
Image consistency
The launch template must reference an approved and current production image so replacement instances do not introduce configuration drift.
Deployment duration
Deployments took longer because updates had to move safely across multiple instances. The trade-off was better availability during gradual replacement.
THE RESULT
Lower cost without preserving a single point of failure
The redesigned environment moved production from one t2.xlarge instance to a load-balanced group of t2.medium instances distributed across two Availability Zones.
The client gained a more resilient production model and a practical scaling range of one to four instances. Individual servers became easier to replace, and the application no longer needed to rely on load-balancer stickiness as its permanent session solution.
The main trade-off was deployment time. Updating a group of instances progressively takes longer than updating one server, but the deployment process no longer depends on taking the only production instance through every change.
THE BROADER LESSON
Resilience requires application thinking
Moving from a single EC2 instance to a load-balanced Auto Scaling architecture is not purely an infrastructure exercise.
The AWS components can be configured correctly while the application still carries assumptions from its single-server design. Sessions are one of the most visible examples, but local files, scheduled tasks, health checks and deployment processes can create similar problems.
A phased migration proved valuable in this project. Load-balancer stickiness provided a simple bridge, while Amazon ElastiCache delivered the stronger long-term session architecture after the required library work was completed.
Planning to remove a single point of failure from an AWS application?
Bytesol can help you improve resilience without losing sight of cost, application behaviour or operational reality.Discuss your AWS architecture