Architecture pattern: applications and APIs

Static website architecture: storage, CDN, domain and HTTPS

A static website is a set of files served exactly as they are, so it is fast, cheap and easy to secure. Here is how the pieces fit, which service plays each part on AWS, Azure and Google Cloud, and where to add small dynamic features.

Quick answer

A static website architecture stores the built HTML, CSS, JavaScript and images in cloud storage or a static hosting service, serves them through a CDN, and uses DNS and an HTTPS certificate for the domain. Forms and other small dynamic features can call serverless functions or hosted services.

The Static website pattern at a glance
Best forMarketing sites, documentation, blogs, landing pages and front ends for APIs
Less suited whenPages that must be built from a database on every request
Start withA static hosting service with a custom domain, HTTPS and a deploy from your code repository
Main services on AWSAmazon Route 53, AWS Certificate Manager, Amazon CloudFront, Amazon S3 + Amazon CloudFront
Main services on AzureAzure DNS, App Service managed certificates, Azure Front Door, Azure Static Web Apps
Main services on Google CloudCloud DNS, Certificate Manager, Cloud CDN, Firebase Hosting

The idea in plain words

A static site has no server code running when someone visits. Your pages are built ahead of time into plain files, and the cloud simply hands them out. That makes the site fast, very cheap and hard to attack.

The files sit in storage or a static hosting service. A CDN copies them to locations near visitors. DNS points your domain at the CDN, and a certificate gives you HTTPS, which most services issue and renew automatically.

Add dynamic parts only where needed: a contact form, a search box or a sign-up can call small serverless functions or third-party services.

The architecture

Boxes show the job each part does. Pick a cloud to see the service for each job.

Static website: architecture diagramTwo rows of boxes. The numbered steps below describe the same flow in words.domain namecertificate for HTTPSpages and files1. Domain name and HTTPSDomain namePoints your address atthe siteAmazon Route 53Azure DNSCloud DNSHTTPS certificateEncrypts theconnectionAWS CertificateManagerApp ServicemanagedcertificatesCertificateManager2. Serve a pageVisitorOpens your address ina browserCDNServes cached filesnearbyAmazon CloudFrontAzure Front DoorCloud CDNStatic hostingStores the built sitefilesAmazon S3 + AmazonCloudFrontAzure Static WebAppsFirebase HostingStatic website: architecture diagramBoxes from top to bottom. The numbered steps below describe the same flow in words.domain namecertificate for HTTPS1. Domain name and HTTPSDomain namePoints your address at the siteAmazon Route 53Azure DNSCloud DNSHTTPS certificateEncrypts the connectionAWS Certificate ManagerApp Service managedcertificatesCertificate Manager2. Serve a pageVisitorOpens your address in a browserCDNServes cached files nearbyAmazon CloudFrontAzure Front DoorCloud CDNStatic hostingStores the built site filesAmazon S3 + AmazonCloudFrontAzure Static Web AppsFirebase Hosting↩ pages and files, back to visitor
Arrows show the direction of the flow, and dashed lines connect the rows. Each box names the main service for that job, taken from CloudBrum's service suggester.

Step by step

  1. Build the siteA build step turns your content and templates into plain HTML, CSS, JavaScript and image files.
  2. Publish the filesA pipeline uploads the files to storage or a static hosting service each time you merge a change.
  3. Point the domainDNS records send your domain to the CDN or hosting service.
  4. Turn on HTTPSA certificate encrypts the traffic. Most services issue and renew it for you.
  5. Serve through a CDNThe CDN caches files near visitors, so pages load fast anywhere and the origin sees little traffic.
  6. Add small dynamic featuresForms, search and sign-up call serverless functions or hosted services, and email goes out through an email service.

Services side by side

The main service for each job on each cloud, with a second option where one exists. Names checked on 23 October 2026.

Services for each job in this architecture on AWS, Azure and Google Cloud
JobAWSAzureGoogle Cloud
DNS and domain names
  • Amazon Route 53DNS, health checks, routing policies and domain registration
  • Azure DNSHosts your DNS zones on Azure
  • App Service Domains
  • Cloud DNSReliable, low-latency authoritative DNS
HTTPS and TLS certificates
  • AWS Certificate ManagerFree public TLS certificates with automatic renewal for AWS services
  • App Service managed certificatesFree managed certificate for custom domains on App Service
  • Azure Key Vault certificates
  • Certificate ManagerGoogle-managed TLS certificates for load balancers
CDN (fast delivery to users worldwide)
  • Amazon CloudFrontGlobal CDN with edge locations in India and worldwide
  • Azure Front DoorGlobal CDN with load balancing and a web application firewall
  • Cloud CDNCDN for sites behind Cloud Load Balancing
  • Media CDN
Static website or front-end hosting
  • Amazon S3 + Amazon CloudFrontStatic files in S3 served worldwide through the CloudFront CDN
  • AWS Amplify Hosting
  • Azure Static Web AppsFree tier, GitHub or Azure DevOps deploys and an optional built-in API
  • Azure Blob Storage static website
  • Firebase HostingFast global hosting with a free tier and automatic HTTPS
  • Cloud Storage + Cloud CDN
