この記事は、AWS SAP合格記 — Slack DMで作るサービス別ノート勉強法 で紹介した「サービス別ノート」を、ユースケースと判断軸ベースで再構成したものです。

SAP試験では「似たサービスの中から最適なものを選ぶ」判断力が問われます。各テーマを 「なぜ複数の選択肢があるのか → どう違うのか → どの条件でどれを選ぶか」 の流れで整理しています。

注: 一部の情報は学習時点（2022〜2023年）のものです。最新情報と異なる可能性がある箇所には注記を入れています。

目次

1. リアルタイムデータ処理
2. 認証・認可パターン
3. コンテンツ配信とアクセス制御
4. データベース選択
5. ネットワーク設計
6. セキュリティ
7. 運用管理
8. サーバーレス / API設計
9. データ移行・ETL

1. リアルタイムデータ処理

なぜ複数の選択肢があるのか

AWSには「データを受け取って後続に渡す」仕組みが複数ある。Kinesis Data Streams、SQS、Amazon MQの3つが代表的だ。これらは一見似ているが、解こうとしている課題が違う。

• Kinesis Data Streams = ストリーミング処理。大量のデータを連続的に受け取り、リアルタイムで処理する
• SQS = メッセージキューイング。コンポーネント間の非同期連携。処理の確実な実行が目的
• Amazon MQ = 既存のActiveMQ互換サービス。オンプレからの移行用

Kinesis Data Streams vs SQS — 判断軸

選択の指針:

• 関連する複数のレコードを同じ処理系に回したい → Kinesis
• 複数のアプリケーションが同じストリームを同時に使う → Kinesis
• レコードを数時間後に同じ順序で使う → Kinesis
• メッセージレベルの確認/失敗を個別に追跡する → SQS
• 遅延のある個別のジョブをスケジュールする → SQS
• 負荷の一時的な上昇をバッファしたい → SQS

Kinesis Data Streams の詳細

概念

• シャード: スループットの単位。1シャードは1MB/秒のデータ入力、2MB/秒のデータ出力をサポート
  • 1秒あたり最大1,000件のPUTレコードをサポート
  • 読み取りは1秒あたり最大5件のトランザクション（GetRecordsは1回で最大10MB/10,000レコード）
  • データ保持期間: デフォルト24時間、最大365日間まで延長可能
• レコード: データの単位。シーケンス番号、パーティションキー、データBLOB（最大1MB）で構成
• パーティションキー: レコードを異なるシャードにルーティングするためのキー
• シーケンス番号: 各レコードの一意識別子。シャード間では増加しない

参考リンク:

• Kinesis Data Streams の主要なコンセプト

データの書き込み

• PutRecord / PutRecords: 同期処理でデータを追加
• Kinesis Producer Library (KPL): 非同期処理の高度な設定が可能なライブラリ
• Kinesis Agent: Linux環境にインストールするJavaアプリケーション。データ収集とストリームへの送信を自動化
• 容量制限超過時は ProvisionedThroughputExceeded 例外で拒否される

データの読み取り

• Kinesis Client Library (KCL): データコンシューマー。ボリュームの変化への適応、負荷分散、耐障害性に対応
  • DynamoDBテーブルを自動作成し、リシャーディングイベントやシーケンス番号チェックポイントを追跡
  • EC2オートスケーリンググループ上で実行すれば、処理能力を自動スケール可能
• Kinesis Connector Library: DynamoDB、Redshift、S3、Elasticsearch等への統合コネクタ（KCLとは別物）
• Kinesis Storm Spout: Apache Storm との統合ライブラリ
• ApproximateArrivalTimestamp: レコードがKinesisに正常に受信・保存された時刻
• 容量制限超過時は ProvisionedThroughputExceeded 例外で読み取り拒否

拡張ファンアウト（Enhanced fan-out）

コンシューマーとシャード間に論理的な2MB/秒のスループットパイプを提供するオプション機能。

使うべきケース:

• 複数コンシューマーがKinesisの性能制限を超えてしまう場合
• 200ms以下のデータ提供速度を求める場合

利用手順:

