Data centre infrastructure management on AWS

The problem

An enterprise client needed a secure, highly available cloud environment to host Schneider Electric’s EcoStruxure IT Advisor, their data centre infrastructure management (DCIM) platform. The platform also had to take in Building Management System data — from Tridium Niagara controllers — across multiple data centre sites.

Four requirements shaped the design, and they did not all point the same way:

• Security. Given the sensitivity of the data and the criticality of the platform, nothing could be exposed directly to the internet — yet internal users, the platform vendor and downstream analytics all needed reliable access.
• Availability. The platform had a 99.99% availability target, so no single server, database instance or availability zone could take it down.
• Low operational overhead. The client needed an environment that would run without constant hands-on attention.
• Software built for in-place operation. IT Advisor, like much of the software the client selected, is designed to be installed on a physical server or virtual machine and then patched and upgraded in place. That mutable operating model had to be reconciled with an infrastructure-as-code environment that favours immutable, reproducible resources.

The approach

A multi-AZ AWS architecture, built on zero-trust networking and isolated data tiers, with every resource defined as infrastructure-as-code in AWS CDK and all configuration managed with Ansible.

Platform

The foundation is a VPC spanning multiple availability zones, divided into public, private and isolated subnet tiers so that each layer of the platform is only as reachable as it needs to be.

IT Advisor runs on EC2 as an active-passive pair, with the primary and secondary nodes in separate availability zones behind an Application Load Balancer. Failover is handled through weighted routing: while the primary is healthy it receives 100% of traffic. If its target health checks fail, an alarm triggers a switch of the weights and traffic moves to the secondary node.

Both nodes are launched from the same AMI, produced by an EC2 Image Builder pipeline that turns the vendor’s installation ISO into a machine image. This keeps the primary and secondary consistent, and means a node can be rebuilt from a known image rather than configured by hand.

The database is Aurora PostgreSQL in isolated subnets with no route to the internet, running as a cluster of one writer and two readers. Downstream processing jobs read from the readers, keeping that load off the writer, and if the writer fails a reader is promoted in its place so applications stay connected to the database.

Access and security

Access is built on zero-trust principles rather than a network perimeter. Internal users reach IT Advisor through Netskope Private Access, with a Netskope Publisher deployed inside the VPC. The Publisher connects outbound to Netskope’s cloud, so users get access to the application without any inbound path being opened from the internet. The vendor works through AWS WorkSpaces, which gives their team a controlled environment for support work.

Inside AWS, traffic to AWS services goes through VPC endpoints, so it stays on the AWS network rather than crossing the public internet. Credentials live in AWS Secrets Manager rather than in code or configuration, and container images are stored in Amazon ECR. Administrative access to instances goes through Session Manager and is authorised through IAM, which removes the need for bastion hosts and inbound SSH.

Data integration

Data moves through the platform along two paths. ECS-based ETL pipelines run alongside the platform and handle data flowing into and out of IT Advisor, packaged as containers so they are deployed and versioned like the rest of the infrastructure.

For analytics, HVR (Fivetran) replicates data to Snowflake in near real time. Downstream reporting works from current data in Snowflake, without placing reporting load on the platform itself.

What I learned

• Mutable software in an immutable-first environment. Much of the software the client selected is designed to be installed once and then operated, patched and upgraded in place. An infrastructure-as-code approach pushes the other way, towards immutable resources that are replaced rather than modified. Bridging that gap was one of the biggest technical challenges on the project. AWS CDK defined the infrastructure, while Ansible handled the configuration of everything running on it.
• Turning a vendor ISO into a deployable AMI. IT Advisor is distributed as a bootable ISO that bundles its own operating system, intended for installation onto a physical server or virtual machine. I built an EC2 Image Builder pipeline that installs IT Advisor from the ISO onto a compatible base OS, adds operational dependencies such as the SSM and CloudWatch agents, and produces an AMI. Primary and secondary instances are then launched from that image as needed.