みなさんこんにちは、グリドンです。 前回の記事を読んでくださった皆さん、ありがとうございます。 前回の記事から、気づけば1年が空いてしまいました。みなさんは、2021年良い年になったでしょうか。 さて、今回は2021年滑り込みでAWS Certified Developer - Associateの資格を取得したので、どのように資格取得に挑んだかを書こうと思います。 AWSの試験とは 簡単に説明すると、Amazon Web Services（AWS）が提供している、クラウドのサービスの理解度を図る試験です。 認定レベルはいくつかあります。 基礎コース アソシエイト ←今回私が受験したレベル プロフェッショナル 専門知識 AWSに全く詳しくなかった一年前は、基礎コースの「クラウドプラクティショナー」の資格を取得しました。 「クラウドプラクティショナー」の試験、まだAWSについて詳しくしらない方などにはおすすめ。また、試験に合格すると次回の試験料が半額になるクーポンももらえます。 難しいレベルになればなるほど、試験料が上がるのでこちらの試験を先に取得すると良いと思います。 詳しく知りたい方は、こちらのURLを参考にして下さい。 どのように勉強したか 以前、クラウドプラクティショナーの資格を取得した時もそうなんですが、僕は基本的にUdemyで勉強します。 他のオンライン授業サービスを利用したことはないので、どれが一番良いかなど比べての評価はできませんが、 Udemyはたくさんの講師の方がいて、自分の好きな講師を選ぶことができるので、Udemyが好きな一つの理由です。 今回私が受講したのはこちらのコース https://www.udemy.com/share/101WES3@8MkoBjAew9IyD6eFeeAPtg3-lWrUv76uun-CVWK0dIkpuD9shpwgQLpARPUdc8pH/ 正直に言うと、、、 あまりよくなかったです。 まあ、安い時で1000円ちょいだったので、文句をいうこともできませんがw 何が具体的に悪かったかと言うと、 何を言ってるのかわからない（アクセントの問題） 教える内容が薄い 付属のテストの内容が薄い（グラマーミスとかも多かった） 正直、これだけで本番受けるのは心配でした。 なので、下記の模擬試験を追加で購入しました。 https://digitalcloud.training/courses/aws-certified-developer-associate-practice-exams/ この人は、Udemyでも授業を複数提供していて、クラウドプラクティショナーの勉強はこの先生の授業を受講しました。 追加で購入した問題集のよかった点は、 本番に近い問題がたくさん出てきた 隙間時間にやりたいだけ問題を解くことができた と、個人的には買ってよかったと思います。 スマホで見にくかったり、どれぐらいやったかの進捗がうまく保存されなかったり、使いづらい所もありましたが、 本番で同じような問題も出てきたし、合格できたのはこの問題集のおかげかと思います。 試験の予約方法 試験の予約方法は、下記のリンクに詳しく載っています。 https://aws.amazon.com/jp/certification/certification-prep/testing/ 私は、Cloud Practitionerも、Developer Associateも自宅でオンラインで受験しました。 動作など遅いな〜やりにくいな〜と感じることもありますが、やはり自宅で受験したい時にできるのは非常に便利です。 ちょっとした裏技ですが、英語で受験すると追加で30分受験時間を与えてもらえます。 あと、試験管も英語で選ぶと試験時間の選択肢も広がるので、英語が可能な人は英語での受験をおすすめします。 試験当日 上記で登録した試験当日にパソコンでログインします。 9時からの場合、チェックインなど時間がかかる場合があるので30分くらいは早めにチェックインを開始することをおすすめします。 初めて受験した時ですが、チェックインに待ち時間があり開始時刻が大幅に遅れることがありました。 当日このようなことが起きると、精神てきによくないので余裕を持ってチェックインを開始して下さい。 結果は、試験をサブミットした時点で画面に表示されます。 正式な通知はその日または次の日には、送られてきて証明書のダウンロードも可能です。 まとめ 以上、私のAWSの試験記録でした。 これから試験を受ける方の少しでも参考になれば嬉しいです。

AWS Cloud Practitiner Essential 殴りがき Amazon CloudWatch クラウド内で使っているサービス(AWS インフラストラクチャ) も クラウド内で実行しているアプリケーション(自分達のサービス)もどちらも監視・可視化できる。 一元的な場所からすべてのメトリクスにアクセスできる -> 分散した監視対象を一括して可視化できる。 AWSのクラウドサービス クラウド内で実行するアプリケーション オンプレミスのアプリケーション　など。 MTTRを短縮できるため、コストが下がる。 ダッシュボード ClaudWatchで監視しているものをダッシュボードで一覧できる。 Amazon CloudWatch アラーム 監視したいメトリクスを指定して閾値を設定するだけ。 閾値を上回った・下回った場合にアクションを実行するアラームが作成できる。 メトリクス: リソースに関連付けられている変数 アマゾンSNSと統合できるため、アラームと通知を同時にできる。 ex: EC2を停止し忘れるのを防ぐため、EC2のCPU使用率が一定の閾値を下回った(使用していないと判断できる)際に、自動的に停止するアラームを作成できる。 AWS CloudTrail AWS環境内で発生したユーザーアクティビティとAPIコールの詳細を確認できる AWSへのすべてのAPIリクエストを記録する。誰が・いつ・何を・どのように。 ログは、S3のバケットに無制限に保存する。 監査の際の証明となる。 記録する情報は APIコール元のID APIコール時刻 APIコールもとのソースIPアドレス　など。(何を使ってリクエストを送ったのかわかる。) APIの事象 イベント発生後15分以内に記録される 閲覧時は、各情報を絞り込みができる。 CloudTrail Insights CloudTrailのオプション機能。 AWSアカウントの異常なAPI実行を自動的に検出できる。 AWS Trusted Advisor AWSサービスを使う上でベストプラクティスに基づいて適切な方針を自動アドバイスしてくれる。 以下の項目についてそれぞれアドバイスをくれる。 コスト最適化 パフォーマンス セキュリティ 耐障害性 サービスの制限 カテゴリの評価は以下の通り。 緑: 問題が検出されなかった オレンジ: 調査が推奨される 赤: 修正アクションが推奨される

Elastic IPとEC2インスタンスの紐付けができたので、 セキュリティグループの設定をしてみます！！ AWSのセキュリティグループとは？ VPC（AWSネットワーク）上で通信制御をするファイアウォール機能だそうです。 Amazon VPC(Amazon Virtual Private Cloud)とは、 AWS上に作成できるプライベート仮想ネットワーク空間です。 AWSアカウント内に専用のネットワークを作成でき、 このネットワーク内に「EC2」などのAWSリソースを配置できます。 Amazon VPCの代表的なコンポーネントは、以下になります。 ※コンポーネントとは、機器やソフトウェア、システムの構成する部品や要素などのことを意味する ・サブネット｜大きなネットワーク内の小さなネットワーク ・インターネットゲートウェイ｜Amazon VPCとインターネットを接続するための出入り口 ・ルートテーブル｜パブリックサブネット内のリソースがどこにアクセスするか？のルールを定めた表 Let's try ! まずAWSコンソールのEC２ インスタンス > 作業環境の「 Furikaeri-Dev 」 のセキュリティをクリック！ あれ？なんかある、先約？ もうセキュリティグループが設定してあるぞ？？ おかしいな？ みんなで相談した結果、VPCを作ってみよう！ということに。 VPCを作ろう! VPCの作成ボタンを押下して適宜設定を入力して…作成ボタンを押下したが！ エラーが！！ 調べると、VPCの作成に上限値があり、既に上限値に達していたのでした。。。 OMG… なので、他のインスタンスと紐付いているので、削除していいか K池さんに確認が必要になり、今日の作業はここまでとなりました。 ちなみにK池さんから既にある研修用のVPC消していいと許可が出ているので、 次回は消してしまおうと思います。 (これに紐付いているインスタンス等も削除してしまってOKとのこと) 今回はここまで〜 written by ジョジョ６部のアニメが始まって嬉しい大森

