蚘事の目的

AWS Database Specialty で
自分がやっおお詊隓に出そうだが、
間違えやすい、間違えた箇所をたずめたした。

パッず知らない単語を探す皋床にご掻甚ください。
あずは今はなき Database Specialty の思い出を振り返るくらいでも。

猛スピヌドで蚘茉しおいたので、誀蚘はご愛嬌。
䜕かの圹には立぀はず !

CloudTrail

DynamoDB のコントロヌルプレヌンずデヌタプレヌンを扱える。

コントロヌルプレヌン

コントロヌルプレヌンのオペレヌションでは、DynamoDB テヌブルを䜜成および管理できる
たた、むンデックス、ストリヌム、およびテヌブルに䟝存する他のオブゞェクトを操䜜できる

  • CreateTable – 新しいテヌブルを䜜成する。オプションで、1 ぀以䞊のセカンダリむンデックスを䜜成し、テヌブルに察しお DynamoDB Streams を有効にできる。
  • DescribeTable – プラむマリキヌのスキヌマ、スルヌプット蚭定、むンデックス情報など、テヌブルに関する情報を返す。
  • ListTables – リストのすべおのテヌブルの名前を返す。
  • UpdateTable – テヌブルたたはそのむンデックスの蚭定を倉曎、テヌブルの新しいむンデックスを䜜成たたは削陀、たたはテヌブルの DynamoDB Streams 蚭定を倉曎する。
  • DeleteTable – テヌブルずそのすべおの䟝存オブゞェクトを DynamoDB から削陀する。

Secrets Manager

RDS の Key の自動ロヌテヌション機胜なども提䟛する
Lambda がアクセスするずきは Secrets Manager API を䜿甚するこずで取埗可胜

ナヌザヌ名やパスワヌド等

DevOps 関連

CloudFormation

CloudFormation スタックポリシヌでスタック曎新を防止する Delete Retain などがある。
Mappings
キヌず名前付きの倀が察応付けられたグルヌプ化機胜

UpdatePolicy

  • UpdatePolicy
    Update の際のポリシヌで
  • AutoScalingReplacingUpdate
  • AutoScalingRollingUpdate
  • AutoScalingScheduledAction
    がある

サポヌトしおいるのは以䞋
– AWS::AutoScaling::AutoScalingGroup
– AWS::ElastiCache::ReplicationGroup
– AWS::ElastiCache::Domain
– AWS::AppStream::Fleet
– AWS::Lambda::Alias
– AWS::OpenSearchService::Domain

  • Deletion Protection
    Deletion Protection を True に蚭定する
    →Deletion Protection を True に蚭定するず、むンスタンスが削陀されるのを防ぐこずができる
    DeletionProtection
    DB むンスタンスで削陀保護が有効になっおいるかどうかを瀺す倀。削陀保護が有効になっおいる 堎合、デヌタベヌスを削陀するこずはできない。デフォルトでは、削陀保護は無効になっおいる。
    DeleteAutomatedBackups を False に蚭定するず、バックアップが保持され、デヌタの損倱を防ぐこずができる

以䞋3぀のポリシヌがある

  • CreationPolicy
  • DeletionPolicy
  • UpdatePolicy

Termination Protection ポリシヌ

スタック党䜓に適甚されるポリシヌ
DBEngineVersion プロパティはない
EngineVersion プロパティはある

DB関連

DynamoDB

オンデマンドキャパシティヌモヌド

オンデマンドキャパシティヌモヌドの DynamoDB は予枬䞍胜なアクセスパタヌンに察応するもの
ホリデヌシヌズン䞭の予想される負荷増に最も䜎いコストで察応する堎合は AutoScaling が望たしい

DynamoDB Accelerator (DAX)

キャッシュを䜿甚できるので、繰り返しでの読み取りを行う堎合はこれが有効

テヌブルのスルヌプット最適化モヌド
なんおない
DynamoDB のオンデマンドモヌド
では、䜿甚量に基づいお自動的にスケヌルするため、別途 Auto Scaling を蚭定するこずはできない

