Designing Web APIs on AWS in 2026A Practical Architecture Guide to Auth, Performance, Security, and Cost

This article is based on AWS documentation, the AWS Architecture Blog, the Amazon Builders' Library, OWASP, and official cloud-provider material available on July 28, 2026. Prices, quotas, and regional availability change; verify the current values in the intended production Region before making a final decision.

1. The 2026 default: keep the synchronous lane narrow and the asynchronous lane wide

A Web API is not complete merely because an HTTP endpoint sits in front of a database. The architecture changes with the caller, the duration of one operation, the number of records touched, whether a retry is safe, and the boundary between the new API and the existing system.

Even so, there is a strong default from which to begin a business application on AWS in 2026:

1. Put CloudFront and AWS WAF, or an API Gateway REST API / Application Load Balancer directly associated with WAF, at the public edge.
2. Do not invent another password database. Use the organization's IdP, Amazon Cognito, Microsoft Entra ID, Okta, or another OIDC / OAuth 2.0 provider.
3. Have the API validate an access token. Use scopes for broad permission and application policy or Amazon Verified Permissions for resource-level decisions.
4. Serve ordinary, short requests synchronously through API Gateway and Lambda.
5. Send work that can exceed 30 seconds, needs controlled retries, or arrives in bursts to SQS and Lambda / ECS, Step Functions, or Lambda Durable Functions. Return 202 Accepted and a job ID.
6. If Lambda talks to an existing relational database, use RDS Proxy to bound database connections instead of allowing every invocation to open one freely.
7. Add OpenAPI, structured logs, OpenTelemetry, SLOs, and Infrastructure as Code at the start. The years spent diagnosing and changing the service usually cost more than its first implementation.

The service names are not the point. The point is to control identity and flow at the edge, admit only short work to the synchronous path, absorb heavy work in a queue, and defend the database as the final scarce resource.

Change that default when the workload demands it:

There is no need to make “serverless or containers” an article of faith. Preserve the API contract and business boundary, measure real traffic, and the execution layer can be replaced later.

2. There is no single kind of API—start with the caller and trust boundary

The same /orders/{id} endpoint needs a different entrance when called by an employee screen, a partner's server, or a consumer mobile app.

Three misconceptions should be removed immediately.

First, an API key is not a login. AWS explicitly says not to use API Gateway API keys for authentication or authorization. They are useful for identifying and metering a subscriber and associating it with a Usage Plan, but a key embedded in a browser or mobile app is only a recoverable shared string.^[1]

Second, authenticated does not mean authorized. A valid token does not prove that its subject may read the customer, document, or department identified in the URL. Broken Object Level Authorization is first in the OWASP API Security Top 10 2023. Nearly every endpoint that accepts an object identifier must check the caller's right to that particular object.^[2]

Third, users are not requests per second. Ten thousand employees do not necessarily send ten thousand requests each second. Conversely, one chat action that fans out to eight internal APIs turns 100 front-end requests per second into 800 internal requests per second.

The first architecture page should therefore describe requirements, not service icons:

• Is the caller a person, a partner company, or an internal service?
• Is the endpoint public or private?
• Does it read, update, transfer a file, or launch long-running work?
• What are average and peak RPS and acceptable p95 / p99 latency?
• How many database queries and downstream calls does one request produce?
• What are the tenant boundary, data classification, and audit obligations?
• Can a request be retried, and where is an idempotency key required?
• What recovery objective and Multi-AZ or multi-Region behavior are actually required?

Once those answers exist, API Gateway versus ALB and Lambda versus Fargate usually stop being mysterious choices.

3. A reference sequence from login to the database response

Consider an employee Web application that reads business data after login through a corporate IdP. For higher-risk data, a Backend for Frontend (BFF) is easier to control than storing a long-lived token in the browser. The browser holds only a session cookie with Secure, HttpOnly, and a deliberate SameSite policy; the server protects the OAuth tokens.

The sequence is browser → IdP → BFF session → WAF/API edge → JWT validation → authorization → compute → connection pool → database. Authentication, authorization, synchronous execution, and data access remain separate control boundaries.

The API Gateway HTTP API JWT authorizer checks a signature against the OIDC issuer's public keys and validates iss, aud / client_id, exp, nbf, iat, and required scopes. It can cache a public key for two hours. Because a machine cannot universally distinguish an ID token from an access token, AWS recommends requiring authorization scopes and configuring the intended issuer and audience for the API.^[3]

Using Cognito therefore does not mean asking Cognito to approve every ordinary API request. Cognito quotas matter for authentication and token refresh. API Gateway can validate the signed JWT locally at the edge. Ten thousand users making API calls and ten thousand users logging in again every second are different capacity problems.^[4]

