Flexus L Daily Ops: Renewal, Bandwidth and Security Group Checks

After a few weeks of running a small Flexus L instance as a student project server, I settled into a short routine I now run in one pass: check renewal, check bandwidth, and audit the security group. None of the three steps is hard on its own, but doing them together once a week has caught the small problems that turn into outages or surprise bills. These are my own notes from doing it on a live instance.

1. Renewal: know the date before the console reminds you

Flexus L instances are billed by the subscription period, so the first thing I check is the expiry date. In the console I open the Flexus L instance list, select the instance, and look at the expiration date on the instance details page. I write the date down in my own calendar with a reminder seven days ahead, because the console reminder alone is easy to miss during exam weeks.

What I check in this step:

• The exact expiry date and whether auto-renew is on or off.
• Whether the current package (vCPU, memory, disk, bandwidth) still matches what the project actually uses.
• Whether any attached service, such as a data disk or an extra public IP, has a different expiry date from the instance itself.

My rule is simple: if the instance is idle for a whole week and nothing depends on it, I let it expire rather than renewing out of habit. If a course project or a small website still depends on it, I renew before the last three days so a payment hiccup cannot take the server down during a deadline.

2. Bandwidth: read the peak, not the average

Flexus L packages include a fixed bandwidth, and the number that matters is the peak, not the daily average. I open Cloud Eye (CES) from the instance details page and look at the outbound bandwidth curve for the last seven days.

What I look for:

• The highest outbound peak and the time it happened. A short spike during a class demo is normal; a sustained high plateau means the package may be too small.
• Any traffic at hours when nobody should be using the server. Unexpected overnight traffic is worth investigating before anything else.
• Whether inbound traffic is also unusual, which can hint at a scan or a misconfigured client retrying in a loop.

On my own instance, the peak is usually a file download during a demo, and the baseline is close to zero. That tells me the current bandwidth is fine and that I do not need a larger package. If the peak were regularly hitting the package ceiling, I would first check what is generating the traffic before paying for more bandwidth.

A quick check from inside the server also helps. I run:

ss -tlnp

to list listening ports, and compare that list against the services I expect to be running. A listening port I do not recognise is a reason to stop and investigate, not something to ignore.

3. Security group: audit every rule, keep only what is used

This is the step that catches the most drift. Security groups accumulate rules over time: a port opened for one test, a wide source range added in a hurry, and then forgotten. I open the security group attached to the instance and read every inbound rule, one by one.

My checklist for each rule:

• Is the port still needed? If the service was removed, the rule goes with it.
• Is the source range as narrow as it can be? A management port such as SSH (22) should never be open to 0.0.0.0/0 if I can restrict it to my own IP addresses.
• Is the protocol and port exactly what the service needs, rather than a wide range such as 1-65535?

In practice, my own instance keeps only a small set of inbound rules: SSH from a narrow source, HTTP (80) and HTTPS (443) for the web service, and nothing else. Everything else stays closed by default.

Inside the server I also verify the SSH setup itself:

# Check that the SSH service is running
systemctl status sshd

# Confirm password login is disabled when key login is in use
grep -E '^(PasswordAuthentication|PubkeyAuthentication)' /etc/ssh/sshd_config

The expected result on my instance is PasswordAuthentication no with PubkeyAuthentication yes. If password login were still on, the narrow security group rule would be the only thing standing between the server and brute-force login attempts, and that is not a position I want to be in.

4. The one-pass routine

Put together, the whole routine takes about fifteen minutes:

What I learned

The useful lesson is not any single setting. It is that the three checks belong together: renewal protects availability, bandwidth protects the budget, and the security group protects the server itself. Checking only one of them leaves the other two to drift. A weekly pass is short, it uses only the console and one SSH session, and it has so far caught every issue on my instance while it was still small.