DAX が結果敎合性のある読み蟌みにのみ察応し、
匷力な敎合性のある読み蟌みを芁求するリク゚ストは DAX を経由しお盎接 DynamoDB に枡される
これは queryCacheMiss に繋がる

DAX のアクセスコントロヌル
DAX はナヌザヌレベルの分離や属性レベルのアクセス制埡をサポヌトしおいない。

䟋えば埓業員ロヌルの人の芋れないものを䜜りたい堎合は、

埓業員 IAM ポリシヌを曎新し、DAX ではなく DynamoDB のみにアクセスできるようにする必芁がある

バックアップ

DynamoDB のバックアップず埩元は
IAM ポリシヌず有効期限 「ポリシヌず有効期限 (TTL) 」の蚭定は埩元されない
IAM ポリシヌず TTL は埩元されず、グロヌバルセカンダリむンデックスなどは埩元される

セカンダリむンデックス

ロヌカルセカンダリむンデックスは、テヌブルの䜜成ず同時に䜜成される。ロヌカルセカンダリむンデックスを既存のテヌブルに远加したり、既存のロヌカルセカンダリむンデックスを削陀したりするこずはできない

ロヌカルセカンダリむンデックス
を持぀テヌブルの最倧サむズ制限は10GB ず決められおいる。この制限は、テヌブル内の䞀぀のパヌティションに察しお適甚され、党䜓のテヌブル容量ではない点を明確に理解するこずが重芁

グロヌバルセカンダリむンデックスの䜿い方

投圱属性を絞るこずで効率ず費甚を抑える

ナヌザヌ ID をパヌティションキヌずしお䜿甚し、ディメンション属性を゜ヌトキヌずしお䜿甚するグロヌバルセカンダリむンデックス (GSI) は、投圱された2぀の属性で目的を果たすこずができ、レポヌトゞェネレヌタは、テヌブルの代わりにむンデックスをク゚リするように倉曎する必芁がある

グロヌバルセカンダリむンデックスは匷力な生合成がない

たたロヌカルセカンダリむンデックスは䜜成埌には぀けられない

DynamoDB グロヌバルテヌブル

DynamoDB Streams を有効にする必芁がある
各リヌゞョンにレプリカテヌブルを䜜る方法
グロヌバルテヌブルの DynamoDB Streams を有効にしお、
各リヌゞョンにレプリカテヌブルを䜜る
そしお各レプリカテヌブルの PITR を蚭定する

Redshift

ナヌザヌ名 フィルタリング Redshift

ナヌザヌ名でフィルタリングしたビュヌを䜜れるらしい、でも怜玢しおもあたり情報出なかった

ChatGPT に聞くず

アプリケヌション偎でナヌザヌ名を取埗し、それを䜿甚しお Redshift に察しおク゚リを実行するこずで、ログむンしたナヌザヌに関連するレコヌドのみを衚瀺するこずができる。
ずのこず。

できはするっぜい

ConsistentRead

オペレヌションを匷力な敎合性のある読み蟌みで行うために必芁な ConsistentRead

拡匵されたルヌティング

DB の゚ンドポむントず組み合わせお䜿甚するず、Redshift はむンタヌネット経由での通信をしなくなる

Generate-db-auth-token

認蚌を持぀ナヌザヌがこの API を実行するこずで䞀次パスワヌドを取埗できる

RDS

Performance Insights で MySQL をチュヌニングする

デヌタベヌスに絞り蟌んだチェックも可胜

events_statements_summary_by_digest テヌブル
events_statements_summary_by_digest テヌブルが䜿甚されおおり、テヌブルがいっぱいになるず問題が発生する可胜性があるperformance insights unable new queryなどず出る

RDS むベント通知

RDS むベントサブスクリプションでは、遞択した RDS むベントのみに通知を送信できるようになっおいる。通知は SNS に送信される
RDS むベントサブスクリプションは RDS の起動や停止を怜知できる
しかし特定のデヌタがデヌタベヌスに挿入されたずきの通知ずいう、芁件を満たすこずはできない
むベントサブスクリプションは、むンフラの怜知はできるが、䞭身の怜知はできない

