W3 NOTES BLOG | The Internet Money Feed : CLOUD ARCHITECTURE | Turn an Application’s Requirements Into a Practical Cloud Design — Choose Compute, Data, Networking, Security, and Recovery Before You Deploy

A cloud application does not begin with a virtual machine, a

database, or a button labelled Deploy.

It begins with a problem that needs to be solved.

Perhaps a business wants customers to book appointments online. Perhaps a developer wants to launch a directory of local businesses. Perhaps a publisher wants to build a digital tool that readers can use from their phones.

Each project needs an architecture: a plan showing which components the application requires, how those components communicate, where information is stored, how access is protected, and what happens when something fails.

Getting these decisions right can reduce unnecessary spending, prevent avoidable failures, and make future development easier.

This chapter introduces a practical method for turning application requirements into a cloud design. You will follow one example from the initial requirements to an architecture that could be evaluated before implementation.

The goal is not to choose the most complicated cloud setup. It is to choose the simplest design that can meet the application’s real needs.

What you will learn

By the end of this chapter, you should be able to:

Translate application requirements into infrastructure requirements.
Choose an appropriate starting point for hosting application code.
Decide whether you need a managed database, object storage, or both.
Understand the roles of domains, DNS, HTTPS, networking, and application access controls.
Plan for monitoring, backups, recovery, and predictable costs.
Recognize when a simple architecture is sufficient—and when it needs to evolve.

1. Start with the application, not the cloud provider

Imagine that you are building a small appointment-booking application for a local service business.

Customers should be able to view available services, submit booking requests, and receive confirmation. The business should be able to review and manage bookings.

Before selecting any cloud services, write down what the application must do.

Functional requirements

These describe what users need to accomplish.

Requirement	What the application needs
Display services	A web interface and access to service information
Accept booking requests	Application logic and input validation
Store appointments	A persistent data store
Let staff manage bookings	Authentication and role-based authorization
Send confirmations	An email or messaging integration
Allow customers to return	A domain name and a reachable application

Non-functional requirements

These describe how well the application must work.

Consider:

Availability: How much downtime can the business tolerate?
Performance: How quickly should pages and booking requests respond?
Security: Which information is sensitive, and who may access it?
Recovery: How much data loss is acceptable after a failure, and how quickly must service return?
Cost: What monthly operating cost can the business sustain?
Maintenance: Who will deploy updates, monitor problems, and manage access?

These questions matter because two applications with identical features may need very different architectures.

A demonstration project used by a handful of people does not automatically need the same infrastructure as a nationwide booking platform handling large volumes of simultaneous requests.

The first design principle: infrastructure should be justified by requirements, not by the number of services a cloud provider offers.

2. Draw the application’s basic architecture

For the booking application, begin with the following conceptual design:

CUSTOMER OR STAFF MEMBER
          |
          v
     WEB BROWSER
          |
          v
    DOMAIN AND DNS
          |
          v
   HTTPS CONNECTION
          |
          v
   HOSTED WEB APPLICATION
          |
          +-------------------+
          |                   |
          v                   v
   MANAGED DATABASE      EMAIL SERVICE
          |
          v
    DATABASE BACKUPS

This is a logical diagram, not a vendor-specific deployment recipe. The actual services and network boundaries depend on the selected platform.

The diagram answers several important questions:

Where does the user enter the application?
Where does the application execute?
Where is the business data stored?
Which external services does it depend on?
How will the data be recovered if something goes wrong?

It also makes missing decisions visible. For example, the diagram does not yet explain how staff accounts are protected, how errors are detected, or how the application is updated.

Those decisions belong in the architecture too.

3. Choose how the application will run

The component that executes your application code is its compute environment. In cloud systems, there are several ways to provide it.

Option A: Static hosting

Static hosting serves files such as HTML, CSS, JavaScript, images, and other assets.

It can be an excellent fit for documentation sites, portfolios, landing pages, and frontends that communicate with an external API.

