How to Upscale Your AWS Lightsail Instance

In the dynamic realm of cloud computing, staying ahead of the curve is essential to meet the ever-growing demands of modern applications. Within this landscape, the optimization of your AWS Lightsail instance stands as a pivotal step. Amazon Web Services (AWS) Lightsail provides a user-friendly platform for quick deployment, but as your projects flourish, so does the need for greater resources. This is where the process of “upscaling” your Lightsail instance shines.

In this article, we will embark on a journey to discover the intricacies of upgrading your AWS Lightsail instance. We will delve into the nuances of predicted performance, memory considerations, and the crucial decision between scaling up and scaling out. Along the way, we will explore the process of taking snapshots, harnessing the power of static IPs, and effectively launching a new Lightsail instance. Whether you are a business seeking enhanced performance or an individual with ambitious digital aspirations, understanding the process of upscaling within AWS Lightsail can be a game-changer.

So, join me as I explore the pathways to optimizing your AWS Lightsail experience. From the technical considerations to the strategic decisions, this article will equip you with the knowledge needed to navigate the realm of upscaling and ensure your digital presence thrives in the face of escalating demands.

Remember, the cloud offers not just a space to host your applications but a canvas to paint your digital dreams. And upgrading your AWS Lightsail instance is a significant brushstroke in that masterpiece.

In this article I will delve into the following topics:

• Predicted AWS Lightsail performance, sustainable vs. burstable
• AWS Lightsail Instance Memory considerations
• Other indications for the need to scale up
• Scale up vs. scale out
• Taking a snapshot
• Using a static IP
• Launching a new AWS Lightsail instance
• Assigning the Static IP
• When does AWS Lightsail scaling out make more sense

Predicted AWS Lightsail performance, sustainable vs. burstable

In many cases, CPU usage is an excellent indicator of the load on your server. This is why it is of paramount importance to keep an eye on your CPU load. Furthermore, AWS Lightsail instances provide you with an escalating level of CPU capacity, based on your instance type. When you’re just starting out, it is perfectly ok to start out with the smallest AWS Lightsail instance you can afford. But as the load on your server increases, hopefully by increased business, you should pay closer attention to the load on your CPU.

There are two key terms to remember: CPU Utilization, and CPU Remaining Burst Capacity.

CPU Utilization

So long that you’re keeping your AWS Lightsail instance’s CPU utilization within the allotted “sustainable zone” for the most part, you’ll be ok, from a CPU point of view.

CPU Burst Capacity

How can you tell that your CPU burst usage is “sustainable”? By looking at the curve for your CPU Remaining Burst Capacity graph.

Monitoring

To automate monitoring of these indicators, you can setup alarms for you AWS Lightsail instance. There are two alarms that you can setup, and I recommend setting both up. The first is CPU Utilization Alarm.

The other alarm type is CPU Burst Capacity. This alarm fires when your CPU burst capacity drops below a certain limit you indicate.

These two alarms can give you a clear picture when your CPU load becomes unsustainable, and allow you a bit of time to either check what is causing the high CPU load and fix it, or consider upgrading if necessary.

AWS Lightsail Instance memory considerations

Another case for considering upgrading your AWS Lightsail instance is when you notice your server is low on memory. The indications for this are slightly more subtle, and can usually be determined by running free -h (on Linux) to notice memory utilization.

Being low on memory can cause your system to be less responsive, or even hang, without particularly overloading the CPU. Yet, being low on memory may sometimes load the CPU, as it tries to manage memory utilization. I learned this the hard way, as at one point, one of my systems kept completely shutting me out, becoming completely unresponsive, with spiking CPU load. I couldn’t even log in to it, to see what was happening! Then I realized that my instance didn’t have swap memory configured, and configuring it saved the day for me. I didn’t have to upgrade yet! A very helpful article that helped me configure swap is written by Mukesh’s Techspace.

Other indications for the need to scale up

There are two other indications that one should consider for scaling up: Storage and Transfer.

Luckily storage usage typically grows slowly. But nevertheless, storage usage should be monitored. As soon as there are signs that storage usage grows beyond 80% of total capacity, upscaling should be considered, and implemented urgently. Full storage can wreck havoc on your system, barring you from logging in, and freezing up your application.

Traffic usage on the other hand is a little bit trickier to evaluate and notice. But having done some rough calculations, I believe a traffic average of 1,400 MBytes per hour, when considered at the weekly average, would approach the 1TB limit for the smallest AWS Lightsail instance. But mind you, this total is for the sum of incoming and outgoing traffic.