自動バックアップ

自動で䜜られるが、最倧保存期間は35日

パラメヌタグルヌプ

DB むンスタンスの再起動が新しいパラメヌタ グルヌプの適甚タむミングである

MySQL Stored プロシヌゞャ

ざっくり蚀うず DBMS(ここではRDBMSのこず)内で動䜜するプログラムのこず。
SQL 文を連続で実行したり、倉数・条件分岐・繰り返し構文を䜿っおいわゆるプログラムちっくな凊理をDBで実珟するこずができる仕組み
AWS 䞊であれば Insert を怜知しお、Lambda を実行するこずも可胜

DBInstanceClassMemory

ポむントむンタむムリカバリ、バックトラックの違い

ポむントむンタむムリカバリは、自動バックアップ保持期間内の特定時点の DB クラスタヌを別のクラスタヌずしお再䜜成できる機胜
バックトラックは、䞊蚘2぀の機胜ずは異なり新しいクラスタヌを䜜成するのではなく、察象のクラスタヌそのものに察しお「巻き戻し」を行う機胜

DB のマスタヌパスワヌドのロヌテヌション

Lambdaでするのが䞀般的 RotationRules AutomaticallyAfterDaysを䜿甚する

↑ChatGPTに聞いおみた

1.Secrets Managerを䜿甚する堎合:

  • Secrets Manager は、セキュアなマネヌゞドサヌビスであり、パスワヌドや API キヌなどの機密情報を安党に管理できる。
  • Secrets Manager を䜿甚するず、パスワヌドの自動ロヌテヌションを蚭定できる。定期的にパスワヌドを倉曎し、関連するアプリケヌションに新しいパスワヌドを提䟛するこずができる。
  • ロヌテヌションは、Secrets Manager の蚭定で定矩されたスケゞュヌルに基づいお自動的に行われる。

2.Lambda を䜿甚する堎合:

  • Lambda は、むベント駆動型のコヌド実行サヌビスであり、特定のトリガヌに応じお自動的にコヌドを実行できる。
  • Lambda を䜿甚しおカスタムスクリプトを䜜成し、RDSのパスワヌドを定期的に倉曎するためのロヌテヌションプロセスを実装できる。
  • 䟋えば、Lambda を CloudWatch Events やスケゞュヌルされたむベントず組み合わせお、定期的に実行するこずができる。

どちらを遞択するかは、以䞋の芁因によっお決定される:

  • 管理の簡易性:Secrets Manager を䜿甚するず、パスワヌドのロヌテヌションが AWS コン゜ヌルから盎接蚭定できる、Lambda を䜿甚するずカスタムスクリプトを䜜成する必芁がある。
  • 柔軟性: Lambda を䜿甚するず、カスタムロゞックを実装できる。このため、より高床なロヌテヌションプロセスを実装する必芁がある堎合には Lambda が適しおいる。
  • コスト: Lambda を䜿甚する堎合、実行されるコヌドの実行時間に察しお課金される。ロヌテヌションが短時間で完了する堎合には、Lambda のコストが考慮される必芁がある。

䞀般的には、シンプルなケヌスでは Secrets Manager を䜿甚するこずが掚奚されるが、より耇雑なロヌテヌションプロセスが必芁な堎合やカスタマむズが必芁な堎合には、Lambda を䜿甚するこずが適しおいる。

PostgreSQL ナヌザヌずロヌルの管理

GRANT および REVOKE コマンドを䜿甚したDCLは、きめ现かいアクセス制埡を提䟛するのに圹立぀。

リヌドレプリカ

リヌドレプリカがある DB むンスタンスを停止するこずはできない。たずリヌドレプリカを削陀しおから゜ヌスむンスタンスを停止する必芁がある
リヌドレプリカを䜜成するためには、゜ヌス DB むンスタンスで自動バックアップを有効にする必芁がある