TL;DR CodePipelineでCodeCommitからECR、ECSへデプロイするために必要な 設計ポイントが書いてあります。 実際の構築手順を期待している方には残念な記事です。 事のはじまり よくあるオーダーなんですが 「今まで手作業だった業務をシステム化したい」 に追加して 「コンテナ化してCICDで自動的にデプロイしたい」 というオーダーになり 突貫工事で作ることになったので　やっつけてきました。 やったこと CodeCommitをリポジトリにしたよ CodeBuildでテストコードを実行させたよ CodeBuildでdocker buildしてECRにPUSHしたよ CodeCommitでマージしたら自動でFargateまでローリングデプロイする仕組みにしたよ 本番環境が別AWSアカウントでも自動デプロイ対応だよ SSMパラメータストアを活用することでマルチアカウント間でもパイプラインが動作するよ 用意するもの AWSアカウント dockerfile イメージ定義ファイル buildspec.yml 詳しく掘らないもの webコンソールの操作方法 pytestの使い方 コンパイル言語でビルドした出力アーティファクトをパイプラインに乗せてデプロイする方法 オシャンなコンテナの実装 オシャンなパイプラインの構成 オシャンなbuildspec.ymlの実装 イケてるNginxの設定 イケてるuWSGIの設定 ABデプロイ デプロイ種別で変わるイメージ定義ファイル 1Container1process 構成 使用するアカウント種別 開発環境AWSアカウント 本番環境AWSアカウント ※開発と本番のアーティファクトのデータ移動は手動でやるものとします。 ※ステージング環境が増えても、やることは変わらんです。 使用するAWSのサービス VPC ECS/Fargate ECR SystemsManager ELB CodeCommit CodeBuild CodePipeline S3 IAM １．VPC イイカンジに作ってください。 Public Subnet、Private Subnetがあるなら Private SubnetはNATゲートウェイもしくはVPCエンドポイントが必須です ２．ECS/Fargate 常時稼働するか？バッチ的にタスクが起動するだけか？で設定が変わります。 ①常時起動が必要なコンテナ クラスター サービス タスク定義 いわゆるWEBサービス的に起動するサービス。 このあたりの設定が必要です。 タスク定義を作ってクラスター作ってサービスを作ります。 ※先に下記ELBから作っておくと面倒が少なくてよいかも。 ②バッチ的に起動するコンテナ クラスター タスク定義 バッチ処理の場合EventBridgeから起動することが多いとおもいます。 その場合 イベントソース→EventBridge→ECS/Fargate という経路になるため、ECSサービスを定義する必要はないです。 ３．ECR ECRへのPUSHをトリガーにFargateへデプロイします。 ECRリポジトリを作っといてください。 ４．SystemsManager パラメータストアに辞書形式で色々と保存しておくと、 開発/商用間の環境差分を吸収するのがシンプルに楽です。 アプリ側もパラメータストアを参照してDB等のエンドポイントを参照するようにしてください。 DBへのアクセスをIAMで認証する場合、ユーザ情報の保存は不要です。 ５．ELB FargateがローリングデプロイするためのALBとターゲットグループを作成しておいてください。 コンテナがデプロイされるまで、ターゲットは空っぽでよいです。 ６．CodeCommit リポジトリ作っておいてください。 パイプラインが発火するブランチ名を決めておくとイイカンジです。 特定ブランチは消させない 特定ブランチへのPUSHを拒否する といった運用はIAMロールで制御してください。 ７．CodeBuild テスト実行用のコンテナを用意しておくと色々と使い勝手が良いですが、 このあたりは設計に合わせてください。 また、CodeBuildに渡される入力アーティファクトはenvに渡されます。 何度かecho $envなどを繰り返して、入念に期待する動作するか？を試してください。 webコンテナ APPコンテナ testexeコンテナ こんなような構成が好きです。 Buildspec.ymlは別個に書くのはあんまり好きくなくて CodeBuildには軽く書いといて、実際の処理はbashなどに書くのが好きです。 Dockerのデーモン化に結構苦しめられたので、UPしておきます。 version: 0.2 phases: install: commands: - nohup /usr/bin/dockerd -H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock & - timeout 15 sh -c "until docker info; do echo .; sleep 1; done" pre_build: commands: - git config --global credential.helper '!aws codecommit credential-helper $@' &&git config --global credential.UseHttpPath true &&git config --global user.email "example@example.com" &&git config --global user.name "UNKO" build: commands: - bash boot-ctrbld.sh ちなみにgit ８．CodePipeline ざっくりですが、下記ステージの構成を取るとイイカンジになります。 アプリソースとコンテナdockerfileを1まとめのブランチに置いている前提で進めています。 ①開発環境 パイプラインA Source：CodeCommit アクション名：source 変数名：source 出力アーティファクト：source CodeCommitの発火したいブランチ名をターゲットにしてください。 Build：CodeBuild アクション名：build 変数名：build 入力アーティファクト：source 出力アーティファクト：build codebuildで起動したコンテナを使って pytestを実行したあと、dockerfileにdocker buildとdocker pushします。 ここでテストしてビルドが通る事を確認しておきましょう。 Deploy：S3 アクション名：deploy 変数名：deploy 入力アーティファクト：source S3へのデプロイソースをSourceアーティファクトにしているにはワケがあります。 商用環境パイプラインにアーティファクトを送るとき、開発で取得した構成やら何やらを変えたくない。 別にビルドしたりコンパイルしているワケではない。 どうせDockerfileも送るんだし、素の状態で送っとけ テストが通ったアーティファクトさえ送れるならヨシ！ パイプラインB Source：ECR、S3 アクション名：source01 変数名：source01 出力アーティファクト：source01 アクション名：source02 変数名：source02 出力アーティファクト：source02 このsource02と呼んでいる箇所がイメージ定義ファイルになります。 SystemsManagerやCodeCommit内に置いても読み込むんちゃうかと思いましたが、 S3に置いてるパターンが多いのでS3に置いてます。 https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/file-reference.html Deploy：ECS アクション名：deploy 変数名deploy 入力アーティファクト：source01、source02 これでサービス登録されたECSクラスターにデプロイが可能となります。 サービス登録していない場合へのデプロイは、パイプラインAでECRにPushしたと思いますが その時点で作業終了です。 ローリングデプロイしたい場合はサービス化しておく必要があるって感じですね。 ②本番環境 パイプライン Source01：S3 どうにかして開発パイプラインAでS3にデプロイした成果物を 本番S3バケットに置いてください。 Build：CodeBuild CodeBuildで入力アーティファクトに対して下記の処理を行ってください。 DockerfileをbuildしてECRにPUSHしてください。 Source02：ECR、S3 開発環境と同じく、ECRとイメージ定義ファイルを指定してください。 Deploy：ECS ECSにデプロイして終了です。 反省点 時間が無くて、コンテナのブランチとAPPのブランチを分けちゃったのが結構面倒でした。1 結局DockerImageBuildするときAPPファイルも組み込むんだし、まとめられるパイプラインはあるなぁ、と。2 次作るときは下記気を付けたいです。 CodeCommitでマージするときブランチ消させたくない。 デフォルトブランチにPushすんな権限付けたい。 イメージ定義ファイルをS3じゃなくて、パラメータストアとかリポジトリに格納する方法を調べる。 CodeBuildは本当に色々やれそう こうして書き起こすとクッソ面倒ですけど CodeCommitからターゲットまで「えい！」でデプロイできるのは本当に強いので インフラメンバーとアプリ共通メンバーに置かれましては ぜひ導入をご検討ください。 分けるメリットもあると思いますが、パイプライン追うのが面倒でした。 ↩ ※そういう仕組みにしてるなら別ですけどね。起動時にCodeCommitから持ってくるみたいな。ただ起動時にCodeCommitから持ってくる分遅くないっすか？コンテナ重くなりませんか？という。 ↩

タイトルは検証内容です。 2021年6月から開始したQiitaへの投稿ですが、年末にレポートを頂きました。 非常に嬉しかった記憶があります。 せっかくなので、Qiitaに関する情報を元にAmazon Quicksightでダッシュボードを作成してみました。 最終的なダッシュボードを以下のように作成しました。 今回は、検証プロセスをQuicksightの仕様と交えて説明していきます。 Amazon Quicksight について Amazon QuickSight とは AWSのフルマネージドサービスであり、クラウド上のBIサービスです。多様なデータソースへ接続し、結合します。 ビジュアルと呼ばれるUIをアレンジし、ダッシュボードを公開する事で、閲覧者から用途に合った情報を取得する事が出来ます。 全体イメージ QuickSight の全体イメージとなります。 QuickSightは、Standard Edition と EnterPrise Edition が存在します。制約は後程記載します。 開発者・分析者は、データセット、分析、ダッシュボードという段階的なプロセスを経て、閲覧者に適切なUIを提供します。 データセット データセット はQuicksightからUIを表示する際に初めに作成します。 データセットを作成する際、データソースを選択します。新規のデータソースから選択する事も、既存のデータソースを選択する事も可能です。以下のように多様なデータソースをサポートします。今回は S3 の CSV を使用します。 データソースの選択が完了すると、データセット上からクエリエディタを使用して、表示したいフィールドの加工、抽出、SPICEの使用などの選択を行います。 フィールドとは、QuickSightがデータソースから認識する、あるいは加工された計算フィールドより認識される一意のデータの集合体となります。フィールドは、後述するいずれのビジュアルタイプにおいても重要な項目となります。 計算フィールドとは、データソースから取り込んだ既存のフィールドに対して、演算子や関数を使用して独自のフィールドを作成するものです。QuickSight 上でフィールドとは別に新しく認識され、計算フィールドを後述のビジュアルタイプから選択する事が出来ます。なお、Quicksight では多数の関数をサポートしております。 SPICE とは、インメモリであり、データソースのデータをインポートをします。これにより、データソースへ直接クエリを発行する必要がなくなり、パフォーマンスが向上します。但し、SPICE上へ保存できるデータ容量には制限がありますので注意が必要です。 Quick sightにおける カスタムSQLクエリとは、Quicksightからデータソースに実行するSQLを事前に定義する事です。通常は SELECT ステートメントを直接実行しますがカスタムSQLクエリにより、抽出するデータの変更が可能です。 Quicksight はクロスデータソース結合と呼ばれる複数のデータソースに対する、JOIN がサポートされます。データセットを作成する際に複数のデータソースを使用する場合、こちらを使用します。Inner / Left / Right / Full Outer JOIN をサポートします。 表示させるデータ、SPICEの選択を経てデータセットを作成します。 分析 データセットが作成すると、分析の画面へ遷移します。 分析のイメージは以下です。 レイアウト レイアウトは、後述のビジュアルを表現する際のフォーマットを指定します。 2021年に新しくフリーフォーマットが使用可能となり、正確な座標を使用してダッシュボードのどこにでも配置できます。また、ビジュアルのオーバーラップが可能となり、重複する座標上で対象のビジュアルの前面、背面に指定する事で、UIの構成に幅が広がりました。 テーマ テーマとは、対象の分析やダッシュボードに適用させるレイアウトの中の設定項目です。具体的には、シートの文字の色や背景色、分析内のグリッド線、枠線、フォントなどを全て指定出来ます。また、独自のテーマを作成する事が可能で、テーマや好みに合ったUIをデザインする事が出来ます。 ビジュアルタイプ 上記の設定が完了すると、ビジュアルを挿入していきます。 ビジュアルとは表やグラフ、画像動画など、一意のオブジェクトを示します。 用途に合ったビジュアルタイプを追加する事で、分析内のシート内にビジュアルを挿入する事が出来ます。 ビジュアルタイプとして様々な形式のグラフを使用する事が出来ます。 主要業務指標(KPI) ゲージグラフ ドーナツグラフ 円グラフ 棒グラフ(各種) 折れ線グラフ ピポットテーブル テーブル ヒートマップ 散布図 カスタムビジュアルコンテンツ (URL形式であればWebコンテンツのオンラインビデオ等も挿入可能です) ビジュアル毎に表示出来るデータに制限事項があります。 開発を行う際は、表示したいビジュアルタイプの制限事項はクリアにしといた方がよいかと思います。 ビジュアルでのフィールドの使用 ビジュアルの挿入が完了したら、分析内で認識されているフィールドを各ビジュアルの形式に沿ったフィールドウェルへ挿入していきます。 以下の例では、テーブル形式のビジュアルを選択しています。 フィールドリストには LGTM / Posted Date / Stock / Tag / Title のフィールドが存在し、これらをフィールドウェルへ挿入していき、テーブルを作成していきます。 なお、フィールド毎のアイコンの違いは、データタイプの違いとなります。 これはデータセットを作成する際にQuicksightが認識するデータタイプであり、変更も可能です。 例えば、Posted Dateは日付形式のデータタイプへ変更していますが、文字列などの異なるデータタイプへ変更が可能です。 分析のUIが完了したら、共有から、ダッシュボードの公開を押下して、ダッシュボードが公開されます。 ダッシュボード ダッシュボードは、閲覧者が共有できる、分析の読み取り専用のスナップショットであり、公開時の分析設定が保存されます。 ここで権限について記載します。 ユーザー設計・アクセス設計 ユーザー管理 Quicksight を使用するユーザーは、IAM ユーザーを保持する事が必須条件ではありません。 後述する管理者が、有効なEメールアドレスへ招待メールを送信できます。招待されたユーザーがサインアップすると、新しいQuickSight専用のユーザーアカウントとして作成されます。 また、IAMユーザーを招待することもできます。 この場合は、IAM認証情報を使用してQuickSightにサインインします。 招待されたIAMユーザーは、上記と同様に有効なEメールアドレスも持っている必要があります。 なお、SSOや、Microsoft Active Directoryを使用したユーザー管理、Idp などもユーザー管理として使用出来ますが、私から EnterPrise Edition の検証は実施できない為、割愛します。 管理・操作・閲覧ユーザーの権限分離 EnterPrise Editionでは、マルチテナントをサポートしています。 マルチテナントとは同じアカウント上に、ネームスペース(名前空間)を作成する事が出来ます。 複数のネームスペースでは、Quicksightのリソース、ユーザーがネームスペース単位で作成されます。 例えば、一つのアカウント上でQuicksightを使用したいが、操作出来るリソースは部署単位で分けたい。といったオーダーに適しているかと思います。 また、Quicksight では、後述するユーザーを一括りにしたグループの生成が可能です。 aws quicksight create-group --aws-account-id=111122223333 --namespace=default --group-name="Sales-Management" --description="Sales Management - Forecasting" これにより、特定のダッシュボードをユーザーではなくグループ単位でセキュリティを管理する事ができます。 いずれもはAWSコンソールからではなく、AWS CLIから操作するという点も特徴の一つです。 ユーザー権限 QuickSight は Edition により、登場人物(Role)が異なります。 管理者(Admin) ユーザー管理やSPICE 容量の購入などの管理タスク等の実行権限を持ちます。 また、ロールとしての管理者と、IAM 管理者ユーザーが存在し、これもまた、権限が異なります。 IAM 管理者ユーザーは、管理者権限および、アクセス許可の管理や、Editionのアップグレード、サブスクリプション解除も行うことができます。 作成者(Author) データセットの作成、分析とダッシュボードの作成などを行う権限を持ちます。 作成者の権限範囲は広いため、Authorの権限を制限する事も可能です。 閲覧者(Reader) Enterprise Edition のみ、共有されたダッシュボードを操作できる Reader が存在します。 AWS サービスへのアクセス権限 Quicksight では、データソースへアクセスするサービスに対してIAMポリシーによる許可する必要があります。 IAM で Amazon QuickSight を使用する 追加のポリシーのアタッチ Amazon Athena や Amazon S3 などの別の AWS のサービスを使用している場合は、特定のアクションを実行するための QuickSight アクセス権限を付与するアクセス権限ポリシーを作成できます。その後、後で QuickSight に渡す IAM ロールにポリシーをアタッチできます。 Amazon QuickSight で既存の IAM ロールを使用する QuickSight 管理者で、QuickSight リソースを更新して IAM ロールを渡す権限を持っている場合は、QuickSight で既存の IAM ロールを使用できます。 補足情報 今回、検証で使用しなかった埋め込み分析、Amazon QuickSight Qや ML insightなどがあります。いずれも EnterPrise Edition から利用可能な機能ですが、Quicksightの分析への拡張性があるものかと思います。 埋め込み分析の操作(EnterPrise Edition) Machine Learning (ML) Insights の使用(EnterPrise Edition) Amazon QuickSight Q の使用 (EnterPrise Edition) ファイルのエクスポート ダッシュボードや分析から CSV/EXCEL/PDF といったファイル形式へのエクスポートも可能です。 静的な情報になりますが、今回作成したPDF ファイルを画面キャプチャします。 参考文献 Amazon Quicksight User Guide

