概要 AWSが提供するサーバーレスオーケストレーションサービス。 分散アプリケーション・マイクロサービスを「ステートマシン」と呼ばれる仕組みでオーケストレートする。 定義したステートマシンはAWS コンソールから「ワークフロー」という形式で可視化できる。 用語 ステート 状態または一つの作業単位を表す。 ステートマシン ステートからなるフロー(ワークフロー）を指す。 ASL (Amazon States Language) と呼ばれるJSON 形式の言語で定義する。 ASL例 { "Comment": "A Hello World example of the Amazon States Language using Pass states", "StartAt": "Hello", "States": { "Hello": { "Type": "Pass", "Result": "Hello", "Next": "World" }, "World": { "Type": "Pass", "Result": "World has been updated!", "End": true } } } Comment:コメント（概要等） StartAt:最初に実行するState States:ステートマシンを構成するStateを定義する。複数のStateの指定が可能。 Task:処理の単位 Choice:条件分岐 Fail/Succeed:失敗または成功として停止 Pass:入力を単純に出力に渡す、または一部の固定データを出力 Wait:処理停止時間 Parallel:並列処理 Map:配列要素ごとに処理を実行 Task例 フィールド 説明 Name タグ Resource※必須 URI/サービスARN Parameters Stateに渡すJSON形式の値 ResultPath Stateの実行結果を受け取るフィールド Retry Stateでランタイムエラーが発生した際の再試行ポリシー Catch Stateでランタイムエラーが発生し、再試行ポリシーが使い果たされたか定義されていない場合に実行される処理 TimeoutSeconds 処理をタイムアウトさせる時間 など ワークフロー ステートマシンを作成する際に以下いずれかのワークフローを選択する。 標準 実行レート：毎秒 2,000 状態遷移レート：毎秒4,000 課金形態：状態遷移ごと Express※大量データ処理向き 実行レート：毎秒100,000 状態遷移レート：ほぼ無制限 課金形態：実行回数と実行期間 サポートAWS サービス 次のようなサービスとの連携をサポート Lambda DynamoDB SNS SQS Batch ECS など 連携パターン リクエストレスポンス リソースに対してHTTP応答を要求。ジョブの完了を待たない。 ジョブの実行 AWS Batchなどとの統合の場合にリクエストが完了するのを待ってから次のStateに遷移 コールバックまで待機 リソースからタスクトークンが返されるまで処理を中断 ステートマシン実行方法 API呼び出し マネジメントコンソール CloudWatch Events API Gateway AWS CLI SDK ステート(ネストして実行) 参考情報 AWS Step Functions とは 20190522 AWS Black Belt Online Seminar AWS Step Functions

LambdaからCognitoユーザーを削除することがあり、少し手間取ったので残しておきます。 前提 Cognitoの削除が可能なポリシーをLambdaのロールにアタッチしていること。 ※今回はAWS管理ポリシーの AmazonCongitoPowerUser をLambdaのロールにアタッチしています。 LambdaのランタイムはNode.js 14.x です。 Lambdaのコード index.js let aws = require("aws-sdk"); exports.handler = async (event) => { // eventから削除するCognitoユーザーのユーザー名リストを受け取る let userNameList = event.userNameList; // Cognitoユーザーの無効化メソッドをコール await disalbeCognito(userNameList); const response = { statusCode: 200, }; return response; }; /** * Cognito情報を無効化し、ログインできないようにする */ async function disalbeCognito(userNameList){ if (userNameList.length > 0) { // Cognitoを使う準備 aws.config.update({ region: 'ap-northeast-1', }); const cognito = new aws.CognitoIdentityServiceProvider({ apiVersion: '2016-04-18' }); // 対象のCognitoユーザープールID const user_pool_id = "hogehoge"; for (let userName of userNameList) { // ユーザー削除 try { await cognito.adminDeleteUser({ UserPoolId: user_pool_id, Username: userName }).promise(); console.log("Success! userName : " + userName); } catch (err) { console.log("Failed! userName : " + userName); if (err.code == 'UserNotFoundException') { // ユーザープールにユーザーが存在していない場合 console.log('UserNotFoundException'); } else { // その他のエラー console.log(err, err.stack); } throw err; } } } }

はじめに 2021年11月23日にAmazon Connect で、問い合わせフローをアーカイブおよび削除するAPIの提供が始まりました。以下AWS公式ページの 抜粋です。 参照URL : https://aws.amazon.com/jp/about-aws/whats-new/2021/11/amazon-connect-apis-archive-delete-contact-flows/ 「Amazon Connect で、問い合わせフローをアーカイブおよび削除する API を提供開始」 Amazon Connect では、問い合わせフローをアーカイブ/解凍する API と削除する API 2 つを新たに提供しています。 と、いう事で、今まで行うことが出来なかった問い合わせフローの削除を、CLI、またはLambdaを使う方法で削除出来るようになったようです。 今回は提供された2つのAPIのうち、「DeleteContactFlow」を使用してAWS CLIを使用しての問い合わせフロー削除を行っていきます。 必要な準備 AWS CLI のインストール IAMユーザーへのアクセスキーとシークレットキーの発行 AWS CLIのインストール 2022年1/7時点ではバージョン２が最新のバージョンになるのでバージョン２をインストールします。 インストールはこちらから行うことが出来ます。 IAMユーザーへのアクセスキーとシークレットキーの付与 CLIでのユーザー認証の際にアクセスキーとシークレットキーの入力が必要となりますので、ご自身のIAMユーザーに設定がされていない場合は発行する必要があります。アクセスキーとシークレットキーの発行は今回の趣旨では無いため、必要な場合はこちらを参照して事前にアクセスキーとシークレットキーを発行します。 問い合わせフローを削除する 今回の手順 ①削除用のフローの用意 ②CLIからフローの削除コマンドを実行する ③フローが削除されたことを確認する ①削除用フローの用意 削除を行うためのフローを用意します。 今回は「test-ari」という名前で問い合わせフローを１つ作成しました。 この問い合わせフローを削除していきます。 コマンド入力時に以下２つの情報を使用するので控えておきます。 インスタンスのARN 問い合わせフローのARN ②CLIからフローの削除コマンドを実行する ~AWSへの認証~ コマンドプロンプトを開きます。 まずは「aws configure」を入力し、awsへの認証と、リージョンの指定、出力形式を指定します。 ※すでに設定済みの場合は行う必要はありません。 ・AWS Access Key ID：「必要な準備」で発行したIAMユーザーのアクセスキー ・AWS Secret Access Key：「必要な準備」で発行したIAMユーザーのシークレットキー ・Default region name：使用するリージョン（今回は東京リージョンap-northeast-1を指定） ・Default output format：出力形式（今回はjsonを指定） ! ~コマンドの入力~ 削除コマンドは以下です。 aws connect delete-contact-flow --instance-id (インスタンスのARN) --contact-flow-id (問い合わせフローのARN) 実行します。 実行されました。 Amazon Connect内で削除が成功しているか確認します。 問い合わせフローからも「test-ari」が無くなっており、コンタクトフローから変更履歴の表示画面でもCLIから削除できたことが確認できました。 まとめ 実際にCLIからコマンド入力で問い合わせフローの削除を行うことが出来ました。 問い合わせフローのステータスは保存のみの場合、公開している場合どちらも削除が可能でした。 問い合わせフローが電話番号に紐づいている場合はエラーとなり削除が出来ませんでした。問い合わせフローは電話番号との紐づけがされていない状態にする必要があるようです。 ちなみに、AWS CloudShellからも実行してみましたが、こちらも同じコマンドの入力で問い合わせフローの削除を行うことが出来ました。 感想 Amazon Connectでは今まで問い合わせフローの削除ができず、不要なフローには不要とわかるようにフロー名を変更したり、作成上限を超えてしまう場合は古い問い合わせフローを書き換えたりして問い合わせフローの管理が煩雑になっていました。 今回このAPIが使えるようになったことで、不要フローは削除ができ、フロー管理が楽になったのではないかと思います。 備考 今回は問い合わせフローの削除を行ってみましたが、それ以外の種類のフローも削除できるかどうかを今後検証して記事に追加したいと思います。

はじめに 先日ANS-C00を受験し、取得することができました。 ネットワークの経験はあまりありませんが取得できたので、同じような方の参考になればと思います。 これまでのAWS認定受験歴 年月 試験 点数(合格点) 合否 2020/08 AWS認定クラウドプラクティショナー(CLF) 809/1000(700) 〇 2020/11 AWS認定ソリューションアーキテクトアソシエイト(SAA) 753/1000(720) 〇 2021/01 AWS認定デベロッパーアソシエイト(DVA) 862/1000(720) 〇 2021/02 AWS認定SysOpsアドミニストレータアソシエイト(SOA)(C01) 731/1000(720) 〇 2021/04 AWS認定ソリューションアーキテクトプロフェッショナル(SAP) 698/1000(750) × 2021/06 AWS認定ソリューションアーキテクトプロフェッショナル(SAP) 832/1000(750) 〇 2021/06 AWS認定DevOpsエンジニアプロフェッショナル(DOP) 821/1000(750) 〇 2021/09 AWS認定セキュリティ専門知識(SCS) 798/1000(750) 〇 2021/11 AWS認定データベース専門知識(DBS) 756/1000(750) 〇 2022/01 AWS認定高度なネットワーキング専門知識(ANS)←★new! 848/1000(750) 〇 試験対策 勉強時間 約30H やったこと 以下を利用しました。 AWS WEB問題集で学習しよう こちらのプロフェッショナルに登録して問題集を繰り返し解きました。 初めて利用させてもらったのですが、7問1区切りの1問1答で効率よく勉強できたような気がします。 こちらの問題集を解きつつ、わからないネットワークの専門用語を調べました。 全体を通して3週は解いたと思います。 Udemy 上記問題集だけでは不安だったので、試験前々日から前日にかけてUdemyも利用しました。 65問の模擬問題があったので最終調整のような形で利用しました。 一部KoiwaClubではカバーできていなかったものもあったのでやってよかったと思います。 BlackBelt 大正義BlackBeltも利用しました。 ANSではオンプレとAWS間の通信も問われるようでしたので、DirectConnectのBlackBeltを中心に観ました。 感想 今回の勉強・試験を通してネットワークの知識が少しはついたような気がします。特にDirect Connect周りの知識が付きました。 試験としては、他の方もおっしゃっているようにちょっと古いなという印象でした。というのも、C-00で開始されてから一度もアップデートされていないよう？なので今なら違うやり方があるのでは？と思う問題もありました。 難易度は、ほかの専門知識と同等レベルだと感じました。SAPよりも難しいという声も見かけるのですが個人的にはSAPの方が難しかったです。

はじめに ARI20新卒2年目の土井と申します。 2021年7月末に AWS Certified Solutions Architect - Professional を取得し(前回の記事はこちら)、かなり時間が経ったので、そろそろ次の資格を...と、思い AWS Certified DevOps Engineer - Professional の受験してきました。 同じ資格を目指す人の役に立てば、ということで記事を書きます。 以下試験結果です。 合格ラインが750点に対して829点とSAPの時よりも余裕を持って合格できました。 教材 勉強に使った教材は以下の公式サイトのトレーニングです。 https://aws.amazon.com/jp/certification/certified-devops-engineer-professional/ URLから飛んでもらうと、↓の画像のように、試験ガイド、サンプル問題、公式練習問題集、デジタルトレーニングを確認することができます。 私が勉強した流れとしては、 2021年11月1週目　：試験ガイドの確認 2021年11月2,3週目：デジタルトレーニング 2021年11月4週目　：有料模擬試験 2021年12月1週目　：サンプル問題 2022年 1月1週目　：公式練習問題集 2022年 1月8日10時：本試験受験 といった感じでした。前回のSAPの時と同様、12月は寝かせる期間でした。 AWS経験としては、SAPに合格した時も書きましたが、2020年の8月からなので1年4か月程です。今回も実業務はDOP合格にかなり影響したと思います。 試験ガイド どの試験においても大事だと思いますが、試験範囲の確認に使います。 試験の形式としては、AWS資格を受験したことがある人はおなじみですが、四者択一と複数解答の選択問題で、75問180分(初めの説明5分、終わりのアンケート5分合わせて190分)に対して1000点満点で750点が合格ラインとなっています。すごい当たり前ですが1時間で25問を解くペースです。1問あたり2分ちょっとなので、180分あるからとゆっくり解答していると時間が足りなくなる可能性があります。受験中は何度も解答数に対する残り時間を確認していました。同じ問題を悩みすぎて、後ろの問題を解答できずに不合格になるのはもったいないです。長考しそうになったらフラグを立てる機能があるので活用して、全部解いた後に戻ってくるのも大事だと思います。 そして、勉強を始める前に試験範囲と配点の確認をしましょう。 以下は試験ガイドの抜出です。 分野 1: SDLC の自動化:22% 1.1 CI/CD パイプラインを自動化するために必要な概念を適用する。 1.2 ソース管理戦略の内容、およびソース管理戦略を実装する方法を決める。 1.3 テストを自動化および統合するために必要な概念を適用する。 1.4 アーティファクトをセキュアに作成および管理するために必要な概念を適用する。 1.5 展開/配信戦略の内容 (例: A/B、ブルー/グリーン、カナリ-、レッド/ブラック)、および、AWS サービスを使用して展開/配信戦略を実装する方法を決める。 分野 2: 構成管理および Infrastructure as Code:19% 2.1 展開ニーズに基づいて展開サービスを決める。 2.2 業務ニーズに基づいて、アプリケーションとインフラストラクチャの展開モデルを決める。 2.3 リソースプロビジョニングの自動化においてセキュリティ概念を適用する。 2.4 展開にライフサイクルフックを実装する方法を決める。 2.5 AWS の構成管理ツールおよび構成管理サービスを使用してシステムを管理するために必要な、概念を適用する。 分野 3: 監視およびロギング:15% 3.1 ログおよびメトリクスの集計処理、格納処理、および分析処理をセットアップする方法を決める。 3.2 環境の監視および環境におけるイベント管理を自動化するために必要な概念を適用する。 3.3 オペレーティングシステム、インフラストラクチャ、およびアプリケーションを監査、ロギング、および監視するために必要な概念を適用する。 3.4 タグ付けなどのメタデータ戦略を実装する方法を決める。 分野 4: ポリシーと標準の自動化:10% 4.1 ロギング、メトリクス、監視、テスト、およびセキュリティに関する標準を遂行するために必要な概念を適用する。 4.2 自動化によってコストを最適化する方法を決める。 4.3 統治戦略を実装するために必要な概念を適用する。 分野 5: インシデントおよびイベントへの対応:18% 5.1 問題をトラブルシューティングし、また、運用復旧方法を決める。 5.2 イベント管理とアラート通知を自動化する方法を決める。 5.3 自動復旧を実装するために必要な概念を適用する。 5.4 イベント駆動型自動アクションをセットアップするために必要な概念を適用する。 分野 6: 高可用性、フォールトトレランス、およびディザスタリカバリ:16% 6.1 マルチ AZ アーキテクチャとマルチリージョンアーキテクチャのどちらが適切かを決める。 6.2 高可用性、拡張性、およびフォールトトレランスを実装する方法を決める。 6.3 業務ニーズ (例: RTO/RPO、コスト) に基づいて適切なサービスを決める。 6.4 ディザスタリカバリ戦略を設計および自動化する方法を決める。 6.5 障害点の観点から展開を評価する。 受験した感覚としては、構築を自動化するCloudFormationとデプロイを自動化するいわゆるCode三兄弟、なにかイベントが起きた時に検知し通知するCloudwatchEvent(EventBridge)とConfig、障害復旧のためのバックアップの設計辺りがよく出題された印象です。 デジタルトレーニング 試験ガイドをサラッと流した後、AWS skillbuilderを実施しました。 公式サイトから飛ぶと英語版になるので日本語版を探すといいです。 検索時に日本語でフィルタをかけると楽に見つかります。 このトレーニングは、コースの概要、試験ガイドの6分野、まとめの8レッスンで構成されており、各レッスン毎に20分前後の講義動画とメインの6分野については4～6問の練習問題と2,3分の解説動画が付いています。解説付きの公式の問題は珍しいので、ある程度勉強している方であれば、練習問題だけ解いてもいいかもしれません。 サンプル問題 こちらも公式サイトからダウンロードできるものです。 レベル感としては本試験で出題された問題と同じ系統の問題も含まれており、腕試しで解答するといいと思います。2番はほぼそのままでたような。。。 こちらの問題も無料で取り組める解説付きの問題ですので活用して損はないと思います。 有料模擬試験 公式の有料模擬試験は11/27に受験しました。前回のSAP合格時の模擬試験無料バウチャーを使用し受験しました。 スコアとしては総合スコアが45%で、トピック別スコアが以下の通りでした。 1.0  SDLC Automation: 25% 2.0  Configuration Management and Infrastructure as Code: 33% 3.0  Monitoring and Logging: 66% 4.0  Policies and Standards Automation: 66% 5.0  Incident and Event Response: 0% 6.0  High Availability, Fault Tolerance, and Disaster Recovery : 100% 勉強しないとなってスコアでしたが、勉強が必要な分野がはっきりして勉強を進める指針になり役に立ちました。また回答形式が本番と同じなので試験慣れという意味でも受験してよかったです。DOPを受験するような人は、SAA等他の資格を既に合格していると思うので形式には慣れていると思いますが、DOPは問題文が長く こちらは後述する無料の練習問題集が公開されたことにより2022年の6月末までは他のAWS資格合格時のバウチャー消化のために受験できますが、それ以降は受験できなくなります。 公式練習問題集 こちらは2021年の年末にAWSからクリスマスプレゼントとしていただいたものです。koiwaclubのサブスク利用料が浮きました。AWSサンタさんありがとうございます。詳しい利用方法はクラスメソッドさんの記事を参照してください。デジタルトレーニングの中のAWS Certification Official Practice Question Sets (Japanese)を実施することでコードが発行され、専用のページでそのコードを入力することで練習問題を解くことができるようになります。 年末、勉強をあまりしなかったサボったので、年明けから試験前日までに実施しました。本試験より少し難しかった印象です。 おわりに AWS Certified DevOps Engineer - Professionalに限らず、AWSの認定資格を受験して、毎回思うのですが、選択式だから消去法的に正解を導いて、合格点を取れたかな、と。ただ、消去法で解いている時点でまだまだ知識不足を感じます。実際に問題慣れすると選択肢のこれとこれは違うなっていうのがなんとなくわかってきます。この合格を機によりAWSの知識を身に付けていけたらと思いました。 次はスペシャリティ系の資格かな....

最近AWSのことについて学習を始めました。現在、AWSの基本的なサービスについて学習をしています。今回は、EBSについて調べたことをまとめたいと思います。 EBS(Elastic Block Store) EBSとはEC2にアタッチされるブロックレベルのストレージサービス。EC2にアタッチされる外付けのHDDのようなもの。 特徴として、以下のことが挙げられる。 OSやアプリケーション、データの置き場など様々な用途で利用される。 EC2とはネットワーク接続されている。 99.999%の可用性を持ち、サイズは1G~16TBでサイズと利用期間で課金される。 ボリュームデータはAZ内で複数のHWにデフォルトで複製されており、冗長化不要。 データは永続的に利用可能。 1つのEBSを複数のインスタンスで共有することはできない（一つのEC2に複数のEBSをアタッチすることは可能）。 同じAZのインスタンスのみ付け替えが可能。 EC2作成時に、デフォルトで汎用SSD型のEBSがアタッチされる。 ストレージサービス ブロックストレージサービス HDDやSSDの領域を一定の大きさのブロックに分けて、データを管理するストレージのことを指す。例えば、１ブロック４０GBで１００GBのデータを管理する場合は、３ブロックを使って管理することになる。 EC2にアタッチして使う。 AWSサービスでは、EBSが該当する。 ファイルストレージサービス 複数のEC２インスタンスから同時にアタッチ可能な共有ストレージサービス。 ファイル形式でデータを保存。 AWSサービスでは、EFSが該当する。 オブジェクトストレージサービス データに目印となるラベル（メタ情報）を付けたうえで、広大な空間に配置するようなイメージ。1つ1つのデータを「オブジェクト」と呼び、画像や動画などの保存に向いている。 ブロック単位ではなくオブジェクト単位で管理するため、特定の欲しいオブジェクト（データ）だけをピンポイントに取り出すことが可能。その際に、REST APIを使用する。 拡張性にとても優れている。 AWSでは、S３が該当する。 EBSのスナップショット ある特定の時点で、ストレージに書き込まれた内容をコピーし、そのコピーは、圧縮されて、S3に保存される。 ストレージ上のデータは保存するが、メモリ上のデータ（アプリケーションのトランザクション情報や、ファイルシステムの更新情報など）は保存しない。この性質をクラッシュ整合性という。 S3に保存される容量に応じて課金される。 前回行われたバックアップからの変更や追加されたデータのみ複製するバックアップ（増分バックアップ方式）。 普通にコピーするよりも、差分のみをコピーするため、容量の消費が少ない。故に、利用効率が良い。 スナップショットからEBSの復元が可能。 スナップショットから他のAZに同一のEBSを構築することもできる。 AMIによるバックアップとスナップショットによるバックアップの違い AMI ある時点でのスナップショット＋その他EC2に関する情報(メタデータ)をバックアップする。 スナップショット ある時点でのストレージデバイスに書き込まれた情報をバックアップする。 EBSのボリュームタイプ 主流なEBSは４つ。系統として二つに分けられる。HDD系とSDD系である。 系統 ボリュームタイプ 用途 サイズ HDD コールドHDD ログデータなどのアクセス頻度が低いデータ。バックアップやアーカイブに用いられる。ルートボリュームには利用不可。 500GB~16TB HDD スループット最適化HDD ビックデータ処理。DWH。大規模なETL処理やログ分析で使われる。ルートボリュームには利用不可。 500GB~16TB SDD 汎用SSD 仮想デスクトップや低レイテンシーを要求するアプリ、中小規模のデータベースで使われる。また、EC2にデフォルトでアタッチされる。 1GB~16TB SDD プロビジョンドIOPS 高いI/O性能に依存するNOSQLアプリ、10000IOPSや160MB/sのワークロード大規模DBで使われる。複数のインスタンスにアタッチ可能。 ４GB~16TB スループットとIOPSの違い IOPS(Input Output per second) ストレージが1秒あたりに処理できるI/O（書き込み・読み込み）アクセスの数を指す。 基本的にHDDは1分あたりの回転数(RPM)の限界があるためIOPSが低い。SSDはIOPSが高い。 スループット １秒あたりのデータ転送量を指す。単位は、bps.mbpsなどがある。 ディスクのスループットが大きければアプリケーションのパフォーマンスが必ず上昇するというわけではない。サイズが小さいファイルを数多く書き込む様な場合、スループットよりもIOPSの数値を重視した方がパフォーマンスが上昇する。ボリュームタイプの選定には、このことを留意した方がよさそうです。

作業イメージ 1シャード分だけ抜き出して考えています。同じことを繰り返せばシャードが何個になっても実質同じです。 当たり前ですが、マルチAZにするために別AZのサブネットを用意する必要があります。 手順 やることは2つだけです。 ap-northeast-1aのNodeを削除する ap-northeast-1cにNodeを作成する マネコンでもCLIでも作業可能ですが、今回は両方紹介します。 ap-northeast-1aのReplica Nodeを削除する マネコン (2022/01/19現在)の場合 ElastiCache for Redisのダッシュボードからシャードを選択 →削除したいノードを選択 →「アクション」から「ノードの削除」を選択 →削除 CLIの場合 ❯ aws elasticache decrease-replica-count --replication-group-id <your-id> --replicas-to-remove <your-id>-0001-003 --apply-immediately 消すのは実際結構怖いので、マネコンで確認しながらやるのが良いかなと思います。 ap-northeast-1cにReplica Nodeを作成する マネコン (2022/01/19現在)の場合 ElastiCache for Redisのダッシュボードからシャードを選択 →「ノードの追加」を選択 →新しいレプリカ数に「現在のレプリカ数+1」を入力、アベイラビリティゾーンの選択で新たにnodeを追加したいAZを選択 →追加 CLIの場合 ❯ aws elasticache increase-replica-count --replication-group-id <your-id> --replica-configuration \ NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=ap-northeast-1a,ap-northeast-1a,ap-northeast-1c \ --apply-immediately これで上図と同じ状態になります。PreferredAvailabilityZonesはPrimary, Replica1, Replica2の並びですね。以下図解。 なお、あまり無さそうなケースですが、マルチAZ→単一AZ化する場合はこの逆を行えば良いです。 MultiAZenabledについて この記事を書く前はMultiAZenabledをtrueにさえすれば上図のように勝手にnodeが分散されると思っていましたが、このパラメータはそういう意味ではなく、 「元々nodeが複数AZに分散しているときに偏りを防ぐかどうかを決める」 ためのパラメータのよう。 なので、元々単一AZの場合はtrueにしても意味が無いですし、そもそもエラーが出るはずです。 （エラー文例：Cannot enable Multi-AZ unless there are nodes across two or more Availability Zones in Node Groups.） 偏らせようとしても防ぐための検証についてこちらの記事が詳しいです。 この設定を変更したい場合、おそらくマネコンではenabledにできないので、CLIでmodifyする必要があります。 aws elasticache modify-replication-group --replication-group-id <your-id> --no-multi-az-enabled

EC2上でのWebサイト運用のためにAWSのどのサービスの利用が最低限必要そうか調査しました。 調べた概要や料金(一部抜粋)を記載します。 本情報のみで完結させるため、各所に「※」で補足情報も載せました。 過不足あればご指摘お願いします。 参考 https://aws.amazon.com/jp/ https://www.underworks.co.jp/dmj/2019/11/28/aws-service/ https://www.underworks.co.jp/dmj/2019/12/11/aws-service-2/ https://e-words.jp/ https://cloudnavi.nhn-techorus.com/archives/3640 ストレージ＆データベース機能 S3(Simple Storage Service) 画像や動画の他、バックアップファイルなどの静的ファイルを保存することができるストレージ。 EC2※にインストールしたCMSと連携して、メディアファイルを格納したり、 バックアップデータを保管する用途としての利用。 ※EC2(Amazon Elastic Compute Cloud)：Linux系各種OSやWindows Serverをパッケージとして提供。 EC2のサーバーそのものにデータを保存することも可能だが、 ある程度のデータ量になるとファイル管理が煩雑になったり対応スピードが遅くなるため、よくS3が利用される。 構築済みの静的HTMLファイルによるWebサイトがあれば、S3にファイルをアップロードして公開することも可能。 料金(一部抜粋) 無料利用枠 ：S3標準ストレージクラス、5GB、20,000GETリクエスト、 　　　　　　 2,000PUT、COPY、POST、あるいは、LISTリクエスト、 　　　　　　 データ送信15GBを毎月、1年間。 S3標準プラン：最初の50TB/月 ・・・ 0.023USD/GB(約3円) Amazon RDS(Amazon Relational Database Service) クラウド上にリレーショナルデータベース※を構築、運用することが可能。 ※リレーショナルデータベース：事前定義された、関連があるデータ項目(列と行を持つテーブルのセット)の集合体。 既存構築済みのデータベースを移行したり、EC2上に構築したCMSのデータベースとして活用することが可能。 EC2のサーバー上にもデータベースを構築すること可能だが、 S3同様にデータの規模やレスポンススピード向上のためにRDSを利用するケースが多い。 料金(一部抜粋) 無料利用枠：750時間使用可能、20GBの汎用DBストレージ。 有料プラン：利用するデータベース、インスタンスタイプ※、 　　　　　　契約期間、前払い有無等によりまちまち。 　　　　　　※インスタンスタイプ：CPU、メモリ、ストレージの組み合わせ等で 　　　　　　　様々なタイプがある。 　　　　　　見た限りだと0.025USD(約3円)～ Amazon EBS(Amazon Elastic Block Store) ブロックストレージ※サービス。 ※データをブロックと呼ばれる単位で保存するストレージの種類の1つ。高速にデータを取得できる。 SSDタイプとHDDタイプの2種類が存在する。 Amazon RDSは、自動的に複数のAmazon EBSボリュームをストライプ※する。 ※パフォーマンス向上のために複数のディスクにわたってデータ(データベース、ログ)を分散させる手段。 料金(一部抜粋) 無料利用枠：12か月間、30GBのストレージ。 有料プラン：利用するプランによりまちまち。見た限りだと0.08USD(約9円)～ ネットワーク機能 CloudFront CDN※サービスを提供。 ※CDN(Contents Delivery Network)：ウェブコンテンツをインターネット経由で配信するために最適化されたネットワークのこと。 Webサイトのデータを複数のポイントにキャッシュしてサーバーの代わりに提供することにより、 コンテンツを効率的にユーザーに配布し、Webサイトのアクセス安定性や読み込みスピードを高めることが可能。 また、ユーザーからのアクセスポイントを分散することにより、 サーバーのネットワーク負荷を下げたり、DDoS攻撃※などに対してセキュリティ対応力を高めることが可能。 ※DDoS攻撃(Denial of Service attack)：ウェブサイトやサーバーに対して過剰なアクセスやデータを送付するサイバー攻撃。 料金 無料利用枠：50GBのデータ送信、200万件のHTTP/HTTPSリクエスト、 　　　　　　200万件のCloudFront Function呼び出しを12か月間。 有料プラン：10TB/月(利用地：日本) ・・・ 0.114 USD(約13円) Amazon Route 53 AWSで提供されるドメインネームシステムウェブサービス(DNS)※。 ※DNS(Domain Name System)：インターネット上でドメイン名※を管理・運用するために開発されたシステム。 　※ドメイン：インターネット上に存在するコンピュータやネットワークを識別し、階層的に管理するために登録された名前。 EC2に構築したWebサイトに対して、ドメイン名登録やDNSルーティングを行うことが可能。 Webサイトにすでに取得しているドメインを設定したり、新たにドメインを取得する際に使用。 料金 前金の支払いは不要。従量課金制。 最初の25ホストゾーン※ / 月 ・・・ 0.50USD(約57円) 最初の10億クエリ※ / 月 ・・・ 0.40USD(約45円) 基本的なヘルスチェック※ / 月 ・・・ 0.50USD(約57円) ※ホストゾーン：ドメインおよびサブドメイン※のトラフィック※の 　　　　　　　　ルーティング方法を保持するコンテナ※。 　※サブドメイン：ドメインを用途に応じて複数に分割するときに使用。 　※トラフィック：一定時間内にネットワーク上で転送されるデータ量。 　※コンテナ：稼働中のOSの一部を分離して他と隔離された 　　　　　　　専用のエリアを用意し、その上でソフトウェアを 　　　　　　　動作させる方式をコンテナ型仮想化という。 　　　　　　　隔離された領域のことをコンテナという。 ※クエリ：情報の検索や抽出を行うために、含まれるキーワードや 　　　　　フレーズ、探索対象や範囲、対象期間などを組み合わせて 　　　　　検索条件を書き記した文字列を指す。 ※ヘルスチェック：ロードバランサ※の機能の一つ。 　　　　　　　　　サーバを状態監視し、異常を検知したサーバを 　　　　　　　　　自動的に切り離す機能のことを意味する場合が多い。 　※ロードバランサ：外部とシステム群の中間に設置され、 　　　　　　　　　　外部からの要求を何らかのルールに基づいて 　　　　　　　　　　各システムに振り分け、並行に処理させる。 ELB(Elastic Load Balancing) アプリケーションへの負荷やCPUの稼働状況をリアルタイムにモニタリングできるロードバランサ。 無料利用枠：750時間 / 月 有料プラン：以下のどのロードバランサを選択するかによる。0.0225USD(約3円)～ 2022年1月現在、ALB、NLB、GLBの3種類がある。 ALB(Application Load Balancer)：WEBアプリケーション用としては最も利用されている。 NLB(Network Load Balancer)：大規模サービス用。高負荷が予想される場合に利用。 GLB(Gateway Load Balancer)：ファイアウォールなどの、サードパーティ※の仮想アプライアンス※をクラウドに展開、拡張、管理。 ※製品やソフトウェアなどを販売・提供するメーカーのこと。 ※仮想化技術を用いて、特定用途のアプリケーションソフトが稼働する環境を即座に構成できるようにしたもの。仮想マシンのイメージファイル※などとして提供される。 　※ストレージ（外部記憶装置）に保管されているデータを、物理的に先頭から末尾まで丸ごと写し取って一つのファイルに記録したもの。 権限＆セキュリティ管理機能 WAF & Shield Webサイトのアプリケーションレベルでのセキュリティ対応を設定するサービス。 WAF機能※によって、Webサイトにアクセスするリクエストを制御したり、 DDos攻撃の影響を小さくしたりすることが可能。 ※WAF(Web Application Firewall)：「Webアプリケーションの脆弱性を悪用した攻撃」からWebサイトを保護するセキュリティ対策。 AWS内で複数のサービスやアカウント、リソースを運用している場合でも、 全てのサービスを共通して管理することが可能。 料金(WAF) 前金の支払いは不要。従量課金制。 Web ACL※ / 月 ・・・ 5.00USD(約569円) ルール / 月 ・・・ 1.00USD(約114円) リクエスト(100万リクエストあたり) ・・・ 0.60USD(約68円) ※ACL(Access Control List)：システムやファイル、ネットワーク上の 　　　　　　　　　　　　　リソースなどへのアクセス可否の設定リスト。 料金(Shield) AWS Shield Standard：無料。 AWS Shield Advanced：有料。AWS Shield Standardよりも保護強化。 Certificate Manager SSL/TLS証明書※の発行と管理を行います。 通信の暗号化がスタンダードとなっている現在のWebサイト運用では、ほとんどのWebサイトが必要とする機能。 SSL/TLS証明書についてはAWS上で発行することも、AWS以外で発行された証明書をインポートすることも可能。 ※SSL(Secure Socket Layer)：データのやり取りを暗号化する技術。 ※TLS(Transport Layer Security)：SSL のセキュリティを強化した技術。 ※SSL/TLS証明書：サイトの身元を明示するためのもの。 料金 Certificate Manager ：無料。 Certificate Manager プライベート認証機関(CA)：有料。30日間の無料トライアルサービスあり。 システム管理機能 CloudWatch WebサイトなどAWS上で実行されるアプリケーションの状況を監視するサービス。 一定時間以上サイトにアクセスできなかったりトラフィックが集中した際に、 アラートを通知するように設定することが可能。 Webサイト運用時に安定してサービスが提供できているかを監視したり、 システムトラブル時を検知して原因分析と対策を行うために使用。 料金 無料利用枠：無料で自動的にメトリクス※をCloudWatchに送信。 有料プラン：前金の支払いは不要。従量課金制。インスタンス数、メトリクス数※によってまちまち。 ※メトリクス：リソースやアプリケーションに関して測定できる変数。 AWS Lambda(ラムダ) EC2などの自前のサーバーを用いずに、サーバー管理に関わる様々な機能を動かすことが可能。 サーバーレスアーキテクチャ※と呼ばれるサービス。 ※サーバーレスアーキテクチャ：常時稼働するサーバー（仮想マシン）を極力使わずにシステムを構築する設計、仕様、思想。 AWSのシステムを使ってEC2などのサーバーを監視して、 システムダウン時に再起動を行うといった機能を自動化することが可能。 予めWebサイトの運用ポリシーをLambdaで設定しておけば、 運用管理にかかる手間やコストを下げることが可能。 料金 無料利用枠：1か月あたり100万件の無料リクエストと、1か月あたり40万GB-sのコンピューティングタイムあり。 有料プラン：割り当てるメモリ量によってまちまち。 AWS Auto Scaling Webサイトアプリケーションの使用状況に基づいて、EC2で起動するインスタンスを自動的に起動したり終了したり、 料金プランを変更することが可能。 料金 追加料金なし。 CloudTrail AWS上のアプリケーションやユーザーによって実行されたアクションのログを管理。 Webサイト運用中のインシデント発生時の原因分析や、運用負荷の管理に利用。 料金 無料利用枠：アカウントの管理イベントの直近90日間の履歴を無料で表示、検索、ダウンロード可能。 有料プラン：前金の支払いは不要。従量課金制。100,000管理イベントあたり2.00USD(約228円)。100,000データイベントあたり0.10USD(約11円)。 AWS Cost Explorer AWSのコストと利用状況を確認、管理することが可能。 従量課金が基本のAWSで、システムの利用状況や設定に基づいて将来のコスト予想を立て、 最適なコストプランをたてることが可能。 料金 コストと使用状況を表示は無料。 ページ分割されたAPIリクエストごとに0.01USD(約1円)の料金が発生。

目次 AWS Cloud service provider の追加 ロールの作成とパーミッションの設定 VPC ネットワークリソースの作成 起動テンプレートの作成 インスタンスの起動 この記事は 前回の記事クラウドオーケストレーターのはじめかたではクラウドオーケストレーターのインストールと Kubernetes のセットアップまで説明しましたが、ここではクラウドオーケストレーターをマルチクラウドのポータルとして Amazon EC2 を管理するためのセットアップ方法を紹介します。 IAM ロールの作成 前提条件として、このドキュメントを参考に IAM ロール を作成してください。AWS 上もしくはオンプレでのクラウドオーケストレーターの運用形態によって、以下のようにクレデンシャルの準備が必要です。 クラウドオーケストレーターAWS （EC2 や EKS、ECS）上で動作させる場合、 IAM ロールをクラウドオーケストレーターのインスタンスにアタッチしてください。 オンプレミス環境で動作させる場合、IAM パーミッションの権限を含んだ AWS Access Key ID と AWS Secret Access Key が必要です。 AWS Cloud service provider の追加 管理者権限（Administrator role）のユーザーでサイトにログインします。 Tour または Cloud service provider のメニューより Add AWS Cloud service provider を選択します。 以下の画面より AWS Cloud を選択します。 Name と Account ID を入力、Regions を選択します。 AWS のクレデンシャルを指定します。方法として ３つのオプションがあります。 オプション 利点 A IAM ロール アクセスキーID と シークレットアクセスキーを設定する必要がない。※IAM ロール は Instance Profile ともいいます。クラウドオーケストレーターでは Instance Profile と表記しています。 B アクセスキー アクセスキーID と シークレットアクセスキーを使用して特定のアカウントの AWS リソースにアクセスできる。 C Assume ロール クラウドモジュールが他の IAM ロールを Assumeし、そのロールで AWS リソースにアクセスできる。 D スイッチロール クラウドモジュールが他の IAM ロールを別のアカウントにスイッチし、切り替え先のロールで AWS リソースにアクセスできる。 A. IAM ロールを使用する方法 - Credentials のセクションより Use Instance Profile にチェックを入れます。 B. アクセスキーを使用する方法 - Use Instance Profile のチェックを外した状態で、Access Key ID と Secret Access Key を入力します。 C. Assume ロールを使用する方法 - Assume Role セクションの Use Assume Role をチェックし、IAM Role 名を入力します。 D. スイッチロールを使用する方法 - 上記 C. に加え、Use Switch Role をチェックし、スイッチ先の Account ID と IAM Role 名を入力します。 フォームを保存し、作成に成功すると以下のメッセージが表示されます。 ロールの作成とパーミッションの設定 Manage メニューから People → Roles に移動し Add Role ボタンをクリックします。 Role の名前を入力しロールを作成します。 作成したロールのドロップダウンから Edit Permission を選択します。 作成したロールに許可したい権限にチェックを入れ、画面最下にある Save ボタンをクリックします。 VPC ネットワークリソースの作成 AWS Cloud service provider の作成後に、Cloud service provider メニューから AWS を選択すると以下の画面が表示されます。 以下の順番で各々の VPC 内のネットワークリソースを作成します。 手順 ステップ 1 SSH キーペアの作成 2 VPC の作成 3 Subnet の作成 4 Internet Gateway の作成 5 Internet Gateway を VPC にアタッチ 6 AMI イメージのインポート 7 Security Groupの設定 SSH キーペアの作成 Key Pairs のタブより Add AWS Cloud key pair をクリックします。 フォームに必要事項を入力し保存するとキーペアが作成されます。 作成に成功するとリストに作成したキーペアが追加されています。 ※キーペアと同様の手順で VPC、Subnet、Internet Gateway の順番でリソースを追加します。Internet Gateway について、以下の手順で VPC に Internet Gateway をアタッチする必要があります。 Internet Gateway を VPC にアタッチ Internet gateway リストの中の Operations Links のドロップダウンから Attach を選択します。 Attach する VPC を選択し、Attach ボタンをクリック。 Attach に成功するとThe Internet Gateway is attached to VPCのメッセージと共に、Operation linksにDetachが表示されます。 AMI イメージのインポート Images タブより Import AWS Cloud image を選択します。 フォームに必要事項を入力し Import をクリックします。 インポートが成功すると表にインポートしたイメージが表示されます。 セキュリティグループの設定 Security groups タブより Add AWS Cloud security group を選択します。 フォームに必要事項を入力し Save ボタンをクリックします。 作成に成功すると表に作成したセキュリティグループをが表示されます。 リストより作成した セキュリティグループをを選択し、Edit タブから Inbound rule と Outbound rule の IP protocol と CIDR IP を設定し保存します。 起動テンプレートの作成 Design → Launch template に移動し、Add launch template を選択します。 フォームに必要事項を入力の上、Workflow の Status を Review に設定し保存します。 インスタンスの起動 リストより作成した起動テンプレートをクリックし、Approve を選択します。 Approve に成功したら、Launch タプを選択します。※ Approve へのステータス変更は管理者権限のあるユーザーが行います。 Automatically terminate instance にチェックを入れ、画面最下にある Launch ボタンをクリックします。 起動に成功すると、The launch template has been launched のメッセージと共に、インスタンスのリストに起動したインスタンスが表示され、ステータスが Pending として表示されます。 以上でクラウドオーケストレーターを使って EC2 インスタンスを起動することができました。 終わりに クラウドオーケストレーターをもっと深く知りたい方のために、関連サイトをリストアップしておきます。 ※この記事は @TamakiFujino が作成し、@dcm_naoi が加筆・修正いたしました。 クラウドオーケストレーターのはじめかた（元記事） クラウドオーケストレーターのホームページ クラウドオーケストレーターの YouTube チャンネル クラウドオーケストレーターのドキュメント（英語） クラウドオーケストレーターの開発サイト クラウドオーケストレーターのソースコード

目次 AWS Cloud service provider の追加 ロールの作成とパーミッションの設定 VPC ネットワークリソースの作成 起動テンプレートの作成 インスタンスの起動 この記事は 元記事クラウドオーケストレーターのはじめかたではクラウドオーケストレーターのインストールと Kubernetes のセットアップまで説明しましたが、ここではクラウドオーケストレーターをマルチクラウドのポータルとして Amazon EC2 を管理するためのセットアップ方法を紹介します。 IAM ロールの作成 前提条件として、このドキュメントを参考に IAM ロール を作成してください。AWS 上もしくはオンプレでのクラウドオーケストレーターの運用形態によって、以下のようにクレデンシャルの準備が必要です。 クラウドオーケストレーターAWS （EC2 や EKS、ECS）上で動作させる場合、 IAM ロールをクラウドオーケストレーターのインスタンスにアタッチしてください。 オンプレミス環境で動作させる場合、IAM パーミッションの権限を持つアクセスキー IDとシークレットアクセスキーが必要です。 AWS Cloud service provider の追加 管理者権限（Administrator role）のユーザーでサイトにログインします。 Tour または Cloud service provider のメニューより Add AWS Cloud service provider を選択します。 以下の画面より AWS Cloud を選択します。 Name と Account ID を入力、Regions を選択します。 AWS のクレデンシャルを指定します。方法として、以下の 4つのオプションがあります。 オプション 利点 IAM ロール アクセスキーID と シークレットアクセスキーを設定する必要がない。※IAM ロール は Instance Profile ともいいます。クラウドオーケストレーターでは Instance Profile と表記しています。 アクセスキー アクセスキーID と シークレットアクセスキーを使用して特定のアカウントの AWS リソースにアクセスできる。 Assume ロール クラウドモジュールが他の IAM ロールを Assumeし、そのロールで AWS リソースにアクセスできる。 スイッチロール クラウドモジュールが他の IAM ロールを別のアカウントにスイッチし、切り替え先のロールで AWS リソースにアクセスできる。 IAM ロールを使用する方法 Credentials のセクションより Use Instance Profile にチェックを入れます。 アクセスキーを使用する方法 Use Instance Profile のチェックを外した状態で、Access Key ID と Secret Access Key を入力します。 Assume ロールを使用する方法 Assume Role セクションの Use Assume Role をチェックし、IAM Role 名を入力します。 スイッチロールを使用する方法 上記 C. Assume ロールを使用する方法に加え、Use Switch Role をチェックし、スイッチ先の Account ID と IAM Role 名を入力します。 最後にフォームを保存し、AWS Cloud service provider の作成に成功すると以下のメッセージが表示されます。 ロールの作成とパーミッションの設定 Manage メニューから People → Roles に移動し Add Role ボタンをクリックします。 Role の名前を入力しロールを作成します。 作成したロールのドロップダウンから Edit Permission を選択します。 作成したロールに許可したい権限にチェックを入れ、画面最下にある Save ボタンをクリックします。 VPC ネットワークリソースの作成 AWS Cloud service provider の作成後に、Cloud service provider メニューから AWS を選択すると以下の画面が表示されます。 以下の順番で各々の VPC 内のネットワークリソースを作成します。 手順 ステップ 1 SSH キーペアの作成 2 VPC の作成 3 Subnet の作成 4 Internet Gateway の作成 5 Internet Gateway を VPC にアタッチ 6 AMI イメージのインポート 7 Security Groupの設定 SSH キーペアの作成 Key Pairs のタブより Add AWS Cloud key pair をクリックします。 フォームに必要事項を入力し保存するとキーペアが作成されます。 作成に成功するとリストに作成したキーペアが追加されています。 ※キーペアと同様の手順で VPC、Subnet、Internet Gateway の順番でリソースを追加します。Internet Gateway について、以下の手順で VPC に Internet Gateway をアタッチする必要があります。 Internet Gateway を VPC にアタッチ Internet gateway リストの中の Operations Links のドロップダウンから Attach を選択します。 Attach する VPC を選択し、Attach ボタンをクリック。 Attach に成功するとThe Internet Gateway is attached to VPCのメッセージと共に、Operation linksにDetachが表示されます。 AMI イメージのインポート Images タブより Import AWS Cloud image を選択します。 フォームに必要事項を入力し Import をクリックします。 インポートが成功すると表にインポートしたイメージが表示されます。 セキュリティグループの設定 Security groups タブより Add AWS Cloud security group を選択します。 フォームに必要事項を入力し Save ボタンをクリックします。 作成に成功すると表に作成したセキュリティグループをが表示されます。 リストより作成した セキュリティグループをを選択し、Edit タブから Inbound rule と Outbound rule の IP protocol と CIDR IP を設定し保存します。 起動テンプレートの作成 Design → Launch template に移動し、Add launch template を選択します。 フォームに必要事項を入力の上、Workflow の Status を Review に設定し保存します。 インスタンスの起動 リストより作成した起動テンプレートをクリックし、Approve を選択します。 Approve に成功したら、Launch タプを選択します。※ Approve へのステータス変更は管理者権限のあるユーザーが行います。 Automatically terminate instance にチェックを入れ、画面最下にある Launch ボタンをクリックします。 起動に成功すると、The launch template has been launched のメッセージと共に、インスタンスのリストに起動したインスタンスが表示され、ステータスが Pending として表示されます。 以上でクラウドオーケストレーターを使って EC2 インスタンスを起動することができました。 終わりに クラウドオーケストレーターをもっと深く知りたい方のために、関連サイトをリストアップしておきます。 クラウドオーケストレーターのはじめかた（元記事） クラウドオーケストレーターのホームページ クラウドオーケストレーターの YouTube チャンネル クラウドオーケストレーターのドキュメント（英語） クラウドオーケストレーターの開発サイト クラウドオーケストレーターのソースコード