However, static hosting alone does not execute a conventional server-side application or safely perform private database operations. If your website needs a backend, you must provide that capability separately.

Option B: A virtual machine

A virtual machine gives you a computing environment in which you can install and configure an operating system, web server, runtime, and application.

It provides flexibility, but you also take responsibility for more operational work, such as operating-system updates, service configuration, access control, and recovery procedures.

A VM can be appropriate when you need control over the environment or must run software that a more managed platform does not support.

Option C: A managed application platform

A managed application platform runs your application while taking responsibility for some of the underlying infrastructure and operational tasks.

Depending on the platform, it may manage parts of deployment, runtime maintenance, scaling, and service health.

This can be a practical starting point for a small web application when the required language, framework, networking, and data integrations are supported.

Option D: Serverless functions or services

Serverless options let developers run code or use services without managing conventional servers directly.

They can be useful for event-driven tasks, lightweight APIs, scheduled jobs, and workloads whose usage varies. However, request limits, execution duration, cold starts, concurrency, networking, and pricing may influence the choice.

Serverless does not mean that infrastructure disappears. It means the provider manages more of it.

Which should you choose?

For our hypothetical booking application, a managed application platform is a reasonable starting candidate because the goal is to deliver a working service without taking on unnecessary server administration.

That is a provisional design decision, not a universal rule. If the application needs specialized system access, a VM may be more suitable. If the frontend is static and the backend is small, static hosting combined with a managed API may be simpler.

Before committing, verify that the platform supports the application’s runtime, deployment process, networking requirements, persistent connections if needed, and expected workload.

4. Choose the right place for each kind of data

Not all data belongs in the same type of storage.

Our booking application may contain service descriptions, customer details, appointment times, and uploaded documents. Each kind of information has different requirements.

Use a database for structured application records

A relational database is a strong candidate when information is connected and must remain consistent.

For example, a booking may refer to a customer, a service, a staff member, and a time slot. The database can represent these relationships and enforce appropriate constraints.

The design should consider:

Which records must be stored?
Which relationships must remain valid?
Which queries will the application perform?
Which users or application components may read or change the records?
What backup and recovery facilities are available?

A managed database may reduce the work of maintaining database infrastructure, but it does not eliminate the need to design data access, permissions, backups, or recovery procedures.

Use object storage for files

Object storage is designed for files and other unstructured objects. It can be appropriate for uploaded documents, images, exports, and generated reports.

If customers upload files, do not assume that placing them in storage makes them private. Configure access controls, validate uploads, and determine whether files should be available publicly or only through authorized access.

Keep database records and uploaded files conceptually separate unless there is a specific reason to combine them.

Do not confuse storage with backup

A database that is running is not necessarily recoverable. A file stored in the cloud is not automatically protected against accidental deletion, account compromise, or an incorrect change.

Plan for backup retention, access restrictions, and recovery testing. Where the consequences justify it, consider keeping recovery copies protected from the same administrative actions that could damage the original data.

A backup strategy is only useful if you know how to restore the application and its data.

5. Design the network and access path

The user’s browser must reach the application, and the application must reach the services it depends on. Network design determines how that communication happens.

For a small application, the path may look like this:

A customer enters the application’s domain name.
DNS helps the device locate the relevant service.
The browser establishes an HTTPS connection.
The hosted application receives the request.
The application communicates with its database or other authorized services.
A response returns to the browser.

The actual path varies by hosting provider and architecture. A small managed deployment may not require you to configure a virtual network, load balancer, or multiple subnets yourself.

Do not add networking components simply because they appear in enterprise architecture diagrams.

Instead, establish the necessary boundaries:

Which components must be reachable from the public Internet?
Which components should accept connections only from the application?
Which administrative interfaces need restricted access?
How will encrypted connections be configured and renewed?
Are any external services required for email, payments, identity, or file processing?

For our booking application, the public web interface must be reachable. The database should not be exposed to the entire Internet merely to make application connectivity convenient.

