Establishing an Enterprise-Grade DevOps Operating Model for a Multi-Tenant SaaS Platform on AWS

The company is a multi-tenant, white-label SaaS platform for commercial property management, serving enterprise real estate operators across multiple branded deployments, including Robinson Park, Copaken Brooks, Hempel, and others. The platform is mission-critical for its clients: it controls physical building access (HID Global integration), processes tenant payments (Stripe), manages maintenance work orders, coordinates amenity and space bookings, and delivers wellness and community content to tenants through native iOS and Android applications.

About the client

The company is a white-label commercial property management SaaS platform that enables enterprise commercial real estate operators to deliver modern, branded tenant experiences through native iOS and Android applications. The platform is mission-critical for its clients: it controls physical building access (HID Global), processes tenant payments (Stripe), manages maintenance work orders, coordinates amenity and space bookings, and delivers community content to tenants in real time.

The company serves multiple enterprise real estate clients, including Robinson Park, Copaken Brooks, Hempel, and others, each operating under a fully isolated, white-labeled AWS account. This account-per-client model is a deliberate architectural decision that ensures complete data isolation between clients and allows each deployment to be branded and configured independently.

Challenges

By early 2026, the company's platform had grown significantly in both capabilities and the number of client environments it served, each operating as a separate, white-labeled AWS account under a shared codebase. This growth had outpaced the formalization of the underlying DevOps and security practices. A Teracloud-led AWS workload assessment conducted at the start of the engagement identified a broad set of critical gaps across security, reliability, observability, and operational governance that posed direct risk to the company's business continuity and its clients' trust.

The core business challenge was that the company's infrastructure had scaled without a corresponding maturation of its DevOps operating model, leaving a multi-tenant, multi-account production platform operating with systemic security and operational gaps. The assessment identified the following specific risk areas:

IAM security was non-compliant at scale. IAM policies across multiple customer accounts contained wildcard permissions (*) in both Action and Resource elements, violating least-privilege principles. Application services authenticated to AWS using static, long-lived IAM access keys (programmatic users) rather than IAM roles, creating credential exposure risk across all environments. Lambda functions lacked authentication controls, and no Service Control Policies (SCPs) existed to enforce organizational security baselines or prevent accounts from leaving the AWS Organization.
High availability was not enforced. Elastic Beanstalk instances were not guaranteed to span multiple Availability Zones, introducing a single point of failure at the compute layer for a platform managing real-time tenant operations including physical building access and payment processing. Multi-AZ configuration for Aurora PostgreSQL had not been formally validated across all environments.
The platform had no observability framework. No KPIs had been defined or instrumented. Monitoring gaps in the event-driven architecture, specifically around Amazon Kinesis stream consumers and SQS dead letter queues, meant that processing failures (data inconsistencies, event backlogs) were occurring silently without alerting the engineering team. No structured notification workflow existed.
Security perimeter controls were absent. No AWS WAF was in place to protect public-facing endpoints. OpenSearch was not fully isolated behind VPC endpoints. AMI hardening had not been applied to Elastic Beanstalk EC2 instances. Several S3 buckets retained legacy configurations without access controls aligned to current best practices.
IaC was non-compliant and environments were not separated. CloudFormation templates contained wildcard IAM policies that would not pass security review. All client environments operated within the same AWS account structure without formal account-level isolation, increasing the blast radius of any misconfiguration or security event.

These gaps represented a compounding risk: a platform that controls physical building access, processes financial transactions, and handles personally identifiable tenant data was operating without the security controls, reliability guarantees, or operational visibility required for a multi-tenant enterprise SaaS. The absence of any formal monitoring framework meant that failures in critical data pipelines went undetected until they manifested as visible data inconsistencies, and with no KPIs defined, there was no objective baseline against which to measure platform health.

Risk of not addressing this challenge

Security and compliance: Static IAM credentials, wildcard policies, and missing perimeter controls across a multi-account environment exposed the company and its clients to unauthorized access, credential compromise, and potential data breaches, with real-time building access credentials and payment data in scope.
Operational: Silent failures in the event-driven architecture (Kinesis consumers, SQS queues) were causing data inconsistencies that property managers and tenants would only notice after business impact had already occurred.
Reliability: Single-AZ exposure at the compute layer meant that an Availability Zone failure could take down the platform for all tenants of a given client, impacting building access, maintenance workflows, and payment processing simultaneously.
Business trust: The company's white-label model requires its enterprise clients to trust that their tenant data and operations are handled with enterprise-grade security and reliability. Operating at this risk level was incompatible with that expectation as the client roster grew.

