The best cloud platforms are the ones nobody talks about. Deployments are routine. Incidents are rare and short. Costs are predictable. Teams spend their time shipping features instead of fighting infrastructure fires. That is the standard we aim for in every cloud engagement: not impressive architecture diagrams, but day-to-day operational reliability.
Most cloud problems are not exotic edge cases. They come from missing fundamentals: resources created by hand in the console, no useful logs when something breaks, identities with far more permissions than they need, and staging environments that quietly drift away from production.
We build on four foundations, whether the target is Azure, AWS, or a hybrid setup.
1. Infrastructure as code
Every resource, from networks and databases to DNS records and alert rules, should be defined in code, reviewed like application code, and applied through a pipeline. We use Terraform (or its open-source fork, OpenTofu) when teams want one tool across providers, and Bicep when a team is committed to Azure and wants first-party tooling. AWS CDK or CloudFormation are reasonable choices for AWS-only teams.
What matters more than the tool:
- Remote state with locking, so two engineers cannot apply conflicting changes at the same time.
- Modules for repeated patterns, such as a standard web app with its database, secrets, and monitoring, so each new service starts from a known-good baseline.
- Plan before apply. Every change produces a plan that is reviewed in the pull request before it touches a real environment.
- No manual changes in production. If an emergency fix is made by hand, it is written back into code the same day, and drift detection runs regularly to catch anything missed.
2. Observability from day one
You cannot operate what you cannot see. Observability should exist before the first user arrives, not after the first outage.
In practice we set up:
- Structured logs with consistent fields (request ID, user or tenant, service, environment), centralized in Azure Monitor and Log Analytics, Amazon CloudWatch, or an open-source stack such as Grafana with Loki and Prometheus.
- Metrics and traces, ideally through OpenTelemetry, so a slow request can be followed across services and databases.
- Health checks and alerts tied to user impact, such as error rates, latency, and failed background jobs, rather than alerts on every CPU spike.
- Runbooks linked from alerts, so whoever is on call knows the first steps.
Logs and metrics also inform cost. Knowing what each service consumes makes conversations about budgets and right-sizing factual instead of speculative.
3. Least-privilege identity
Over-permissive identity is one of the most common and most dangerous cloud weaknesses. Our baseline:
- Managed identities on Azure and IAM roles on AWS for workloads, instead of long-lived access keys in configuration files.
- Secrets in Key Vault or Secrets Manager, never in source code or in plain-text pipeline variables, with rotation where the service supports it.
- Narrow, purpose-specific roles. The application can read its own storage container, not every container in the subscription or account.
- Human access through single sign-on with multi-factor authentication, time-limited elevation for administrative tasks, and regular reviews of who has access to what.
- Pipeline identities using workload identity federation (OIDC) where supported, so CI/CD does not hold static cloud credentials.
4. Gated promotion paths
Development, staging, and production should be built from the same code with different parameters, so that what passed in staging is what runs in production.
A healthy promotion path looks like this:
- Every merge builds an immutable artifact, such as a container image tagged with the commit.
- The same artifact is deployed automatically to development, then to staging.
- Automated tests, migrations, and smoke checks run against staging.
- Promotion to production requires an explicit approval gate, and the deployment strategy (rolling, blue-green, or deployment slots) allows a quick rollback.
Database migrations deserve special care: make them backward-compatible so the previous application version can still run if you need to roll back.
Azure or AWS?
The principles hold on both providers. Provider-specific choices, such as AKS or EKS, Azure SQL or RDS, App Service or ECS, depend on your team's skills, existing licensing and contracts, regional availability, and data-residency requirements. Many workloads do not need Kubernetes at all; a managed container platform such as Azure Container Apps or ECS on Fargate is often simpler to run. We recommend choosing the simplest platform that meets your requirements, then applying the four foundations consistently.
Foundations that let teams ship
This is the baseline we set up at the start of our own cloud engagements: networking, identity, pipelines, and monitoring, all in code, before the first feature is deployed. It costs a few weeks up front and pays for itself the first time something breaks at 2 a.m. and the on-call engineer can see what happened. When the foundations are right, the infrastructure fades into the background, and reliability becomes the default rather than the exception.