How to scale and optimize Moodle LMS on AWS

Moodle is an open-source learning management system (LMS). Moodle has more than 300 million users worldwide across both academic and enterprise organizations, and is the world’s most widely used learning platform.

There are many ways to get started with Moodle on Amazon Web Services (AWS). In this blog post, discover how to scale and optimize Moodle once you are already serving students. In this case, you may need to deal with migrating data from an existing platform and making sure the new environment caters to thousands of students and is still a cost effective solution.

Prerequisites

Start by referring to the AWS Moodle Reference Architecture on GitHub. This is a set of AWS CloudFormation templates that allow you to spin up a highly available, elastic, multi-Availability Zone (AZ) Moodle platform that is scalable and built according to Moodle best practices. We built this based on WordPress: Best Practices, as they share a similarly tiered architecture.

Procedure

Launch the stack for your desired Region to get started. To deploy to a Region not listed, you may need to make some small updates to the templates. For example, if you want to deploy to the AWS Africa (Cape Town) Region, replace some of the existing instance types with ones that are available in the region of your choice.

1. Create an Amazon Simple Storage Service (Amazon S3) bucket in your account to store the templates.
2. Git clone or download the CloudFormation templates, and save them locally on your computer. Make any changes required.
3. Update the 00-master.yaml file to refer to the Amazon S3 bucket in your account so it can find all the other nested CloudFormation templates.
4. Upload the updated templates to your Amazon S3 bucket.
5. Go to CloudFormation in the region you want to deploy to, select Create Stack, and point it to the Amazon S3 URL of your 00-master.yaml file in your bucket. This will load up the first template, which will refer to all the other nested templates in that bucket.

If you want to reuse improvements that others have made, browse GitHub for forks of the repo. For example, there is a fork of that repo that has made changes to enable deployment to the Africa (Cape Town) Region. That fork enabled Amazon Aurora MySQL-Compatible Edition instead of Amazon Aurora PostgreSQL-Compatible Edition as the database layer for Moodle.

Now that you have built a highly scalable Moodle platform, lets discuss some considerations of migrating from an existing legacy Moodle platform.

Resolving differences between Moodle versions

According to Moodle Statistics, there are multiple versions of Moodle used in production:

Figure 1. Diagram showing the multiple versions of Moodle used by customers across the world.

The current AWS Moodle Reference Architecture specifies Moodle version 3.8.3. If your current version is different, you have a few options. To stay on the same version, update the 04-web-yaml file in your Amazon S3 bucket to change the version that the reference architecture uses. Alternatively, you can upgrade your current version in place, before migrating the data to the AWS. This choice should be guided by Moodle theme and plugin compatibility with the new version, as well as training requirements for the academic staff, and perhaps students as well.

Choose the database that meets your needs

Moodle can use different types of databases, which are all supported by Amazon RDS. Moodle 3.10 and above includes support for Amazon Aurora. If your existing Moodle platform used MySQL or PostgreSQL instead of Aurora, then you again have a few options. You can modify the 03-rds.yaml CloudFormation templates in your Amazon S3 bucket to match the database used in your legacy setup. Alternatively, if your existing setup is using MySQL, and you choose to run Aurora MySQL in AWS, then you will need to modify your data backup before restoring to Aurora MySQL.

Once you have chosen your database type, you can use AWS Database Migration Service (AWS DMS) and AWS Schema Conversion Tool (AWS SCT) to migrate quickly and securely between databases.

Load testing

One of the pillars of optimizing and scaling Moodle is to obtain a baseline benchmark, which can be achieved by running load tests. To run load tests, you need a replica of your production environment against which to load test. By using the AWS Moodle Reference Architecture, you can simply, quickly, and reliably build replicate Moodle environments for different environments: development, testing, production, etc. These environments can then be shut down when not needed, saving costs. Moodle allows you to natively generate Jmeter test plans, which can be installed on separate Amazon Elastic Compute Cloud (Amazon EC2) instances (or using the Distributed Load Testing on AWS solution) to generate load against your load-testing Moodle environment. This allows you to now effectively plan, scale, and budget for your Moodle platform.

Right size to save costs

Cost is architecture. With a legacy single-instance Moodle setup, it can be cost prohibitive to increase performance. However, with a layered architecture, you can adjust the capacity and performance at the layer that needs it and only pay for what you use, when you use it. Using the process of right sizing, by using Amazon CloudWatch to monitor usage, matched with finance data in AWS Cost Explorer, you can adjust instance types and sizes to your workload performance and capacity requirements at the lowest possible cost.

In the AWS Cost Explorer graph to follow, I demonstrate the impact of right sizing on a Moodle platform running in production.

Figure 2. Screenshot of the AWS Cost Explorer console showing how right sizing has helped to reduce costs, by matching capacity to actual usage

Initially, Amazon Elasticache and Amazon Relational Database Service (Amazon RDS) were the biggest contributors to cost, but over a two-week period, we were able to bring costs inline, without affecting performance or the student experience. Over these two weeks, we managed to decrease daily costs by 59 percent.

Increase savings with AWS Reservation Models

The above costs savings were based on using on-demand instance pricing, which allows you the flexibility to adjust your capacity to match actual usage. But once you’ve reached steady-state, where your usage is consistent and predictable over time, you can take advantage of savings plans and reserved instances, which provide up to 72 percent savings compared to on-demand pricing. If you plan to use Moodle over a one or three-year period, you can reduce your costs significantly. Even if your exam usage is higher than normal usage throughout the year, this can still reduce your costs. Applying this to the Moodle architecture, you could use savings plans for the Moodle instances, reserved instances for the Amazon RDS Moodle database, and  Elasticache reserved nodes for the caching layer.

What’s next and learn more

Now, you’ve seen how simple it is to re-architect Moodle once you have migrated to the cloud. By moving to AWS, you can achieve agility to make quick changes, scaling to meet your demands, in a cost-effective manner. Learn more about cloud computing for education, read about how customers like UCL migrated Moodle to AWS, and find AWS Education Competency Partners.

Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox, or contact us.

Please take a few minutes to share insights regarding your experience with the AWS Public Sector Blog in this survey, and we’ll use feedback from the survey to create more content aligned with the preferences of our readers.