Architecture pattern: applications and APIs

REST API architecture: gateway, hosting and database

A REST API is the front door to your business logic and data. A gateway handles access and limits, a managed platform runs your code, and a database keeps the data. Here is how the pieces fit, which service plays each part on AWS, Azure and Google Cloud, and what to decide first.

Quick answer

A REST API architecture puts an API gateway in front of your code to check sign-in, apply rate limits and hide the back end. The code runs on a managed platform or as serverless functions, stores data in a managed database and reads keys from a secrets service, with monitoring on every call.

Best forBack ends for web and mobile apps, partner integrations and internal services
Less suited whenA single page with no data or users, where static hosting is enough
Start withA gateway and one small service, with sign-in, rate limits and logging switched on
Main services on AWSAmazon Cognito, AWS Secrets Manager, Amazon API Gateway, AWS Elastic Beanstalk, Amazon RDS
Main services on AzureMicrosoft Entra External ID, Azure Key Vault, Azure API Management, Azure App Service, Azure SQL Database
Main services on Google CloudIdentity Platform, Secret Manager, API Gateway, Cloud Run, Cloud SQL

The idea in plain words

A REST API lets other software use your service over HTTP: apps ask for data, create orders or update records. A good API is predictable, secure and easy to change without breaking the people who call it.

Put an API gateway in front. It checks who is calling, limits how often, rejects bad requests and gives you one place for logging and versioning. Behind it, your code runs on a managed platform or as serverless functions and keeps data in a managed database.

Treat the API as a product: document it, version it, and decide early how you will handle errors, paging and changes.

The architecture

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

REST API back end: architecture diagramTwo rows of boxes. The numbered steps below describe the same flow in words.checks tokenskeys and passwordsJSON response1. Support: sign-in and secretsSign-inIssues and checks usertokensAmazon CognitoMicrosoft EntraExternal IDIdentity PlatformSecretsStores keys andpasswordsAWS SecretsManagerAzure Key VaultSecret Manager2. Handle an API callClientA web app, mobile appor partner systemAPI front doorChecks, limits androutes callsAmazon API GatewayAzure APIManagementAPI GatewayAPI platformRuns your API codeAWS ElasticBeanstalkAzure App ServiceCloud RunDatabaseKeeps the dataAmazon RDSAzure SQL DatabaseCloud SQLREST API back end: architecture diagramBoxes from top to bottom. The numbered steps below describe the same flow in words.checks tokenskeys and passwords1. Support: sign-in and secretsSecretsStores keys and passwordsAWS Secrets ManagerAzure Key VaultSecret ManagerSign-inIssues and checks user tokensAmazon CognitoMicrosoft Entra External IDIdentity Platform2. Handle an API callClientA web app, mobile app or partnersystemAPI front doorChecks, limits and routes callsAmazon API GatewayAzure API ManagementAPI GatewayAPI platformRuns your API codeAWS Elastic BeanstalkAzure App ServiceCloud RunDatabaseKeeps the dataAmazon RDSAzure SQL DatabaseCloud SQL↩ JSON response, back to client
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. A client sends a requestA web app, mobile app or partner system calls your API over HTTPS with a token that says who it is.
  2. The gateway checks the callThe API gateway validates the token, applies rate limits and quotas, and rejects bad requests before they reach your code.
  3. Sign-in provides the tokenA sign-in service issues the tokens and handles registration, multi-factor sign-in and refresh.
  4. Your code does the workThe API runs on a managed platform or as serverless functions, applies your business rules and reads secrets from a secrets service.
  5. Data is read and writtenThe code reads and writes a managed database, using connection limits and indexes that match your queries.
  6. A response is returnedThe API returns a clear response and status code in a consistent format, with errors that help the caller fix the request.
  7. Everything is logged and watchedEach call is logged with a request ID, and metrics and alerts show errors, speed and traffic so problems are caught early.

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.

JobAWSAzureGoogle Cloud
Customer sign-up and login
  • Amazon CognitoUser sign-up and sign-in, social login, MFA and tokens for your apps
  • Microsoft Entra External IDCustomer identity for apps; replaces Azure AD B2C for new projects
  • Identity PlatformCustomer sign-in for apps, built on Firebase Authentication
Store secrets (passwords, API keys)
  • AWS Secrets ManagerStores, rotates and retrieves secrets such as database passwords
  • Azure Key VaultSecrets, keys and certificates in one managed vault
  • Secret ManagerStores and versions API keys, passwords and certificates
