Almentor. Three engagements.
Almentor is a leading Arabic-language e-learning platform, serving learners across the Middle East and North Africa with professional and personal development content. As the platform scaled, the infrastructure under it had to be rebuilt, secured, and then extended — in that order.
One platform, rebuilt in three passes.
Each engagement stands on its own and was scoped, signed and delivered separately. Together they move the platform onto a foundation it can grow on.
Migration and AI modernization
Delivered under the AWS Migration Acceleration Program, covering the Assess and Mobilize phases.
The problem
Almentor had grown past the infrastructure it was running on. The estate was not designed for the scale the platform had reached, observability was limited, and cloud-native tooling was largely absent — the familiar shape of a business that outgrew its foundation faster than it could rebuild it.
Two things had to happen at once: move the platform to AWS, and start the AI roadmap. Doing them sequentially would have meant migrating an estate and then immediately reopening it.
What we did
- Assessed before deciding Tool-based discovery of every workload, dependency mapping to sequence the waves, and a rehost-or-rebuild call made per workload rather than for the estate as a whole.
- Designed, then signed off Target architecture, multi-account landing zone, security baseline and wave plan — all reviewed and approved before any build work started.
- Migrated in waves Sequenced by dependency and business criticality, each wave with a defined rollback path, and every piece of infrastructure delivered as code rather than console clicks.
- Built the AI layer on Bedrock A recommendation engine and a live assistant, with retrieval over the course catalogue, response caching, and guardrails configured before either went near a learner.
- Handed over the operating model Runbooks, architecture walkthroughs, a cloud governance charter, a skills-uplift path by role, and 30 days of hyper-care after go-live.
Network and security hardening
A perimeter and data-protection layer sized to a platform holding learner and payment data.
The problem
A platform serving learners across a region carries obligations that grow with it: protecting the perimeter, knowing what sensitive data sits where, keeping access permissions honest as teams change, and staying available when someone decides to point traffic at you.
Those controls are cheapest to add deliberately and most expensive to add during an incident.
What we did
- Two firewalls, two jobs AWS WAF in front of the application for request-level rules, and AWS Network Firewall at the VPC boundary for traffic that should never reach an application to be judged by it.
- Managed DDoS protection AWS Shield Advanced, with the response team and the cost protection that comes with it. Volumetric defence is not something to build the week it is needed.
- Knowing where the data is Amazon Macie discovering and classifying sensitive data across object storage, so "where is it" is answered by a report rather than an investigation.
- Access that stays honest IAM Access Analyzer running continuously to surface permissions broader than intended — before they become the finding in someone else’s audit.
- Guardrails on the AI layer Bedrock Guardrails applied to model interactions, so the assistant is bounded by configuration rather than by prompt discipline.
- Traffic that stays inside VPC interface endpoints so calls to AWS services never leave the private network to reach a service in the same region.
Business login service on ECS
Login, payments and Learning Path lifted out of the platform into a service that scales and fails on its own terms.
The problem
Login, payment logic and Learning Path handling all sat tightly coupled to the rest of the platform. That coupling had four consequences, and none of them were theoretical.
Checkout could not be scaled, deployed or recovered independently, so any single incident took a wider blast radius than it needed. Payment integrations were harder to isolate, secure and audit without a network boundary around them. There was no right-sized AWS foundation purpose-built for a function this critical. And incident response was harder than it should have been, because the service had no monitoring or health-check surface of its own.
What we did
- A service with its own boundary Business login, payment logic and Learning Path deployed as a dedicated containerized service on ECS Fargate, behind an Application Load Balancer with its own health checks and target groups.
- A landing zone built for it A purpose-built AWS foundation: segmented networking across public, private and isolated tiers, identity and access design, centralized logging, and a security baseline established before the service was deployed.
- Connected back, privately Site-to-site VPN to the existing environment with dual-tunnel redundancy, so the new service reaches what it still needs without exposing either side.
- A registry with rules Container images in Amazon ECR with immutable tags, scanning on push, and lifecycle policies — so what runs in production is traceable to what was built.
- Reusable, deliberately The landing zone was designed as a foundation for the microservices that follow, not as scaffolding for one service.