いまAWSでWeb APIをつくるなら――2026年版、認証・性能・コストを外さない実戦アーキテクチャ

この記事は、2026年7月28日時点で確認できるAWS公式ドキュメント、AWS Architecture Blog、AWS Builders' Library、OWASP、各クラウドの公式資料を基にしています。料金・クォータ・リージョン対応は変更されるため、本番採用前に対象リージョンの最新値を再確認してください。

1. 結論――2026年の「標準形」は、同期の細い道と非同期の太い道を分ける

APIは、データベースの前にHTTPの入口を置けば完成するものではない。誰が呼ぶのか、1回の処理に何秒かかるのか、何件のデータを触るのか、失敗時に再実行してよいのか、既存システムとどこまで責任を分けるのか。その答えによって構成は変わる。

それでも、2026年のAWSで業務系Web APIを新しく作るなら、出発点としてかなり強い「標準形」はある。

1. ブラウザの前段は CloudFront + AWS WAF、またはWAFを直接関連付けられる API Gateway REST API / Application Load Balancer にする。
2. ログインは独自実装せず、既存の社内IdP、Amazon Cognito、Microsoft Entra ID、Oktaなどの OIDC / OAuth 2.0 を使う。
3. APIは アクセストークン を検証し、粗い権限はscope、細かい権限はアプリケーションまたはAmazon Verified Permissionsで判定する。
4. 通常の短い要求は API Gateway + Lambda で同期応答する。
5. 30秒を超え得る仕事、再試行が必要な仕事、瞬間的な大量処理は SQS + Lambda / ECS、Step Functions、Lambda Durable Functions へ逃がし、202 Accepted とジョブIDを返す。
6. 既存のリレーショナルDBへ接続するなら RDS Proxy で接続数を制御し、APIごとにDBへ無制限接続させない。
7. OpenAPI、構造化ログ、OpenTelemetry、SLO、Infrastructure as Codeを最初から入れ、「作る」より長い「直す・調べる・引き継ぐ」期間を安くする。

この構成の本質は、サービス名ではない。入口で身元と流量を制御し、短い仕事だけを同期で通し、重い仕事はキューで受け止め、データベースを最後の防波堤で守ることにある。

反対に、次の条件なら最初から構成を変えた方がよい。

「サーバレスかコンテナか」を宗教のように決める必要はない。API契約とビジネスロジックの境界を保てば、入口や実行基盤は負荷実測後に交換できる。

2. APIは一種類ではない――利用者と信頼境界から設計を始める

同じ /orders/{id} でも、社内画面から呼ぶ場合、取引先のシステムから呼ぶ場合、一般消費者のアプリから呼ぶ場合では、必要な入口が違う。

ここで最初に捨てたい誤解が三つある。

第一に、APIキーはログインの代わりではない。AWS自身も、API GatewayのAPIキーを認証・認可に使わないよう明記している。APIキーは利用者の識別、計量、Usage Planとの紐付けには便利だが、ブラウザやモバイルアプリに埋めれば回収できる共有文字列にすぎない。^[1]

第二に、ログイン済みだから認可済み、ではない。トークンが正しくても、その利用者が指定された顧客ID、文書ID、部署データへアクセスできるとは限らない。OWASP API Security Top 10 2023の先頭はBroken Object Level Authorizationであり、IDを受け取るほぼすべてのAPIで、対象オブジェクトに対する権限確認が必要になる。^[2]

第三に、利用者数はRPSではない。社員が1万人いても、全員が毎秒1回送るとは限らない。一方で、1回のチャット操作が内部APIを8回呼ぶなら、画面上の100RPSが内部では800RPSになる。人数より、操作頻度、fan-out、処理時間、ピーク係数を測る必要がある。

API設計の最初の1枚には、サービス名ではなく次を書いた方がよい。

• 人間、外部企業、社内サービスのどれが呼ぶのか
• public / privateのどちらか
• 読み取り、更新、ファイル転送、長時間処理のどれか
• 平均RPS、ピークRPS、許容p95 / p99
• 1要求あたりのDBクエリ数と外部呼び出し数
• tenant境界、データ分類、監査要件
• 再試行可能か、冪等性が必要か
• 目標復旧時間と、マルチAZ / マルチリージョンの必要性