A BFF is not mandatory. A pure SPA can use Authorization Code + PKCE, short access tokens kept in memory, and refresh-token rotation; avoid designing around a long-lived token in localStorage. With an ALB front end, the load balancer itself can authenticate with OIDC or Cognito, manage the session cookie, and send signed user claims to the backend. The backend must still verify the claim signature and the expected ALB signer.^[5]

4. Authentication and authorization: decide where each fact becomes trusted

Authentication establishes who the caller is. Authorization decides whether that caller may perform this operation on this resource. Combining both into one growing middleware function usually creates exceptions and fragile if statements.

Choosing authentication

• For employees already managed in Entra ID, Okta, Google Workspace, or another corporate IdP, federate with the existing identity. Do not create another password.
• For a new B2C population, multiple social IdPs, or an AWS-centered user pool, Cognito is a reasonable candidate.
• For a cookie-based Web application behind an ALB, managed ALB OIDC authentication is unusually practical.
• For B2B machine-to-machine access, use OAuth 2.0 client credentials and consider mTLS. Inside AWS, begin with an IAM role and SigV4.
• For a private REST API, combine a VPC endpoint policy and an API resource policy to restrict organization, VPC endpoint, and principal.^[6]

Three layers of authorization

Straightforward RBAC often needs nothing more than a group or role claim plus application policy. When the decision combines department, owner, classification, contract plan, time, and action, Amazon Verified Permissions can move policy into Cedar rather than scattering it through code. Verified Permissions accepts Cognito or OIDC identity sources. Its convenient automatic API Gateway integration is a Lambda authorizer for REST APIs; with an HTTP API, calling the authorization service from the application is another valid design.^[7]

The important rules are stable:

• Derive tenant and user identity from validated claims, not a request body.
• For GET /documents/123, check both that document 123 exists and that this principal can read it, inside a safe consistency boundary.
• A role embedded in a token can be stale until expiry. Use shorter token lifetime, step-up authentication, or a current policy lookup for high-risk actions.
• Deny by default. Separate administrative routes, permissions, and audit trails from ordinary operations.
• Keep secrets out of source code and plaintext environment files. Store and rotate them in Secrets Manager; where possible, use an execution role or RDS IAM authentication so no static secret exists at all.^[8]

WAF is not a universal remedy. As of July 2026, API Gateway HTTP APIs still do not provide direct AWS WAF association, private endpoints, resource policies, API keys, Usage Plans, built-in caching, or request validation. Those are legitimate reasons to choose a REST API. An HTTP API can sit behind CloudFront and WAF, but the origin must be protected against direct bypass; otherwise the architecture only appears to be guarded. AWS's own feature comparison presents REST APIs as the feature-rich choice and HTTP APIs as the lower-cost, minimal choice.^[9]

Security depth should follow exposure and impact:

Adding every control to every endpoint is not the goal. Making the trust decision and residual risk explicit is.

5. Where Lambda stops being the answer

“API Gateway plus Lambda” is an excellent initial choice, but it becomes awkward when treated as universal. By 2026, there are useful points between classic Lambda and a conventional container service.

Standard Lambda handles short, bursty work; Lambda Managed Instances target predictable high throughput; ECS/Fargate provides resident pools, long-lived connections, and container freedom. A stable API and data boundary lets the team move among them.

A standard Lambda invocation can run for 900 seconds—15 minutes. An HTTP API integration, however, is capped at 30 seconds and cannot be raised. Setting a Lambda timeout to 15 minutes does not make an HTTP API client wait for 15 minutes.^[10][11]

API Gateway REST APIs now support response streaming from proxy integrations for as long as 15 minutes. That helps generated-AI responses, server-sent events, and progress feeds, and it can exceed the 10 MB buffered-response limit. But it is response streaming, not request streaming. A disconnected client may not terminate the Lambda execution, so cost and side-effect cancellation remain application concerns.^[12]

For most long business processes, an asynchronous contract is safer than “a synchronous endpoint that is allowed to wait”:

POST /reports
  -> 202 Accepted
  -> Location: /jobs/01J...

GET /jobs/01J...
  -> queued | running | succeeded | failed

Now SQS absorbs the burst and worker concurrency can be set to the database's safe capacity. Step Functions Standard can run for up to one year, while Express workflows are capped at five minutes. Lambda Durable Functions, introduced at the end of 2025, provide checkpoints, waits, callbacks, and retries in ordinary code and can remain durable for up to one year. The synchronous invocation and each standard Lambda invocation still retain the 15-minute boundary. Step Functions are particularly good when a workflow visibly crosses AWS services; Durable Functions are attractive when the control flow remains Lambda-centered.^[13][14]

