はじめに
こんにちは、 AWS Japan でソリューションアーキテクトをしているいなりくです。
「 Next.js を AWS にサクッとデプロイしたい」。最近こういう相談をよく受けます。既存の AWS インフラと統合したい、コスト構造を自分でコントロールしたい、コンプライアンス要件で AWS アカウント内に全部置きたいなど、 AWS を選ぶ理由はさまざまです。
Next.js の本家である Vercel は Next.js を最もスムーズに動かせるプラットフォームとして発展してきました。一方で、上記のような要件を持つケースでは AWS 上にホストする選択肢を評価したいことも多いはずです。
2026 年の今、 AWS で Next.js を動かす選択肢は以前よりかなり整っています。特に 2026 年 3 月に Next.js 16.2 で公式 Adapter API が stable になり、 AWS を含む多様なプラットフォームで同じ挙動を担保しやすくなったのが大きな転換点です。
この記事では、「サクッと」を重視しつつ、 2026 年 5 月時点で本番に持っていける 3 つの選択肢を整理します。
- AWS Amplify Hosting (Gen 2 compute)
- OpenNext (ビルドは OpenNext 、デプロイは SST などのツール)
- cdklabs/cdk-nextjs (AWS CDK Labs 製のコンストラクト)
それぞれの Pros / Cons 、裏で動いているアーキテクチャ、料金感、向き / 不向きをまとめ、最後に「これから注目の動き」として OpenNext と Amplify の最新状況にも触れます。
TL;DR: 3 つの選択肢の早見表
| Amplify Hosting | OpenNext | cdklabs/cdk-nextjs | |
|---|---|---|---|
| デプロイ体験 | GitHub 連携 → main push |
npx sst init → sst deploy （SST の場合） |
cdk deploy |
| 必要な知識 | Git と AWS コンソール | TypeScript と AWS CLI 認証 | AWS CDK |
| 裏で使っている技術 | Amplify 独自 | OpenNext | Next.js 16.2 公式 Adapter API |
| Next.js 要件 | 12 以降 | OpenNext が対応する範囲 | 16.2 以降のみ |
| インフラの管理 | フルマネージド | すべて自分のアカウント | すべて自分のアカウント |
| On-Demand ISR | ❌ 未対応 | ✅ | ✅ |
画像最適化（ next/image ） |
✅ ビルトイン | ✅ OpenNext | ✅ |
| カスタマイズ | 限定的 |
transform や Override で深くフック可 |
overrides で各レイヤーを差し替え |
| 料金モデル | Amplify 料金 + AWS 従量 | AWS 純粋従量 | AWS 純粋従量 |
| 成熟度 | GA | 成熟（ Anomaly Innovations が運営） | Experimental |
選び方のざっくりした指針:
- IaC を書きたくない・ CI/CD を自分で組みたくない なら Amplify Hosting
- 全機能使いたい・ AWS アカウント内に全リソースを置きたい・ TypeScript で書きたい なら OpenNext （実装は SST が公式おすすめ）
- Next.js 16.2 以降しか使わず、 AWS CDK で書きたい・ OpenNext のような「フレームワーク内部へのパッチ」を避けたい なら cdklabs/cdk-nextjs
以下、順に見ていきます。
前提: Next.js を AWS で動かすときの登場人物
本題に入る前に、最近の Next.js デプロイまわりの登場人物を整理しておきます。ここがわかっていると、後段の比較がすっきり読めます。
OpenNext
2023 年に SST コミュニティが立ち上げた OSS の Next.js アダプターです。 Next.js の build output を AWS（ Lambda / ECS ）や Cloudflare Workers 、 Netlify などに持っていける形に変換します。
2024 年に OpenNext V3 がリリースされ、 Function splitting （ SSR は Lambda 、 ISR は別関数、画像最適化はさらに別など）や、内部コンポーネントを差し替える Override システムが強化されました。 NHS England 、 Udacity 、 Gymshark といった本番事例もあり、現時点で AWS 上の Next.js セルフホスト実装としてはもっとも成熟した部類です。
Next.js 16.2 の Adapter API
2026 年 3 月、 Next.js 16.2 でプラットフォーム向けの公式 Adapter API が stable になりました。これまで OpenNext が「 Next.js の private API をリバースエンジニアリングして動かす」というアクロバティックなことをやっていたのが、公開契約として正式に型付けされた、というのが大きな変化です。
この Adapter API は Vercel 自身のアダプターも含めて同じ公開契約に揃えて作られており、 OpenNext ・ Netlify ・ Cloudflare ・ AWS Amplify ・ Google Cloud が参加する Ecosystem Working Group で設計されています。
なぜこれが本記事に関係するか
3 つの選択肢のうち、 cdklabs/cdk-nextjs はこの公式 Adapter API を使う 設計になっています（ Next.js 16.2 以降必須）。一方、 OpenNext は従来どおり Next.js 本体の出力を独自に処理し、 Amplify Hosting は Amplify 独自実装です。同じ AWS 上の Next.js ホスティングでも、下で動いている仕組みが違うのが 2026 年の景色です。
選択肢 1: AWS Amplify Hosting
どんなものか
AWS 公式のフルマネージド Web ホスティング。 GitHub / GitLab / Bitbucket と連携し、 push したらビルド・デプロイされます。 Gen 2 の Amplify Hosting compute は Next.js の SSR・ ISR・ next/image をアダプターなしでサポートします。
どうデプロイするか
- AWS Amplify コンソール で「アプリをデプロイ」
- リポジトリを接続
- ブランチを選ぶ
-
amplify.ymlでビルド設定を確認 - デプロイ
これだけです。 IaC を書かなくてよく、 CI/CD も自動で組まれます。「サクッと」の度合いでは 3 択の中で最強です。
サービスの位置づけ
Amplify Hosting は フルマネージドのホスティングサービス です。利用者は Git 連携とビルド設定だけで、以下の機能がビルトインで提供されます。
- ビルドパイプライン (CI/CD) — Git push でビルド → デプロイが自動実行
- PR / ブランチプレビュー — 各 PR にユニーク URL が発行され、動作確認が可能
- グローバル CDN 配信
- SSR コンピュート（ Next.js 12 以降、アダプター不要）
- カスタムドメイン + SSL 証明書の自動発行・更新
- WAF ネイティブ統合
- SSR ログの Amazon CloudWatch Logs 連携（利用者の AWS アカウント側）
- IAM Compute Role による SSR → AWS サービスへの安全アクセス
特に 「 Git ベースのパイプラインと PR プレビューがビルトインで手に入る」 のは 3 択の中で Amplify Hosting 固有の大きな強みです。 OpenNext や cdklabs/cdk-nextjs では、これらは GitHub Actions などで自前で組む必要があります。
つまり Amplify Hosting を使う側からすると、 Git push するだけでこれらが自動で整う、という体験になります。
対応機能
Amplify Hosting の SSR supported features より、主要なものをまとめます。
| 機能 | 対応 |
|---|---|
| App Router | ✅ |
| Pages Router | ✅ |
SSR ( getServerSideProps 、 Route Handlers ) |
✅ |
| SSG | ✅ |
| ISR （時間ベース） | ✅ |
On-Demand ISR ( revalidateTag / revalidatePath ) |
❌ |
| Middleware | ✅（一部制限あり） |
| Edge API Routes | ❌ |
next/image 最適化 |
✅ ビルトイン |
| Server Actions | ✅ |
generateMetadata |
✅ |
| Response Streaming | ❌（全レスポンスがバッファリングされる） |
On-Demand ISR ・ Edge API Routes の非対応は AWS Amplify 公式ドキュメント 等でも明記されています。
新しい Next.js 機能ほど対応が遅れる傾向があり、「 Next.js のリリースから Amplify Hosting の対応までラグがある」のは念頭に置いておくべきです。
料金
- ビルド時間（分単位）
- ホスティング容量・データ転送量
- SSR コンピュート（リクエスト数・実行時間）
詳細は Amplify Pricing を参照してください。
Pros / Cons
✅ Pros
- Git ベースの CI/CD パイプラインと PR プレビューがビルトイン （ 3 択の中では Amplify Hosting だけ）
- デプロイまでのステップが最小。 IaC 不要
- カスタムドメイン、 SSL 、 WAF 統合もコンソールから設定可能
- IAM Compute Role で SSR から AWS サービスに安全アクセス可
-
generateMetadataやnext/imageがアダプターなしで動く
❌ Cons
- On-Demand ISR ・ Edge API Routes ・ Response Streaming は非対応
- フルマネージドゆえ、 CloudFront の挙動や SSR Lambda の設定などインフラレイヤーの細かなチューニングは難しい
こういう人向け
- 「インフラはとにかく AWS にまかせたい、 Next.js を git push で動かしたい」
- CI/CD や PR プレビューを自前で組みたくない
- Next.js の機能フル活用より「動けば OK 」を優先する
- まず小さく始めて、必要なら後で IaC 化するつもり
選択肢 2: OpenNext
どんなものか
OpenNext は、 Next.js のビルド成果物を AWS （ Lambda / ECS ）や Cloudflare Workers 、 Netlify 向けに変換する OSS のアダプターです。 SST コミュニティが 2023 年に始め、現在は OpenNext AWS team （ Anomaly Innovations ）が中心にメンテしています。
重要なのは、 OpenNext 自体はビルド変換を行うツールで、 AWS リソースを作るのは別のツールの役目ということです。 OpenNext 公式ドキュメントにも以下のように明記されています。
OpenNext does not create the underlying infrastructure. You can create the infrastructure for your app with your preferred tool — SST, AWS CDK, Terraform, Serverless Framework, etc.
公式の Getting Started で列挙されているデプロイ手段は以下の通りです。
| デプロイ手段 | 備考 |
|---|---|
| SST | OpenNext AWS team 自身が「 The easiest way 」として推奨・公式メンテ |
| CDK |
jetbridge/cdk-nextjs など（コミュニティ貢献） |
| Terraform |
RJPearson94/terraform-aws-open-next 、 nhs-england-tools/terraform-aws-opennext
|
| CloudFormation / Serverless Framework | コミュニティ貢献 |
本記事では最もエルゴノミクスが良い SST を使ったハンズオンを紹介します。
どうデプロイするか (SST での例)
SST は TypeScript で AWS のインフラを書ける IaC フレームワークです。 v3 で AWS CDK から Pulumi （内部的には Terraform provider ） に移行し、 AWS 以外のプロバイダー（ Cloudflare 、 Vercel など）も 1 つの sst.config.ts で扱えるようになっています。 sst.aws.Nextjs というコンポーネント 1 行で、内部で OpenNext を呼んだ Next.js 環境が立ち上がります。
npx sst@latest init
で SST を初期化。生成された sst.config.ts は概ねこんな感じです。
/// <reference path="./.sst/platform/config.d.ts" />
export default $config({
app(input) {
return {
name: "my-nextjs-app",
home: "aws",
removal: input?.stage === "production" ? "retain" : "remove",
};
},
async run() {
// DynamoDB テーブル
const table = new sst.aws.Dynamo("Posts", {
fields: { id: "string" },
primaryIndex: { hashKey: "id" },
});
// Next.js アプリ（内部で OpenNext を呼び出す）
new sst.aws.Nextjs("Web", {
link: [table], // IAM と環境変数を自動注入
domain: "my-app.com",
});
},
});
npx sst deploy --stage production
でデプロイ完了です。
アプリコード側では link したリソースを型安全に扱えます。
// app/page.tsx
import { Resource } from "sst";
const tableName = Resource.Posts.name; // 型付き、 IAM 権限も自動付与済み
裏で何が動いているか
OpenNext は内部で Next.js をビルドし、以下のような構成を SST や CDK / Terraform で自分の AWS アカウントに作ります（図は SST の sst.aws.Nextjs を使った場合）。
OpenNext V3 の Architecture ドキュメントに詳しく書かれています。
開発体験: sst dev (SST 利用時)
SST を使うと Live Lambda Development という開発体験がついてきます。
npx sst dev
これを叩くと、ローカルマシンの TypeScript コードが、 AWS 側にデプロイした API Gateway / SQS / DynamoDB からの呼び出しを WebSocket 経由でプロキシされて実行されます。ブレークポイントが打てて、ホットリロードでき、 CloudWatch を介さず高速にログが見られます。
対応機能
OpenNext 経由なので、 Next.js 15 の機能はほぼフルカバーです。
| 機能 | 対応 |
|---|---|
| App Router / Pages Router | ✅ |
| SSR / SSG / ISR | ✅ |
| On-Demand ISR | ✅ |
| Middleware | ✅ |
| Edge runtime | △（ node runtime の中でエミュレーション） |
next/image 最適化 |
✅ |
| Server Actions | ✅ |
after / 'use cache'
|
✅ |
| NextAuth.js | ✅ |
| Draft Mode | ✅ |
料金
SST 自体の利用料は無料で、 AWS の従量課金のみです。
- Lambda （リクエスト数 + 実行時間）
- CloudFront （データ転送量）
- S3 （ストレージ + リクエスト数）
- DynamoDB （オンデマンド、小規模ならほぼタダ）
- SQS （FIFO 、 ISR リバリデーション用）
- Warmer Lambda （ EventBridge で数分ごとに起動、月数百円オーダー）
小〜中規模ならトータル月 $10〜30 程度に収まるケースが多いです。
Pros / Cons
✅ Pros
- TypeScript で AWS インフラを書ける。 IaC としての DX が 3 択で最上
-
linkで IAM と環境変数の接続がすべて型安全 -
sst devでローカル ↔ AWS のハイブリッド開発 - OpenNext ベースなので Next.js 機能のカバレッジが広い
- リソースはすべて自分の AWS アカウント。 CloudWatch / X-Ray で可視性あり
❌ Cons
- デプロイ手段 (SST / CDK / Terraform 等) を自分で選ぶ必要がある
- SST を使う場合は v2 → v3 のような破壊的変更を経験する可能性、またフレームワークへの依存がある
- OpenNext の挙動理解が必要になるケースがある（エッジランタイム周りなど）
こういう人向け
- Next.js の機能をフル活用したい
- リソースを自分の AWS アカウントに置きたい
- TypeScript / Terraform など、自分の好みの IaC で書きたい
- （ SST を使うなら）
sst devのローカル開発体験に惹かれる
選択肢 3: cdklabs/cdk-nextjs
どんなものか
AWS CDK Labs 製の Next.js 専用 Construct Library です。 Next.js 16.2 の公式 Adapter API を使って Next.js アプリを AWS にデプロイします。 Apache-2.0 。現在は Experimental ステータスで、 2026 年 3 月時点で v0.4.16 が出ています。
設計思想が明確で、 README の FAQ にこう書かれています。
A goal of cdk-nextjs is to customize Next.js as little as possible to reduce the maintenance burden and decrease chances of breaking changes.
これは OpenNext に対する対照的なスタンス です。 OpenNext は Next.js の private API に手を入れて最適化を行う一方、 cdklabs/cdk-nextjs は Next.js を black box として扱い、公開 Adapter API だけに依存 します。そのトレードオフとして Next.js 16.2 以降のみ をサポートします。
どうデプロイするか
npm i cdk-nextjs-
next.config.tsにadapterPathを追加 - CDK スタックで
NextjsGlobalFunctionsを new する
// next.config.ts
import { NextConfig } from "next";
const nextConfig: NextConfig = {
adapterPath: import.meta.resolve("cdk-nextjs/adapter"),
};
export default nextConfig;
// CDK Stack
import { App, Stack, StackProps } from "aws-cdk-lib";
import { Construct } from "constructs";
import { NextjsGlobalFunctions } from "cdk-nextjs";
import { join } from "node:path";
class WebStack extends Stack {
constructor(scope: Construct, id: string, props?: StackProps) {
super(scope, id, props);
new NextjsGlobalFunctions(this, "Nextjs", {
buildDirectory: join(import.meta.dirname),
healthCheckPath: "/api/health",
});
}
}
const app = new App();
new WebStack(app, "web-stack");
cdk deploy
これだけで CloudFront + Lambda + S3 + DynamoDB の構成が立ち上がります。
4 つのアーキテクチャから選べる
cdklabs/cdk-nextjs は用途別に 4 種類の Construct を用意しています。
| Construct | 構成 | 用途 |
|---|---|---|
NextjsGlobalFunctions |
CloudFront + Lambda | 一般的な用途。第一候補 |
NextjsGlobalContainers |
CloudFront + ECS Fargate | 予測可能なトラフィック、低レイテンシ重視 |
NextjsRegionalFunctions |
API Gateway + Lambda | GovCloud 対応 |
NextjsRegionalContainers |
ALB + ECS Fargate | GovCloud 対応 |
Lambda と Fargate を用途に応じて選べる、同じインターフェイスで切り替えられる、という点が強みです。
裏で何が動いているか（ NextjsGlobalFunctions の場合）
OpenNext + SST と似た構成ですが、 Warmer Lambda や SQS FIFO がない分シンプルです。 OpenNext の private API 依存を避けている代わりに、運用のための最適化はやや少なめ、という設計です。
料金感（公式ドキュメントの試算）
README に 1K MAU / 100PV/user / us-east-1 の仮定でのコスト試算が載っています。
| 構成 | 月額 |
|---|---|
NextjsGlobalFunctions (Lambda + CloudFront) |
$8.09 |
NextjsRegionalFunctions (Lambda + API Gateway) |
$11.08 |
NextjsGlobalContainers (Fargate + CloudFront + NAT) |
$121.25 |
NextjsRegionalContainers (Fargate + ALB + NAT) |
$139.00 |
Fargate 系は NAT Gateway のコストが大きく効いてきます。小〜中規模なら Lambda 系、大規模で常時稼働のワークロードなら Fargate 系、という選び分けになります。
Pros / Cons
✅ Pros
- AWS CDK Labs 製で、 Apache-2.0 のオープンソース
- 公式 Adapter API ベースなので Next.js 内部実装への依存が最小
- Lambda / Fargate / Regional / Global の 4 パターンを同じ API で切り替え可能
-
overridesで CloudFront Distribution 、 ECS Cluster 、 ALB 、 S3 、 DynamoDB すべて BYO 可能 -
cdk-nag組み込みでセキュリティベストプラクティスを自動チェック - Preview 環境（ per-branch deployment ）の公式ガイドあり
❌ Cons
- Next.js 16.2 以降必須（それ未満では使えない）
- Experimental ステータス（semver 保証なし、破壊的変更あり得る）
-
NextjsRegionalFunctionsでは API Gateway の制限で Streaming 未対応 - OpenNext が搭載しているコールドスタート対策（ Warmer 関数など）は含まれない
こういう人向け
- AWS CDK を普段から使っている
- Next.js 16.2 以降を使う / 使える
- OpenNext のような「フレームワーク内部への介入」を嫌う
- Lambda / Fargate を用途で切り替えたい
- PR プレビュー環境を構築したい
機能・特性の比較
3 択をもう一段並べて見てみます。
機能対応表
| 機能 | Amplify Hosting | OpenNext | cdklabs/cdk-nextjs |
|---|---|---|---|
| App Router | ✅ | ✅ | ✅ |
| SSR / SSG | ✅ | ✅ | ✅ |
| ISR （時間ベース） | ✅ | ✅ | ✅ |
| On-Demand ISR | ❌ | ✅ | ✅ |
| Middleware | ✅（一部制限） | ✅ | ✅ |
| Edge API Routes | ❌ | △ | △ |
next/image |
✅ | ✅ | ✅ |
generateMetadata |
✅ | ✅ | ✅ |
| Server Actions | ✅ | ✅ | ✅ |
| Response Streaming | ❌ | ✅ | ✅（ Global のみ） |
運用観点の比較
| Amplify Hosting | OpenNext | cdklabs/cdk-nextjs | |
|---|---|---|---|
| リソースの管理 | フルマネージド | 自分の AWS アカウント | 自分の AWS アカウント |
| CI/CD | ビルトイン | 自分で用意 | 自分で用意 |
| PR プレビュー | ビルトイン | 自分で書く | 公式ガイドあり |
| ログ・メトリクス | Amplify コンソール | CloudWatch / X-Ray | CloudWatch / X-Ray |
| カスタムドメイン | コンソールで設定 | IaC で設定（例: SST の domain: プロップ） |
domain: プロップ |
| WAF | ネイティブ統合 | 追加設定で可 |
waf: プロップ |
| コスト可視性 | Amplify 料金 + AWS 料金 | AWS 料金のみ | AWS 料金のみ |
選び方のおすすめ
ユースケース別に:
とにかく手早く、 CI/CD も含めて丸ごと任せたい
Amplify Hosting 。 Git 連携で CI/CD と PR プレビューがビルトイン、 IaC も不要で最速です。 On-Demand ISR ・ Edge API Routes ・ Response Streaming のような非対応機能が要件に入っていないか、最初にチェックしてください。
Next.js 機能をフル活用したい、 TypeScript で IaC を書きたい
OpenNext 。最もエルゴノミクスの良い実装は SST の sst.aws.Nextjs で、 1 行の定義で OpenNext 構成が立ち上がり、 link で周辺リソースも型安全に繋がります。 sst dev のローカル開発体験は一度試す価値があります。 SST 以外にも CDK や Terraform のコミュニティ実装が利用できます。
普段から AWS CDK を使っている、 Next.js 16.2 以降に乗る
cdklabs/cdk-nextjs 。既存の CDK プロジェクトに 1 Construct を追加するだけで Next.js アプリがデプロイできます。 Lambda か Fargate かも柔軟に選べます。
これから注目の動き
最後に、 2026 年 5 月時点で進行中の注目トピックを 2 つだけ紹介します。いずれもまだ GA やアナウンスされたわけではなく、 GitHub 上で公開されている情報をもとにしています。仕様は変更される可能性があるため、採用判断は公式アナウンスを待つのが無難です。
1. OpenNext の Next.js Verified Adapter
Next.js 16.2 の Adapter API に合わせ、 OpenNext も Verified Adapter として Next.js の GitHub Organization 配下に入り、 AWS / Cloudflare / Netlify 向けの新しいアダプターを共有モノレポで開発中です。リリースは 2026 年中が目標とされています。
ポイントは、既存の OpenNext V3 は引き続きサポート・メンテナンスされるということです。今日 OpenNext で組んだ環境が無駄になることはありません。
2. @aws-amplify/hosting パッケージ（ Preview / 開発中）
Amplify チームが aws-amplify/amplify-backend リポジトリで、 Amplify Hosting を「自分の AWS アカウント内に立てる IaC 版」 に相当する新パッケージを開発中です。複数の PR で進行しています。
公開 PR から読み取れる範囲で整理すると:
- 新パッケージ
@aws-amplify/hostingが追加され、defineHosting()という API が提供される - 内部で
@opennextjs/awsを使って Next.js のビルドを処理する -
AmplifyHostingConstructは Amplify フレームワークから独立した CDK Construct としても使える - リソースは利用者自身の AWS アカウントに S3 + CloudFront + Lambda として作られる
package.json を見ると OpenNext に依存しているのが確認できます。
"dependencies": {
"@opennextjs/aws": "~3.10.0",
...
}
ただし、現時点では以下の点に注意が必要です。
- PR #3174 は Draft 状態、未マージ
- npm に publish されているのは
0.0.0-test-seedなどの snapshot リリース のみ - README にも
"⚠️ PREVIEW release — not for production use"と明記 - AWS 公式ブログ・ドキュメントでのアナウンスはまだない
- API も PR 内で数回 redesign されており、今後も変わる可能性が高い
つまり「 AWS が正式発表した新機能」ではなく、「 GitHub 上で開発中のパッケージ」という段階です。方向性としては IaC として利用者の AWS アカウントにリソースを作り、 OpenNext を内部採用して Next.js 機能カバレッジを広げる という動きに見えますが、リリース時期や最終 API は公式発表を待ちましょう。
まとめ
AWS で Next.js をサクッとデプロイするなら、 2026 年 5 月時点では以下の 3 択がバランスの取れた選択肢です。
- AWS Amplify Hosting: IaC 不要・ Git push で動く。 On-Demand ISR 等の機能制限を許容できるなら最速
- OpenNext: Next.js 機能をフルカバー。 SST 、 CDK 、 Terraform など好みの IaC でデプロイ可能 (OpenNext AWS team のおすすめは SST)
- cdklabs/cdk-nextjs: AWS CDK Labs 製、公式 Adapter API ベース。 Next.js 16.2 以降で CDK を使う人向け
あわせて、
- Next.js 16.2 の Adapter API が stable になり、今後 OpenNext が Verified Adapter として公式の立場を得ようとしている
-
Amplify Hosting の IaC 版（
@aws-amplify/hosting）が GitHub 上で開発中、 Preview スナップショットとして npm にも出ている
というように、今後 6〜12 か月で景色がさらに動く可能性があります。現時点での採用判断は今日使える 3 択から、そして新しい動きは公式アナウンスを待ちつつウォッチしておく、くらいのスタンスがちょうどよいと思います。
「サクッと」の閾値は人によって違うので、「自分のユースケースに一番ハマるサクッと」を見つけていただければ幸いです。
参考
この Publication に投稿している記事は、アマゾン ウェブ サービス ジャパン合同会社または Amazon Web Services, Inc. 所属社員による個人の見解であり、所属する組織の公式見解ではありません。参加したい従業員の方は、Sugiyama Suguru までお知らせください。
Discussion