How to Build a Secure, Scalable and Operable Cloud Foundation

Key takeaways

A reliable cloud foundation combines governance, security, resilience, automation, observability, cost control, and clear operational ownership.
Cloud architecture should be selected according to workload requirements rather than forcing every application into containers, Kubernetes, serverless, or another fixed technology stack.
A governed landing zone and infrastructure as code help organisations manage identities, networks, policies, resources, and cloud environments consistently and securely.
High availability and disaster recovery are different concerns. Recovery must be designed around agreed RTO and RPO targets and supported by tested backups, restore procedures, and incident runbooks.
Cloud maturity should be measured through outcomes such as service reliability, recovery time, deployment quality, security remediation, cost visibility, and developer efficiency, not by the number of tools being used.

Cloud infrastructure is the combination of technology, controls and operating practices used to run workloads in the cloud. It includes accounts or subscriptions, identity and access, networking, compute, data services, security, deployment automation, observability, backup, recovery and cost management.

A strong cloud foundation makes these capabilities reusable and consistent. It gives application teams a safe starting point without forcing every workload into the same architecture. At WeAre, our aim is to combine proven AWS and Azure practices with automation and clear ownership, so customers can develop and operate services without rebuilding the platform for every application.

The right design is not the one with the longest list of cloud products. It is the one that meets the workload’s business, security, availability, recovery, performance and cost requirements with the least unnecessary complexity.

What should a modern cloud foundation achieve?

Capability	Desired outcome
Governance	Accounts, subscriptions, regions, policies, ownership and exceptions are managed consistently.
Security	Identity, secrets, data, networks, software supply chains and administrative access are protected by design.
Reliability	Workloads tolerate expected failures and recover within agreed business targets.
Delivery	Infrastructure and applications can be changed safely, repeatedly and with an audit trail.
Operability	Teams can understand service health, detect meaningful problems and respond with clear ownership.
Cost control	Resources have owners, budgets and cost allocation data, and waste can be identified.
Developer experience	Teams can use approved patterns without waiting for repetitive manual infrastructure work.

These outcomes align with the broader principles in the AWS and Azure Well-Architected frameworks. They should be translated into decisions and controls that fit the customer’s organisation, workload and regulatory context.

Start with workload requirements, not a fixed technology stack

Cloud platforms offer several valid ways to run an application. A team might choose a managed web application platform, containers, serverless functions, managed Kubernetes or virtual machines. The correct option depends on factors such as application architecture, scaling behaviour, latency, portability, data requirements, operational skills and cost.

Managed services are often a good default because they can reduce undifferentiated maintenance and transfer some platform responsibilities to the provider. They do not remove the customer’s responsibility for secure configuration, identities, data, application code, monitoring, recovery planning and compliance.

The decision should therefore be explicit. For each major service, document why it was selected, what responsibilities remain with the delivery team, how it fails, how it is updated, how data is protected and how the service can be replaced or migrated if necessary.

Build a governed landing zone

A cloud foundation normally begins with a landing zone. This is the governed environment in which workloads are deployed. The exact structure varies, but it commonly covers:

account, subscription and management-group structure
identity federation, privileged access and break-glass access
network topology, connectivity, DNS and ingress or egress controls
approved regions and data-location requirements
central security, audit and activity logs
resource naming, tagging, ownership and cost allocation
policy guardrails and an exception process
shared services and platform responsibilities
backup, recovery and incident-management requirements

Large organisations may need separate platform, security, connectivity and workload areas. A smaller cloud-native organisation may need a lighter structure. The goal is not to reproduce a complex reference architecture in every environment. The goal is to make essential controls repeatable and visible.

Infrastructure as code should be the normal mechanism for creating and changing the foundation. It improves repeatability, reviewability and recovery, but it is not a substitute for architecture, testing or operational ownership.

Prefer managed services when the trade-off is favourable

Managed databases, queues, object storage, application platforms and identity services can reduce the amount of operating-system and middleware maintenance performed by the application team. They can also provide integrated options for scaling, backup, encryption and monitoring.

