A reference architecture is useful only if it is specific enough to argue with. What follows is a conceptual model for an enterprise Drupal platform, read in the order a request travels, with the decision each layer actually contains.
None of it is exotic. Drupal is a conventional PHP application, and the architecture is a conventional web architecture in which the parts that hold state are treated seriously. The value is in being deliberate about each layer rather than inheriting it.
Edge
The first layer a request meets: content delivery, a web application firewall, and denial of service protection.
Most traffic should be answered here and most hostile traffic should stop here. Two decisions live in this layer.
What is cacheable. Getting this wrong in either direction is expensive. Too conservative and the origin carries traffic it should not. Too aggressive and an authenticated page ends up in a shared cache, which is a data exposure rather than a performance bug. Drupal's cache metadata is designed to make this decision explicit; the edge has to be configured to respect it.
Whose edge it is. The organization's approved platform, in its own account, with its own logs. An edge you cannot query during an incident is a layer you do not really operate.
Load balancing
Distribution across application instances, with health checks that understand what a healthy Drupal response actually looks like.
The common failure is a health check that requests the front page and accepts a 200. A Drupal site with a broken database connection can still return a cached front page, so the check passes while the site is unusable. A useful health endpoint exercises the database and the cache and reports honestly.
Application runtime
PHP, the web server and the Drupal codebase, deployed as an artifact rather than assembled in place.
The architectural requirement is that instances are interchangeable and disposable. Anything an instance holds locally that matters is a defect: sessions, uploaded files, generated derivatives and caches all belong in shared services rather than on a disk that will disappear when the instance is replaced.
That property is what makes scaling, patching and recovery ordinary instead of delicate.
Environments
Development, staging and production built from the same definitions, so that what passes in staging is a rehearsal rather than a resemblance.
Two properties matter more than the number of environments. They are produced from code, so a new one is a repeat of a known procedure. They differ only in ways that are declared, typically scale and data, so a difference in behavior points at the release rather than at the environment.
Modeling each as a governed object also gives you the audit trail. Microsoft describes an environment as a group of resources you can target with deployments from a pipeline, and notes that deployment history can be used to identify the source of changes.
Data services
The layer that holds state, and therefore the layer that decides what recovery means.
- Database. Where the site actually lives. Sizing, parameters, connection limits, backup window and, above all, demonstrated restore capability.
- File storage. Public and private, durable, shared across instances. Private files must be mediated by the application rather than served directly, which is an access policy and not merely a bucket.
- Cache. A shared cache service rather than per instance memory, with a clear invalidation story per layer.
- Search. Frequently forgotten in inventories and then discovered during a pilot. If a site uses an external search service, that service is part of the architecture.
Security services
Identity, secrets, certificates, and the path by which security events reach the people who watch them.
The design questions are ordinary and are answered badly surprisingly often: how administrators authenticate and whether that is the organization's directory; where secrets live and how they are rotated; which identity the application uses to reach other services and whether that identity is scoped per environment; and where logs go so that they can be correlated with everything else.
The detail is in Drupal cloud security architecture.
Observability
Metrics, logs, traces and synthetic checks, covering infrastructure and application together.
The distinction that matters: infrastructure monitoring tells you the servers are healthy, which a Drupal site can contradict comprehensively. Application signals, including Drupal's own health, PHP behavior, database and cache performance, are what tell you whether the platform is working. OpenTelemetry describes itself as an observability framework and toolkit designed to facilitate the generation, export and collection of telemetry data, and is explicit that it is not an observability backend itself, which is worth knowing before it is treated as one. See Drupal observability.
Protection and recovery
Backup, retention, rehearsed restore and a documented recovery procedure with owners.
Two objectives should be written down before the architecture is signed off, because they size several of the layers above. NIST defines the recovery point objective as the point in time, prior to a disruption or system outage, to which data must be recovered, and the recovery time objective in terms of the maximum amount of time a resource can remain unavailable before there is an unacceptable impact.
Those are business decisions expressed as numbers, and an architecture that does not know them is guessing at redundancy. See backup and disaster recovery.
Automation and delivery
The layer that makes every layer above repeatable: infrastructure definitions, the delivery pipeline, and Drupal lifecycle operations.
Three distinct jobs, and confusing them is the most common architectural error here. Infrastructure is declared with a tool HashiCorp describes as letting you build, change, and version cloud and on-prem resources safely and efficiently. Delivery is orchestrated by a pipeline; Microsoft describes Azure Pipelines as combining continuous integration, continuous testing and continuous delivery to deploy code projects to any destination. Drupal operations are performed by Drush, which describes itself as a command line shell and Unix scripting interface for Drupal.
The decisions the diagram does not show
Four questions decide more about how the platform behaves than the box diagram does.
Where does state live, and what happens when it is lost? Answer this per data service, in writing. It is the question every incident eventually becomes.
What is the failure domain? A single availability zone, several, or several regions. This is a cost decision as much as an engineering one, and it should follow the recovery objectives rather than precede them. AWS's Well-Architected material is a reasonable reference for the reasoning: it describes a framework based on six pillars, one of which is reliability.
What is shared across sites, and what is not? A shared database service is efficient and couples sites together. A shared edge is efficient and makes one site's misconfiguration everyone's problem. Both can be right; neither should be accidental.
Who can change what, without asking? The most operationally consequential question in the list, and the least likely to be in the diagram.
Implementations vary, deliberately
This model can be implemented on public cloud, on private cloud, on hybrid arrangements, on infrastructure the organization already controls, or on a combination. NIST's definitions are worth using precisely here: it defines private cloud as infrastructure provisioned for exclusive use by a single organization, and lists on-demand self-service and resource pooling among the essential characteristics of cloud computing.
No vendor stack is mandatory, and a reference architecture that names products in every box is a product diagram wearing an architecture label. What should not vary is that the environment is described in code, that state is deliberate, and that recovery has been demonstrated rather than designed.
How the layers change when there are forty sites
The model above describes one platform. An estate is the same model with a sharing decision taken at every layer, and those decisions are where the cost and the coupling actually live.
Three patterns recur, and each is right somewhere.
- Fully shared. One edge, one cluster, one database service, one set of pipelines, with sites separated by configuration. Cheapest per site and the most coupled: one site's traffic spike or misconfiguration is felt by the others, and a shared maintenance window applies to everybody.
- Fully isolated. Each site with its own environment end to end. Strong separation, simple blast radius, and a per site cost that only makes sense when the sites are few or genuinely unlike each other.
- Tiered. The arrangement most large estates end up with. A shared tier for the long tail of low complexity sites, and dedicated environments for the handful that are high traffic, high sensitivity or heavily integrated.
Tiering is usually the right answer and is only defensible if the placement is evidence based. Putting a site in the shared tier because it is small, when it happens to hold personal data or carry a regulatory obligation, is the kind of decision that is discovered during an audit. The classification in the site complexity assessment is what makes the placement argument rather than the guess.
Two layers deserve particular care when sharing is on the table. The database service is where a noisy neighbor is felt first and where a restore affects everyone sharing the instance. Identity and access is where sharing quietly becomes a security decision: if one credential can reach every site's storage, the isolation in the diagram is not present in the account.
How to use this
As a checklist against an existing estate rather than as a target to build toward. Take each layer, ask who owns it today, how it is defined, and what happens when it fails. The layers where the answer is uncomfortable are the migration's real scope, and they are usually not the ones on the project plan.
The architecture is one part of enterprise Drupal modernization and managed operations, and the way it is built and proved is in Terraform and Infrastructure as Code for Drupal. If you would like a review of a current architecture against this model, that is a useful exercise.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.
- Microsoft, What is Azure Pipelines?, Azure DevOps documentation
- Microsoft, Create and target an environment, Azure Pipelines documentation
- HashiCorp, What is Terraform?, Terraform documentation
- Drush, Drush 13 documentation
- NIST, Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1
- NIST, The NIST Definition of Cloud Computing, SP 800-145, September 2011
- Amazon Web Services, Reliability Pillar, AWS Well-Architected Framework
- OpenTelemetry, What is OpenTelemetry?