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.
Leave a Reply