Send email (transactional or bulk)Optional
  • Amazon SESLow-cost transactional and marketing email with high deliverability
  • Azure Communication Services EmailSends transactional and bulk email from your own domain
  • Partner email service (SendGrid, Mailgun)Google Cloud does not offer its own bulk email service; use a partner, available in Cloud Marketplace
Serverless functionsOptional
  • AWS LambdaRuns code on events with no servers to manage; pay per request
  • Azure FunctionsEvent-driven code with many triggers; Durable Functions for long workflows
  • Cloud Run functionsEvent-driven functions on Cloud Run (formerly Cloud Functions)

Common variations

  • Content changes often and non-developers edit it. Use a headless content system that triggers a rebuild when content changes.
  • Many pages and large images. Optimise images, use long cache times and let the CDN compress files.
  • A form must send email. Send the form to a serverless function that checks it and calls an email service.
  • Pages for several countries or languages. Use language folders and correct language tags, and use the CDN's location-based routing only if you need it.

Try this in the service suggester

Static hosting or a web application platform?

If every visitor sees the same files, static hosting is simpler and cheaper. If pages are built from a database on each request, you need a web application platform, shown in the table.

Services for this choice on each cloud
 AWSAzureGoogle Cloud
Web app or API hosting (managed platform)
  • AWS Elastic BeanstalkUpload code (Java, .NET, Node.js, PHP, Python, Ruby, Go or Docker); AWS sets up servers, scaling and load balancing
  • Amazon ECS Express Mode
  • Azure App ServiceManaged hosting for .NET, Java, Node.js, Python and PHP, with autoscale and deployment slots
  • Azure Container Apps
  • Cloud RunDeploy a container or source code; scales to zero and bills per request
  • App Engine

Static hosting

Good

  • Cheapest and fastest option
  • Almost nothing to patch or secure
  • Handles any traffic without effort

Watch out

  • No server code on page requests
  • Dynamic features need extra services
  • A rebuild is needed to change content

Web application platform

Good

  • Pages can be built for each visitor
  • Full server-side logic and database access
  • Content changes appear immediately

Watch out

  • More to run, secure and pay for
  • Slower than cached files unless tuned
  • Needs scaling and patch planning
A common path. Use static hosting whenever pages can be built ahead of time, and add small functions for dynamic needs.

Keep in mind

  • Cache and updates. Long cache times make sites fast but can show old files. Use file names that change when content changes, or clear the CDN cache on each release.
  • Security headers. Add standard security headers at the CDN, and never put secrets or private data in the files.
  • Forms and spam. Protect forms with a spam check and rate limits, and validate on the server side.
  • Redirects and search visibility. Keep old addresses working with redirects, publish a sitemap, and give every page a title and description.
  • Cost. Cost is mostly data transfer. Compress files, cache well and set a budget alert.
  • Domain and certificate renewals. An expired domain or certificate takes the site down. Turn on automatic renewal and add reminders.
  • Privacy. Cookie banners, analytics and embedded content bring privacy duties. Rules such as the EU's ePrivacy and GDPR requirements or India's DPDP Act may require consent before non-essential cookies are set.
A starting point, not a design review. This is a general pattern. Your documents, users, rules and budget decide the real design. Confirm features, limits, pricing and regions on each provider's own pages. CloudBrum is independent of AWS, Microsoft and Google.

Words used on this page

Services in this pattern that have changed

Cloud providers rename and retire services often. These affect the parts above. Checked on 23 October 2026.

  • AWS Closed to new customers AWS App Runner stopped accepting new customers on 30 April 2026. AWS recommends Amazon ECS Express Mode for new container web apps. Details
  • AWS Retiring Amazon Pinpoint ends support on 30 October 2026. SMS, voice and push continue as AWS End User Messaging; for email AWS recommends Amazon SES. Details
  • Google Cloud Renamed Cloud Functions is now Cloud Run functions. Details

Sources and further reading

Check details such as features, limits, prices and regions in the providers' own documentation.

Announcements about the changed services above

Frequently asked questions

What is a static website?

A static website is made of pre-built files, such as HTML, CSS, JavaScript and images, that a server hands out unchanged. No code runs on the server for each visit.

How do I host a static website on the cloud?

Upload the built files to cloud storage or a static hosting service, put a CDN in front, point your domain at it with DNS and turn on HTTPS. Each cloud has services for all four steps.

Can a static site have forms or login?

Yes. The page calls serverless functions or hosted services for forms, search and sign-in, so the site stays static while the dynamic parts run elsewhere.

Is static hosting cheaper than a server?

Usually yes, because you pay mainly for storage and data transfer, and nothing runs between visits. Very high traffic still costs money, so cache well.

Do I need a CDN for a small site?

Static hosting services often include one. A CDN makes pages load faster for visitors far from the server and reduces load, so it is worth using even on small sites.

Want this reviewed for your case?

CloudBrum architects can adapt this pattern to your documents, users, rules and budget, and estimate the cost. Nothing is sent until you choose.

Building something else?

Describe it in plain words and get matching services on all three clouds.

Service suggester → Cloud consulting →