Greenfield cloud-native workloads
New systems where managed services genuinely remove operational burden and where no incumbency argument constrains the choice.
AWS consulting and cloud architecture
AWS offers more services than any organisation should adopt. The value in an independent view is largely in what we tell you not to use, and that advice is only credible from someone earning nothing on the outcome.
Overview
AWS's breadth is its defining property. There is a managed service for almost everything, which removes a great deal of undifferentiated operational work — and also makes it very easy to assemble an estate using forty services where twelve would do.
The second characteristic is the account model. Multi-account isolation is genuinely strong and is the primary mechanism for separating environments, workloads and blast radius. Organisations that start with a single account and grow into it find the retrofit expensive.
We design AWS estates and are equally willing to say when a workload belongs elsewhere or when fewer services would serve better. We hold no AWS partnership and take no commission, so consolidation advice costs us nothing to give.
Enterprise use cases
Where we see this used to good effect, and what makes each case a fit.
Strong workload isolation requirements
Where regulated or multi-tenant workloads must be separated firmly, and the multi-account model provides a boundary that is hard to cross by accident.
High-volume event ingestion
Streaming and queue-based architectures at volumes where managed ingestion is materially cheaper than operating the equivalent.
Global distribution
Workloads needing regional presence and edge delivery, where the breadth of regions and the edge network are the deciding factor.
Elastic and peaked workloads
Retail trading events, enrolment peaks and seasonal load, where paying for peak beats provisioning for it year-round.
Lift-and-shift with a modernisation path
Estates that must leave a data centre on a date, where migrating first and modernising after is the honest sequence.
Architecture
The account structure is the decision with the widest consequences. It determines isolation, cost attribution, policy inheritance and the blast radius of a compromise, and moving workloads between accounts later is expensive enough that most organisations do not.
The second is how much managed service to adopt. Managed services remove operational work and increase coupling to the provider, and the right balance depends on how much operational capability you have and how seriously you take portability.
- Multi-account structure designed before workloads land, not retrofitted
- Organisational policy inheritance decided alongside the account layout
- Managed-versus-self-operated taken as an explicit decision with a stated trade
- Region and availability zone strategy derived from recovery objectives
Best practices
The practices that keep an AWS estate coherent are the same ones that are skipped under delivery pressure: infrastructure defined in code, least-privilege IAM designed rather than accumulated, and a deliberate limit on how many services the estate uses.
That last one deserves emphasis. Each additional service carries learning cost, operational surface and a security posture someone has to understand. Breadth is AWS's strength and adopting all of it is a recurring and expensive mistake.
- A deliberate, documented limit on how many services the estate uses
- IAM designed from job function rather than accumulated from access requests
- Infrastructure as code with drift detection, not console changes
- Tagging enforced at creation, since cost attribution is impossible without it
Security
IAM is where AWS security is won or lost. Wildcard permissions, long-lived access keys and roles that accumulated privileges through individual requests account for the majority of serious findings we encounter.
Storage exposure is the second. It is a well-known failure mode and it still occurs, because the controls that prevent it entirely — account-level public access blocks and preventive policy — are frequently not applied at the organisational level.
- Public access blocked at account and organisation level, not per bucket
- Long-lived access keys eliminated in favour of roles and workload identity
- Service control policies preventing the misconfigurations that matter most
- GuardDuty and Security Hub findings triaged by exploitability, not by severity
Scalability
AWS will scale further than most workloads require. The constraints organisations actually encounter are account and service quotas, which are per-region and per-account and frequently lower than assumed until requested.
Beyond quotas, the limiting factor is the architecture. Serverless scales trivially and shifts the constraint to whatever it calls — usually a database with a connection limit, which is exactly the sort of ceiling that is invisible until traffic arrives.
- Quota review during design, per region and per account, before load arrives
- Downstream constraints identified, since scaling the front tier moves the limit
- Connection management designed where serverless meets a relational database
- Load tested against a realistic profile rather than a comfortable multiple
Performance
Performance issues on AWS are usually design issues: cross-availability-zone chatter, an under-provisioned database, or a synchronous call chain where an asynchronous one would serve.
Cold starts and connection overhead in serverless architectures are the other recurring source, and both are addressable by design — but only if the latency requirement was stated before the architecture was chosen.
- Latency requirements stated as numbers before the architecture is selected
- Data locality and cross-zone traffic reviewed before capacity is added
- Synchronous call chains examined for where asynchrony would serve better
- Caching placed by measurement rather than by intuition
Integration
AWS provides several messaging and integration primitives with genuinely different semantics, and choosing between them is a design decision rather than a preference — ordering, delivery guarantees and replay behaviour differ in ways that matter.
Hybrid and third-party integration is the second consideration. Private connectivity to on-premises estates and to partners is straightforward to design and awkward to retrofit into an estate built around public endpoints.
- Messaging primitive chosen on ordering, delivery and replay semantics
- Idempotency in receivers rather than exactly-once assumed from a transport
- Private connectivity to on-premises and partners designed rather than added
- Event schema versioning agreed before producers and consumers multiply
Operations
Operational cost on AWS is driven as much by observability and data transfer as by compute. Log retention set by default rather than by investigation need, and cross-region or cross-zone data transfer nobody modelled, are consistent surprises.
The second is the operational surface created by service breadth. Every service in the estate needs someone who understands its failure modes, and an estate using forty services rarely has that for all of them.
- Log retention and metric resolution set against investigation need and cost
- Data transfer modelled, because it is invisible until the invoice arrives
- Every service in the estate owned by someone who knows its failure modes
- Cost allocation enforced by tag, and reviewed rather than merely reported
Governance
Service control policies are the most valuable governance mechanism AWS offers, because they prevent rather than report. Restricting regions, services and dangerous actions at the organisation level removes whole categories of misconfiguration.
Cost governance benefits from the same preventive approach. Budgets alert after spend has occurred; policy restricting instance families and regions prevents a meaningful share of it.
- Service control policies restricting regions, services and dangerous actions
- Account provisioning automated with the baseline applied on creation
- Budgets and anomaly detection with a named owner per account
- An exception path faster to follow than to work around
Recommended industries
Sectors where this comes up most often, and the constraint that puts it there.
Industry
Retail & E-commerce
Traffic that is seasonal rather than steady, omnichannel inventory accuracy, and catalogue scale.
IndustryLogistics
Real-time tracking, partner system integration, and routing systems where latency has a direct cost.
IndustryTelecommunications
OSS/BSS complexity, network-scale data volumes and availability expectations measured in minutes per year.
IndustryBanking & Financial Services
Core system modernisation, real-time payment flows, and architecture that can evidence regulatory controls.
IndustryManufacturing
Operational technology meeting information technology, supply chain visibility, and ERP estates grown by accretion.
IndustryEducation
Student information systems, hybrid delivery platforms and sharply seasonal load.
Related services
The engagements this work is usually delivered within.
Cloud Consulting
Migration strategy, landing-zone design, cost modelling and the architecture decisions that determine whether cloud spend buys capability.
Enterprise Architecture
Target-state design, modernisation roadmaps, integration and cloud architecture, and the governance that keeps decisions consistent after the consultants leave.
DevOps & Platform Engineering
Delivery pipelines, infrastructure as code, Kubernetes and the observability practices that make releases routine.
Cybersecurity
Security architecture, assessment and compliance advisory, designed in rather than reviewed afterwards.
AI & Data Engineering
Data architecture, platform modernisation, integration and analytics — the foundations that have to exist before AI is a sensible conversation.
Software Development
Custom application, web, mobile and API development, and modernisation of systems that are constraining the business.
Frequently asked questions
Not in general, and any consultancy answering that question in general is telling you about its commercial arrangements. AWS has the broadest managed service catalogue and the strongest account isolation model; the right choice depends on your workloads, your existing identity estate and the team that will operate it.
No. We hold no partnership with AWS or any other provider, resell nothing and take no commission. That is what makes a recommendation to use fewer services, or a different provider, credible.
More than one, and structured by isolation boundary rather than by team convenience. Accounts are the strongest boundary AWS offers for blast radius, environment separation and cost attribution, and moving workloads between them later is expensive enough that most organisations never do.
Frequently yes. Each service carries learning cost, operational surface and a security posture someone must understand, and an estate using forty services rarely has that understanding for all of them. Breadth is AWS's strength; adopting all of it is a recurring mistake.
For some workloads it is clearly right, and it shifts the constraint rather than removing it — usually to a database with a connection limit. Serverless is a good fit for spiky, event-driven work and a poor fit where sustained throughput or predictable latency dominates.
Most commonly data transfer, log retention set by default rather than by need, non-production environments running continuously, and over-provisioned database tiers. None of those scale with traffic, which is exactly why the pattern is confusing when it appears.
At the account and organisation level rather than per resource. Public access blocks and service control policies remove the failure mode entirely; per-bucket configuration relies on every future bucket being created correctly, which is a weaker guarantee than it sounds.
Sometimes it is the honest sequence, particularly against a data centre exit date. The risk is that modernisation never follows, so the second phase needs its own funding and its own business case agreed before the first one starts.
IAM. Wildcard permissions, long-lived access keys and roles that accumulated privileges through individual requests. It is unglamorous to fix and it is where the real exposure sits — considerably more often than in anything a scanner flags as critical.
By reviewing them during design rather than during a peak. Quotas are per region and per account and are frequently lower than assumed until requested, and the request itself is not always instant — which is the part that turns a limit into an incident.
Next step
Discuss an AWS architecture
A free first consultation covering your workloads, your account structure and how many services your estate should actually be using — from a party that earns nothing from the answer.
No cost, no obligation. Pricing is transparent and includes GST.