1. コンシューマーをKinesis Data Streamsサービスに登録する
2. KCL 2.xを使用している場合、登録は自動
3. 登録されたコンシューマーはそれぞれ独自の拡張ファンアウトスループットを持つ
4. HTTP/2 SubscribeToShard API でデータを取得する

リシャーディング

シャードの分割・結合によりデータストリームをスケールするプロセス。一度に実行できるリシャーディングオペレーションは1つだけ。

セキュリティ

• HTTPS（SSLエンドポイント）経由でデータを安全に格納・取得
• AWS KMSマスターキー（CMK）によるサーバー側暗号化
• クライアント側暗号化も可能（独自の暗号化ライブラリを使用）
• VPCエンドポイントでプライベートアクセス

SQS のポイント

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

• キュー処理が失敗した場合にPushされるキュー
• 未使用の元メッセージとエラーメッセージがセットでプッシュされる
• DLQが推奨されないケース: キューの順序性を維持する必要がある場合、無制限にリトライ処理をする場合

Amazon MQ

• ActiveMQに互換性のあるマネージドサービス（Pub/Sub型キューイング）
• EC2としてVPC内に起動し、ActiveMQのGUIが使える
• 機能的にはSQS/SNSと同じだが、既存のActiveMQからの移行用として提供されている
• AWSとしては、新規構築にはSQSを推奨している

参考: キューイングシステムの比較（MQ/Kafka）— https://qiita.com/mura16/items/0ea2914156b1614201aa

2. 認証・認可パターン

なぜ複数の選択肢があるのか

AWSリソースへのアクセス制御には、「誰が」「どこから」「何の認証情報で」アクセスするかによって最適な方式が変わる。STSの5つのAPIは、それぞれ異なる認証シナリオに対応している。

STS — 一時的なセキュリティ認証情報の5つのAPI

ユーザーIDをAWSの外で管理している場合、IAMユーザーを作成する代わりにIdP（Identity Provider）を利用する。IAMはOpenID Connect（OIDC）またはSAML 2.0と互換性のあるIdPをサポートする。

STSが返す一時的認証情報は以下の3つのセット:

• アクセスキー（アクセスキーID + シークレットアクセスキー）
• セキュリティトークン
• 有効期限

選択の指針:

• IAMユーザーが一時的に権限を得たい（MFA付き等）→ GetSessionToken
• 外部ユーザーにIAMユーザー相当のアクセスを与えたい → GetFederationToken
• 別のAWSアカウントのリソースにアクセスしたい → AssumeRole
• GoogleやFacebookログインでAWSリソースにアクセスしたい → AssumeRoleWithWebIdentity
• 社内のActive Directory（SAML）でAWSにログインしたい → AssumeRoleWithSAML

参考リンク:

• https://qiita.com/fkooo/items/a6d71407b2bed42332cc
• https://dev.classmethod.jp/articles/getfederetiontoken-assumerole-getsessiontoken/#toc-1
• https://blog.serverworks.co.jp/summary-of-getting-security-credentials-from-sts

モバイルアプリの認証 — Cognito vs STS直接呼び出し

モバイルアプリからAWSリソースにアクセスするパターンは主に2つ:

パターン1: Amazon Cognito（推奨）

• ユーザープール + IDプールを使い、外部IdP認証またはCognito自体での認証・認可を実装
• Cognitoが裏でSTSを呼んでくれるので、アプリ側の実装がシンプルになる

パターン2: AssumeRoleWithWebIdentity API 直接呼び出し

• SDKで外部IdPからの認証情報を取得し、それを使ってAWSからIAM Roleを引き受ける
• より細かい制御が必要な場合向き

API Gateway の認証 — Lambda オーソライザー

API Gatewayへのアクセスを制御するためにLambda関数を使う機能。OAuthやSAMLなどのベアラートークン認可や、カスタム認証スキームを実装できる。

2種類のオーソライザー:

• トークンベース（TOKEN オーソライザー）: JWT や OAuth トークンなどのベアラートークンで発信者IDを受け取る
• リクエストパラメータベース（REQUEST オーソライザー）: ヘッダー、クエリ文字列、stageVariables、$context変数の組み合わせで発信者IDを受け取る

3. コンテンツ配信とアクセス制御