Goals and Objectives

The company engaged Teracloud to remediate the gaps identified in the initial AWS workload assessment and establish a DevOps operating model that matched the enterprise criticality of the platform. The engagement objectives were defined working backwards from a clear outcome: a production environment that could be operated with confidence, audited for compliance, and scaled to onboard new commercial real estate clients without inheriting accumulated technical debt.

Business Objectives

Achieve enterprise-grade security posture aligned with AWS best practices. The company's white-label model requires that each client's data and operations be handled with enterprise-level security controls. The primary business objective was to eliminate the documented IAM, perimeter, and governance gaps, replacing informal, ad hoc configurations with a documented, auditable security baseline across all accounts in the AWS Organization.
Guarantee platform reliability for mission-critical tenant operations. Building access control, payment processing, and maintenance workflows cannot tolerate unplanned downtime. The objective was to enforce high availability at every layer, compute, database, and networking, so that an infrastructure failure in one Availability Zone would not result in tenant-facing service disruption.
Establish operational visibility as a standard practice. Without KPIs or alerting, the engineering team was operating reactively. The objective was to instrument the platform so that failures in event-driven pipelines were detected and surfaced automatically, before they caused visible data inconsistencies for property managers or tenants.
Formalize a scalable, isolated account foundation for client onboarding. The company's business model deploys a dedicated AWS account per client to ensure 100% data isolation and independent configuration. The objective was to establish governance, IaC patterns, and account structure standards within AWS Organizations that would make onboarding new clients repeatable, secure, and operationally consistent.

Technical Objectives

IAM least-privilege enforcement across all accounts. Replace all wildcard IAM policies with scoped, resource-specific permissions. Eliminate static IAM access keys in application services; replace with IAM roles. Authenticate Lambda functions and all service-to-service calls via IAM roles. Enforce organizational baselines via SCPs in AWS Organizations.
High availability enforcement at compute and database layers. Configure Elastic Beanstalk environments to span a minimum of two Availability Zones with auto scaling (2–6 t3.small instances). Validate and enforce Aurora Serverless v2 multi-AZ deployment in all production environments.
Observability framework definition and instrumentation. Define a structured set of KPIs for platform health. Implement 7 CloudWatch alarms covering API availability, database performance, Kinesis consumer lag, SQS dead-letter queue depth, and application error rates. Route alerts via SNS → AWS Chatbot → Slack #aws for real-time engineering visibility.
Security perimeter hardening. Deploy AWS WAF on all public-facing ALB endpoints. Complete OpenSearch cluster isolation within VPC private subnets with fine-grained access control. Apply AMI hardening to Elastic Beanstalk EC2 instances. Remediate S3 bucket configurations to align with current AWS best practices.
IaC remediation and standardization. Rewrite non-compliant CloudFormation templates to eliminate wildcard permissions and enforce least-privilege. Introduce the cfn.py CLI wrapper to standardize stack deployment and parameter management across environments. Maintain 19 CloudFormation stacks covering the full application architecture.
Multi-account governance via AWS Organizations. Formalize the 10-account structure (the company management + per-client accounts + Shared/Audit/Log Archive) under AWS Organizations. Migrate all console and programmatic access to IAM Identity Center SSO with MFA enforcement. Eliminate all remaining IAM users.
Deployment pipeline standardization. Establish formal dev → stage → production pipeline using AWS CodePipeline, CodeBuild, and GitHub Actions with OIDC authentication. Enforce manual approval gate for production deployments. Adopt immutable deployment strategy for Elastic Beanstalk to prevent in-place configuration drift.

Solution and Execution

Teracloud's engagement was structured as an assessment-driven remediation: beginning with a formal Cloudfit Assessment that documented the full gap baseline, then executing a prioritized remediation plan across six domains, security and IAM governance, high availability, observability, CI/CD pipeline standardization, infrastructure as code, and multi-account governance. All work was performed on the live production platform while maintaining continuity of service for the company's enterprise clients.

