Moodle on AWS vs Managed Hosting: Unpacking the True Cost for UK Firms

Placing Moodle on AWS seems like an infrastructure decision, but it is, first and foremost, a decision about responsibility. The EC2 bill is the easy part to compare — and it's almost never the largest part of the overall cost. This article breaks down both models with published figures: what AWS charges, what it explicitly doesn't do for you, and at what point managed hosting becomes cheaper in the total bill.

TL;DR

• AWS doesn't host your Moodle. It rents out machines. Under the shared responsibility model, the guest operating system, security patches, and the application are the customer's responsibility.
• The visible bill is misleading. A t3.medium in São Paulo costs US$ 0.0672/hour, but egress at US$ 0.15/GB, NAT Gateway at US$ 0.045/hour, and support with a minimum of US$ 100/month often add up to more than the instance itself. *Note: These are US dollar prices, and actual costs for UK businesses will depend on exchange rates.*
• The Moodle calendar waits for no one. General support for Moodle 5.1 ends on 05/10/2026 — the same date Moodle 5.3, the next LTS, is released.
• The right question isn't "how much does the server cost", it's "who wakes up at 3 AM".

What goes into the cost when you run Moodle on AWS

The conversation about Moodle on AWS costs almost always starts incorrectly. Someone opens a calculator, chooses an instance, sees a two-digit dollar figure, and concludes that "it's cheap". That figure is the floor, not the price.

The visible part of the bill

• EC2 (compute). In the South America (São Paulo) region, a t3.medium — 2 vCPU and 4 GiB — costs US$ 0.0672/hour on demand, according to a June 2026 survey of public AWS rates. The same instance costs US$ 0.042/hour in us-east-1. São Paulo is expensive, and it's where latency for your students makes sense.
• EBS (disk). A gp3 volume is around US$ 0.08 per GB-month in São Paulo, with 3,000 IOPS and 125 MB/s baseline included.
• Database. Either you set up MariaDB on the EC2 instance itself (cheaper, more work) or use RDS (more expensive, less work). A db.t3.medium starts at around US$ 0.068/hour in the cheapest regions — and São Paulo is one of the most expensive in the catalogue.

The part no one puts on the spreadsheet

• Egress. The first 100 GB per month are free and shared across regions and services. After that, São Paulo is the most expensive region in the world for data egress: US$ 0.15/GB. A Moodle instance serving video lessons from its own server will exceed this in days.
• NAT Gateway. Following the "correct" architecture, with the application in a private subnet, you pay US$ 0.045/hour just for the gateway to exist — around US$ 32/month, without a single byte transferred — plus US$ 0.045 per GB processed. There is no free tier.
• CPU Credits. t3 instances are burstable. In Unlimited mode (the default), when the 24-hour average CPU usage exceeds the baseline, AWS charges US$ 0.05 per excess vCPU-hour. Moodle with heavy cron jobs and grade reports can easily exceed the baseline.
• Support. The legacy Business plan charges based on spending tiers (10%, 7%, 5%, 3%) with a minimum of US$ 100/month, and will be discontinued on 01/01/2027, along with Developer and Enterprise On-Ramp. Without a paid plan, you cannot open a technical support case.
• Exchange Rate. The bill is in US dollars; your academic budget is in pounds sterling. This difference incurs costs and introduces variability.

None of this is an AWS trap. It's their model: granular components, charged individually, assembled by you. The error lies in comparing this model with a managed service as if they were the same thing.

What Moodle requires from the server in 2026

Versions, PHP, and a calendar that waits for no one

Moodle 5.1, released on 06/10/2025, requires PHP 8.2 minimum (with support for 8.2.x, 8.3.x, and 8.4.x), the sodium extension, max_input_vars ≥ 5,000, and 64-bit PHP. For the database: PostgreSQL 15+, MySQL 8.4+, MariaDB 10.11+, or SQL Server 2017+. The upgrade path only starts from 4.2.3 or higher installations — those far behind need intermediate jumps.

The official calendar, published by Moodle Developer Resources, is the most significant factor in a hosting decision:

Version	Release	End of General Support	End of Security Support
Moodle 5.2	20/04/2026	19/04/2027	04/10/2027
Moodle 5.1	06/10/2025	05/10/2026	19/04/2027
Moodle 5.0	14/04/2025	20/04/2026	05/10/2026
Moodle 4.5 (LTS)	07/10/2024	06/10/2025	04/10/2027

The cadence is fixed: a major version every six months (April and October), minor corrections every two. The next LTS is Moodle 5.3, scheduled for 05/10/2026 — the same day 5.1 exits general support. Translating this to operations: if you've set up Moodle on AWS and don't have someone responsible for planning upgrades twice a year, your environment will age on its own. Moodle's security documentation is direct: the older the version, the more vulnerabilities it likely contains. I broke down this cycle in Moodle UFBA: version, LTS, and AVA upgrade in 2026 (an example from the Brazilian market).

RAM, cron, and the Monday peak