Lambda Managed Instances are another new midpoint. They preserve the Lambda programming model while running on EC2 instances in the customer's account, and one execution environment can process multiple invocations concurrently. Predictable heavy load, resident JVMs, and EC2 Savings Plans can make them attractive. Unlike standard Lambda, the default highly available design normally maintains at least three instances and does not scale to zero; mutable shared state and non-thread-safe code become real hazards.^[15]

Ask these questions before choosing compute:

• Can the p99 target tolerate any cold start?
• Is one request reliably under 30 seconds, does it stream, or can it become a job?
• Does traffic approach zero, or remain steady all day?
• Are custom binaries, sidecars, unusual runtimes, or very large images required?
• Does the process need a resident database pool?
• Can the team safely operate container deployments and autoscaling?

6. When 10,000 people arrive: model RPS, concurrency, and the downstream limit

“Ten thousand employees will use the chat” sounds like 10,000 RPS, but the design model should be decomposed:

external RPS = users × concurrently active fraction × actions per user per second
internal RPS = external RPS × API fan-out per action
required concurrency ≈ RPS × average processing seconds

If 10% of 10,000 employees are active and each acts once every 20 seconds, the external rate is 50 RPS. If one action calls search, authorization, master data, and history services eight times, the internal rate is 400 RPS. A 300 ms Lambda at 400 RPS needs roughly 120 concurrent executions before headroom.

Autoscaling is not backpressure. The queue absorbs arrival rate; bounded worker concurrency protects the database; retry and dead-letter paths isolate failure. Keep only fast reads and validation in the synchronous lane.

API Gateway's default account throttle in most Regions is 10,000 RPS with a 5,000-request token-bucket burst capacity. Some newer Regions default to 2,500 / 1,250. Those are adjustable account-level limits, not a guarantee that the database can accept the same rate.^[16]

Lambda itself can create up to 1,000 execution environments for a function every 10 seconds, corresponding to up to 10,000 additional requests per second for functions of sufficient duration. Account concurrency, reserved concurrency, provisioned concurrency, regional quotas, VPC behavior, and downstream capacity still apply.^[17]

The deliberate controls are therefore:

• Reserve or cap concurrency per function so a noncritical endpoint cannot consume the account or crush the database.
• Put SQS before write-heavy and expensive work; make maximum worker concurrency match measured DB and dependency capacity.
• Return 429 with Retry-After when the system cannot accept more synchronous work.
• Use a client-supplied or server-issued idempotency key for retryable writes.
• Apply exponential backoff with jitter at one chosen layer; avoid retrying at every hop.
• Limit fan-out and parallelism inside an agent. A tool loop is a workload generator, not a special exemption from API capacity planning.
• Watch queue age and saturation, not only average CPU.

The Amazon Builders' Library explains why timeouts, bounded retries, exponential backoff, and jitter must be designed together. A retry is selfish: it adds work exactly when a dependency is already failing. Multiple retrying layers can multiply load dramatically.^[18]

For Lambda, initialize SDK clients outside the handler, use keep-alive where the runtime permits it, make the handler idempotent, and use reserved concurrency as both isolation and a downstream fuse. These are explicit Lambda best practices, not micro-optimizations.^[19]

Chat and agent experiences also change the return channel:

• For a token or progress stream, use REST API response streaming or ALB + ECS with SSE.
• For bidirectional messages, API Gateway WebSocket APIs work, but each integration is capped at 29 seconds, idle connections at 10 minutes, and connection duration at two hours. A long job must remain separate from the connection lifecycle.^[20]
• For large pub/sub fan-out, AppSync Events provides managed WebSocket event APIs with IAM, Cognito, OIDC, or Lambda authorization and is designed for very large subscriber counts.^[21]

The LLM is not the API architecture. An agent that queries business data should call narrow, permission-aware tools such as get_order_summary rather than receive a general SQL escape hatch. Every tool call carries the end-user subject, tenant, trace, deadline, and purpose, and every write requires authorization, idempotency, and a clear confirmation boundary.

7. Protect the data layer, especially when the database already exists

When the source of truth is an existing RDS or Aurora database, do not move it into DynamoDB merely to make the API look serverless. Put a facade or anti-corruption layer in front of the legacy schema, begin with read-only use cases, and create a dedicated least-privilege database role.

The dangerous combination is “Lambda scales instantly, therefore every invocation opens a database connection.” A short burst can exhaust the database's connection or memory budget long before Lambda or API Gateway reaches its advertised quota.

