Renting capability instead of owning every layer
Cloud computing provides compute, storage, networking, and higher-level services through on-demand interfaces. You can provision a server, store an object, or use a managed database without first buying hardware and installing every supporting component.
This changes how infrastructure is obtained, but it does not remove engineering responsibility. Applications still need secure access, capacity planning, recovery procedures, and cost controls. Cloud services shift which layers you operate and which layers the provider operates.
Know which layer you are buying
Infrastructure as a service provides resources such as virtual machines, disks, and virtual networks. You usually manage the operating system and application. Platform services abstract more of the runtime and deployment process. Software as a service provides a finished application that users configure and use.
These labels are broad, and real services overlap. A managed database can remove much of the server maintenance while leaving schema design, query performance, account permissions, data retention, and recovery verification to you.
| Service shape | Provider often handles | You still handle |
|---|---|---|
| Virtual machine | Physical hardware and virtualization | OS, application, access, patch strategy |
| Managed database | Much of infrastructure and engine operations | Schema, queries, permissions, data policies |
| Function platform | Runtime infrastructure and invocation scaling | Code, dependencies, permissions, limits |
| Object storage | Storage infrastructure and durability mechanisms | Access policy, lifecycle, naming, data use |
Exact responsibilities vary by product and configuration. Read the service's shared-responsibility documentation instead of treating “managed” as a promise that every risk is covered.
Regions and availability zones
A region is a geographic deployment area. Availability zones are distinct locations within a region designed to reduce shared infrastructure failure. Their precise design differs among providers.
Placing replicas across zones can improve resilience to a zone failure, but only if networking, data replication, health checks, and traffic routing support that behavior. A database running in one zone can remain a single point of failure even if application servers run in several zones.
Multiple regions can protect against a regional outage or reduce latency for distant users. They introduce harder questions: where can data legally reside, how is state replicated, what happens during conflicting writes, and how will traffic fail over? Start with the required recovery objectives rather than adding regions automatically.
Storage is not one thing
Object storage holds objects identified by keys and is useful for images, backups, logs, and static assets. Block storage behaves like a disk attached to a machine. File storage provides a shared filesystem interface. Databases add structured querying, transactions, and other data guarantees.
Choose based on access patterns. An image upload fits object storage well; a relational application may need a managed SQL database. Durable storage is not the same as a complete backup strategy. Accidental deletion, corrupted application writes, or compromised credentials can require versioning, independent backups, and restore testing.
Scaling has several dimensions
Vertical scaling increases the capacity of one machine. Horizontal scaling adds instances. Autoscaling adjusts capacity using metrics or policies, but the correct metric depends on the workload. CPU can be useful for compute-heavy services; queue depth or request latency may be more informative elsewhere.
A stateless web tier is easier to scale because any instance can handle a request. Sessions, uploaded files, and long-running work should use appropriate shared services rather than depending on an instance's local filesystem.
“Serverless” does not mean servers disappear. It means the provider manages more of the execution infrastructure. Functions can simplify event-driven work, but consider cold starts, execution limits, concurrency, database connections, retry behavior, and pricing under sustained traffic.
Security starts with identity
Use least-privilege access and short-lived credentials where possible. Avoid placing long-lived secrets in source code or container images. Separate human access from application identities, protect administrative accounts, and log significant changes.
Network isolation helps, but a private network is not a replacement for authentication and authorization. Encrypt sensitive traffic, configure storage access deliberately, and keep dependency and operating-system update processes appropriate to the services you operate.
Infrastructure as code makes changes reviewable and repeatable. Protect its state, review destructive plans, and maintain a way to recover when an automated change fails.
Understand the bill before the architecture grows
Costs may include compute time, storage capacity, requests, database operations, logs, backups, inter-zone traffic, and data leaving a region or provider. Small per-request charges can become significant at high volume. Excessive observability data can also become a major expense.
Set budgets and alerts, label resources by owner, and delete unused environments. Compare unit costs such as cost per active customer or per processed job, not just the total bill. A managed service may cost more per infrastructure unit while saving enough engineering work to be the better choice.
For a small web application, a managed deployment platform, database, object storage, and CDN may be sufficient. Add complexity when a measured requirement demands it. The most useful cloud architecture is one that the team can operate, restore, secure, and afford.