先日AWSの認定資格をすべて取得完了しました。いま取得可能なAWS認定資格はβ版を除き11個ですが、廃止になった資格をまだ1つ保持していますので、12個になりました。そのうち半分以上の7個を最後の1ヶ月ほどで取得しました。 これまでの資格取得を軽くまとめます。 これまでに取得した資格 ここ数年で取得した資格の一覧です。せっかくなのでAWS以外も含みます。リンクは私の合格体験記です。（1個目だけQiita始める前だったから記事がない） 取得時期 試験名 レベル 成績 / 合格ライン 2019/09 AWS Certified Solutions Architect Associate アソシエイト 867 / 720 2019/10 AWS Certified Big Data Specialty 専門知識 66% 2019/11 AWS Certified Machine Learning Specialty 専門知識 807 / 750 2020/05 日本統計学会 統計検定 2級 2020/07 日本ディープラーニング協会 G検定 2020/10 AWS Certified Database Specialty 専門知識 794 / 750 2021/07 AWS Certified Developer Associate アソシエイト 916 / 720 2021/07 Google Cloud Certified Professional Cloud Architect 2021/07 Google Cloud Certified Professional Cloud Developer 2021/07 Google Cloud Certified Professional Data Engineer 2021/12 AWS Certified Data Analytics Specialty 専門知識 812 / 750 2021/12 AWS Certified SysOps Administrator Associate アソシエイト 777 / 720 2021/12 AWS Certified Security Specialty 専門知識 875 / 750 2021/12 AWS Certified Advanced Networking Specialty 専門知識 793 / 750 2021/12 AWS Certified Cloud Practitioner 834 / 700 2022/01 AWS Certified Solutions Architect Professional プロフェッショナル 803 / 750 2022/01 AWS Certified DevOps Engineer Professional プロフェッショナル 885 / 750 私の経歴は、2019年夏ごろまではAWSを直接触る機会はほとんどなく、用意されているAWSインフラ上でサーバサイド開発をするエンジニアでした。2019年秋ごろからAWSを扱う仕事を始め、認定資格も取得し始めました。2020年はAWS受験をサボっていて1個だけにとどまりました。2021年は一時期Google Cloudに浮気して連続受験したのち、12月から年始にかけての1か月で7連続受験をしました。いまのところすべて一発合格です。 認定資格を取得し始めてから2年余りかかりましたので、今年にはもう更新が始まります。 全部取得してよかったこと 全部取得して本当によかったです。AWSのサービスを一通り知る機会になります。特にSolution Architect Professionalの勉強では、AWS全般を広く知ることになります。資格そのものよりも勉強したことに価値があります。試験ごとに少しずつ試験範囲が重なっています。すべての試験を受けると、同じことを何度も、少しずつ視点を変えて勉強することになります。多角的な理解つながります。 AWSの各サービス内容や機能は必要になったときに調べればいいと思っていたのですが、そもそも存在を知らない概念（サービス、機能、考え方）は調べるに至りません。手持ちの知識だけでなんとかしようとしてしまい、アンチパターンになってしまうこともあります。無知なことは恐怖に思います。いままでこの内容を勉強せずにAWSを業務で扱っていたのかと思うと。 プロフェッショナルのレベルまで取得したとしても、広く浅い知識なので、実際に使うにあたってはもちろんわからないことたくさんあって、調べながら実装していくことになります。今回全資格を取得して初めてAWSのスタート地点に立ったと感じます。 AWS認定資格の受験の順序 ここは全部取得したいという人向けの説明です。 最初はやはりクラウドプラクティショナーを受けるべきです。どうせ全部集めるならばです。 その次は、AWSのサービス全般の概要を把握するためにも、ソリューションアーキテクトアソシエイトがよいです。私も最初に受けました。 それ以降は、アソシエイトだからとか専門知識（スペシャリティ）だからというのは、難易度に差は感じませんでした。単に苦手な領域ほど難しく感じます。得意だと思うもの、もしくは伸ばしていきたい領域から受ければよいと思います。苦手な領域が最後の方に残りますが、徐々にAWS全般の知識が溜まってくるので、受けやすくなります。私は最初にビッグデータや機械学習、最後のほうにセキュリティやネットワークと、いま振り返っても私のスキルとしては正しい順序だったと思います。 プロフェッショナルの2つはどちらが先でもいいと思いますが、いずれにせよスペシャリティなどを受験した後、記憶が残っているうちに続けて受けてしまうのがよいです。プロフェッショナルとスペシャリティどちらが先に受けるべきかについては両論あると思いますが、私はスペシャリティのほうが勉強しやすかったです。勉強範囲が比較的明確なためです。スペシャリティよりもプロフェッショナルを先に受けたときのプロフェッショナルの勉強方法は想像つきません。 私はクラウドプラクティショナーの受験順序だけ明らかに間違えています。みなさんの記事を見ていると、私同様にクラウドプラクティショナーを取り損ねてコンプリート目的であとから受験している人もいそうですね。 連続受験 最初のころは1つずつ慎重に受験していましたが、徐々に受験に慣れてきますので、連続して受験するのがいいと思います。私は12個中、7個を最後の1ヶ月で取りました。勉強する範囲が少しずつ重なっているので効率がいいです。3年後の資格更新時期にひどい目に合いそうですけどね。 ある程度AWSをエンジニアとして扱っていれば、あとは受験するかどうかだと思います。受験申し込みをしたらそれに向けて必死に短期集中で勉強することになります。慣れてこれば、勉強してから受験申し込みではなく、申し込みをしてから勉強してもなんとかなります。 今回AWSコンプリートに至ったのは、昨年末に連続受験をし始めたのがきっかけです。 もともとは昨年夏に1個取得したあと、年内にあと2個くらいは取得しておきたいと思っていた ↓ しかしそのままずるずると12月になってしまい、12月中に2個受験することに ↓ 思い返せば7月にGoogleを3連続受験している → AWSも3連続受験をしてみよう ↓ スペシャリティを1つ残すだけになる → 残り1つも取得してしまおう（4連続） ↓ プロフェッショナルとクラウドプラクティショナを残すのみになる → なんとなくクラウドプラクティショナーを残して年超すのが気持ち悪いので、続けて取得（5連続） ↓ プロフェッショナルも直近の連続受験の記憶が残っているうちに受験したほうが楽だと思い至る → 年明けに2つのプロフェッショナル資格を取得（7連続） ↓ 結果、コンプリート達成 勉強方法 私の実際の具体的な勉強方法は、最初に挙げた合格体験記の各記事に書いています。 AWSの試験を受け始めたころは、一般的な本を読んだり、実際に関連するサービスを触ってみたりもしていました。Udemyにある模擬試験を買ったこともあります。後半（最近1カ月）は、YouTubeやSlideshareなどで上がっているBlack Beltの資料と、PDFで公開されているサンプル問題と、BenchPrepというので受けられる模擬試験だけでほぼカバーしていました。 以下、箇条書きで勉強方法をまとめておきます。 試験対策の本 Solutions Architect AssociateとProfessionalは、対象サービスが多岐にわたるので、本で全体を理解するのが役に立ちました セキュリティのスペシャリティも本があります 出題範囲が特化している試験は、ある程度AWSに慣れてこれば、本を買わなくてもBlack Beltの資料で足りそうです 一般的な本 ビッグデータとは、機械学習とは、セキュリティとはみたいな 受けようとする試験の領域が苦手だったり自信がない場合には、最初に本を読んだこともありました Black Belt Online Seminarの資料 リンク: サービス別資料 | AWS クラウドサービス活用資料集 AWSのドキュメントと違って、必要な情報がコンパクトにまとまっています AWSにある程度慣れてきている人にとっては、勉強ソースとして一番使いやすいです Solutions Architect AssociateとProfessionalは、対象サービスが多岐にわたるので、Black Beltを通読するのは辛いかも PDFのサンプル問題 試験の対象領域を理解するためにサンプル問題を最初にやっておくとよいです 試験対策の本がある場合は、本を読むことで領域がわかるので、サンプル問題は最後に模試代わりに使ったこともあります BenchPrep 無料で手に入る模擬試験なので、必ず解いてみるべきです Black Beltだとかから漏れている知識も手に入ります Udemy等にある模擬試験 BenchPrepがないころはここで模擬試験を購入したことがあります。koiwaclubというのもあるらしいです 難易度が実際の試験とギャップがある場合もあり、あまりこういった模擬試験に惑わされないほうがよいです Qiitaなどにある先輩の方々の合格体験ブログ記事 出題範囲や勉強方法の参考とします 合格した人を見て、自分も合格したいという気持ちをおこします AWSドキュメント 問題集などでわからない点があったときに、ググって出てきたページがAWSドキュメントならばそれを読みます AWSドキュメントを一通り読むのは、私には読解力も読解スピードも足りなくて無理でした いずれの媒体を使うにしても、得た知識は自分で整理してノートにまとめます。自分の言葉で書くことに意味があります。試験を繰り返すと同じ領域の知識を深掘りすることになるので、ノートが更新されていきます。アソシエイトレベルでは、機能の一覧だけ書いてあったところが、プロフェッショナルやスペシャリティでは各機能の詳細を書き足していくようなイメージです。私はScrapboxというサービスで知識を整理しています。 おわりに AWSの全資格を取得したことで、広く浅くの知識が手に入りました。繰り返しますが、全部受験してよかったです。今後は全資格の更新受験を繰り返すことで、知識のベースを維持していきたいと思います。

