AWS-SAA(アプリケーション統合)

AppFlow¶

1. サービス概要¶

Amazon AppFlow は、AWS が提供するフルマネージドの統合サービスで、Software as a Service（SaaS）アプリケーションと AWS サービス間で、安全かつ双方向にデータ転送を自動化する。
これにより、開発者はデータのサイロ化を解消し、ビジネスアプリケーションに必要なデータを迅速かつ簡単に利用できるようになる。 AppFlow は、データ転送の複雑さを抽象化し、データパイプラインの構築と管理を簡素化する。

主なユースケースとして、

SaaS アプリケーションのデータバックアップ（Salesforce のデータを S3 に保存）、
データレイクへのデータ投入（Marketo のデータを Amazon Redshift にロード）、
データ同期（Google Analytics のデータを Amazon S3 に同期）
ビジネスアプリケーション統合（Zendesk のデータを Salesforce に同期）

などが挙げられる。

2. 主な特徴と機能¶

2.1 広範なデータソースのサポート¶

Amazon AppFlow は、Salesforce、Marketo、Google Analytics、Zendesk、Snowflake、ServiceNow など、多数の SaaS アプリケーションや AWS サービスをデータソースとしてサポートしている。
これにより、異なるシステム間でデータをシームレスに転送できる。

SaaS アプリケーション: Salesforce, Marketo, Google Analytics, Zendesk, ServiceNow など。
AWS サービス: Amazon S3, Amazon Redshift, Amazon SQS, Amazon EventBridge など。
データベース: Snowflake など。

2.2 双方向データ転送¶

AppFlow は、ソースからターゲットへの一方通行のデータ転送だけでなく、ターゲットからソースへの双方向のデータ転送もサポートしている。
これにより、データの同期や統合を柔軟に行うことができる。

2.3 データ変換とマッピング¶

データ転送中に、データのフィルタリング、変換、マッピングなどの処理を行うことができる。
不要なデータの除外、データ形式の変換、カラムのマッピングなどを定義できる。

データフィルタリング: 特定の条件に合致するデータのみを転送。
データ変換: データ型変換、文字列操作、関数適用。
カラムマッピング: ソースとターゲットのカラムを対応付け。

2.4 スケジュール実行とイベント駆動¶

データ転送をスケジュールに基づいて定期的に実行したり、イベントをトリガーとして実行したりすることができる。
リアルタイムデータ転送やバッチ処理に対応できる。

スケジュール実行: 時間間隔、時間帯、曜日などを設定して定期的に実行。
イベント駆動: Amazon EventBridge イベントをトリガーとして実行。

2.5 フルマネージドサービス¶

インフラの管理やスケーリングは AWS が自動で行うため、ユーザーはデータの転送設定に集中できる。
サーバーレスで可用性の高い環境でデータ転送が可能。

2.6 セキュリティとコンプライアンス¶

AppFlow は、データの暗号化、アクセス制御、コンプライアンス認証に対応し、安全なデータ転送を保証する。
IAM によるアクセス制御、転送中のデータ暗号化、保存中のデータ暗号化をサポートしている。

IAM 連携: AWS IAM を使用してアクセス制御と権限管理。
データ暗号化: 転送中および保存中のデータを暗号化。
コンプライアンス認証: SOC、PCI DSS、HIPAA などに対応。

2.7 統合性と拡張性¶

AWS の他のサービス（Amazon S3、Amazon Redshift、Amazon EventBridge など）と連携することで、柔軟なデータパイプラインを構築できる。
AWS Lambda と連携してカスタム変換処理を追加できる。

3. アーキテクチャおよび技術要素¶

ユーザーは AppFlow コンソールまたは API でデータフローを定義。
AppFlow は、定義されたデータソースからデータを抽出。
必要に応じて、データ変換やマッピングを実行。
データをターゲットに転送。
データ転送のスケジュールやイベントトリガーを管理。

AppFlow は、フルマネージドサービスとして提供され、可用性、スケーラビリティ、セキュリティが内包されている。
データ転送の複雑さを抽象化し、データパイプラインの構築と管理を簡素化する。

4. セキュリティと認証・認可¶

セキュリティは AppFlow の重要な要素:

IAM によるアクセス制御: AWS IAM を利用して、AppFlow リソースへのアクセスを制御。
データ暗号化: 転送中および保存中のデータを暗号化し、データの機密性を保護。
VPC サポート: Amazon VPC 内で AppFlow を使用する場合、プライベート接続を確立。
認証情報の管理: AWS Secrets Manager を使用して、データソースの認証情報を安全に管理。
監査ログ: AWS CloudTrail を使用して、API 呼び出しやリソース変更を記録。

これにより、データの安全性とコンプライアンスを確保できる。

5. 料金形態¶

Amazon AppFlow の料金は主に以下に基づく:

データ処理量: 転送・処理されるデータ量に応じた従量課金。
データコネクタ: 特定のデータコネクタの使用料。
追加機能: 特定の追加機能（プライベートリンクなど）の利用料。

6. よくあるアーキテクチャ・設計パターン¶

一般的なパターンは以下の通り:

SaaS データバックアップ: Salesforce などの SaaS アプリケーションのデータを S3 に定期的にバックアップ。
データレイク構築: Marketo、Google Analytics などのデータを S3 に集約し、データレイクを構築。
データウェアハウス連携: S3 に集約したデータを Amazon Redshift にロードし、データ分析を効率化。
リアルタイムデータ同期: Salesforce と Zendesk 間で顧客情報を同期し、顧客管理を効率化。
マーケティングデータ分析: Google Analytics のデータを Amazon QuickSight に連携し、マーケティング分析を可視化。

