AWS Lightsail US$3.5/mo instance reviewed

This is a personal, independent review of the service which I have paid for, and is in no way affiliated with AWS.

As mentioned in the inauguration article, I was in the market for a VPS with excellent internet connectivities to improve my streaming experience for content hosted in certain countries. My household streaming consumption is about 1.6TB per month, of which about a quarter, or 400GB, could use some accelerations.

Frankly, AWS wasn’t even on the shopping list, as I won’t be able to afford their US$0.15/GB of egress data charges — I’ll have to fork out US$60 monthly just for the network fees, which would cost more than all the streaming subscriptions combined. That is until I became aware of Lightsail. Let’s take a look at its price plans:

The 512MB plan is perfect for my use case.

These work a lot like those t2/t3 burstable instances, so you need to know what you’re getting yourself into. Two key metrics to understand here are the CPU Credits and Baseline Performance, which AWS has provided some documentation. The memory configuration of the Lightsail instances are slightly different from that of the t series, but the performance characteristic and throttling mechanism are quite similar. It will perform fine for hosting a website with light traffic and as additionally a network relay. It is not for number crunching or workloads that require high CPU load continuously.

The experience

You will not be getting the full AWS ECS experience. Instead, you will be presented with an easy-to-use portal, specific for Lightsail products, that is very intuitive to use. This is great for first-timers or content creators who wish to spend their time creating content instead of managing cloud instances. You can deploy a fully functional application through one of the 20 blueprints within minutes.

However, you would also lose some control over the security settings. Instead of a full-fledge firewall offered in EC2, you would only get a simple firewall that whitelists specified TCP or UDP ports you specify. It is an allow-all or allow-none ruleset for the specific target port, which works fine for most people. If you need to permit traffic from specific IP addresses or rate limit SSH, you will have to get your hands dirty and deal with ufw or iptables within the instance. There is also no IPv6 support on the Lightsail instances.

Benchmarks

Below are the results of bench.sh and superbench:

One red flag is the disk I/O, it is among the lowest I’ve ever seen on a modern cloud instance. It is on the very low side so the disk-intensive tasks are not going to perform well. 66MB/s reminds me so much of that 500GB SATA/I HDD, although the AWS EBS is going to provide a lot more resiliency behind that year 2002 I/O speed. As for network performance, while the port speed is at 1Gbps, the actual bandwidth seems to be capped at 500Mbps for both upload and download.

Would the US$5/mo plan perform 43% faster?

Nope. 100% more memory and 100% more egress bandwidth are exactly what you’ll get.

In the name of science, I have tried out the 1GB instance to see if its disk and network speed are scaled up in accordance with the charges. To my disappointment, both the disk and network performances are the same for the 512MB and 1GB plans. The CPU performance is the same as long as it is not throttled (i.e. when your CPU credit is >0). When throttling is active, the 1GB plan will be allowed slightly higher performance than the 512GB plan. I am not sure if the even higher plans like the 2GB or 4GB ones would eventually provide 1Gbps bandwidths, but at US$10/mo or US$20/mo, the value proposition diminishes quickly, as I am not getting more cloud performance in proportion to the more money I’m throwing at the higher plans.

The Geekbench v5 results show a single-core CPU score of 678.

Routing and peering

AWS is the biggest player in the public cloud space, I would expect its network peering and transit to be no less than excellent to any destinations. In reality, that is not quite the case. Routing to a China Unicom server in Jiangsu is routed via the Singapore-Japan NTT route, before hitting Shanghai:

  1  *
  2  *
  3  *
  4  *
  5  *
  6  100.65.11.193  0.33 ms  *  Shared Address
  7  52.93.10.70  0.52 ms  *  Singapore amazon.com
  8  52.93.8.70  1.59 ms  *  Singapore amazon.com
  9  52.93.8.57  2.34 ms  *  Singapore amazon.com
 10  ae-6.a01.sngpsi07.sg.bb.gin.ntt.net (116.51.17.129)  6.76 ms  AS2914  Singapore ntt.com
 11  ae-5.r01.sngpsi07.sg.bb.gin.ntt.net (129.250.2.241)  68.56 ms  AS2914  Singapore ntt.com
 12  ae-2.r21.sngpsi07.sg.bb.gin.ntt.net (129.250.3.131)  1.72 ms  AS2914  Singapore ntt.com
 13  ae-17.r31.tokyjp05.jp.bb.gin.ntt.net (129.250.2.243)  70.53 ms  AS2914  Japan Tokyo ntt.com
 14  ae-11.r27.tokyjp05.jp.bb.gin.ntt.net (129.250.2.154)  68.32 ms  AS2914  Japan Tokyo ntt.com
 15  xe-0.cnc-g.tokyjp05.jp.bb.gin.ntt.net (129.250.8.38)  112.67 ms  AS2914  China Shanghai ntt.com
 16  219.158.113.134  119.79 ms  AS4837  China Shanghai ChinaUnicom
 17  219.158.113.105  108.62 ms  AS4837  China Shanghai ChinaUnicom
 18  219.158.18.6  116.50 ms  AS4837  China Jiangsu Wuxi ChinaUnicom
 19  122.194.46.114  120.28 ms  AS4837  China Jiangsu Zhenjiang ChinaUnicom
 20  122.194.47.110  121.38 ms  AS4837  China Jiangsu Zhenjiang ChinaUnicom
 21  58.241.96.82  126.67 ms  AS4837  China Jiangsu Zhenjiang ChinaUnicom
 22  103.56.x.x  114.13 ms  AS4837  China Jiangsu Zhenjiang ChinaUnicom