先日AWSの認定資格をすべて取得完了しました。いま取得可能なAWS認定資格はβ版を除き11個ですが、廃止になった資格をまだ1つ保持していますので、12個になりました。そのうち半分以上の7個を最後の1ヶ月ほどで取得しました。 これまでの資格取得を軽くまとめます。 これまでに取得した資格 ここ数年で取得した資格の一覧です。せっかくなのでAWS以外も含みます。リンクは私の合格体験記です。（1個目だけQiita始める前だったから記事がない） 取得時期 試験名 レベル 成績 / 合格ライン 2019/09 AWS Certified Solutions Architect Associate アソシエイト 867 / 720 2019/10 AWS Certified Big Data Specialty 専門知識 66% 2019/11 AWS Certified Machine Learning Specialty 専門知識 807 / 750 2020/05 日本統計学会 統計検定 2級 2020/07 日本ディープラーニング協会 G検定 2020/10 AWS Certified Database Specialty 専門知識 794 / 750 2021/07 AWS Certified Developer Associate アソシエイト 916 / 720 2021/07 Google Cloud Certified Professional Cloud Architect 2021/07 Google Cloud Certified Professional Cloud Developer 2021/07 Google Cloud Certified Professional Data Engineer 2021/12 AWS Certified Data Analytics Specialty 専門知識 812 / 750 2021/12 AWS Certified SysOps Administrator Associate アソシエイト 777 / 720 2021/12 AWS Certified Security Specialty 専門知識 875 / 750 2021/12 AWS Certified Advanced Networking Specialty 専門知識 793 / 750 2021/12 AWS Certified Cloud Practitioner 834 / 700 2022/01 AWS Certified Solutions Architect Professional プロフェッショナル 803 / 750 2022/01 AWS Certified DevOps Engineer Professional プロフェッショナル 885 / 750 私の経歴は、2019年夏ごろまではAWSを直接触る機会はほとんどなく、用意されているAWSインフラ上でサーバサイド開発をするエンジニアでした。2019年秋ごろからAWSを扱う仕事を始め、認定資格も取得し始めました。2020年はAWS受験をサボっていて1個だけにとどまりました。2021年は一時期Google Cloudに浮気して連続受験したのち、12月から年始にかけての1か月で7連続受験をしました。いまのところすべて一発合格です。 認定資格を取得し始めてから2年余りかかりましたので、今年にはもう更新が始まります。 全部取得してよかったこと 全部取得して本当によかったです。AWSのサービスを一通り知る機会になります。特にSolution Architect Professionalの勉強では、AWS全般を広く知ることになります。資格そのものよりも勉強したことに価値があります。試験ごとに少しずつ試験範囲が重なっています。すべての試験を受けると、同じことを何度も、少しずつ視点を変えて勉強することになります。多角的な理解つながります。 AWSの各サービス内容や機能は必要になったときに調べればいいと思っていたのですが、そもそも存在を知らない概念（サービス、機能、考え方）は調べるに至りません。手持ちの知識だけでなんとかしようとしてしまい、アンチパターンになってしまうこともあります。無知なことは恐怖に思います。いままでこの内容を勉強せずにAWSを業務で扱っていたのかと思うと。 プロフェッショナルのレベルまで取得したとしても、広く浅い知識なので、実際に使うにあたってはもちろんわからないことたくさんあって、調べながら実装していくことになります。今回全資格を取得して初めてAWSのスタート地点に立ったと感じます。 AWS認定資格の受験の順序 ここは全部取得したいという人向けの説明です。 最初はやはりクラウドプラクティショナーを受けるべきです。どうせ全部集めるならばです。 その次は、AWSのサービス全般の概要を把握するためにも、ソリューションアーキテクトアソシエイトがよいです。私も最初に受けました。 それ以降は、アソシエイトだからとか専門知識（スペシャリティ）だからというのは、難易度に差は感じませんでした。単に苦手な領域ほど難しく感じます。得意だと思うもの、もしくは伸ばしていきたい領域から受ければよいと思います。苦手な領域が最後の方に残りますが、徐々にAWS全般の知識が溜まってくるので、受けやすくなります。私は最初にビッグデータや機械学習、最後のほうにセキュリティやネットワークと、いま振り返っても私のスキルとしては正しい順序だったと思います。 プロフェッショナルの2つはどちらが先でもいいと思いますが、いずれにせよスペシャリティなどを受験した後、記憶が残っているうちに続けて受けてしまうのがよいです。プロフェッショナルとスペシャリティどちらが先に受けるべきかについては両論あると思いますが、私はスペシャリティのほうが勉強しやすかったです。勉強範囲が比較的明確なためです。スペシャリティよりもプロフェッショナルを先に受けたときのプロフェッショナルの勉強方法は想像つきません。 私はクラウドプラクティショナーの受験順序だけ明らかに間違えています。みなさんの記事を見ていると、私同様にクラウドプラクティショナーを取り損ねてコンプリート目的であとから受験している人もいそうですね。 連続受験 最初のころは1つずつ慎重に受験していましたが、徐々に受験に慣れてきますので、連続して受験するのがいいと思います。私は12個中、7個を最後の1ヶ月で取りました。勉強する範囲が少しずつ重なっているので効率がいいです。3年後の資格更新時期にひどい目に合いそうですけどね。 ある程度AWSをエンジニアとして扱っていれば、あとは受験するかどうかだと思います。受験申し込みをしたらそれに向けて必死に短期集中で勉強することになります。慣れてこれば、勉強してから受験申し込みではなく、申し込みをしてから勉強してもなんとかなります。 今回AWSコンプリートに至ったのは、昨年末に連続受験をし始めたのがきっかけです。 もともとは昨年夏に1個取得したあと、年内にあと2個くらいは取得しておきたいと思っていた ↓ しかしそのままずるずると12月になってしまい、12月中に2個受験することに ↓ 思い返せば7月にGoogleを3連続受験している → AWSも3連続受験をしてみよう ↓ スペシャリティを1つ残すだけになる → 残り1つも取得してしまおう（4連続） ↓ プロフェッショナルとクラウドプラクティショナを残すのみになる → なんとなくクラウドプラクティショナーを残して年超すのが気持ち悪いので、続けて取得（5連続） ↓ プロフェッショナルも直近の連続受験の記憶が残っているうちに受験したほうが楽だと思い至る → 年明けに2つのプロフェッショナル資格を取得（7連続） ↓ 結果、コンプリート達成 勉強方法 私の実際の具体的な勉強方法は、最初に挙げた合格体験記の各記事に書いています。 AWSの試験を受け始めたころは、一般的な本を読んだり、実際に関連するサービスを触ってみたりもしていました。Udemyにある模擬試験を買ったこともあります。後半（最近1カ月）は、YouTubeやSlideshareなどで上がっているBlack Beltの資料と、PDFで公開されているサンプル問題と、BenchPrepというので受けられる模擬試験だけでほぼカバーしていました。 以下、箇条書きで勉強方法をまとめておきます。 試験対策の本 Solutions Architect AssociateとProfessionalは、対象サービスが多岐にわたるので、本で全体を理解するのが役に立ちました セキュリティのスペシャリティも本があります 出題範囲が特化している試験は、ある程度AWSに慣れてこれば、本を買わなくてもBlack Beltの資料で足りそうです 一般的な本 ビッグデータとは、機械学習とは、セキュリティとはみたいな 受けようとする試験の領域が苦手だったり自信がない場合には、最初に本を読んだこともありました Black Belt Online Seminarの資料 リンク: サービス別資料 | AWS クラウドサービス活用資料集 AWSのドキュメントと違って、必要な情報がコンパクトにまとまっています AWSにある程度慣れてきている人にとっては、勉強ソースとして一番使いやすいです Solutions Architect AssociateとProfessionalは、対象サービスが多岐にわたるので、Black Beltを通読するのは辛いかも PDFのサンプル問題 試験の対象領域を理解するためにサンプル問題を最初にやっておくとよいです 試験対策の本がある場合は、本を読むことで領域がわかるので、サンプル問題は最後に模試代わりに使ったこともあります BenchPrep 無料で手に入る模擬試験なので、必ず解いてみるべきです Black Beltだとかから漏れている知識も手に入ります Udemy等にある模擬試験 BenchPrepがないころはここで模擬試験を購入したことがあります。koiwaclubというのもあるらしいです 難易度が実際の試験とギャップがある場合もあり、あまりこういった模擬試験に惑わされないほうがよいです Qiitaなどにある先輩の方々の合格体験ブログ記事 出題範囲や勉強方法の参考とします 合格した人を見て、自分も合格したいという気持ちをおこします AWSドキュメント 問題集などでわからない点があったときに、ググって出てきたページがAWSドキュメントならばそれを読みます AWSドキュメントを一通り読むのは、私には読解力も読解スピードも足りなくて無理でした いずれの媒体を使うにしても、得た知識は自分で整理してノートにまとめます。自分の言葉で書くことに意味があります。試験を繰り返すと同じ領域の知識を深掘りすることになるので、ノートが更新されていきます。アソシエイトレベルでは、機能の一覧だけ書いてあったところが、プロフェッショナルやスペシャリティでは各機能の詳細を書き足していくようなイメージです。私はScrapboxというサービスで知識を整理しています。 おわりに AWSの全資格を取得したことで、広く浅くの知識が手に入りました。繰り返しますが、全部受験してよかったです。今後は全資格の更新受験を繰り返すことで、知識のベースを維持していきたいと思います。