7. 設定・デプロイ手順（ハンズオン例）¶

AppFlow コンソールでデータフローを作成。
データソース（例: Salesforce）とターゲット（例: Amazon S3）を設定。
データのフィルタリング、変換、マッピングを設定。
データ転送のスケジュールまたはイベントトリガーを設定。
データフローを実行し、データ転送を確認。

8. 試験で問われやすいポイント¶

8.1 データソースとターゲットのサポート¶

サポート対象: Salesforce, Marketo, Google Analytics, Zendesk, Snowflake, S3, Redshift など、主要な SaaS アプリケーションと AWS サービスのサポートについて理解。
データコネクタ: 各データソース・ターゲットに対応するコネクタについて理解。

8.2 双方向データ転送¶

一方通行転送: ソースからターゲットへのデータ転送について理解。
双方向転送: ソースとターゲット間でデータを同期するシナリオについて理解。

8.3 データ変換とマッピング¶

データフィルタリング: 特定の条件に合致するデータのみを転送する方法について理解。
データ変換: データ型変換、文字列操作、関数適用について理解。
カラムマッピング: ソースとターゲットのカラムを対応付ける方法について理解。

8.4 スケジュール実行とイベント駆動¶

スケジュール実行: スケジュールを設定して定期的にデータ転送を実行する方法を理解。
イベント駆動: Amazon EventBridge イベントをトリガーとしてデータ転送を実行する方法を理解。

8.5 フルマネージドサービス¶

インフラ管理: AWS がインフラを自動で管理、スケーリングも自動で行われることについて理解。
サーバーレス: サーバーレスで可用性の高いデータ転送が可能であることを理解。

8.6 セキュリティ¶

IAM: IAM を利用したアクセス制御について理解。
データ暗号化: 転送中および保存中のデータを暗号化することについて理解。
VPC サポート: VPC 内でのプライベート接続について理解。
認証情報管理: AWS Secrets Manager を使った認証情報の安全な管理について理解。

8.7 料金体系¶

データ処理量: 転送・処理されるデータ量による従量課金について理解。
データコネクタ: データコネクタの種類による課金について理解。
追加機能: プライベートリンクなど、追加機能の利用による課金について理解。

8.8 類似・関連サービスとの比較¶

AWS Glue: データ変換、ETL ジョブに特化。AppFlow は SaaS と AWS 間のデータ転送に特化。
AWS Data Pipeline: データ処理パイプラインのオーケストレーションに特化。AppFlow は SaaS 連携に特化。

8.9 試験で頻出となる具体的な問われ方と答え¶

Q: Amazon AppFlow の主な用途は？
A: SaaS アプリケーションと AWS サービス間の安全かつ双方向のデータ転送自動化。
Q: AppFlow がサポートするデータソースの例は？
A: Salesforce, Marketo, Google Analytics, Zendesk, S3, Redshift など。
Q: AppFlow で可能なデータ変換処理は？
A: データフィルタリング、データ型変換、文字列操作、カラムマッピングなど。
Q: AppFlow のデータ転送実行方法は？
A: スケジュール実行、イベント駆動。
Q: AppFlow のセキュリティ対策は？
A: IAM によるアクセス制御、データ暗号化、VPC サポートなど。
Q: AppFlow の料金体系は？
A: データ処理量、データコネクタ、追加機能の利用に応じた課金。
Q: AppFlow と AWS Glue の違いは？
A: AppFlow は SaaS 連携に特化、AWS Glue は ETL ジョブに特化。

EventBridge¶

1. サービス概要¶

Amazon EventBridge は、AWS サービス、SaaS アプリケーション、独自アプリケーションから発生するイベントをストリームとして受け取り、それらを他のターゲットサービスへとルーティングするサーバーレスのイベントバスサービス。
これにより、複雑なイベント駆動型アーキテクチャをシンプルかつスケーラブルに実装可能になり、疎結合で拡張しやすいシステムを構築できる。

主なユースケースとして、

マイクロサービス間通信
SaaS アプリとのインテグレーション
リアルタイムなイベント処理
ワークフローオーケストレーション

が挙げられる。

2. 主な特徴と機能¶

2.1 イベントバス(Event Bus)¶

EventBridge は、イベントを流通させるためのイベントバスを提供する。

デフォルトイベントバス: AWS アカウント標準のイベントバス
カスタムイベントバス: アプリケーション固有のイベント受け取り用
パートナーイベントバス: SaaS アプリケーションや外部サービスからのイベントを受け取る

2.2 イベントルール(Rules)¶

ルールはイベントパターンや条件に基づいて、受け取ったイベントを特定のターゲットへルーティングする。
ルールはフィルタリング機能を持ち、JSON 形式のイベントペイロードに対して特定のフィールド条件を指定可能。

2.3 ターゲット(Targets)¶

ルールにマッチしたイベントは、

AWS Lambda
Amazon SQS
Amazon SNS
Amazon Kinesis Streams
Amazon ECS
API Destinations
Step Functions

など、様々なターゲットに送信できる。
これにより、イベントをトリガーとして自動処理や非同期ワークフローを実現できる。

2.4 スキーマレジストリとディスカバリー¶

EventBridge はイベントスキーマをレジストリで管理し、スキーマディスカバリー機能を利用して、実際に流れるイベントからスキーマを自動的に推論・登録可能。
これにより、開発者はイベント駆動アプリケーションのスキーマ管理を容易に行える。

3. アーキテクチャおよび技術要素¶