これが決まれば、API GatewayかALBか、LambdaかFargateかはかなり自然に決まる。

3. 推奨リファレンス――ログインからDB応答までを一本のシーケンスで見る

社内IdPでログインしたWebアプリから、業務データを安全に取得する例を考える。高い安全性が必要なら、ブラウザに長寿命トークンを保持させるより Backend for Frontend（BFF） を置き、ブラウザは Secure、HttpOnly、適切な SameSite 属性を持つセッションCookieだけを扱う方が制御しやすい。

図の流れは、ブラウザ→IdP→BFFセッション→WAF/API入口→JWT検証→認可判定→実行基盤→接続プール→DB。重要なのは、認証と認可、同期処理とデータ接続を別の境界として扱うことである。

API Gateway HTTP APIのJWT authorizerは、OIDC issuerの公開鍵を使って署名を検証し、iss、aud / client_id、exp、nbf、iat、scopeを確認する。公開鍵は最大2時間キャッシュされる。AWSは、ID tokenとaccess tokenを機械的に見分ける標準手段がないため、APIではscopeを要求し、access token向けのissuer / audienceを設定することを勧めている。^[3]

つまり、Cognitoを使ったからといってAPIリクエストごとにCognitoへログイン問い合わせを投げるわけではない。ログインとtoken refreshにはCognitoのquotaが関係するが、通常のAPI呼び出しはAPI GatewayがJWT署名を検証できる。1万人がAPIを使うことと、毎秒1万人が再ログインすることは別問題である。^[4]

BFFを置かないSPAも成立する。その場合はAuthorization Code + PKCE、短いaccess token、メモリ保持、refresh token rotationを基本にし、localStorage へ長寿命tokenを置く設計は避けたい。ALBを入口にするなら、ALB自身がOIDCまたはCognito認証を行い、セッションCookieを管理して、署名済みのユーザーclaimsをバックエンドへ渡せる。ただしバックエンドは、その署名と想定ALBのsignerを検証しなければならない。^[5]

4. 認証と認可――Cognitoを使うかより、「どこで何を信じるか」が重要

認証は「誰か」を確かめ、認可は「その人が、この対象に、この操作をしてよいか」を決める。ここを一つのmiddlewareへ押し込むと、後から例外とif文が増える。

認証の選び方

• 既にEntra ID、Okta、Google Workspaceなどがある社員向けシステムは、原則として既存IdPを使う。新しいIDとパスワードを増やさない。
• 新規B2C、複数のソーシャルIdP、AWS内で完結するユーザープールが必要ならCognitoが候補になる。
• ALB配下のWebアプリで、cookie sessionまでマネージドにしたいならALB OIDCは非常に実用的である。
• B2Bのシステム間通信は、OAuth 2.0 client credentialsにmTLSを重ねる。AWS内だけならIAMロールとSigV4を第一候補にする。
• private REST APIではVPC endpoint policyとAPI resource policyを重ね、組織、VPC endpoint、principalを絞れる。^[6]

認可の三段階

単純なRBACなら、tokenのgroupやroleとアプリ側のpolicyで十分である。部署、データ分類、所有者、契約プラン、時間帯などを組み合わせるなら、Amazon Verified PermissionsのCedar policyで認可をコードから分離する価値が出る。Verified PermissionsはCognitoまたはOIDCをidentity sourceにできる。なお、API Gatewayとの自動統合はREST API向けLambda authorizerとして提供されるため、HTTP APIで使う場合はアプリ側から認可APIを呼ぶ構成も検討する。^[7]

認可では、次の原則を守りたい。

• tenant IDやuser IDはrequest bodyではなく、検証済みtokenのclaimから決める。
• GET /documents/123 では「document 123が存在する」だけでなく「このprincipalが123を読める」を同じtransaction境界で確認する。
• tokenのroleは失効まで古い可能性がある。高リスク操作は短いtoken TTL、step-up、最新policy照会を使う。
• deny by defaultにし、管理APIは通常APIと経路・権限・監査を分ける。
• secretsはコードや平文環境ファイルへ置かず、Secrets Managerで保管・rotationする。可能ならRDS IAM authenticationや実行ロールで静的secret自体を減らす。^[8]