Publish and secure APIs
  • Amazon API GatewayCreate, secure and monitor REST, HTTP and WebSocket APIs; pairs with Lambda
  • Azure API ManagementFull API gateway with policies, developer portal and analytics
  • API GatewaySimple managed gateway for serverless back ends
  • Apigee API Management
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
Relational (SQL) database
  • Amazon RDSManaged MySQL, PostgreSQL, MariaDB, SQL Server, Oracle and Db2
  • Amazon Aurora
  • Azure SQL DatabaseManaged SQL Server engine with a serverless option
  • Azure Database for PostgreSQL
  • Cloud SQLManaged MySQL, PostgreSQL and SQL Server
  • AlloyDB for PostgreSQL
Monitoring, metrics and alertsOptional
  • Amazon CloudWatchMetrics, alarms, dashboards and logs for AWS resources and apps
  • Azure MonitorMetrics, alerts, logs and Application Insights in one service
  • Cloud Monitoring (Google Cloud Observability)Metrics, dashboards and alerting, with Managed Service for Prometheus
Message queue (decouple parts of an app)Optional
  • Amazon SQSFully managed message queues, standard or FIFO
  • Azure Service BusEnterprise queues and topics with sessions, dead-lettering and transactions
  • Azure Queue Storage
  • Pub/SubMessaging with pull subscriptions and ordering
  • Cloud Tasks

Common variations

  • Slow work such as sending email or processing files. Accept the request, put the job on a queue and let background workers finish it, so the API answers quickly.
  • A public API for outside developers. Add a developer portal, API keys, usage plans and documentation, and version the API from the start.
  • Many small services behind one gateway. Route each path to its own service. See the microservices pattern.
  • Read-heavy traffic. Cache common responses at the gateway or CDN and add read copies of the database.

Try this in the service suggester

Always-on platform or serverless functions?

Your API code can run on a managed platform that stays on, or as serverless functions that start per request and cost nothing when idle. The functions are shown in the table.

 AWSAzureGoogle Cloud
Serverless functions
  • 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)

Managed platform (always on)

Good

  • Steady, fast responses with no start-up delay
  • Easier to run existing frameworks
  • Predictable cost at constant traffic

Watch out

  • You pay while it is idle
  • You set the scaling rules
  • Fewer ready-made event triggers

Serverless functions

Good

  • Pay only when called
  • Scales up and down automatically
  • Easy to attach events and queues

Watch out

  • Start-up delay after idle periods
  • Limits on run time and memory
  • Many small pieces and harder local testing
A common path. Choose the platform that fits your traffic: always-on for steady load or existing frameworks, functions for spiky or low traffic and event-driven work.

Keep in mind

  • Authentication and authorisation. Check who is calling and what they may do on every request. Never trust the client, and keep permissions as narrow as possible.
  • Rate limits and quotas. Limit calls per client to protect your back end and your budget, and return a clear error so callers can back off.
  • Versioning and change. Never break existing callers. Version the API and announce changes early, with a clear date for retiring old versions.
  • Input validation. Validate every field, limit sizes and return clear errors. Treat all input as untrusted.
  • Idempotency and retries. Callers retry. Make create and payment calls safe to repeat, for example with an idempotency key.
  • Observability. Log each call with a request ID, and track errors, latency and traffic per route. Set alerts on error rates.
  • Data protection. Encrypt traffic and stored data, keep personal data out of logs, and check which privacy laws (the GDPR, the CCPA, India's DPDP Act) cover what the API returns.
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
  • Azure Closed to new customers Azure AD B2C has not been sold to new customers since 1 May 2025. Microsoft Entra External ID is the replacement for new projects. 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 REST API?

A REST API lets software talk to your service over HTTP, using standard methods such as GET and POST on addresses that represent things like orders or users. It usually returns data as JSON.

Do I need an API gateway?

A gateway is worth it when you need sign-in checks, rate limits, usage plans or one entry point for several services. A tiny internal API can start without one.

Should I use REST or GraphQL?

REST is simple, cacheable and widely understood. GraphQL suits clients that need to choose exactly which fields to fetch. Many teams start with REST and add GraphQL where it helps.

How do I secure an API?

Use HTTPS, verify tokens at the gateway, give each client only the access it needs, validate input, apply rate limits and log requests.

Should I use serverless functions or containers for an API?

Functions suit uneven or low traffic and event-driven work. Containers or a managed platform suit steady traffic and existing frameworks. Both can sit behind the same gateway.

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 →