Scale up vs. scale out

In systems architecture there is a concept of scaling up vs. scaling out. Scaling up essentially means adding resources to your server, in our case your AWS Lightsail instance. Scaling out would mean to add more instances, and distribute the load amongst them.

Each of these concepts has its merits. Scaling up is the simpler of the two. But if you’re building an application that can potentially become global, with many thousands of users, and perhaps waves of unpredictable load, then scaling out becomes the better choice. However, scaling out has to be designed from the get-go.

In this article, we’re more concerned with the simple scaling up solution for enhancing the performance of your AWS Lightsail instance and application running on it. Scaling out, is out of scope for this article.

Scaling up your AWS Lightsail instance is actually the process of replacing it with a bigger instance. However, this replacement can be carried out methodically with little planning, and minimal effort. Very little effort will be required at the application level, if any.

Taking a snapshot

Scaling up will however require a bit of down time for your application. How long the downtime is, depends on how big your initial AWS Lightsail instance is. But typically, this can all be completed within an hour or less.

The first task to complete, would be to shutdown your instance, and take a snapshot of it. Although you can take a snapshot while your instance is running, but typically I recommend you shut down your instance first, so that your snapshot captures the system at an idle state.

Using a static IP

This is important because if you are using a static IP, I would assume your DNS address is pointing to this IP.

If you are not using a static IP address as shown above, then you will need to carry out an additional step later on. I’ll address this as we move along.

Launching a new AWS Lightsail instance

To proceed with upscaling your AWS Lightsail instance, you will now need to launch a new instance, with the upgraded specifications. However, this time, you need to launch the new instance directly from your snapshot, as shown below:

When you launch your instance this way, everything on you original instance will be copied to your instance. But you can now choose a bigger instance type than the one you started with. For example if you started with an instance that had 1 GB memory, you can now launch an instance with 2 GB memory.

Also note that you cannot select a smaller instance type than the one the you have started with. So in fact, once you upscale, you can no longer downscale in the future, using this same method, unfortunately.

Assigning the static IP

Your next step would be to assign the static IP that you had for your initial AWS Lightsail instance to the new instance. But in order to assign that same address, you will have to detach it first from your initial instance.

Once you detach the static IP (note its name – in the figure above it is demo-static), you can now attach it to your new instance. Note that your new instance, after you’ve created it from the snapshot, should be running.

With this step, you would have completed the upgrade. Your application running on your new instance, and your DNS would be pointing to the new instance.

If you were not using a static IP

If you were not using a static IP for your initial instance, this might be a good time to start using one! But if for any reason you do not wish to use one, (for example if you were using the IPv6 address instead) then what you need to do, is point your DNS address record to the new IPv6 address of the new instance. This change in DNS will take a bit of time to propagate through the internet, again typically less than an hour.

Of course your situation could be completely different than my assumption here. You can always reach to me here, and I can evaluate and assist you in determining what can be done.

When does AWS Lightsail scaling out make more sense

Scaling out versus scaling up presents a choice with key considerations. Relocating the database tier is a crucial aspect, often involving a database-as-a-service approach for effective scaling.

Scaling out expands resources horizontally, not just replicating instances. A load-balanced setup includes components like load balancers.

However, scaling out comes at a higher cost due to added resources. The benefits extend beyond performance, offering fault tolerance and redundancy.

It’s noteworthy that scaling out isn’t limited to load balancing. Moving the database tier separately is an option, albeit with potentially reduced fault tolerance.

In conclusion, weighing the costs against benefits is crucial. Scaling out, with its resilience and performance enhancements, is apt for businesses managing the expenses.

Conclusion: Enhance you AWS Lightsail instance’s performance by upscaling

In this article, I discussed the process through which you can safely and efficiently scale up your AWS Lightsail instance. I discussed the indication for a need to scale up, from CPU utilization and Memory consumption, to other indications to consider.

The process of scaling up involved taking a snapshot, reusing your static IP, and your snapshot to create a new AWS Lightsail instance, and be up and running in less than an hour.

Scaling up is not the only choice you have, but it is the easiest, quickest, and most probably the most cost effective to consider. Other alternatives to consider would be to scale out, whether by separating your data tier into a separate AWS Lightsail instance, or by utilizing a database-as-a-service. In addition, you can also consider load balancing two AWS Lightsail instances, and using a database-as-a-service for improved performance and reliability.

I hope this article has provided some help to you one way or the other. Please feel free to comment below if you have any questions or feedback. Also, you can always reach out to me here.