Managed does not mean maintenance-free or automatically highly available. Capabilities vary by service, region, pricing tier and configuration. Some updates are automatic, while others require scheduling, compatibility testing or an explicit major-version upgrade. Some services are regional, some are zonal, and some need a multi-zone option to be enabled.

Before adopting a managed service, assess:

functional and performance fit
availability and recovery characteristics
customer and provider responsibilities
network and identity integration
encryption and key management
backup and restore behaviour
observability and audit data
update and version policy
portability and exit options
total cost at expected and peak usage.

This produces a more sustainable platform than a blanket rule that every available managed service must be used.

Design high availability around failure modes

High availability starts by identifying what can fail and what the business impact would be. Availability Zones are isolated locations within a cloud region, not simply interchangeable labels for conventional data centres. Deploying across multiple zones can protect against some infrastructure failures, but only when the selected service supports it and the workload is configured accordingly.

A highly available design may include:

multiple application instances across supported Availability Zones
health-based traffic routing and automatic replacement of unhealthy instances
data services configured for appropriate redundancy and failover
removal of single-instance dependencies
capacity headroom and tested autoscaling
timeouts, retries with backoff, circuit breaking and graceful degradation
monitoring of the full dependency chain.

Autoscaling also requires care. Scaling signals vary by platform and workload. CPU can be useful for some services, while request rate, latency, queue depth or a business-specific metric may be more meaningful for others. Scaling limits and downstream capacity must be tested so that one tier does not overload another.

High availability within one region is not the same as disaster recovery. A separate recovery design may be needed for regional disruption, data corruption, a security incident or a deployment that damages production data.

Choose application platforms by workload

Containers can provide consistent packaging, process isolation and a practical unit for deployment and horizontal scaling. They are useful for many applications, but containerisation is not automatically the best option for every workload.

Where containers are used, application processes should be designed to be disposable and stateless where practical, while durable state is stored in an appropriate data service. Containers can still run stateful workloads, but the data lifecycle, replication and recovery design must be explicit.

Useful container controls include:

minimal, trusted and maintained base images
running as a non-root user where supported
read-only filesystems and dropped Linux capabilities where practical
restricted network access and least-privilege workload identities
image provenance, software bills of materials and vulnerability scanning
defined patch and remediation targets
prevention of secrets in images, source repositories and build logs.
Removing a few operating-system commands from an image is not a sufficient hardening strategy. Reducing the image and privilege level, controlling provenance, scanning continuously and rebuilding promptly are more meaningful controls.

For suitable web applications, managed platforms such as AWS Elastic Beanstalk or Azure App Service can handle parts of deployment, capacity, load balancing, scaling and health monitoring. Serverless services can be effective for event-driven or intermittent workloads. The platform decision should remain workload-specific.

Automate infrastructure safely

Infrastructure as code enables the same reviewed configuration to be used across environments. It supports repeatable deployments, change history, peer review and rebuilding. HCP Terraform, previously called Terraform Cloud, is one possible platform for managing Terraform workflows and state.

A mature infrastructure workflow includes:

modular and versioned code
peer-reviewed pull requests
automated formatting, validation and policy checks
a clear plan review before changes are applied
protected production approvals appropriate to risk
secure remote state and limited access
drift detection and a controlled process for emergency changes
tested module and provider upgrades
documented ownership and support.

Infrastructure code can recreate resources, but it cannot by itself restore business data, external dependencies, certificates, DNS, secrets or operational knowledge. Those elements belong in the continuity and recovery design.

Use CI/CD to make changes small, testable and reversible

The objective of continuous delivery is not to release every hour at any cost. It is to make changes safe enough that teams can release when the business needs them.

A deployment pipeline can include:

build and dependency verification
unit and integration tests
static analysis and security checks
container or artifact scanning
infrastructure validation and policy checks
deployment to an isolated test or preview environment where valuable
smoke tests after deployment
change evidence and an audit trail
controlled promotion to production
health checks and a defined recovery action.

