CloudFormationで構成するAWS AppSync 2025年版 - Event APIとJavaScriptランタイムがもたらす新たな可能性

最終更新日：2025年08月26日｜公開日：2025年08月14日

writer：益子竜与志

AWS AppSyncがCloudFormationで構成可能なリソースタイプを7つから12種類に拡充し、開発者にとって格段に扱いやすくなりました。

特に2024年10月に発表された「AppSync Events」によるWebSocketベースのリアルタイム通信機能と、JavaScriptランタイムの正式対応は、これまでVTL（Velocity Template Language）で苦労していたエンジニアたちに新しい選択肢を提供しています。本記事では、2025年8月時点の最新機能を踏まえ、実践的なCloudFormation構成を解説します。

CloudFormationで構成するAWS AppSync - 12種類のリソースが実現する新たな可能性

AppSyncリソースタイプの現状と拡充内容

CloudFormationがサポートするAppSyncリソースは現在12種類まで拡充されました。2021年時点の7種類から約1.7倍に増加した背景には、エンタープライズ企業のプロダクション利用が急速に進んだことがあります。

新たに追加された5つのリソースを見てみると、いずれも実務で直面する課題を解決するものばかりです。

現在利用可能なリソースタイプの一覧は以下の通りです。

AWS::AppSync::Api（Event API用・新規）
AWS::AppSync::ApiCache
AWS::AppSync::ApiKey
AWS::AppSync::ChannelNamespace（Event API用・新規）
AWS::AppSync::DataSource
AWS::AppSync::DomainName（カスタムドメイン用・新規）
AWS::AppSync::DomainNameApiAssociation（カスタムドメイン用・新規）
AWS::AppSync::FunctionConfiguration
AWS::AppSync::GraphQLApi
AWS::AppSync::GraphQLSchema
AWS::AppSync::Resolver
AWS::AppSync::SourceApiAssociation（マージドAPI用・新規）

これらのリソースタイプの進化を追うことで、AWSがAppSyncをどのような方向に進化させようとしているかが見えてきます。特に「Event API」の追加は、GraphQLだけでなくWebSocketベースのリアルタイム通信という新しい選択肢を提供している点で注目に値します。

既存リソースの大幅アップデート

ApiCacheの進化と最適化戦略

AWS::AppSync::ApiCacheに「OPERATION_LEVEL_CACHING」が追加されたことで、キャッシュ戦略の選択肢が広がりました。

Resources:
  ApiCache:
    Type: AWS::AppSync::ApiCache
    Properties:
      ApiCachingBehavior: OPERATION_LEVEL_CACHING  # 新たに追加された動作モード
      ApiId: !GetAtt GraphQLApi.ApiId
      Ttl: 3600  # 1時間のキャッシュ（実装に応じて調整）
      Type: LARGE  # T2_SMALL, T2_MEDIUM, SMALL, MEDIUM, LARGE, XLARGE, LARGE_2X等から選択

「AtRestEncryptionEnabled」と「TransitEncryptionEnabled」のプロパティが非推奨となったのは、AWSがセキュリティをデフォルトで有効にする方針に移行したためです。この変更は「Security by Default」という業界のトレンドを反映しており、開発者が意識せずとも安全な構成になるよう配慮されています。

実務では、キャッシュ戦略を以下のように使い分けることが推奨されます。

FULL_REQUEST_CACHING：マスターデータなど更新頻度の低いクエリ
PER_RESOLVER_CACHING：特定のリゾルバーのみキャッシュしたい場合
OPERATION_LEVEL_CACHING：オペレーション単位で細かくキャッシュ制御したい場合

JavaScriptランタイムによるリゾルバー記述の革新

VTLに加えてJavaScript（APPSYNC_JS）でリゾルバーを記述できるようになったことは、開発者体験を大きく向上させました。

Resources:
  UserResolver:
    Type: AWS::AppSync::Resolver
    Properties:
      ApiId: !GetAtt GraphQLApi.ApiId
      TypeName: "Query"
      FieldName: "getUser"
      Kind: UNIT
      DataSourceName: !GetAtt UserDataSource.Name
      Runtime:
        Name: APPSYNC_JS
        RuntimeVersion: "1.0.0"
      Code: |
        import * as ddb from '@aws-appsync/utils/dynamodb';

        export function request(ctx) {
          return ddb.get({
            key: {
              id: ctx.args.id
            },
            consistentRead: true
          });
        }

        export function response(ctx) {
          if (ctx.error) {
            ctx.util.error(ctx.error.message, ctx.error.type);
          }
          return ctx.result;
        }

