AWS Certified Data Engineer Associate
最終確認：2026年5月
DEA-C01 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
ストリーミング取り込みのためのKinesisサービスを選択する。
サブ秒単位のコンシューマー制御処理 → Kinesis Data Streams。オプションのフォーマット変換を伴うS3/Redshift/OpenSearchへの完全マネージド型配信 → Kinesis Data Firehose。
理由: KDSはレコードを保持し（24時間〜365日）、複数のコンシューマーをサポートする。Firehoseにはリプレイ機能がないが、リプレイを犠牲にすることでゼロオペレーションの配信を実現する。
ピーク時にストリームでProvisionedThroughputExceededエラーが発生する。
リシャードする。各シャードは1 MB/秒または1,000レコード/秒の取り込み、2 MB/秒の出力に対応する。均一なパーティションキーを使用し、コンシューマーあたり2 MB/秒を超える場合はEnhanced Fan-Outを有効にする。
理由: ホットパーティションキーはトラフィックを1つのシャードに集中させる。ランダムまたはハッシュベースのキーは負荷を分散する。
ストリーミングワークロードが突発的で予測不能なため、手動でのリシャーディングが運用上の負担となっている。
オンデマンドキャパシティモードのKinesis Data Streamsを使用する。デフォルトで200 MB/秒まで自動スケーリングし、データ量に応じて課金される。
同じストリームを読み取る複数のコンシューマーが、シャードあたりの読み取り制限である2 MB/秒に達する。
Enhanced Fan-Outを使用する。各コンシューマーは、プッシュベースのHTTP/2 SubscribeToShardを介して、シャードあたり専用の2 MB/秒を受け取る。
プロデューサー側のアプリケーションからの取り込みスループットを最大化する。
集約とコレクション機能を備えたKinesis Producer Library (KPL)を使用する。複数のユーザーレコードを最大1 MBの1つのKinesisレコードにバッチ処理し、PUTコストを削減する。
理由: 単一レコードのPutRecordはレート制限があり、50,000イベント/秒では高価になる。KPLはクライアント側で集約を行う。
JSONクリックストリームをイベント時間でパーティション分割されたParquet形式でS3に保存する。
Glue Data Catalogテーブルとイベントタイムスタンプによる動的パーティション分割を使用して、レコードフォーマット変換（JSON → Parquet）を行うFirehoseを使用する。
理由: Parquetとパーティション分割によりAthenaのスキャンコストが大幅に削減される。動的パーティション分割により、別途ETLステップが不要になる。
Firehoseの変換または配信で一部のレコードが失敗する。それらをリプレイのためにキャプチャする必要がある。
S3バックアップを`AllData`または`FailedDataOnly`で設定する。失敗したレコードは、エラーメタデータとともに設定されたプレフィックスに保存される。
ブローカーAZに障害が発生した場合でもMSKでデータ損失がないことを保証する。
3つのAZ全体でレプリケーションファクターを3以上にし、プロデューサーの`acks=all`で`min.insync.replicas=2`を設定する。ZooKeeperレスのKRaftまたは3AZブローカー配置を介してMulti-AZを有効にする。
Kafka Connectクラスターを管理することなく、MSKからS3、OpenSearch、またはRDSにストリーミングする。
マネージドコネクタ（Confluent S3 Sink、CDC用のDebezium）を備えたMSK Connectを使用する。WCUごとにワーカーが自動スケーリングされる。
トピックはキーごとのレコードの最新バージョンを保存し、古いバージョンは破棄できる。
トピックの`cleanup.policy=compact`を設定する。Kafkaは各キーの最新値を保持し、古い同じキーのレコードはコンパクションの対象となる。
オンプレミスのNFSからS3へ、Direct Connect経由で毎週10 TBを定期的に転送する。
オンプレミスエージェントとスケジュールされたタスクを備えたAWS DataSyncを使用する。データ整合性を検証し、増分転送と並列転送をサポートする。
理由: DataSyncはaws-cli syncよりも高速で、帯域幅スロットリング、再試行、検証をネイティブに処理する。
SaaS API（Salesforce、ServiceNow、Zendesk）からS3へ、スケジュールに従ってデータをプルする。
AWS AppFlowを使用する。マネージドコネクタ、OAuth処理、スケジュールまたはイベントトリガー、Parquet形式でS3に書き込み。
オンプレミスのSQL ServerからAurora MySQLへ、最小限のダウンタイムで継続的な変更をレプリケートする。
フルロードとCDCタスクを備えたAWS DMSを使用する。DMSの前に、異種スキーマ/コード変換のためにSchema Conversion Tool (SCT)を使用する。
DMSレプリケーションインスタンスが失敗し、レプリケーションが中断する。
レプリケーションインスタンスでMulti-AZを有効にする。別のAZに同期スタンバイを設定し、自動フェイルオーバーを有効にする。
ETLパイプラインなしでOLTP Auroraデータに対するほぼリアルタイムの分析が必要。
RedshiftへのAurora zero-ETL統合を使用する。AuroraデータをRedshiftに継続的にレプリケートし、クエリは数秒以内に新しいデータを参照できる。
理由: OLTPからウェアハウスへのユースケースにおけるDMS / Glue / カスタムCDCパイプラインを不要にする。
オンプレミスからS3へ100 TBの履歴アーカイブを移動する。帯域幅に制限がある。
AWS Snowball Edge Storage Optimizedを使用する。物理デバイスを現場に発送し、データをコピーして返送する。
ソースJSONにネストされた配列があり、ダウンストリームのリレーショナル分析にはフラット化された行が必要。
Glue PySparkの`Relationalize`変換（またはDataFrameの`explode()`）を使用して、ネストされた配列を個別の行/テーブルにフラット化する。
Glue Crawlerが、不整合なCSVデータから曖昧な型（`choice<int,string>`）を推論する。
`ResolveChoice`変換を適用し、特定の型にキャストするか、構造体に投影する。または、スキーマを強制することでソースで修正する。
Glue ETLジョブがS3の増え続けるデータに対して1時間ごとに実行される。新しいファイルのみを処理する必要がある。
Glueジョブブックマークを有効にする。Glueは処理済みのファイル/パーティションを追跡し、再実行時にそれらをスキップする。
理由: データセット全体の再処理を回避する。増分ETLパイプラインに必要。
大規模な集約中にGlue SparkジョブがドライバーでOutOfMemoryErrorにより失敗する。
G.2XまたはG.4Xワーカー（より多くのドライバーメモリ）に切り替えるか、`--enable-glue-datacatalog`プッシュダウン述語を有効にしてシャッフルされるデータを減らす。
マネージドインフラストラクチャを使用して、Kinesisソースに対して連続的なSpark Structured Streamingを実行する。
AWS GlueストリーミングETLジョブを使用する。内部ではSpark Structured Streamingが動作し、S3へのチェックポイントも行う。
ビジネスアナリストがコードを書かずにデータをクリーンアップおよび変換する必要がある。
AWS Glue DataBrewを使用する。視覚的なレシピベースの変換（250以上）、プロファイリング、リネージ機能を提供する。S3、Redshift、RDSに出力可能。
CrawlerがData Catalogを正常に更新した後にのみGlue ETLジョブを実行する。
条件付きトリガーを備えたGlue Workflowを使用する。Crawlerが成功した場合 → ETLジョブをトリガー。失敗した場合 → スキップ/アラーム。
CrawlerがすべてのCSV列を`string`と推論する。日付型と数値型が必要。
クロールする前にカスタムGlue分類器（Grokパターンまたはカラムヒント）を追加する。または、明示的な型を持つヘッダー行を事前に書き込む。
Kafka上の複数のプロデューサー/コンシューマーが、互いに壊すことなくスキーマ進化を必要とする。
互換性ルール（BACKWARD/FORWARD/FULL）を備えたAWS Glue Schema Registryを使用する。プロデューサーはスキーマを登録し、コンシューマーはスキーマを取得して検証する。
Spark ETLにEMRとGlueのどちらを選択するか。
詳細なチューニングを伴う長時間実行のカスタムSpark、複数のフレームワーク（Hive、Presto、Flink）→ EMR。Glue Data Catalog統合を備えたサーバーレスのジョブごとのETL → Glue。突発的/予測不能なSpark → EMR Serverless。
断続的なSpark/Hiveジョブ。ゼロクラスタ運用とアイドルコンピューティングの排除を希望。
EMR Serverlessを使用する。低レイテンシ起動のための事前初期化されたキャパシティプールを備え、ジョブごとにスケールし、vCPU時間単位で課金される。
コスト最適化されたEMRのために、オンデマンドのコアノードとスポットのタスクノードを組み合わせる。
タイプごとのターゲットキャパシティを持つInstance Fleetsを使用する。HDFSの安定性のためにコアフリートをオンデマンドにし、多様なインスタンスタイプを持つタスクフリートをスポットにする。
Kubernetesに標準化し、EMR Sparkジョブを他のワークロードとクラスターを共有させたい。
EMR on EKSを使用する。Sparkは既存のEKSクラスター上でPodとして実行され、IRSAを介してインフラとIAMロールを共有する。
ウィンドウ集約とexactly-onceセマンティクスによるステートフルなストリーミング。
Apache Flink向けKinesis Data Analyticsを使用する。マネージドFlinkランタイムで、S3へのチェックポイント、自動スケーリングに対応。
Kinesisストリーム上で軽量なレコードごとの変換（各1ミリ秒未満）。
KDS上のEvent Source Mappingを備えたLambdaを使用する。`BatchSize`、`MaximumBatchingWindowInSeconds`、`ParallelizationFactor`を調整する。
理由: Lambdaは、小さなレコードごとの作業においてKCL/Glue Streamingよりも安価である。
Step Functionsのステップが一時的なスロットリングで時々失敗する。再試行後にアラートを送信する。
`Retry`ブロックを`ErrorEquals: ["Lambda.ThrottlingException", "States.TaskFailed"]`、`IntervalSeconds`、`MaxAttempts`、`BackoffRate=2`で追加する。さらに、通知ステートへの`Catch`を追加する。
500,000個のJSONファイルをLambda変換を介して並行処理する。
`MaxConcurrency`とS3からのItemReaderを備えたStep Functions分散Mapステートを使用する。数千の並列Lambda呼び出しにファンアウトする。
クロスサービス依存関係（Glue + Redshift COPY + Lambda + Eメール）とリネージ要件を持つ複雑なDAG。
Amazon MWAA（Managed Workflows for Apache Airflow）を使用する。AWSサービス向けのネイティブなAirflowオペレーターを備え、Git駆動型のDAG同期が可能。
デプロイが障害を引き起こした場合、DAGの変更をロールバックする必要がある。
DAGをバージョン管理されたS3バケットに保存し、S3バージョニングを介して同期する。または、Gitリポジトリで環境ごとのブランチを持ち、CIを介してS3同期を行う。
生データは30日間ホット、次の90日間は時々アクセス、7年間アーカイブ。
S3ライフサイクル: 0〜30日はStandard、30日後にStandard-IAへ移行、120日後にGlacier Flexible Retrievalへ移行、7年後に期限切れ。
アクセスパターンが予測不能で、手動のライフサイクルポリシーでは不適切。
S3 Intelligent-Tieringを使用する。アクセスパターンに基づいて、オブジェクトをFrequent / Infrequent / Archive Instant Access / Archive / Deep Archive間で自動的に移動する。オブジェクトごとの監視料金が発生するが、Frequent/IAでは取り出し料金はかからない。
データレイクでのAthenaクエリが遅い。パーティションに数千個の1～5 KBのJSONファイルがある。
Glue/EMRジョブを介して小さなファイルを約256 MBのParquetファイルに圧縮する。マネージドテーブルフォーマットにはIcebergの`OPTIMIZE`またはHudiのコンパクションを使用する。
理由: Athena/Sparkのファイルごとのオーバーヘッドは、小さなファイルの場合に支配的になる。最適なサイズは約128～512 MBのParquetファイル。
1つのバケットに複数のチームがあり、それぞれ異なるプレフィックススコープのアクセスパターンが必要。
S3 Access Pointsを使用する。これは、チームごとの名前付きエンドポイントで、独自のポリシーがプレフィックスにバインドされる。巨大なバケットポリシーよりもシンプル。
異なるコンシューマーが同じS3オブジェクトの異なるビュー（PIIの編集済み、要約済みなど）を必要とする。
S3 Object Lambda Access Pointを使用する。GETリクエストはLambdaを呼び出し、オブジェクトをその場で変換する。コンシューマーは変換されたビューを見る。
S3データレイク上でACIDトランザクション、スキーマ進化、タイムトラベルが必要。
Apache Icebergテーブル（Glue Catalog + S3ストレージ）を使用する。アトミックコミット、MERGE/UPDATE/DELETE、スナップショット分離、パーティション進化に対応。
理由: Hiveスタイルの追記のみのS3は行レベルの更新をサポートしない。Iceberg/Hudi/Deltaがこの問題を解決する。
データレイクテーブルに複数の書き込み者と読み込み者がいて、トランザクションの一貫性と行レベルのアクセス制御が必要。
Lake Formationガバナンス対象テーブル（Icebergバックアップ）をLF-Tagsと組み合わせて権限管理を行う。
Athena、Redshift Spectrum、EMR、Glue ETLのすべてが共有メタデータストアを必要とする。
AWS Glue Data Catalogを使用する。すべてのアナリティクスサービスが利用できる単一のHive互換メタストア。
Redshiftクラスターでストレージをコンピューティングとは独立してスケールさせる必要がある。
マネージドストレージ（RMS）を備えたRA3ノードを使用する。ストレージはS3でバックアップされ、コンピューティングは個別にスケールする。AQUA、コンカレンシースケーリング、フェデレーテッドクエリに必要。
Redshiftクエリが`created_at`で頻繁にフィルタリングされるため、フルテーブルスキャンが遅い。
`created_at`にソートキー（または`created_at`を含む複合ソートキー）を定義する。Redshiftはゾーンマップを使用して、スキャン時にブロックをスキップする。
`orders`と`order_items`間の頻繁な結合で、クエリのシャッフルが遅延の原因となっている。
両方のテーブルで同じDISTKEY（`order_id`）を使用する。共存する行は、結合時のネットワークシャッフルを回避する。
理由: キー分散により、結合する行が同じコンピューティングノードに共存する。
約1 GBのgzip圧縮CSVファイル32個を4ノードのRedshiftクラスターにロードするのが遅い。
単一のマニフェストから並行してCOPYを実行する。ファイル数をスライス数の倍数（スライス数 = ノード数 × vCPU）にする。4ノードのra3.xlplusは8スライス → 32ファイル = スライスあたり4ファイル。
S3にある5 TBのコールドParquetデータとホットなRedshiftファクトテーブルを結合したいが、データをロードしたくない。
Redshift Spectrumを使用する。Glue Catalog内の外部テーブルを使用し、クエリはRedshiftコンピューティングでS3から直接データを読み取る。
ピーク時のレポートチームのクエリがETLワークロードを遅延させる。両方とも同じクラスターで実行されている。
関連するWLMキューでコンカレンシースケーリングを有効にする。Redshiftはオーバーフローしたクエリをスケールアウトされたクラスターに透過的にルーティングする。
ダッシュボードクエリが3つの大きなテーブルを繰り返し結合・集約しており、レイテンシが高い。
自動更新付きのマテリアライズドビューを使用する。Redshiftが事前に計算された結果を維持し、クエリはマテリアライズドデータから読み取る。
断続的な分析ワークロード。プロビジョニングされたクラスターがアイドル状態になっている。
Amazon Redshift Serverlessを使用する。ワークロードごとにRPUを自動プロビジョニングおよびスケールし、RPU時間単位で課金される。運用は不要。
RedshiftデータとライブのAurora MySQLデータをETLなしで結合する必要がある。
Redshift Federated Queriesを使用する。Auroraを指すEXTERNAL SCHEMAを作成し、クエリはライブRDS接続を介して述語をプッシュダウンする。
ダッシュボードがレンダリングのたびに注文 + 顧客 + 製品を結合するため、スタースキーマでは遅すぎる。
ワイドファクトテーブルまたはマテリアライズドビューに非正規化する。BIワークロードでは、書き込み時に解決される読み取り時の結合が好まれる。
S3が`year/month/day/hour`でパーティション分割されており、`MSCK REPAIR TABLE`に30分以上かかる。
Athenaパーティションプロジェクション（Glue Catalogパーティションエントリなし）を有効にする。テーブルプロパティでパーティションキーの型と範囲を定義する。
理由: Athenaは、プロジェクションルールからクエリ時にパーティションの場所を計算する。MSCKもGlue APIのスロットリングも発生しない。
Athenaクエリ結果をParquet形式に変換し、パーティション分割して1回の操作で行う。
`format=PARQUET`、`partitioned_by=ARRAY['region']`、`external_location`をターゲットS3プレフィックスに設定したCREATE TABLE AS SELECT (CTAS)を使用する。
同じクエリテンプレートが一日を通して異なるパラメーター値で実行される。
Athenaプリペアドステートメントを使用する: パラメーター値を指定して`PREPARE`、`EXECUTE`。再パースを回避し、クリーンなパラメータ化を実現する。
IoTデバイスの読み取り値。 (1) 特定の時間ウィンドウ内のデバイスのすべての読み取り値、(2) デバイスごとの最新の読み取り値が必要。
PK = `device_id`、SK = `timestamp`。PK = `device_id`、SK = 反転した`timestamp`を持つGSIを使用する（または`ScanIndexForward=false LIMIT 1`でQueryを使用する）。
セッションテーブルが無制限に増大し、古いセッションは7日後に削除できる。
`expires_at`エポック属性にDynamoDB TTLを有効にする。DynamoDBは期限切れのアイテムをコストなしで削除する（約48時間以内）。
IoTセンサーデータ: 直近7日間のホットクエリ、2年間の時折のクエリ。
Amazon Timestreamを使用する。最近のデータにはメモリストア（高速クエリ）、履歴データには磁気ストアへの自動階層化。
Cassandra互換で、高書き込みの時系列データを90日間保持するストア。
行にTTLを設定したAmazon Keyspacesを使用する。Cassandra CQLと互換性があり、サーバーレスキャパシティ、クラスター管理不要。
OpenSearchのストレージコストが増加し、古いインデックスはめったにクエリされない。
OpenSearch ISMポリシーでデータを階層化する: ホット → UltraWarm (S3バックアップ) → Cold。Coldティアはデタッチされるが、オンデマンドで検索可能。
ダウンストリームで消費される前に、ETL出力が1,000行以上であり、列のnull率が2%未満であることを検証する。
AWS Glue Data Qualityルール (DQDL): `RowCount >= 1000`、`Completeness "col" > 0.98`を設定する。ルールが失敗した場合、パイプラインは停止する。
EMR上のカスタムSparkベースのデータ品質フレームワークで、列レベルの統計的チェックが必要。
Spark上のAWS Deequライブラリを使用する。制約（`isComplete`、`hasMin`、`isContainedIn`）を定義し、DeequはSparkジョブとして実行され、メトリクスを出力する。
アナリストがアカウント間でデータ製品を発見し、アクセスをリクエストし、リネージを理解する必要がある。
Amazon DataZoneを使用する。ビジネス用語集、アクセスワークフロー、リネージを備えたデータカタログであり、Lake Formation、Redshift、RDSにわたる。
Lambdaがレコードごとの処理メトリクスを出力するが、CloudWatch PutMetricDataのコストが高い。
CloudWatch Embedded Metric Format (EMF)を使用する。EMFスキーマでJSONをログに記録すると、CloudWatchはログからメトリクスを抽出し、PutMetricDataごとのコストはかからない。
過去7日間で実行時間が1時間を超えたすべてのGlueジョブを検索する。
CloudWatch Logs Insightsクエリを使用する: `fields @timestamp, @message | filter @message like /JobRunDuration/ | parse @message "duration=*" as d | filter d > 3600`。
Glueジョブが遅い。リソース不足か、シャッフルが偏っているかを知る必要がある。
Glueジョブメトリクスと可観測性を有効にする。CloudWatchは、最大DPU使用量、エグゼキュータ利用率、ステージごとのシャッフル読み取り/書き込みを表示する。
Glue Sparkジョブのサイズが実行ごとに10倍変動するため、小さな入力に対しては過剰プロビジョニングされている。
Glueオートスケーリング（Glue 3.0以降）を有効にする。ステージの並列処理に基づいて、実行中にワーカーが追加/削除される。
Athenaが1日分のデータに触れるクエリに応答するために5 TBをスキャンしており、コストが高すぎる。
日付でパーティション分割し、WHERE句がパーティションキーを使用するようにする。パーティションプルーニングを示す`EXPLAIN`で検証する。
JSONデータレイクでのAthenaクエリが遅く、コストも高い。
Parquet（カラムナー）またはORC形式に変換する。必要なカラムのみを読み取り、ネイティブ圧縮によりスキャンコストと時間を削減する。
データ損失のリスクなしにEMRクラスターのコスト最適化を行う。
コアノードをオンデマンド（HDFS / シャッフルをホスト）にし、タスクノードを多様なインスタンスタイプを持つInstance Fleetsを介してスポットにする。
Redshiftクラスターが24時間稼働しており、オンデマンド料金が高額。
Redshift Reserved Nodes（1年または3年、全額前払い/一部前払い/前払いなし）を使用する。定常状態のワークロードでは、オンデマンドと比較して最大約75%割引。
毎日500 GB / 50クエリのワークロードに対して、Athena、Redshift、EMRのいずれかを選択する。
アドホックで頻度が低い場合 → Athena（スキャンされたTBあたり課金）。予測可能なBIダッシュボード → Redshift（RA3 + Reserved）。大量のカスタムSpark → EMR。
理由: Athenaはスキャンされたデータ量に応じて課金され、Redshiftはクラスター時間あたり、EMRはインスタンス時間あたりに課金される。課金モデルをアクセスパターンに合わせる。
Glueジョブが複数回同時にトリガーされる。一度に1つの実行に制限したい。
Glueジョブの`MaxConcurrentRuns=1`を設定する。後続のトリガーは待機し、並行状態の破損を排除する。
Glue ETLの再試行により、S3ターゲットで重複する出力行が生成される。
冪等性: 実行ごとに一時プレフィックスに書き込み、S3マルチパート`CompleteMultipartUpload`を介してアトミックリネームを行うか、アップサートにはIceberg/Hudi MERGEを使用する。
ETLの不具合によりAurora MySQLに破損した行が書き込まれた。数分前の時点に回復する必要がある。
Aurora Backtrack（MySQL互換のみ）を使用する。スナップショットからの復元なしに、クラスターを目標時点まで巻き戻す。
パイプラインが正しいS3オブジェクトを破損したデータで上書きしてしまった。
S3バケットバージョニングを有効にし、以前のバージョンを復元する。MFA Deleteと組み合わせて、誤ったバージョン期限切れを防ぐ。
災害復旧のために、EBSスナップショットの作成、保持、クロスリージョンコピーを自動化する。
タグごとのポリシー（スケジュール、保持、クロスリージョンコピー）を設定したAmazon Data Lifecycle Manager (DLM)を使用する。
MSKコンシューマーがプロデューサーに追いつかなくなっており、これを検出し、アラートを発する必要がある。
コンシューマーグループごとのCloudWatchメトリクス`MaxOffsetLag`を使用する。しきい値を超えたらアラームを発生させ、コンシューマー数をスケールアップするか、パーティションの並列処理を増やす。
Kinesisコンシューマーが遅延していることを検出したい。
CloudWatchメトリクス`GetRecords.IteratorAgeMilliseconds`を使用する。60秒を超えると、通常はコンシューマーのリソースが不足していることを意味する。
チューニングのために、過去1時間で最も遅かったRedshiftクエリを特定する。
`SVL_QLOG` / `STL_QUERY` / `SYS_QUERY_HISTORY`をクエリして実行時間上位のエントリを特定し、`SVL_QUERY_REPORT`を使用してステップごとの詳細を確認する。
営業チームは、共有データレイク内で割り当てられたリージョンの行のみを参照できるようにする。
Lake Formationの行レベルセキュリティをデータフィルター経由で実装する: IAMプリンシパルごとに`region IN ('NA', 'EU')`を設定する。単一のテーブルに対して、プリンシパルごとのフィルタリングされたビュー。
ヘルスケアテーブルで、アナリストはSSNと診断コードの列を参照できないようにする。
Lake Formationの列レベル権限を使用する: テーブルに対するSELECT権限を付与し、`ssn`と`diagnosis_code`を除く。
多数のチームと多数のテーブルがあり、テーブルごとの権限付与では管理が困難。
Lake Formation LF-Tagsを使用する。テーブル/列にタグを付け、タグベースの権限をプリンシパルに付与する。新しいテーブルを追加する際は適切なタグを付けるだけでよい。
アカウントAにデータレイクがあり、アカウントBのアナリストが特定のテーブルに読み取りアクセスする必要がある。
RAMを介したLake Formationクロスアカウント共有を使用する。アカウントAはアカウントBのIAMプリンシパル/アカウントに権限を付与し、アカウントBはAthena/Redshift Spectrumを介してアクセスする。
Redshift内部での行レベルセキュリティ（Lake Formationではない）。
RedshiftネイティブRLSポリシーを使用する: セッションコンテキスト（`current_user`、`session_role`）を参照する述語とともに`CREATE RLS POLICY`を作成する。ポリシーをテーブルにアタッチする。
コンプライアンスにより、Redshift暗号化のために監査証跡付きの顧客管理キーが必要。
顧客管理KMSキーでRedshiftクラスターを暗号化する。キーローテーションを有効にし、CloudTrailがCMKに対するすべてのDecrypt操作をキャプチャする。
Glue ETLジョブの入力/出力を企業管理キーで暗号化する。
S3 + CloudWatch Logs + ジョブブックマーク用のCMKを備えたGlueセキュリティ設定を使用する。Glueロールにキーに対する`kms:Decrypt`/`Encrypt`権限を付与する。
S3データレイクに存在するPII（氏名、SSN、Eメール）を検出および分類する。
Amazon Macieを使用する。S3上で機械学習駆動型の機密データ検出を行い、オブジェクトの場所とPIIタイプを含む検出結果を生成する。
データレイクバケット内のすべてのS3 GetObject / PutObjectを監査する。
バケットのCloudTrailデータイベントを有効にする。CloudTrailはデフォルトで管理イベントのみをログ記録するため、データイベントは明示的に有効にする必要がある。
理由: データイベントはイベントごとに課金されるため、コストを管理するために機密性の高いバケットのみにスコープを限定する。
すべてのS3アクセスについて誰が/いつ/どのIPからアクセスしたかが必要だが、CloudTrailデータイベントは高すぎる。
S3サーバーアクセスログを使用する。無料で、別のログバケットに配信される。CloudTrailよりも詳細は少ないが、リクエスター + IP + パスをカバーする。
バケットポリシーで許可されていても、アカウント内のどのバケットも誤って公開されないようにする。
アカウントレベルでS3 Block Public Accessを有効にする。これはバケットレベルのポリシーを上書きし、ガードレールとして強制される。
VPC内のRedshiftがパブリックインターネットを経由せずにS3から読み取る必要がある。
RedshiftサブネットのルートテーブルにS3 Gateway Endpointを設定する。トラフィックはAWSバックボーンを経由し、NATもIGWも不要。
Glue ETLジョブがプライベートサブネット内のRDSにアクセスし、かつGlue Data Catalog APIを呼び出す必要がある。
RDS VPC上のGlue接続と、`glue.amazonaws.com`用のインターフェースVPCエンドポイント + S3 Gateway Endpointを使用する。
Glue ETLがS3読み取り、Redshift書き込み、Secrets Manager読み取りを必要とする。
最小限の権限ポリシーを持つ単一のGlue実行ロールを使用する: ソースプレフィックスに対する`s3:GetObject`、`redshift-data:ExecuteStatement`、特定のシークレットARNに対する`secretsmanager:GetSecretValue`。
異常なデータアクセスパターン（以前にデータレイクにアクセスしたことのないIAMユーザーによる大量ダウンロードなど）を検出する。
GuardDuty S3 Protectionを使用する。IAMプリンシパルごとの行動ベースラインを設定し、異常なアクセス量/パターンに関する検出結果を生成する。
コンプライアンスにより、財務データに対して7年間のWORM（一度書き込んだら複数回読み取り）保持が必要。
コンプライアンスモードと7年間の保持期間を持つS3 Object Lockを使用する。ルートユーザーでさえ削除できず、SEC 17a-4 / FINRAに準拠する。
HIPAA / SOC 2監査のための継続的なコンプライアンス証拠収集。
事前構築済みフレームワークを備えたAWS Audit Managerを使用する。CloudTrail、Config、Security Hubから証拠を自動収集し、監査対応レポートを生成する。