Temporary environments for pull requests can be valuable for complex user journeys and integration testing. They also create cost, data-handling and cleanup responsibilities, so they should be automated, access-controlled and removed when no longer needed.

Different deployment strategies suit different platforms. Rolling, immutable, blue-green or traffic-splitting deployments can reduce risk. Azure App Service deployment slots and AWS Elastic Beanstalk deployment policies are examples of platform capabilities that can support safer releases.

Rollback must not be oversold. Application code can often be returned to a previous version, but database migrations and external side effects may not be safely reversible. Backward-compatible schema changes, staged migrations, feature flags, tested restore procedures and forward-fix plans are often more reliable than a promise of one-click rollback.

Test the system at several levels

End-to-end browser testing is useful, but no single tool can continuously prove that every feature works. A balanced strategy combines tests according to the risk and architecture of the service.

This can include:

unit tests for business logic
integration and contract tests for service boundaries
component and end-to-end tests for important user journeys
accessibility checks
performance and capacity tests
infrastructure and policy tests
security testing and dependency scanning
backup restoration and disaster-recovery exercises
smoke tests and synthetic checks in running environments.

Cypress can support end-to-end, component and accessibility testing, while other tools may cover APIs, performance, infrastructure and security. The important outcome is useful feedback and risk reduction, not the number of automated tests.

Protect secrets and machine identities

Secrets should not be stored in source code, container images or ordinary configuration files. A central secret-management service can control access and provide audit data. Workloads should receive only the secret they need, for the time they need it.

Depending on the platform and customer requirements, this can involve a cloud-native secret manager, a service such as 1Password Secrets Automation, or short-lived identities that avoid static secrets altogether.

Important controls include:

least-privilege access for people, workloads and delivery pipelines
separate identities for separate applications and environments
short-lived credentials where supported
rotation and revocation procedures
audit logging and alerting for sensitive access
prevention of secret values in logs and error messages
careful treatment of infrastructure state files.

Marking a Terraform value as sensitive redacts it from normal command output, but the value can still be stored in state. Ephemeral values and write-only arguments can reduce persistence when supported, but state access and backend security remain important.

No system can truthfully guarantee that a secret is never visible anywhere. The consuming process must receive or use the credential, and poor logging or debugging can expose it. The practical goal is to minimise where secrets exist, who can retrieve them and how long they remain valid.

Define disaster recovery through business targets

Disaster recovery begins with two business decisions:

the recovery time objective, or RTO, which describes how quickly the service must be restored
the recovery point objective, or RPO, which describes how much data loss the business can tolerate.

These targets determine the architecture and cost. A workload might restore from backup, maintain a pilot-light environment, keep a warm standby, or operate actively in more than one region. Not every workload needs the same strategy.

A complete recovery plan covers more than database backups. It should address:

application and infrastructure code
databases, object storage and message data
identity, keys, certificates and secrets
network, DNS and external integrations
build artifacts and third-party dependencies
monitoring and administrative access during an incident
runbooks, decision authority and communication
restoration, failover and failback testing.

Backup retention varies by database service and configuration. Exact claims such as a universal 72-hour live restore window, 35 days at one-second intervals or one year of weekly images should not be published unless they describe a verified customer-specific policy. Cloud services offer configurable point-in-time recovery and long-term retention options, but recovery must be configured, protected and tested.

Object storage also needs a data-protection design. Durability does not automatically protect against accidental deletion, malicious changes, inappropriate lifecycle rules or loss of credentials. Versioning, replication, object lock, backup, lifecycle controls and cross-account or cross-region copies may be appropriate depending on the risk.

Want to learn more about why SLA monitoring matters for modern ITOps? Read our full blog here.

You can also read about our SLA case study here.

Design shared integrations as a product

A shared integration layer can prevent every application from rebuilding the same ERP, partner or country-specific connection. It can translate data formats, centralise common controls and make application code more reusable.

