Your First Cloud Project: Design the Exit Before the Deployment

Start with the smallest useful system

A learning project can become expensive when its resources outlive the lesson. Before deploying, write one sentence describing the outcome. For example: accept a synthetic daily sales file, validate it and produce an aggregate report. If a proposed service does not serve that outcome, leave it out of the first version.

This is a planning method, not a price comparison. No current provider prices or free-tier allowances are assumed. Check the provider’s own billing pages for your chosen account, region and services.

Create a resource ledger

Record every planned resource: storage location, compute process, database if needed, logs and network components. For each, note why it exists, who owns it and how it will be deleted. A small document is enough; the benefit comes from having an explicit inventory.

For the example pipeline, begin with one input location, one execution path and one output. You may not need a database or a permanently running server. Fewer components make the first cost estimate and cleanup easier to inspect.

Estimate more than the headline price

Write down expected input size, execution frequency, output retention and whether data crosses regions or leaves the provider. List uncertainties instead of guessing precise totals. Include the currency in which the provider bills and separately check payment charges or taxes applicable to you.

A learner in Accra, Nairobi or Johannesburg should not assume that the same displayed dollar figure becomes the same local-currency expense. This guide makes no claim about local card eligibility, tax treatment or exchange rates.

Set alerts and understand their limits

AWS documents budget notifications and notes that billing information and notifications can lag usage. A notification is not a guaranteed real-time spending ceiling. Separate budget actions can be configured for supported actions, but you must understand and test what they actually control.

Choose thresholds below the maximum amount you can afford, verify the notification destination and review the billing console during experiments. If you cannot tolerate any charge, do the exercise locally until you understand the service’s billing behaviour.

Rehearse cleanup before you need it

Write the shutdown procedure before starting the workload. Include resources that may persist after compute stops, such as stored objects, snapshots or retained logs. Record what must be kept for your portfolio and what should be deleted.

After the exercise, compare the resource inventory with the account console. Check again after billing data updates. Removing the browser tab does not remove a deployed resource.

What belongs in the portfolio

Publish the architecture, sanitized configuration, a cost-assumption worksheet and the cleanup procedure. Explain why the chosen services fit the workload. Include limitations: untested scale, unavailable recovery features or manual operational steps.

That explanation shows practical judgement. A long service list mainly shows that a menu was available.

Sources and further reading

AWS Budgets best practices

AWS Budgets overview