Why we switched from AWS Lightsail to EC2 for Gitlab

by DevOpsZen — on  ,  ,  , 

Gitlab can do Continuous Integration, Continuous Delivery, and Continuous Deployment within the same web interface. You can host Gitlab CE yourself on your own servers or in a container or on the cloud providers for free.

AWS Lightsail is a new product from AWS, it as simple as digitalocean or linode, one click to setup Gitlab CE.

If you have a large website and looking for managed cloud service please check: Transfon managed cloud service.

AWS Lightsail - Gitlab

AWS Lightsail provides the fixed public IP which can be binded on a Lightsail instance. So when you modify the Lightsail instance the public IP will not change and you don’t have to modify the DNS records which is good.

AWS Lightsail Networking and fixed IP

There is a private IP of the instance similar to AWS EC2, which is using the CIDR 172.26.0.0/16.

The firewall is very simple, you can only control the ports connectivity. It is not allowed to block IP or whitelist IP. You can only do this inside the instance with iptables.

AWS Lightsail Networking and private IP

The private subnet gave me hope to connect with and communicate with the existed AWS VPC. Then we can see there is an advanced feature called VPC peering at the Lightsail settings menu. It is just a on/off button for VPC peering.

AWS Lightsail VPC peering

VPC peering only enables the Two-way communication between 2 VPC, and it is not possible to communication via a ‘middle man’ VPC.

So the problem is you can only do VPC peering from AWS Lightsail VPC to the ‘default’ AWS VPC. We can’t communite with the other custom VPC by default without setting up a proxy. Plus using the ‘default’ VPC is not a best practice.

AWS EC2 marketplace - Gitlab

So, it is better to launch the Gitlab instance inside your existed VPC with a marketplace instance which is providing the same features.