様々なソース（AWS サービスイベント、独自アプリからの PutEvents API、SaaS 連携等）からイベントバスへイベントが投入される。
イベントルールが、イベントペイロードに基づいてフィルタリングを行う。
マッチしたイベントは、ターゲット（Lambda や SQS、Step Functions など）へ自動的にルーティングされる。
スキーマレジストリでイベントスキーマを管理し、開発者はスキーマに基づく型安全なコード生成が可能。

すべてがサーバーレスで、柔軟かつ拡張性の高いイベント駆動アーキテクチャを構築できる。

4. セキュリティと認証・認可¶

EventBridge では、IAM ポリシーとリソースポリシーにより、イベントバスへの PutEvents やルールへのアクセスを制御する。
また、API Destinations 機能を利用する場合には、コネクションを作成し、認証情報(例えば OAuth、API キー等)を安全に扱うことが可能。

IAM ポリシー: ユーザやロールが EventBridge API（PutRule、PutTargets、PutEvents など）を実行できるか制御。
リソースベースポリシー: 特定のイベントバスやルールに対するクロスアカウントアクセスを制御。
暗号化: イベントは基本的に、暗号化された通信（TLS）上でやりとりされ、センシティブ情報はターゲット先での暗号化や IAM 制御で保護。

5. 料金形態¶

Amazon EventBridge の料金は主にイベント数に基づく従量課金モデル。

イベント挿入数: PutEvents API で送信されたイベント数や、AWS サービスから発生するイベント数に応じて課金。
スキーマディスカバリー: スキーマレジストリへの登録やスキーマディスカバリーには一定の無料枠があるが、超過すると課金対象。

6. よくあるアーキテクチャ・設計パターン¶

マイクロサービス間通信: 個別サービス間を疎結合に保つため、EventBridge にイベントを送信し、別のマイクロサービスがそれをトリガーに動作。
システム統合: SaaS アプリ（Salesforce、Zendesk など）からのイベントを EventBridge で受け取り、自社アプリへ連動。
ワークフローオーケストレーション: イベント発生に応じて Step Functions を起動し、複雑なビジネスフローを非同期で実行。
イベント駆動 CI/CD: コードコミットイベントや ECR イメージプッシュイベントをトリガーにパイプラインを起動。

7. 設定・デプロイ手順（ハンズオン例）¶

Amazon EventBridge コンソールで新規ルールを作成。
ルールにイベントパターン（例：{"source": ["aws.ec2"]}）を定義し、特定のイベントのみマッチさせる。
ターゲットとして Lambda 関数を指定。
EC2 で特定の状態変化イベント（インスタンス起動など）が発生すると、そのイベントが EventBridge により Lambda へ転送。
Lambda でイベントペイロードを処理し、ログ出力や通知送信などを実行。

8. 試験で問われやすいポイント¶

8.1 イベントバスの種類と用途¶

デフォルトイベントバス: 同一アカウント内で AWS サービスイベントを受け取る標準バス。
カスタムイベントバス: アプリケーション独自イベントを分類・整理可能。マルチテナント環境や分離が必要なケースで有効。
パートナーイベントバス: SaaS アプリケーションや外部サービスのイベントを直接受け取るためのイベントバス。

8.2 イベントパターンとルール¶

イベントパターン: イベントの source 、 detail-type 、 detail フィールドを条件にフィルタリング。
ルール: 一つのルールで複数ターゲットを指定可能。マッチしたイベントを並列に複数のターゲットへ送信。
注意点: ルールにはステートレスで、イベントを変換（InputTransformer）したり、一部フィールドのみ抽出したりできる。

8.3 ターゲットとその特性¶

Lambda: コード実行でイベント処理。サーバーレスで柔軟な処理が可能。
SQS: 非同期キューイングでイベントをバッファリング。消費者側で後処理。
SNS: Pub/Sub 型の分配。メール、SMS、HTTP エンドポイントなどへの通知。
Step Functions: 複雑なワークフロー駆動。イベントをトリガーに状態機械を実行。
API Destinations: 外部 API への安全な呼び出し（コネクション認証管理付き）。

8.4 スキーマレジストリとディスカバリー¶

スキーマレジストリ: イベント構造を管理し、スキーマとして保持。 Java、Python、TypeScript などで自動コード生成可能。
スキーマディスカバリー: 実際に流れるイベントを監視し、自動でスキーマを特定・登録。

試験では

「スキーマを自動取得する方法は？」
「スキーマ管理でコード生成ができるか？」

などが問われる。

8.5 セキュリティモデル¶

IAM ポリシー: EventBridge API へのアクセス制御（ルール作成、削除、PutEvents など）。
リソースポリシー: クロスアカウントアクセスで、他アカウントからイベントバスへイベントを送信可能にする。
API Destinations 認証: OAuth や API キー認証情報を安全に保管。

8.6 コストモデルと最適化¶

イベント数管理: 不必要なイベント送信を控え、コスト削減。
フィルタリングの徹底: ルールで不要なイベントを除外し、ターゲットの呼び出し回数を減らす。

8.7 類似・関連サービスとの比較¶

Amazon SNS との違い: SNS は Pub/Sub モデルでトピック購読、EventBridge は構造化されたイベントバスとフィルタリングが強力。
Amazon CloudWatch Events との関係: EventBridge は CloudWatch Events の拡張版であり、SaaS 統合やスキーマ管理が追加されている。
Amazon SQS との役割分担: EventBridge はイベントルーティング、SQS はキューイング。EventBridge でフィルタリングして SQS へ送れば柔軟なアーキテクチャを構築可能。

8.8 試験で頻出となる具体的な問われ方と答え¶