Infrastructure as Code: The full application infrastructure is managed via 19 AWS CloudFormation stacks, covering compute, networking, databases, streaming, security, and monitoring layers. A custom cfn.py CLI wrapper was introduced to standardize stack deployment and parameter management across environments, enforcing consistent execution patterns and eliminating ad hoc console-driven changes. All CloudFormation templates were audited and rewritten to remove wildcard IAM permissions, replacing them with scoped, resource-specific policies aligned to least-privilege principles.
CI/CD Pipeline: A formal three-environment deployment pipeline was established using AWS CodePipeline and CodeBuild, integrated with GitHub via CodeStar Connections and OIDC-authenticated GitHub Actions, eliminating long-lived AWS credentials from the CI/CD workflow. The pipeline enforces a structured dev → stage → production promotion flow with a mandatory manual approval gate before any production deployment. Elastic Beanstalk deployments use an immutable strategy, ensuring that new application versions are deployed to fresh instances before traffic is cut over, preventing in-place configuration drift.
Compute and Application Layer: The company API is built on Kotlin/Ktor and deployed on Elastic Beanstalk with an Application Load Balancer, configured with auto-scaling across 2–6 t3.small instances spanning multiple Availability Zones. Cognito User Pools handle tenant authentication with JWT-based sessions, admin-create-only flows, and SES-delivered communications.
Data Layer: DynamoDB (PAY_PER_REQUEST) serves as the primary data store, with 30+ tables, Point-in-Time Recovery enabled, and Kinesis Data Streams integration for change data capture. Aurora Serverless v2 PostgreSQL (0.5–2 ACU, multi-AZ) handles relational workloads, with AWS DMS providing CDC replication from Aurora into the event-driven pipeline. Amazon Kinesis Data Streams ON_DEMAND with a KCL consumer processes events with 365-day retention. An OpenSearch cluster (3-node, zone-aware, VPC-isolated, fine-grained access control) supports search and analytics workloads.
Event-driven components include SQS with Dead Letter Queues (14-day retention), EventBridge for scheduling and webhook routing, and Lambda functions handling Stripe payment webhooks and HID Global building access events.

Security and Identity: IAM Identity Center SSO with MFA enforcement was adopted as the sole access mechanism across all accounts, eliminating all standing IAM users. Service-to-service authentication was migrated from static IAM access keys to IAM roles. Lambda functions were updated to authenticate via IAM roles. AWS WAF was deployed on public ALB endpoints. Secrets Manager replaced hard-coded credentials and environment variables. KMS encryption was applied across data stores. CloudTrail was configured for full API audit across the organization. SCPs were implemented at the AWS Organizations level to enforce security baselines across all accounts and prevent unauthorized organizational actions.

Multi-Account Governance: The platform operates across a 10-account AWS Organizations structure: a the company management account and dedicated per-client accounts (Robinson Park, Copaken Brooks, Hempel, ThePeakOKC, Colcord, and others), complemented by Shared Services, Audit, and Log Archive accounts. This architecture reflects the company's core business model, one isolated AWS account per client, and was formalized with IAM Identity Center federation, SCPs, and centralized logging to the Log Archive account.

Monitoring and Observability: Seven structured CloudWatch alarms were defined covering API availability, database performance, Kinesis consumer lag thresholds, SQS dead-letter queue depth, and application error rates. Alarms route through SNS to AWS Chatbot, delivering real-time notifications to the engineering team's Slack #aws channel. Firebase Crashlytics monitors mobile application stability with a target crash-free session rate of ≥99.5%. CloudTrail provides a complete audit trail of API activity across all accounts.

Networking: A multi-AZ VPC with 2 public and 3 private subnets, 2 NAT Gateways, and an ALB in public subnets provides the network foundation. OpenSearch and Aurora are isolated in private subnets. All inter-service communication traverses private networking paths.

Architecture Overview

The following diagram illustrates the company's production AWS architecture across its multi-account environment.