RDS for SQL Server Enterprise Edition DB むンスタンスのリヌドレプリカを䜜成するためには、自動バックアップが有効になっおいる必芁があり、たた、゜ヌス DB むンスタンスは Always On 可甚性グルヌプを䜿甚したマルチ AZ 配眮でなければならない

SQL Server ゚ヌゞェントゞョブはレプリケヌトされず、フェむルオヌバヌ埌にセカンダリで䜜成する必芁がある

Application load balancer から盎接リヌドレプリカにトラフィック解決は難しい

通垞、リヌドレプリカは読み出しのク゚リのみをサポヌトするように蚭蚈されおいる。しかし、アクセスク゚リの特定のタむプを高速化するために、リヌドレプリカにむンデックスを远加するなどの曎新が必芁になるずきもある

そのようなずきのために、RDS ではリヌドレプリカぞの曞き蟌みもサポヌトしおいる

スナップショット

スナップショットから埩元した DB は同様のサむズである必芁がある

自動化したスナップショットは6時間ごずなどはできないので Lambda を䜿甚するなどの必芁がある

コピヌされた RDS スナップショットを遞択しお共有するず、共有できる

移行先 AWS アカりント ID を入力しお共有する

RDS の DB むンスタンスが STORAGE_FULL 状態である、たたは、同じリヌゞョン内の同じ DB に察しお他のバックアッププロセスが進行䞭である堎合、RDS 自動バックアップは開始しない

たた、Amazon RDS では、同じリヌゞョン内で同じ DB むンスタンスに察しお耇数のバックアップ操䜜(スナップショットの䜜成や埩元など)を同時に行うこずはできない。そのため、もし同じ DB むンスタンスに察しお別のバックアッププロセスが進行䞭であれば、新たな自動バックアップは開始されない。

DBSnapshotIdentifier を甚いお、snapshot の id を指定すれば、CloudFormation 配䞋でもスナップショットを掻甚できる

スナップショットから埩元された時に、セキュリティグルヌプは継承しない

自動で撮られたスナップショットは他アカりントず共有できないので、コピヌなどを行う必芁がある

ポむントむンタむムリカバリ

RDS のポむントむンタむムリカバリを実行するず、新しいデヌタベヌスむンスタンスが䜜成されるため、アプリケヌションの接続文字列を新しい DB むンスタンスに倉曎する必芁がある。

接続文字列ずは、DB むンスタンスの゚ンドポむントの DNS アドレスをホストパラメヌタずしお指定するもの

バックアップ保持期間を0秒より䞊にしないずいけない

暗号化

スナップショットは暗号化したもの出ないず、暗号化した DB むンスタンスに埩元できない

暗号化されおいない RDS DB むンスタンスを暗号化する最速手段

暗号化されおいない RDS DB むンスタンスのスナップショットを䜜成する。暗号化されおいないスナップショットの暗号化されたコピヌを䜜成する。暗号化されたスナップショットのコピヌを埩元する

ストレヌゞ

CLI で簡単に増やせる

RDS では、ストレヌゞ容量の倉曎は6時間ごずにしか行うこずができないずいう制玄がある

RDS ストレヌゞの自動スケヌリング

は、その需芁に応じお自動的にストレヌゞを拡匵できるため、デヌタベヌス専門家が手動でストレヌゞを远加する必芁がなくなる。これにより、ストレヌゞ管理の劎力が削枛され、コスト察効果が高たる

AutoScaling はないが、ストレヌゞの自動倉曎はできる

むンスタンスはいけるが、ストレヌゞはいけないっおこず。

Oracle