JavaScriptランタイムの採用により、以下のメリットが得られます。

TypeScriptの型定義を活用した開発が可能
エディタのインテリセンスが効く
ユニットテストが書きやすい
VTL特有の記法を覚える必要がない

ただし、既存のVTLテンプレートからの移行は慎重に行う必要があります。パフォーマンスへの影響を測定しながら、段階的に移行することをお勧めします。

データソースの拡充とその活用方法

データソースタイプにEventBridgeとBedrock Runtimeが追加されたことで、AppSyncの適用範囲が大きく広がりました。

EventBridge統合の実装例

Resources:
  EventBridgeDataSource:
    Type: AWS::AppSync::DataSource
    Properties:
      ApiId: !GetAtt GraphQLApi.ApiId
      Name: EventBridgeSource
      Type: AMAZON_EVENTBRIDGE
      ServiceRoleArn: !GetAtt EventBridgeRole.Arn
      EventBridgeConfig:
        EventBusArn: !GetAtt CustomEventBus.Arn

EventBridge統合により、イベント駆動アーキテクチャとGraphQLを組み合わせた実装が容易になります。例えば、GraphQL Mutationから直接EventBridgeにイベントを発行し、複数のマイクロサービスに処理を委譲するパターンが実現可能です。

Bedrock Runtime統合による生成AI活用

Resources:
  BedrockDataSource:
    Type: AWS::AppSync::DataSource
    Properties:
      ApiId: !GetAtt GraphQLApi.ApiId
      Name: BedrockSource
      Type: AMAZON_BEDROCK_RUNTIME
      ServiceRoleArn: !GetAtt BedrockRole.Arn

Bedrock Runtimeとの統合により、GraphQLから直接LLMを呼び出せるようになりました。ただし、同期処理で10秒以内というタイムアウト制限があるため、複雑なプロンプトや大量のテキスト生成には向きません。

実務では、以下のようなユースケースに適しています。

商品説明の自動生成（100文字程度）
カテゴリ分類の自動判定
簡単な要約生成

より複雑な処理が必要な場合は、Lambda経由での非同期処理を検討すべきです。

Event API - リアルタイム通信の新たな選択肢

Event APIの概要と特徴

2024年10月に発表されたAppSync Eventsは、WebSocketベースのPub/Sub機能を提供する新しいAPIタイプです。

Resources:
  EventApi:
    Type: AWS::AppSync::Api
    Properties:
      Name: RealtimeEventApi
      EventConfig:
        ConnectionAuthModes:
          - AuthType: API_KEY
        DefaultPublishAuthModes:
          - AuthType: API_KEY
        DefaultSubscribeAuthModes:
          - AuthType: API_KEY

  EventNamespace:
    Type: AWS::AppSync::ChannelNamespace
    Properties:
      ApiId: !Ref EventApi
      Name: chat
      PublishAuthModes:
        - AuthType: API_KEY
      SubscribeAuthModes:
        - AuthType: API_KEY
      CodeHandlers: |
        export function onPublish(ctx) {
          // メッセージのバリデーションやフィルタリング
          if (ctx.event.message.length > 1000) {
            util.error("Message too long", "ValidationError");
          }
          return ctx.event;
        }

        export function onSubscribe(ctx) {
          // 購読時の認可チェック
          return {
            filterExpression: {
              userId: { eq: ctx.identity.userId }
            }
          };
        }

Event APIは、従来のGraphQL Subscriptionと比較して以下の利点があります。

スケーラビリティが大幅に向上（数百万接続をサポート）
レイテンシが低減（50ms以下を実現）
メッセージフィルタリングが効率的

ただし、GraphQLのような型安全性は提供されないため、用途に応じて使い分ける必要があります。リアルタイムチャット、ライブダッシュボード、IoTデータストリーミングなど、高スループットが求められる場面では Event API が適しています。

Event APIとGraphQLの使い分け戦略

実際のプロダクション環境では、Event APIとGraphQL APIを組み合わせて使用することが多くなるでしょう。以下の表は、それぞれの特性と適用場面をまとめたものです。

表 Event APIとGraphQL APIの特性比較

