What it is
Everything that has to be true before and after the code is written: infrastructure that is described rather than remembered, a pipeline that builds and ships it, secrets that are not in a repository, containers that behave the same everywhere, and enough monitoring to know something is wrong before a customer says so.
We have run this on both clouds long enough to be plain about the difference between them. AWS has the deeper catalogue and the finer controls; Azure is the easier fit where the rest of the estate is Microsoft. Either can be done well or badly, and the work is the same on both: describe the infrastructure in code, keep every environment reproducible, and leave you able to change it without us.
The two clouds we work on
AWS
Compute is EC2 and Auto Scaling groups where a machine should just be a machine, ECS or EKS with Fargate where a container should be one, and Lambda with API Gateway for the small functions that do not deserve a service. Data and storage are S3 with lifecycle rules rather than as a place things accumulate, RDS and Aurora for relational work, ElastiCache for caches, DynamoDB for key-value at almost any size, and MSK where the event log itself lives on AWS.
Messaging is SQS, SNS and EventBridge, which is where the queues, topics and routing rules that keep the seams between services visible rather than buried in code belong. The edge is CloudFront and Route 53. Identity and keys are IAM, KMS and Secrets Manager - the parts that are really about trust. Operations are CloudWatch, CloudTrail and X-Ray, which is where an incident gets its evidence. And all of it is written down in CloudFormation or CDK, or in Terraform where that is what the estate already speaks.
Azure
Compute is Virtual Machines and scale sets, AKS and Container Apps for containers, and App Service or Functions for the two shapes above. Data and storage are Blob Storage with lifecycle policies, Azure SQL, PostgreSQL Flexible Server, Cosmos DB, and Event Hubs - which is also how a system that already thinks in Kafka arrives on Azure.
Messaging is Service Bus for queues and topics and Event Grid for the routing between services. The edge is Front Door and Azure DNS. Identity and keys are Entra ID, managed identities and Key Vault, so that a service holds no credential of its own to leak. Operations are Azure Monitor and Application Insights. And infrastructure is described in Bicep or ARM templates - or Terraform, when one tool for both clouds is worth more than the native one.
What we do on both
- Infrastructure as code from the first day. Terraform, CDK or Bicep, reviewed like any other change, so an environment is a commit rather than somebody's memory of a console.
- Delivery pipelines. GitHub Actions or the cloud's own tooling: build, test, migrate, deploy, and a way back that has been practised rather than assumed.
- Containers and orchestration. Dockerfiles that are small and honest, and Kubernetes only where it earns the complexity it brings.
- Cost, which is a design conversation. Right-sizing, committed capacity, storage classes, and the idle resources nobody remembers paying for.
- Security and secrets, which is the part an audit asks about: least-privilege identities, encryption, patching, and no credentials in the repository.
- The operational side. Dashboards, alerts that mean something, runbooks, and backup restores that have actually been performed.
- Migration between the two clouds, or out of a rack in an office, without rewriting everything at once.
How it starts
A review of what you run now: the accounts, the pipeline, the bill and the alerts. The first deliverable is usually a short list of changes ordered by what they save or protect, and the second is the first one of them done.