Q: EventBridge で SaaS アプリからのイベントを受け取るには？
A: パートナーイベントバスを使用する。
Q: クロスアカウントでイベントを受け取るには？
A: イベントバスにリソースポリシーを設定して他アカウントからのアクセスを許可。
Q: スキーマディスカバリーの役割は？
A: フローするイベントから自動でスキーマを推論・登録する。
Q: ターゲットに Lambda と SQS を同時に設定できるか？
A: 可能。1 ルールで複数ターゲットを設定できる。
Q: CloudWatch Events と EventBridge の違いは？
A: EventBridge は CloudWatch Events の拡張版。SaaS 統合やスキーマ管理があり、より包括的。

MQ¶

1. サービス概要¶

Amazon MQ は、AWS が提供するフルマネージドのメッセージブローカーサービス。
このサービスを利用することで、Apache ActiveMQとRabbitMQという 2 つの一般的なメッセージブローカーを、クラウド上で簡単にデプロイ、運用できる。
Amazon MQ は、メッセージングシステムに必要なインフラストラクチャの管理を AWS に任せ、アプリケーションの疎結合と信頼性の高いメッセージングをサポートする。

主なユースケースとして、

マイクロサービスアーキテクチャにおける非同期通信
分散システムにおけるメッセージング
トランザクション処理
イベントドリブンアーキテクチャ

などが挙げられる。

2. 主な特徴と機能¶

2.1 Apache ActiveMQ と RabbitMQ のサポート¶

Amazon MQ は、Apache ActiveMQ と RabbitMQ という 2 つの一般的なメッセージブローカーをサポートしている。
これにより、既存のアプリケーションで使用されているメッセージングフレームワークをそのまま利用できる。

Apache ActiveMQ: Java ベースのメッセージブローカーで、幅広いプロトコル (JMS, AMQP, MQTT, STOMP など) をサポート。
RabbitMQ: Erlang で開発されたメッセージブローカーで、AMQP プロトコルをサポート。

2.2 フルマネージドサービス¶

メッセージブローカーのプロビジョニング、スケーリング、パッチ適用、バックアップなどの運用管理は AWS が自動で行う。
これにより、ユーザーはインフラ管理に煩わされることなく、アプリケーションの開発に集中できる。

2.3 可用性と耐久性¶

Amazon MQ は、複数のアベイラビリティーゾーンにデータを分散して保存し、自動的にフェイルオーバーを処理する。
これにより、高い可用性と耐久性を実現し、システムのダウンタイムを最小限に抑える。

2.4 セキュリティ¶

Amazon MQ は、データの暗号化、アクセス制御、ネットワーク分離などのセキュリティ機能を提供する。
IAM によるアクセス制御、転送中のデータ暗号化、保存中のデータ暗号化、VPC 内でのプライベート接続をサポートしている。

IAM 連携: AWS IAM を使用してアクセス制御と権限管理。
データ暗号化: 転送中および保存中のデータを暗号化。
VPC サポート: Amazon VPC 内でのプライベート接続。

2.5 メッセージの耐久性¶

メッセージは、永続ストレージに保存され、ブローカーの障害時にも失われないように保護されている。
これにより、信頼性の高いメッセージングを実現できる。

2.6 メトリクスとモニタリング¶

Amazon CloudWatch と統合されており、メッセージブローカーのパフォーマンス、メッセージ数、接続数などを監視できる。
これにより、システムの状態を常に把握し、異常を早期に発見できる。

2.7 統合性¶

Amazon MQ は、AWS の他のサービス（AWS Lambda, Amazon ECS, Amazon SQS など）と統合されており、様々なアプリケーションアーキテクチャに対応できる。
AWS X-Ray と連携して分散トレーシングを行うことができる。

3. アーキテクチャおよび技術要素¶

アプリケーションは、メッセージブローカーにメッセージを送信。
Amazon MQ は、メッセージをキューまたはトピックに保存。
アプリケーションは、メッセージブローカーからメッセージを受信。
メッセージは、複数のアベイラビリティーゾーンに分散して保存。
自動フェイルオーバー機能により、高可用性を確保。

Amazon MQ は、フルマネージドサービスとして提供され、高い可用性、スケーラビリティ、セキュリティを内包している。
メッセージングに必要なインフラ管理を簡素化し、開発者はアプリケーション開発に集中できる。

4. セキュリティと認証・認可¶

セキュリティは Amazon MQ の重要な要素:

IAM によるアクセス制御: AWS IAM を利用して、Amazon MQ リソースへのアクセスを制御し、権限を管理。
データ暗号化: 転送中および保存中のデータを暗号化し、データの機密性を保護。
VPC サポート: Amazon VPC 内で Amazon MQ を使用する場合、プライベート接続を確立。
認証: メッセージブローカーのユーザー名とパスワードによる認証を提供。
監査ログ: AWS CloudTrail を利用して、API 呼び出しやリソース変更を記録。

5. 料金形態¶

Amazon MQ の料金は主に以下に基づく:

ブローカーインスタンス料金: メッセージブローカーの実行時間に応じた課金。
ストレージ料金: メッセージブローカーが使用するストレージ量に応じた課金。
データ転送料金: データ転送量に応じた課金。

6. よくあるアーキテクチャ・設計パターン¶

一般的なパターンは以下の通り:

マイクロサービスアーキテクチャ: マイクロサービス間の非同期通信にメッセージブローカーを利用し、疎結合を促進。
分散システム: 分散システムでメッセージングを利用して、異なるコンポーネント間で情報を伝達。
トランザクション処理: トランザクション処理をメッセージキューに格納し、処理の信頼性と効率性を向上。
イベントドリブンアーキテクチャ: イベントが発生した際にメッセージブローカーを介して通知し、関連するサービスを起動。
アプリケーション統合: 異なるアプリケーション間でメッセージブローカーを利用してデータの統合。