RDS Proxy keeps a pool of established connections and multiplexes many application connections over them. It can queue or throttle when the pool is constrained and supports IAM authentication and Secrets Manager. This is valuable for bursty Lambda access and for failover behavior.^[22]

It is not infinite capacity:

• Keep transactions short. Test session variables, temporary tables, prepared statements, and other behavior that can pin a client to one database connection.
• Do not drive MaxConnectionsPercent to 100%; preserve the headroom AWS recommends for internal changes.
• Configure query/statement timeouts and the proxy connection-borrow timeout.
• Route read-only APIs to a read replica and a read-only database user where appropriate.
• Eliminate N+1 queries, scans, and huge offset pagination before the load test.
• Reuse SDK clients and reusable connections outside a Lambda handler, but never leave per-user data in the execution environment.

Choose storage from the access and consistency model, not from a “serverless” label:

Aurora Serverless v2 can be configured in 0.5 ACU increments up to 256 ACUs and supported engine versions can pause at 0 ACUs. Resume from zero is not appropriate for a strict latency SLO, and AWS notes that scaling speed depends on current capacity. Set the production minimum ACU from measurement, not optimism.^[23]

When a transaction must also publish an event, a database commit followed independently by an SQS publish is a dual write that can split during failure. With RDS, write the business row and an outbox row in the same transaction; a separate publisher sends the outbox to SQS. DynamoDB Streams can serve the equivalent role. Standard SQS delivery is at least once, so the consumer must be idempotent. AWS Prescriptive Guidance documents this transactional outbox failure boundary.^[24]

8. Cost and maintainability: measure the whole waiting system

Serverless is not automatically cheap. Its superpower is that the service need not pay for unused time. With stable 24/7 work, resident compute and commitments can cross the cost curve.

Using public US East (N. Virginia) prices and excluding the free tier, transfer, WAF, CloudWatch, NAT, RDS, and RDS Proxy gives a deliberately simple comparison. HTTP API uses $1 per million requests for the first 300 million, the REST API example uses $3.50 per million, Lambda requests cost $0.20 per million, and x86 compute is $0.0000166667 per GB-second.^[25][26]

The table shows that duration and memory can matter more than the Lambda request charge, while the REST-versus-HTTP price gap becomes material at volume. In a real bill, the database, WAF, log ingestion, transfer, NAT Gateway, proxy, or cache can exceed both.

The 2026 Lambda Managed Instances pricing example describes a high-throughput API with 100 million requests per month, 200 ms average duration, m7g.xlarge instances, roughly 2,000 instance-hours, and a three-year Compute Savings Plan: $91.40 for EC2, about $13.71 for the 15% management fee, and $20 for requests. That is an example with a particular traffic shape and commitment, not a universal break-even point. It does show that “Lambda's development model plus EC2 economics” is now a serious option for steady traffic.^[26]

Frequently missed costs include:

• NAT Gateway traffic from a private-subnet Lambda to public SaaS or public service endpoints;
• CloudWatch Logs ingest when full request and response bodies remain at debug level;
• RDS Proxy capacity charges and PrivateLink for additional proxy endpoints;
• a low-hit-rate API Gateway or ElastiCache cache;
• retries that duplicate Lambda, external API, and database work;
• operational labor for premature multi-Region, EKS, or a service mesh.

Maintainability is more than a small resource count:

• Treat OpenAPI as a source of truth; check schemas and breaking changes in CI.
• Separate domain logic from the handler so Lambda and ECS can invoke the same use case.
• Standardize Infrastructure as Code on CDK, SAM, Terraform, or OpenTofu; do not retain console-only resources.
• Emit structured JSON fields such as trace_id, request_id, anonymized subject, tenant_id, route, latency_ms, and result.
• Monitor p95 / p99, errors, throttles, queue age, and database saturation rather than averages alone.
• Define SLOs—such as 99.9% availability and a 300 ms read-API p95—and use an error budget to guide investment.

AWS put the X-Ray SDK and daemon into maintenance mode on February 25, 2026. New instrumentation should begin with OpenTelemetry / AWS Distro for OpenTelemetry and export to CloudWatch Application Signals or X-Ray as needed. OpenTelemetry also travels more easily when compute moves to ECS or another cloud.^[27]

9. Then and now: more microservices do not mean more progress

Ten years ago, a typical design was a large Web application on EC2, a shared RDS database, home-grown authentication, cron, and a load balancer. It was conceptually simple, but the team owned patching, capacity, deployments, and a large failure domain.

