Cloud & SaaS Architecture

The three ways cloud projects go wrong

Cloud failures follow a pattern. The first is cost: an architecture that works beautifully at pilot scale and produces an invoice nobody can explain at production scale, usually because compute was sized for peak and left running, or data egress was never modelled. The second is security debt: permissive roles created during development and never tightened, credentials in environment files, no audit trail of who accessed what. The third is operational blindness — a system that fails and nobody knows until a customer calls.

These are design decisions, not accidents, and they are cheap to get right early and expensive to retrofit. So we address all three in the architecture phase: cost modelled against realistic load before committing to a pattern, least-privilege roles from the first deployment, and observability treated as a feature with an owner rather than something added after the first outage.

Why we standardise on AWS

We are deliberately narrow here. Media 365 runs AWS, deeply, rather than claiming equal competence across three hyperscalers. That is a considered position: cloud platforms are only superficially similar, and the difference between a good deployment and a fragile one lies in knowing the failure modes, quota limits, IAM subtleties and pricing cliffs of the specific services you are using. Shallow coverage of three clouds produces systems that work until they are stressed.

In practice that means Cognito for identity and access, Lambda for serverless business logic, S3 with encryption for storage, CloudFront for global delivery, and CloudWatch for metrics, logs and alerting. Infrastructure is defined as code so environments are reproducible and reviewable, and so recovering from a mistake is a rollback rather than an archaeology project. Where Australian data-residency requirements apply, we architect for regional hosting from the outset.

Multi-tenant SaaS, done properly

If you are building a SaaS product, tenancy is the decision that constrains everything afterwards. Isolate too little and one customer can degrade or, worse, see another. Isolate too much and your per-tenant cost destroys the unit economics that made the product attractive. We work through that trade-off explicitly with you, against your actual customer profile and pricing, rather than defaulting to a pattern.

Around that sit the unglamorous requirements that enterprise buyers audit: role-based access control that reflects real organisational hierarchies, tenant-scoped data access enforced at the query layer rather than trusted to application code, per-tenant configuration without forking the codebase, and usage metering accurate enough to bill from.

We also plan for the conversations that come later. Enterprise procurement will ask for an architecture diagram, a security questionnaire response, an incident process and evidence of access control. Documenting these during the build costs days. Reconstructing them under deal pressure costs weeks and sometimes the deal — a lesson from work like Know Your Asset, where a documented architecture materially helped enterprise conversations progress.

Taking over an existing platform

A significant share of this work is inherited rather than greenfield: a platform that outgrew its original build, or whose original team has moved on. We start with an architecture, cost and security review that produces a plain-language findings document — what is sound, what is urgent, what is merely untidy. Then we stabilise what is running before modernising anything.

We are wary of recommending rebuilds. They are the easiest thing for an agency to sell and frequently the worst outcome for the client, because they discard years of accumulated business logic that nobody has documented. Incremental modernisation is usually slower to describe and far cheaper to live with.