WAFも万能ではない。API Gateway HTTP APIは、2026年7月時点でもAWS WAFの直接関連付け、private endpoint、resource policy、API keys、Usage Plans、組み込みcacheを持たない。これらが必要ならREST APIを選ぶ理由になる。CloudFront + WAFの背後へHTTP APIを置くことはできるが、CloudFrontを迂回してoriginへ到達できない構成かを明示的に検証しなければ、「WAFを置いたつもり」になる。AWS公式の機能比較は、RESTを多機能、HTTP APIを低価格で最小機能の選択肢として整理している。^[9]

5. Lambdaだけでよいのか――HTTP API、REST API、Managed Instances、Fargateの境界

「API Gateway + Lambda」は優秀な初期値だが、何にでも当てはめると不自然になる。2026年は選択肢が増え、単純な「Lambdaかコンテナか」の二択でもなくなった。

左は短くバーストする標準Lambda、中央は予測可能な高スループット向けLambda Managed Instances、右は長時間接続やコンテナ自由度を持つECS/Fargate。入口とデータ境界を保てば段階的に選び直せる。

標準Lambdaの1回の実行は最大900秒、つまり15分である。しかし、HTTP APIのintegration timeoutは最大30秒で増やせない。Lambdaを15分に設定しても、HTTP APIの利用者が15分待てるようになるわけではない。^[10][11]

2026年には、API Gateway REST APIがproxy integrationのresponse streamingをサポートし、最大15分のstreamingを行える。生成AIの応答、SSE、進捗通知には有力で、10MBのbuffered response制限も超えられる。ただしstreamが切断されてもLambda実行が継続し得るため、課金と副作用を止める仕組みは別に必要である。response streamingはREST APIのみで、request streamingではない。^[12]

長い業務処理を「15分まで待てる同期API」にするより、多くの場合は次の方が堅い。

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

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

この形なら、SQSでバーストを吸収し、worker concurrencyをDBの安全量へ合わせられる。Step Functions Standardは最大1年、Expressは最大5分である。2025年末に登場したLambda Durable Functionsも、checkpoint、wait、callback、retryをコード内で扱い、全体を最大1年継続できる。ただし同期invokeは15分までで、1回の標準Lambda invokeの上限も15分のままである。Step FunctionsはAWS serviceをまたぐworkflowの見える化、Durable FunctionsはLambda中心で通常言語による制御に向く。^[13][14]

もう一つの新しい中間点がLambda Managed Instancesである。Lambdaのプログラミングモデルを保ちながら、利用者アカウント内のEC2 instanceで動き、1 execution environmentが複数invokeを同時処理する。予測可能な高負荷、常駐JVM、EC2 Savings Plansが効く処理には魅力的だが、標準Lambdaと違って最低3 instanceでのAZ分散が基本になり、thread safetyとrequest間の状態分離が必要になる。^[15]

したがって、初期選定は次の質問で決めるとよい。

• p99 latencyでcold startを1回でも許せるか
• 1要求は30秒以内か、streamingか、job化できるか
• trafficはゼロまで下がるか、24時間安定しているか
• custom binary、sidecar、特殊runtime、10GB超imageが必要か
• DB connection poolを常駐させたいか
• チームはcontainer運用とautoscalingを安全に維持できるか

6. 1万人が一斉に使うとき――人数ではなく、RPS・同時実行・下流容量で考える

「社員1万人がチャットを使う」と聞くと、1万RPSを想像しやすい。しかし、設計値は次のように分解する。

外部RPS = 利用者数 × 同時利用率 × 1人あたり操作頻度
内部RPS = 外部RPS × 1操作あたりAPI fan-out
必要同時実行数 ≒ RPS × 平均処理秒

たとえば1万人のうち10%が同時に使い、20秒に1回操作するなら外部は50RPSである。1操作が検索、権限、マスタ、履歴の8 APIを呼べば内部は400RPS。ピーク係数5倍なら2,000RPSを想定する。この2,000RPSが平均200msのLambdaなら、おおよその同時実行は400である。

