はじめに

試験対策に備忘録として、
　分かりにくい
　間違えやすい
箇所をメモを記載していく

目次

RDSをIAMデータベース認証
RDS作成時にバックアップ保持期間
RDSのリードレプリカ作成
RDS（MySQL、PostgreSQL）をAuroraへ移行
RDS（MySQL）のスキーマ変更
RDSのバックアップ
RDSのモニタリング（拡張モニタリング）
RDSのメンテナンス
RDSリソースの削除防止
RDSでTrustAdvisor
Auroraの暗号化
Auroraのクローン
Auroraのバックトラック
Auroraの一時停止
Auroraのリードレプリカが遅い原因
DynamoDBのキャパシティユニット
DynamoDBとQLDBはVPC 内にない
DynamoDBグローバルテーブル
Redshiftへデータ移行
ElastiCacheの用途
ElastiCache for Redisの不正アクセス保護
QLDBのリアルタイム検索
CloudFormationの複数リージョンでデプロイ

RDSをIAMデータベース認証

IAM データベース認証
　MySQL　　：可能
　PostgreSQL：可能
　それ以外（oraclesqlServer）：不可
IAM データベース認証の制限
　DBインスタンスごとに１秒当たりの最大接続数あり
　 MySQL、推奨1 秒あたり 200 未満
認証トークンには 15 分の有効期間
複数のIAMユーザーまたはロールを同じデータベースユーザーアカウントにマップ可能

その他

EC2上のアプリケーションからは、EC2 インスタンスプロファイル認証情報を使用してデータベースにアクセス可能

RDS作成時にバックアップ保持期間

コンソールを使用してDBインスタンスを作成
　→　デフォルトのバックアップ保持期間は7日

Amazon RDS APIを使用してDBインスタンスを作成
　→　デフォルトのバックアップ保持期間は1日

※Auroraのデフォルトのバックアップ保持期間は1日

RDSのリードレプリカ作成

作成方法
RDSはプライマリのDBインスタンスからスナップショットを作成して、リードレプリカを作成
※スナップショット作成時に、プライマリDBインスタンスのI/Oが一定時間停止

RDSのマルチAZ配置の場合
　スタンバイDBインスタンスからスナップショットを作成するため、I/Oの停止を回避できる

自動バックアップを有効（保持期間を0以外の値に設定）
既存の第1層からリードレプリカ作成
RDS（MYSQL）　　　→　既存リードレプリカのリードレプリカを作成可能
RDS（MYSQL）以外　→　既存リードレプリカのリードレプリカを作成不可

RDS（MySQL、PostgreSQL）をAuroraへ移行

Aurora Readレプリカを使用して、MySQL用のAmazonRDSDBインスタンスからAmazonAuroraに移行
①RDS(MySQL)でAuroraリードレプリカ作成
②Auroraリードレプリカを昇格

RDS（MySQL）のスキーマ変更

RDS（MySQL）のリードレプリカのスキーマ変更等ができるため、下記の手順でDDLを反映する

①リードレプリカ作成
②リードレプリカのDBパラメーターグループでread_onlyパラメーターを「0」に設定
①リードレプリカにDDL操作を実行
②リードレプリカをDBインスタンスに昇格
　※昇格時、プライマリDBの書き込みを停止し、リードレプリカの更新を待つ

RDSのDR対策

目標復旧時間（RTO）
　災害後に作業状態に戻るのにかかる時間
目標復旧時点（RPO）
　RPOは時間単位でも表され、災害が発生したときに失われる可能性のあるデータの量
　（例）RPOが1時間の場合、災害が発生したときに最大1時間分のデータが失われる可能性

自動バックアップ

DBインスタンスの最初のスナップショットには、完全なDBインスタンス
　※その後、増分スナップショット
特定の時間指定ができない（8時間単位にランダム）
マルチAZ構成の場合、プライマリへの影響を減らすために、スタンバイでバックアップが実行
バックアップ保持期間は、PITR（ポイントタイムリストア）が可能
DBインスタンス削除時、同時に削除される（※削除しない方法もあり）
クロスリージョン自動バックアップをサポート

手動バックアップ

リージョンごとに最大100スナップショット
自動的に削除されない
複数のリージョンでサポート
最大20のAWSアカウントと共有可能

RDSのモニタリング

Amazon RDS Performance Insights
パフォーマンスの問題を分析し、解決するのに役立つ、データベースのパフォーマンス情報

Trusted Advisor
RDSアイドルDBインスタンス、RDSセキュリティグループアクセスリスク、RDSバックアップ、RDSマルチAZをチェック

Amazon RDS EnhancedMonitoring（拡張モニタリング）
DB インスタンスのオペレーティングシステムをリアルタイムでモニタリング

RDSのメンテナンス

ハードウェアのメンテナンス
シングル AZ 配置の場合、ダウンタイムあり。
マルチ AZ 配置の場合、メンテナンスのAZによって影響が変わる。セカンダリのAZメンテナンスであれば、影響なし。
OS のメンテナンス
延期可能
マルチ AZ 配置で対応し、セカンダリインスタンス適用後、フェールーバーし、プライマリインスタンス更新
DB エンジンレベルのアップグレード
プライマリ DB インスタンスとスタンバイ DB インスタンスの両方が同時にアップグレード
ダンタイム必要

RDSリソースの削除防止

CloudFormationの下記を設定し、リソースの削除を防止

RDSのインスタンス削除保護
　DeleteProtectionが「true」設定
スタック削除時、RDSのインスタンス削除保護
　DeletionPolicy属性に「Retain」設定
万が一削除された場合を考慮して、自動バックアップは削除しない　　
　DeleteAutomatedBackups属性に「False」設定
スタックそのもの削除保護
　・コンソールでスタックの「termination protection」を有効化
スタックが意図せずに更新または削除されるのを防止
　・スタックポリシーを設定