特性	Event API	GraphQL API
リアルタイム性	非常に高い（50ms以下）	中程度（100-200ms）
スケーラビリティ	数百万接続対応	数万接続程度
型安全性	なし（JSON Schema検証は可能）	完全な型安全性
開発効率	シンプルなPub/Sub向け	複雑なデータ取得向け
キャッシュ	なし	複数レベルで対応
料金体系	メッセージ数ベース	リクエスト数ベース

この比較から、リアルタイムイベントの配信にはEvent API、構造化データの取得や更新にはGraphQL APIという使い分けが最適です。

カスタムドメインとマージドAPIによる運用の高度化

カスタムドメインの実装

DomainNameリソースとDomainNameApiAssociationリソースにより、独自ドメインでのAPI公開が可能になりました。

Resources:
  CustomDomain:
    Type: AWS::AppSync::DomainName
    Properties:
      DomainName: api.example.com
      CertificateArn: !Ref ACMCertificate
      Description: Production API Domain

  DomainAssociation:
    Type: AWS::AppSync::DomainNameApiAssociation
    Properties:
      ApiId: !GetAtt GraphQLApi.ApiId
      DomainName: !Ref CustomDomain

カスタムドメインの導入により、以下のメリットが得られます。

APIエンドポイントの変更時もクライアント側の修正が不要
複数環境（dev/stg/prod）の統一的な管理
WAFやCloudFrontとの統合が容易

マージドAPIによるマイクロサービス統合

SourceApiAssociationリソースを使用することで、複数のGraphQL APIを単一エンドポイントに統合できます。

Resources:
  MergedApiAssociation:
    Type: AWS::AppSync::SourceApiAssociation
    Properties:
      MergedApiId: !Ref MergedApi
      SourceApiId: !Ref UserServiceApi
      SourceApiAssociationConfig:
        MergeType: AUTO_MERGE

マージドAPIは、マイクロサービスアーキテクチャにおいて各サービスが独自のGraphQL APIを持ちながら、クライアントには統一されたAPIを提供したい場合に有効です。ただし、スキーマの競合解決やパフォーマンスへの影響を慎重に検討する必要があります。

認証・認可の進化と実装パターン

Lambda認証の活用

5つの認証タイプ（API_KEY、AWS_LAMBDA、AWS_IAM、OPENID_CONNECT、AMAZON_COGNITO_USER_POOLS）が利用可能になり、特にLambda認証の追加により柔軟な認証ロジックの実装が可能になりました。

Resources:
  GraphQLApi:
    Type: AWS::AppSync::GraphQLApi
    Properties:
      Name: SecureApi
      AuthenticationType: AWS_LAMBDA
      LambdaAuthorizerConfig:
        AuthorizerUri: !GetAtt AuthorizerFunction.Arn
        AuthorizerResultTtlInSeconds: 300
        IdentityValidationExpression: ".*"
      AdditionalAuthenticationProviders:
        - AuthenticationType: API_KEY
        - AuthenticationType: AWS_IAM

Lambda認証を使用することで、以下のような高度な認証パターンが実装可能です。

JWTトークンのカスタム検証
IPアドレスベースのアクセス制限
時間帯による利用制限
外部IDプロバイダーとの連携

複数の認証タイプを組み合わせることで、パブリックAPIとプライベートAPIを同一のエンドポイントで提供する設計も可能になります。

認証戦略の選定指針

実装する認証タイプの選定は、セキュリティ要件とユーザビリティのバランスを考慮して決定すべきです。以下の指針を参考にしてください。

開発・検証環境では「API_KEY」を使用し、迅速な開発を優先します。内部システム間の通信には「AWS_IAM」を採用し、AWS の認証機構を活用します。B2Cサービスでは「AMAZON_COGNITO_USER_POOLS」を使用し、ユーザー管理機能を統合します。既存の認証基盤がある場合は「OPENID_CONNECT」や「AWS_LAMBDA」を検討します。

実装時の最適化とベストプラクティス

パフォーマンス最適化の実践

AppSyncのパフォーマンスを最大化するには、以下の観点での最適化が重要です。

表 AppSyncパフォーマンス最適化チェックリスト