はじめに あけましておめでとうございます、なじむです。 2021/12/10 に DBS も合格し、目標であった全冠（11冠）を達成できました。半年かけてスペシャリティの資格を毎月一個取得してきましたが、とてもいい勉強になりました。社会人になってこんなに勉強したのは久しぶりな気がします。とはいえ、言葉が分かるようになった、ある程度の使い方・注意点が分かるようになった、程度なので引き続き精進していきたいと思います。 というわけで今年も張り切ってやっていきましょう！AWS Japan さんがまとめている週刊AWSで確認した内容の自分用メモ。 今回は1/3週のアップデートです。 1/3(月) AWS Glue ジョブでのオートスケーリングのご紹介 (プレビュー) Glue は ETL (Extract：抽出、Transform：変換、Load：格納) を実行するマネージドサービスです。 ※例えば S3 からデータを抽出し、抽出したデータに何かしらの処理を加え変換し、変換後のデータを再度 S3 に格納したりします。 (出典) AWS Glue これまで、Glue ジョブを実行する際の実行リソースは最初に決めた数のワーカーを使用していました。そのため、リソースを過剰にプロビジョニングし膨大なコストがかかってしまったり、コストダウンのためにリソースの最適化が必要になっていました。本アップデートにより、Glue ジョブのオートスケーリング機能が追加されました。これにより、最適な量のリソースで Glue ジョブを実行できるようになり、無駄なコストを抑えることが可能になります。 実際の画面は以下です。 ジョブの作成時にはオートスケーリングの設定はできません。ジョブの作成後、Glue Studio から対象ジョブを選択し、[Job details] タブから設定が可能です。 設定前：Requested number of workers を設定できる 設定後：Maximum number of workers を設定できるようになる オートスケーリングの利用には以下のような注意事項があります。詳細は Using Auto Scaling for AWS Glue を参照ください。 Type ：Spark または Spark Streaming を指定（Python shell は対象外） Glue Version：3.0 以上を指定 worker types：G.1X または G.2X を指定（Standard DPUs はサポート外） なお、本機能はプレビュー機能です。現時点では米国東部(オハイオ)のみで利用可能なためご注意ください。 日本リージョン対応状況 東京：未対応 大阪：未対応 1/4(火) Amazon SageMaker JumpStart のタブデータに LightGBM と CatBoost モデルが追加 時間切れで確認できず… 日本リージョン対応状況 東京：未確認… 大阪：未確認… Amazon ECS で ECS クラスターとタスク定義作成のための簡素化されたコンソールエクスペリエンスを開始 ECS は Docker コンテナを実行および管理するマネージドサービスです。 (出典) Amazon EFS を Amazon ECS と AWS Fargate で使用するための開発者ガイド – パート 1 本アップデートでは、ECS のマネジメントコンソールが新しくなりました。 新旧コンソールの切り替えは画面左上のトグルボタンで行います。 新コンソールになり、以下の改善が加わっています。 ※以前の画面と並べて比較しようと思ったんですが、結構変わっていて並べての比較が難しいなと思ったため、新コンソールのみ載せます。 ECS クラスターの作成時 Auto Scaling グループの作成を簡易化（EC2 インスタンスを起動して新しい Amazon ECS クラスターに自動的に登録） タスク定義作成時 複雑な設定の削除（柔軟性のあるデフォルトの提供、タスク実行に必要なロールの自動作成） ※画面から無くなっている項目のため割愛 EC2 および Fargate の両方において、異なる OS/アーキテクチャ (Graviton、Windows、Linux) で実行するタスクを設定可能に メトリクスとトレースの収集を有効にするオプションを追加（X-Ray、CloudWatch、Amazon Managed Service for Prometheus へのエクスポートが可能） 一方で、コンソールが新しくなったことにより、一部作成時に設定できなくなった項目もあるようです。それらに関しては、旧コンソールで設定する必要があります（具体的に新コンソールで何が設定できないのかは未確認） 日本リージョン対応状況 東京：対応 大阪：未対応 ※画面右上のトグルが無かったので未対応と思われます。 Amazon EMR on EKS がカスタム Docker コンテナイメージのテストを簡素化するカスタムイメージ検証ツールをリリース EMR on EKS は EKS 上で EMR を動かせるサービスです。EMR on EKS を使用すると、同じ EKS クラスターで Spark アプリケーションを他のタイプのアプリケーションとともに実行し、リソース使用率を向上させ、インフラストラクチャ管理を簡素化することができます (出典) 新発表 — Amazon EMR on Amazon Elastic Kubernetes Service (EKS) EMR on EKS では、pod にカスタムイメージを使用することができます。本アップデートでは、カスタムイメージを検証するためのツールがオープンソースとして公開されました。検証ツールを使用することで、以下のチェックを行うことが可能です。 Basic Test ：カスタムイメージに以下パラメータが含まれていることを検証 UserName WorkingDir EntryPoint Environment Test ：必要な環境変数が期待されるパスに設定されていることを検証 SPARK_HOME=/usr/lib/spark JAVA_HOME=/etc/alternatives/jre File Structure Test ：必要なファイルが予想されるパスに存在することを検証 Local Job Run Test ：カスタムイメージが有効であり、基本的なジョブ実行に合格できることを検証 検証ツールは github からダウンロードできます。 (参考) awslabs/amazon-emr-on-eks-custom-image-cli 日本リージョン対応状況 東京：対応 大阪：未対応 ※EMR on EKS に未対応 Amazon Managed Blockchain (AMB) が Hyperledger Fabric v2.2 のサポートを発表 Managed Blockchain はブロックチェーンネットワークを構築できるマネージドサービスです。 (出典) Amazon Managed Blockchain を使用したサーバーレスブロックチェーンアプリケーションの構築 Managed Blockchain では、ネットワークの構築にオープンソースのブロックチェーン・プラットフォームである Hyperledger Fabric 利用しています。本アップデートにより、Managed Blockchain で LTS 版である Hyperledger Fabric v2.2 がサポートされました。v2.2 では以下の特徴があります（なぞってみたけど全く分からない…） v 2.x リリースの初の LTS リリース チェーンコード (スマートコントラクト) の分散型ガバナンスを導入 複数の組織でチェーンコードのパラメータ (チェーンコード承認ポリシーなど) を使用する前に各組織が同意することが可能に 参加する可能性のあるチャンネルメンバーのすべての組み合わせのプライベートデータコレクションを作成する必要なく、プライベートデータを共有する高度なパターンを使用することが可能に その他の Fabric v2.2 でのアップデート内容は以下に記載があります。 (参考) New release: Hyperledger Fabric 2.2 LTS 実際の画面は以下です。 Hyperledger Fabric v2.2 が利用可能になっています。 やってみた系の記事はクラメソさんのブログが参考になりました。 (参考) Amazon Managed BlockchainでHyperledger Fabric v2.2が利用出来るようになったのでネットワーク作成してチェーンコードを実行してみた 日本リージョン対応状況 東京：対応 大阪：未対応 ※Managed Blockchain 自体に未対応 Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス) が OpenSearch バージョン 1.1 のサポートを開始 OpenSearch Service は OSS の全文検索エンジンのマネージドサービスです（ElasticSearch、Kibana の AWS フォーク版です） 本アップデートでは、OpenSearch Service 1.1 が利用可能になり、以下機能が追加されました。 クラスター間レプリケーション (CCR) ：クラスター間でのデータレプリカ。Elasticsearch 7.10 でサポートしていた機能が追加。 履歴データの異常検出 ：過去のデータを基にした異常値検出。これ便利そう。 バケットレベルのアラート ：これよく分かりませんでした… 実際の画面は以下です。バージョン 1.1 が選択できるようになっています。 日本リージョン対応状況 東京：対応 大阪：対応 AWS Glue Interactive SessionsとJob Notebooksの紹介（プレビュー） Glue Interactive Sessions と Job Notebooks がプレビュー利用可能になりました。 Glue ジョブの開発では Jupyter Notebook 使うと効率的に進められます。従来は SageMaker ノートブック + 開発エンドポイントで構築していましたが、その構成はコストが非常にかかります。本アップデートによりサーバレスで Jupyter Notebook が使えるようになったためコストが抑えることが可能になりました（使い方次第かも） 実際の画面は以下です。 Glue Studio から Jupyter Notebook が選択できるようになっています。 3 分くらいすると環境が構築されます。めっちゃ簡単でめっちゃ早い！（実際の開発はしていないため使い勝手は不明…） 日本リージョン対応状況 東京：対応 大阪：未対応 1/5(水) Amazon Redshift 向け AWS Data Exchange を発表 ※Data Exchange のサブスクライブが間に合わなかったため推測※ Data Exchange は AWS クラウド内のサードパーティのデータを簡単に検索、サブスクリプション、および利用できるサービスです。例えば、コロナ関連のデータ（世界の感染者数の情報等）が利用可能です。 (出典) AWS Data Exchange for Amazon Redshift これまで、Redshift に Data Exchange のデータを取り込むためには、サブスクライブしたデータを S3 から Redshift に取り込む必要がありました。本アップデートにより、データをサブスクライブすると直接 Redshift 上に表示することが可能となり、Redshift に取り込む手間がなくなったものと思います（ここ確証無し）また、Data Exchange 上のデータは自動で更新されるため、「自分が今使っているのは最新のデータか？」という点を気にしなくてもよくなります。 なお、AWS Data Exchange for Amazon Redshift の利用開始には、当該リージョンで Redshift の RA3 インスタンスを利用する必要があるためご注意ください。 ※2021/10/19 に発表されたプレビュー機能が GA になったというアップデートです 実際の画面は以下です。 任意の Data を選択し、サブスクライブする（Redshift向けの製品で絞ります） Redshift 上からデータを閲覧（できるんじゃなかろうかと推測） 申請がサブスクライブされなかったので実動作が分からなかったのですが、こんな感じなんじゃないかなと思います。どこかでちゃんと検証します… 日本リージョン対応状況 東京：対応 大阪：未対応 ※Data Exchange 自体に未対応 マネージド型の監査およびセキュリティレイクである AWS CloudTrail Lake を発表 CloudTrail ログをクエリできるサービスである CloudTrail Lake が新規利用可能になりました。 従来、CloudTrail のログは CloudTrail のコンソールから確認することが可能でしたが、保存期間が90日である、設定しているリージョンのみしか表示されない等、いくつか使いづらい点がありました。それらを解決するために S3 に保存した CloudTrail ログに対して Ahtena を使用してクエリをかける方法が一般的ですが、今回のアップデートでは、それと同様の環境をより簡単に構築できる CloudTrail Lake が利用可能になりました。 クエリまでの大きな流れは以下です。 イベントデータストアを作成する クエリを実行する 凄い簡単ですね！実際に構築してみて、以下が嬉しい点かなと思いました。 本当に簡単に環境が作成できる 最長7年ログが保存できる（料金は当然かかる） 全てのリージョン、全ての組織内のアカウントの CloudTrail ログをまとめてクエリできる CloudTrail Lake クエリの文法は以下を参照ください。 (参考) CloudTrail Lake SQL constraints また、やってみた系は公式ブログが参考になりましたので併せてご覧ください。 (参考) Announcing AWS CloudTrail Lake – a managed audit and security Lake 日本リージョン対応状況 東京：対応 大阪：対応 Amazon RDS Proxy が 8 つの追加 AWS リージョンで利用可能に RDS Proxy はデータベースプロキシのマネージドサービスです。 (出典) Amazon RDS Proxy のご紹介 Lambda や EC2、Fargate と RDS の間に RDS Proxy を使用することにより、以下のようなことが可能となります。 接続プーリングでオーバーヘッド削減 ：RDS Proxy が中継することで、RDS のリソース消費を抑えることができます（特にLambda からの接続時などに有効） フェイルオーバー時の復旧時間短縮 ：DNS に依存しないフェイルオーバーにより復旧時間短縮 RDS への接続に IAM 認証が使用可能に：DB ユーザではなく、IAM ロール等を用いて RDS に接続可能になります（RDS IAM認証と同様の機能） 今回のアップデートにより、大阪リージョンでも RDS Proxy が使用可能になりました。 実際の画面は以下です。 大阪リージョンで RDS Proxy が作成できるようになっています。 日本リージョン対応状況 東京：対応 大阪：対応 1/6(木) CloudFormation Registry に 37 の新しいリソースタイプを導入 CloudFormation は AWS リソースの IaC (Infrastructure as Code) のサービスです。JSON または YAML で AWS のリソースを記載することにより、AWS のリソースをテンプレートとして管理することができます。 本アップデートでは先月追加されたサービスを中心に、新たに 37 のサービスが CloudFormation で記述できるようになりました。 AWS::AmplifyUIBuilder::Component AWS::AmplifyUIBuilder::Theme AWS::AppStream::AppBlock AWS::AppStream::Application AWS::AppStream::ApplicationFleetAssociation AWS::AppSync::DomainName AWS::AppSync::DomainNameApiAssociation AWS::Batch::SchedulingPolicy AWS::Chatbot::SlackChannelConfiguration AWS::CloudFront::ResponseHeadersPolicy AWS::Connect::ContactFlow AWS::Connect::ContactFlowModule AWS::DataSync::LocationHDFS AWS::EC2::IPAM AWS::EC2::IPAMPool AWS::EC2::IPAMScope AWS::Evidently::Experiment AWS::Evidently::Feature, AWS::Evidently::Launch, AWS::Evidently::Project AWS::FSx::FileSystem AWS::FSx::Snapshot AWS::FSx::StorageVirtualMachine AWS::FSx::Volume AWS::Lex:Bot AWS::Lex::BotAlias AWS::Lex::BotVersion AWS::Lex::ResourcePolicy AWS::IoT::Logging AWS::IoT::ResourceSpecificLogging AWS::IoTWireless::FuotaTask AWS::IoTWireless::MulticastGroup AWS::Pinpoint::InAppTemplate AWS::ResilienceHub::App AWS::ResilienceHub::ResiliencyPolicy AWS::RUM::AppMonitor AWS::Timestream::ScheduledQuery 具体的な文法に関しては CloudFormation のリファレンスを参照ください。 (参考) AWS resource and property types reference 日本リージョン対応状況 ※各サービスが東京、大阪に対応していれば CloudFormation で記述可能 東京：対応 大阪：対応 Amazon EKS が Internet Protocol version 6 (IPv6) をサポート EKS は Kubernetes のコントロールプレーンのマネージドサービスです。 (出典) Amazon EKS ネットワーク これまで、EKS では IPv4 しか選択できませんでした。EKS は Pod 毎に IP が割り振られるため、大規模なシステムでは IP が枯渇する場合があります。プラグインを用いることでその問題を回避することも可能ですが、ネットワーク構成が複雑になり、遅延が発生する場合もあります。IPv6 を使用することでそれらの課題を回避することができます。 実際の画面は以下です。 IPv6 が選択できるようになっています。 日本リージョン対応状況 東京：対応 大阪：対応 AWS Lambda が ES モジュールと Node.js 14 の Top-Level Await のサポートを開始 Lambda はサーバレスでコードを実行できるサービスです。Lambda で Node.js 14 を実行している場合、以下2つの機能が利用可能になりました。 ECMAScript (ES) モジュール Top-Level Await 私はこの辺に疎いのですが、以下記事がとても参考になりました。こんなにまとめられるの凄い。 (参考) top-level awaitがどのようにES Modulesに影響するのか完全に理解する 日本リージョン対応状況 東京：対応 大阪：対応 インスタンスタグが Amazon EC2 インスタンスメタデータサービスで利用可能に EC2 は仮想マシンのサービスです。EC2 にはインスタンスメタデータサービスと呼ばれるサービスがあります。EC2 上で curl http://169.254.169.254 と実行することで、ホスト名やセキュリティグループなど、インスタンスに関する様々な情報を取得することができます。 これまで、タグ情報を取得したい場合は DescribeInstance または DescribeTag を実行することで取得していましたが、大量に実行するとスロットリングエラーや API の実行に時間がかかるといった課題がありました。本アップデートにより、インスタンスメタデータからインスタンスのタグ情報を取得できるようになりました。これにより、先の課題が解決されます。 実際の画面は以下です。 先ずはインスタンス作成時に設定を有効にする必要があります（既存のインスタンスでも、設定を有効にすることができます） 有効にした後はインスタンスにログインし、メタデータにアクセスします。curl http://169.254.169.254/latest/meta-data/tags/instance/Name を実行することで Name タグの値を取得することができました。 （見やすいように改行を修正しています） $ curl http://169.254.169.254/ 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 2011-01-01 2011-05-01 2012-01-12 2014-02-25 2014-11-05 2015-10-20 2016-04-19 2016-06-30 2016-09-02 2018-03-28 2018-08-17 2018-09-24 2019-10-01 2020-10-27 2021-01-03 2021-03-23 2021-07-15 latest $ $ curl http://169.254.169.254/latest/ dynamic meta-data $ $ curl http://169.254.169.254/latest/meta-data/ ami-id ami-launch-index ami-manifest-path block-device-mapping/ events/ hibernation/ hostname iam/ identity-credentials/ instance-action instance-id instance-life-cycle instance-type local-hostname local-ipv4 mac managed-ssh-keys/ metrics/ network/ placement/ profile public-hostname public-ipv4 public-keys/ reservation-id security-groups services/ tags/ $ $ curl http://169.254.169.254/latest/meta-data/tags/ instance/ $ $ curl http://169.254.169.254/latest/meta-data/tags/instance/ Name Owner $ $ curl http://169.254.169.254/latest/meta-data/tags/instance/Name nagym-ec2 $ 日本リージョン対応状況 東京：対応 大阪：対応 1/7(金) Amazon AppStream 2.0 が SAML 2.0 フェデレーティッドユーザー ID 向けにアプリケーションエンタイトルメントの提供を開始 Amazon AppStream 2.0 はアプリケーションストリーミングのマネージドサービスです。 (出典) Amazon AppStream 2.0でデスクトップアプリケーションのストリームをスケールする AppStream 2.0 で作成したアプリケーションにアクセスするためには認証（ユーザ情報）と認可（そのユーザがどのアプリケーションにアクセスできるか）の設定が必要になります。本アップデートでは、その設定をアプリケーションエンタイトルメントを用いて設定できるようになりました。例えば、AD に登録しているユーザで "nagym-dev" というグループに所属しているユーザには "VS Code" の実行を許可するという設定を、以下のようにアプリケーションエンタイトルメントで設定できるようになりました。 AD を構築しておらず検証ができなかったため、実機での検証はしていませんが、詳細な解説と実際のやってみた系は今年もクラメソさんのブログが参考になります。ぜひご覧ください。 (参考) [アップデート] AppStream 2.0 で SAML 2.0 Federated User を利用する際にアプリケーションの選択ができる様になりました 日本リージョン対応状況 東京：対応 大阪：未対応 ※AppStream 2.0 に未対応 感想 新年早々、めっちゃアップデートあるなって思いました。そしてしばらくサボっていた分、全然分からなくなっていました… 今年は（忙しくなければ）継続してやっていきたいと思いますので、本年もよろしくお願いします。 間違いがあればご指摘ください。