API Gatewayの標準account quotaは、多くのリージョンでHTTP、REST、WebSocketを合算して10,000RPS、burst bucketは最大5,000で、quota increaseを申請できる。ただし一部リージョンは初期値が2,500RPSである。Lambdaはfunctionごとに10秒あたり最大1,000 execution environment、または10秒あたり10,000RPS相当の速度でscaleするが、account concurrency quotaは別に存在する。入口が耐えても、DB、外部SaaS、認可serviceが耐えるとは限らない。^[16][17]

API Gatewayが受けられる量ではなく、DBが安全に処理できる量を基準にworker concurrencyを決める。キューは遅延を消す装置ではなく、過負荷を制御可能な待ち時間へ変える装置である。

バースト対策は「全部を自動scaleさせる」ことではない。各層に違う役割を持たせる。

1. WAFとgatewayで不正・巨大・過頻度requestを落とす。
2. routeごとのthrottleで、高価な検索や集計を軽いread APIから分離する。
3. Lambdaのreserved concurrency、SQS event sourceのmaximum concurrencyでDBを守る。
4. clientは429 / 503に対して指数backoff + jitterを使い、無制限retryしない。
5. POSTにはidempotency keyを持たせ、timeout後の再送で二重更新しない。
6. deadlineを下流へ伝え、上流が諦めたrequestを裏で延々処理しない。
7. queue age、throttle、p95 / p99、DB connection borrow latencyを同時に見る。

Amazon Builders' Libraryは、retryが負荷を増幅するため、各layerで何度もretryせず、backoff、jitter、token bucket、idempotencyを組み合わせる考え方を説明している。Lambda公式best practiceも、downstreamのthroughputを理解し、reserved concurrencyで上限を作り、冪等な実装にするよう求めている。^[18][19]

リアルタイム画面も一種類ではない。1対1の生成結果を徐々に返すならSSE / response streaming、双方向会話ならWebSocket、多数の購読者へbroadcastするならAWS AppSync Eventsが候補になる。API Gateway WebSocketは1接続最大2時間、idle timeout 10分である。数時間開きっぱなしの画面は、再接続とresume tokenを前提にする。^[20][21]

7. データ層――新しいAPIのために、既存DBを壊さない

既存システムへAPIを追加する場合、最も危険なのは「Lambdaが簡単に増えるから、DB接続も簡単に増やす」ことである。Lambdaは数秒で大量の実行環境を作れるが、リレーショナルDBの接続数、lock、buffer、IOPSは同じ速度では増えない。

RDS Proxyはclient connectionを受け、少数のdatabase connectionへpool / multiplexする。突発負荷でDBへ接続を作りすぎるのを防ぎ、上限を超えた接続をqueueまたはthrottleし、failover時の回復も助ける。IAM authenticationを強制し、DB credentialをSecrets Managerへ置くこともできる。^[22]

ただし、RDS Proxyを挟めば無限にscaleするわけではない。

• transactionを短くし、session変数、temporary table、prepared statementなどconnection pinningを起こす使い方を確認する。
• MaxConnectionsPercentを100%近くまで使い切らず、AWSの説明どおり内部変動に備えたheadroomを持つ。
• query timeout、statement timeout、connection borrow timeoutを設定する。
• read-only APIは可能ならread replicaとread-only DB userへ分ける。
• N+1 query、全件scan、巨大なoffset paginationを負荷試験前に潰す。
• Lambda handlerの外でSDK clientや再利用可能connectionを初期化するが、利用者固有データはexecution environmentへ残さない。

データベースの選び方も「serverlessだからDynamoDB」ではない。

Aurora Serverless v2は0.5 ACU単位で最大256 ACUまで設定でき、対応engine versionでは0 ACUまでpauseできる。ただし、0からのresumeは厳しいlatency SLOに向かない。AWSも、scale速度は現在capacityに依存すると説明している。重要な本番系ではminimum ACUを実測で決める。^[23]

更新後にeventも発行する場合、DB commitとSQS publishを別々に行う「dual write」は障害時にずれる。RDSなら同じtransactionで業務tableとoutbox tableへ書き、別processがoutboxをSQSへ送る。DynamoDBならStreamsを使える。標準SQSはat-least-onceなので、consumerも冪等にする。AWS Prescriptive Guidanceのtransactional outbox patternは、この失敗境界を具体的に示している。^[24]

8. コストと保守性――リクエスト単価より、全体の待機・ログ・DBを見る