最適化項目	推奨設定	効果	実装難易度
キャッシュ戦略	OPERATION_LEVEL_CACHING	レスポンス時間50%削減	低
バッチ処理	MaxBatchSize: 2000	DynamoDB読み取り効率10倍	中
データローダー	パイプラインリゾルバー活用	N+1問題の解消	高
並列実行	Promise.all()の活用	処理時間30%削減	低
コネクションプーリング	RDSプロキシ使用	DB接続オーバーヘッド削減	中

特にキャッシュ戦略は即効性が高く、実装も容易なため、まず最初に取り組むべき最適化項目です。

監視とトラブルシューティング

Enhanced Metricsを有効化することで、詳細なメトリクスをCloudWatchで確認できます。

Resources:
  GraphQLApi:
    Type: AWS::AppSync::GraphQLApi
    Properties:
      Name: MonitoredApi
      XrayEnabled: true
      EnhancedMetricsConfig:
        ResolverLevelMetricsBehavior: ENABLED
        DataSourceLevelMetricsBehavior: ENABLED
        OperationLevelMetricsConfig: ENABLED

これにより、以下のメトリクスが取得可能になります。

リゾルバーごとの実行時間とエラー率
データソースごとのレイテンシ
オペレーションレベルでのキャッシュヒット率

実務では、これらのメトリクスを基にアラートを設定し、プロアクティブな監視体制を構築することが重要です。

移行戦略と段階的アップグレード

既存システムからの移行アプローチ

2021年頃のAppSync構成から最新版への移行は、段階的に行うことを推奨します。以下の移行順序が実践的です。

認証機構の更新：Lambda認証への移行で柔軟性を確保
JavaScriptランタイムへの移行：保守性の高いコードベースへ
データソースの拡充：EventBridge/Bedrock統合の検討
Event APIの導入：リアルタイム要件がある部分から段階的に
カスタムドメインの設定：最後に外部公開用の設定

各段階で十分なテストを行い、パフォーマンスへの影響を測定しながら進めることが成功の鍵です。

非推奨機能への対応

既存のCloudFormationテンプレートで「AtRestEncryptionEnabled」や「TransitEncryptionEnabled」を使用している場合、これらは非推奨となっているため、削除する必要があります。

# 旧設定（非推奨）
ApiCache:
  Type: AWS::AppSync::ApiCache
  Properties:
    AtRestEncryptionEnabled: true  # 削除
    TransitEncryptionEnabled: true  # 削除

# 新設定
ApiCache:
  Type: AWS::AppSync::ApiCache
  Properties:
    ApiCachingBehavior: OPERATION_LEVEL_CACHING
    # 暗号化はデフォルトで有効

コスト最適化の実践

料金体系の理解と最適化

AppSyncの料金は複数の要素から構成されており、それぞれに最適化の余地があります。

表 AppSyncコスト最適化の実践方法

コスト要素	最適化方法	期待削減率	実装優先度
クエリ/Mutation実行	キャッシュの活用	40-60%	高
リアルタイム接続	Event API への移行検討	20-30%	中
データ転送	レスポンスサイズの最適化	10-20%	低
キャッシュストレージ	適切なインスタンスサイズ選択	15-25%	中
CloudWatch Logs	ログレベルの調整	30-40%	高

特にキャッシュの活用は、コスト削減とパフォーマンス向上の両方に寄与するため、積極的に活用すべきです。

Reserved Capacityの活用

安定した利用が見込まれる場合、Reserved Capacityを購入することで最大50%のコスト削減が可能です。ただし、Event APIには現時点でReserved Capacityが提供されていないため、GraphQL APIのみが対象となります。

実装サンプル - モダンなAppSync構成

最新機能を活用した実装サンプルを示します。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Modern AppSync Configuration 2025'