About five years ago, API Gateway, Lambda, Step Functions, and finely divided microservices were strongly promoted. Their benefits are real: low initial capacity, independent scaling, and event-driven integration. The same period also produced distributed monoliths—one request divided among too many tiny functions and network transitions that always had to execute in the same order.

The current practice is not to maximize service count:

• A new system maintained by one team can start as a modular monolith with firm module boundaries.
• Extract a service when deployment, scaling, data ownership, or failure isolation truly needs independence.
• Keep synchronous call chains short and choose asynchronous boundaries deliberately.
• Keep work that exchanges large data at high frequency inside one process when the network and serialization tax dominates.
• Migrate an existing system by route rather than by a big-bang rewrite.

A facade and anti-corruption layer protect the boundary instead of letting every new API share the legacy schema. Routes migrate to new services gradually while old and new remain operational.

The strangler fig pattern in AWS Prescriptive Guidance places a proxy in front of the legacy monolith and new services, while an anti-corruption layer absorbs interface differences. It avoids the risk of a full rewrite and lets the team extract the functions with the highest change or scale pressure first.^[28]

The Prime Video audio/video quality-monitoring service is a useful public counterexample. Its initial distributed serverless design stored fine-grained intermediate media data in S3 and orchestrated many processing steps through Step Functions. It reached hard scaling limits and high cost at roughly 5% of the intended load. The team moved the work into a single process on EC2 / ECS, passed intermediate data in memory, and reported a 90% cost reduction. This did not mean that Prime Video abandoned microservices or that Lambda is inherently slow. It meant that work that always executes together and exchanges large intermediate data had been decomposed across a network too aggressively.^[29]

Conversely, a business API with uncertain demand, short independent operations, and meaningful scale-to-zero remains a strong serverless fit. Fashion is not the test. Measured latency, cost, and failure behavior should make it possible to redraw the boundary.

10. A selection matrix, the first 90 days, and multi-cloud portability

The practical selection table is compact:

A first 90-day sequence that limits rework:

1. Weeks 1–2: define callers, trust boundaries, OpenAPI, SLOs, data ownership, and the peak model.
2. Weeks 3–4: implement one vertical slice from OIDC login through object-level authorization and create the threat model.
3. Weeks 5–6: implement representative read and write APIs, RDS Proxy, idempotency, structured logs, and tracing.
4. Weeks 7–8: test normal and burst load, database delay, downstream timeouts, duplicates, and poison messages.
5. Weeks 9–10: compare measured Lambda, ECS, and Managed Instances cost, p95 / p99, and operational burden.
6. Weeks 11–12: complete canary, rollback, runbooks, dashboards, quota increases, and backup/restore testing.

Supporting “10,000 people” does not mean trusting autoscaling after production launch. Drive at least twice the planned peak and observe where API Gateway throttling, Lambda concurrency, queue age, RDS Proxy borrow latency, database CPU/connections/locks, and downstream timeouts bend. A system whose limit is unknown has not been capacity-designed, even if every component says “auto scaling.”

Port API contracts, identity standards, business logic, telemetry, and data interfaces—not identical resource names. Implement cloud-specific edge, authorization, networking, and databases in provider modules.

The same principles map to other clouds:

Terraform or OpenTofu does not make an application multi-cloud automatically. Portability comes from design:

• Fix API contracts in OpenAPI and event contracts in AsyncAPI or an equivalent schema.
• Use OIDC / OAuth 2.0 for login and short-lived credentials for service identities.
• Separate business logic from cloud SDKs; switch SQS, Service Bus, and Pub/Sub through adapters.
• Package the parts suited to containers as OCI images and keep provider-specific function handlers thin.
• Instrument with OpenTelemetry.
• Do not force one universal IaC module. Use provider modules such as aws/, azure/, gcp/, and oci/ behind a shared interface.
• Treat migration, consistency, KMS, networking, and IAM as genuinely cloud-specific design work.

Microsoft's official enterprise-integration reference combines Entra ID, API Management, Logic Apps, and Service Bus. Google Cloud provides API Gateway / Cloud Run and service-to-service OIDC ID tokens. OCI API Gateway supplies authentication and rate limiting in front of Functions, Kubernetes, and HTTP backends. The logical model transfers even though the product details do not.^[30][31][32]

The final recommendation is deliberately simple: start small, but do not defer edge identity, flow control, the asynchronous boundary, database protection, or observability. Selecting API Gateway and Lambda is not what makes an architecture modern. An architecture is modern when changing requirements let the team move the boundary from Lambda to Managed Instances, Fargate, or another cloud without tearing apart the API and business model.

References