serverlessは必ず安いのではなく、利用しない時間を買わなくてよいのが強い。一定量を24時間処理するなら、常駐基盤やcommitmentが安くなる地点がある。

米国東部（バージニア北部）の公開単価を使い、free tier、data transfer、WAF、CloudWatch、NAT、RDSを除いた単純例を計算すると、次のようになる。HTTP APIは最初の3億requestまで100万件あたり1ドル、REST APIの例は3.50ドル、Lambda requestは100万件0.20ドル、x86 computeは1 GB秒あたり0.0000166667ドルで計算した。^[25][26]

この表から分かるのは、Lambdaのrequest料金より 実行時間とmemory の方が効きやすく、RESTとHTTPの差はrequest数が増えると無視できないことだ。ただし実際の請求では、DB、WAF、log ingestion、data transfer、NAT Gateway、RDS Proxy、cacheの方が大きくなることがある。

2026年のLambda Managed Instances公式pricing exampleでは、1億request/月、平均200msの高throughput APIをm7g.xlargeと3年Compute Savings Planで動かし、約2,000 instance-hoursを使う想定で、EC2部分91.40ドル、15% management fee約13.71ドル、request料金20ドルという例が示されている。これは特定のtraffic patternとcommitmentの試算で、全環境の損益分岐点ではない。しかし、安定負荷では「Lambdaの開発体験 + EC2価格」という新しい選択肢が現実になったことは分かる。^[26]

見落としやすいコストは次である。

• private subnetのLambdaからpublic SaaSやAWS public endpointへ出るNAT Gateway
• debug logに大きなrequest / responseを出し続けるCloudWatch Logs
• RDS ProxyのvCPU / ACU課金と追加endpointのPrivateLink
• 低hit rateのAPI Gateway cacheやElastiCache
• retry stormによる二重のLambda、外部API、DB負荷
• 過剰なmulti-region、EKS、service meshを初日から持つ運用人件費

保守性の基準は「resource数が少ない」だけではない。

• OpenAPIをsource of truthにし、request / response schemaとbreaking changeをCIで検査する。
• domain logicをhandlerから分け、Lambda / ECSのどちらでも呼べるようにする。
• Infrastructure as CodeはCDK、SAM、Terraform / OpenTofuのいずれかに統一し、console手作業を残さない。
• structured JSON logに trace_id、request_id、subjectの匿名化ID、tenant_id、route、latency_ms、resultを入れる。
• metricは平均ではなくp95 / p99、error、throttle、queue age、DB saturationを見る。
• SLOを「利用可能性99.9%」「read API p95 300ms未満」のように決め、error budgetで投資を判断する。

2026年2月25日からAWS X-Ray SDKとdaemonはmaintenance modeに入った。新規実装はOpenTelemetry / AWS Distro for OpenTelemetryを基本にし、CloudWatch Application SignalsやX-Rayへexportする方が将来性がある。OpenTelemetryにしておけば、ECSや他cloudへ実行基盤を変えてもinstrumentationを持ち運びやすい。^[27]

9. 昔の定石、今の定石――マイクロサービスを増やすことが進化ではない

10年前の典型は、EC2上の大きなWeb application、共有RDS、手書きの認証、cron、ロードバランサーだった。構成は単純だが、patch、capacity、deploy、障害範囲をチームが抱えた。

5年ほど前には、API Gateway、Lambda、Step Functions、細かなmicroservicesへ分ける設計が強く推奨された。初期投資を抑え、機能ごとにscaleし、event drivenにできる利点は本物だった。一方で、1回の要求を細かすぎるfunctionとstate transitionへ分割し、常に同じ順番で通信する「distributed monolith」も生まれた。

現在の定石は、microservicesの数を競うことではない。

• 1チームで保守する初期systemは、module境界を持つmodular monolithでもよい。
• deployment、scaling、data ownership、障害範囲を独立させる必要が出た部分だけserviceへ分ける。
• 同期callの鎖を短くし、非同期化する場所を意図的に選ぶ。
• network hopとserializationの費用が高い処理は、同一processに置く判断もする。
• 既存systemはbig-bang rewriteせず、proxyでrouteを少しずつ新APIへ移す。

