Cloud platforms give small and medium-sized businesses access to resilient infrastructure, managed databases, global content delivery and sophisticated security controls without owning a data centre. They also make it easy to create complexity that nobody is prepared to operate.
A cloud stack should be designed from the business workload outwards. The right answer for a public website differs from the right answer for a field application holding sensitive evidence or an internal system integrated with finance. Architecture is the discipline of making those differences explicit.
Public cloud is often a sensible starting point because services can be adopted incrementally and much underlying infrastructure is managed by the provider. Private or hybrid approaches may be justified by legacy dependencies, regulation, latency or operational constraints. No deployment model is automatically secure or cost-effective; implementation and ownership determine the result.
1. Workload: what must the system do?
Start with the product and its usage. Is it a static business website, a transactional application, a scheduled data process or an API used by field devices? What are the busiest periods? What happens if processing is delayed? Does the workload run continuously or in bursts?
Static hosting and a content delivery network can provide a fast, low-maintenance foundation for a website. Serverless functions may suit event-driven or variable processing. Long-running, specialised workloads may be clearer in managed containers or conventional compute. Choose the model that makes the operating behaviour understandable.
Jay Malvern’s own website is statically generated and delivered using AWS infrastructure. That is a natural fit for this workload; it is not evidence that every business system should use the same pattern or provider.
2. Users: who needs access and from where?
Public visitors, employees, customers, administrators, integration services and field devices have different access needs. Define roles and journeys before selecting identity controls.
Consider geographic access, device management and periods without connectivity. An internal application may rely on an existing organisational identity provider. A customer portal needs its own account recovery and support model. Service-to-service identities should be separate from human accounts.
3. Data: what is stored, processed and moved?
Classify data by sensitivity, purpose and lifecycle. Determine where it originates, which region it may occupy, how long it is retained and where it travels through integrations and backups.
A managed relational database is appropriate for many structured business applications. Object storage suits documents, media and exports. Other database models can be valuable when access patterns justify them. The fashionable choice is less important than a clear data model, protection, recovery and ownership.
Minimise collection. Encryption is important, but it does not compensate for storing information the service does not need.
4. Security: design boundaries and defaults
Security is a set of controls across identity, network paths, applications, data, deployment and operations. Use secure defaults, protected administrative interfaces, encrypted connections and managed secrets. Separate production from development and test environments.
Publicly reachable does not mean publicly writable. Expose only the interfaces users require. Validate inputs and keep dependencies maintained. Record security-relevant events without putting secrets or excessive personal data into logs.
Threats and controls should be proportionate. A simple marketing site and a platform processing sensitive inspection evidence deserve different assessments.
5. Identity: know who and what is acting
Multi-factor authentication should protect privileged and appropriate user access. Least privilege gives each person and service only the permissions needed for its role. Avoid long-lived shared credentials and broad administrative access for routine deployment.
Cloud identity design should include emergency access, joiner and leaver processes, service identities and periodic review. A technically strong policy loses value if nobody owns account changes.
6. Availability: define what interruption means
“Always available” is not a useful requirement. Ask how long the business can tolerate loss of access, whether all features have the same priority and how users should be informed during disruption.
Managed services can reduce infrastructure work and offer resilient designs, but redundancy adds cost and complexity. Multi-region architecture may be justified for some critical services and excessive for many SME workloads. Establish realistic recovery objectives and design to them.
7. Backup and recovery: prove restoration
Backup is not complete until restoration has been tested. Define what is backed up, frequency, retention, protection from alteration and the person responsible for recovery.
Versioned storage can protect against accidental changes, while database snapshots and point-in-time recovery serve different failure scenarios. Backups should not be the only copies affected by the same credentials or deletion route as production. Document recovery steps and rehearse them in proportion to risk.
8. Integration: treat interfaces as part of the service
Cloud applications rarely stand alone. APIs may connect customer, finance, identity or operational systems. Define authentication, validation, rate limits, retries and reconciliation for each interface.
Third-party availability becomes part of the product experience. Queueing can isolate temporary outages for suitable workflows. Timeouts and user-facing error states should be deliberate. Integration data needs the same privacy and retention consideration as the primary application.
9. Monitoring: see technical and business health
Logging, metrics and alerts should answer whether the system works for its users. Infrastructure health matters, but so do failed enquiries, delayed jobs and synchronisation backlogs.
Centralise relevant logs, set retention intentionally and avoid alerting on every fluctuation. Each actionable alert needs an owner and response. Dashboards should distinguish normal variation from a condition that requires intervention.
10. Cost: understand the drivers
Cloud cost reflects architecture and usage. Storage volume, outbound data transfer, database capacity, logging, always-on compute and high-availability choices can all contribute. Estimate these drivers before launch and revisit them with real use.
Budgets and cost alerts provide early visibility, but they do not replace design. Tagging or another allocation model can show which environment or product generates spend. Cost optimisation should preserve required security and resilience rather than remove controls blindly.
11. Growth: scale the parts that need it
Scalability is not only handling millions of users. It can mean accommodating a larger dataset, more field evidence, a new integration or a busier seasonal period without redesigning everything.
Managed services and automated deployment can support controlled growth. Keep components suitably separated, use documented interfaces and avoid premature distribution. A straightforward architecture that the team understands often scales further than an elaborate one it cannot safely change.
12. Operational ownership: who runs it on Tuesday morning?
Every architecture creates ongoing responsibilities: access reviews, dependency updates, backup checks, incident response, cost review and changes to connected services. Decide what the cloud provider manages, what a delivery partner manages and what remains with the business.
Document deployment and recovery. Restrict and audit changes. Use automation to make releases repeatable. Ensure alerts reach people who can act. A technically impressive stack without operational ownership is unfinished.
Provider choice and proportionality
AWS, Microsoft Azure and Google Cloud each offer mature services. Existing skills, identity platforms, commercial arrangements, data needs and workload fit may influence the choice. Provider neutrality does not require using several clouds; multi-cloud designs add their own operational burden and should answer a real requirement.
For many SMEs, a concise architecture based on public cloud, managed services, strong identity, tested backups and purposeful monitoring is a sound foundation. Other organisations will have constraints that lead to hybrid or specialised choices.
The principle is consistent: begin with the workload, users and data; design security and recovery; understand integrations, cost and growth; and assign operational ownership. Jay Malvern’s AWS cloud architecture and deployment service applies that decision framework to the product rather than starting from an arbitrary stack.