Where the chosen platform supports private database connectivity, use it when appropriate. Otherwise, configure the platform’s supported network restrictions and database access controls.

6. Protect identities, secrets, and customer data

Security is not a separate feature that can be added after the architecture is finished. It influences how the components are connected and operated.

Start with the following controls.

Authentication and authorization

Authentication establishes who a user is. Authorization determines what that user is permitted to do.

A customer may be allowed to view and manage their own bookings. A staff member may need access to the business’s booking dashboard. An administrator may need additional permissions.

These roles should be enforced by the application or an appropriate identity service—not merely by hiding buttons in the interface.

Protect credentials and secrets

Database passwords, API keys, signing keys, and other secrets should not be placed in public frontend code or committed to a source-code repository.

Use the hosting platform’s supported secret-management or environment-configuration mechanisms. Restrict which people and services can access each secret, and rotate credentials when required.

Apply least privilege

Give each user, application component, and service only the permissions it needs.

For example, the public frontend should not receive unrestricted database credentials. A service that only needs to read a particular type of information should not automatically receive permission to delete every record.

Validate and protect incoming data

Validate data on the server side, enforce appropriate authorization checks, and use database operations safely. Apply suitable controls to file uploads and sensitive personal information.

Use HTTPS for communication in transit, keep software dependencies maintained, and review the security configuration of the selected services.

For additional guidance, consult the Google Cloud Well-Architected Framework and the AWS Well-Architected Framework. Their detailed recommendations are provider-specific in places, but their broader emphasis on security, reliability, operational excellence, performance, and cost is useful when evaluating a design.

7. Decide how the application will recover from failure

A reliable design does not assume that every component will always work.

The application could become unavailable because of a deployment error, a failed service, an exhausted resource limit, a damaged data record, an expired credential, or a wider provider incident.

You do not need to eliminate every possible failure before launching. You do need to understand which failures matter and prepare proportionate responses.

Define two recovery targets

Recovery Point Objective (RPO) describes how much recent data the business can afford to lose, measured in time.

Recovery Time Objective (RTO) describes how long the business can afford to take to restore service after a disruption.

Suppose the booking business decides that losing a whole day of appointments would be unacceptable. That requirement influences the backup frequency and recovery design.

If the business must resume accepting bookings quickly, that influences how restoration is performed and tested.

These are illustrative requirements, not universal targets. The business must choose them based on the consequences of downtime and data loss.

Build a practical recovery plan

At minimum:

Identify the information that must be recoverable.
Check what backups or recovery mechanisms the chosen database and storage services actually provide.
Define retention periods and access restrictions.
Document how to restore the data.
Test the restoration process in a safe environment.
Record the steps required to bring the application back online.
Review the plan when the architecture changes.

Do not claim that an application is highly available merely because it runs in the cloud. Availability depends on the actual design, provider capabilities, configuration, dependencies, and recovery procedures.

Multi-zone or multi-region deployment may be justified when business requirements demand it. It also introduces additional complexity and potential cost. Choose it based on a defined reliability target rather than as a default badge of technical sophistication.

8. Monitor the application after deployment

Deployment is the beginning of operation, not the end of the project.

You need enough visibility to determine whether the application is working, whether users are experiencing errors, and whether resources are approaching their limits.

Begin with a small set of useful signals:

Availability: Can users reach the service?
Errors: Are requests failing unexpectedly?
Latency: Are requests taking longer than expected?
Resource use: Are compute, memory, storage, or connection limits being approached?
Database health: Are queries failing or becoming unusually slow?
Security events: Are there suspicious access attempts or unexpected permission changes?
Costs: Is resource consumption rising beyond the expected budget?

Use the monitoring and logging features supported by the selected platform. Set alerts for problems that require action, and avoid collecting or retaining sensitive information unnecessarily in logs.

A useful alert should tell someone that a meaningful condition has occurred and, where possible, help them investigate it.