The shared layer also becomes an important dependency. It should therefore be operated as a product with:

a named owner and service expectations
documented and versioned APIs or event contracts
authentication, authorisation and data validation
idempotency, retries, timeouts and dead-letter handling
capacity limits, throttling and tenant isolation where needed
observability, audit logging and support procedures
backward compatibility and a deprecation process
availability and recovery appropriate to its impact.

Serverless technology can be a good implementation choice for an integration layer, but “serverless” does not remove the need to manage architecture, security, observability, limits and cost.

Centralise logs, metrics, traces and operational context

Centralised logging can make troubleshooting and investigations faster by bringing together application, platform, security and audit events. It is most useful when events include consistent timestamps, environment and service identifiers, correlation IDs and ownership information.

Logs should not be collected without limits. Define which sources matter, who can access them, how long they are retained, where they are stored, how integrity is protected and how sensitive data is redacted. Passwords, private keys and unnecessary token values must not be logged.

Business dashboards can be built from operational data when the source, definition, freshness and owner of each metric are clear. Not every application log is a reliable business event, so important KPIs often deserve an explicit event model.

Observability combines telemetry with service context to help teams understand system behaviour. A useful operating model includes:

service-level indicators and objectives for important user journeys
metrics, logs, traces, events and synthetic checks where appropriate
dynamic discovery plus explicit service ownership
alerts tied to user or business impact
documented response actions and escalation routes
incident reviews and tracked improvement work.
Automatic anomaly detection and correlation can help responders find likely causes. They do not guarantee a correct root-cause analysis. Human investigation, system knowledge and good telemetry remain necessary.

If your organisation needs help centralising and governing operational data, read about centralised log management and archiving. For a managed observability operating model, see Observability as a Service.

Observability Playbook

WeAre’s Observability Playbook is a practical guide for IT, DevOps, platform, and business teams that want to understand how observability helps improve visibility, reduce downtime, and connect technical performance to business outcomes. It explains how logs, metrics, and traces work together, why observability matters in modern distributed environments, how mature observability practices companies have, and how organisations can move step by step from reactive troubleshooting toward faster incident response, shared visibility, and stronger operational trust.

Reuse components without creating hidden coupling

Shared application and infrastructure components can reduce duplication and improve consistency. A shared component library works best when it has clear ownership, documentation, versioning and a secure update process.

Teams should be able to understand which version they use, receive security updates, test upgrades and move away from a component when it no longer fits. Reuse should reduce repeated work without turning one library or platform team into a bottleneck for every application.

Measure outcomes, not the number of tools

Cloud maturity is better demonstrated through results than through a list of products. Useful measures can include:

deployment frequency and change failure rate
mean time to restore service
service-level objective performance
age and remediation time of critical vulnerabilities
backup restore success and recovery-exercise results
policy compliance and documented exceptions
percentage of resources with an owner and cost allocation tag
cost variance and identified waste
alert quality and incident recurrence
developer lead time for a new environment or service.

Metrics should lead to decisions. A high deployment frequency is not valuable if changes frequently fail. A large number of alerts is not evidence of strong monitoring. A successful backup job is not evidence of recoverability until restoration has been tested.

Cloud infrastructure implementation checklist

Before calling a cloud foundation production-ready, confirm that:

business owners have approved availability, RTO and RPO targets
accounts or subscriptions, identity, networking and policy guardrails are defined
every production service and shared component has an owner
infrastructure changes are versioned, reviewed and auditable
privileged access and emergency access are protected and tested
durable data has a documented backup and recovery design
multi-zone or multi-region choices match the actual failure scenarios
secrets and machine identities are managed with least privilege
artifacts and container images are traceable, scanned and patched
deployment and database-change recovery have been tested
logs, metrics, traces and alerts support important user journeys
sensitive telemetry is minimised, protected and retained intentionally
costs, tags, budgets and capacity are reviewed
incident, recovery and supplier-dependency runbooks are current
architecture and controls are reviewed as the workload evolves.