Moodle on AWS vs. Managed Hosting: The True Cost

Deploying Moodle on AWS might seem like an infrastructure decision, but it's primarily a decision about responsibility. The EC2 bill is easy to compare — and rarely the largest part of the total cost. This article breaks down both models using published figures: what AWS charges, what it explicitly doesn't do for you, and where managed hosting becomes more cost-effective in the overall picture.

TL;DR

AWS doesn't host your Moodle; it rents out compute power. Under the shared responsibility model, the guest operating system, security patches, and application are the customer's responsibility.

The visible bill is misleading. A t3.medium in the São Paulo region costs $0.0672/hour, but egress at $0.15/GB, NAT Gateway at $0.045/hour, and support with a minimum of $100/month often add up to more than the instance itself.

The Moodle calendar waits for no one. General support for Moodle 5.1 ends on October 5, 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 Deploy Moodle on AWS

Discussions about Moodle on AWS costs almost always start incorrectly. Someone opens a calculator, picks an instance, sees a two-digit dollar figure, and concludes, "it's cheap." That number is the floor, not the actual 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 $0.0672/hour on demand, according to a June 2026 survey of public AWS rates. The same instance costs $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 $0.08 per GB-month in São Paulo, with 3,000 IOPS and 125 MB/s baseline included.
Database. You can either deploy a MariaDB on EC2 itself (cheaper, more work) or use RDS (more expensive, less work). A db.t3.medium starts at about $0.068/hour in the cheapest regions — and São Paulo is one of the most expensive in the catalog.

The Part Nobody Puts in 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: $0.15/GB. A Moodle instance serving video lessons directly from the server will blow through that in days.
NAT Gateway. Implementing the "correct" architecture, with your application in a private subnet, you pay $0.045/hour just for the gateway to exist — about $32/month, without a single byte transferred — plus $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 $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 $100/month, and will be discontinued on January 1, 2027, along with Developer and Enterprise On-Ramp. Without a paid plan, you cannot open a technical support ticket.
Currency Exchange. While the bill is in US dollars, if your academic budget is in a different currency, this difference introduces both cost and variance.

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

What Moodle Requires from Your Server in 2026

Versions, PHP, and a Calendar That Doesn't Wait

Moodle 5.1, released on October 6, 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 installations 4.2.3 or higher — those far behind need intermediate jumps.

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

Version	Release Date	General Support Ends	Security Support Ends
Moodle 5.2	April 20, 2026	April 19, 2027	October 4, 2027
Moodle 5.1	October 6, 2025	October 5, 2026	April 19, 2027
Moodle 5.0	April 14, 2025	April 20, 2026	October 5, 2026
Moodle 4.5 (LTS)	October 7, 2024	October 6, 2025	October 4, 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 October 5, 2026 — the same day 5.1 exits general support. Translating this to operations: if you've deployed 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 clear: the older the version, the more vulnerabilities it likely contains. I broke down this cycle in Moodle UFBA: Version, LTS, and VLE Upgrade in 2026.

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" here doesn't mean logged-in users — it refers to web server processes active in memory within the same few-second window. An institution with 800 enrolled students might have 120 concurrent users during an assignment submission and 8 on a Tuesday afternoon.

That's why sizing Moodle on AWS is tricky: the access graph isn't a straight line; it's a saw-tooth pattern. There are predictable peaks (semester start, exam week) and unpredictable ones (a professor releasing a quiz for 400 students at once). A 4 GiB t3.medium can handle a normal day but struggles during exam week — and the autoscaling that would solve this is yet another component to design, test, and pay for. I analyzed this pattern in Moodle UTFPR: What the 2026/2 Peak Teaches About Distance Learning. Add to this the items rarely included in the initial plan: cron jobs 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, and 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 comes out on a Friday night, AWS doesn't apply the patch. When moodledata fills up the disk at 2 AM on exam day, AWS doesn't expand the volume. When cron jobs stop and grades fail to synchronize, AWS doesn't open a ticket — you do, and only with a paid plan.

Hiring AWS is contracting capacity. Hiring managed Moodle hosting is contracting outcomes. They are different products sold under the same budget line item, which is why the comparison often becomes skewed.

