Start With Architecture Planning

Before provisioning a single resource, it helps to write down what the system actually needs to do: expected traffic patterns, data sensitivity, compliance constraints, latency requirements and how many environments (dev, staging, production) are needed. Architecture decisions made under this context are far more durable than ones made by copying a reference diagram.

A useful habit is to separate the architecture into layers — network, identity, compute, data, and observability — and decide each layer independently before wiring them together. This keeps the design reviewable and makes it easier to change one layer (for example, swapping a database engine) without redesigning everything else.

Designing the Network Layer

A VPC (or VNet on Azure) is the network boundary for your workloads. The most common production pattern is to split the network into public and private subnets across multiple availability zones:

• Public subnets host internet-facing resources such as load balancers and NAT gateways.
• Private subnets host application servers, containers and databases that should never be directly reachable from the internet.
• Multiple availability zones so a single zone failure does not take down the whole environment.

A simple three-tier layout for a /16 VPC might reserve smaller CIDR blocks per tier and per zone, for example:

10.0.0.0/16   VPC
10.0.0.0/20   public-subnet-az1
10.0.16.0/20  public-subnet-az2
10.0.32.0/20  private-app-az1
10.0.48.0/20  private-app-az2
10.0.64.0/20  private-data-az1
10.0.80.0/20  private-data-az2

Route tables, NAT gateways and security groups then enforce that only the traffic you intend to allow can move between tiers — for example, application servers can reach the database subnet on a specific port, but nothing outside the VPC can reach the database directly.

Identity and Access Management

IAM is easy to under-invest in early and expensive to fix later. The core principle is least privilege: every user, service and pipeline should have exactly the permissions it needs, no more. In practice this means:

• Using roles instead of long-lived static credentials wherever the platform supports it.
• Scoping permissions to specific resources rather than granting account-wide access.
• Separating human access (engineers) from machine access (CI/CD pipelines, application runtime roles).
• Requiring multi-factor authentication for privileged accounts.

Treat IAM policies as code — version-controlled and reviewed like any other infrastructure change — rather than as manual console edits that are hard to audit.

Compute and Storage Choices

Compute decisions (virtual machines, managed containers, or Kubernetes) should follow the workload's operational profile rather than trend. A stateless API with variable load is a good fit for autoscaled compute behind a load balancer; a long-running batch job may be better suited to a scheduled task runner.

Storage should be matched to access pattern: block storage for databases and application state, object storage for backups, logs and static assets, and file storage only when multiple instances genuinely need shared, POSIX-style access. Lifecycle policies on object storage (moving old data to cheaper storage tiers or expiring it) are worth setting up from day one rather than retrofitting later.

Databases and High Availability

For most production systems, a managed database service with multi-AZ replication is the pragmatic choice: it removes a large class of operational work (patching, failover, backups) while still giving you control over instance sizing and network placement.

High availability at the database layer typically means a synchronous standby in a second availability zone, automated failover, and read replicas if read traffic needs to scale independently of writes. It's worth explicitly testing failover in a non-production environment rather than assuming it will work correctly the first time it happens for real.

Backup and Disaster Recovery

Backups and disaster recovery are two different guarantees. A backup protects against data loss or corruption; disaster recovery protects against losing an entire region or environment. Both need explicit targets:

• RPO (Recovery Point Objective) — how much data loss is acceptable, which determines backup frequency.
• RTO (Recovery Time Objective) — how quickly the system must be restored, which determines whether you need a warm standby or can rely on restoring from backup.

Backups that have never been restored are, in practice, unverified. Periodic restore drills are what actually validate a disaster recovery plan.

Security Controls

Security controls for production infrastructure generally cover four areas: network boundaries (security groups, network ACLs, private subnets), identity (IAM, least privilege, MFA), data protection (encryption at rest and in transit, key management) and visibility (audit logging of API and console activity). None of these are optional extras — they are part of the baseline, not something bolted on after launch.

Monitoring and Infrastructure as Code

Production systems need monitoring that answers two questions quickly: is the system healthy right now, and what changed recently. That means metrics and dashboards for the first question, and infrastructure as code with a change history for the second. When infrastructure is defined in code (Terraform, CloudFormation, Bicep, or similar), every change is reviewable, repeatable across environments, and traceable to a specific commit — which turns "what changed before this incident started" into a five-minute question instead of a guessing exercise.

Environment Separation

Development, staging and production should be genuinely separate — separate accounts or subscriptions where possible, separate networks, separate credentials. Sharing an environment across stages of the delivery pipeline is one of the most common causes of "it worked in staging" incidents, because staging quietly stops representing production's actual configuration.

What "Production-Ready" Actually Requires

Pulling this together, production readiness is the combination of a deliberately designed network, least-privilege identity, appropriately chosen compute and storage, a database with a tested failover path, backups with defined RPO/RTO, baseline security controls, monitoring that surfaces both health and change, infrastructure defined as code, and environments that are actually separate from each other. None of these require exotic tooling — they require doing the fundamentals properly and revisiting them as the system grows.