7. 設定・デプロイ手順（ハンズオン例）¶

AWS コンソールで Amazon MQ のブローカーを作成（ActiveMQ または RabbitMQ を選択）。
ブローカーのアクセス設定を行い、クライアントアプリケーションが接続できるように設定。
メッセージをキューまたはトピックに送信。
メッセージブローカーからメッセージを受信。
CloudWatch でメトリクスを監視。

8. 試験で問われやすいポイント¶

8.1 Apache ActiveMQ と RabbitMQ のサポート¶

ActiveMQ: Java ベース、様々なプロトコルをサポートすることを理解。
RabbitMQ: AMQP プロトコルをサポートすることを理解。
フレームワーク選択: 既存のアプリケーションの要件に合わせて適切なブローカーを選択することを理解。

8.2 フルマネージドサービス¶

運用管理: メッセージブローカーのプロビジョニング、スケーリング、パッチ適用、バックアップなどを AWS が自動で管理することを理解。
開発への集中: ユーザーはインフラ管理に煩わされることなく、アプリケーション開発に集中できることを理解。

8.3 可用性と耐久性¶

マルチ AZ: 複数のアベイラビリティーゾーンにデータを分散して保存することを理解。
自動フェイルオーバー: 自動フェイルオーバー機能で高い可用性を実現することを理解。

8.4 セキュリティ¶

IAM: IAM によるアクセス制御と権限管理について理解。
データ暗号化: 転送中および保存中のデータを暗号化することを理解。
VPC サポート: VPC 内でのプライベート接続について理解。
認証: メッセージブローカーの認証機能について理解。

8.5 料金体系¶

ブローカーインスタンス: メッセージブローカーの実行時間による課金を理解。
ストレージ: メッセージブローカーが使用するストレージ量による課金を理解。
データ転送: データ転送量による課金を理解。

8.6 類似・関連サービスとの比較¶

Amazon SQS: キューイングサービス。Amazon MQ はメッセージブローカー。
Amazon SNS: パブリッシュ/サブスクライブ型メッセージングサービス。Amazon MQ はより柔軟なメッセージルーティングが可能。

8.7 試験で頻出となる具体的な問われ方と答え¶

Q: Amazon MQ の主な用途は？
A: メッセージブローカーのデプロイ、運用管理を簡素化し、アプリケーションの疎結合を促進すること。
Q: Amazon MQ がサポートするメッセージブローカーは？
A: Apache ActiveMQ と RabbitMQ。
Q: Amazon MQ のフルマネージドとは？
A: メッセージブローカーの運用管理を AWS が行うこと。
Q: Amazon MQ でメッセージの耐久性を確保する方法は？
A: 永続ストレージにメッセージを保存すること。
Q: Amazon MQ のセキュリティ対策は？
A: IAM によるアクセス制御、データ暗号化、VPC サポートなど。
Q: Amazon MQ の料金体系は？
A: ブローカーインスタンス、ストレージ、データ転送に応じた課金。
Q: Amazon MQ と Amazon SQS の違いは？
A: SQS はキューイングサービス、Amazon MQ はメッセージブローカー。

SNS¶

1. サービス概要¶

Amazon Simple Notification Service (SNS) は、Publisher/Subscriber(Pub/Sub)モデルに基づくフルマネージドなメッセージングサービス。
トピックを介してメッセージを受信者（Subscriber）へ配信することで、マイクロサービスや分散アプリケーション間の疎結合化、リアルタイムな通知・イベント通知、アラート通知などを実現する。

主なユースケースとして、

アラート・通知システム(メール、SMS、HTTP エンドポイント)
分散アプリ間連携
イベントドリブンアーキテクチャの中継
モバイルプッシュ通知

などが挙げられる。

2. 主な特徴と機能¶

2.1 トピックとサブスクライバー¶

SNS は「トピック」を中心にメッセージを配信します。Publisher はトピックにメッセージを発行し、Subscriber はトピックにサブスクライブすることでメッセージを受け取る。
サブスクライバーとして、

HTTP(S)エンドポイント
E メール
SMS
SQS キュー
Lambda 関数
モバイルプッシュ通知

など、多彩なエンドポイントが指定可能。

2.2 メッセージ配信方式¶

SNS は Push 型でメッセージを配信する。
つまり Subscriber が Pull する必要なく、トピックに新規メッセージが投稿されると即座にサブスクライバーへ通知される。
冗長性を確保し、送信失敗時には再試行（リトライ）戦略をとる。

2.3 メッセージ属性とフィルタポリシー¶

SNS メッセージには属性を付与でき、Subscriber 側でフィルタポリシーを設定することで受信するメッセージを選別可能。
これにより、1 つのトピックで異なる種類のイベントを扱いつつ、サブスクライバーごとに特定属性のメッセージだけを受け取ることができる。

2.4 メッセージ暗号化とセキュリティ¶

サーバー側暗号化(SSE)を用いて、SNS トピックで転送されるメッセージを AWS KMS キーで暗号化可能。
IAM ポリシーやトピックポリシーを使って、特定アカウント、ロール、IP アドレス範囲からのみ Publish や Subscribe を許可するなど、アクセス制御が可能。

3. アーキテクチャおよび技術要素¶

Publisher がトピックにメッセージを Publish。
SNS はサブスクライバー(HTTP、Lambda、SQS、E メール、SMS 等)へメッセージを Push 配信。
フィルタポリシーにより、属性に応じたメッセージを特定サブスクライバーのみに送付可能。
SSE や IAM/トピックポリシーでセキュリティを強化。