なぜ複数の選択肢があるのか

S3に置いたコンテンツを制限付きで配信したい場合、「S3の署名付きURL」と「CloudFront + 署名付きURL」の2つの方法がある。さらにCloudFront側では「署名付きURL」と「署名付きCookie」の選択肢もある。配信の規模、速度要件、アクセス制御の粒度によって使い分ける。

S3署名付きURL vs CloudFront署名付きURL

共通点:

• URLを共有すれば誰でもアクセスできる
• 有効期限を設定できる

選択の指針:

• 少量・一時的なファイル共有 → S3署名付きURL
• 大量リクエスト、高速配信が必要 → CloudFront署名付きURL
• S3のURLを外部に見せたくない → CloudFront署名付きURL
• グローバルなアクセスが見込まれる → CloudFront署名付きURL

署名付きURL vs 署名付きCookie

非公開のS3バケットに対して、特定のクライアントにアクセス許可を与える手法。署名は秘密鍵（クライアント側）と公開鍵（サーバー側）で認証と改ざん検知を行い、有効期限を設定できる。

• 署名付きURL: 個別のファイルへのアクセス制御。ユーザーがコンテンツにアクセスできる日時やIPアドレスを制御可能
• 署名付きCookie: 複数のファイルへのアクセスを一括制御。サイト全体へのアクセス権を管理したい場合

参考: http://developers.goalist.co.jp/entry/2017/05/11/191628

S3オリジンへのアクセス制御 — OAC（Origin Access Control）

CloudFront経由でS3にアクセスさせる際、S3バケットを非公開にしたまま CloudFrontからのアクセスだけを許可する仕組み。

⚠️ 2024年時点の更新: 従来のOAI（Origin Access Identity）は非推奨となり、OAC（Origin Access Control）が推奨されています。OACはIAMロールベースの制御、短期間の認証情報ローテーション、SSE-KMS暗号化オブジェクトのサポート、全HTTPメソッド（GET/PUT/POST/PATCH/DELETE/OPTIONS/HEAD）のサポートなど、OAIより多くの機能を提供します。

参考: Restrict access to an Amazon S3 origin

地理的なアクセス制限

• CloudFrontの地理制限機能: 国単位でホワイトリスト/ブラックリストを設定可能
• 国より詳細なレベル（都市、IP単位等）で制限する場合は、サードパーティの位置情報サービスが必要

キャッシュの最適化

CloudFrontのキャッシュ制御は、Min TTL/Max TTL/Default TTLとオリジンのヘッダー値を組み合わせて決まる。

参考: CloudFront がコンテンツをキャッシュする期間の管理

TTLを0にした場合の動作:

• リクエストの都度Originに更新有無を確認する
• 更新がなければ304が返り、キャッシュしたコンテンツを利用する
• 完全にキャッシュ無効にはならず、Originの負荷軽減効果がある

クエリ文字列に対するキャッシュ設定:

• クエリ文字列でコンテンツが変わらない場合 → Originに転送せず、クエリ文字列に関係なくキャッシュ
• すべてのクエリ文字列パラメータでキャッシュ → クエリが違うと別リクエスト扱い（ヒット率は下がる）
• 指定したクエリ文字列のみキャッシュ → 上記2つのハイブリッド

参考: https://qiita.com/tmiki/items/be36303e514ce4d012f8

Originのプロトコル設定

HTTP、HTTPS、Match Viewer（クライアントのプロトコルに合わせる）の3つから設定可能。

Lambda@Edge

CloudFrontの拡張機能。エッジロケーションでLambda関数を実行できる。4つのイベントをトリガーにできる:

1. Viewer Request — クライアント → CloudFront
2. Origin Request — CloudFront → Origin
3. Origin Response — CloudFront ← Origin
4. Viewer Response — クライアント ← CloudFront

4. データベース選択

DynamoDB

基本特性

• リージョン内の3つのAZで同期的にレプリケートされ、高可用性・耐久性を提供
• デフォルトは結果整合性（最新の書き込みを反映していない可能性がある）
• 強い整合性読み込み（strongly consistent read）も利用可能
• スループットを指定し、それを超えると「スループット超過エラー」になる
  • → SQSにキューイングしてバッファとすることで防止可能