IAMユーザ一覧エクスポート IAMのマネジメントコンソールにはエクスポート機能がないため、CLIにて出力する必要がある。 AWS CloudShellを起動する 以下コマンドを実行し、スクリプトを作成してあげればよいだけ！！！ $ vi shell.sh $ chmod 755 shell.sh $ ./shell.sh #!/usr/bin/env bash users=($(aws iam list-users | jq '.Users[].UserName'| sed 's/"//g')) createtime=($(aws iam list-users | jq '.Users[].CreateDate'| sed 's/"//g')) for (( i = 0; i < ${#users[@]}; ++i )); do listuserpolicies=($(aws iam list-user-policies --user-name ${users[$i]}| jq '.PolicyNames[]'| sed 's/"//g')) createdate=`echo ${createtime[$i]} | awk '{print substr($0, 0, 10)}'` printf "${users[$i]} $createdate \n" done

Identity base policy の基本 AWS公式ドキュメント『AWS アカウント へのアクセスを許可し、IAM ポリシーを有効にする』に記載されている通りだが。 IAMによるKMSのアクセス制御（identity base policy）を有効にするには、キーポリシーに以下の ような ポリシーを含める必要がある。 { "Sid": "Enable IAM policies", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "kms:*", "Resource": "*" } } このキーポリシーでは、KMSの全アクセス権がIAMポリシーで制御できるようになる。 一部のアクセス権の制御をIAMポリシーに渡す 公式ドキュメントからは読み取りづらいのだが、全アクセス権ではなく一部のアクセス権をIAMに渡すこともできる。 下記のキーポリシーのように Action を限定すれば、そのアクセス権だけがIAMで制御できるようになる。 { "Sid": "Enable IAM policies", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, - "Action": "kms:*", + "Action": "kms:Get*", "Resource": "*" } }