4. セキュリティと認証・認可¶

IAM ポリシー: 誰が SNS トピックに Publish/Subscribe 可能かを制御。
トピックポリシー: バケットポリシー同様、トピックリソースに対するアクセス制御を JSON ポリシーで定義。
SSE-KMS 暗号化: トピックへのメッセージを KMS 鍵で暗号化し、メッセージセキュリティを強化。
VPC エンドポイント（PrivateLink）: パブリックインターネット経由せずに VPC 内から SNS へアクセス可能。

5. 料金形態¶

SNS は主に次の項目で課金される:

Publish リクエスト数: トピックへメッセージを送信する度にリクエストとしてカウント。
配信先ごとの料金: E メールは無料枠あり、SMS はメッセージ数/国別料金、HTTP/HTTPS はリクエスト数など。
フィルタポリシー適用コスト: 通常は追加料金なし。
SSE-KMS 利用: KMS API コールコストが発生する可能性。

6. よくあるアーキテクチャ・設計パターン¶

マイクロサービス間通信: SNS トピック経由で非同期にイベント通知し、SQS や Lambda へ配信して処理を連結。
アラート通知: CloudWatch アラームや EventBridge ルールから SNS へメッセージを送り、E メール/SMS で運用担当へリアルタイム通知。
Fan-out パターン: 1 つのメッセージを複数サブスクライバーへ同時配信して並列処理を促進。
モバイルプッシュ通知: SNS と Mobile Push トピックを使い、iOS/Android 端末へ直接通知配信。

7. 設定・デプロイ手順（ハンズオン例）¶

SNS コンソールで新規トピックを作成（トピック名、アクセス制御設定）。
サブスクリプションを作成（E メールアドレスや SQS キュー ARN などを指定）。
Publish テストメッセージを送信し、サブスクライバーに届くことを確認。
必要に応じて、SSE-KMS 暗号化を有効化し、IAM ロールを割り当ててセキュリティ強化。
フィルタポリシーでサブスクライバー毎に受信メッセージを制御。

8. 試験で問われやすいポイント¶

8.1 トピック、サブスクリプション、エンドポイント¶

Pub/Sub モデル、複数エンドポイントへの同時配信。

8.2 フィルタポリシー¶

メッセージ属性に基づく受信メッセージの選別。

8.3 暗号化とアクセス制御¶

IAM ポリシー、トピックポリシーでのアクセス権限管理。
SSE-KMS でメッセージを暗号化。

8.4 料金モデルとコスト最適化¶

無料枠の活用（E メール通知）、SMS コスト、HTTP(S)配信コストの理解。

8.5 サブスクライバーの種類¶

SQS、Lambda、HTTP(S)、E メール、SMS、Mobile Push など豊富なターゲット。

8.6 冗長性と再試行戦略¶

HTTP エンドポイントへの配信失敗時に一定のリトライ戦略あり。

8.7 他サービスとの統合¶

CloudWatch、EventBridge、S3、Lambda、SQS との連携で分散アーキテクチャを構築。

8.8 試験で頻出となる具体的な問われ方と答え¶

Q: SNS はどのようなモデルでメッセージ配信を行うか？
A: Pub/Sub モデルでトピック経由の非同期メッセージ配信を行う。
Q: フィルタポリシーを使うと何ができるか？
A: メッセージ属性に応じて、サブスクライバーごとに受け取るメッセージを選別可能になる。
Q: SSE-KMS は何に使用するか？
A: SNS トピック上で転送されるメッセージを KMS キーで暗号化するために使用。
Q: サブスクライバーを Lambda にした場合の利点は？
A: メッセージ受信をトリガーにコード実行が可能になり、イベント駆動の処理フローを実現できる。
Q: SNS を用いた Fan-out パターンとは何か？
A: 1 つのメッセージを複数のターゲット（SQS、Lambda、E メールなど）へ同時に配信することで並列処理を実現する手法。

Simple Queue Service (SQS)¶

1. サービス概要¶

Amazon Simple Queue Service (SQS) は、分散アプリケーション間の非同期メッセージキューイングを提供するフルマネージドサービス。
送信側(Producer)と受信側(Consumer)を疎結合にし、メッセージを一時的にキューに蓄積することで、システム全体の耐障害性・スケーラビリティを向上させる。

主なユースケースとして、

Microservices 間の非同期処理
ピーク負荷対策
デカップリング
バックログ処理
非同期ワークフローの構築

などが挙げられる。

2. 主な特徴と機能¶

2.1 スタンダードキューと FIFO キュー¶

SQS には 2 種類のキュータイプがある。

スタンダードキュー: 高スループット、少量の重複や順序の崩れが許容される。
FIFO キュー: First-In-First-Out を保証し、重複排除、厳密なメッセージ順序が必要な場合に使用。

2.2 可視性タイムアウト (Visibility Timeout)¶

コンシューマーがメッセージを受信した後、一定時間(可視性タイムアウト)そのメッセージは他のコンシューマーから見えなくなる。
コンシューマーが処理を完了し DeleteMessage する前にタイムアウトが切れると、同じメッセージが再度配信され、処理失敗時の再試行を可能にする。

2.3 デッドレタキュー (Dead-Letter Queue: DLQ)¶

処理失敗を繰り返すメッセージを別のキュー（DLQ）に隔離することで、問題あるメッセージを後から分析・再処理しやすくする。
DLQ を用いることで、正常なメッセージ処理を妨げないアーキテクチャを実現できる。

2.4 長いポーリング (Long Polling)¶

コンシューマーがキューからメッセージを取得する際に、すぐにメッセージがなければ一定時間待機できる機能。
これにより、空のレスポンスを減らし、コスト・レイテンシ削減が可能。