Multi-account governance: Hub-and-spoke model with one isolated AWS account per client, governed under AWS Organizations with SCPs enforcing security baselines organization-wide.
Application layer: Elastic Beanstalk (Kotlin/Ktor API) behind an ALB with multi-AZ auto-scaling (2–6 t3.small instances) and immutable deployments.
Data layer: DynamoDB (primary store, 30+ tables, PITR), Aurora Serverless v2 PostgreSQL (multi-AZ, DMS CDC), and Kinesis Data Streams ON_DEMAND for event-driven processing.
Search and analytics: OpenSearch cluster (3-node, zone-aware) deployed within VPC private subnets with fine-grained access control.
Networking: Multi-AZ VPC with public and private subnet separation, 2 NAT Gateways, and ALB providing inbound traffic distribution.
Security: AWS WAF on public endpoints, IAM Identity Center SSO with MFA, KMS encryption, Secrets Manager, and CloudTrail across all accounts.

KPIs And Outcomes

Following the engagement, the company's platform operates with a formalized DevOps baseline across all seven remediation domains. The outcomes below reflect the delta between the state documented in the initial assessment and the production state at engagement close.

IAM posture: All wildcard IAM permissions replaced with scoped, least-privilege policies across all accounts. Zero standing IAM users, all access federated via IAM Identity Center SSO with MFA enforcement. Static IAM access keys eliminated from all application services and Lambda functions.

Observability: Platform went from zero defined KPIs and zero alerting to 7 structured CloudWatch alarms with an automated SNS → AWS Chatbot → Slack notification pipeline. Kinesis consumer lag and SQS dead-letter queue depth, previously silent failure points, are now actively monitored.

Reliability: Elastic Beanstalk environments enforced to span multiple Availability Zones with auto-scaling. Aurora Serverless v2 multi-AZ validated in production. Immutable deployment strategy adopted, eliminating in-place configuration drift risk.

Infrastructure as Code: 100% of production infrastructure managed via 19 CloudFormation stacks with standardized cfn.py CLI deployment. All IaC templates remediated to remove wildcard IAM permissions.

CI/CD pipeline: Formal dev → stage → prod pipeline established with OIDC authentication, eliminating long-lived AWS credentials from the CI/CD workflow. Manual approval gate enforced for all production deployments.

Account governance: 10-account AWS Organizations structure formalized with SCPs, dedicated Audit and Log Archive accounts, and IAM Identity Center federation, establishing a repeatable, secure foundation for future client onboarding.

Security perimeter: AWS WAF deployed on all public ALB endpoints. OpenSearch isolated within VPC private subnets. Secrets Manager adopted for all credential management.

Business Impact

The DevOps operating model established through this engagement has a direct impact on the company's capacity to operate reliably, retain enterprise clients, and grow its platform.

The company's business model places exceptional demands on its underlying infrastructure: the platform controls physical building access for tenants in real time, processes financial transactions, and handles personally identifiable data, all across multiple isolated client environments. For the company's enterprise real estate clients, a platform outage is not a degraded user experience; it is an operational failure with immediate, on-the-ground consequences. The enforcement of multi-AZ compute and validated database HA transforms reliability from an assumption into a guaranteed architectural property, one that the company can now evidence to clients and prospects.

The elimination of wildcard IAM permissions, static access keys, and unauthenticated Lambda functions across a 10-account organization closes the security exposure that was most directly proportional to the company's risk: a compromise in one client account, or a credential leak from a shared programmatic user, could have cascading effects across a multi-tenant architecture handling building access credentials and payment data. The shift to IAM Identity Center SSO with MFA and organizational SCPs removes that exposure systemically, not account by account.

Perhaps most significant to the company's growth trajectory is the formalization of the account-per-client model within AWS Organizations. Each new commercial real estate client the company onboards now enters a defined, repeatable account structure governed by the same IaC templates, security baselines, and operational runbooks established during this engagement. What was previously an informal pattern becomes a scalable, auditable onboarding playbook, enabling the company to expand its client roster without compounding operational risk.

Finally, the observability framework transforms the engineering team's operational posture. Silent failures in Kinesis consumers and SQS dead-letter queues, the kind that previously surfaced only when a property manager reported a data inconsistency, are now detected automatically and routed to the engineering team before they become visible business problems. This shift from reactive to proactive operations directly reduces the cost of incidents and protects the trust that the company's enterprise clients place in the platform.

Get in touch

Take your business to the next level.