Moodle on AWS vs. Managed Hosting: A 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 optimized for Moodle
OS and PHP Patches	Customer's responsibility, by contract	Provider's responsibility, included
Version Upgrades	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, indexes	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 Moodle	For Moodle, in English, during US business hours
Cost	Variable, in dollars, granular	Predictable, in US dollars, by contract
Where it's Unbeatable	Large scale, custom architecture, existing SRE team	Institutions without a dedicated sysadmin for Distance Learning

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

Monthly Cost Simulation for 800 Students

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

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)	$0.0672/h	~49
EBS gp3 — 150 GB	$0.08/GB-month	12
Egress — 300 GB (100 GB free)	200 GB × $0.15	30
NAT Gateway (1 unit, 730 h)	$0.045/h + processing	~33
Snapshots and Offsite Backup	conservative estimate	~10
Infrastructure Subtotal		~232
AWS Support (Business, minimum)	$100/month	100
Total		~332

The most expensive line, which doesn't appear on the bill, is missing: staff hours. In our experience operating distance learning environments, maintaining this setup requires 6 to 20 technical hours per month for routine tasks — patching, monitoring, tested backups, index adjustments — not including the semiannual upgrade windows. At any hourly cost for a senior professional, this line alone surpasses the entire infrastructure subtotal.

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

When Running Moodle on AWS Is the Right Decision

An infrastructure team already exists. With in-house SRE, on-call support, and an IaC culture, Moodle becomes just another workload — and AWS's elasticity has no equivalent in a fixed-price 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 proprietary cloud. International parent companies often mandate that everything runs on the group's AWS account, with centralized tagging and billing. Here, there's 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 capacity you actually use.

When Moodle on AWS Is the Wrong Decision

No dedicated sysadmin exists. If the same person manages 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 peaks twice per semester don't need elasticity; they need stability.
The budget needs to be predictable. A variable dollar bill with unpredictable egress charges is an administrative problem before it's a technical one.
Nobody has tested a restore. Having a snapshot isn't having a backup — a backup is what you've already restored. The painful version of this is in Moodle UFOP: Content Exclusion and How to Save Your Backup.
The real pain is Moodle-related, not server-related. A broken plugin, an outdated theme, or a stuck integration with SGA won't be solved by switching clouds.

Five Common Pitfalls We See with Moodle on AWS

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

None of these are AWS's fault. All are a consequence 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 production distance learning environments for over 15 years — including public institutions, technical schools, and corporate training. Our managed Moodle hosting exists to remove precisely the lines of responsibility that AWS leaves with the customer from your institution.

What's Included:

Stack designed for Moodle, not generic hosting: PHP-FPM with a dedicated pool per instance, tuned OPcache, Redis for sessions, cache, and MUC, MariaDB 10.11+ with binlog for point-in-time recovery, and Moodle cron jobs isolated on their own worker.
Incremental binlog backup every 15 minutes and AES-256 encrypted offsite copy, with a rehearsed — not presumed — restore.
Active monitoring with Grafana and Prometheus, Sentry for application errors, and external verification independent of our own infrastructure. The alert reaches the technical team before a student complaint.
Version updates performed in staging before touching production, including during 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 US business hours, with SLA by severity in contract — provided by the same team that writes the code and designs the architecture, not by Tier 1 reading a script.
Assisted migration from your current provider, including from an existing AWS account, with a guarantee of parity: 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 Get Started: The starting point is a diagnosis of your current environment — Moodle version, students and peak concurrent users, critical plugins, integrations, and moodledata volume. From there, we finalize the scope and monthly value in US dollars, with migration within an agreed-upon window. The form and direct WhatsApp channel are on the product page.

An honest observation: if you already run Moodle on AWS with an in-house team and are satisfied, there's no reason to switch. Our service is for those who discovered they bought capacity when they needed operations.

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 their 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 your environment is hosted.

Third: Will your Moodle be on 5.3 LTS by the first half of 2027? Knowing that it arrives on October 5, 2026, and that 5.1 exits general support on the same day, who performs this upgrade and within what window?

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