キー設計 — DynamoDBの最重要ポイント

• プライマリキー: データを一意に識別。パーティションキー単体、またはパーティションキー + ソートキーの複合キー
• パーティションキー: データのカテゴライズ。このキーのハッシュ値で保存先パーティションが決まる
  • 例: 個人情報テーブルで郵便番号をパーティションキーにすると、同じ郵便番号のデータは同じパーティションに保存される
• ソートキー: パーティション内でのデータの並び順を決める
  • パーティションキーでカテゴライズし、ソートキーでソートする
• GSI（Global Secondary Index）: 元テーブルとは別のパーティションキー+ソートキーでテーブルを再構成
• LSI（Local Secondary Index）: パーティションキーはそのまま、ソートキーだけ変える

参考: https://qiita.com/shibataka000/items/e3f3792201d6fcc397fd

FGAC（Fine Grained Access Control）

• IAMではテーブル単位のアクセス制御しかできない
• FGACを使えばレコード単位、キー単位での細かいアクセス制御が可能
• モバイルアプリから直接DynamoDBにアクセスする構成で有用

キャパシティユニット計算

RCU（読み込みキャパシティユニット）:

• 1RCU = 最大4KBの項目について、1秒あたり1回の強い整合性読み込み、または2回の結果整合性読み込み
• 4KBを超える項目は追加のRCUを消費する（8KB → 2RCU（強い整合性）or 1RCU（結果整合性））
• 例: 10RCUのテーブル → 4KB項目を1秒に10回（強い整合性）or 20回（結果整合性）読み込み可能

WCU（書き込みキャパシティユニット）:

• 1WCU = 最大1KBの項目について、1秒あたり1回の書き込み
• 書き込みサイズは1KBの倍数に切り上げ（500バイト → 1KB扱い）
• 例: 30WCUのテーブル → 1KB項目を1秒に30回書き込み可能

キャパシティモード

キャパシティの15%以上を利用する設計なら、プロビジョニングの方がコスト効率が良い。

DynamoDB Streams

• DynamoDBへの項目の追加・変更・削除をイベントとして検出する機能
• 24時間以内の変更の時系列順序を保持
• テーブル単位で有効化

DynamoDBトランザクション

• 複数テーブルへの同時読み取り・書き込みの一貫性を提供
• 同時に10件のテーブル操作を1つのトランザクションにまとめられる
• トランザクション内での同じアイテムに複数操作はできない
• グローバルテーブルは非同期のためサポートされない

参考: https://qiita.com/blackcat5016/items/c2af7d3d55093134bac3

Cross-Region Replication

• ユースケース: 災害対策（DR）、リージョン移行

RDS Proxy

• アプリケーションとRDSの間に配置されるプロキシ。データベースへのコネクションプールを効率的に管理する
• フェールオーバー時間を最大66%短縮（Aurora/RDS）
• LambdaからRDSに接続する場合は必須級 — Lambdaの同時実行でコネクションが乱立するのを防ぐ

Redshift — Concurrency Scaling（同時実行スケーリング）

• エンドポイントを変更せずに、自動で新しいクラスターを追加する機能
• メインクラスタのクエリ同時実行数を超過すると、スケーリングクラスタにルーティング
• スケーリングクラスタは読み取り専用

参考: Amazon Redshift Concurrency Scaling

5. ネットワーク設計

Global Accelerator

AWSのグローバルネットワークを使い、ユーザーに最も近いエッジロケーションからAWSリソースへのトラフィックを最適化するサービス。

オリジンに利用できるサービス: NLB、ALB、EC2、EIP

標準ルーティング vs カスタムルーティング:

• 標準ルーティング: 基本的にこちらを利用。AWSが最適なエンドポイントへ自動ルーティング
• カスタムルーティング: 特定のEC2に特定のクライアントを紐づけたい場合（ゲームサーバー等）

Direct Connect

オンプレミスとAWSを専用線で接続するサービス。

構築に必要な設定:

• VGW（Virtual Private Gateway）の設定とルート伝搬の有効化
• オンプレと通信するサブネットのルートテーブルにオンプレ宛のルートを登録