はじめに みなさんAWS OpenSearch Service（Elasticsearch）は使ってますか？ 先日OpenSearchのクラスタ（ドメイン）を複製してコピー環境を作ったのですが、この際に若干ハマってしまい色々調べたので、手順整理の意味も込めて対応方法を書いておきたいと思います。 OpenSearchのクラスタ複製について OpenSearchには自動スナップショット取得機能があります。１時間おきに自動でクラスタのバックアップを取得してくれるので非常に便利なのですが、こちらは同じクラスタ内でしか使えないので、基本的な用途としては「何かあった時にデータを復元する」といった形になるかと思います。 今回やりたかったことは別のクラスタにデータを移す（同じデータを持ったクラスタを複製する）ことですが、これをやるためには手動でスナップショットを取得しなければなりません。 最初は「まあRDSと同じようなもんだろ。スナップショット取って復元するだけだから楽勝」と考えていたのですが、そう甘い話でもなかったので以下詳細について記載しておきたいと思います。 なお今回の作業内容は概ね以下のAWSドキュメントをベースにしていますので、興味のある方はご覧ください。 今回の構成 OpenSearchの手動スナップショットは基本的にS3バケットに保存する必要があります。S3を中心にして、コピー元でスナップショットを作成し、コピー先へリストアするイメージです。ざっくりした構成はこのような形です。 いくらか端折っていますが、大筋の流れはのような感じです。 項番 大筋の流れ ① EC2インスタンス上でPythonスクリプトを実行し、手動スナップショット保存用のリポジトリ（宛先はS3）を登録する。ちなみに必ずしもEC2を使う必要はなく、ローカルPCから直接スクリプトを実行してもOK。ただし、今回の記事はEC2を前提とした手順になっているのでご注意を。 ② コピー元のOpenSearchクラスタ上でスナップショット取得用のクエリ（API）を実行し、S3へ保存する。 ③ コピー先のクラスタ上でリストア用のクエリ（API）を実行し、スナップショットからのリストアを行う。 作業手順 それでは早速やっていきましょう。 S3バケットの作成 まずはスナップショットの保存先（リポジトリ）として使用するS3バケットを作成します。 作り方に関しては色んなところに記事があるので割愛しますが、ここでのバケット名は「bucket-es-repo-snapshot」としました。 権限設定①：スナップショット取得用のロール作成 S3へスナップショットを保存するにあたり、IAMロールやポリシーの設定など各種権限設定が必要になります。 まずは新規のロールを１つ作成します。今回は名前を「role-es-repo-snapshot」としました。 スナップショット取得時にはOpenSearchからS3へアクセスする必要があるのですが、この際に必要な権限をポリシーとして記述し、今回作成するロールに割り当てます。具体的なポリシーの内容は以下になります。 {     "Version": "2012-10-17",     "Statement": [         {             "Action": [                 "s3:ListBucket"             ],             "Effect": "Allow",             "Resource": [                 "arn:aws:s3:::bucket-es-repo-snapshot" ※前段のバケット名を指定             ]         },         {             "Action": [                 "s3:GetObject",                 "s3:PutObject",                 "s3:DeleteObject"             ],             "Effect": "Allow",             "Resource": [                 "arn:aws:s3:::bucket-es-repo-snapshot/*" ※前段のバケット名を指定             ]         }     ] } インラインポリシーとして直接設定するか、または任意の名称で管理ポリシーを作成してロールにアタッチするか、どちらかで対応してください。 なお本ロールを作成する際のユースケースは「Amazon OpenSearch Service 」を選択してください。もしEC2など別のものを選択してしまった場合、ロールを作成した後に「信頼関係」を編集して以下の通り設定すれば大丈夫です。 { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "es.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } 権限設定②：スクリプト実行用のポリシー作成とアタッチ 前述の通り、今回はEC2インスタンス上でPythonスクリプトを実行することで、OpenSearchに対してスナップショット保存用のリポジトリ（S3）を登録する流れになります。 このスクリプトの実行にあたり、専用のポリシーを１つ作成してスクリプト実行ユーザ（今回でいくとEC2に割り当てたロール）にアタッチする必要があります。ポリシーの内容は以下の通りです。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::[アカウント番号]:role/role-es-repo-snapshot" }, { "Effect": "Allow", "Action": "es:ESHttpPut", "Resource": "[コピー元OpenSearchのARN]/*" }, { "Effect": "Allow", "Action": "es:ESHttpPut", "Resource": "[コピー先OpenSearchのARN]/*" } ] } 定義は計３つ記載しています。一番上の定義により、先程作成したロール（role-es-repo-snapshot）をOpenSearchに対して割り当てるための権限（PassRole）を得ることができます。また、下の２つの定義でes:ESHttpPutの実行権限を追加しています。 ポリシー作成後、EC2のロールにアタッチしましょう。または先程と同じく、インラインポリシーで直接設定してもOKです。 スナップショット用のリポジトリ登録（Pythonスクリプト実行） それではいよいよリポジトリ登録用のPythonスクリプトを実行します。スクリプトの中身は以下の通りです。カッコつきの数字部分は環境依存なので適宜変更ください。 import boto3 import requests from requests_aws4auth import AWS4Auth region = 'ap-northeast-1' service = 'es' credentials = boto3.Session().get_credentials() awsauth = AWS4Auth(credentials.access_key, credentials.secret_key, region, service, session_token=credentials.token) # ESドメインのエンドポイント（各自の環境に従い見直すこと）・・・（１） host = 'https://xxxxxx.ap-northeast-1.es.amazonaws.com/' # スナップショットリポジトリの名前（スラッシュから右側には任意の名前を指定）・・・（２） path = '_snapshot/index-repo-s3' url = host + path # リポジトリ取得先のバケット名（各自の環境に従い見直すこと）・・・（３） backetName = 'bucket-es-repo-snapshot' # ロールARN（各自の環境に従い見直すこと）・・・（４） roleArn = 'arn:aws:iam::[アカウント番号]:role/role-es-repo-snapshot' # リポジトリ登録処理 payload = { "type": "s3", "settings": { "bucket": backetName, "region": region, "role_arn": roleArn } } headers = {"Content-Type": "application/json"} res = requests.put(url, auth=awsauth, json=payload, headers=headers) print(res.status_code) print(res.text) これをEC2上の任意のディレクトリに保存して実行します。Pythonの実行に必要なモジュール等は事前にインストールしておいてください。 実行結果として以下がコンソールに出力されればOKです。 200 {"acknowledged":true} コピー元、コピー先それぞれのOpenSearchに対して上記スクリプトを実行してください。 ※具体的には、上記（１）のエンドポイント名を変更して、計２回スクリプトを実行する感じです コピー元クラスタでのスナップショット取得 続いてコピー元のOpenSearchクラスタでスナップショットの取得を行います。 まずはリポジトリがちゃんと登録されているか確認してみましょう。確認用のクエリは以下の通りです。 GET /_cat/repositories?v ※実行結果 id type cs-automated-enc s3 index-repo-s3 s3 OpenSearchは基本的にREST API（https）で操作するのでcurlコマンドなんかでもいけるのですが、今回はOpenSearch Dashboard（Kibana）のDev Toolsを使いました。OpenSearch Dashboardへアクセスし、左上のハンバーガーメニューから「Dev Tools」を選択すればクエリ実行画面が開くので、上記のクエリをそのままコピペすれば実行できます。 ちなみに上の実行結果部分に表示されている「cs-automated-enc」は自動スナップショット用のリポジトリです。結果の２番目に今回のリポジトリ名（index-repo-s3）が表示されているので、無事登録が行われてるのが分かります。 では続いてスナップショットを作成してみましょう。以下のクエリを実行します。 PUT /_snapshot/index-repo-s3/[任意のスナップショット名] ※実行結果 { "accepted" : true } スナップショットの取得にはしばらく時間がかかるので待ちましょう。結果の確認は以下のクエリから行えます。実行結果のstateがSUCCESSになっていれば無事取得完了です。 GET /_snapshot/index-repo-s3/_all ※実行結果 { "snapshots" : [ { "snapshot" : "スナップショット名", "uuid" : "XXXXXXXXXXX", "version_id" : 1111111, "version" : "7.10.2", "indices" : [ スナップショットに含まれるインデックスの一覧 ], "data_streams" : [ ], "include_global_state" : true, "state" : "SUCCESS", ～～以下略～～ コピー先クラスタへのリストア コピー先クラスタでも同様、OpenSearch Dashboard（Kibana）のDev Toolsを開きます。 まずは以下のクエリを実行し、先ほど取得したスナップショットが参照できるか確認しましょう。 GET /_snapshot/index-repo-s3/_all ※実行結果 { "snapshots" : [ { "snapshot" : "スナップショット名", "uuid" : "XXXXXXXXXXX", "version_id" : 1111111, "version" : "7.10.2", ～～以下略～～ 上記の通り、見えていますね。では続けてリストアを実行します。クエリは以下の通りです。 POST /_snapshot/index-repo-s3/[スナップショット名]/_restore ※実行結果 { "error" : { "root_cause" : [ { "type" : "snapshot_restore_exception", "reason" : "[*****] cannot restore index [.kibana_1] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name" } ], "type" : "snapshot_restore_exception", "reason" : "["[*****]] cannot restore index [.kibana_1] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name" }, "status" : 500 } あれ、エラーになってしまいました。。 調べてみたところ、Elasticsearchのバージョン5.1以降では.kibanaインデックスを常時モニタリングしているようで、リストアの際に必ずエラーになってしまうようです。（OpenSearchはElasticsearch7.10からフォークされているので同じ現象が発生します） 対応方法はいくつかあると思いますが、今回はエラーの原因となる.kibana関連のインデックスをリストア対象から除外することにしました。クエリは以下の通りで、「indices: "-.kibana*"」の構文を追加しています。 POST /_snapshot/index-repo-s3/[スナップショット名]/_restore { indices: "-.kibana*" } ※実行結果 { "accepted" : true } 今度はうまく行きました。これでリストア作業は完了です。お疲れ様でした。 さいごに 今回はOpenSearchでクラスタをコピー（複製）する方法をご紹介しました。 RDSなんかだと割と簡単に対応できるのですが、見て頂いた通りOpenSearchではリポジトリの登録や権限周りの設定が必要なので色々大変な印象です。RDSと同じくマウスポチポチだけで対応できるよう、今後の機能追加に期待したいと思います。 この記事が誰かのお役に立てると幸いです。