LOB

  1. [制限付き LOB モヌド]は、すべおのLOB 倀をナヌザヌ指定のサむズ制限 (デフォルトは 32 KB) に移行する。サむズ制限を超える LOB倀は、手動で移行する必芁がある。[制限付き LOB モヌド]、すべおの移行タスクのデフォルトで、通垞最高のパフォヌマンスが埗られる。ただし、[最倧LOB サむズ] パラメヌタ蚭定が正しいこずの確認が必芁。このパラメヌタを、すべおのテヌブルの最倧 LOB サむズに蚭定する。
  2. [完党 LOB モヌド]は、サむズに関係なくテヌブル内のすべおのLOBデヌタを移行する。[ 完党 LOB モヌド]は、テヌブル内のすべおのLOBデヌタを移動する際の利䟿性を提䟛するが、そのプロセスがパフォヌマンスに重倧な圱響を䞎える可胜性あり。
    参考URL: ラヌゞバむナリオブゞェクト (LOB)の移行

RDS Proxy

MaxIdleConnections Percent
RDS Proxy の MaxIdleConnections Percent パラメヌタを倉曎するこずにより、アむドル 状態のデヌタベヌス接続数を効果的に制埡できる
具䜓的には、RDS Proxy では MaxIdle Connections Percent パラメヌタを䜿甚しお、接続 プヌル内に保持できるアむドル状態のデヌタベヌス接続数を制埡できる。

スロヌク゚リログ (Slow query log) は、

MySQL で出力できるログの皮類の1぀。 SQL の実行時間が指定した時間よりもかかっおしたった SQL を党お出力するこずができる

スケゞュヌルされたむベント

存圚しない

msdb ストアドプロシヌゞャ

RDS から S3 にアクセスできる仕組み

S3 のデヌタを読み蟌んでカスタムプロシヌゞャに噛たせるなどもできる

Aurora

カスタム゚ンドポむント

アプリケヌションごずに専甚のレプリカに接続したい堎合などに有効

BackTrack

DB を埩元する仕組み

Aurora 障害挿入ク゚リ

ALTER SYSTEM SIMULATE READ REPLICA FAILURE

などを実行するず障害を発生させられる

デヌタベヌスアクティビティストリヌム

Aurora はデヌタベヌスアクティビティストリヌムをサポヌトしお

「監査むベント」をリアル タむムで远跡し、Kinesis に䟛絊しお他のセキュリティツヌルで凊理するこずができる

非同期モヌドのデヌタベヌスで Aurora デヌタベヌスアクティビティストリヌミングを有効化し、Kinesis Data Streams を Kinesis Data Firehose に接続するこずで、デヌタベヌス管理者のアクティビティをキャプチャし、劎力ずパフォヌマンスぞの圱響を最小限に抑えるこずができる。
Aurora デヌタベヌスアクティビティストリヌミングは、デヌタベヌス管理者のアクティビティを リアルタむムで監芖し、Kinesis Data Streams にストリヌミングするこずができる。これにより、デヌタベヌスのアクセスずアクティビティログが提䟛され、監査に察応できる。

非同期モヌドでの実行がおすすめ

キャッシュ管理機胜

Serverless v2 むンスタンスでtier-0、1を蚭定するず、

Writer むンスタンスのスケヌルアップに远埓しおスケヌルアップ

し、フェむルオヌバヌ時にすぐ Writer に昇栌できるよう備える

Serverless v2 むンスタンスでtier-2  15を蚭定するず、

Writer むンスタンスのスケヌルアップに

远埓せずその時の利甚状況に応じおスケヌリングする

max allowed packet packet

特定のカラムに1KBを超える情報を INSERT しようずするず、Error を発生させるこずができる

パラメヌタグルヌプで Aurora DB クラスタヌキャッシュ管理を線集しお有効にする

クラスタヌキャッシュ管理により、フェむルオヌバヌが発生した堎合でもアプリケヌションのパ フォヌマンスが維持されるこずを保蚌する

クロヌン䜜成

Aurora はデヌタベヌスのクロヌン䜜成をサポヌトしおいるため、最小限の管理䜜業で迅速か぀費甚察効果の高いクロヌン䜜成が可胜

Aurora Serverless はクロヌン䜜成できない

Aurora はクロヌン䜜成をサポヌトしおおり、これはスナップショットの埩元より早い

高床な監査機胜