The official documentation uses a conservative rule of thumb: 10 to 20 concurrent users per GB of RAM. And "concurrent" there isn't just logged-in users — it's web server processes alive in memory within the same few-second window. An institution with 800 enrolled students might have 120 concurrent users during an activity submission and 8 on a Tuesday afternoon.

This is why sizing Moodle on AWS is tricky: the access graph isn't a straight line, it's a saw-tooth. There are predictable peaks (start of term, exam week) and unpredictable ones (a lecturer releasing a quiz for 400 students all at once). A 4 GiB t3.medium can handle a normal day but will struggle on an exam Tuesday — and the autoscaling that would solve this is yet another component to design, test, and pay for. I analysed this pattern in Moodle UTFPR: what the 2026/2 peak teaches about EAD (an example from the Brazilian market). Add to this items rarely included in the initial plan: a cron job every minute on an isolated worker, MUC cache in Redis, sessions outside local disk, and a secure place for moodledata to grow.

Where AWS's responsibility ends and yours begins

This is the point that decides the comparison, and it's documented by Amazon itself. AWS is responsible for the security of the cloud: physical facilities, hardware, hypervisor, host operating system. The customer is responsible for security in the cloud:

• Guest operating system, including updates and security patches
• All application software you install — PHP, web server, database, and Moodle itself
• Firewall configuration (security groups)
• Identity, encryption, log retention, and network design

When a Moodle security alert is issued on a Friday night, AWS doesn't apply the patch. When moodledata fills the disk at 2 AM on exam day, AWS doesn't expand the volume. When cron stops and grades fail to synchronise, AWS doesn't open a case — you do, and only with a paid plan.

Hiring AWS is hiring capacity. Hiring managed Moodle hosting is hiring outcomes. They are different products sold under the same budget line, which is why the comparison often goes awry.

Moodle on AWS vs managed hosting: the line-by-line comparison

Dimension	Moodle on AWS (self-managed)	Managed Hosting
Provisioning	You design VPC, subnets, security groups, EC2, EBS, database, and backup	Environment delivered ready and optimised for Moodle
OS and PHP Patching	Customer's responsibility, by contract	Provider's responsibility, included
Version Upgrade	Customer's responsibility (at least 2 windows per year)	Provider's responsibility, with staging before production
Moodle Tuning	You research OPcache, MUC, PHP-FPM pool, indices	Already configured for Moodle's IO/CPU pattern
Monitoring	Raw CloudWatch; dashboards and alerts are your responsibility	Metrics, alerts, and incident response included
Backup and Restore	Snapshot configured by you; restore rarely rehearsed	Routine with PITR and validated restore
Support	Paid plan separately, for infrastructure — not for Moodle	For Moodle, in English, during UK business hours
Cost	Variable, in US dollars, granular	Predictable, in pounds sterling, by contract
Where it's unbeatable	Large scale, custom architecture, existing SRE team	Institutions without a dedicated sysadmin for EAD

The second-to-last line is the most important. AWS support solves AWS problems. If Moodle is slow because the mdl_logstore_standard_log table has exceeded 40 million rows, that's not an infrastructure issue — it's Moodle knowledge, and no Amazon plan covers it.

Monthly cost simulation for 800 students

Estimate built from the published rates above, for application separate from the database, 150 GB total disk space, and 300 GB egress per month. In US dollars, excluding taxes and exchange rates.

Item	Calculation Basis	USD/month
EC2 application (8 GiB, 730 h)	2× the t3.medium rate in São Paulo	~98
EC2 database (t3.medium, 730 h)	US$ 0.0672/h	~49
EBS gp3 — 150 GB	US$ 0.08/GB-month	12
Egress — 300 GB (100 GB free)	200 GB × US$ 0.15	30
NAT Gateway (1 unit, 730 h)	US$ 0.045/h + processing	~33
Snapshots and offsite backup	conservative estimate	~10
Infrastructure Subtotal		~232
AWS Support (Business, minimum)	US$ 100/month	100
Total		~332

The most expensive line, which doesn't appear on the bill, is missing: staff hours. Maintaining this environment requires, in our experience operating EAD, 6 to 20 technical hours per month for routine tasks — patching, monitoring, tested backups, index adjustments — in addition to the semi-annual upgrade windows. At any senior professional's hourly cost in the UK, this line alone exceeds the entire infrastructure subtotal.

The 2026 Flexera report, with 753 cloud decision-makers, estimates 29% waste on global IaaS and PaaS spending — the first increase in five years. Orphaned volumes, forgotten snapshots, and oversized instances are not exceptions: they are the market average. It is because of this gap between the estimated and actual bill that our managed Moodle hosting operates with a fixed price in pounds sterling. The sizing risk remains on our side.

When Moodle on AWS is the right decision

I won't pretend the answer is always "managed". There are scenarios where Moodle on AWS is technically superior:

• An infrastructure team already exists. With SRE, on-call support, and an IaC culture in-house, Moodle becomes just another workload — and AWS's elasticity has no equivalent in a fixed plan.
• Real and volatile scale. Above a few thousand concurrent users with sudden seasonal peaks, autoscaling and load balancing pay for themselves.
• Corporate requirement for a private cloud. International parent companies often mandate that everything runs on the group's AWS account, with centralised tagging and billing. Here there is no debate.
• Deep integration with the AWS ecosystem. If academic data already resides in RDS, S3, and Redshift, bringing the LMS closer reduces latency and egress.

In these cases, the cost is justified by a capacity you actually use.

When Moodle on AWS is the wrong decision

• No dedicated sysadmin exists. If the same person looks after Moodle, email, Wi-Fi, and the academic system, the environment will go months without patches. That's statistics, not pessimism.
• Demand is predictable. 800 students with a peak twice a term don't need elasticity; they need stability.
• The budget needs to be predictable. A variable US dollar bill, with unpredictable egress charges, is an administrative problem before it's a technical one.
• No one has tested a restore. Having snapshots isn't having a backup — a backup is what you've already restored. The painful version of this is in Moodle UFOP: content deletion and how to save the backup (an example from the Brazilian market).
• The real pain is Moodle-related, not server-related. A broken plugin, an outdated theme, or a stalled integration with the SGA won't be solved by changing clouds.

Five common pitfalls we see with Moodle on AWS

1. Serving video from the EC2 instance itself. The fastest way to a three-digit egress bill. Video should go to object storage with a CDN in front, not to the application's disk.
2. moodledata on the root volume. The directory grows endlessly with uploads, cache, and course files. When it fills the system volume, Moodle doesn't just slow down: it stops.
3. Burstable instance without credit alarms. The environment doesn't crash, degradation isn't obvious, and the charge for excess vCPU-hours only appears at the end of the month.
4. Moodle cron in the system's crontab, without isolation. Competes for CPU with student requests exactly at peak times and can even run in duplicate after a reboot.
5. Backup without restoration testing. Daily snapshots in the console provide a false sense of security that is only disproven on the worst possible day. Restore needs to be rehearsed on a schedule.

None of these are AWS's fault. All are consequences of operating a complex application without someone whose job it is to operate it.

How Agathas Web solves this

I've worked with Moodle since 2008, and Agathas Web has supported EAD environments in production for over 15 years — public institutions, technical schools, and corporate training. Our managed Moodle hosting exists to take exactly the lines of responsibility that AWS leaves with the customer away from the institution.

What's included:

• Stack designed for Moodle, not generic hosting: PHP-FPM with a dedicated pool per instance, optimised OPcache, Redis for sessions, cache, and MUC, MariaDB 10.11+ with binlog for point-in-time recovery, and Moodle cron isolated on its own worker.
• Incremental binlog backup every 15 minutes and AES-256 encrypted offsite copy, with rehearsed — not presumed — restore.
• Active monitoring with Grafana and Prometheus, Sentry for application errors, and independent external verification of our own infrastructure. Alerts reach the technical team before a student complaint.
• Version updates performed in staging before touching production, including the two annual windows of the official calendar, with plugins and institutional themes validated.
• Operational security: WAF and DDoS protection at the edge, SSL with automatic renewal, fail2ban and rate limiting on critical routes, OS hardening, and log auditing.
• Senior support in English, during UK business hours, with SLA by severity in contract — provided by the same team that writes the code and designs the architecture, not by level 1 staff reading a script.
• Assisted migration from your current provider, including an existing AWS account, with parity guarantee: users, courses, grades, certificates, forums, and assignments. You validate in a staging environment and approve in writing before cut-over.
• Portability: if you ever wish to leave, we provide a complete backup. We do not engage in technical lock-in.

How to contract: The starting point is a diagnosis of the current environment — Moodle version, students and concurrent users at peak, critical plugins, integrations, and moodledata volume. From this, we finalise the scope and monthly value in pounds sterling, with migration in an agreed window. The form and direct WhatsApp channel are on the product page.

An honest observation: if you already run Moodle on AWS with your own team and are satisfied, there's no reason to switch. Our case is for those who discovered they bought capacity when they needed operation.

Conclusion: how to decide in an afternoon

Answer three questions in writing.

First: Is there currently someone whose formal responsibility includes applying Moodle and operating system security patches within a week of the announcement? If the answer is "more or less", the self-managed model already presents more risk than savings.

Second: When was the last tested backup restoration, not just configured? Without a date, this is the most urgent item on the list — regardless of where the environment is located.

Third: Will your Moodle be on 5.3 LTS by the first half of 2027? Knowing that it arrives on 05/10/2026 and that 5.1 exits general support on the same day, who will perform this upgrade and in what window?

If all three answers are solid, AWS is an excellent home for your Moodle. If any of them posed a challenge, the next step is to discuss managed Moodle hosting: half an hour of conversation will determine if it makes sense, and a diagnosis of your current environment comes before any proposal.