参考: https://dev.classmethod.jp/articles/whitepaper-translate-jpn-vpc-connectivity-options-01/

Transit Gateway Network Manager

• Transit Gateway、VPC、VPNのトポロジを可視化して管理するサービス
• 主な機能は可視化とモニタリング

参考: https://dev.classmethod.jp/articles/transit-gateway-network-manager-vpn/

EC2 プレイスメントグループ

EC2が起動する物理サーバーの配置を指定する設定。3つの戦略がある。

既存インスタンスをプレイスメントグループに追加する場合:

• インスタンスを一度停止
• AWS CLIで移動
• インスタンスタイプを統一し、グループ全体を再起動

参考: プレイスメントグループ

EC2 インスタンスの選択

主なインスタンスタイプと用途:

• T3: バースト可能な汎用タイプ。一時的なCPUスパイクがある中程度の負荷向け
• G2: 高度なグラフィック処理。低レイテンシネットワーキング付きGPUサーバー
• G4: 最もコスト効率の高いGPUインスタンス。ML推論やグラフィクス向け

EC2 ネットワーク

拡張ネットワーキング:

• 高帯域幅、低レイテンシーを実現する機能
• OSへのモジュールインストールとAWS CLIでの有効化が必要（一部OS/タイプでは最初から有効化済み）
• 100Gbpsネットワーク対応: C5, M5, R5, P3, T3など多数のインスタンスタイプ

IPv6対応: T3は未対応、T4は対応

インスタンスストア:

• EBSより高IOPS、高スループット、低遅延
• I3, F1, C5d, M6gdなど d がつくタイプで利用可能
• スナップショットは取得不可。再起動ではデータ維持、停止で消失
• 起動後にマウントが必要

EC2 AutoScaling メトリクス

トリガーとして使えるメトリクス:

• CPU/Memory
• SQSのキュー長
• ネットワークのIN/OUTトラフィック

ELB

トラフィック急増時のメトリクス:

クライアント証明書を使う場合:

• ALBではHTTPSの終端でクライアント証明書を扱えないため、NLBのTCPリスナー（443） でEC2に直接TLSを終端させる

スティッキーセッション: Cookie名は AWSELB（CLBでも同じ）

参考:

• NLBとProxy Protocol
• S3暗号化

BYOIP（自組織のグローバルIP持ち込み）

自組織が所有するグローバルIPアドレスをAWSに持ち込む手順:

1. ROAオブジェクトの作成

• ROA（Route Origination Authorization）: IPアドレスレンジとASNの対応を証明するデータ
• RPKIで発行したリソース証明書で署名

2. RDAP用X509証明書の作成

• RDAP（Registration Data Access Protocol）: WHOISの後継プロトコル（HTTPS + JSON応答）

3. 署名付き認可メッセージの作成

1|aws|account|cidr|YYYYMMDD|SHA256|RSAPSS

4. AWSへのプロビジョニング

aws ec2 provision-byoip-cidr --cidr address-range --cidr-authorization-context Message="$text_message",Signature="$signed_message"

参考: http://jpopf.net/opf-jp/opm16/jpopm16-08.pdf

RD Gateway Server

• インターネットからRDP接続する際に、HTTPS/443でプロキシするための機能
• 接続先と同じLAN内に配置し、証明書をインストールして利用
• クライアント側はRDP接続でRD Gateway経由を選択し、サーバー名とクライアント証明書を指定

参考: https://blog.pfs.nifcloud.com/20191711_RD_Gateway_RemoteDesktopConnection

6. セキュリティ

AWS Shield — Standard vs Advanced

DDoS保護サービス。無料のStandardと有料のAdvancedで保護レベルが大きく異なる。

Shield StandardでL7 DDoSを検知するには: AWS WAFを同時利用すれば可能。

参考:

• AWS Shield
• DDoS対策ホワイトペーパー

CloudHSM vs KMS — 暗号化キーの管理

選択の指針:

• FIPS 140-2 レベル3が必要 → CloudHSM
• 専用ハードウェアによるキー管理が要件 → CloudHSM
• コスト効率を重視、一般的な暗号化 → KMS

CloudHSMによるSSL/TLSオフロード

