Managing network security across multiple cloud instances can get complicated. Each server needs different rules based on its use. Your web servers need to talk to the world, but your databases should stay locked down. Your production environment requires stricter rules than staging. And when you’re scaling quickly, you can’t manually configure every instance from scratch.
That’s where Security Groups come in.
What Are Security Groups?
Think of a Security Group as a reusable firewall template. Instead of configuring security rules on each instance individually, you create a Security Group once, defining which traffic is allowed in and out, and then apply it to one or more instances.
You can set rules for specific protocols (TCP, UDP, ICMP, or all traffic), choose which ports to allow, and specify which IP ranges can access them. Then you’re done!
Apply that same group to your web servers, your app servers, your database, or anywhere else you need those same rules.
Why This Matters
Consistency across your infrastructure.
When you apply the same Security Group to 50 instances, they all get identical security rules. No more wondering if you configured one instance slightly differently from the others.
Simple and flexible security for different environments.
Your production environment might have a strict Security Group that only allows HTTPS from the public internet. The staging environment could be more permissive, allowing SSH for debugging. Your database might have one group that says, “only talk to app servers.” Create them once, reuse them everywhere.
More secure overall setup.
By forcing you to think through your traffic flow, Security Groups naturally lead to a more secure setup. You’re less likely to accidentally leave a database exposed to the public internet.
Real-World Examples
A typical web application: Your web servers get a Security Group allowing HTTP and HTTPS from anywhere, plus SSH from your admin IPs. Your app servers get a different group that only accepts traffic from the web servers on port 8080. Your database gets its own group that strictly allows port 3306 (MySQL) only from the app servers. If your database ever gets compromised, an attacker can’t immediately pivot to the web tier because the network itself prevents it.
Multi-environment setup: You maintain separate Security Groups for staging and production. Staging allows SSH access for troubleshooting. Production doesn’t. This prevents mistakes, meaning someone can’t accidentally start debugging a production database via SSH when they are meant to use staging.
Microservices communication: Each microservice has its own Security Group. The API gateway can talk to the auth service. The auth service can talk to the data layer. But the data layer can only accept traffic from the auth service, not directly from the API gateway. This “least privilege” approach limits the fallout if one service is compromised.
How to Get Started
You’ll find Security Groups right in your Leaseweb Public Cloud dashboard, under the Security Groups tab. Creating one takes a few minutes: give it a name, add your rules (protocol, port, IP range), and you’re set.
When you launch a new instance, you can attach Security Groups right away.
Already have instances running? You can add or change their Security Groups at any time. Just stop the instance, update the groups, and start it back up.
Conclusion
Security Groups simplify something that’s traditionally been tedious and error-prone: managing network access to your servers. You spend less time configuring, fewer mistakes get made, and your infrastructure naturally ends up more secure.
If you’re already running instances on Leaseweb Public Cloud and want to tighten up your network security. Check out the Security Groups tab in your dashboard to get started.