Why we switched from AWS Lightsail to EC2 for Gitlab

Share this post:

Gitlab offers continuous integration, continuous delivery, and continuous deployment within the same web interface. Gitlab CE can be hosted on your own servers, in a container, or freely on Cloud providers.

AWS Lightsail is a new product from AWS. It is as simple as DigitalOcean or Linode. Set up Gitlab CE with one click.

AWS Lightsail - Gitlab

AWS Lightsail provides a fixed, public IP which can be bound onto a Lightsail instance. An advantage is that when you modify the Lightsail instance, the public IP will not change and you needn’t modify the DNS records.

AWS Lightsail Networking and Fixed IP

There is a private IP of a similar instance to AWS EC2: the CIDR

The firewall is very simple, and you can only control the port’s connectivity. It is not permitted to block IPs or to whitelist IPs. You can only do this within the instance with iptables.

AWS Lightsail Networking and private IP

The private subnet gave me hope that I could connect and communicate with the existing AWS VPC. We can see that there is an advanced feature called VPC-peering on the Lightsail settings menu. It is just an on/off button for VPC-peering.

AWS Lightsail VPC peering

VPC peering only enables two-way communication between 2 VPCs, and it is not able to communication via a ‘middle man’ VPC.

Consequently, the problem is that you can only do VPC-peering from AWS Lightsail VPC to the ‘default’ AWS VPC. We couldn’t communicate with the other custom VPC by default without setting up a proxy. Also, using the ‘default’ VPC is not a best practice.

AWS EC2 marketplace - Gitlab

In conclusion, it is better to launch the Gitlab instance from within your existing VPC with a marketplace instance that provides the same features.

If you have a large website or system and you are looking for managed Cloud services, check out the managed Cloud service provided by Transfon. We can manage your in-house Gitlab CI/CI system.