Industrial Matrix: From Monolith to Multi-Account ECS on AWS
Consultant Leading the Project
Fernando Goncalves
Senior Cloud Engineering Consultant 20+ years in software development 10+ years specializing in AWS Former AWS Solutions Architect Public speaker
About Industrial Matrix
Challenge
We have demands for ingress data, for retrieval of data, for processing - there’s a lot of different services that before were running together. It was more expensive to scale. Every time I had to scale, I had to scale everything. So if I have more sensors sending data, or more users, or less users - it doesn’t matter, because I had to scale everything together to fit the bill.
- Resilience that matched the stakes. With hundreds of devices and a growing customer base now depending on the platform, concentration risk that was acceptable early on no longer was. The architecture needed to spread that risk, not pool it.
- Delivery that could keep pace. A hands-on deployment process works for a small team shipping occasionally. At their new velocity, they needed infrastructure as code and CI/CD so releases were fast, repeatable, and independent of who ran them.
- Room to build without risk to customers. As the team and roadmap grew, they needed space to develop and test separately from the environment serving live customers.
Solution
In a first engagement, FivexL laid the foundation. Using RightStart for AWS - FivexL’s productised landing zone - Industrial Matrix received a secure, multi-account AWS environment built with infrastructure as code. RightStart delivers what typically takes an in-house team over a year to assemble: a full AWS organisation structure with separate accounts for workloads, security, logs, and networking; centralised identity and SSO; encrypted secrets management; automated security tooling including GuardDuty, Security Hub, and CloudTrail; and CI/CD-ready OIDC access - all configured and ready in a month.
The accounts were created. The foundation was solid. But the application itself had never been moved onto it.
The second engagement focused on completing that work: migrating the production platform onto the foundation, replacing manual deployments with an automated pipeline, and giving the team the skills to own and operate the new architecture.
One sequencing decision shaped everything else: build a local development environment that mirrored the new architecture before the production cutover, so the team could learn the new platform in safety before depending on it.
Local Development Environment, Built First
Before touching production, FivexL built a local development environment that mirrored the new architecture, so the team could run and test their code on their own machines. When access to the old setup eventually disappeared, the developers already had a tested replacement they’d been using for weeks - and were running it with their own data seeders they’d built themselves.
Ariel saw the difference immediately: “One of the things we’ve done as well is the local development. So now it’s faster for developers to test and try things than before.”
Containerise the Application As-Is
The application was containerised without a framework upgrade. Combining a runtime upgrade with the infrastructure migration was too risky. The framework upgrade becomes a clean, separate project on a foundation that can support it.
Production Cutover
The migration to production happened over a single nine-hour window. FivexL prepared a detailed runbook with a rollback procedure for every step, tested the cutover in development and staging first, and resolved code conflicts before going live.
The largest dataset - too big to move within the downtime window - stayed in place and was made accessible to the new platform without being copied. The hundreds of IoT devices in the field kept sending their data without interruption, routed through a temporary bridge so customers never had to touch their hardware.
Automated Deployments and Cost Optimisation
FivexL replaced manual SSH deployments with an automated four-stage pipeline that promotes code from development to staging to production. No long-lived credentials anywhere in the system.
The team also right-sized the platform’s compute and database resources, set up reserved capacity for predictable workloads, and stood up ongoing cost reporting so the business has visibility into what each environment costs to run. The engagement closed with full platform documentation covering the new infrastructure.
The engagement ran on daily standups, pair programming, and async coordination.
Benefits
One of the things we’ve done as well is the local development. So now it’s faster for the team to test and try things than before.
Scale only what needs scaling
With the platform split across separate services, the parts that handle ingestion, retrieval, and processing can now scale independently. Adding sensors in the field or onboarding new customers no longer means scaling everything together.
Ship faster
The team went from manual deployments to an automated promotion pipeline. Shipping new versions of the software became routine rather than a bespoke operation - a capability the platform didn't have before.
Room to add environments without re-architecting
The accounts are structured by purpose - development, staging, production - with room for more. Including the option of standing up isolated environments for specific clients without touching the rest of the platform.
A platform the development team owns
The team now deploys to all environments through the automated pipeline without infrastructure support. They've built their own data seeders for the local environment and started shipping features on the new architecture.
Three environments where there was one
Dev, staging, and production now live in separate AWS accounts. The team can test changes without touching production.
Security posture transformed
The platform moved from a single AWS account with manual access to a multi-account environment with centralised security controls, encrypted service-to-service communication, and continuous threat monitoring.
Planning an AWS migration? See how RightStart for AWS gives you the foundation Industrial Matrix built on - and how ECS Blueprint gives you the container platform they migrated to.
Our happy customers
"FivexL didn't just set up infrastructure - they gave us a production platform we could trust from day one. We went from a manual MVP to onboarding real customers in weeks."
Daniil Goloviznin, Head of Infrastructure at Sirob Technologies"Fivexl has been a great partner. They demonstrate unrivaled expertise in the AWS ecosystem and deliver results quickly."
Rusty Atkinson, VP, Technology at Clearway Health"The FivexL team had laid the foundation for SOC2, and we didn’t need to make major changes to get certified."
Mattias Hemmingsson, Head of Security at Hippo"By developing infrastructure FivexL allows us to focus on our core business: Product development hypothesis testing and roadmap generation."
Artem Eroshenko, Co-founder and CPO at Allure TestOps (Qameta)