Monitoring also supports improvement: recurring slow requests may indicate a query problem, while repeated resource exhaustion may suggest that the application or its capacity needs to change.

9. Estimate and control costs before launch

Cloud costs depend on the services selected, the region, usage, storage, network traffic, support arrangements, and other pricing rules.

A service that looks inexpensive at low usage may cost more as traffic or data grows. Conversely, a highly elaborate architecture may waste money when a simple managed deployment would meet the requirements.

Create a basic cost model before deploying.

Cost area	Questions to investigate
Compute	Is the service continuously running or billed by use?
Database	What are the charges for capacity, storage, requests, and backups?
File storage	How much data will be retained, and how often will it be accessed?
Networking	Are there charges for data transfer, gateways, or external access?
Monitoring	What are the costs of logs, metrics, retention, and alerts?
Recovery	Do backup copies or redundant deployments create additional charges?
Other services	Are email, identity, domain registration, or integrations billed separately?

Use the provider’s current pricing calculator and service documentation for the intended configuration. Do not rely on a generic monthly figure when you have not specified the region, usage, or service configuration.

Then establish safeguards:

Set budgets and available billing alerts.
Tag or label resources where supported.
Remove abandoned test resources.
Review usage and bills regularly.
Understand what happens when a free allowance or trial expires.
Keep a record of the assumptions behind the estimate.

An alert may warn you about spending, but it does not necessarily stop the charges. Verify the provider’s actual budget and enforcement features.

For a small business, predictable operating costs are part of the architecture—not an afterthought.

10. Put the decisions together

Our hypothetical booking application now has a preliminary design.

Design area	Initial decision	Reason
Application hosting	Evaluate a managed application platform	Reduce infrastructure administration
Data	Use a managed relational database if supported and appropriate	Store related booking records consistently
Files	Add object storage only if the application needs file uploads or generated files	Avoid unnecessary components
Network	Expose the web application through the platform’s supported secure access path	Let users reach the service without exposing every component
Identity	Enforce customer, staff, and administrator permissions	Protect accounts and business records
Secrets	Use supported secret-management mechanisms	Avoid exposing credentials in code
Recovery	Define RPO and RTO, then configure and test suitable backups	Make data loss and downtime manageable
Monitoring	Track availability, errors, latency, and resource use	Detect and investigate problems
Costs	Estimate the full service configuration and set alerts	Reduce bill surprises

This is an initial architecture, not a claim that a particular application is production-ready. Before implementation, validate the choices against the application’s framework, workload, security needs, operational skills, and actual provider capabilities.

The next step is to select a candidate platform and confirm that each required capability is available at an acceptable cost.

11. Use a pre-deployment checklist

Before launching a cloud application, work through this checklist.

[ ] The application’s purpose and essential features are documented.
[ ] Expected users, usage patterns, and performance needs are understood.
[ ] The hosting approach supports the application’s runtime and framework.
[ ] Data has been classified, and the correct storage types have been selected.
[ ] Public and private access paths are understood.
[ ] HTTPS and appropriate identity controls are configured.
[ ] Credentials and API secrets are not exposed in public code.
[ ] Permissions follow the principle of least privilege.
[ ] Backups, retention, and recovery requirements are defined.
[ ] The recovery process has been tested where feasible.
[ ] Monitoring and actionable alerts are configured.
[ ] Current service pricing has been reviewed.
[ ] Budget controls and resource-cleanup procedures are in place.
[ ] Deployment and rollback procedures are documented.
[ ] The application has been tested before production use.

A checklist does not replace a security review or production-readiness assessment. It helps make important omissions less likely.

12. Know when to improve the architecture

A good architecture is not necessarily the most advanced architecture. It is an architecture that meets its requirements and can evolve as those requirements change.

Consider adding or changing components when you have evidence that the current design is insufficient.

Examples include:

A content delivery network (CDN) when geographically distributed users or static assets justify it.
A cache when repeated reads are expensive and caching can be implemented without compromising correctness.
A background queue when work should be processed asynchronously or retried safely.
A load balancer or additional application instances when traffic, availability targets, or deployment needs require them.
Stronger isolation when the security or compliance requirements demand it.
Multi-zone or multi-region design when the required availability and recovery targets justify the extra cost and operational work.

Each additional component introduces configuration, dependencies, monitoring, and possible failure modes. Complexity should buy a measurable benefit.

This is the central architectural trade-off: build enough infrastructure to satisfy the requirement, but not so much that the infrastructure becomes a problem of its own.

A practical exercise: design before you deploy

Choose a small application you may want to build, such as a business directory, appointment system, learning resource, or digital publishing tool.

Write down your answers to these questions:

Who will use it, and what must they be able to do?
What data must it store?
Does it need server-side code, or can some functions be served as static files?
Which parts must be publicly accessible?
Which information requires restricted access?
What would happen if the application became unavailable for several hours?
How much recent data could the business afford to lose?
Who will monitor and maintain the application?
What costs could increase as usage grows?
What evidence would tell you that the initial design needs to change?

Draw a simple diagram showing the user, application, database, external services, and backup or recovery path.

You do not need to know the final answers immediately. The exercise is to learn how to make architecture decisions deliberately rather than selecting cloud services at random.

Frequently asked questions

Is cloud architecture only for large companies?

No. Even a small website or business application has architectural decisions involving hosting, data, access, security, and recovery. The appropriate design can be very simple.

Should I always choose serverless?

No. Serverless is one option. Its suitability depends on the workload, execution requirements, pricing, platform limits, and operational needs.

Is a managed database automatically secure?

No. Managed services can reduce some infrastructure-management responsibilities, but access permissions, credentials, data exposure, configuration, application security, and recovery still need attention.

Do I need a load balancer for a small application?

Not necessarily. It may be unnecessary for a small application hosted on a platform that already manages incoming traffic. Use one when the architecture and requirements justify it.

Should I use multiple cloud providers to avoid being locked in?

Not automatically. Multi-cloud can address specific business or technical requirements, but it also increases operational complexity. First understand your portability needs, contractual constraints, data dependencies, and recovery objectives.

What is the difference between a cloud architecture and a deployment?

Architecture is the design of the components, their relationships, responsibilities, and trade-offs. Deployment is the process of putting the application and its required infrastructure into an environment where it can run.

How often should a cloud architecture be reviewed?

Review it when requirements, usage, costs, security risks, dependencies, or provider capabilities change. A periodic review is also useful even when no major change is planned. The appropriate frequency depends on the application's risk and rate of change.

Conclusion: Design for the problem you actually have

Cloud architecture is the practice of turning application requirements into a workable arrangement of computing, data, networking, security, and operational components.

The strongest starting point is not a diagram filled with impressive services. It is a clear understanding of what the application must do, what can go wrong, and what the business can afford to operate.

For a small application, that may mean a managed application platform, a suitable database, secure access, tested backups, basic monitoring, and a realistic cost estimate.

As usage and requirements grow, the design can evolve to include more advanced networking, caching, queues, redundancy, automation, and other infrastructure.

Remember the sequence:

REQUIREMENTS → ARCHITECTURE → SECURITY → RECOVERY → COST → DEPLOYMENT → MONITORING → IMPROVEMENT

That sequence turns cloud computing from a collection of services into a disciplined engineering process.

It also connects cloud infrastructure to the wider W3 NOTES curriculum: computing provides the execution foundation, networking connects the components, software supplies the application logic, cybersecurity protects the system, and operations keep the service useful over time.

The practical lesson is simple: understand the problem first, design the smallest suitable system, and add complexity only when the evidence and requirements justify it.

Pages

Saturday, October 10, 2026

CLOUD ARCHITECTURE | Turn an Application’s Requirements Into a Practical Cloud Design — Choose Compute, Data, Networking, Security, and Recovery Before You Deploy