The route to the China Mobile server in the same region is done via Hong Kong:

  1  *
  2  *
  3  *
  4  *
  5  *
  6  100.65.11.193  0.37 ms  *  Shared Address
  7  52.93.10.70  0.85 ms  *  Singapore amazon.com
  8  52.93.8.114  1.32 ms  *  Singapore amazon.com
  9  52.93.8.105  0.58 ms  *  Singapore amazon.com
 10  223.119.2.213  3.30 ms  AS58453  Singapore ChinaMobile
 11  223.118.4.177  35.05 ms  AS58453  China Hong Kong ChinaMobile
 12  221.183.30.169  78.84 ms  AS9808  China Guangdong Guangzhou ChinaMobile
 13  221.176.24.61  119.26 ms  AS9808  China Guangdong Guangzhou ChinaMobile
 14  221.176.24.205  82.56 ms  AS9808  China Guangdong Guangzhou ChinaMobile
 15  221.183.22.13  110.84 ms  AS9808  China Jiangsu Nanjing ChinaMobile
 16  *
 17  *
 18  223.68.223.118  159.43 ms  AS56046  China Jiangsu Suqian ChinaMobile
 19  112.3.26.18  121.72 ms  AS56046  China Jiangsu Suqian ChinaMobile
 20  112.3.24.47  115.37 ms  AS56046  China Jiangsu Suqian ChinaMobile
 21  112.3.x.x  126.74 ms  AS56046  China Jiangsu Suqian ChinaMobile

The route to a Beijing China Telecom server is transited through the normal 163 backbone and not CN2:

  1  *
  2  *
  3  *
  4  *
  5  *
  6  100.65.8.225  1.05 ms  *  Shared Address
  7  52.93.10.72  2.99 ms  *  Singapore amazon.com
  8  52.93.8.48  2.84 ms  *  Singapore amazon.com
  9  52.93.8.35  0.49 ms  *  Singapore amazon.com
 10  183.91.56.81  1.56 ms  AS4134  Singapore ChinaTelecom
 11  202.97.89.153  59.02 ms  AS4134  China Shanghai ChinaTelecom
 12  202.97.12.189  63.08 ms  AS4134  China Shanghai ChinaTelecom
 13  202.97.24.185  63.59 ms  AS4134  China Shanghai ChinaTelecom
 14  202.97.34.177  97.11 ms  AS4134  China Beijing ChinaTelecom
 15  *
 16  220.181.0.30  97.06 ms  AS23724  China Beijing ChinaTelecom
 17  *
 18  *
 19  *
 20  *
 21  *
 22  *
 23  *
 24  *
 25  *
 26  *
 27  117.50.x.x  92.61 ms  AS9808  China Beijing ucloud.cn ChinaTelecom

The verdict

US$3.5 per month is a reasonable amount for a cloud instance that is close to you physically such that it can provide low latency access. The generous 1TB data per month is a plus. 500Mbps bandwidth is sufficient, although I would prefer AWS to be more forthcoming about this. While we are at it, I urge AWS to provide clear documentation on the CPU/Disk/Network pointing system and throttling mechanism for Lightsail instances – it is easy to upgrade from a smaller to bigger instance but not as trivial vice versa, due to the need to shrink the OS disk before downsizing. The transparency would allow content providers to know which plans are more suitable for their use cases, instead of a trial and error approach. Of course, if the objective is simply to discourage customers from using competitive solutions from DigitalOcean or Vultr, or to drive customers to EC2, then I can comprehend the intended ambiguity.

The disk performance in Lightsail instances is poor, and there is no sugarcoating it. If you are using it to serve static webpages, files or using it to run a DNS server or proxy, then disk performance is irrelevant.

Network routing to China left quite a bit to be desired, congestion happens with a large number of packet loss during evening peak hours, typically from 8pm onwards. If your purpose of using Lightsail is to serve web content to an audience within China or is pulling contents from China servers, you may want to look elsewhere. Access to the rest of the world is good, as you would expect from an AWS data center.