Education & E-Learning · Cloud Architecture
A Resilient AWS Foundation for a Prominent Education Platform in Qatar
A learning platform that ran from one shared hosting account is now designed as a secure, multi-zone AWS environment, built as code, released safely and ready to grow with demand, all inside an account the institute owns.
14 wks
Planned, kick-off to go-live
2+
Availability zones for the web tier
10–20 min
Design target, approval to live
5–10 min
Design target, rollback time
Platform Type: E-learning web application
Framework: Multi-zone, auto-scaling AWS
Basis: Architecture → Go-live
The Challenge
One Server, Manual Releases and No Room to Grow
The institute’s learning platform served students in Qatar and abroad from a single shared hosting account. It worked, but the setup had limits. One server held everything. Releases were mostly manual. There was no easy way to add capacity when demand rose, or to recover quickly if something failed.
The institute also wanted to keep full ownership of its cloud account, and to know exactly who could change what.
الموثوقية
The platform should keep running if a server, or even a whole data centre building, fails.
Speed for learners
Pages and course media should load quickly for students in Qatar and elsewhere.
Security by default
Student records and payments protected at every layer.
Repeatable releases
New versions delivered safely, in minutes, with an easy way back.
Predictable cost
A clear monthly budget, with alerts, and room to grow.
Ownership
The institute holds the account. We work inside it with limited, recorded access.
Project Snapshot
The Engagement at a Glance
| Item | Detail |
|---|---|
| العميل | A prominent educational institute in Qatar |
| Sector | Education and e-learning |
| المنصة | A web application for learners in Qatar and around the world: course videos, documents, quizzes and online payments |
| Cloud | Amazon Web Services (AWS), Frankfurt region |
| Our role | Cloud architecture, infrastructure as code, deployment pipeline, and a review of the application for cloud readiness |
| Planned duration | About 14 weeks from kick-off to go-live |
| التكنولوجيا | CloudFront, AWS WAF, Application Load Balancer, EC2 Auto Scaling, RDS, ElastiCache, SQS, S3, Route 53, Secrets Manager, CloudWatch, Image Builder, Terraform, GitLab CI, Laravel and PHP 8.3 |
The Carmatec Approach
Six Principles Behind the Build
Each principle answers one of the institute’s needs, from account ownership to a design that starts modest and grows without redesign.
The client owns the account
Access is limited to what each person needs, with a second sign-in code (MFA) required. There are no shared logins. Every manual change is written down, with how to undo it.
Everything is built as code
We describe the whole environment in Terraform, a tool that builds cloud resources from text files. Before any change, a plan shows exactly what will be created, changed or removed, and a person approves it first. The same files can rebuild the environment if it is ever lost.
Prove it small first
A staging environment is built from the same setup script that later builds production. People in Qatar time their connection to the candidate AWS regions, so the region is chosen with data, not assumption.
Review the application, not just the servers
Moving a platform to the cloud is partly an application job. We ran an AI-assisted readiness review of the code against a deployment checklist. It produced a ranked list of changes: moving uploaded files to cloud storage, keeping sign-in sessions outside the servers, handling traffic that arrives through a content delivery network, and removing settings that were tied to one host. We then estimated the hours for each.
Build once, deploy many
One package is built and moved from staging to production unchanged. The pipeline signs in to AWS with short-lived credentials, so no long-term password or key is stored. A person approves each production release.
Plan for growth
The design starts modest and grows without redesign. More servers, a separate worker tier, standby copies of the database and cache, and a queue service can be switched on as demand rises.
The Solution
A Multi-Zone Architecture With Stateless Servers
Learners reach the platform through a content delivery network (CloudFront) protected by a web firewall (AWS WAF). Requests go to a load balancer and on to servers spread across two or more availability zones. An availability zone is a separate data centre building within a region. The servers hold no data of their own, so any server can be replaced at any moment. Data lives in managed services.
What each layer does
| Layer | What it does |
|---|---|
| At the edge | CloudFront keeps copies of files near learners and serves paid content only through signed links. AWS WAF filters harmful traffic, limits repeated sign-in attempts and applies the institute's country-level access policy. DNS runs on Route 53. |
| Application tier | Identical web servers in an Auto Scaling group, started from a standard server image. Workers that send emails and process imports run in their own group and scale with the size of the job queue. A load balancer checks every server's health and spreads the traffic. |
| Data and queues | A managed MySQL database (RDS), with a standby copy in a second zone as demand grows. A managed in-memory store (ElastiCache) for cache and sign-in sessions, with a replica for automatic failover. Amazon SQS holds background jobs durably, with a dead-letter queue for anything that keeps failing. Course files sit in private S3 storage. |
| Operations | Secrets Manager holds passwords and keys. CloudWatch collects logs and raises alarms. CloudTrail records every account change. Image Builder builds a fresh patched server image on a schedule. Budget alerts watch cost from day one. |
What Made the Difference
Engineering Decisions That Matter
Choosing the region with data
People in Qatar time their connection to candidate AWS regions before anything regional is built. The region is confirmed from the numbers.
Stateless servers
Sessions live in the cache and files in S3. A server can be stopped and replaced without anyone noticing.
Paid content stays paid
Course videos and documents are private. They open only through time-limited signed links.
Servers from an image
Every server starts from one tested image, built from a script rather than copied from a running machine. A failed server is replaced in minutes. The image is rebuilt on a schedule to pick up security patches.
Queues built to survive repeats
Background jobs are safe to run twice. Scheduled tasks run on one server only. A durable queue and a self-scaling worker group take over as volume grows.
Secrets never in code
Passwords are generated during setup and stored in a secrets service. The deployment pipeline holds no stored keys.
Email left undisturbed
DNS moves to Route 53 only after every email record is copied and tested, so staff email is not interrupted.
Cost under control
Budget alerts from the first day. A staging environment without expensive networking parts. Reserved pricing considered only after real usage is known.
الأمن
Security by Design, Layer by Layer
Student records and payments are protected at every layer, from the network to the audit trail.
| Layer | Protection |
|---|---|
| Network | Servers and database sit in private networks. Firewall rules allow only the connections that are needed. There is no open remote-login port. |
| Web edge | Managed attack rules, rate limits on sign-in and one-time-code pages, and, with the institute's approval, a country-level access policy. |
| Data | Encryption for the database, disks, files, cache and secrets, and for data moving between services. |
| People and pipeline | Named users with MFA, short-lived pipeline credentials, and least-privilege roles for servers. |
| Audit | Account activity logged, application logs kept without personal data or one-time codes, and alarms on unusual events. |
How We Deliver It
Five Phases, Each Reviewed Before It Is Built
The work runs in phases. Each phase ends with a plan that is reviewed and approved before anything is built.
What each layer does
| Layer | What it does | Planned timing |
|---|---|---|
| Foundation | Cost alerts, activity logging, DNS moved to Route 53, region speed test from Qatar | Weeks 1 to 3 |
| Staging | Staging server built from the setup script, deployment path, GitLab pipeline | Weeks 3 to 6 |
| Application readiness | Developers apply the review's changes. The review is repeated. | Weeks 5 to 9 |
| Production | Network, database, cache, servers from the image, CDN and web firewall, monitoringr | Weeks 7 to 13 |
| Go-live | Pre-production test, second review, cut-over, close support after launchr | Weeks 13 to 14 |
النتائج
Design Targets
Self-healing
A failed web server is replaced automatically, without visitors noticing.
10–20 min
Approval to live, with a rollback in 5 to 10 minutes.
2 zones
The web tier spans two availability zones, with room to add servers and zones as demand grows.
Signed links
Paid content is reachable only through signed links.
Day-one alerts
Monthly spend is watched by budget alerts from the first day.
Lessons Learned
What We Recommend to Others
Decide the region with data
A short speed test from the learners’ country is cheap and settles the question.
Review the application early
The readiness review found that most of the needed changes sit in the application, not in the servers.
Get DNS and registrar access on day one
Name-server changes can take up to two days to spread, and certificates depend on them.
Write decisions down
One record of what was agreed keeps every team aligned.
Build staging from the same script as production
What is tested is what runs.
Ready to Give Your Platform a Resilient Cloud Foundation?
Carmatec Qatar designs secure, cost-controlled AWS environments for organisations across Doha and the wider GCC: built as code, owned by you, and ready to grow with demand.
English 
العربية 