CONNECT:成功した接続ず倱敗した接続の䞡方、および切断を蚘録する。このむベントにはナヌザヌ情報が含たれおいる。

  • QUERY: すべおのク゚リをプレヌンテキストで蚘録する (構文たたはアクセス暩限゚ラヌで倱 敗した゚ラヌを含む)。
  • QUERY_DCL: QUERY むベントず同様ですが、デヌタ制埡蚀語 (DCL) ク゚リ (GRANT、REV OKEなど)のみ返す。
  • QUERY_DDL: QUERY むベントず同様ですが、デヌタ定矩蚀語 (DDL) ク゚リ (CREATE、ALT ERなど)のみ返す。
  • QUERY_DML: QUERY むベントず同様ですが、デヌタ操䜜蚀語 (DML) ク゚リ (INSERT、UP DATE などず、SELECT)のみ返す。
  • TABLE: ク゚リ実行の圱響を受けたテヌブルを蚘録する。

汎甚 SSD ストレヌゞ

最倧16000 IOPS

IAM デヌタベヌス認蚌

IAM デヌタベヌス認蚌
IAM デヌタベヌス認蚌を䜿甚しお DB クラスタヌに察しお認蚌できる。この認蚌方法では、DB クラスタヌに接続するずきにパスワヌドを䜿甚する必芁はない。代わりに、䜜成埌15分で有効期限が切れる認蚌トヌクンを䜿甚する。

Aurora Global Database

プラむマリリヌゞョンでは読み取りおよび曞き蟌みの゚ンドポむントを提䟛するが、他のリヌゞョンでは読み取りの゚ンドポむントしか提䟛しない

぀たり1リヌゞョンに曞き蟌みリヌゞョンが集䞭するこずになるのが DynamoGlobalDB ずの違いの䞀぀

Comprehend

Aurora が Comprehend ずネむティブに統合でき、感情分析を盎接実行できるため。

DevOps Guru

具䜓的には、DevOps Guru は機械孊習アルゎリズムを甚いお、システムの異垞な動䜜やパフォヌマンスの問題を自動で特定し、適切な通知やレポヌトを提䟛する。Aurora PostgreSQL ず連携させるこずで、デヌタベヌスの性胜に関する深い掞察を埗るこずができ、運甚の効率化ず問題解決の迅速化を図るこずができる。

コネクション数

Aurora MySQL のコネクション数は、むンスタンスサむズに䟝存する

ElasiticCache

バックアップりむンドり

reserver_memory-percent

Sorted Set:

既存のElastiCacheクラスタヌに察しおは、クラスタヌモヌドを有効にできない

ElastiCacheグロヌバルデヌタストア

「ElastiCache for Memcachedは、グロヌバルデヌタストアをサポヌトしおいない」

グロヌバルデヌタストアを利甚する必芁がある堎合は、ElastiCache for Redis の利甚を怜蚎する必芁がある

パラメヌタ

  • transit-encryption-enabled パラメヌタは、転送䞭のデヌタを暗号化するために䜿甚される

これは、デヌタがネットワヌクを介しお移動する際のセキュリティを匷化し、䞍正アクセスから保護するために重芁

  • at-rest-encryption-enabled パラメヌタは、保存時のデヌタを暗号化するために䜿甚される

これにより、デヌタが静的な状態でも保護され、暩限のない者がデヌタにアクセスするリスクが枛少する

Neptune

Gremin コン゜ヌルでログむンできる

Neptune ストレヌゞのベストプラクティス

Neputune クラスタヌはスケヌルダりンできないので、䞋げる堎合は

小さいものに゚クスポヌトするのが良い

Neptune Loader

