クラウドサービス

Amazon AppFlow

Salesforce などの SaaS と AWS の間を、コードを書かずにつないでデータを安全に転送。連携処理を自前で作り込む手間を省く、Amazon AppFlow のフルマネージド統合サービス。

基礎DEA-C01運用上の優秀性
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. SaaS と AWS 間のデータ転送をコードなしで定義する。
  2. 取得、絞り込み、変換、書き込みをフローとして実行する。
  3. 再実行時の重複とスキーマ変更は利用側で管理する。

解決する課題

  • SaaS(Salesforce、ServiceNow、Slack など)と AWS の間でデータを連携したいが、API 連携のコードを書きたくない
  • データ転送のたびに認証・ページング・リトライ・スロットリングを自前で実装するのが負担
  • SaaS から取り込んだデータを S3 や Redshift に集約し、分析や機械学習に使いたい
  • 連携処理を安全に(インターネットに出さず)実行したい

主要概念と用語

  • フロー: 送信元から送信先へのデータ転送の単位。GUI で定義する設定
  • コネクタ: SaaS や AWS サービスへの接続定義。SaaS 側は OAuth などで認証する
  • 送信元 / 送信先: 転送の起点と終点。片方は SaaS、もう片方は AWS(S3、Redshift など)が一般的
  • トリガー: フローの実行契機。手動 / スケジュール / イベント駆動の方式がある
  • マッピング: 送信元フィールドと送信先フィールドの対応付け
  • 変換・フィルタ: 転送中の値の加工や、条件に合うレコードだけを通す絞り込み
  • コネクタプロファイル: 接続先ごとの認証情報をまとめた再利用可能な設定

仕様・制限・クォータ

  • 50 を超える SaaS アプリケーション向けのビルトインコネクタを提供
  • 1 アカウントあたり 1,000 フロー、同時実行 1,000、月間 1,000 万回が既定上限
  • 送信先として Amazon S3Amazon Redshift などを選択でき、S3 ではファイル形式や集約方法を指定できる
  • 1 回の実行は最長 48 時間。スケジュールは最短 1 分だが、コネクタ固有の制限が優先される

内部の仕組み

横にスクロール

手動、スケジュール、業務イベントを契機に、コネクタプロファイルでSaaS APIへ接続し、差分取得、絞り込み、変換、検証を経てS3などへ書き込む経路と、認証失効、API制限、スキーマ変更、再実行時の重複を示す図
AppFlow は転送処理を管理します。取得範囲と再実行時の重複排除は利用側の設計です。

AppFlow はユーザーが GUI で定義したフローに従い、送信元コネクタを通じて SaaS の API を呼び出してデータを取得し、必要に応じてフィールドマッピング・変換・フィルタを適用したうえで送信先へ書き込みます。認証情報はコネクタプロファイルとして安全に保持され、API のページングやリトライといった煩雑な処理はサービス側が肩代わりするため、利用者はコードを書く必要がありません。

トリガーは三方式あり、手動(オンデマンド実行)、スケジュール(一定間隔の定期実行)、イベント駆動(SaaS 側の変更イベントを契機とするほぼリアルタイムな転送)から選びます。転送はフルマネージドにスケールし、運用者がサーバーを管理する必要はありません。

実行単位の再試行や手動再実行では、追記型の送信先に同じレコードが重複する可能性があります。差分取得の基準列を固定し、業務キーで上書きまたは重複排除できる着地方式にします。SaaS 側のスキーマ変更と API 制限も利用者が監視します。

ノーコードが要点

AppFlow の本質は「SaaS と AWS の連携をコードなしで作れる」ことです。Lambda などで API 連携を自作する場合と比べ、認証・ページング・リトライの実装を肩代わりしてくれる点が価値になります。

設計パターン / ベストプラクティス

  • SaaS のデータを S3 に集約し、分析基盤(Athena、Redshift、QuickSight など)の入力にする
  • 大量データはスケジュール転送+差分取得で負荷とコストを抑える
  • 重要な業務イベントはイベント駆動トリガーでほぼリアルタイムに反映する
  • 転送中にフィルタで不要レコードを除外し、変換でフォーマットを整えることで後段の処理を簡素化する
  • 認証情報はコネクタプロファイルとして再利用し、各フローへ散らさない

運用・監視

  • 各フローの実行履歴で成功・失敗や転送レコード数を確認する
  • 実行イベントは CloudWatchCloudTrail と連携して監視・監査できる
  • 失敗時は SaaS 側のスロットリングや認証期限切れ、マッピング不整合を確認する
  • スケジュール転送では実行間隔と SaaS API の制限のバランスに注意する

コスト

  • 課金は成功したフロー実行回数処理データ量に基づく。新規データがなくても確認実行は回数に含まれる
  • 自作の連携基盤(サーバーや Lambda の運用)と比べ、運用負荷を含めた総コストで評価する
  • 不要に短い間隔のスケジュール実行は実行回数を増やすため、要件に見合う間隔にする
  • 具体的な料金は変動するため、見積もりは公式の料金ページで確認する

セキュリティ

  • 転送データは通信経路で暗号化され、保存時の暗号化には KMS を利用できる
  • AWS PrivateLink に対応するコネクタに限り、トラフィックをインターネットに出さず転送できる
  • SaaS への認証は OAuth などを用い、認証情報はサービスが安全に管理する
  • アクセスは IAM で制御し、最小権限で運用する

Well-Architected の観点

  • 運用上の優秀性: ノーコードでフローを定義でき、認証・リトライ・スケーリングをマネージドに任せられるため運用負荷が下がる
  • セキュリティ: 暗号化と PrivateLink により安全な連携を実現できる

試験で問われるポイント

頻出
  • SaaS と AWS のデータ連携をノーコードで行いたい要件=AppFlow
  • Salesforce などのデータを S3 / Redshift に取り込む典型シナリオ
  • トリガーは手動・スケジュール・イベント駆動の 3 方式
  • 安全な転送には暗号化と PrivateLinkが使える

関連サービス・比較

観点AppFlowGlue
主目的SaaS と AWS のデータ連携ETL とデータ統合
接続先SaaS アプリ中心データストア中心
実装方法ノーコードの GUIスクリプトやジョブ定義
強みSaaS 認証や API を肩代わり大規模な変換とカタログ管理

ハンズオン / CLI例

# 定義済みのフローをオンデマンドで実行する
aws appflow start-flow --flow-name salesforce-to-s3

# フローの一覧と概要を確認する
aws appflow list-flows

# 特定フローの設定や直近の実行状況を確認する
aws appflow describe-flow --flow-name salesforce-to-s3

AWS Service

Amazon AppFlowを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

アプリ統合

比較で見る軸

クラウド: AWS / カテゴリ: アプリ統合 / 難易度: basic

導入後に効く点

取得、絞り込み、変換、書き込みをフローとして実行する。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
AWS
カテゴリ
アプリ統合
難易度
basic
関連資格
DEA-C01
設計柱
operational

判断チェックリスト

  • 自社の用途が「アプリ統合 / operational」に近いか確認する。
  • 強みである「SaaS と AWS 間のデータ転送をコードなしで定義する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

アプリ統合operationalDEA-C01