Cloud Service
Amazon AppFlow
Salesforce などの SaaS と AWS の間でデータをノーコードで安全に連携・転送するフルマネージドな統合サービス。
基礎DEA-C01運用上の優秀性
最終更新: 2026-06-13公式ドキュメント ↗
TL;DR要点だけ先に
- 1.SaaS と AWS のデータ連携を画面操作だけで作れるマネージドサービス。
- 2.コネクタ・フロー・トリガで転送を定義し、変換やフィルタも可能。
- 3.通信は暗号化され PrivateLink にも対応するため安全に転送できる。
解決する課題
- SaaS(Salesforce、ServiceNow、Slack など)と AWS の間でデータを連携したいが、API 連携のコードを書きたくない
- データ転送のたびに認証・ページング・リトライ・スロットリングを自前で実装するのが負担
- SaaS から取り込んだデータを S3 や Redshift に集約し、分析や機械学習に使いたい
- 連携処理を**安全に(インターネットに出さず)**実行したい
主要概念と用語
- フロー: 送信元から送信先へのデータ転送の単位。GUI で定義する設定
- コネクタ: SaaS や AWS サービスへの接続定義。SaaS 側は OAuth などで認証する
- 送信元 / 送信先: 転送の起点と終点。片方は SaaS、もう片方は AWS(S3、Redshift など)が一般的
- トリガ: フローの実行契機。手動 / スケジュール / イベント駆動の方式がある
- マッピング: 送信元フィールドと送信先フィールドの対応付け
- 変換・フィルタ: 転送中の値の加工や、条件に合うレコードだけを通す絞り込み
- コネクタプロファイル: 接続先ごとの認証情報をまとめた再利用可能な設定
仕様・制限・クォータ
- 多数の SaaS アプリケーション向けのビルトインコネクタを提供
- 1 回の転送でのレコード数やフロー数などにサービスクォータがあり、必要に応じて引き上げ申請が可能
- 送信先として Amazon S3 や Amazon Redshift などを選択でき、S3 ではファイル形式や集約方法を指定できる
- スケジュール実行の最短間隔やレコードサイズなど、具体的な数値は更新され得るため最新の公式ドキュメントで確認する
内部の仕組み
AppFlow はユーザーが GUI で定義したフローに従い、送信元コネクタを通じて SaaS の API を呼び出してデータを取得し、必要に応じてフィールドマッピング・変換・フィルタを適用したうえで送信先へ書き込みます。認証情報はコネクタプロファイルとして安全に保持され、API のページングやリトライといった煩雑な処理はサービス側が肩代わりするため、利用者はコードを書く必要がありません。
トリガは三方式あり、手動(オンデマンド実行)、スケジュール(一定間隔の定期実行)、イベント駆動(SaaS 側の変更イベントを契機とするほぼリアルタイムな転送)から選びます。転送はフルマネージドにスケールし、運用者がサーバを管理する必要はありません。
ノーコードが要点
AppFlow の本質は「SaaS と AWS の連携をコードなしで作れる」ことです。Lambda などで API 連携を自作する場合と比べ、認証・ページング・リトライの実装を肩代わりしてくれる点が価値になります。
設計パターン / ベストプラクティス
- SaaS のデータを S3 に集約し、分析基盤(Athena、Redshift、QuickSight など)の入力にする
- 大量データはスケジュール転送+差分取得で負荷とコストを抑える
- 重要な業務イベントはイベント駆動トリガでほぼリアルタイムに反映する
- 転送中にフィルタで不要レコードを除外し、変換でフォーマットを整えることで後段の処理を簡素化する
- 認証情報はコネクタプロファイルとして再利用し、各フローへ散らさない
運用・監視
- 各フローの実行履歴で成功・失敗や転送レコード数を確認する
- 実行イベントは CloudWatch や CloudTrail と連携して監視・監査できる
- 失敗時は SaaS 側のスロットリングや認証期限切れ、マッピング不整合を確認する
- スケジュール転送では実行間隔と SaaS API の制限のバランスに注意する
コスト
- 課金は主に実行したフローの回数と処理したデータ量に基づく
- 自作の連携基盤(サーバや Lambda の運用)と比べ、運用負荷を含めた総コストで評価する
- 不要に短い間隔のスケジュール実行は実行回数を増やすため、要件に見合う間隔にする
- 具体的な料金は変動するため、見積もりは公式の料金ページで確認する
セキュリティ
- 転送データは通信経路で暗号化され、保存時の暗号化には KMS を利用できる
- AWS PrivateLink に対応するコネクタでは、トラフィックをインターネットに出さずプライベートに転送できる
- SaaS への認証は OAuth などを用い、認証情報はサービスが安全に管理する
- アクセスは IAM で制御し、最小権限で運用する
Well-Architected の観点
- 運用上の優秀性: ノーコードでフローを定義でき、認証・リトライ・スケーリングをマネージドに任せられるため運用負荷が下がる
- セキュリティ: 暗号化と PrivateLink により安全な連携を実現できる
試験で問われるポイント
頻出
- SaaS と AWS のデータ連携をノーコードで行いたい要件=AppFlow
- Salesforce などのデータを S3 / Redshift に取り込む典型シナリオ
- トリガは手動・スケジュール・イベント駆動の 3 方式
- 安全な転送には暗号化と PrivateLinkが使える
関連サービス・比較
| 観点 | AppFlow | Glue |
|---|---|---|
| 主目的 | 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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。