2.5 メッセージ属性とバッチ操作¶

メッセージには属性（キー・バリュー）を付与可能。
また、複数メッセージをまとめて送受信・削除（最大 10 件）できるバッチ操作でパフォーマンス向上が可能。

3. アーキテクチャおよび技術要素¶

Producer が SQS キューにメッセージを SendMessage または SendMessageBatch で送信。
Consumer は ReceiveMessage でキューからメッセージを取得、処理後 DeleteMessage で削除。
必要に応じて FIFO キューで順序の保証、DLQ で失敗メッセージ隔離、Long Polling で効率的なメッセージ取得を活用。
IAM ポリシーやキューポリシー、KMS による暗号化でセキュリティ・アクセス制御を実施

4. セキュリティと認証・認可¶

IAM ポリシー: 誰が SQS API（SendMessage、ReceiveMessage など）を実行できるか制御。
キューポリシー: 特定アカウントや条件に基づいてキューへの操作許可・拒否が設定可能。
SSE-KMS 暗号化: キューへ送信されるメッセージを KMS で暗号化し、メッセージ機密性を確保。
VPC エンドポイント: VPC 内からインターネット経由せずに SQS へアクセス可能。

5. 料金形態¶

SQS は次の項目で主に課金される:

リクエスト数: メッセージ送信・受信・削除リクエストごとに課金。（スタンダードキューは月 100 万リクエストまで無料枠あり）
SSE-KMS 暗号化: KMS API コールコストが追加。
データ転送料: 同一リージョン内への転送は無料だが、クロスリージョン転送には料金発生。

6. よくあるアーキテクチャ・設計パターン¶

非同期処理キュー: Web アプリから非同期ジョブを SQS キューに送信、バックエンドの Worker が処理。
キューと Lambda 連携: SQS キューを Lambda トリガーに設定し、メッセージ到着時に自動処理。
キュー間連携と DLQ: メインキュー → 処理失敗 →DLQ へ移送し、後から再処理や分析。
Fan-out パターン(併用): SNS トピック →SQS キュー複数へ配信し、並列処理を実現。

7. 設定・デプロイ手順（ハンズオン例）¶

SQS コンソールで新規キュー作成（Standard または FIFO、キュー名、属性を設定）。
必要に応じてキューポリシーや SSE-KMS 暗号化を有効化。
Producer は AWS CLI、SDK またはコンソールから SendMessage でメッセージ送信。
Consumer は ReceiveMessage でメッセージ取得後、処理完了時に DeleteMessage 。
DLQ や Long Polling 設定、Visibility Timeout 調整で可用性・再処理性を最適化。

8. 試験で問われやすいポイント¶

8.1 スタンダードキューと FIFO キュー¶

スタンダードは無制限スループットと多少のメッセージ順序崩れ許容、FIFO は順序厳密維持と重複排除。

8.2 可視性タイムアウト¶

コンシューマー処理中に同じメッセージが他から見えないようにするための時間。

8.3 デッドレタキュー（DLQ）¶

処理失敗したメッセージを隔離し、再処理やデバッグを容易にする。

8.4 Long Polling¶

空のレスポンスを減らし、コストを抑えつつリアルタイム性向上。

8.5 セキュリティと暗号化¶

IAM ポリシー、キューポリシー、SSE-KMS で制御と暗号化。

8.6 コストモデルと無料枠¶

標準キューには一定の無料枠、バッチ操作でリクエスト数低減。

SQS→Lambda 連携でイベント駆動処理、SNS→SQS 連携で Fan-out パターン、Step Functions ワークフロー内での待機状態としても活用。

8.8 試験で頻出となる具体的な問われ方と答え¶

Q: SQS のスタンダードキューと FIFO キューの違いは？
A: スタンダードは高スループットだが順序保証なし、FIFO は順序と重複排除を保証するがスループット制限あり。
Q: 可視性タイムアウトは何のためにある？
A: メッセージ処理中に同じメッセージが他のコンシューマーに見えないようにし、重複処理を防ぐため。
Q: デッドレタキューはどのように利用する？
A: 処理に何度も失敗したメッセージを DLQ に隔離し、後から分析や再処理を行うため。
Q: Long Polling を有効にすると何が得られる？
A: キューが空の場合でも一定時間待機することで、空レスポンスを減らしコスト削減と低レイテンシ取得を実現できる。
Q: SQS と Lambda を連携するとどのような利点がある？
A: SQS キュー到着メッセージを自動トリガーとして Lambda が処理することで、サーバーレスかつ非同期なワークフローを構築できる。

Step Functions¶

1. サービス概要¶

AWS Step Functions は、サーバーレスなワークフローオーケストレーションサービス。
JSON ベースの状態機械(State Machine)で、複数の AWS サービスやカスタムタスクをシーケンス化・分岐・並列実行し、可観測性の高いビジネスロジックを構築できる。

手動でのコード書き換えや複雑なエラー処理ロジックを組み込むことなく、エラーリトライ、待機、並列処理、条件分岐などの高度なフロー制御が行える。

ユースケースには、

マイクロサービス間オーケストレーション
データ処理パイプラインの自動化
機械学習ワークフロー
長期実行バッチジョブ
イベント駆動型アプリケーション

などが挙げられる。

2. 主な特徴と機能¶

2.1 状態機械とステートタイプ¶

ワークフローは「状態機械」として定義し、各ステート(State)で処理を定義する。

タスク(State Machine 内で特定の AWS サービス呼び出しや Lambda 実行)
Choice(条件分岐)
Parallel(並列処理)
Map(反復処理)
Wait(待機)
Pass(データパス操作のみ)
Succeed/Fail(ワークフロー終了)