CloudHSMでHTTPS（SSL/TLS）の暗号化処理を実行できる。ハンドシェイクの流れ:

1. クライアントがサーバーにHelloメッセージを送信
2. サーバーがHelloメッセージと証明書を返す
3. クライアントが証明書を検証し、プリマスターシークレットをサーバーの公開鍵で暗号化して送信
4. サーバーがプリマスターシークレットをHSMに送り、HSMの秘密鍵で復号（ここがHSMの役割）
5. 両者がプリマスターシークレットからマスターシークレットを計算
6. 以降の通信はマスターシークレットで暗号化

ログを保存するために、S3 + SSE-S3による暗号化が利用可能（暗号化キーの管理はAWS側）

AWS Organizations — マルチアカウント管理

複数のAWSアカウントのセキュリティと請求をまとめて管理するサービス。

SCP（Service Control Policy）

• OU（Organizational Unit） でAWSアカウントをグループ化。OUは階層的に定義可能
• OUにSCPを割り当て、許可/拒否するAWSサービスを制御
• 継承: 上位OUのSCPは下位のOU/アカウントに継承される
• 記法はIAMポリシーと同じ（暗黙のDeny < 明示Allow < 明示Deny）
• ただし、サービスにアタッチされたIAMロールには影響しない

参考: https://dev.classmethod.jp/articles/organizations-scp-inheritance/

2つの機能セット

• すべての機能（推奨）: 一括請求 + SCP + 組織全体のAWSサービス管理 + アカウント作成・招待
• 一括請求機能のみ: 請求とアカウント作成・招待のみ

その他のポイント

• アカウント作成時: OrganizationAccountAccessRole（Admin権限）が子アカウントに自動作成される
• CloudTrail: マスターアカウントのCloudTrailを有効化すると全メンバーアカウントのログ取得可能。単一S3バケットに集約可能
• リザーブドインスタンス共有: Organizations内で共有可能。共有しない設定はマスターアカウントからのみ
• 子アカウント削除: スタンドアロン動作に必要な設定が事前に必要（支払い権限を持つIAMユーザーで設定変更）

AWS Control Tower

Organizationsの上に構築されたガバナンスサービス。主な機能:

• ログ集約
• コントロール適用（コンフォーマンスパック）
• 通知
• ID一元管理
• AWSアカウントの作成・プロビジョニング

Amazon Inspector

AWSリソースに対するセキュリティ評価サービス。「もしAの攻撃を受けたら問題ないか」という観点でテスト。

ルールパッケージ:

• ネットワークの到達可能性: インターネット、VPCピアリング、VPN経由でEC2にアクセス可能かどうか
• ホスト評価: EC2自体の脆弱性や問題のある設定をチェック

⚠️ 2024年時点の更新: Inspector v2ではエージェントレス脆弱性スキャンがGA（一般提供）となりました。ハイブリッドスキャンモード（SSMエージェント + エージェントレスの自動切り替え）が新規顧客のデフォルトです。Inspector Classicは2026年にサポート終了予定です。

7. 運用管理

Systems Manager — 統合運用管理プラットフォーム

Systems Managerは多数の機能を持つが、大きく4つのカテゴリに分かれる。

参考:

• Systems Manager Black Belt
• https://blog.serverworks.co.jp/tech/2020/04/16/systems_manager_yattemiyou/

運用管理

アプリケーション管理

変更管理

ノード管理

共有リソース — ドキュメント

管理対象インスタンスへの操作を定義したテンプレート。インスタンスの起動/停止/作成/削除やOS内コマンドの実行を事前定義し、オートメーション等で利用する。

有料機能

OpsCenter、AppConfig、パラメータストア、オンプレミスインスタンス管理、ディストリビューター、オートメーション

CloudFormation

DeletionPolicy — スタック削除時のリソース挙動

CreationPolicy

EC2インスタンスのプロビジョニング時に、ソフトウェアインストールやブートストラップ処理の完了を待ってからスタック作成を続行させる設定。CreationPolicyを指定しないと、インスタンスが起動しただけで（initスクリプト完了前に）スタック作成が続行される。

ヘルパースクリプト

CloudFormationでのEC2作成時に使う拡張ツール:

