AppSync

AppSync とは

AWS AppSync は、GraphQL API をフルマネージドで提供するサービスである。DynamoDB、Lambda、RDS、OpenSearch、HTTP エンドポイントをデータソースとして接続し、単一の GraphQL エンドポイントから統合的にデータを取得・更新できる。リアルタイムのサブスクリプション (WebSocket) もビルトインで提供する。

API Gateway + Lambda vs AppSync

両者の差は「REST か GraphQL か」だけではない。リアルタイム配信・キャッシュ・認可の選択肢まで含めて、どこを自前で作る必要があるかが変わる。

観点	API Gateway + Lambda	AppSync
API スタイル	REST	GraphQL
データ取得	エンドポイントごとに固定	クライアントが必要なフィールドを指定
リアルタイム	WebSocket API を別途構築	サブスクリプションがビルトイン
N+1 リクエスト	クライアントが関連データを個別に取得して発生	入れ子フィールドのリゾルバーが件数分呼ばれて発生し、バッチ化で抑える
認可の選択肢	IAM、リソースポリシー、Lambda オーソライザー、JWT / Cognito オーソライザー	API キー、Lambda、IAM、OIDC、Cognito ユーザープールの 5 方式
キャッシュ	自前で実装	ビルトインキャッシュ

モバイルアプリやリアルタイム機能が必要な場合は AppSync、シンプルな REST API なら API Gateway + Lambda が適する。

表で「認可の選択肢」としたのは、API Gateway の API キーが利用プランによる計測とスロットリングの仕組みであって、それ単体を認証の代わりに使うものではないためである。GraphQL 側の N+1 も自動では消えない。1 件のクエリで親を取り、子フィールドのリゾルバーが親の件数だけ呼ばれる形で発生するため、Lambda データソースなら BatchInvoke (maxBatchSize で 1 回に渡す入力数を指定する) 、DynamoDB なら一括取得の API へまとめる設計が必要になる。

リゾルバーの種類

リゾルバーは GraphQL のフィールドとデータソースをつなぐ部品で、書き方と実行場所の組み合わせで選ぶ。

リゾルバー	説明	適用場面
VTL リゾルバー	Apache Velocity テンプレートで記述	DynamoDB への直接アクセス
JavaScript リゾルバー	APPSYNC_JS ランタイムで実行	変換処理を関数内で完結させる
Lambda リゾルバー	Lambda 関数を呼び出し	既存のビジネスロジック
パイプラインリゾルバー	複数の AppSync 関数を順に実行	認可チェック → データ取得 → 整形

JavaScript リゾルバーは Lambda を経由せず AppSync 内の APPSYNC_JS ランタイムで動くため、変換処理のために Lambda 関数を 1 つ増やす必要がない。2026 年 8 月時点ではユニットリゾルバーとパイプラインリゾルバーの両方で JavaScript が使え、VTL の関数と JavaScript の関数を同じパイプラインに混在させることもできる。

ただし APPSYNC_JS は ECMAScript の部分集合で、ネットワークアクセスとファイルアクセスができず、async/await や Promise も使えない。外部 API の呼び出しや重い処理は HTTP データソースか Lambda リゾルバーへ寄せる前提で設計する。

リアルタイムサブスクリプション

サブスクリプションは、スキーマ側の宣言とクライアント側の購読が対になって動く。まずスキーマで、どの Mutation を契機に通知するかを @aws_subscribe で結び付ける。

type Subscription {
  onCreateMessage(channelId: String!): Message
    @aws_subscribe(mutations: ["createMessage"])
}

クライアントはこの購読フィールドを呼ぶ。

subscription OnNewMessage {
  onCreateMessage(channelId: "general") {
    id
    content
    author
    createdAt
  }
}

クライアントが購読を登録すると、AppSync がサーバーレスの WebSocket 接続を維持し、対応する Mutation が正常終了したタイミングで購読者へデータを配信する。引数 (上の例では channelId) を渡せば、その値に一致する変更だけを受け取れる。チャット、通知、ダッシュボードの自動更新に使える。

落とし穴は、通知の契機が「AppSync の API を通した Mutation」に限られる点である。バッチ処理や別のサービスが DynamoDB のテーブルを直接書き換えても、サブスクリプションは発火しない。裏側から更新する経路がある場合は、その処理からも AppSync の Mutation を呼ぶか、DynamoDB Streams を受けて Mutation を実行する Lambda を挟む必要がある。

DynamoDB との統合

AppSync は DynamoDB と直接統合でき、Lambda を経由せずに CRUD 操作を実行できる。

[クライアント] → [AppSync] → [DynamoDB]
                    ↓
              VTL / JS リゾルバーで
              DynamoDB API を直接呼び出し

Lambda 関数を挟まないため、コールドスタートの待ちも Lambda の実行料金も発生しない。単純な CRUD ほどこの構成の利点が出るが、どれだけ速くなるかは項目サイズとクエリの形に左右されるので、実際の差は自分のワークロードで測る。

認可モードの多層化

AppSync の認可方式は API キー、Lambda、IAM、OpenID Connect、Cognito ユーザープールの 5 種類で、1 つの API に既定の方式と追加の方式を組み合わせて設定できる。パブリックなクエリは API キー、ユーザー固有のデータは Cognito ユーザープール、管理操作は IAM、という振り分けは、スキーマのフィールドにディレクティブ (@aws_api_key、@aws_cognito_user_pools、@aws_iam、@aws_oidc) を付けて表現する。

組み合わせには制約がある。API キー、Lambda、IAM は既定の方式と追加の方式で重複して指定できない (Cognito ユーザープールと OpenID Connect は複数のプロバイダーを並べられる)。また API キーは開発中か、公開しても差し支えない API に限って使うものと位置付けられており、ユーザーごとのアクセス制御には向かない。

GraphQL 自体の考え方は GraphQL、購読の仕組みは GraphQL サブスクリプション、データソース側の設計は DynamoDB と Cognito をあわせて読むと、AppSync に任せられる範囲と自分で設計すべき範囲の境目が見えてくる。