Network operations case study · October 2026
Bandwidth Control on a Satellite Link, and What the Data Showed Next
A research station in Kenya on satellite internet was using data at roughly twice its monthly budget. I applied controls remotely, then analysed 24 days of firewall reports to check whether they worked. They did not fully work, and the data showed why.
A data budget running out halfway through the month.
The station's satellite plan has a monthly data budget, and usage was on pace for roughly twice that amount. Firewall reports for three and a half days showed about 110 GB used, between 27 and 37 GB a day, dominated by video and social media.
Throttle, don't block.
Checking the result with 24 days of data.
Three weeks later I combined 24 daily firewall reports into one analysis. One day's report was missing, and the analysis says so instead of filling the gap.
Expected
Measured
The throttle worked on the traffic it targeted, but that traffic was not the main cause.
Cloud uploads and personal devices.
134 GB of uploads to OneDrive and SharePoint, 126 GB of it in a single day.
About 271 devices on a working day, mostly personal phones on the Wi-Fi.
Still present, but reduced by the throttle.
Specific next steps instead of a general warning.
- Contact the two heavy uploaders and agree a schedule or limit for cloud sync
- Apply per-device limits on the network used by personal phones
- Identify two unknown high-usage devices
- Investigate two unidentified destinations
- Keep the existing app and betting-site blocks
- Confirm the satellite plan's limits with the provider
- Fix the missing daily report so future analysis has complete data
Why I include a fix that did not fully work.
The first fix was reasonable, but only the follow-up data showed it targeted the wrong traffic.
Cloud backup and sync can use more data than all the video on the network.
Stating that one day of data was missing made the analysis more trustworthy, not less.