Resources:
  # メインのGraphQL API
  MainGraphQLApi:
    Type: AWS::AppSync::GraphQLApi
    Properties:
      Name: ModernAppSyncApi
      AuthenticationType: AWS_LAMBDA
      LambdaAuthorizerConfig:
        AuthorizerUri: !GetAtt AuthLambda.Arn
        AuthorizerResultTtlInSeconds: 300
      AdditionalAuthenticationProviders:
        - AuthenticationType: API_KEY
        - AuthenticationType: AWS_IAM
      XrayEnabled: true
      EnhancedMetricsConfig:
        ResolverLevelMetricsBehavior: ENABLED
        DataSourceLevelMetricsBehavior: ENABLED

  # Event API for リアルタイム通信
  RealtimeEventApi:
    Type: AWS::AppSync::Api
    Properties:
      Name: RealtimeEvents
      EventConfig:
        ConnectionAuthModes:
          - AuthType: API_KEY
        DefaultPublishAuthModes:
          - AuthType: API_KEY
        DefaultSubscribeAuthModes:
          - AuthType: API_KEY

  # JavaScript リゾルバー with DynamoDB
  ModernResolver:
    Type: AWS::AppSync::Resolver
    Properties:
      ApiId: !GetAtt MainGraphQLApi.ApiId
      TypeName: Query
      FieldName: getItems
      Kind: PIPELINE
      Runtime:
        Name: APPSYNC_JS
        RuntimeVersion: "1.0.0"
      Code: |
        export function request(ctx) {
          return {};
        }
        export function response(ctx) {
          return ctx.prev.result;
        }
      PipelineConfig:
        Functions:
          - !GetAtt GetItemFunction.FunctionId
          - !GetAtt EnrichFunction.FunctionId

  # Bedrock データソース
  BedrockDataSource:
    Type: AWS::AppSync::DataSource
    Properties:
      ApiId: !GetAtt MainGraphQLApi.ApiId
      Name: BedrockAI
      Type: AMAZON_BEDROCK_RUNTIME
      ServiceRoleArn: !GetAtt BedrockRole.Arn

  # EventBridge データソース
  EventBridgeDataSource:
    Type: AWS::AppSync::DataSource
    Properties:
      ApiId: !GetAtt MainGraphQLApi.ApiId
      Name: EventBus
      Type: AMAZON_EVENTBRIDGE
      ServiceRoleArn: !GetAtt EventBridgeRole.Arn
      EventBridgeConfig:
        EventBusArn: !GetAtt CustomEventBus.Arn

  # 最適化されたキャッシュ設定
  OptimizedCache:
    Type: AWS::AppSync::ApiCache
    Properties:
      ApiId: !GetAtt MainGraphQLApi.ApiId
      ApiCachingBehavior: OPERATION_LEVEL_CACHING
      Ttl: 3600
      Type: LARGE

  # カスタムドメイン
  CustomDomain:
    Type: AWS::AppSync::DomainName
    Properties:
      DomainName: api.example.com
      CertificateArn: !Ref ACMCertificate

  DomainAssociation:
    Type: AWS::AppSync::DomainNameApiAssociation
    Properties:
      ApiId: !GetAtt MainGraphQLApi.ApiId
      DomainName: !Ref CustomDomain

まとめと今後の展望

AWS AppSyncは、2021年から2025年にかけて大きく進化しました。リソースタイプが7つから12種類に増加し、JavaScriptランタイムのサポート、Event APIの追加、そしてEventBridgeやBedrockとの統合により、適用可能な範囲が大幅に広がっています。

これらの進化は単なる機能追加ではなく、開発者体験の向上とエンタープライズ要件への対応を両立させた戦略的なものです。特にJavaScriptランタイムの採用は、VTLという独自言語の学習コストを削減し、多くの開発者にとってAppSyncをより身近なものにしました。

今後は、生成AIとの統合がさらに進化し、GraphQLスキーマの自動生成やリゾルバーの最適化提案など、開発生産性をさらに向上させる機能が追加されることが予想されます。また、Event APIの機能拡充により、IoTやリアルタイムコラボレーションツールなど、新たなユースケースでの活用も期待できます。

CloudFormationを使用したIaCによる管理は、これらの進化に追従しながら、安定した運用を実現するための重要な要素です。本記事で紹介した最新機能を活用し、より効率的で保守性の高いAppSync環境を構築していただければ幸いです。

この記事を書いた人

ソリューションアーキテクト益子竜与志

複数のITベンチャーで技術責任者／経営企画を歴任し、事業戦略とプロダクト成長を主導。2017年にRagate株式会社を創業し、サーバーレス技術の黎明期よりAWS・サーバーレス開発プロジェクトを牽引し、AWS Top Engineers 2024 ( Service ) ・AWS Rising Star Partners of the Year – Japan賞を受賞。経営課題/戦略を起点としたDX戦略策定とクラウドシステムデリバリを強みに、SMB市場を中心に数多くの企業変革を支援。GLOBIS経営大学院MBAで培った経営戦略・マーケティングミックスの知見と、AWS／先端技術の深い専門性を掛け合わせ、価値創出を加速させている。

【保有資格・認定】