Cloud Cost Control, Reliability and Security Basics for Beginners

Two students build a photo-print start-up as a weekend project. Their first full month's bill is several times what they expected, and nobody can say why. Investigation finds a forgotten test database running around the clock, a pile of unattached disks from deleted servers, a log bucket growing with no expiry, and a NAT gateway carrying traffic they never planned for. None of it was reckless. The cloud simply bills every running thing, whether or not anyone is looking at it. Cost, reliability and security share a root: visibility and defaults.

Cost control starts with seeing the bill

The pay-as-you-go model rewards teams who track usage and punishes those who do not. Four habits catch most surprises. First, tag every resource with an owner, a project and an environment, so a line on the bill maps to a person. Second, set a budget with alerts at several thresholds (for instance half, eighty percent and full, plus a forecast alert if your provider offers one) so you hear about a runaway cost within a day, not at month end. Third, review the bill by service each week while the account is young. Fourth, delete or stop what you do not use, and automate it for non-production environments: development databases and test servers rarely need to run at three in the morning.

1. Open cost-by-service for the last 7 days. What are the top 3 lines?
   - Does each have an owner tag? Untagged spend -> find the owner today.
2. Look for things that run 24/7 but are used for 8 hours/day
   - dev/test databases, staging VMs  -> schedule off-hours shutdown.
3. Look for orphans
   - disks not attached to any server
   - old snapshots/backups beyond the retention policy
   - unused public IP addresses or load balancers with no targets
4. Look for data movement lines
   - data leaving the cloud to the internet (egress)
   - traffic between zones or regions
   - NAT / gateway processing charges
5. Storage growth
   - log or upload buckets with no lifecycle rule -> add expiry or cheaper tier
6. Right-size
   - servers averaging under ~20% CPU for weeks -> try one size smaller
7. Commitments (only after usage is stable for months)
   - discounts for committed usage trade flexibility for lower rates
8. Write down one action per finding, an owner and a date.

Reliability: the arithmetic of availability

Availability is the fraction of time a service works, often quoted in nines. A seemingly small difference in percentage is a large difference in allowed downtime, and redundancy changes the result in a predictable way: components that all must work multiply their availabilities, while redundant copies, any one of which suffices, multiply their failure probabilities. The program below does both, assuming failures are independent, which is the reason to spread copies across zones.

MINUTES_PER_30_DAYS = 30 * 24 * 60

def downtime_minutes(availability):
    return round((1 - availability) * MINUTES_PER_30_DAYS, 1)

for target in (0.99, 0.999, 0.9999):
    print(f"{target:.2%} available -> about {downtime_minutes(target)} min down per 30 days")

def serial(*parts):          # every part must be up
    result = 1.0
    for p in parts:
        result *= p
    return result

def redundant(single, copies):   # service is up if at least one copy is up
    return 1 - (1 - single) ** copies

web, db = 0.999, 0.999
print()
print("one web server + one database  :", f"{serial(web, db):.6f}")
print("two web servers + one database :", f"{serial(redundant(web, 2), db):.6f}")
print("two web servers + two databases:", f"{serial(redundant(web, 2), redundant(db, 2)):.6f}")

99.00% available -> about 432.0 min down per 30 days
99.90% available -> about 43.2 min down per 30 days
99.99% available -> about 4.3 min down per 30 days

one web server + one database  : 0.998001
two web servers + one database : 0.998999
two web servers + two databases: 0.999998

Read the second block carefully. One server plus one database is worse than either alone, because both must work. Doubling only the web tier barely helps while the database remains a single point of failure: the weakest link sets the ceiling. And the independence assumption is the catch: two copies on the same machine or in the same zone fail together, so the real gain comes from placing copies in different zones, as the previous lesson described.

Redundancy does not protect against mistakes, so you also need backups, and two numbers to decide how good they must be. RPO (recovery point objective) is how much recent data you can afford to lose, expressed as time: an RPO of fifteen minutes means backups or replication no more than fifteen minutes behind. RTO (recovery time objective) is how long you can afford to be down while restoring. Tighter RPO and RTO cost more, so set them per system from the business impact, not from habit. The usual recovery strategies form a ladder, and each rung buys faster recovery with more spending.

Whichever rung you choose, test a restore on a schedule: a backup nobody has restored is a hope, not a plan.

Security basics you can apply on day one

Remember the shared responsibility model: the provider secures the cloud, you secure what is in it. Five practices cover most beginner-level risk, and they map onto the framework in Cybersecurity Fundamentals.

• Protect the root account. The account's original owner login can do everything. Enable multi-factor authentication, use it only for rare account-level tasks, and do daily work with named individual users or roles.
• Least privilege. Give each person and each application only the permissions it needs on only the resources it needs. Start narrow and widen on a real error, instead of starting with "administrator for everyone".
• Encrypt in transit and at rest. Use HTTPS/TLS between users and your site and between your own services. Turn on encryption for disks, databases and object storage; most providers make it a checkbox, and it limits damage if a disk or backup leaks.
• Keep secrets out of code. Database passwords and API keys belong in a managed secret store or environment configuration, never in source files or public repositories, and they should be rotatable.
• Log and alert. Turn on audit logging of who did what to your account, and alert on the events that matter, such as root logins, new access keys or changes to firewall rules.

Principal : the 'print-worker' service identity
Action    : read objects, write objects
Resource  : storage bucket 'photo-uploads', path 'incoming/*' only
Condition : requests from the application's private subnets only
Effect    : allow

NOT ALLOWED (default deny): delete bucket, change permissions,
read any other bucket, create new users, view billing.

Real policy languages differ per provider, but they all express the same four things: who, what action, on which resource, under which conditions. A policy you can read aloud in a sentence is usually a good one; a policy that grants "everything on everything" is a breach waiting for one leaked key.

Common mistakes

• Leaving test resources running. Symptom: a bill with steady charges for things nobody remembers creating. Tag with an owner and an expiry date.
• Public storage by accident. Symptom: data discoverable by anyone with the link, often found by security researchers before you notice. Block public access at the account level and open exceptions deliberately.
• Committing keys to a Git repository. Symptom: unfamiliar servers appearing in your account within minutes of a push. Revoke the key immediately, then rotate and clean up; deleting the commit is not enough.
• One big administrator role for the whole team. A single phished account then exposes everything. Use separate roles and require MFA.
• Never testing a restore. Symptom: during a real incident the backup is found to be incomplete, encrypted with a lost key or years old.

How this shows up in real projects and interviews

Entry-level cloud interviews ask about least privilege, MFA, the difference between high availability and backup, and how you would stop a surprise bill. Real teams formalise these as a short "new account baseline": MFA on, root locked away, budgets and alerts set, audit logging on, public storage blocked, tagging rules agreed, backup and restore tested. Setting that up on the first day costs an afternoon; discovering the need for it after an incident costs far more. When you are ready to apply it on a real platform, AWS Fundamentals walks through one provider's version, and you can review the architecture thinking behind it in System Design.