AWSが2026年6月4日に発表した「AWS Databases on Vercel」の追加リージョン対応は、Vercelやv0で作ったアプリのデータ層を考える人にとって、かなり実務寄りのニュースです。ポイントは、Vercel Marketplaceやv0からAmazon Aurora PostgreSQL、Amazon Aurora DSQL、Amazon DynamoDBを作る入口が広がり、東京と大阪を含むAWSリージョンを選びやすくなったことです。
この記事では、AWS公式発表、AWS Database Blog、Vercel公式情報、AWSの各データベース製品ページで確認できる範囲に絞り、日本の開発者や導入担当者が作成前に見るべきことを整理します。確認日は2026年6月6日です。Amazon Watch JapanはAmazonおよび関係会社とは非提携の独立ブログであり、商標や公式情報は出典を明示して扱います。
3行まとめ
このテーマをもう少し広げて見るなら、AWS MCP Serverのクロスアカウント対応とは：AIコーディングエージェントに複数AWSアカウントを触らせる前に確認すべき権限設計 と 次世代Amazon OpenSearch Serverlessとは：AIエージェント検索基盤で確認すべきScale-to-zeroと移行条件 も合わせて確認してください。v0やAIコーディングエージェントからAWSリソースを扱う前に、アカウントとロールの境界を確認できます。
Aurora PostgreSQL、Aurora DSQL、DynamoDBをVercelの導線から選びやすくなった。
Aurora DSQLの対象リージョンには、Asia Pacific (Tokyo)とAsia Pacific (Osaka)が含まれる。
v0で作れることと、安全に運用できることは別に考える必要がある。
データベースの種類、リージョン、AWSアカウント、権限、請求、環境変数を分けて確認する。
- AWS Databases on Vercelは、Vercel Marketplaceとv0からAurora PostgreSQL、Aurora DSQL、DynamoDBを使う導線で、2026年6月4日に追加AWSリージョン対応が発表されました。
- Aurora PostgreSQLとDynamoDBはVercel経由で17のデフォルト有効リージョンから、Aurora DSQLは東京・大阪を含む16リージョンから作成できるとAWSは説明しています。
- v0で自然言語からアプリとDBを作れることと、本番で安全に運用できることは別です。リージョン、DB種類、AWSアカウント、権限、請求、環境変数を分けて確認する必要があります。
この話題は、6月のAWS関連発表を追っている読者にとって、生成AIアプリの「モデル」ではなく「データの置き場所」を考える入口になります。月次の流れを追う場合は、公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月 重要トピックまとめ</a>もあわせて確認できます。今回の記事では、ニュースの見出しよりも、実際にVercelやv0の画面でDBを選ぶ前の判断材料を優先します。
AWS Databases on Vercelのリージョン拡大で何が変わったのか
Vercel MarketplaceからAWSデータベースを作成し、プロジェクトへ接続する導線がある。
自然言語からアプリとデータベースを作る流れで、AWSデータベースを使う選択肢が入る。
Aurora PostgreSQLとDynamoDBは、デフォルトで有効な17のAWSリージョンから作成できると説明されている。
Aurora DSQLは、東京と大阪を含む16のAWSリージョンが対象として挙げられている。
選択肢が増えた分、アプリの利用者、データ要件、運用体制に合わせて選ぶ必要がある。
AWSの発表では、Amazon Aurora PostgreSQL、Amazon Aurora DSQL、Amazon DynamoDBのサーバーレスデータベースが、Vercel Marketplaceとv0 by Vercelで追加AWSリージョンに対応したと説明されています。ここで重要なのは、単に選択肢が増えたことではありません。Vercelでアプリを作る流れの中で、データベースのリージョン、DB種類、AWSアカウントを同じ導線で選びやすくなったことです。
東京・大阪を含む追加リージョン対応の要点
AWSによると、Vercel経由でAurora PostgreSQLデータベースまたはDynamoDBテーブルを作成できるリージョンは、デフォルトで有効な17のAWSリージョンに広がりました。Aurora DSQLについては、16のAWSリージョンが挙げられており、その中にAsia Pacific (Tokyo)とAsia Pacific (Osaka)が含まれています。
根拠
公式発表で明記されているAurora DSQLの対象リージョンには、米国東部、米国西部、アジア太平洋、カナダ、欧州、南米の複数リージョンが並びます。日本の読者にとっては、東京だけでなく大阪も含まれる点が目を引きます。ただし、リージョンが選べることと、アプリ全体が日本国内の要件を満たすことは同じではありません。
注意点
Vercel側の実行環境、AWS側のDBリージョン、外部API、ログ、バックアップ、監視サービスは、それぞれ別の場所に存在しえます。東京や大阪を選ぶ理由が、遅延なのか、既存AWS資産との近さなのか、社内規定なのか、災害対策なのかを先に分けておかないと、「日本リージョンを選んだから大丈夫」という雑な判断になりがちです。
Vercel Marketplaceとv0で作れること
AWSの発表では、v0に自然言語でアイデアを説明すると、ツールが仕様に沿った設計、コードとインフラのデプロイ、アプリケーションデータの保存先として適したAWSデータベースの利用まで進める、と説明されています。Vercel側の公式情報でも、Vercel MarketplaceからAurora PostgreSQL、Aurora DSQL、DynamoDBを選び、プロジェクトに接続する流れが紹介されています。
確認項目
まず見るべきなのは、どのDBが選べるか、どのリージョンが選べるか、新規AWSアカウントを作るのか、既存AWSアカウントを連携するのかです。次に、接続情報や認証情報がどのVercelプロジェクトへ注入されるのか、プレビュー環境と本番環境で分かれているのか、後から権限や請求を誰が管理するのかを確認します。
誤解しやすい点
「v0で作れる」は、「スキーマ設計、権限設計、監視、バックアップ、コスト管理まで自動で本番品質になる」という意味ではありません。とくにデータベースは、後から直すと影響範囲が大きくなります。最初の試作では便利さを活かしつつ、本番投入前にはDBの種類、テーブル設計、接続管理、環境変数、利用量を人間が見直す前提で扱うのが安全です。
Aurora PostgreSQL、Aurora DSQL、DynamoDBはどう選ぶか
どれか一つが常に優れているわけではなく、アプリのデータ要件と運用チームの知識で選ぶ。
今回の発表では3つのデータベース名が並びますが、読者が迷うのは「どれが一番新しいか」ではなく「自分のVercelアプリにはどれが合うか」です。ここはAWSの製品説明をそのまま覚えるより、データの形、アクセスパターン、運用チームの知識、将来の変更可能性から見るほうが判断しやすくなります。
AWS関連サービスの導入判断をまとめて追いたい場合は、カテゴリHubの<a href="https://amzn-watch.blog.mo-gmo.com/category/products-services-solutions/">製品・サービス・ソリューション</a>から関連記事を確認できます。
Aurora PostgreSQLを選びやすいケース
Amazon Auroraは、AWSの公式ページではMySQLおよびPostgreSQLと互換性のあるリレーショナルデータベースサービスとして説明されています。Vercelアプリで、ユーザー、注文、投稿、コメント、管理画面、権限ロールのように、データ同士の関係をSQLで扱いたいなら、Aurora PostgreSQLは最初に検討しやすい選択肢です。
評価基準
既存のPostgreSQL知識を使えるか、ORMやマイグレーションツールを使うか、トランザクションが必要か、後から管理画面や分析クエリを増やす予定があるか。このあたりに心当たりがあるなら、まずAurora PostgreSQLを候補に置くと考えやすくなります。v0で生成されたコードがPostgreSQL前提のスキーマやクエリを作る場合も、レビューしやすいのが利点です。
注意点
入口が簡単でも、リレーショナルDBの運用が消えるわけではありません。接続数、スキーマ変更、バックアップ、権限分離、接続文字列の管理、長期費用は別途確認が必要です。Vercelのプレビュー環境ごとに同じ本番DBへ接続してしまうと、テストデータや破壊的なマイグレーションが混ざる可能性もあります。試作環境と本番環境の分離は、v0で作った後に必ず確認したい点です。
Aurora DSQLを検討するケース
Amazon Aurora DSQLは、AWS公式ページでサーバーレス分散SQLデータベースとして説明されています。アクティブ・アクティブの分散アーキテクチャ、PostgreSQL互換、複数リージョンでの可用性を強く意識するアプリでは、検討対象になります。今回の発表で東京と大阪が含まれることは、日本向けの可用性設計や検証を考える読者にとって大きな確認点です。
条件
Aurora DSQLを考えるのは、単に「新しいDBを触りたい」場合ではなく、分散SQL、サーバーレス、複数リージョン、強い整合性、可用性といった特徴が要件に関係する場合です。たとえば、国内ユーザー中心だが将来的に複数リージョン構成を評価したい、災害対策を見据えたデータ層を検証したい、といったケースでは見る価値があります。
下振れ
小さなCRUDアプリ、社内向けの単純な管理画面、短期のキャンペーンサイトのような用途で、いきなり分散SQLを選ぶと過剰設計になることがあります。Aurora DSQLをPostgreSQLの完全な上位互換のように扱うのも危険です。PostgreSQL互換という言葉だけで決めず、対応機能、制約、料金、リージョン、利用するORMやドライバーとの相性を公式ドキュメントで確認する必要があります。
DynamoDBを選びやすいケース
Amazon DynamoDBは、AWS公式ページでサーバーレス、フルマネージド、分散NoSQLデータベースとして説明されています。公式ドキュメントでは、任意の規模で一桁ミリ秒のパフォーマンスを提供すること、JOINのようなリレーショナルDB的な機能を前提にしない設計であることも説明されています。
評価基準
DynamoDBが向くのは、アクセスパターンが先に見えている用途です。セッション、イベント、ステータス、通知、ユーザーごとの設定、単純なキー値アクセス、時間順のログなど、どのキーで読み書きするかを最初に決められるなら候補になります。Vercelやv0で作る小さなアプリでも、読み書きパターンが単純なら扱いやすい場合があります。
注意点
一方で、後から自由に検索条件を足したい、管理画面で複雑に絞り込みたい、複数テーブルをJOINして柔軟に分析したい、という用途では設計が難しくなります。DynamoDBを選ぶなら、テーブル設計より先に「誰が、何をキーに、どの頻度で読むのか」を書き出すべきです。v0が生成した構成をそのまま採用する前に、将来の検索条件と運用担当者の理解度を確認しておくと、後戻りが少なくなります。
東京・大阪リージョンを選ぶ前に確認すること
日本向けユーザーが中心で、既存AWS資産や監視基盤がap-northeast-1に寄っている場合に確認しやすい。
災害対策や分散配置の候補になるが、アプリ全体の構成や復旧手順と合わせて判断する。
DBだけを日本に置いても、アプリ、ログ、認証、外部連携の所在地まで自動で決まるわけではない。
既存の監視、ログ、権限、社内標準と同じリージョン設計に寄せられるかを見る。
リージョン選択は、DB単体ではなくアプリ全体の遅延、監査、復旧、データ管理と合わせて確認する。
東京と大阪が選択肢に入ると、日本の読者はすぐに「国内向けなら東京」「DRなら大阪」と考えたくなります。方向性としては自然ですが、実際の設計ではもう少し丁寧に分ける必要があります。データベースの場所だけで、アプリ全体の遅延、データ所在地、監査、災害対策が決まるわけではないからです。
東京リージョンを選ぶ理由
東京リージョンを選びやすいのは、日本向けユーザーが中心で、既存のAWS資産、監視、ログ、社内標準がap-northeast-1に寄っている場合です。すでにCognito、S3、Lambda、API Gateway、Bedrock、監視基盤などを東京リージョンで運用しているなら、DBも近い場所に置くことで、ネットワーク経路や運用確認がしやすくなります。
根拠
今回の発表で東京が含まれることは、Vercelやv0で作るアプリからAWS DBを使うとき、日本のAWS利用者が既存設計に寄せやすくなる材料です。たとえばログイン基盤やDRの観点をあわせて見るなら、公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-20-cognito-multi-region-replication/">Cognitoマルチリージョンレプリケーションの記事</a>も参考になります。
確認項目
東京を選ぶ前に、Vercel側のデプロイ地域、DBのリージョン、外部API、ログ保管先、バックアップ先、監視通知の宛先を分けて見ます。ユーザーが日本中心でも、Vercel側の処理や外部サービスが別地域にあるなら、体感速度やデータの流れはDBだけでは決まりません。企業利用では、社内のクラウド利用規定とデータ分類も確認したほうがよいです。
大阪リージョンをどう位置づけるか
大阪リージョンは、単に「東京の代わり」ではなく、可用性、DR、既存AWS設計との関係で位置づけるほうが自然です。とくにAurora DSQLのように複数リージョンや高可用性が話題になりやすいサービスでは、東京と大阪をどう使い分けるかが検証テーマになります。
条件
大阪を候補に入れるなら、どの障害を想定するのか、どのデータを複数リージョンで扱うのか、アプリケーション側がリージョン切り替えに対応できるのかを考える必要があります。DBが大阪に作れるとしても、フロントエンド、API、認証、決済、通知がどう切り替わるかを考えないと、DBだけが分散しても全体の可用性は上がりません。
注意点
リージョン対応は変わりやすい情報です。今回の記事では2026年6月6日時点の公式発表をもとにしていますが、実際に作成する直前には、Vercel Marketplace、v0の作成画面、AWS公式発表、各DBのリージョン表を再確認してください。確認先をまとめる入口としては、固定ページの<a href="https://amzn-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>も使えます。
新規AWSアカウント作成と既存AWSアカウント連携の違い
新規作成と既存連携は、試作の速さと運用責任の置き場所が変わる選択として見る。
AWSの発表では、Vercelから新しいAWSアカウントを作成する流れと、既存AWSアカウントを連携する流れの両方が説明されています。ここは、クレジットだけを見て決める場所ではありません。請求、権限、監査、アカウント所有者、将来の移行、社内ルールを含めて確認する必要があります。
新規AWSアカウント作成で見ること
AWSは、新規AWSアカウントをVercelから作成した場合、3つのデータベースに使える100米ドルのクレジットを最大6カ月利用できると説明しています。試作やハッカソン、個人開発、社内検証の入口としては魅力があります。AWS Database Blogでも、Vercelダッシュボード内のAWS settings pageでプラン、支払い情報、利用状況を管理できると説明されています。
根拠
Vercel公式情報では、新規AWSチーム向けにVercel-managed accountを作成し、Aurora PostgreSQL、Aurora DSQL、DynamoDBを選び、リージョンとプランを選んでプロジェクトへ接続する流れが示されています。AWS側のブログでは、Vercel経由で作成されるAWSアカウントは、簡素化された体験のための限定的なスコープのアカウントであり、AWSサービスへのフルアクセスが必要な場合は既存AWSアカウントを接続する、と説明されています。
注意点
100米ドルクレジットは、長期運用費用の保証ではありません。対象サービス、利用可能期間、超過後の請求、支払い情報、プラン変更、リージョンごとの費用、バックアップやデータ転送の費用を確認してください。個人開発なら入口として使いやすくても、企業利用では請求先やアカウント所有者が曖昧にならないようにする必要があります。
既存AWSアカウント連携で見ること
すでにAWS Organizations、IAM、請求タグ、CloudTrail、監視、セキュリティ基準を運用している企業やチームでは、既存AWSアカウントを連携するほうが自然な場合があります。Vercel公式ブログでは、既存AWSアカウントを連携する場合、AWS IAMの一時的な委任権限を使い、VercelからAWSリソースを作成してプロジェクトに接続できると説明されています。
確認項目
誰のAWSアカウントにDBを作るのか、どのIAM権限をVercelに許可するのか、作成されたDBにどのタグを付けるのか、利用量を誰が見るのか、CloudTrailや監査ログで何を確認するのかを決めておきます。既存VPC、既存DB、既存Secrets Manager、社内の承認フローとの関係も確認が必要です。
上振れ
既存AWSアカウント連携の利点は、社内の監視、請求、セキュリティ、ログ保管、運用ルールに乗せやすいことです。DB接続情報やAPIキーなどの扱いを深掘りしたい場合は、公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-21-agentcore-identity-secrets-manager/">AgentCore IdentityとSecrets Managerの記事</a>も、認証情報をどう分けるかの参考になります。
v0で生成した後に本番投入前に確認すること
- 1接続先を分ける
本番、プレビュー、ローカル開発で、接続先DBが分かれているか確認する。
- 2認証情報を確認する
自動注入された値の保存場所、露出、リポジトリへの書き戻しを確認する。
- 3最小権限に寄せる
Vercelに付与した権限、DB権限、アプリから使うユーザーやロールを分けて見る。
- 4復旧手順を持つ
監視、バックアップ、削除権限、障害時の対応を本番前に確認する。
接続できることと、最小権限で安全に接続していることは別に確認する。
v0でアプリとDBがすぐ作れるとしても、本番投入前のレビューは省けません。むしろ生成の速度が上がるほど、レビューの観点を先に決めておかないと、動くデモと運用できるサービスの差が見えにくくなります。
環境変数と認証情報
Vercel公式情報では、AWSデータベースを接続すると、Vercelが環境変数や設定を自動で注入すると説明されています。AWS Database Blogでも、接続文字列や認証情報の環境変数が生成され、Vercelプロジェクト内に安全に保存されると説明されています。これは便利ですが、どの環境に何が入ったかを見ないまま本番化するのは危険です。
確認項目
本番環境、プレビュー環境、ローカル開発環境で、接続先DBが分かれているかを確認します。環境変数名、接続先リージョン、権限、ローテーション方法、ログへの露出、スクリーンショットやAIプロンプトへの貼り付けリスクも見ます。自動注入された値をリポジトリに書き戻さないことも大切です。
注意点
接続できることと、最小権限で安全に接続していることは別です。特に既存AWSアカウントを連携する場合、Vercelに付与した権限、作成されたDBの権限、アプリから使うユーザーやロールを分けて確認してください。便利な統合ほど、どこまで自動で、どこからが自分たちの責任かを明確にする必要があります。
スキーマ、権限、監視
DBを作った後は、スキーマ変更、マイグレーション、監視、バックアップ、利用量の見える化が必要です。Aurora PostgreSQLなら接続数やマイグレーション、Aurora DSQLなら分散構成や対応機能、DynamoDBならアクセスパターンとホットキーを見ます。どのDBを選んでも、「作成できた」で終わらせないことが大切です。
評価基準
本番前の最小ラインとして、スキーマ変更手順、データ削除の権限、管理者操作のログ、アプリケーションエラー、DBメトリクス、バックアップまたは復旧手順、費用アラートを確認します。Vercelから作ったDBでも、AWS側のメトリクスや請求はAWSの責任範囲として確認する場面が出てきます。
下振れ
デモでは軽く動いていても、ユーザーが増えると接続数、DynamoDBのパーティション設計、クエリの偏り、スキーマ変更、データ移行、コスト急増で詰まることがあります。AWSアプリ実行基盤の選択も含めて見たい場合は、公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-18-aws-app-runner-maintenance-ecs-express-mode/">App Runner新規受付停止後の確認ポイント</a>も、運用基盤を見直す文脈で参考になります。
まず試すならどの構成が無難か
- 1関係性のあるデータか
ユーザー、投稿、注文、管理画面のような関係性があるならAurora PostgreSQLから考えやすい。
- 2キー値アクセスが明確か
アクセスパターンを先に説明できるならDynamoDBを候補にできる。
- 3分散SQLを検証するか
分散SQLや高い可用性が検証目的ならAurora DSQLの要件を確認する。
- 4試作と本番を分ける
接続先、マイグレーション、プレビュー環境、バックアップ、削除権限を分けて確認する。
最初の検証では、試作データと本番データを混在させないことを前提に小さく始める。
最初の検証では、いきなり万能構成を作ろうとしないほうがうまくいきます。Vercelとv0の強みは、アイデアから小さく動かすまでの距離を縮めることです。だからこそ、DB選定も「試作の目的」に合わせて小さく決めるのが現実的です。
小さなCRUDアプリならAurora PostgreSQLから考える
ユーザー、投稿、注文、問い合わせ、管理画面のように、関係性のあるデータを扱うならAurora PostgreSQLから考えるのが無難です。SQLやORMの知識を活かしやすく、v0が生成したスキーマやコードもレビューしやすいからです。
条件
PoCや社内ツールで、最初から複数の検索条件や管理画面が必要なら、PostgreSQL互換のほうが変更に追随しやすいことがあります。既存チームがPostgreSQLに慣れているなら、学習コストも抑えられます。
確認項目
接続先が本番DBだけになっていないか、マイグレーションをどう実行するか、プレビュー環境をどう分けるか、バックアップや削除権限を誰が持つかを確認します。小さなアプリでも、本番データと試作データの混在は避けるべきです。
イベントやセッション中心ならDynamoDBを検討する
イベント記録、セッション、ユーザー設定、通知状態、短いステータス管理など、キーで素早く読み書きする用途ではDynamoDBが候補になります。Vercelアプリの中でも、DBを複雑な検索基盤としてではなく、高速な状態保存先として使う場合に合いやすい選択肢です。
条件
読み書きのパターンが明確で、主キーやソートキーの設計を先に決められることが前提です。たとえばユーザーID単位、プロジェクトID単位、日時順のイベントなど、アクセスパターンが安定しているなら評価しやすくなります。
注意点
後から「この条件でも検索したい」「管理画面で自由に絞り込みたい」が増えると、DynamoDBの設計を見直す必要が出ます。v0が作った初期テーブルをそのまま使う前に、将来の検索条件を1ページに書き出しておくと判断しやすくなります。
分散SQLを評価したいならAurora DSQLを小さく試す
Aurora DSQLは、分散SQLや高可用性を検証したい場合に候補になります。東京と大阪を含むリージョン対応が見えてきたことで、日本の開発者も「将来の可用性設計」を手元で検討しやすくなりました。
評価基準
分散SQLが本当に要件に関係するかを先に問い直します。国内向けの小さなアプリでも、将来の高可用性、複数リージョン、事業継続性を検証する目的があるなら、Aurora DSQLを小さく試す意味があります。
注意点
一方で、単純なCRUDや短期のPoCでは、Aurora DSQLの価値が見えにくい場合があります。新しいサービス名だけで選ばず、公式ドキュメント、料金、制約、対応ツールを確認してから、本番候補にするかを決めるべきです。
作成ボタンを押す前の確認表
最初に決めるべきなのはDB種類ではなく、アプリのデータ要件と運用責任の置き場所。
最後に、Vercel Marketplaceやv0でAWS Databasesを選ぶ前の確認項目を、実務の順番でまとめます。
| 確認すること | 見る理由 | 見落とすと起きること |
|---|---|---|
| DB種類 | データの形とアクセスパターンに合うかを決めるため | 後からスキーマや検索要件を大きく変えることになる |
| リージョン | 遅延、既存AWS資産、社内規定、DRに関わるため | DBだけ日本に置いても全体要件を満たせない |
| AWSアカウント | 請求、権限、監査、所有者が変わるため | 誰が費用と権限を管理するか曖昧になる |
| 環境変数 | 接続先と認証情報の露出を防ぐため | 本番DBへプレビュー環境が接続する |
| 料金とクレジット | 試作費用と長期運用費は別だから | クレジット終了後や超過利用で想定外の請求になる |
| 監視と復旧 | 本番運用では障害時の手順が必要だから | デモは動くが障害時に復旧できない |
この表の中で、最初に決めるべきなのはDB種類ではなく、アプリのデータ要件です。リレーショナルに変更し続けるならAurora PostgreSQL、キー値アクセスが明確ならDynamoDB、分散SQLや可用性を検証したいならAurora DSQL、という順で考えると、公式発表を実装判断に落とし込みやすくなります。
更新履歴
- 2026年6月4日リージョン拡大が発表
AWS Databases on Vercelの追加AWSリージョン対応が発表された。
- 2026年6月6日初版を作成
AWS What’s New、AWS Database Blog、Vercel公式情報、AWS各データベース製品ページを確認した。
更新履歴は、確認した一次情報と記事作成時点を分けて読む。
- 2026年6月6日: AWS What’s New、AWS Database Blog、Vercel公式Marketplace、Vercel公式Blog、AWS各データベース製品ページを確認し、初版を作成しました。
次に読むなら
参照した主な情報源
- AWS What's New「AWS Databases on Vercel now available in additional AWS Regions」確認日: 2026年6月6日 https://aws.amazon.com/about-aws/whats-new/2026/06/aws-databases-vercel-aws-regions/
- AWS Database Blog「AI-native, full-stack web apps with Vercel and AWS Databases」確認日: 2026年6月6日 https://aws.amazon.com/blogs/database/ai-native-full-stack-web-apps-with-vercel-and-aws-databases/
- Vercel Marketplace「AWS for Vercel」確認日: 2026年6月6日 https://vercel.com/marketplace/aws
- Vercel Blog「AWS databases are now live on the Vercel Marketplace and v0」確認日: 2026年6月6日 https://vercel.com/blog/aws-databases-are-now-live-on-the-vercel-marketplace-and-v0
- AWS「Amazon Aurora」確認日: 2026年6月6日 https://aws.amazon.com/rds/aurora/
- AWS「Amazon Aurora DSQL」確認日: 2026年6月6日 https://aws.amazon.com/aurora/dsql/
- AWS「Amazon DynamoDB」確認日: 2026年6月6日 https://aws.amazon.com/dynamodb/