Why we switched from AWS Lightsail to EC2 for Gitlab
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 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.
There is a private IP of a similar instance to AWS EC2: the CIDR 172.26.0.0/16.
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.
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.
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.
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.