など、多様なステートを提供する。

2.2 ワークフロータイプ（Standard と Express）¶

Standard ワークフロー: 長期実行（最大 1 年）、ステップごとの履歴保存、複雑なロジックに最適。
Express ワークフロー: 短時間・高スループットのイベント処理用、コスト最適化しやすく、ログは CloudWatch Logs に出力。

2.3 サービス統合¶

Step Functions は

Lambda
SNS
SQS
DynamoDB
ECS
Glue
Athena
SageMaker

など、多くの AWS サービスとネイティブに統合。
「サービス統合パターン」を通じてタスクステート内で AWS サービス API を直接呼び出せるため、追加のコード不要で複雑なワークフローが実現可能。

2.4 エラー処理とリトライ、キャッチ¶

各タスクでエラーが発生した場合、リトライポリシーを定義し、特定のエラー時に再試行回数・待機時間を設定可能。
Catch ハンドラーで失敗時のフォールバックシナリオ（異なるステートへの遷移）を定義でき、堅牢なエラー処理が実現できる。

2.5 データパス操作と入力・出力加工¶

パス(Path)、入力変換(InputPath, OutputPath, ResultPath)を用いて、ステート間で渡すデータを柔軟にフィルタリング・変換可能。
不要なデータを削除、JSON 構造の一部を抽出、結果を組み合わせるなど、複雑なデータ操作が定義ファイルのみで実現できる。

3. アーキテクチャおよび技術要素¶

デベロッパーが Amazon States Language（ASL）で JSON 定義を記述し、状態機械を作成。
状態機械は Standard または Express ワークフローのいずれかを選択。
タスクステートで AWS サービスを統合し、条件や並列処理を定義。
実行開始後、Step Functions は定義通りにワークフローをオーケストレーション。
実行履歴やメトリクスはマネジメントコンソールや CloudWatch で確認可能。

4. セキュリティと認証・認可¶

IAM ロール: Step Functions はワークフローから呼び出すサービスへのアクセスを IAM ロールで制御。必要な最小権限を付与するベストプラクティスが推奨。
VPC 統合: VPC 内リソースにアクセスする場合は、VPC エンドポイントや特定の Task 実行環境でプライベートアクセス可能。
暗号化: 入出力データを含めて CloudWatch Logs へ出力する場合、ロググループの KMS 暗号化でデータ保護可能。

5. 料金形態¶

Step Functions の料金は主に実行数とステート遷移数に基づく。

Standard ワークフロー: ステート遷移数に応じて課金。実行履歴の保持も含まれる。
Express ワークフロー: 実行回数と処理期間、リソース使用時間に基づく低コストモデル。
IAM・KMS などの追加コスト: KMS 等の利用に伴うコストが別途発生。

6. よくあるアーキテクチャ・設計パターン¶

マイクロサービスオーケストレーション: 複数 Lambda や ECS タスクを条件分岐やエラーリトライ付きで接続。
データ処理パイプライン: S3→Glue→Athena→SNS といった一連の処理を Step Functions で自動化。
ML ワークフロー: SageMaker ジョブの開始、完了待ち、結果処理を可視化・制御。
複雑なビジネスロジック: エラー時の代替フロー、分岐条件、並列処理を定義し、再利用可能なビジネスロジックを確立。

7. 設定・デプロイ手順（ハンズオン例）¶

Step Functions コンソールで「State Machine を作成」を選択。
ASL(JSON)で状態定義を記述、またはワークフロービルダーで可視的に定義。
IAM ロールを指定し、タスクで呼び出すサービスへのアクセス権を付与。
ワークフロー開始(Execute)後、実行履歴やグラフィカルな表示で進行状況を確認。
必要に応じて Express ワークフローで高スループットイベント処理、Standard で長期実行タスクをサポート。

8. 試験で問われやすいポイント¶

8.1 Standard vs Express ワークフロー¶

Standard は長期実行と詳細履歴、Express は短時間・高スループット重視。

8.2 ステートタイプ（Task、Choice、Parallel、Map、Wait など）¶

各ステートの役割と使いどころ、データパス操作方法。

8.3 エラー処理とリトライ、キャッチ¶

エラー時の再試行戦略とフォールバックステート設定。

8.4 サービス統合パターン¶

直接 API 呼び出し（.sync, .waitForTaskToken パターンなど）で AWS サービスをオーケストレーション。

8.5 セキュリティと IAM ロール¶

Step Functions がタスクで使用するサービスにアクセスするためのロール設定。

8.6 料金モデル理解¶

Standard はステート遷移数、Express は実行回数と実行時間。

8.7 データパス操作と入力・出力フィルタ¶

InputPath, OutputPath, ResultPath でデータ加工。

8.8 試験で頻出となる具体的な問われ方と答え¶

Q: 長期間実行され、各ステップの履歴を詳細に保持するワークフロータイプは何？
A: Standard ワークフロー。
Q: タスクステートでエラーが発生した場合、特定のエラーで再試行する方法は？
A: タスク定義内の"Retry"フィールドでエラー名、最大試行回数、待機時間などを定義している。
Q: 並列に複数のブランチを同時実行するにはどのステートを使うか？
A: Parallel ステートを使用。
Q: Step Functions で Lambda を呼び出す際、コード変更なしに API 直接呼び出しを行う仕組みを何と呼ぶか？
A: サービス統合パターン(AWS SDK 統合)と呼ぶ。
Q: データから特定のフィールドのみを取り出して次ステートに渡すにはどうするか？
A: InputPath や OutputPath で JSON から必要なフィールドを抽出する。