Guides

Startup cloud infrastructure: the first 90 days

A sequenced plan for an early-stage startup: what to decide in the first weeks, what to defer, and how credits and cheap compute fit into the first quarter.

Updated September 25, 2026

Startup cloud infrastructure: the first 90 days

Early-stage startups rarely fail because they chose the wrong cloud. They lose time by making irreversible decisions too early, or by never making the reversible ones at all. This guide lays out a sequence for the first 90 days after a founding team opens a cloud account: what to settle in week one, what to build by month two, and which decisions can wait until real usage tells you something.

Days 1 to 7: ownership, access and limits

The first week is about control, not architecture. Decide who owns the root identity on each account, store recovery details somewhere two founders can reach, and turn on multi-factor authentication before anything is deployed. The security baseline for new cloud credentials covers the exact order.

Then set a spending ceiling. Every major provider offers budgets and alerts, and AWS additionally ships Cost Explorer and anomaly detection. A hard rule for the first quarter: no resource gets created before a budget alert exists. If the account carries a promotional balance, note its expiry and which services it covers, because credits are draw-down pools that stop applying once exhausted.

  • Root identity secured, MFA on, recovery contacts documented
  • Individual users or roles for each founder, no shared logins
  • Budget alert at a low threshold, raised later as usage grows
  • Credit balance, expiry and coverage written down

Days 8 to 30: one environment, one region, one repo

The temptation in month one is to design for scale. Resist it. Pick a single region close to your first users, one production environment and one throwaway staging environment. Put every infrastructure definition in version control from the start, even if it is a handful of shell scripts; infrastructure as code for a new account explains how to keep state and secrets separate.

Provider choice at this stage is mostly a question of what your product needs on day one. A team leaning on managed databases, queues and generative AI endpoints will find those on Buy AWS Account and Buy Google Cloud Account listings, where the marketplace carries credit-based options such as the AWS $1K Credit Account and the Google Cloud Prepaid $300 Credit Account. A team shipping a monolith and a Postgres database can run comfortably on plain virtual machines, where a Hetzner 5 Server Limits Account listed on the marketplace is a modest starting point.

Days 31 to 60: measure before you optimize

By the second month there is usage data. Read the first invoice line by line, not just the total; data transfer, snapshots and idle IP addresses are the usual surprises. Tag or label every resource by environment so the bill can be split. If you have not already, add basic monitoring for CPU, memory, disk and error rates, plus a billing alert that pages someone.

This is also when to right-size. New accounts start with conservative quotas, and startups often discover that their first instance choice was either far too large or too small. Resize based on observed peaks rather than guesses.

What to defer

Multi-region deployment, Kubernetes, reserved or committed-use pricing and a second cloud provider all belong after product-market fit. Each locks in spend or adds operational load that a three-person team does not need yet.

Days 61 to 90: reduce blast radius and plan the next quarter

With a stable product, split environments into separate accounts or projects where the provider supports it. AWS Organizations, Google Cloud projects and separate Hetzner projects all give you billing and access boundaries without a migration. Write a short runbook: how to restore from a snapshot, how to rotate a leaked key, who to call when the bill spikes.

Window Decide now Leave for later
Days 1 to 7 Ownership, MFA, budget alert, credit expiry Architecture
Days 8 to 30 Region, one environment, code in version control Second region, Kubernetes
Days 31 to 60 Tagging, monitoring, right-sizing Committed-use pricing
Days 61 to 90 Account separation, runbooks Multi-cloud

Credits change the pace, not the sequence

A credit balance lets a startup run heavier experiments earlier, and the hyperscaler listings on the marketplace go up to the AWS $100K Credit Account and the Google Cloud $25K Credit Account. Credits do not change the order above. Teams that skip the budget alert because “the credits cover it” tend to discover the balance ran out mid-month. The article on how cloud credits work across providers is worth reading before relying on any balance.

The 90-day checklist in one place

  1. Secure ownership and enable MFA on every account.
  2. Set a budget alert before creating the first resource.
  3. Choose one region, one production environment, one staging environment.
  4. Keep every infrastructure definition in version control.
  5. Read the first invoice line by line and tag everything.
  6. Right-size from observed data, not estimates.
  7. Separate environments into accounts or projects once the product is stable.
  8. Write the runbook before you need it.

None of these steps require a large team or a large budget. They require doing things in an order that keeps every early decision reversible until the product tells you which ones deserve to be permanent.

Questions on this topic

Should a startup begin on a hyperscaler or a smaller provider?

It depends on what the product needs in its first month. Managed databases, queues and AI endpoints point toward AWS or Google Cloud. A monolith on a few virtual machines runs well on a provider such as Hetzner at lower cost. The guide on hyperscale or developer-focused cloud lays out the tradeoffs, and switching later is easier when infrastructure is defined in code.

When should a startup set up a second region?

Usually not in the first 90 days. A second region doubles operational surface and only helps once you have users whose latency or availability needs justify it. Focus on a single region, good backups and a tested restore first. Revisit multi-region once traffic patterns and revenue make the extra complexity worth carrying.

How do promotional credits fit into the first quarter?

Credits cover eligible usage until the balance runs out or expires, so treat them as a runway extension rather than free capacity. Record the expiry date, confirm which services they apply to and keep a budget alert active anyway. Listed options such as the AWS $1K Credit Account should be verified for balance and validity before relying on them.

More from the Blog

All articles