VPC Flow Logs で取得したフローログを CloudWatch Logs に発行する
はじめに
VPC Flow Logs で取得したフローログを CloudWatch Logs に発行する方法についてまとめる。
VPC Flow Logs とは
VPC のネットワークインターフェース(≒ ENI)との間で行き来する IP トラフィックに関する情報をキャプチャしてログに記録する機能であり、取得したデータは CloudWatch Logs または S3 に発行できる。 フローログはネットワークトラフィックのパスの外で収集されるため、ネットワークのスループットやレイテンシーに影響を与えることなく取得できる。
フローログは VPC、サブネット、特定の ENI に対して作成できる。 ログのキャプチャレベルは下記のいずれかが設定できる。
ここからの作業の前提
- AWS マネジメントコンソールから手動で作業を進める。
- AdministratorAccess 権限を持つ IAM ユーザにて作業を行う。この作業では VPC、IAM、CloudWatch Logs の操作を行うため、必要な権限を持つ IAM ユーザで作業を行う必要がある。
- 東京リージョンで作業を行う。
フローログを CloudWatch Logs に発行する
「CloudWatch Logs へのフローログの発行」を参考に取得方法を見ていく。
準備
準備として下記の作業を行う。
- IAM ロールの作成
- CloudWatch Logs のロググループの作成
IAM ロールの作成
VPC Flow Logs にフローログを CloudWatch Logs に発行するための権限を与える必要がある。
IAM のコンソール画面を開き、「ロール」を選択する。
「ロールを作成」を選択する。
「信頼されたエンティティタイプ」では「AWS のサービス」、「ユースケース」では「EC2」を選択して、「次へ」を選択する。
「許可を設定」では、何も設定せずに「次へ」を選択する。 許可(権限)は後続の手順で設定する。
「名前、確認、および作成」では「ロール名」(ここでは「network-demo-role」)のみ設定して、「ロールを作成」を選択する。 信頼されたエンティティは後続の手順で設定する。
IAM ロールの作成が正常終了したことを確認する。 今回作成したロール(ここでは「network-demo-role」)を選択して、詳細画面を開く。
今回作成した IAM ロールに CloudWatch Logs にログを発行するための権限を設定する。 「アクセス許可を追加」のプルダウンメニューを開き、「インラインポリシーを作成」を選択する。
「ポリシーの作成」で「JSON」タブを選択する。 CloudWatch Logs にログを発行するための最小の権限は下記の通り。 これをコピー&ペーストして、「ポリシーの確認」を選択する。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogGroups", "logs:DescribeLogStreams" ], "Resource": "*" } ] }
「ポリシーの確認」では「名前」(ここでは「network-demo-cloudwatch-logs-policy」)を設定し、「概要」に表示されている権限に問題がないことを確認して、「ポリシーの作成」を選択する。
「許可ポリシー」に今回作成したポリシー(ここでは「network-demo-cloudwatch-logs-policy」)が表示されていることを確認する。
「信頼関係」タブを選択して、「信頼ポリシーを編集」を選択する。
VPC Flow Logs に信頼ポリシー(IAM ロールを Assume するための権限)を付与する。 下記をコピー&ペーストして、「ポリシーを更新」を選択する(「Service」の値が差分)。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "vpc-flow-logs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
CloudWatch Logs のロググループの作成
ログの送付先となる CloudWatch Logs のロググループを作成する。 なお、ログストリームはネットワークインターフェースごとに自動で作成される。
CloudWatch のコンソール画面を開く。 左側メニューで「ログ」を開き、「ロググループ」を選択する。
「ロググループ」で「ロググループを作成」を選択する。
「ロググループの詳細」で「ロググループ名」(ここでは、「network-demo-log-group」)を設定し、「作成」を選択する。
ロググループの作成が正常終了したことを確認する。
フローログを作成する
フローログは VPC、サブネット、特定のネットワークインターフェースに対して作成できるが、ここでは最も取得範囲の広い VPC に対して作成する。
VPC のコンソール画面を開き、フローログを設定したい VPC(ここでは、「network-demo-vpc」)の詳細画面を開く。 「フローログ」のタブを選択して、「フローログを作成」を選択する。
「フローログを作成」の画面に遷移する。
この画面での設定項目と説明、今回の設定値を下記にまとめる。 設定値の入力完了後に、「フローログを作成」を選択する。
設定項目 | 説明 | 設定値 |
---|---|---|
名前 | フローログの名前を設定する。オプション設定 | network-demo-flow-log-vpc |
フィルタ | キャプチャするトラフィックのタイプを設定する。「承諾(ACCEPT)」「却下(REJECT)」「すべて(ACCEPT と REJECT の両方)」から選択する | すべて |
最大集約間隔 | パケットのフローがキャプチャされてからフローログレコードに集約されるまでの間隔の最大時間。「10分間」「1分間」から設定する | 10分間 |
送信先 | フローログデータを公開する宛先。「CloudWatch Logs に送信」「Amazon S3 バケットに送信」から選択する | CloudWatch Logs に送信 |
送信先ロググループ | フローログデータが発行される CloudWatch Logs ロググループの名前を選択する。新しいログストリームは、モニタリングされている各ネットワークインターフェース(ENI)に対して作成される | network-demo-log-group |
IAM ロール | CloudWatch ロググループに発行するアクセス許可を持つ IAM ロールを選択する | network-demo-role |
ログレコードの形式 | フローログレコードに含めるフィールドを指定する。「AWS のデフォルト形式」「カスタム形式」から選択する | AWS のデフォルト形式 |
フローログの作成が正常終了したことを確認する。
ログの確認
VPC 内に EC2 インスタンスを作成し、そのインスタンスと通信した後に最大集約間隔として設定した10分程度待つと、CloudWatch Logs に下記のようなフローログが記録される(アカウント ID と VPC に設定した CIDR ブロック以外の IP アドレスを念のためマスクしている)。
EC2 インスタンスに SSH(#22/TCP)で接続した際に記録されたフローログは下記の通り。 なお、AWS アカウント ID と接続元 IP アドレスは置き換えをしている。
2 123456789012 eni-03f3d84b79d1edb78 10.0.22.65 aaa.bbb.ccc.ddd 22 53443 6 44 6253 1647819365 1647819419 ACCEPT OK
VPC Flow Logs に関する補足事項
フローログレコード
- フローログに記録されるレコードは AWS のデフォルト形式で下記が設定される。カスタマイズも可能。
${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}
- 各フィールドの説明は下記の通り(参考:「VPC フローログを使用した IP トラフィックのロギング」)。
フィールド | 説明 |
---|---|
version | VPC フローログバージョン。デフォルト形式では2が設定され、カスタム形式の場合は最も高いバージョンが設定される |
account-id | トラフィックが記録されるネットワークインターフェイスの所有者の AWS アカウント ID |
interface-id | トラフィックが記録されるネットワークインターフェイスの ID |
srcaddr | 受信トラフィックの送信元の アドレスか、ネットワークインターフェイスにおける送信トラフィックのネットワークインターフェイスの IPv4 または IPv6 アドレス |
dstaddr | 送信トラフィックの送信先アドレスか、ネットワークインターフェイスにおける受信トラフィックのネットワークインターフェイスの IPv4 または IPv6 アドレス |
srcport | トラフィックの送信元ポート |
dstport | トラフィックの送信先ポート |
protocol | トラフィックの IANA プロトコル番号 |
packets | フロー中に転送されたパケットの数 |
bytes | フロー中に転送されたバイト数 |
start | 集約間隔内にフローの最初のパケットが受信された時間(UNIX 秒) |
end | 集約間隔内にフローの最後のパケットが受信された時間(UNIX 秒) |
action | トラフィックに関連付けられたアクション。「ACCEPT(承諾)」「REJECT(拒否)」のいずれか |
log-status | フローログのロギングステータス。「OK(送信先に正常に記録された)」「NODATA(集約間隔内に通信がなかった)」「SKIPDATA(集約間隔内に何らかの問題があり一部のログがスキップされた。)」 |
最大集約間隔
- 最大集約間隔は「10分間」または「1分間」のいずれかが設定できる。
- 「最大」という表現はログの取得とログの発行に時間がかかるため。実際には下記の時間を目安にベストエフォートで配信される。
- CloudWatch Logs: 5分
- S3: 10分
- Nitro ベースのインスタンス(例:M5、C5、R5 など)のネットワークインターフェースの場合は、設定した最大集約間隔に関係なく常に1分以下となる。
フローログの活用
下記のような利用方法が考えられる。
- フローログを定常運用で定期的に監査して、自社サービスの利用の傾向(時間やアクセス数など)や不審なアクセスの有無などを調査する。
- CloudWatch Logs のメトリクスフィルタと CloudWatch Alarms を利用して、特定の条件を満たした場合にアラートを発報する。
- GuardDuty のインプットとして VPC 内の脅威の検知を行う。
参考文献
Amazon GuardDuty をセットアップし、AWS Chatbot による Slack 通知を設定する
はじめに
Amazon GuardDuty(GuardDuty) のセットアップ方法についてまとめる。 また、GuardDuty が脅威を検知した場合、速やかにその検知内容を確認して対処の要否を判断できることが重要である。 そのための手段として、検知結果を Slack に通知する方法についてもまとめる。
GuardDuty とは
AWS が提供する機械学習を用いたクラウドネイティブな脅威検知のマネージドサービス。 下記のログをデータソースとして脅威の検出を行い、検出結果を重要度(HIGH、MEDIUM、 LOW)で提示してくれる。
- CloudTrail イベントログ
- CloudTrail 管理イベント
- CloudTrail S3 データイベント
- Kubernetes 監査ログ
- VPC Flow Logs
- Route 53 の DNS ログ
ポートスキャンなどの悪意のあるスキャン、EC2 インスタンスへの DoS 攻撃、不正な API の呼び出しや予期しないリソースへのアクセスなども脅威として検出できる。 GuardDuty で検出できる脅威は「結果タイプ」を参照のこと。
また、EventBridge とも統合されており、GuardDuty が脅威を検知したことをトリガーにして E メールやチャットツールに通知の送付もできる。
ここからの作業の前提
- AWS マネジメントコンソールから手動で作業を進める。
- AdministratorAccess 権限を持つ IAM ユーザにて作業を行う。この作業では GuardDuty、Amazon EventBridge(EventBridge)、Amazon SNS(SNS)、AWS Chatbot(Chatbot)、IAM の操作を行うため、必要な権限を持つ IAM ユーザで作業を行う必要がある。
- 東京リージョンで作業を行う。
GuardDuty をセットアップする
AWS マネジメントコンソールでの作業の場合、GuardDuty は有効化のボタンを押下するだけでセットアップが可能である。
AWS マネジメントコンソールにログインし、GuardDuty のコンソール画面に移動する。 「今すぐ始める」を押下する。
表示されているメッセージを確認して、「GuardDuty の有効化」を押下する。
なお、ここで GuardDuty を有効化すると、GuardDuty に対して下記のアクセス権限と信頼ポリシーが付与される。 この内容は「サービスロールのアクセス権限の表示」を押下すると確認できる。
付与されるアクセス権限は下記の通り。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeVpcEndpoints", "ec2:DescribeSubnets", "ec2:DescribeVpcPeeringConnections", "ec2:DescribeTransitGatewayAttachments", "organizations:ListAccounts", "organizations:DescribeAccount", "s3:GetBucketPublicAccessBlock", "s3:GetEncryptionConfiguration", "s3:GetBucketTagging", "s3:GetAccountPublicAccessBlock", "s3:ListAllMyBuckets", "s3:GetBucketAcl", "s3:GetBucketPolicy", "s3:GetBucketPolicyStatus" ], "Resource": "*" } ] }
信頼ポリシーは下記の通り。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "guardduty.amazonaws.com" }, "Action": [ "sts:AssumeRole" ] } ] }
有効化に成功すると、下記のような「結果」の画面に遷移する。
なお、GuardDuty はリージョンサービスであり、有効化の作業を行なったリージョンでのみで有効化される。 セキュリティ向上のためには全リージョンでの有効化が望ましい。 リージョン数も多いので、CloudFormation の StackSets などを利用して有効化すると良い(参考:「一発でGuardDutyを全リージョン有効化して通知設定するテンプレート作った」)。
AWS Chatbot による Slack 通知を設定する
ここでは AWS Chatbot(Chatbot)を使い、Slack の通知を設定する。 大きく下記の作業を実施する。
- SNS のトピック作成
- EventBridge のルール作成
- Chatbot の設定
SNS のトピック作成
SNS のコンソール画面を開く。 画面の右上の「トピックの作成」で、「トピック名」(今回は「guardduty-notification」)を設定し、「次のステップ」を押下する。
「トピックの作成」の「詳細」で下記を確認する。 その他はデフォルトのままとして、「トピックの作成」を押下する。
- タイプ:スタンダード
- 名前:前の画面で設定した「トピック名」
トピックの作成に成功した場合、下記のような画面が表示される。
EventBridge のルール作成
EventBridge のコンソール画面を開く。 画面の右上の「新しいルールを作成」で、「ルールを作成」を押下する。
「ルールの詳細を定義」の画面で、下記のように設定して、「次へ」を押下する。
分類 | 設定項目 | 説明 | 設定値 |
---|---|---|---|
ルールの詳細 | 名前 | ルールの名前を設定する。 | 任意(今回は「guardduty-rule」) |
説明 | ルールの説明を記載する。 | 設定しない | |
イベントバス | イベントの発行元のリソースの種類を設定する。AWS サービス(GuardDuty)なので「default」を選択する。 | default | |
選択したイベントバスでルールを有効にする | イベントバスの有効/無効を設定する。 | 有効化 | |
ルールタイプ | ルールがイベントもしくは時間駆動のどちらなのかを設定する。 | イベントパターンを持つルール |
「イベントパターンを構築」の画面で、下記のように設定して、「次へ」を押下する。
分類 | 設定項目 | 説明 | 設定値 |
---|---|---|---|
イベントソース | イベントソース | イベントの送信元となるイベントソースを選択する。 | AWS のサービス |
イベントパターン | イベントソース | イベントソースとなる AWS サービス名を選択する。 | GuardDuty |
イベントタイプ | イベントのタイプを選択する。 | GuardDuty Finding |
上記の設定をすると、「イベントパターン」に下記が示される。 カスタマイズも可能だが、今回はこれで問題ないため、「次へ」を選択する。
{ "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"] }
「ターゲットを選択」の画面で、下記のように設定して、「次へ」を押下する。
分類 | 設定項目 | 説明 | 設定値 |
---|---|---|---|
ターゲット1 | ターゲットタイプ | イベントの送信先となるターゲットのタイプを選択する。 | AWS のサービス |
ターゲットを選択 | イベントがイベントパターンに一致した場合に呼び出すターゲットを選択する。 | SNS トピック | |
トピック | メッセージを発行する SNS トピックを選択する。 | 今回は「guardduty-notification」 |
「タグを設定」の画面では、必要に応じてタグを設定する。 今回は設定せずに「次へ」を選択する。
「レビューと作成」の画面で、設定に問題がないことを確認し、「ルールを作成」を選択する。
ルールの作成に成功した場合、下記のような画面が表示される。
Chatbot の設定
チャットクライアントの設定
Chatbot のコンソール画面を開く。 画面の右上の「チャットクライアントを設定」で、「チャットクライアント」に「Slack」を設定し、「クライアントを設定」を選択する。
Slack の認証ページにリダイレクトされるので、通知先となる Slack のワークスペースにサインインする。 処理を進めると、下記のような Chatbot と Slack の連携を設定する画面が表示される。 内容を確認して、「許可する」を選択する。
Chatbot と Slack の連携に成功すると、下記のような画面が表示される。 「新しいチャネルを設定」を選択する(矢印のどちらでも可)。
チャネルの設定
「Slack チャネルを選択」の画面で、下記のように設定して、「次へ」を押下する。
分類 | 設定項目 | 説明 | 設定値 |
---|---|---|---|
設定の詳細 | 設定名 | 設定の名前を設定する。 | 任意(今回は「guardduty-notification」) |
ログ記録 | CloudWatch Logs へのログの記録の有無を設定する。 | 設定しない | |
Slack チャネル | チャネルタイプ | 通知先となる Slack チャネルの公開レベルを選択する。 | パブリック |
パブリックチャネル名 | 通知先となる Slack チャネル名を選択する。 | notification | |
アクセス許可 | ロール設定 | チャネルのメンバーに付与するアクセス許可を設定する。 | チャネル IAM ロール |
チャネル IAM ロール | チャネルに設定する IAM ロールを選択する。 | テンプレートを使用して IAM ロールを作成する | |
ロール名 | IAM ロールの名称を設定する。 | 任意(今回は「AWSChatbot-role」) | |
ポリシーテンプレート | IAM ロールに設定する権限をポリシーテンプレートから設定する。 | 通知のアクセス許可 | |
ガードレールポリシー ポリシ名 | IAM ロールでチャネルのメンバーに付与するアクセス許可の制約を設定する(ガードレールポリシーで許可していない操作は実行できない)。 | チャネル IAM ロールより広い権限を付与(今回は「AdministratorAccess」) | |
通知 | SNS トピック リージョン | 購読する SNS トピックがあるリージョンを選択する。 | 「アジアパシフィック - 東京」 |
トピック | 購読する SNS トピックを選択する。 | 今回は「guardduty-notification」 |
チャネルの設定に成功すると、下記のような画面が表示される。
デスクトップアプリなどで Slack を開き、App 配下に「aws」が存在することを確認する。 存在しない場合は、「アプリを追加する」から「AWS Chatbot」を追加する。
Chatbot のコンソール画面で、今回設定したチャネル(「guardduty-notification」)のチェックボックスにチェックをつけて、「テストメッセージを送信」を選択すると、Chatbot - Slack 間の疎通をテストできる。
通知のテスト
GuardDuty では脅威の検知結果のサンプルを生成できる。 サンプルの生成をトリガーに Slack に検知結果が通知されることを確認する。
(注意)このテストで100通程度の Slack 通知が飛ぶ点に注意すること。
GuardDuty のコンソール画面を表示して、左側のメニューの「設定」を選択する。 「設定」画面の下の方にスクロールし、「結果のサンプル」の「結果サンプルの生成」を選択する(ボタン押下後の変化が少ないが問題ない)。
その後、左側のメニューの「結果」を選択する。 GuardDuty の脅威の結果画面を確認すると、脅威の検知結果のサンプルが表示されている。
(注意)この結果はあくまでサンプルであり、実際に攻撃を受けている訳ではない。
デスクトップアプリなどで Slack を開くと、下記のような通知が届く。 筆者がテストした際は通知が届くまでに少し時間がかかったので、届かない場合でも数分待つと届く。
Severity(重要度)は下記の通り。
- HIGH: 赤
- MEDIUM: 黄
- LOW: 青
検知結果の意味は、「結果タイプ」に記載されている。
上図の「Finding type: Backdoor:EC2/DenialOfService.Udp」は、EC2 インスタンスが UDP による DoS 攻撃を受けている可能性を示すもの。
補足
GuardDuty の利用料金
- GuardDuty の利用料金は、分析したログのイベント数やデータサイズに対する従量課金となる。
- 初回の有効時から30日間は利用料が無料となるが、GuardDuty のコンソール画面の「使用状況」から予測コストを確認できる(※ 下図は有効化の初日に確認したため、予測が0ドルになっている)。
GuardDuty の停止と無効化
- GuardDuty による脅威検知を一時的に停止したい場合は「GuardDuty の停止」を選択する。再開も可能。
- GuardDuty による脅威検知をやめたい場合は「GuardDuty の無効化」を選択する。
- (注意)GuardDuty の無償期間は30日間なので、課金を停止したい場合は期限切れまでに対処する必要がある点に注意する。
参考文献
Amazon SageMaker Canvas を使ってノーコードで AI による予測をする
はじめに
こちらは APN Ambassadors(AWS Ambassadors)によるアドベントカレンダー「Japan APN Ambassador Advent Calendar 2021」での20日目の記事となります。 AWS Ambassadors の詳細については、下記の記事をご覧ください。
本記事では AWS re:Invent 2021 にて発表された「Amazon SageMaker Canvas」(以下、SageMaker Canvas)の簡単な動作検証を実施してみたいと思います。
SageMaker Canvas
概要
SageMaker Canvas は AWS re:Invent 2021 で発表された新機能であり、ノーコードで AI を用いた予測が行えます。 手元に構造化されたデータがあれば、30 分程度で簡単な予測結果が得られます。
ビジネスおよびテクニカル観点で SageMaker Canvas を見てみます。
ビジネス観点
- ビジネスアナリストやプロダクトオーナーがデータサイエンティストやエンジニアの手を借りずに自身の手でデータを検証できる
- 「依頼」には余計なオーバーヘッドがかかりがち…
- 手元にあるデータでサクッと仮説検証して、結果をデータサイエンティストやエンジニアに共有できればビジネスへの導入も円滑に進みやすい
- スポンサーに有用性を説明して出資なども取り付けやすい
- 下記のようなビジネス課題に対するソリューションになる(開発者ガイドより引用)
- Reducing employee churn(従業員の離職を減らす)
- Detecting fraud(不正を検出する)
- Forecasting sales(売上を予測する)
- Optimizing inventory(在庫量を予測して最適化する)
テクニカル観点
- SageMaker Canvas の仕様や挙動から背後で SageMaker Autopilot が使われていると思われるため、SageMaker Autopilot でできることは実現可能
- 学習データの分析(統計情報や欠損値の割合の分析など)
- 下記の学習アルゴリズムを用いたモデル構築
- 回帰
- 分類(二値・多値)
- 時系列予測
- 構築したモデルによる推論
- モデルの判断根拠の可視化(説明可能な AI: XAI)
使い方
SageMaker Canvas の概要や有用性がわかったところで、具体的な使い方を見ていきたいと思います。 SageMaker の開発者ガイドより、SageMaker Canvas は事前準備を含めて、下記の 6 ステップで予測まで実行することができます。
- Step 0: 事前準備
- Step 1: SageMaker Canvas へのログイン
- Step 2: データのインポート
- Step 3: モデルの構築
- Step 4: モデルの評価
- Step 5: 予測
ここからは SageMaker Canvas を使って簡単な動作検証を実施してみたいと思います。
今回は UCI Machine Learning Repository の Bank Marketing のオープンデータを利用して、二値判別問題に取り組みます。 このデータにはポルトガル銀行の顧客の属性情報(年齢、職業、住宅ローンの有無など)とその顧客が定期預金を申し込んだかどうかの情報が含まれています。 属性情報から何らかの法則性を見出せれば、定期預金を申し込んでくれそうな顧客に対して効率的に営業活動ができます。
Step 0: 事前準備
このステップでは、下記を実施します。
- Step 0-1: AWS リソースに対する適切な権限を持った IAM ユーザにログインする
- Step 0-2: S3 に学習データとテストデータをアップロードする
- Step 0-3: SageMaker Domain をセットアップする
Step 0-1: AWS リソースに対する適切な権限を持った IAM ユーザにログインする
AWS マネジメントコンソールから IAM ユーザにログインします。
今回は簡単な動作検証なので AdministratorAccess 権限を持つ IAM ユーザで実施しますが、特にビジネスで利用する際は AWS のベストプラクティスにしたがって必要最小限の権限に制約してください。
SageMaker Canvas は、本稿の執筆時点では下記のリージョンでのみ利用が可能であり、東京&大阪リージョンに対応していません。 今回は「米国西部(オレゴン)」を利用します。
Step 0-2: S3 に学習データとテストデータをアップロードする
S3 のコンソール画面に移動し、学習データとテストデータをアップロードします。
SageMaker Canvas にファイルに対して下記の制約がありますので、注意してください。
- ファイルサイズは 5GB 以下で、CSV 形式とする
- 欠損値補完などの前処理を事前に実施する(前処理機能が実装されていない)
Step 0-3: SageMaker Domain をセットアップする
この手順は SageMaker Domain が未セットアップの場合にのみ必要となります。
SageMaker のコンソール画面に移動し、「Canvas」を選択します。
SageMaker Domain が未セットアップの場合は、下図に示すセットアップ画面に誘導されます。 構成状況が不明の場合でもこの方法で確認できます。
今回は「高速セットアップ」で進めます。
SageMaker Domain は下記のリソースで構成され、AWS アカウントの 1 つのリージョンあたりに 1 つだけ構成できます。
- EFS ボリューム
- 認証されたユーザの一覧
- 様々なセキュリティ、アプリケーション、ポリシー、VPC の構成
SageMaker Domain は SageMaker Studio でも活用されています。 例えば、同じ SageMaker Domain に所属するユーザ間では EFS ボリュームを介してノートブックなどのファイルを共有できます。
下記のような画面となれば SageMaker Domain の構成完了です。
Step 1: SageMaker Canvas へのログイン
このステップでは、下記を実施します。
- Step 1-1: SageMaker Canvas を起動する
Step 1-1: SageMaker Canvas を起動する
SageMaker Canvas は赤い矢印で示した「アプリケーションを起動」のプルダウンから「Canvas」を選択すると起動できます。
起動に成功すると、下図のような画面が表示されます。
初回接続時にチュートリアルが表示されますが、左下の「?」を選択すればいつでも確認できます。
Step 2: データのインポート
このステップでは、下記を実施します。
- Step 2-1: S3 から学習データとテストデータをインポートする
ここでは、機械学習モデルの構築で利用する学習データと予測で利用するテストデータをインポートします。
Step 2-1: S3 から学習データとテストデータをインポートする
左側のメニューを開くと、それぞれのアイコンの内容が確認できます。 「Datasets」を選択します。
画面右上もしくは中央下の「Import」を選択します。
データが格納されている S3 Bucket を選択します。
インポートするデータにチェックをつけて、「Import data」を選択します。
ファイル名をクリックすると、データの内容を確認できます。
下図のように「Status」が「Ready」となれば完了です。
なお、開発者ガイドによるとデータソースとして下記がサポートされると記載されますが、本稿の執筆時点では S3 のみが利用可能です。 上図では「Upload」というボタンがあり、ローカル PC からのアップデートができそうに見えますが、ボタンが活性化されておらず利用できません。
- ローカル PC
- S3
- Redshift
- Snowflake
また、今回は実施しませんが、「Join data」を選択するとインポートしたデータを結合できます(図は SageMaker の開発者ガイド より引用)。
Step 3: モデルの構築
このステップでは、下記を実施します。
- Step 3-1: 「Models」に移動する
- Step 3-2: 機械学習モデルの名前を設定する
- Step 3-3: 学習データを選択する
- Step 3-4: 予測対象となるカラム名を選択する
- Step 3-5: 学習方法を選択して実行する
Step 3-1: 「Models」に移動する
左側のメニューで「Models」を選択後、画面右上もしくは中央下の「New model」を選択します。
Step 3-2: 機械学習モデルの名前を設定する
機械学習モデルの名前を入力して、「Create」を選択します。
Step 3-3: 学習データを選択する
学習データとするデータを選択して、「Select data」を選択します。
Step 3-4: 予測対象となるカラム名を選択する
「Target column」から予測対象となるカラム名を選択します。 今回は定期預金を申し込んだかどうかが記録されている「y」を選択します。
赤枠部分に学習データの「y」の比率が示されています。 この学習データは「no(定期預金を申し込まない)」よりも「yes(定期預金を申し込む)」が著しく少ない不均衡データであることがわかります。
青枠部分には「y」のデータの内容から、SageMaker Canvas が 自動で「2 category prediction(二値判別予測)」と判断し、その結果が示されています。 判断が間違っている場合は、その下の「Change type」で変更できます。
画面の下半分には学習データのカラム別の分析結果が示されています。 データ型や欠損割合に加えて、平均や中央値などの統計情報も提示されます。
分析結果の上部にあるアイコンを選択すると、データの分析観点を変更したり、フィルタなどもできます。 下図は矢印を選択したものです。 カラム別にデータの分布が可視化され、学習データの中の 100 行が示されています。
Step 3-5: 学習方法を選択して実行する
矢印のプルダウンを選択すると、2 つの学習方法を選択することができます。 今回は「Quick build」を選択します。
- Standard build: 数時間かけて 250 モデルを作成し、精度が最良のものを選択する
- Quick build: 数分でクイックに精度を提示する(恐らく 1 モデルのみの構築)
今回は「Quick build」を選択するので数分で結果が得られますが、「Standard build」は結果を得るまでに数時間かかります。 事前に精度の見通しを持てるため、非常にありがたい機能です。
なお、画面上部の「Share」を使うと学習モデルを他者に共有できますが、「Quick build」では共有ができない点に注意してください。
「Preview model」を選択して数分待つと、画面右下に「Estimated accuracy(モデルの予測精度)」と「Column impact(カラムの値が予測に与える影響度合い)」が表示されます。
「Preview model」の実体は「Quick build」と考えられますが、この時に構築したモデルは偶然良いもしくは悪い精度を出す可能性があるため、結果の妥当性を求めたい場合は「Standard build」を選択すると良いでしょう。
「_c0」というカラムは学習データの行番号を示すものであり、学習には不要なデータでした。 そのような場合はカラム名の左横のチェックを外すと学習から除外でき、数分待つと予測精度も更新できます。
学習データに問題ないことが確認できたら「Quick build」を選択します。 下図のような画面に遷移するので、学習が完了するまで数分待ちます。
Step 4: モデルの評価
このステップでは、下記を実施します。
- Step 4-1: モデルを評価する
ここでは、モデルの評価を行います。 正解がわかっている学習データを用いた評価となります。
Step 4-1: モデルを評価する
学習が完了すると、下図のような画面が表示されます。 「精度」と「カラムの値が予測に与える影響度合い」が図で示されます。
今回は「duration(最後の連絡期間)」が最上位になりました。 なお、今回利用した UCI のデータセットの説明では「duration」が「y」に大きな影響を与えるので検証以外で利用する場合には注意せよとの記載があります。 データの性質と一致する結果となりました。
「Scoring」を選択すると、予測の正解と不正解の割合が図示されます。
画面の右の方にある「Advanced metrics」を選択すると、「no(定期預金を申し込まない)」と「yes(定期預金を申し込む)」のそれぞれについて、詳細なメトリクス(指標値)を確認することができます。 「Download」を選択すると、画像として保存もできます。
- F1(適合率と再現率の調和平均)
- Accuracy(精度、正解率)
- Precision(適合率)
- Recall(再現率)
- AUC(ROC 曲線の面積)
- 混同行列の内訳
「yes」はデータ量の不足もあって十分な指標値が得られていません。 「no」はそこそこですが、誤検出や検出漏れが少なくないためビジネスで利用するには十分とは言えません。 このような結果を得た場合は「yes」「no」ともデータ量を増やし、かつ、両者の比率も揃える必要があるでしょう。
Step 5: 予測
このステップでは、下記を実施します。
- Step 5-1: 「Predict」を選択する
- Step 5-2: 「Batch prediction」を選択する
- Step 5-3: テストデータを使って予測する
- Step 5-4: 予測結果を確認する
Step 4 で構築したモデルを使って、未知データ(定期預金を申し込むかどうかわからない顧客のデータ)から予測を取得します。
Step 5-1: 「Predict」を選択する
確認が完了したら、右上もしくは右下の「Predict」を選択します。
Step 5-2: 「Batch prediction」を選択する
SageMaker Canvas は下記の 2 つの予測方法にて予測を行えます。
- Batch prediction: 予測対象のデータをファイルで一括指定する
- Single prediction: 予測対象のカラムの値を手動で設定する
「Batch prediction」を選択して、「Select dataset」を選択します。
Step 5-3: テストデータを使って予測する
テストデータを選択して、「Generate prediction」を選択します。
Step 5-4: 予測結果を確認する
少々分かりづらいですが、予測が完了すると画面の下部に黒いポップアップが表示されます。 「View」を選択すると、下図のように表形式で予測結果が提示されます。
- Prediction (y): 予測した「y(定期預金を申し込むかどうか)」の値
- Probability: 予測した「y」の値をとる確率
「Download CSV」を選択すると、予測結果を CSV 形式のファイルとして保存できます。
なお、「Single prediction」を選択すると、各カラムの値を手動で変更して、その時の予測結果がどのように変化するかを確認できます。 業務知識をもとに値を設定して予測結果を得るなどのシミュレーションができます。
制約事項
動作検証の中でも触れましたが、SageMaker Canvas の主な制約事項をまとめます。
- 東京&大阪リージョンでは利用不可
- S3 からのデータ(5GB 以下& CSV 形式)のインポートのみに対応
- 回帰、分類(二値・多値)、時系列予測にのみ対応
- 「Quick build」はモデルの共有不可
SageMaker Canvas はまだ発表されたばかりですので、順次機能が拡張されていくものと考えられます。
まとめ
本稿では SageMaker Canvas について、開発者ガイドのチュートリアルを利用しながら簡単な動作検証を実施しました。 製品の謳い文句の通りにノーコードで AI を利用した予測ができました。
本稿のボリュームはそれなりにありますが、慣れれば Quick build なら 30 分程度で予測結果を得られると思います。 非常に有用なサービスですので、早々の東京&大阪リージョンへの対応を期待したいところです。
Advent Calendar も佳境ですが、AWS Ambassadors の仲間が興味深い記事をたくさん投稿していますので、是非お読みいただければと思います。
参考文献
- Amazon SageMaker Canvas
- Introducing Amazon SageMaker Canvas - a visual, no-code interface to build accurate machine learning models
- Announcing Amazon SageMaker Canvas – a Visual, No Code Machine Learning Capability for Business Analysts
- AWS re:Invent 2021 - A deeper look at SageMaker Canvas
- Amazon SageMaker Developer Guide
AWS Chatbot を使ってサインインイベントを Slack に通知する
はじめに
AWS の新規開発案件に携わることがあったので、AWS を利用する上での初期設定の1つとなるマネジメントコンソールへのサインイン(ログイン)を Slack に通知する方法をまとめる。 実現方法はいくつかあるが、ここでは AWS Chatbot を使った方法を採用する。
AWS Chatbot とは
AWS Chatbot(Chatbot)は、AWS で「ChatOps」を実現するためのマネージドサービスであり、Slack と Amazon Chime への連携を簡単に行える。 今回扱うような簡単な通知であれば、コードを一切書かずにマネジメントコンソールの操作だけで実現できる。
Chatbot の利用に追加費用は不要(つまり、無料)であり、東京&大阪リージョンでも利用できる。
ChatOps とは
ChatOps は、「Chat(チャット)」+「Ops(Operations: 運用)」を合わせた用語であり、文字通りにシステム運用にチャットを活用する手法のことを指す。
多くの組織で Slack や Mattermost などのチャットツールがコミュニケーションツールとして採用されているが、システムで発生したイベントをチャットに通知することで、状態の変化や障害にすぐに気づくことができ、その後のアクションを迅速に行える。
ここで扱うマネジメントコンソールへのサインインイベントの Slack 通知が実現できると、誰がいつサインインをしたか?を把握でき、Slack にその記録も残せる。 想定しないタイミングでサインイン通知があった場合には、その異常にもすぐに気づいて対処ができる。
今回実現するアーキテクチャ
下図に示すように、マネジメントコンソールへのサインインを契機に Slack にイベントを通知するアーキテクチャを実現する。
実現手順
Chatbot の管理者ガイドを参考に実施する。
なお、今回は通知機能の実現に必要な最低限の設定のみを行うこととする。 商用で採用する場合には要件にしたがい、蓄積データの暗号化やログの取得などを適切に行うこと。
Chatbot のセットアップ
Chatbot を利用するための前提条件が下記となる。 利用者の環境によっては既に設定されているものもあると思うが、不足があれば「Setting up AWS Chatbot」にしたがって設定を行う。
- Chatbot に対する適切な権限を持つ IAM ユーザを作成すること
- Chatbot からの通知を受け取る SNS トピックを作成すること
- 今回は「signin-notification」という SNS トピックを作成する。(作成手順を下記に示す)
- Slack のワークスペースの管理者権限を持っていること
- Slack のワークスペースに SNS トピックからの通知を受け取るチャネルを作っておくこと
- 今回は「notification」チャネルに通知する。
なお、サインインのイベントは「米国東部(バージニア北部)us-east-1」リージョンで発生するので、ここで作業を行う。
SNS トピックの作成
下記に SNS トピックの作成手順を示す。
ここでの作業範囲を下図に示す。
マネジメントコンソールで SNS のコンソールに移動する。 画面右上の「トピック作成」に「トピック名」を入力して、「次のステップ」を選択する。
「タイプ」で「スタンダード」が設定されていることを確認する。 その他はオプション設定なのでデフォルトのままとする。 画面の下までスクロールして「トピックの作成」を選択する。
SNS トピックの作成に成功すると、下記のようなメッセージが表示される。
Chatbot の設定
「Getting started with AWS Chatbot」を参考にして、Chatbot を設定する。
ここでの作業範囲を下図に示す。
Chatbot のチャットクライアントのセットアップ
マネジメントコンソールで Chatbot のコンソールに移動する。
チャットクライアントには「Slack」と「Amazon Chime」が選べるが、ここでは「Slack」とする。 「クライアントを設定」を選択する。
Slack の認証ページにリダイレクトされるので、Slack のワークスペース名を確認する。 連携したいワークスペース名が表示されていない場合は、右上のプルダウンから選択する。 内容を確認して「許可する」を選択する。
Slack と Chatbot との連携に成功すると、下図のようなメッセージが表示される。 「新しいチャネルを設定」を選択する。
ここでは、下表のように設定する。 設定が終わったら、画面の下までスクロールして「設定」を選択する。
分類 | 設定項目 | 説明 | 設定値 |
---|---|---|---|
設定の詳細 | 設定名 | 設定の名前を設定する。 | 「signin-configuration」 |
ログ記録 | CloudWatch Logs へのログの記録の有無を設定する。 | 設定しない | |
Slack チャネル | チャネルタイプ | 通知先となる Slack チャネルの公開レベルを選択する。 | 「パブリック」 |
パブリックチャネル名 | 通知先となる Slack チャネル名を選択する。 | 「notification」 | |
アクセス許可 | IAM ロール | Chatbot に付与する IAM ロールをテンプレートから新規作成するか、既存の IAM ロールから選択する。 | 「テンプレートを使用して IAM ロールを作成する」 |
ロール名 | IAM ロールの名称を設定する。 | 「AWSChatbot-role」 | |
ポリシーテンプレート | IAM ロールに設定する権限をポリシーテンプレートから設定する。 | 「通知のアクセス許可」 | |
通知 | SNS トピック | 購読する SNS トピックがあるリージョンを選択する。 | 「米国東部 - バージニア北部」 |
購読する SNS トピックを選択する。 | 「signin-notification」 |
Chatbot の設定が完了すると、下図のようなメッセージが表示される。
デスクトップアプリなどで Slack を開き、App 配下に「aws」が存在することを確認する。 存在しない場合は、「アプリを追加する」から「AWS Chatbot」を追加する。
ここまでの手順で Chatbot と Slack の連携が完了している。 下図のように、上記で設定したワークスペースの設定(「notification-configuration」)の左のラジオボタンを選択し、「テストメッセージを送信」を選択すると Slack にテストメッセージを送信できる。
Chatbot と Slack の連携がうまくできていれば、下図のようなメッセージが届く。
EventBridge の設定
Amazon EventBridge(EventBridge)のルールを使って、マネジメントコンソールへのサインインイベントの発生を捕捉する。
「Tutorial: Creating an Amazon EventBridge rule that sends notifications to AWS Chatbot」を参考にして、EventBridge のルールを作成する。
ここでの作業範囲を下図に示す。
EventBridge のルールの作成
マネジメントコンソールで EventBridge のコンソールに移動する。
「ルールを作成」を選択する。
ルールの作成画面に遷移する。
ここでは、下表のように設定する。 設定が終わったら、画面の下までスクロールして「作成」を選択する。
分類 | 設定項目 | 説明 | 設定値 |
---|---|---|---|
名前と説明 | 名前 | ルールの名前を設定する。 | 「signin-rule」 |
説明 | ルールの説明を記載する。 | 設定しない | |
パターンを定義 | イベント駆動もしくは時間駆動のルールを選択する。 | 「イベントパターン」 | |
イベント一致パターン | サービスごとに事前定義されたパターンか、パターンをカスタマイズするかを選択する。 | 「サービスごとの事前定義パターン」 | |
サービスプロバイダー | イベントソースとなるサービスの提供者を選択する。 | 「AWS」 | |
サービス名 | イベントソースのサービス名を選択する。 | 「AWS コンソールのサインイン」 | |
イベントタイプ | イベントのタイプを選択する。 | 「サインインイベント」 | |
サインインイベントを捕捉するユーザを設定する。 | 「任意のユーザ」 | ||
イベントバスを選択 | ルールのイベントバスを選択する。 | 「AWS のデフォルトのイベントバス」 | |
選択したイベントバスのルールを有効化するか選択する。 | 「選択したイベントバスでルールを有効にする」 | ||
ターゲットを選択 | ターゲット | イベントがイベントパターンに一致した場合に呼び出すターゲットを選択する。 | 「SNS トピック」 |
メッセージを発行する SNS トピックを選択する。 | 「signin-notification」 | ||
タグ | ルールに付与するタグを設定する。 | 設定しない |
ルールの作成が完了すると、下図のようなメッセージが表示される。
以上で設定は完了である。
通知のテスト
マネジメントコンソールへのサインインで Slack に通知が届くかテストする。
一度マネジメントコンソールをサインアウトして、再度サインインする。
設定が正しく行われていれば、下図に示すようなメッセージが通知される。 なお、一段階目のパスワード認証時と二段階目の MFA 認証時で2つのサインインイベントが発生するため、2通メッセージが届く。
AWS のイベント情報は JSON で記録されるが、利用者側で特に情報の抽出や整形をすることなく Chatbot が自動で実行してくれている。
まとめ
Chatbot を使ってマネジメントコンソールのサインインイベントを Slack に通知する仕組みを構築した。 今回はサインインイベントをターゲットにしたが、コードを一切書くことなく簡単に実現できた。 他にも日々の Billing 情報の通知、CloudWatch Alarms でのエラー検知、CI/CD の実行状況の通知などにも使えるので、別の機会に試したい。
参考文献
Amazon Aurora PostgreSQL での擬似障害の実行 (1)
はじめに
Amazon Aurora PostgreSQL (以下、Aurora PostgreSQL) で擬似障害試験を実施することがあったのでまとめる。
Amazon Aurora における擬似障害
Amazon Aurora で擬似障害を発生させる方法には、大きく3つの方法がある。
- AWS マネジメントコンソールによる手動のフェイルオーバーを発生させる方法
- 障害挿入クエリを利用して DB インスタンスをクラッシュさせる方法
- AWS Fault Injection Simulator を利用する方法
Amazon Aurora には MySQL 互換の DB エンジン (以下、Aurora MySQL) も用意されているが、Aurora PostgreSQL と Aurora MySQL で障害挿入クエリが異なるため、具体的な擬似障害の発生方法が異なる点に注意する。
今回は Aurora PostgreSQL を対象とする。
検証環境の構成
Aurora PostgreSQL のバージョンは 3.2 (PostgreSQL バージョン 11.7 との互換性あり) とし、DB クラスタの構成を下記とする。
DB 識別子 | ロール | フェイルオーバー優先順位 |
---|---|---|
aurora-test-cluster-instance-1 | 書き込み | 1 |
aurora-test-cluster-read-replica-1 | 読み込み | 1 |
aurora-test-cluster-read-replica-2 | 読み込み | 2 |
「フェイルオーバー優先順位」は、0 (最高) から 15 (最低) までの16段階で設定可能である。
プライマリ DB (aurora-test-cluster-instance-1) に障害があった場合、優先度の高いリードレプリカ 1 (aurora-test-cluster-read-replica-1) がプライマリ DB に昇格することになる。
なお、Amazon Aurora の仕様では、優先度が同じ場合は、その中でサイズが最も大きいリードレプリカが選択される。 優先度もサイズも同じ場合は、その中からランダムに選択される。
AWS マネジメントコンソールによる手動のフェイルオーバーを発生させる方法
事前の準備が必要ないので、最も単純に実施できる方法である。
1. AWS マネジメントコンソールで Amazon RDS のコンソールに移動する
2. 「データベース」を選択する
3. DB クラスタと DB インスタンスの「ステータス」を確認する
DB クラスタと DB インスタンスとリードレプリカの「ステータス」が「利用可能」であることを確認する。
4. フェイルオーバーを発生させる
「アクション > フェイルオーバー」を選択する。
フェイルオーバーを発生させるクラスタのクラスタ名 (ここでは、aurora-test-cluster) を確認する。 間違いがなければ「フェイルオーバー」を選択する。
5. フェイルオーバーの発生を確認する
問題がなければ、元の「データベース」の画面に戻る。 画面のリフレッシュを行うと、DB クラスタののステータスが「Failing-over」となる。
DB クラスタに1つ以上のリードレプリカが含まれる場合、一般的には120秒未満、多くの場合は60秒未満でリードレプリカの1つへのフェイルオーバーが完了する。
DB クラスタに1つ以上のリードレプリカが含まれない場合は、DB インスタンスの再作成処理が行われる。通常は10分未満で完了する。
6. フェイルオーバーの完了を確認する
1分程度待ち、「ステータス」が「利用可能」となれば、フェイルオーバーは完了。
今回のフェイルオーバーにより、リードレプリカ 1 (aurora-test-cluster-read-replica-1) がプライマリ DB に昇格して、元プライマリ DB がリードレプリカとなったため、期待通り。
参考文献
Amazon Aurora PostgreSQL のリードレプリカの追加
はじめに
Amazon Aurora PostgreSQL (以下、Aurora PostgreSQL) の DB クラスタにリードレプリカを追加する方法をまとめる。
実施方法
下記の3つの方法で追加が可能。
ここでは、「AWS マネジメントコンソールを利用する方法」と「AWS CLI を利用する方法」を検証する。
AWS マネジメントコンソールを利用する方法
AWS マネジメントコンソールを利用してリードレプリカを作成する方法を記載する。
1. AWS マネジメントコンソールで Amazon RDS のコンソールに移動する
2. 「データベース」を選択する
3. DB クラスタと DB インスタンスの「ステータス」を確認する
DB クラスタと DB インスタンス (ソース DB) の「ステータス」が「利用可能」であることを確認する。
4. 「アクション > リーダーの追加」を選択する
5. 「リーダーの追加」でリードレプリカの設定をする
設定項目はクラスタ (インスタンス) の作成時と基本同じ。 AZ の配置など要件に従って設定を行う。
設定の入力が終わったら、「Add reader」を選択する。
6. 「ステータス」が「利用可能」となったことを確認する。
設定値に不備などがなければ、「データベース」に戻る。 リードレプリカは「ロール」が「読み込み」と表示される。
数分程度待ち、「ステータス」が「利用可能」となれば、作成完了。
AWS CLI を利用する方法
AWS CLI の create-db-instance コマンドを利用する。
実行コマンド
下記のコマンドにて作成する。
aws rds create-db-instance --db-instance-identifier aurora-test-cluster-read-replica-2 \ --db-cluster-identifier aurora-test-cluster \ --engine aurora-postgresql \ --db-instance-class db.t3.medium \ --availability-zone ap-northeast-1d
引数の意味と設定値は順番に下記の通り。
引数 | 設定値 |
---|---|
db-instance-identifier (DB インスタンス名) |
aurora-test-cluster-read-replica-2 |
db-cluster-identifier (DB クラスタ名) |
aurora-test-cluster |
engine (DB エンジン) |
aurora-postgresql |
db-instance-class (DB インスタンスクラス) |
db.t3.medium |
availability-zone (DB インスタンスを配置する AZ) |
ap-northeast-1d |
コマンドに不備がなければ、下記のような出力 (ここでは yaml 形式で出力) が返される。 今回作成したリードレプリカに加えて、DB クラスタの既存リソースの情報も出力されている点に注意する。
DBInstance: AllocatedStorage: 1 AssociatedRoles: [] AutoMinorVersionUpgrade: true AvailabilityZone: ap-northeast-1d BackupRetentionPeriod: 1 CACertificateIdentifier: rds-ca-2019 CopyTagsToSnapshot: false CustomerOwnedIpEnabled: false DBClusterIdentifier: aurora-test-cluster DBInstanceArn: arn:aws:rds:ap-northeast-1:12345678912:db:aurora-test-cluster-read-replica-2 DBInstanceClass: db.t3.medium DBInstanceIdentifier: aurora-test-cluster-read-replica-2 DBInstanceStatus: creating DBName: aurora_test_db DBParameterGroups: - DBParameterGroupName: default.aurora-postgresql11 ParameterApplyStatus: in-sync DBSecurityGroups: [] DBSubnetGroup: DBSubnetGroupDescription: Created from the RDS Management Console DBSubnetGroupName: xxxxx SubnetGroupStatus: Complete Subnets: - SubnetAvailabilityZone: Name: ap-northeast-1a SubnetIdentifier: subnet-xxxxxxxx SubnetOutpost: {} SubnetStatus: Active - SubnetAvailabilityZone: Name: ap-northeast-1d SubnetIdentifier: subnet-xxxxxxxx SubnetOutpost: {} SubnetStatus: Active - SubnetAvailabilityZone: Name: ap-northeast-1c SubnetIdentifier: subnet-xxxxxxxx SubnetOutpost: {} SubnetStatus: Active VpcId: vpc-xxxxxxxx DbInstancePort: 0 DbiResourceId: db-xxxxxxxxxxxxxxxxxxxxxxxxxx PubliclyAccessible: false ReadReplicaDBInstanceIdentifiers: [] StorageEncrypted: false StorageType: aurora TagList: [] VpcSecurityGroups: - Status: active VpcSecurityGroupId: sg-xxxxxxxxxxxxxxxxx
AWS マネジメントコンソールを確認すると、リードレプリカが追加されている。
数分程度待ち、「ステータス」が「利用可能」となれば、作成完了。
注意事項
- リードレプリカは、最大15個まで作成が可能。
- マルチマスタークラスタでは、リードレプリカの構成がサポートされていない。
- Aurora では、異なるリージョン (クロスリージョン) でリードレプリカを構成できない。異なるリージョンで読み取り用のレプリカを構成したい場合は、グローバルデータベースを利用する。