既存DBを新APIから直接共有するのではなく、facadeとanti-corruption layerで境界を作る。route単位で新serviceへ移し、旧systemと新systemを安全に共存させる。

AWS Prescriptive Guidanceのstrangler fig patternは、proxy layerが旧monolithと新serviceへrouteを振り分け、anti-corruption layerがinterface差を吸収する段階移行を示している。全面rewriteのriskを避け、変更頻度やscale要求の高い機能から切り出せる。^[28]

有名な反例がPrime Videoのaudio/video quality monitoring serviceである。最初の分散serverless構成は、映像の細かな中間データをS3へ置き、Step Functionsで多数の処理を調整したため、想定負荷の約5%でhard scaling limitと高costに直面した。チームは処理をEC2 / ECS上の単一processへ寄せ、中間データをmemory内で渡し、costを90%削減したと報告した。これは「Prime Video全体がmicroservicesを捨てた」「Lambdaは遅い」という話ではない。常に一緒に動き、大量データを細かく受け渡す処理を、network越しに分解しすぎたという具体例である。^[29]

逆に、利用頻度が読めず、短いAPIが独立し、scale-to-zeroが効く業務APIではserverlessが合理的である。大切なのは流行ではなく、実測したlatency、cost、failure modeから境界を決め直せることだ。

10. 実装判断表とマルチクラウド――最初の90日で何を決めるか

ここまでを、実務の選択表へ落とす。

最初の90日は、次の順で進めると手戻りが少ない。

1. 第1〜2週: 利用者、trust boundary、OpenAPI、SLO、data ownership、ピークmodelを決める。
2. 第3〜4週: OIDC loginからobject-level authorizationまで縦に1本通し、脅威modelを作る。
3. 第5〜6週: 代表read / write API、RDS Proxy、idempotency、structured log、traceを実装する。
4. 第7〜8週: 通常、burst、DB遅延、外部API timeout、duplicate、poison messageを負荷・障害試験する。
5. 第9〜10週: LambdaとECS / Managed Instancesの実測cost、p95 / p99、運用負荷を比較する。
6. 第11〜12週: canary、rollback、runbook、dashboard、quota increase、backup / restore testを終える。

「1万人対応」は、productionへ出してからautoscalingを信じることではない。予定peakの少なくとも2倍を流し、API Gateway throttle、Lambda concurrency、queue age、RDS Proxy borrow latency、DB CPU / connection / lock、外部dependency timeoutがどこで曲がるかを確認する。限界を知らないsystemは、autoscalingしていても容量設計されていない。

持ち運ぶのは同一resource名ではなく、API契約、identity標準、business logic、telemetry、data interface。cloud固有の入口・認可・network・databaseはprovider別moduleとして実装する。

AWS以外でも、同じ原則は横展開できる。

ただし、TerraformやOpenTofuを書けばapplicationが自動的にmulti-cloudになるわけではない。移植性を高めるのは次の設計である。

• API contractをOpenAPI、event contractをAsyncAPI等で固定する。
• loginはOIDC / OAuth 2.0、service identityは短期credentialを使う。
• business logicをcloud SDKから分離し、adapterでSQS / Service Bus / Pub/Subを切り替える。
• containerが適する部分はOCI imageにし、function固有handlerを薄くする。
• telemetryはOpenTelemetryにする。
• IaCは共通moduleを無理に一つにせず、aws/、azure/、gcp/、oci/のprovider別moduleと共通interfaceに分ける。
• data migration、consistency、KMS、network、IAMはcloud固有問題として正面から設計する。

Azure公式のenterprise integration architectureはEntra ID、API Management、Logic Apps、Service Bus等を組み合わせ、Google CloudはAPI Gateway / Cloud Runとservice accountのOIDC ID token、OCI API Gatewayは認証・rate limitとFunctions / Kubernetes / HTTP backendを提供している。概念は十分に対応する。^[30][31][32]

最終的な推奨はシンプルである。小さく始める。ただし、入口のidentity、流量制御、非同期境界、DB保護、observabilityだけは後回しにしない。 API Gateway + Lambdaを選ぶことがmodernなのではない。要求が変わっても、LambdaからManaged Instancesへ、Fargateへ、別cloudへ、無理なく境界を動かせることがmodernなのである。

参考文献