cfn-init          : EC2へのパッケージインストール、ファイル作成
cfn-signal        : インストール結果（OK/NG）を他のスタックに連携
cfn-get-metadata  : メタデータの取得
cfn-hup           : メタデータの更新を検知し次の処理に連携

CloudFormationでのLambda関数デプロイ

• AWS::Lambda::Function でLambdaのデプロイパッケージを参照
• すべてのランタイムに対して S3 内のオブジェクトの場所を指定可能
• 依存関係がない場合は、テンプレートに直接Lambda関数コードを記載可能

8. サーバーレス / API設計

API Gateway vs AppSync — いつどちらを使うか

API Gateway の詳細

メトリクス

Lambda統合時の504エラー

• API Gatewayはバックエンド処理を含め29秒でタイムアウトし504を返す
• INTEGRATION_FAILURE: 統合失敗（デフォルトでDEFAULT_5XX）
• INTEGRATION_TIMEOUT: 統合タイムアウト。Lambdaの処理が29秒以上かかった場合
  • 普段は正常で、たまに発生する場合はタイムアウトを疑う

AppSync / GraphQL

GraphQLとは:

• RESTの課題を解決するためにFacebookが開発したオープンソースのクエリ言語
• RESTがアーキテクチャスタイルであるのに対し、GraphQLは標準化された言語・型付け・仕様を持つ
• クライアント側から取得したいデータだけを選択して取得できる（RESTではバックエンド改修かクライアント側加工が必要だった）

AppSyncの概要:

• サーバーレスでGraphQLのバックエンドを実装できるサービス（GraphQL版のAPI Gateway的な位置づけ）
• 手順: ①スキーマ定義 → ②リゾルバー作成（VTLでスキーマとデータソースのマッピング） → ③エンドポイント生成

参考:

• https://www.webprofessional.jp/rest-2-0-graphql/
• https://dev.classmethod.jp/articles/relay-re-introduction-2019-appsync/

Amazon Connect

クラウドベースのコンタクトセンターサービス。

Contact Lens:

• 通話内容を機械学習で分析する機能
• 文字起こし、感情分析、キーワードアラート通知に対応

UpdateContactAttributes API:

• 連絡先の属性（発信者名、電話の理由、サービス品質等）をプログラム的に追加・更新できるAPI
• 従来は対応フロー内でのみ設定可能だったが、このAPIで通話中・通話後にCRM等からも更新可能に

参考: https://aws.amazon.com/jp/about-aws/whats-new/2018/08/amazon-connect-adds-new-contact-api-to-set-contact-attributes/

9. データ移行・ETL

なぜ複数の選択肢があるのか

データの移動・変換には「何を」「どこからどこへ」「どう加工するか」によって最適なサービスが異なる。

AWS DataSync

• オンプレ ↔ AWS間のデータ転送サービス
• 転送先: S3、EFS
• オンプレ側のサーバーにエージェントを導入して利用

参考: AWS DataSync とは

AWS Glue

S3、RDS、Redshift等のAWSサービス間のデータ連携を仲介するサーバーレスETLサービス。

主要コンポーネント:

ETL処理の流れ:

1. データソース（CSVファイル等）をクロールし、データカタログにメタデータを作成
2. データカタログの情報からコンソールでジョブを定義
3. スケジューラーでジョブの実行タイミングを設定
4. ジョブを実行し、抽出・変換・書き込みを実施

AWS Data Pipeline

⚠️ 2024年7月に新規顧客へのアクセスが停止されました。既存顧客は引き続き利用可能ですが、新規構築にはGlueやStep Functionsの利用が推奨されます。

• マネージドETLサービス
• AWS内のデータソースからデータを抽出し、任意の処理を行い、別のデータソースに保存する
• 例: S3 → Redshift、RDS → S3

付録: その他のサービス

Amazon Managed Blockchain

• Hyperledger FabricやEthereumを使って、スケーラブルなブロックチェーンネットワークを作成・管理するフルマネージドサービス
• ネットワーク参加には提案→投票→招待のプロセスが必要（投票ルールに基づく）
• IAMロールやSTSでの直接参加はできない。必ずネットワーク内の提案・投票プロセスを経る