RDSでTrustAdvisor

5カテゴリで問題を検知する　
※メール通設機能設定、CloudWatchEvent(trustAdvisorEvent)→SNS通知

コストの最適化

長期間使用されていないDBインスタンスの検出
　　提案アクション：スナップショット作成後、インスタンス削除
RDS の利用状況をチェック
　　提案アクション：リザーブドインスタンスの購入提案

セキュリティ

RDSのセキュリティグループをチェック
RDSのスナップショットが公開に設定されているチェック

耐障害性

自動バックアップのチェック
単一AZのRDSをチェック

Auroraの暗号化

　　Aurora →　スナップショット →　Aurora（暗号化）※リストア時にKMSキー指定可能
　　RDS →　スナップショット　→　暗号化スナップショット　→　RDS（暗号化）

Auroraのクローン

クローンはコピーではない。
同一リージョン内の同一AZでのみ作成可能（※VPCは異なってもOK）
Aurora Serverless v1 DBでクローン可能
最大15個まで
クロスアカウントのクローン作成可能

Auroraのバックトラック

クラスター作成時、リストア時のみ設定可能
最大72時間
既存のDBクラスターに反映
単一テーブルのみ選択し、戻すことは不可

Auroraの一時停止

すべてのリードレプリカを削除後、プライマリRDSDBインスタンスを停止する
※DB インスタンスは最大 7 日間停止。その後、自動起動

Auroraのリードレプリカが遅い原因

レプリケーションでタイムラグがあり、遅延する原因

クラスターで書き込みアクティビティの突然の急増
リードレプリカのクラスター内のインスタンスが小さい
リードレプリカに複数のセッションが同時アクセス
ネットワークの通信障害

調査

AuroraReplicaLag メトリクスでタイムラグを測定可能
拡張モニタリングでCPU使用率、DBコネクションの監視

DynamoDBのキャパシティユニット

パーティションのサポートされる最大サイズ：10GB
単一項目のプライマリキーに対して、下記のスループットを提供
　最大RCU：3,000
　最大WCU：1,000

（例）16KB/秒強力整合性で読み取り10回を行いたい
　強力整合性　1RCU　＝　4 KB/秒

　1回：16KB/秒　/ 4KB/秒　= 4RCU
　10回：4RCU × 10　= 40RCU

（例）10WCU 10WCU
　Read
　　　強力整合性　1RCU　＝　4 KB/秒
　　　強力整合性 4 KB/秒 × 10RCU = 40KB/秒
　　　結果整合性 40KB/秒 × 2倍 = 80KB/秒
　　　トランザクション 40KB/秒 × 1/2倍 = 20KB/秒
　Write
　　　強力整合性　1WCU　＝　1 KB/秒
　　　強力整合性 1 KB/秒 × 10RCU = 10KB/秒
　　　トランザクション 10KB/ × 1/2倍 = 5KB/秒

(例)5,000RCU 500WCU　テーブル：50GB
　(500/1000）+（5000/3000）= 2.1〜3 ≒ 3パーティション
　50GB / 10GB = 5パーティション
　MAX(3,5) = 5パーティション

DynamoDBとQLDBはVPC 内にない

DynamoDB や Amazon QLDB などのデータベースサービスは VPC 内で実行されない

QLDB はインターフェイスエンドポイント使用（ENI）
DynamoDB はゲートウェイエンドポイント使用

DynamoDBグローバルテーブル

テーブル名、LSI、GSIがリージョン間で一貫
TTL設定がリージョン間で一貫
暗号化設定がリージョン間で一貫
DynamoStreamが有効
DynamoDB Auto Scaling有効またはオンデマンドキャパシティ有効

Redshiftへデータ移行

DMSでデータ移行
　ダウンタイム最小限、ペタバイト規模のデータウェアハウスに統合可能
　移行方法：データ元　→　DMS　→　S3　→　DMS　→　RedShift　※S3を使用
KinesisDataStreamsでデータ移行
　１秒に数ギガバイトのデータをキャプチャし、移行可能
　ただし、Redshift側で予想されるデータ処理のためにシャドーを手動でプロビジョニングが必要
EMRでデータ移行
　大量のデータを処理可能。Redshiftにコピーするためのカスタム移行ジョブの開発が必要

ElastiCacheの用途

複雑な計算が必要となるデータをキャッシュ
Pub/Sub
ランキングボード
位置情報
セッションストア
リーダーボード

ElastiCache for Redisの不正アクセス保護

auth-tokenを使用する
転送中と保存中のデータの暗号化
セキュリティグループのインバウンド設定（指定のポート許可）

QLDBのリアルタイム検索

Amazon Kinesis Data Streamsにリアルタイム配信可能

リアルタイム分析
履歴分析
ワード検索（ElasticSearchに登録）

CloudFormationの複数リージョンでデプロイ

スタックセットを介してテンプレートを複数のリージョンにデプロイ

セキュリティ

保管中のデータの暗号化

RDS　：任意
Aurora：任意
ElastiCache：任意
DocumentDB：任意
Neptune：任意
Redshift：任意
DynamoDB：デフォルトで暗号化
QLDB：デフォルトで暗号化（※CMKのサポートなし）

転送中のデータの暗号化

RDS　：任意（証明書の設定が必要）
Aurora：任意（証明書の設定が必要）
ElastiCache：任意（パフォーマンス影響有）
DynamoDB：TLS
DocumentDB：任意（TLS）
DocumentDB：TLS
Redshift

最後に

なかなかデータベースの勉強大変ですね。
ユースケース等を調べたり、違いを理解したり。。
実際にコンソール触って、RDSやAuroraのイメージを理解する必要があると感じました。