はじめに みなさんAWS OpenSearch Service（Elasticsearch）は使ってますか？ 先日OpenSearchのクラスタ（ドメイン）を複製してコピー環境を作ったのですが、この際に若干ハマってしまい色々調べたので、手順整理の意味も込めて対応方法を書いておきたいと思います。 OpenSearchのクラスタ複製について OpenSearchには自動スナップショット取得機能があります。１時間おきに自動でクラスタのバックアップを取得してくれるので非常に便利なのですが、こちらは同じクラスタ内でしか使えないので、基本的な用途としては「何かあった時にデータを復元する」といった形になるかと思います。 今回やりたかったことは別のクラスタにデータを移す（同じデータを持ったクラスタを複製する）ことですが、これをやるためには手動でスナップショットを取得しなければなりません。 最初は「まあRDSと同じようなもんだろ。スナップショット取って復元するだけだから楽勝」と考えていたのですが、そう甘い話でもなかったので以下詳細について記載しておきたいと思います。 なお今回の作業内容は概ね以下のAWSドキュメントをベースにしていますので、興味のある方はご覧ください。 今回の構成 OpenSearchの手動スナップショットは基本的にS3バケットに保存する必要があります。S3を中心にして、コピー元でスナップショットを作成し、コピー先へリストアするイメージです。ざっくりした構成はこのような形です。 いくらか端折っていますが、大筋の流れはのような感じです。 項番 大筋の流れ ① EC2インスタンス上でPythonスクリプトを実行し、手動スナップショット保存用のリポジトリ（宛先はS3）を登録する。ちなみに必ずしもEC2を使う必要はなく、ローカルPCから直接スクリプトを実行してもOK。ただし、今回の記事はEC2を前提とした手順になっているのでご注意を。 ② コピー元のOpenSearchクラスタ上でスナップショット取得用のクエリ（API）を実行し、S3へ保存する。 ③ コピー先のクラスタ上でリストア用のクエリ（API）を実行し、スナップショットからのリストアを行う。 作業手順 それでは早速やっていきましょう。 S3バケットの作成 まずはスナップショットの保存先（リポジトリ）として使用するS3バケットを作成します。 作り方に関しては色んなところに記事があるので割愛しますが、ここでのバケット名は「bucket-es-repo-snapshot」としました。 権限設定①：スナップショット取得用のロール作成 S3へスナップショットを保存するにあたり、IAMロールやポリシーの設定など各種権限設定が必要になります。 まずは新規のロールを１つ作成します。今回は名前を「role-es-repo-snapshot」としました。 スナップショット取得時にはOpenSearchからS3へアクセスする必要があるのですが、この際に必要な権限をポリシーとして記述し、今回作成するロールに割り当てます。具体的なポリシーの内容は以下になります。 {     "Version": "2012-10-17",     "Statement": [         {             "Action": [                 "s3:ListBucket"             ],             "Effect": "Allow",             "Resource": [                 "arn:aws:s3:::bucket-es-repo-snapshot" ※前段のバケット名を指定             ]         },         {             "Action": [                 "s3:GetObject",                 "s3:PutObject",                 "s3:DeleteObject"             ],             "Effect": "Allow",             "Resource": [                 "arn:aws:s3:::bucket-es-repo-snapshot/*" ※前段のバケット名を指定             ]         }     ] } インラインポリシーとして直接設定するか、または任意の名称で管理ポリシーを作成してロールにアタッチするか、どちらかで対応してください。 なお本ロールを作成する際のユースケースは「Amazon OpenSearch Service 」を選択してください。もしEC2など別のものを選択してしまった場合、ロールを作成した後に「信頼関係」を編集して以下の通り設定すれば大丈夫です。 { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "es.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } 権限設定②：スクリプト実行用のポリシー作成とアタッチ 前述の通り、今回はEC2インスタンス上でPythonスクリプトを実行することで、OpenSearchに対してスナップショット保存用のリポジトリ（S3）を登録する流れになります。 このスクリプトの実行にあたり、専用のポリシーを１つ作成してスクリプト実行ユーザ（今回でいくとEC2に割り当てたロール）にアタッチする必要があります。ポリシーの内容は以下の通りです。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::[アカウント番号]:role/role-es-repo-snapshot" }, { "Effect": "Allow", "Action": "es:ESHttpPut", "Resource": "[コピー元OpenSearchのARN]/*" }, { "Effect": "Allow", "Action": "es:ESHttpPut", "Resource": "[コピー先OpenSearchのARN]/*" } ] } 定義は計３つ記載しています。一番上の定義により、先程作成したロール（role-es-repo-snapshot）をOpenSearchに対して割り当てるための権限（PassRole）を得ることができます。また、下の２つの定義でes:ESHttpPutの実行権限を追加しています。 ポリシー作成後、EC2のロールにアタッチしましょう。または先程と同じく、インラインポリシーで直接設定してもOKです。 スナップショット用のリポジトリ登録（Pythonスクリプト実行） それではいよいよリポジトリ登録用のPythonスクリプトを実行します。スクリプトの中身は以下の通りです。カッコつきの数字部分は環境依存なので適宜変更ください。 import boto3 import requests from requests_aws4auth import AWS4Auth region = 'ap-northeast-1' service = 'es' credentials = boto3.Session().get_credentials() awsauth = AWS4Auth(credentials.access_key, credentials.secret_key, region, service, session_token=credentials.token) # ESドメインのエンドポイント（各自の環境に従い見直すこと）・・・（１） host = 'https://xxxxxx.ap-northeast-1.es.amazonaws.com/' # スナップショットリポジトリの名前（スラッシュから右側には任意の名前を指定）・・・（２） path = '_snapshot/index-repo-s3' url = host + path # リポジトリ取得先のバケット名（各自の環境に従い見直すこと）・・・（３） backetName = 'bucket-es-repo-snapshot' # ロールARN（各自の環境に従い見直すこと）・・・（４） roleArn = 'arn:aws:iam::[アカウント番号]:role/role-es-repo-snapshot' # リポジトリ登録処理 payload = { "type": "s3", "settings": { "bucket": backetName, "region": region, "role_arn": roleArn } } headers = {"Content-Type": "application/json"} res = requests.put(url, auth=awsauth, json=payload, headers=headers) print(res.status_code) print(res.text) これをEC2上の任意のディレクトリに保存して実行します。Pythonの実行に必要なモジュール等は事前にインストールしておいてください。 実行結果として以下がコンソールに出力されればOKです。 200 {"acknowledged":true} コピー元、コピー先それぞれのOpenSearchに対して上記スクリプトを実行してください。 ※具体的には、上記（１）のエンドポイント名を変更して、計２回スクリプトを実行する感じです コピー元クラスタでのスナップショット取得 続いてコピー元のOpenSearchクラスタでスナップショットの取得を行います。 まずはリポジトリがちゃんと登録されているか確認してみましょう。確認用のクエリは以下の通りです。 GET /_cat/repositories?v ※実行結果 id type cs-automated-enc s3 index-repo-s3 s3 OpenSearchは基本的にREST API（https）で操作するのでcurlコマンドなんかでもいけるのですが、今回はOpenSearch Dashboard（Kibana）のDev Toolsを使いました。OpenSearch Dashboardへアクセスし、左上のハンバーガーメニューから「Dev Tools」を選択すればクエリ実行画面が開くので、上記のクエリをそのままコピペすれば実行できます。 ちなみに上の実行結果部分に表示されている「cs-automated-enc」は自動スナップショット用のリポジトリです。結果の２番目に今回のリポジトリ名（index-repo-s3）が表示されているので、無事登録が行われてるのが分かります。 では続いてスナップショットを作成してみましょう。以下のクエリを実行します。 PUT /_snapshot/index-repo-s3/[任意のスナップショット名] ※実行結果 { "accepted" : true } スナップショットの取得にはしばらく時間がかかるので待ちましょう。結果の確認は以下のクエリから行えます。実行結果のstateがSUCCESSになっていれば無事取得完了です。 GET /_snapshot/index-repo-s3/_all ※実行結果 { "snapshots" : [ { "snapshot" : "スナップショット名", "uuid" : "XXXXXXXXXXX", "version_id" : 1111111, "version" : "7.10.2", "indices" : [ スナップショットに含まれるインデックスの一覧 ], "data_streams" : [ ], "include_global_state" : true, "state" : "SUCCESS", ～～以下略～～ コピー先クラスタへのリストア コピー先クラスタでも同様、OpenSearch Dashboard（Kibana）のDev Toolsを開きます。 まずは以下のクエリを実行し、先ほど取得したスナップショットが参照できるか確認しましょう。 GET /_snapshot/index-repo-s3/_all ※実行結果 { "snapshots" : [ { "snapshot" : "スナップショット名", "uuid" : "XXXXXXXXXXX", "version_id" : 1111111, "version" : "7.10.2", ～～以下略～～ 上記の通り、見えていますね。では続けてリストアを実行します。クエリは以下の通りです。 POST /_snapshot/index-repo-s3/[スナップショット名]/_restore ※実行結果 { "error" : { "root_cause" : [ { "type" : "snapshot_restore_exception", "reason" : "[*****] cannot restore index [.kibana_1] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name" } ], "type" : "snapshot_restore_exception", "reason" : "["[*****]] cannot restore index [.kibana_1] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name" }, "status" : 500 } あれ、エラーになってしまいました。。 調べてみたところ、Elasticsearchのバージョン5.1以降では.kibanaインデックスを常時モニタリングしているようで、リストアの際に必ずエラーになってしまうようです。（OpenSearchはElasticsearch7.10からフォークされているので同じ現象が発生します） 対応方法はいくつかあると思いますが、今回はエラーの原因となる.kibana関連のインデックスをリストア対象から除外することにしました。クエリは以下の通りで、「indices: "-.kibana*"」の構文を追加しています。 POST /_snapshot/index-repo-s3/[スナップショット名]/_restore { indices: "-.kibana*" } ※実行結果 { "accepted" : true } 今度はうまく行きました。これでリストア作業は完了です。お疲れ様でした。 さいごに 今回はOpenSearchでクラスタをコピー（複製）する方法をご紹介しました。 RDSなんかだと割と簡単に対応できるのですが、見て頂いた通りOpenSearchではリポジトリの登録や権限周りの設定が必要なので色々大変な印象です。RDSと同じくマウスポチポチだけで対応できるよう、今後の機能追加に期待したいと思います。 この記事が誰かのお役に立てると幸いです。

概要 初投稿です。 aws-cli公式Dockerイメージを利用することで、Dockerのインストールのみでaws-cliを使用できます。 しかし、簡潔なセットアップ方法の記事が見つけられないので作りましました。 前提条件 Linux OS(shellが使えれば他のOSでもOK) Dockerをインストール済み 1.「.aws」ディレクトリの作成 下記のコマンドを実行し、「.aws」ディレクトリおよび認証ファイルを作成する cd ~ mkdir ~/.aws && touch ~/.aws/credentials && touch ~/.aws/config 続いて、それぞれのファイルを下記のとおりに編集する ~/.aws/credentials [default] aws_access_key_id=AKIAIOSFODNN7EXAMPLE aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY ※記載されているキーはAWS公式のサンプルなので、そのままコピペしても動きません。 ※配布された自分のアクセスキーとシークレットキーを設定しましょう。 ~/.aws/config [default] region=ap-northeast-1 output=json 2.aws-cliの実行 下記のコマンドを実行し、動作確認を行う。 docker run --rm -it amazon/aws-cli --version 下記のような表示がされればOK aws-cli/2.4.11 Python/3.8.8 Linux/4.19.104-microsoft-standard docker/x86_64.amzn.2 prompt/off 続いて、下記のコマンドを実行し、「.aws」ディレクトリが正しくマウント出来ていることを確認する。 docker run --rm -it -v ~/.aws:/root/.aws amazon/aws-cli sts get-caller-identity 下記のように表示されれば、設定完了。 { "UserId": "AIDAXXXXXXXXXEXAMPLE", "Account": "XXX", "Arn": "arn:aws:iam::XXX:user/XXX" }