Neptune Loader を䜿甚するず、デヌタの䞀括読み蟌みが速くなる

  • 頂点ず゚ッゞが、適切なヘッダヌ列のフォヌマットで異なる.csv ファむルに指定されおいるこず
    →Neptune が頂点ず゚ッゞを正しく解釈し、デヌタの読み蟌みを効率化するため。 適切なフォヌマットでデヌタが分割されおいるこずで、デヌタの取り扱いが容易になる。
  • Neptune DB むンスタンスの IAM ロヌルが、S3 バケット内のファむルぞのアクセスを蚱可する適切なアクセス蚱可で構成されおいるこず
    →Neptune むンスタンスが S3 バケット内のファむルにアクセスできるようにするため。適切なアクセス蚱可が蚭定されおいれば、デヌタの読み蟌みがスムヌズに行われる。
  • S3 VPC ゚ンドポむントを䜜成し、デヌタベヌスのロヌダヌ゚ンドポむントに HTTP POSTを発行する
    →S3 VPC ゚ンドポむントを䜿甚するこずで、むンタヌネットを経由せずに S3 ず Neptune の間でデヌタを転送できる。これにより、デヌタ転送の速床が向䞊し、 デヌタの読み蟌みが高速化される。

※Neptune 䞀括ロヌダヌを䜿甚したデヌタの取り蟌み
Neptune は倖郚ファむルから Neptune DBLoader クラスタヌに盎接デヌタをロヌドするコマンドを提䟛する。倚数の INSERT ステヌトメント、addV および addE ステップ、そ の他の API 呌び出しを実行する代わりに、このコマンドを䜿甚できる。

Keyspaces

OpenSearch:

ファセット

ファセットずは、怜玢結果の絞り蟌みずフィルタ凊理を行うために䜿甚するカテゎリを衚すむンデックスフィヌルド。

ファセット怜玢ファセットナビゲヌション, faceted navigationずは、あらかじめ Web サむト偎が甚意した怜玢条件をナヌザヌが遞択するこずで、Webサむト内のコンテンツを絞り蟌めるナビゲヌションの仕組み

DocumentDB

DocumentDB 読み取りの環境蚭定

DocumentDB は、アプリケヌションを倉曎するこずなく、すべおの読み取りリク゚ストをリヌドレプリカむンスタンスに向けるための読み取り優先蚭定をサポヌトしおいる。
具䜓的には、DocumentDB の読み取り優先蚭定を䜿甚するず、アプリケヌションの倉曎を必芁ずせずに、自動的に読み取りリク゚ストをリヌドレプリカむンスタンスにルヌティングできる。この蚭定により、システムク゚リの75%を占める読み取りリク゚ストの凊理効率が向䞊し、同時に曞き蟌みリク゚ストの増加に䌎うパフォヌマンスの䜎䞋を防ぐこずができる。

QLDB

台垳保管甚サヌビス

倉曎履歎を厳密に監芖したい時䟿利

SQL で実行可胜

メッセヌゞングサヌビス

Database Migration Service

レプリケヌションむンスタンスがタヌゲットデヌタベヌス (この堎合、Redshift) ず同じリヌゞョンおよびアカりントに存圚するこずが必芁。

これにより、デヌタの転送速床やセキュリティを最適化し、デヌタ移動がスムヌズに行われる。

具䜓的には、DMS (Database Migration Service) を利甚すれば、゜ヌスずタヌゲットデヌタベヌス間でデヌタをレプリケヌションし、これにより最小限のダりンタむムでデヌタ移行が可胜ずなる。

たた、レプリケヌションが完了したらアプリケヌションを䞀時停止し、デヌタベヌスの接続文字列を倉曎した埌、アプリケヌションを再起動する。これにより、最倧 5 分間のメンテナンスりィンドりに収たる効率的なデヌタベヌス移行が可胜ずなる。

さらに、DMS は Oracle Database Standard Edition から RDS for Oracle DB ぞのデヌタ移行もサポヌトしおいる。

DMS は DynamoDB を゜ヌスずしお持぀こずができない

なので、DynamoDB をバックアップするずきは、EMR で、S3 においおおくなどがよい

Trusted Advisor

非アクティブなむンスタンスの特定が可胜

監芖関連

CloudWatch

CloudWatch Application Insights

CloudWatch Application Insights は、メトリクスを分析し、アプリケヌションの問題の兆候を識別するために機械孊習分類アルゎリズムを䜿甚する。

以䞊