こんにちは、技術1課の加藤です。
今回は、Amazon Connect についての話題。

手軽に電話を扱えるサービスな Amazon Connect。コールセンターや企業の代表電話をリプレースするサービスとして注目されています。

(参考情報↓)

• 30分でわかる AWS UPDATE 放送にて Connect について取り上げました！
  • 30分でわかる AWS UPDATE!#003
• 代表電話を Connect にしたブログ
  • わたしたち、こうやって Amazon Connect を本格導入しました

ですがまだまだ生まれたばかりのサービス。Connect には気をつけないといけない点がちょこちょこあります。
今回は Connect のハマりどこを知ろう、ということで、読み上げブロックの文字数制限に引っかかったお話をします。
(※ この記事は2020/04/08 に書かれています。仕様については念のため 公式ドキュメント を確認してください)

経緯

顧客入力をループして繰り返し、受け取った情報をまとめて読み上げる、というような処理をフローに実装していました。

このフローを使ったとき、ある回数以上入力をすると、読み上げのブロックがスキップされてしまうという現象が発生したのです。
ログを見ても特にエラーの発生なども記録されておらず。なぜだろう…と悩んでもよくわからない。

状況を把握していた開発メンバーのひとりが、調査を買って出てくださいました。
彼がサポートに問い合わせたり仕様を調査してくださったりと奮闘してくださった結果。

初めて、読み上げブロックには文字数制限がある、ということを知ることになったのです。

Connect の読み上げブロックの文字数制限

Connect の文字列の読み上げには、裏で Polly が使われています。
呼び出されている API はどうやら SynthesizeSpeech API 。
今回ハマった読み上げブロックの文字数制限は、この仕様によるもののでした。

ドキュメントを見ると以下の通り、API の制約が書かれています。

SynthesizeSpeech API オペレーションの使用には、以下の制限が関連している点に注意してください。
• 入力テキストのサイズは、最大 3000 課金対象文字 (合計 6000 文字) です。SSML タグは、課金対象文字としてカウントされません。
• 入力テキストに適用する最大 5 個のレキシコンを指定できます。
• 出力オーディオストリーム (合成) は 10 分に制限されています。これに達した後は、残りの音声はカットオフされます。

一つ目の項目が、文字数制限の項目になります。
ちょっと日本語がわかりにくいですが、

• SSML を含めず 3,000文字
• SSML を含めて 6,000文字

というのが文字数制限の条件となるようです。
これを超える文字数を Connect の読み上げブロックに渡すと、Polly が音声を合成することができず、その読み上げをスキップしてしまいます。

長文の読み上げを計画されている場合、読み上げるブロックを分けるなどして対応をしてあげる必要があります。

※追記

Connect のフロー上で文字列を読み上げられるブロックはいくつかあるのですが、 プロンプトの再生および顧客入力の取得 ブロックのドキュメントには上記文字制限についての言及がありました。

• 問い合わせブロック: プロンプトの再生
• 問い合わせブロック: お客様の入力の取得

今回制限にかかったのは 顧客入力の保存 ブロックだったのですが、こちらには執筆時点で文字制限の記載がないようです。
内部仕様を正しく把握した上で制限の有無をきちんと確認する必要がありますね。

• 問い合わせブロック: お客様入力を保存する

最近の Connect 関連ブログ

結構 Connect の情報発信も増えてきたので、最近の記事を軽くシェアさせていただきます。興味がある記事があればぜひご覧ください。

• わたしたち、こうやって Amazon Connect を本格導入しました
• 【Amazon Connect社内導入】電話の情報をSlackへ通知したらこうなりました
• Amazon Connect で上限緩和申請
• Amazon Connect の一部料金が秒単位課金になりました！
• 特定の接続元IPアドレスだけAmazon Connectを使いたいあなたへ
• Amazon Connect 導入支援をお願いしたときのコスト感を知りたい
• Amazon Connect 電話に出るエージェント(オペレータ)の疑問を解決
• G SuiteでAmazon Connectを認証するお手続き

AWS Transit Gatewayのアップデート

技術3課の杉村です。2020/04/07、AWS Transit Gatewayのインターリージョンピアリング（Inter-region Peering）機能が東京リージョンに対応しました。
AWS Transit Gateway now Supports Inter-Region Peering in 11 additional regions

これにより、下記ブログの構成が東京リージョンで可能になりました。つまり、リージョン間でTransit Gateway同士を接続することができるようになり、リージョン/複数AWSアカウントに所属するVPC/オンプレミスサイトを跨いだネットワーク構成が可能になりました。

Transit Gatewayで実現するマルチリージョン構成・マルチアカウント構成

今のTransit Gatewayの機能で実現可能な構成は、上記のブログ投稿を参照いただければと思います。

Direct Connect機能のまとめ

Direct Connect関連の機能はアップデートが頻繁にあり、追いつくのが大変/全体を把握していない方も多いと思います。
以下のブログを順に読んでいくと、仕様の全体と変遷を追うことができます。

1. AWS Direct Connectの概念の整理…Connectionとは？VIFとは？

2. DX系サービスの変遷とAWS Transit Gatewayの嬉しいところ

3. AWS Transit GatewayとDirect ConnectのマルチAWSアカウント構成

4. Transit Gatewayで実現するマルチリージョン構成・マルチアカウント構成

その後、下記の公式資料をお読みいただくと、理解が深まると思います。

[AWS Black Belt Online Seminar] AWS Direct Connect

はじめに

こんにちは、孔子の80代目子孫兼技術5課の孔です。

Amazon Connectでクラウド型のコールセンターを立ち上げると、「コロナでコールセンターに相談員が行けないから電話受付機能が麻痺してしまった…」などの問題を簡単に解決できる！との話を聞いて、Amazon Connectを学ぶモチベーションが急上昇しています。そんな中で、DTMF入力値（後ほど説明します）の日別集計をもしかしてCloudWatch Contributor Insightsで簡単に取れるのでは？と社内の方から依頼され、実際やってみました。それでは、そのDTMF入力値をCloudWatch Contributor Insightsで取得する過程と感想をお伝えいたしますので、ぜひ御一読くださいませ！

DTMF入力値？

コールセンターに電話したときに、例えばこのような音声を聞いたことがあるかと思います。「掃除機に関する問い合わせは１を、カメラに関する問い合わせは２をおしてください」このとき、１か２など入力する番号のことをDTMF入力値といいます。はい、以上でした。

CloudWatch Contributor Insights？

CloudWatch Contributor Insightsは、CloudWatch logsで取得されるロググループを指定して、そのグループの中で指定したキーと一致する値が来たらそれを集計して可視化して見せてくれるCloudWatchの機能となります。

こちらはサンプ例となります。VPC flow logsの発信元毎にどのようなactionがされたのかを集計するルールとなります。例えばflow logsのログは

2 123456789010 eni-1235b8ca123456789 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK

このような形で格納されていきますが、キーとしてsrcaddrとactionを指定しておけば、この中のsrcaddrとなる172.31.16.139とactionとなるACCEPTをペアでcountし、その集計を可視化してCloudWatch Contributor Insightsのダッシュボードに表示してくれます。

お問い合わせフローを作成する

まずはAmazon Connectのインスタンスを立ち上げるところからですが、今回構築したお問い合わせフローはAWSで出したハンズオンをそのまま使用したので、そちらを確認してください（このリンクをクリックしてください）

このハンズオンの環境を構築する中で、追加ポイントが一つあります。お問い合わせフローを作成するときに（資料の49p）最初に「音声の設定」を行いますが、今回はログを収集する必要があるので、ログの取得を有効にする必要があります。ですので以下のフローを最初に組み込んでください（ログ記録が有効化になっていることを確認！）

後はハンズオンに従ったフローを作成してください。

CloudWatch Contributor Insightsのルールを作る

まずCloudWatch Contributor Insightsの画面に入り、新しいルールを作成ボタンを押すとこちらの画面になります。

ルール名は任意のもので、ロググループはAmazon Connectがログを記録するログストリームを指定してください。CloudWatch logsのロググループを見てみると/aws/connect/XXXXというロググループがあるかと思います。ログの形式は今回はJSONで、コントリビューションを「ContacId（お問い合わせのID）」と「Result（入力されたDTMF入力値）」を入力してください。

ここでコントリビューションがCloudWatch Contributor Insightsのポイントとなります。コントリビューションは「ログストリームの中に記録されるログの中で、コントリビューションで指定したキーを持っているログを対象にキーのバリューを取得して、可視化していくもの」となります。具体的な例はもう少し後で出てきますので、今は理解できなくても後ほど例を見てみると理解しやすいのではないかと思います。

結果を見る

CloudWatch logsに記録されるAmazon Connectのログはこのような形のものとなります。

このログたちの中で、「Result」というキーを持っているのはDTMF値を入力する場面となるので、キーとして「ContacId（お問い合わせのID）」と「Result（入力されたDTMF入力値）」をCloudWatch Contributor Insightsのコントリビューションとして指定していくと両方のキーを持っているログ、つまりDTMF入力値の情報を持っているログのみが集計対象となります。実際どのようにCloudWatch Contributor Insightsに出力されていくのか見てみますと

このようにContactIdとResultのペアのCountを表示して下れます。これだとあまり集計しても意味がないので、だとえばResultだけ集計しますと

このようになります。使い方として、例えば「カメラのプロモーションを行った直後にカメラのお問い合わせがどれくらい増えたのかな？」を把握したいときに有効に使えるのではないかと思います。

最後に

一見便利そうに見えますが、こちらのものをそのまま使うには少し難点があります。それは「どの質問に対してどのボタンを押したのか」を集計することができないということです。例えば、DTMF入力が複数ある場合、resultはどの質問でどの入力をしたのかまではわからないため、そのままだとあまり使えないのではないかと思います。ですので、Lambdaなどを使って独自のログに整形するなど、少し工夫が必要となります。

CloudWatch Contributor Insightsは一番最初紹介するときに載せた記事にもいろいろな使い方が載っていたりするので、少し工夫してみると多様な場面で活躍してくれるのではないかと思います。それでは、お読み頂きどうもありがとうございました！

食卓のりにハマっているCI部の柿﨑です。
Amazon Detectiveに初めて触る機会がございましたので、簡単にですが内容をまとめます。

目次

1. Amazon Detectiveとは
2. Amazon Detectiveの有効化
3. Amazon Detectiveに触れてみる

1．Amazon Detectiveとは

Detective = 探偵という意味がある通り、AWS上の探偵的な役割を持つサービスです。
基本的には各種サービスによって収集されたデータをAmazon Detectiveが受信し、受信したデータを基に詳細な調査が行えます。
この詳細な調査の部分を簡単にしてくれるサービスがAmazon Detectiveとなります。

また、Amazon Detectiveの有効化時にAmazon GuardDuty、AWS Security Hubと自動的にサービスが統合されるため、上記サービスを有効化しているマスターアカウントにてAmazon Detectiveを有効化することが望ましいです。

前提条件
いくつか前提条件または推奨事項があります。
最初に引っかかりそうなところとしましてはAmazon Detectiveを有効化するAWSアカウントにて、Amazon GuardDutyを有効化してから48時間以上経過している必要がある点です。
他にもいくつか項目がありますので、詳細については管理ガイド(※執筆時点では英語版のみ)をご覧ください。

ユースケース
執筆時点では以下のタイプを検索できます。
GuardDuty finding、AWS account、EC2 instance、IP address、AWS role、AWS user、User agent

例として、AWS accountを選択すれば指定されたAWS account毎にAPIコールの成否をグラフ化したもの、コールされたAPIの種類、IPアドレス、IPアドレスの位置情報、Access Key IDなどを追跡することができます。
また、IP addressを選択することで、IP address毎にも上記の情報を確認できたり、どのAWSリソースが利用されたか(IAM Userなど)も確認することが可能です。

料金
Amazon Detectiveの料金はAWS CloudTrail、VPC Flow Logs、Amazon GuardDutyの結果から取り込まれたデータの量に基づいて発生するようです。
詳しい料金は、料金ページをご覧ください。
実際にAmazon Detectiveを有効化しますと、以下画像のUsageからある程度のコストが分かります。
はじめに30日間の無料トライアルがありますので、まずはAmazon Detectiveを有効化してから利用を検討してみてはいかがでしょうか。

2．Amazon Detectiveの有効化

それではAmazon Detectiveを有効化してみます。

1．AWSマネジメントコンソールからAmazon Detectiveサービスへ移動し、Get started を押下します
2．私の環境では前述したマスターアカウント且つAdmin権限のIAM Userのため、そのまま Enable Amazon Detective を押下します
3．有効化が完了すると以下のような画面へ遷移します
この画面ではAmazon GuardDuty、AWS Security Hubのように外部のAWSアカウントをメンバーとして追加することが可能です。

3．Amazon Detectiveに触れてみる

簡単にですがAmazon Detectiveを操作してみます。
まずはAmazon GuardDuty、AWS Security Hubにどのように統合されているのか見てみます。

Amazon GuardDutyでは以下のように調査アクションが存在し、こちらを選択するとAmazon Detectiveの画面へ遷移して調査することが可能となっています。

AWS Security Hubでは以下のように説明が載っています。
試しに自身が使用しているIAM Userについて調べてみます。
SearchからSelect typeにてAWS Userを指定します。
すると以下画像のマスクされた箇所にサンプルデータのリンクが表示されましたので、クリックしてみます。
現在使用しているAdmin権限を持つIAM Userの情報が表示されました。
まずはNew behaviorタブを押下してみます。
するとIAM Userで使用されたIPアドレスを基にAPI コールが観測された位置情報が表示されました。
場所が新宿区と表示されておりますので間違いありません。
※もちろん現在はテレワーク中です。
上記の画面よりDetailsを選択してみますとIPアドレスやAPIコールの状況が分かります。
ここでOverviewを選択し、画面を戻します。

Overviewの画面を下にスクロールし、APIコールのグラフを押下します。
そうしますと以下のようなAPIの統計情報を閲覧することが可能です。
以下の画像ではIPアドレス毎にAPIを表示させ、対応しているAccess Key IDまで確認することができます。
API methodを選択したパターン

Access Key IDを選択したパターン

このようにポチポチクリックするだけで詳細な情報が分かりやすい形で表示されます。
これならばAWS上の調査にかかる時間も短縮できそうです！！

こんにちは！技術2課、濱岡です。
先日、どうぶつの森でマグロを釣ろうと奮闘していたらリュウグウノツカイが釣れました。(通算2回目)
無事、マグロは釣れました。

さて、今回は、みなさん気になっているんじゃないかと思いましてAWS DeepComposerのこちらのキーボード以外でも使えるのかを試してみました。

※この情報はAWSへ未確認の情報となりますので自己責任でお試しください。

結論:動いた

ちゃんと動きました問題なく。
メロディの入力もちゃんとできます。

今回試したのはこちらのmicroKEY-25です。
Amazonで5,000円くらいで買えます。
25鍵の小さいキーボードですので下の画像の赤枠の範囲しか鍵盤は使えませんが…
(キーボードのOCTAVEのUPとDOWNのボタンで音の高さの上下は可能です。)

それ以外は問題ないですかね。

AWS DeepComposerを試しに使ってみたブログも書いておりますのでよかったら読んでみてくださいね。
AWS DeepComposerで遊んでみた
AWS DeepComposerで遊んでみた その2

以上、濱岡でした！

こんにちは！CSM課岩渕です。
EBSのFast Snapshot Restore（FSR）について全然知らなかったので、試してみました。

Fast Snapshot Restore（FSR）って何それ？　何がいいの？

Fast Snapshot Restore（FSR）は、EBSのスナップショットのリストアを高速でできちゃうよ！　という機能。
FSRを有効化した状態で、スナップショット復元を行うと、完全に初期化（事前ウォーミング）された状態でボリューム作成ができるので、初回アクセス遅延なしで、プロビジョンドパフォーマンスを即座に使用できる。というもの。

上記の説明で、「なるほどね～」と分かる方は以下の「FSRを使う上で知っておかなければならない事」まで読み飛ばして下さい～　因みに私は「何言ってるのかさっぱり分からん！」でした。。。
ということで、まずは「初期化と遅延」について調べてみました。

スナップショットから復元されたボリュームへのアクセスは、ストレージブロックがAmazon S3からプルダウンされてボリュームに書き込こまれると可能になります。この事前処理には一定の時間がかかるため、各ブロックへの初回アクセス時には、I/O 操作のレイテンシーが著しく増加する可能性があります。ボリュームのパフォーマンスは、すべてのブロックがダウンロードされてボリュームに書き込まれると正常値に達します。

Amazon EBS ボリュームの初期化
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-initialize.html

とあります。つまりはこんな感じですね。

スナップショットから復元されたボリュームにアクセスするとき、復元直後で手元に対象ブロックのデータがない場合は、S3に取りに行く。
取りに行くので時間がかかる（＝レイテンシー(遅延)発生）。取ったブロックデータは、手元のボリュームに落としておく。次回、同じデータにアクセスする場合は、手元のデータにアクセスするので、もう時間はかからない。
でも、違うブロックデータにアクセスする場合は、またS3に取りに行く。
取りに行くので時間がかかる（＝レイテンシー発生）。取ったブロックデータは、手元のボリュームに落としておく。を繰り返す。
全ブロックデータをボリュームに落とし込んだら、やっと、レイテンシー無しでの全データアクセスが可能となる。

※S3にアクセスする際のレイテンシー発生によりボリュームのパフォーマンスが５０％も低下する場合があるそうです！
※このスナップショットからの復元後の初回アクセス時の性能低下のことを
　・初回アクセス遅延
　・ファーストタッチペナルティ
　・ファーストタッチレイテンシー
　といったりするようです。

遅延については納得ですね。
と同時に、対策として、スナップショットから復元したら、使用開始する前に、全ブロックにアクセスしておけばいいんじゃない？　ということにもなりますよね。
そのためのコマンドがこれ↓

[ec2-user ~]$ sudo dd if=/dev/xvdf of=/dev/null bs=1M
または
[ec2-user ~]$ sudo fio –filename=/dev/xvdf –rw=read –bs=128k –iodepth=32 –ioengine=libaio –direct=1 –name=volume-initialize

Amazon EBS ボリュームの初期化 – [Linux の Amazon EBS ボリュームの初期化]
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-initialize.html

※ fioの方が高速
※/dev/xvdf の「xvdf」部分は、読み出しデバイスの名前に応じて変更する必要あり

このようにボリューム内の全ブロックに事前アクセスすることでパフォーマンス低下を回避することを
・初期化
・事前ウォーミング
・プレウォーミング
などというそうです。
で、このddやfioコマンドで「初期化」をしてあげればいいだけなら、それでいいような気がしますよね。
でも、これ時間がかかるんです。

3. デバイスのすべてのブロックを読み取るには、dd ユーティリティまたは fio ユーティリティを使用します。Linux システムにデフォルトでインストールされているのは dd コマンドですが、マルチスレッドの読み取りが可能な fio の方が、処理速度が大幅に速くなります。
注記
このステップは、使用している EC2 インスタンスの帯域幅、ボリュームに対してプロビジョニングされている IOPS、そしてボリュームのサイズに応じて、数分から数時間かかることがあります。

Amazon EBS ボリュームの初期化 – [Linux の Amazon EBS ボリュームの初期化]
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-initialize.html

開発環境だったら、待ってもらうのもありかもしれませんが、本番環境だったら１秒でも早く開始できるようにしたいですよね。
そこで、やっとFSRの登場です。

改めまして、
Fast Snapshot Restore（FSR）って何それ？　何がいいの？

Fast Snapshot Restore（FSR）は、EBSのスナップショットのリストアを高速でできちゃうよ！　という機能。
FSRを有効化した状態で、スナップショット復元を行うと、完全に初期化（事前ウォーミング）された状態でボリューム作成ができるので、初回アクセス遅延なしで、プロビジョンドパフォーマンスを即座に使用できる。というもの。

ここまでで、「FSRを使わない手はないじゃない！」って思ったあなた、ちょっと待って下さい！
FSRを使う上で、知っておかなければならない事があります。

FSRを使う上で知っておかなければならない事

コストに注意！

例えば、
・東京リージョンの1スナップショットに対して2つのAZを指定して、
　FSRを12時間有効にした場合
　０.９ × 1スナップショット × ２AZ × １２時間＝２１.６ドル！
・東京リージョンの1スナップショットに対して2つのAZを指定して、
　FSRを1か月有効にし続けた場合
　０.９ × 1スナップショット × ２AZ × ７４４時間＝１３３９.２ドル！

Amazon EBS Fast Snapshot Restore
Fast Snapshot Restore の課金は、それが有効化された各アベイラビリティゾーンでの、データサービス単位時間 (DSU) に基づきます。DSU への請求は、最低で 1 時間分から毎秒ごとに発生します。

Fast Snapshot Restore：有効化された各 AZ で 1 DSU 時間あたり0.90USD
※東京リージョン

Amazon EBS の価格 – [Amazon EBS Fast Snapshot Restore]
https://aws.amazon.com/jp/ebs/pricing/

なので、「必要な時間だけ」FSRを有効にすることが大事です。
そして、リストアが完了したら、FSRを無効に戻せば良いわけです。
※いつリストアが発生するか分からない状況で、FSRを有効化し続けるのは、予算が潤沢にあったとしても、かなり勿体ない気がします。そのコストをかけるくらいなら、初期化（事前ウォーミング）に時間がかかっても問題ない基盤設計に修正した方がいいですね。

こちらも、ぜひ参考にご一読ください。
設楽さんのFSRを数日間有効にしつづけた結果、課金がやばくなった話です。

AWS利用料を使いすぎた話
http://blog.serverworks.co.jp/tech/2020/03/16/awscost-overuse/

FSRを有効化するのに時間がかかるよ！

スナップショットのサイズに応じてFSRの有効化には時間がかかります。
TiBあたり60分かかるので、1GBあたり約3.51秒、100GBなら約351秒です。
「今すぐ、FSRを有効化して、リストアしたいんだ～」って言われても、すぐには出来ません。

スナップショットに対して高速スナップショット復元を有効にすると、以下のいずれかの状態になります。
enabling — 高速スナップショット復元の有効化がリクエストされました。
optimizing — 高速スナップショット復元の有効化中です。スナップショットの最適化には TiB あたり 60 分を要します。
enabled — 高速スナップショット復元は有効になっています。
disabling — 高速スナップショット復元の無効化がリクエストされました。または、高速スナップショット復元の有効化のリクエストが失敗しました。
disabled — 高速スナップショット復元は無効になっています。高速スナップショット復元は必要に応じて再度有効にすることができます。

Amazon EBS 高速スナップショット復元 – [高速スナップショット復元の状態]
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html

FSRを有効にした複数スナップショットを、一度に全てをリストアした場合、
全てが初期化された状態でリストアされるとは限らないよ！

これ、ちょっと分かりにくいんですが、初期化されるボリューム数は「クレジット」の数で決まります。

高速スナップショット復元のパフォーマンスの利点を全面的に享受するボリュームの数は、スナップショットのボリューム作成クレジットの数によって決まります。
・・・
たとえば、サイズが 100 GiB のスナップショットに対して高速スナップショット復元を有効にすると、そのクレジットバケットの最大サイズは 10 クレジットとなり、補充レートは 1 時間あたり 10 クレジットになります。クレジットバケットが満杯である場合、このスナップショットからは同時に 10 個の初期化済みボリュームを作成できます。

Amazon EBS 高速スナップショット復元 – [ボリューム作成クレジット]
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html

共有スナップショットには使えないよ！

他と共有しているスナップショットに対してFSRを有効化することはできません。

では、FSRを試行してみましょう

既にスナップショットが存在している状態から始めます。
スナップショットを作成すると同時にFSRを有効化することも可能ですが、ここではFSR設定していないスナップショットから始めます。
FSRが有効化されていないスナップショットの場合、以下のように「スナップショットの高速復元」の欄に何も表示されていない状態です。
[スナップショット] – [アクション] – [Manage Fast Snapshot Restore] を選択します。
次にAZを選択します。必要な分だけ、 AZ を選択して「Save」を押下して下さい。
「スナップショットの高速復元」のステータスが以下の順で変化します。
１．enabling — 高速スナップショット復元の有効化がリクエストされました。
２．optimizing — 高速スナップショット復元の有効化中です。
３．enabled — 高速スナップショット復元は有効になっています。
以下例では、100GBのスナップショットですので、計算通り約６分ほどで「enabled」になりました。
あとは、普通にボリュームを作成して、アタッチすればOKです。
因みにFSRが有効化されているスナップショットからボリュームを作成する場合、
以下のように「Fast Snapshot Restore」が「enabled」になっています。ボリュームを作成し終わったら、課金を抑えるために、さっさとFSRを無効に戻しておきましょう。
再び [スナップショット] – [アクション] – [Manage Fast Snapshot Restore] を選択して、
先ほどチェックONにしたAZをOFFにすることで無効化します。
無効にすると「スナップショットの高速復元」のステータスが以下の順で変化します。
１．disabling — 高速スナップショット復元の無効化がリクエストされました。
　　　または、高速スナップショット復元の有効化のリクエストが失敗しました。
２．disabled — 高速スナップショット復元は無効になっています。
　　　高速スナップショット復元は必要に応じて再度有効にすることができます。

まとめ

いかがでしたか？
事前に予定されているリストアの場合なら、便利に使えそうですね。
使い終わったらFSRを無効化することを忘れずに！
ではまた！

こんにちは、技術1課の加藤です。
今年の1 〜 3月の間、ANGEL Dojo という AWS が主催する若手エンジニア向けハッカソンイベントに参加し、Ossu! という Webアプリを作成しました。
(詳しくはこちら: 新卒1, 2年目の若手エンジニアがANGEL Dojo に参加。 Invent and Simplify 賞を受賞！)

このアプリでは方位磁石のような要素を表示するために、デバイスの向きを取得する必要がありました。
そんなことWebアプリでできるのか…？ と思っていたんですが、 ちゃんとWeb API が用意されているんですね。すごい。

ということで今回は、デバイスの方向を検出する Web API、DeviceOrientationEvent について解説していきます。

DeviceOrientationEvent とは

デバイスの方向の情報を制御するイベントです。
方向がかわるたびにイベントが発火され、新しく更新された値を教えてくれます。

使いたい時は Eventリスナーを登録して使うことになります。

window.addEventListener("deviceorientation", () => {
  // 処理
});

なお 2020/04/09 時点で、DeviceOrientationEvent は実験的な機能となっています。利用する際は、ブラウザが対応しているのか確認するようにしましょう。
デバイスの方向の検出 – Web API | MDN

DeviceOrientationEvent で取得する値

デバイスは 3次元で扱うものですので、方向の情報は3次元の動きを表現する必要があります。このため、DeviceOrientationEvent では 3つの値を教えてくれます。

• alpha (上端部方向)
• beta (右方向)
• gamma (空方向)

デバイスを地面に置いた状態を想像してください。
この時、デバイスの中心から上端部に向かう方向が alpha、
右に向かう方向が beta、デバイスの画面からまっすぐ空に向かう方向が gamma です。

デバイスを縦向きに回転させるとalpha値が変わります。
横向きに回転させるとbeta値が変わり、
コマのように回転させるとgamma値がかわります。

これらの値を利用することで、デバイスがどういうの方向を向いているのか、検知することができます。

言葉だけだと伝わりにくいので、図も貼っておきますね。
回転について – 方向および動きとして示されるデータ | MDN

DeviceOrientationEvent を利用する際に気をつけること

イベントリスナーを登録するだけなので利用は比較的簡単なのですが、気をつけないといけないことがあります。それが iOS の制限です。

iOS では 12.2 から、Safari の「モーションと画面の向きのアクセス」を許可してあげないと DeviceOrientation を含むデバイスの状態に関するイベントを取得することができなくなりました。

そしてさらに iOS 13 からは、取得時にユーザーから許可を受け取ることが必要になりました。
DeviceOrientationEvent.requestPermission 関数を動かして許可を求めるわけですが、この許可を求めるのにもちょこっと工夫が必要です。

というのも、この requestPermission 関数は、「ページを開いた瞬間」に動かすことができず、「ユーザーがボタンを押すなど明示的に操作を行った場合にのみ」実行することが可能なのです。

このため、以下のような記述をする必要があります。

<!-- 許可を求めるボタン -->
<button onclick="handleOnClick">許可</button>
...
<script>
function handleOnClick() {
  // 許可を求める
  DeviceOrientationEvent.requestPermission().then(function () {
    // イベントリスナーを登録
    window.addEventListener("deviceorientation", function (e) {
      // 処理
      console.log(e);
    }
  }).catch(function (e) { console.log(e) });
}
</script>

ちょっと面倒くさいですね。
そして現状、以下の３つの環境が混在しているため、これらを意識してコーディングをしてやる必要があります。

• iOS 12.1 以前 / Android: 許可の必要なし
• iOS 12.2 以降 〜 13未満: Safari の設定を行う必要あり
• iOS 13 以降: ユーザーアクションにより許可を行う必要あり

ハマりやすいので覚えておきましょう。

おまけ

冒頭でチラリと話した ANGEL Dojo が、第二期を募集しているようです。

「日本を元気にする」APN Next Generation Engineer Leaders(ANGEL) Dojo Season2の申し込みスタート！

AWS の全面バックアップのもと開発の経験を積める非常に有意義な会です。
APN パートナー企業所属の IT 経験 3年目までなら応募可能なので、興味ある方、ぜひぜひ挑戦してみてください！

そもそもJetsonという製品群はエッジでモデルのトレーニングもできてしまうようなデバイスなので簡単なことであればクラウドは必要ないかもしれません。

Jetsonの強みはエッジで機械学習できることなので、クラウドへセンサーデータを送り推論みたいなことは必要はないし、低いレイテンシが求められるときはNGいかもと思います。ただデバイスやセンサーの数が多くなると管理はやっぱりクラウドでしたいですよね。

AWS IoTにはDevice Shadowという機能があります。これは簡単に言うとデバイスの状態保存&取得できる機能です。デバイスの状態というのはライトのon/offなどです。

このDevice ShadowもGreengrassを使うことでエッジへもっていくことができます。

というわけで今回はDevice Shadowの検証なので、Jetson Nanoとほとんど関係ありあません。

ドキュメントのモジュール5: Device Shadowの操作を参考に検証していきます。

1. 構成

今回の構成はこんな感じ。

今回はDevice Shadowの検証なので実際にセンサーや機械学習のモデルなどは用意しませんでしたが、ドアの開閉を実行するデバイスと開閉を制御するアプリケーションの乗ったデバイスがある想定です。

アプリケーションがDevice Shadowで管理されるドアの開閉状態を更新するという想定です。

ドキュメントにもありますがIoT Greengrass Coreはゲートウェイとなるデバイスにデプロイし、それ以外のデバイスはデバイス間の通信でIoT Greengrass Coreを利用するといった構成が想定されているようです。わかりませんが。

この構成では真ん中のデバイスにIoT Greengrass Coreがデプロイされています。各デバイスはこのデバイスを通じて通信します。

構成図通りにやろうとするとデバイスが3つ必要ですが、、、今回は1つのJetson Nano上でそれぞれのプログラムを動かすことにします。。。

2. 準備

2-1. 「デバイス」の作成

まずはAWS IoTのコンソールから「デバイス」を作成します。今回は「door01」「door_controller01」という名前でデバイスを作成します。

対象のGreengrassグループの「デバイス」一覧から作成開始。

「新しいデバイスの作成」をクリック。

デバイス名を入力。

「デフォルトを使用」します。Coreデバイス上でプログラムを実行するのでルートCAはCoreデバイスでしようしているものを流用します。後述しますがローカルシャドウでのやり取りになるので、GreengrassグループのCAを別途取得して利用することとなります。

証明書等のtar.gzをダウンロードして完了。

2つとも作成できたらこんな感じで一覧に表示されます。

2-2. サブスクリプションの作成

次にサブスクリプションを作成します。

Device ShadowはMQTTトピックを使用してデバイスの状態を取得・更新します。

Device Shadowで使用するトピックはAWSによりあらかじめ予約されています。

シャドウのMQTTトピック

必要なサブスクリプションはドキュメントに記載があります。

今回の構成で簡記すると以下になります。

対象のGreengrassグループの「サブスクリプション」一覧から作成開始。

ソースとターゲットを選択。

トピックフィルターにトピック名を入力。

完了。

全部作るとこんな感じ。

デバイスとサブスクリプションの設定をデプロイします。Jetson Nano上でコアソフトウェアが起動していることが前提となります。

2-3. AWS IoT Device SDK for Pythonのインストール

今回はPythonを使用します。

PythonからDevice Shadowを利用するのにSDKが必要なので、Jetson Nanoへpipでインストールします。

pip install AWSIoTPythonSDK

2-4. プログラムの用意

さてデバイス上で動かすプログラムを用意します。今回はシャドウのドアの状態更新するプログラムとシャドウから更新されたドアの状態を受け取るプログラムを用意します。前者がドアの開閉を支持するデバイスで、後者がドアを開閉するデバイスにあたるわけです。

作成したプログラム、 door.py と door_controller.py はGitHubに置いておきました。参考にしてみてください。といっても、ほとんどドキュメントで使ってるサンプルをコピペしただけですが。。。Greengrassでは初心者向けにサンプルが用意されてるので、それを使って手軽に開発できるのがよいです。

以下、注意点です。

• Greengrassコアのトピックと通信するためにはグループCAが必要になります。サンプルと同様にそれぞれのプログラムが最初に走った時にグループCAをAWS IoTから取得する処理を入れています。AWS IoTとの通信はインターネットを経由するため、インターネットと通信できない環境で稼働させるときはあらかじめデバイスにグループCAを置いておく必要があります。もちろんAWS IoT Device SDK for Pythonも。
• 今回、Greengrassコアのエンドポイントは 127.0.0.1 としました。コアが同じデバイスで実行されているためです。別々のデバイスの場合はコアデバイスのIPアドレスを代入するなり取得する処理などいれないといけません。ドメイン名でもいける？

上記のプログラム内のルートCAのパスや証明書のハッシュは各環境に合わせて書き換えてください。

プログラムと証明書をデバイスの同じディレクトリに配置します。

$ ls
xxxxxxxxxx.cert.pem      xxxxxxxxxx.cert.pem      door_controller.py
xxxxxxxxxx.private.key   xxxxxxxxxx.private.key   door.py
xxxxxxxxxx.public.key    xxxxxxxxxx.public.key

3. 実行

さてターミナルを2つ開いて、１つは door.py を実行します。もう一方は door_controller.py を実行します。

まずは door.py を実行します。シャドウの更新がないため何も表示されません。

次に door_controller.py を実行します。シャドウへ送信されたドアの状態が表示されます。

そして door.py を実行中のターミナルを確認すると、状態が更新されていることがわかります。

もう少し、このDevice Shadowについて説明しておくと、、、

今回の場合以下のような流れの繰り返しになっています。 Divice Shadowは以下の desired delta reported でデバイスの状態を保持しているというわけです。

1. door_controller01がdoor01のあるべき状態 desired を更新。
2. 実際のdoor01の状態 reported と desired が異なるため delta が更新。
3. delta の更新をdoor01が受け取り、 reported を更新。

まとめ

いかがでしたでしょうか。デバイスの状態を管理できるDevice Shadowという機能のご紹介でしたが、Greengrassを利用することでこの機能もエッジで利用することができます。つまりインターネットにつながりにくい場所でもこの機能が利用できるということです。

こんにちは、仙台オフィス技術5課の芳賀です。
以前、以下のブログにてRDSのエンジンバージョンについて一覧にまとめていました。
RDSのDBエンジンのバージョン一覧(2019/11/06時点)

約5か月ぶりにどのようになったかをまとめました。
また、前回保留になっていた以下の件についても分かったことがありましたので残したいと思います。

・一部RDSで重複したエンジンバージョンが取得される
・マネコン上で選択できないエンジンバージョンが取得される

調べたタイミング：2020/04/13
リージョン：東京リージョン（ap-northeast-1）

目次

・MySQL
・PostgresSQL
・MariaDB
・Aurora
　・Aurora-MySQL
　・Aurora-PostgreSQL
・Oracle
　・Oracle-EE
　・Oracle-SE
　・Oracle-SE1
　・Oracle-SE2
・SQL Server
　・SQL Server-EX
　・SQL Server-Web
　・SQL Server-SE
　・SQL Server-EE
・その他
　・DocumentDB
　・Neptune

【MySQL】

【PostgresSQL】

【MariaDB】

【Aurora】

【Aurora-MySQL】

【Aurora-PostgreSQL】

Oracle

【Oracle-EE】（Enterprise Edition）

【Oracle-SE】（Standard Edition）

【Oracle-SE1】（Standard Edition One）

【Oracle-SE2】（Standard Edition Two）

SQL Server

SQL Serverのエンジンバージョン毎のサービスパックを知りたい場合はこちらを参照してください。

【AWSで選択できる製品バージョンのSP早見表】

【SQL Server-EX】（Express Edition）

【SQL Server-Web】（Web Edition）

【SQL Server-SE】（Standard Edition）

【SQL Server-EE】（Enterprise Edition）

その他

以下DocumentDB、Neptuneについては、今回のCLIで取得できたのでついでに載せました。

【DocumentDB】

【Neptune】

前回保留になっていた件

一部RDSで重複したエンジンバージョンが取得される件

この件は主にAurora MySQLのエンジンバージョン取得時に重複していました。
Aurora MySQLの場合、構築時にバージョンの他にデータベースロケーションやデータベースの機能を選択することができるのですが、この選択によって内部的にエンジンバージョンが異なるようでした。選択画面は以下のようなイメージになります。

マネコン上で選択できないエンジンバージョンが取得される件

この件は廃止されたエンジンバージョンが取得されていたようです。
廃止されたものを除いて取得する術が見つからず、今回も一部手動で加工して一覧化しています。

まとめ

やはり5か月も経つと廃止・追加されたエンジンバージョンが結構ありますね！次回調査する際はスクリプトを一発、バシッと叩けば一覧化してくれるようにしたいなと思います！

Cloud Automator からWorkSpaceを起動できるアクションが追加されました。

「WorkSpaces: WorkSpaceを起動」アクションについて

AutostopモードのWorkSpacesではクライアントアプリケーションからWorkSpacesを起動することができますが、実際に起動が完了するまで若干のタイムラグがあり、利用者がすぐには作業を開始できないという課題がありました。
特にWorkSpacesを複数台運用している場合、1台では少しのオーバーヘッドでも全体的なビジネスインパクトは大きくなります。

今回追加された「WorkSpaces: WorkSpaceを起動」アクションを利用することで、上記のような課題を解決することができます。

例えば、タイマートリガーで毎日決まった時刻にWorkSpacesを自動的に起動しておくことで、利用者がすぐに作業に取り掛かることができるようになります。

ご利用方法

Cloud Automatorのジョブ作成画面のアクション選択フォームにおいて「WorkSpaces: WorkSpaceを起動」を選択してください。

アクションのパラメータを入力する画面において、パラメータを設定ください。

その他注意事項

• 実行モードが「AutoStop」のWorkSpaceのみがジョブの対象になります
• 1ジョブで対象にできるWorkSpaceの最大数は100台です

より詳しくはこちらのマニュアルをご確認ください。

おわりに

今後のリリース計画については、ロードマップページにて公開しております。
これからもCloud Automatorをよろしくお願いいたします。

Cloud Automator(クラウドオートメーター)とは、ノンプログラミングでAWS運用を自動化し、AWSの利用を最大限に引き出すサービスです。バックアップや災害対策、AWS費用の削減を実現する「ジョブ」と、AWSがガイドライン通りに運用されていることを継続的に確認する「構成レビュー」という2つの機能をご提供しております。

こんにちは、技術1課の小倉です。
2020/4/7にアップデートがあり、AWS Transit Gatewayでリージョン間ピアリングが11リージョンで使えるようになりました(東京リージョン含む)！

AWS Transit Gateway がリージョン間ピアリングのサポートを 11 の追加リージョンで開始

AWS Transit Gatewayリージョン間ピアリングについては以下のブログにまとまっていますので、こちらをご参照ください。
Transit Gatewayで実現するマルチリージョン構成・マルチアカウント構成

AWS Transit Gatewayとは

AWS Transit Gateway は Amazon VPCとオンプレミスネットワークを単一のゲートウェイに接続できるようにするサービスです。AWS Transit Gatewayに接続できるのは、Amazon VPC、AWS VPN、AWS Direct Connect Gatewayです。
AWSドキュメント : AWS Transit Gateway

VPCピアリングの例で、VPCが5つあってすべてのVPCとVPCピアリングをする場合、VPCピアリングを10回設定します(左図)。それに対してTransit Gatewayを導入するとすべてのVPCをTransit Gatewayに接続してルートテーブルを設定するだけでVPC間の通信ができるようになり、構成が簡略化されます。
また、VPCピアリングはリージョン間でもできますので、今回のアップデートでリージョン間の構成も簡略化できるようになりました。

またTransit Gatewayの料金は以下のサイトに記載されていますが、Transit Gatewayに接続しているVPC等の数×時間当たりの使用料金と1GBあたりの通信料がかかります。
リージョン間ピアリングですが、料金サイトの記載を読む限り、別リージョンのTransit Gatewayが接続している状態となるので、時間当たりの使用料金がかかりますが、通信料はかからないとなっています。

AWS Transit Gateway の料金

設定手順

東京リージョン(172.16.0.0/16)とシンガポールリージョン(172.31.0.0/16)をTransit Gatewayのピアリング接続を経由して通信できるようにします。

東京リージョン側

Transit Gatewayを作成します。

• マネジメントコンソールにログインして、VPCのコンソールを開きます。
• 左メニューの[Transit Gateway]をクリックし、[Create Transit Gateway]をクリックします。
• Create Transit Gatewayの画面で、Name tagとDescriptionを入力して、[Create Transit Gateway]をクリックします。

Transit GatewayをVPCにアタッチします。

• VPCのコンソールで、左メニューの[Transit Gatewayアタッチメント]をクリックし、[Create Transit Gateway Attachment]をクリックします。
• Create Transit Gateway Attachmentの画面で、以下を設定し、[Create attachment]をクリックします。
  • Transit Gateway ID : 先ほど作成したTransit Gatewayを選択
  • Attachment type : VPCを選択
  • VPC ID : Transit Gateway経由で通信させたいVPCを選択
  • Subnet IDs :  Transit Gateway経由で通信させたいサブネットを選択

シンガポールリージョン側

東京リージョンと同様の手順でTransit Gatewayを作成し、Transit GatewayをVPCにアタッチします。

Transit Gatewayピアリングを設定します(これは東京リージョンのTransit Gatewayから実施してもできます)。

• VPCのコンソールで、左メニューの[Transit Gatewayアタッチメント]をクリックし、[Create Transit Gateway Attachment]をクリックします。
• Create Transit Gateway Attachmentの画面で、以下を設定し、[Create attachment]をクリックします。
  • Transit Gateway ID : 先ほど作成したTransit Gatewayを選択
  • Attachment type : Peering Connectionを選択
  • Account : My Accountを選択(今回は同じアカウントの別リージョンのため)
  • Region : 東京リージョンを選択(接続先のリージョンを選択します)
  • Transit gateway (accepter) : 東京リージョンで接続するTransit GatewayのIDを入力

東京リージョン側

シンガポールリージョンのTransit Gatewayからピアリングのリクエストがきていますので、承認します。

• VPCのコンソールで、左メニューの[Transit Gatewayアタッチメント]をクリックします。
• Resource typeがPeeringが追加されていますので、[右クリック] – [Accept]をクリックします。

Stateがavailableになったら利用できます。

この状態でTransit Gatewayのピアリングは設定できているのですが、別リージョンあてのルートテーブルがないため、Transit Gatewayルートテーブルの設定が必要です。

• VPCのコンソールで、左メニューの[Transit Gatewayルートテーブル]をクリックし、先ほど作成したTransit Gateway IDのルートテーブルを選択します。
• 画面下のRoutesタブをクリックして、[Create route]をクリックします。
• Create routeの画面で、以下を設定し、[Create route]をクリックします。
  • CIDR : シンガポールリージョンのCIDRを入力(今回は172.31.0.0/16)
  • Choose attachment : Resource IDがTransit Gatewayを選択

VPC内のルートテーブルにもルートを追加します。

• VPCのコンソールで、左メニューの[ルートテーブル]をクリックし、Transit GatewayでアタッチしたVPCのサブネットが利用しているルートテーブルを選択します。
• 画面下のルートタブをクリックし、ルートの編集をクリックします。
• ルートの編集画面で、以下を設定し、[ルートの保存]をクリックします。
  • 送信先 : シンガポールリージョンのCIDRを入力(今回は172.31.0.0/16)
  • ターゲット : Transit Gatewayを選択して、ピアリング接続をしたTransit Gateway IDを選択

シンガポールリージョン側

シンガポールリージョン側も同様にTransit Gatewayルートテーブルの追加とVPC内のルートテーブルの追加を実施します。

これで設定は完了です。
東京リージョンとシンガポールリージョンにそれぞれEC2をつくってpingが通ることを確認しました。以下は東京リージョンのEC2(172.16.1.175)からシンガポールリージョンのEC2(172.31.19.144)へのpingの実行結果です。またtracerouteを実行しましたが、途中の経路はでてきませんでした。

[ec2-user@ip-172-16-1-175 ~]$ ping 172.31.19.144
PING 172.31.19.144 (172.31.19.144) 56(84) bytes of data.
64 bytes from 172.31.19.144: icmp_seq=1 ttl=253 time=81.7 ms
64 bytes from 172.31.19.144: icmp_seq=2 ttl=253 time=81.1 ms
64 bytes from 172.31.19.144: icmp_seq=3 ttl=253 time=81.0 ms
64 bytes from 172.31.19.144: icmp_seq=4 ttl=253 time=81.3 ms
64 bytes from 172.31.19.144: icmp_seq=5 ttl=253 time=81.0 ms
^C
--- 172.31.19.144 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 81.053/81.271/81.779/0.450 ms

[ec2-user@ip-172-16-1-175 ~]$ traceroute 172.31.19.144
traceroute to 172.31.19.144 (172.31.19.144), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  172.31.19.144 (172.31.19.144)  70.456 ms *  70.308 ms

まとめ

AWS Transit Gatewayでリージョン間ピアリングができるリージョンが増えました。このアップデートによって、多数のVPCピアリングなどをしている場合は接続経路が簡略化して管理が楽になります。管理コストとAWS Transit Gatewayの料金との兼ね合いかと思いますが、リージョン間で複数のVPCピアリングなどをしている方は利用を検討してみてはいかがでしょうか。

また、本ブログの内容は2020/4/15(水) 12:00よりYouTube Liveで配信される「30分でわかる AWS UPDATE！」でも取り上げる予定ですので、ぜひご覧ください！
もしリアルタイムで見逃しても、アーカイブ動画から内容を確認できます。

こんにちは！CSM課の岩渕です。
SELinuxの無効化ミスによりEC2（Red Hat Linux 8）が起動できなくなったという事象に遭遇したので、対応方法を検証してみました。

補足：
ミドルウェアのインストール時やプログラムの実行において、SELinuxの無効化が要求される場合がありますが、無効化するとセキュリティレベルは落ちる可能性があるので、その点は認識しておく必要があります。

事象

Red Hat Linux 8（RHEL8）で SELinuxを無効化するために /etc/selinux/configに
「SELINUX=disabled」を設定すべきところ、誤って
「SELINUXTYPE=disabled」に設定してしまった。
その後、停止→起動しようとしたところ、正常起動できなくなった。

インスタンスの状態は「running」になっていますが、ステータスチェックが1/2になっています。

システムログから何が起きているか確認してみましょう。

最終行付近に「Failed to load SELinux policy.」が確認できました。
これによりSELinuxの設定ミスにより起動できない状態であることが分かりました。

対処概要

今回は、以下の方法で対処してみました。
１．RHEL8を停止
２．RHEL8からボリュームをデタッチ
３．SSH接続可能な適当なインスタンス(AmazonLinux2)に、RHEL8のボリュームをアタッチ
４．AmazonLinux2でRHEL8のボリュームをマウント
５．AmazonLinux2でRHEL8のSELinuxの設定を修正
６．AmazonLinux2からRHEL8のボリュームをデタッチ
７．RHEL8にRHEL8のボリュームをアタッチし直し
８．RHEL8を起動

では、やってみましょう！

RHEL8の停止

RHEL8のEC2インスタンスを停止します。
通常の停止時間よりかなり時間（５分ほど）がかかりました。
※念のため、停止後に、当該インスタンスのボリュームのスナップショットを作成しました。

RHEL8からボリュームをデタッチ

RHEL8からボリュームをデタッチします。
デタッチするとボリュームの状態が「available」に変わります。
※デタッチ前にRHEL8のインスタンス画面から現状のデバイス名をメモしておいて下さい。
　本例では「/dev/sda1」です。最終工程で使用します。

SSH接続可能な適当なインスタンスにRHEL8のボリュームをアタッチ

SSH接続可能な適当なインスタンスとして、既に稼働中のAmazonLinux2を使用します。
上記でデタッチしたRHEL8のボリュームを、稼働中のAmazonLinux2にアタッチします。

「ボリュームのアタッチ」画面で以下を設定してアタッチします。
インスタンス：稼働中のAmazonLinux2のインスタンス
デバイス：デフォルト

アタッチが完了するとボリュームの状態が「in-use」に代わり、
AmazonLinux2のインスタンス画面で「ブロックデバイス」にデバイスが追加されたことが確認できます。

AmazonLinux2からブロックデバイスの一覧を確認しましょう。
ボリュームアタッチ前：

[ec2-user@ip-172-17-47-24 ~]$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
[ec2-user@ip-172-17-47-24 ~]$

ボリュームアタッチ後：

[ec2-user@ip-172-17-47-24 ~]$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0    8G  0 disk 
└─xvda1 202:1    0    8G  0 part /
xvdf    202:80   0  200G  0 disk 
├─xvdf1 202:81   0    1M  0 part 
└─xvdf2 202:82   0  200G  0 part 
[ec2-user@ip-172-17-47-24 ~]$

また、ボリュームにファイルシステム(XFS)があることを確認します。
今回は、/dev/xvdf2がマウント対象となるので、それが確認できればOKです。

[ec2-user@ip-172-17-47-24 ~]$ sudo file -s /dev/xvdf2
/dev/xvdf2: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)
[ec2-user@ip-172-17-47-24 ~]$

AmazonLinux2でRHEL8のボリュームをマウント

マウントポイントディレクトリを作成し、アタッチしたボリュームをマウントします。
dmesgからエラーが発生していないこと、またdfコマンドで正常にマウントできたことを確認します。

[ec2-user@ip-172-17-47-24 ~]$ sudo mkdir /data
[ec2-user@ip-172-17-47-24 ~]$ sudo mount /dev/xvdf2 /data
[ec2-user@ip-172-17-47-24 ~]$ 
[ec2-user@ip-172-17-47-24 ~]$ dmesg |tail
[ 8344.943502] XFS (xvdf2): EXPERIMENTAL reflink feature enabled. Use at your own risk!
[ 8344.949041] XFS (xvdf2): Mounting V5 Filesystem
[ 8344.968604] XFS (xvdf2): Ending clean mount
[ec2-user@ip-172-17-47-24 ~]$ 
[ec2-user@ip-172-17-47-24 ~]$ df -T
Filesystem     Type     1K-blocks    Used Available Use% Mounted on
devtmpfs       devtmpfs    485468       0    485468   0% /dev
tmpfs          tmpfs       503480       0    503480   0% /dev/shm
tmpfs          tmpfs       503480     412    503068   1% /run
tmpfs          tmpfs       503480       0    503480   0% /sys/fs/cgroup
/dev/xvda1     xfs        8376300 1133504   7242796  14% /
tmpfs          tmpfs       100696       0    100696   0% /run/user/1000
/dev/xvdf2     xfs      209702892 2449436 207253456   2% /data
[ec2-user@ip-172-17-47-24 ~]$

AmazonLinux2でマウントしたRHEL8のSELinuxの設定を修正

マウントディレクトリ配下のSELinux設定ファイル（etc/selinux/config）を正しい設定値に修正し、その後、マウント解除します。

[ec2-user@ip-172-17-47-24 ~]$ ll /data/etc/selinux/config
-rw-r--r--. 1 root root 548 Apr 13 07:39 /data/etc/selinux/config
[ec2-user@ip-172-17-47-24 ~]$ 
[ec2-user@ip-172-17-47-24 ~]$ sudo vi /data/etc/selinux/config
[ec2-user@ip-172-17-47-24 ~]$ 
[ec2-user@ip-172-17-47-24 ~]$ cat /data/etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted
[ec2-user@ip-172-17-47-24 ~]$ 
[ec2-user@ip-172-17-47-24 ~]$ sudo umount /data

AmazonLinux2からRHEL8のボリュームをデタッチ

AmazonLinux2からRHEL8のボリュームをデタッチします。
デタッチするとボリュームの状態が「available」に変わります。

RHEL8にRHEL8のボリュームをアタッチし直し

RHEL8のインスタンスにRHEL8のボリュームをアタッチし直します。
その際、「ボリュームのアタッチ」画面で、以下を設定します。
インスタンス：RHEL8のインスタンス
デバイス：「RHEL8からボリュームをデタッチ」でメモしておいた「デバイス名」

RHEL8を起動

ようやく、RHEL8を起動できました。
ステータスチェックで2/2のチェックに合格、またSSHログインが正常にできることを確認して下さい。

まとめ

もっと、簡単にできると思って始めてみましたが、やってみると、以外と面倒でした。
でも、一度経験としておくと、いざという時、役に立ちそうですね。
本ブログが似たような境遇のどなたかの一助になれば、嬉しいです。
ではまた！

はじめに

こんにちは、技術 1 課の山中です。
毎日花粉症の薬を飲んでるのですが、花粉はいつまで続くのでしょうか。
花粉の検査を以前病院で行ってもらったのですが、検査結果を待たずして引っ越してしまったので本当の花粉症なのか未だになぞです。

今回は Amazon Personaliize のアップデートがあったので、ためしてみました！

Amazon Personalize とは

Amazon Personalize (以下、Personalize) とは、 Amazon.com で使用されている機械学習アルゴリズムを使用して、ユーザへのレコメンデーション機能を簡単に作成できるサービスです。
Personalize を使用すると、ユーザの嗜好や行動に基づくレコメンデーション機能などを簡単にアプリケーションで実現できます。

Personalize のスコアリング

今回のアップデートで、各レコメンデーションアイテムごとに推奨度合いを測るためのスコアが提供されるようになりました。
このアップデートによって、例えば「ユーザにレコメンデーションするアイテムは最高スコアの 50 %以上のものとする」等これまでより柔軟にビジネスロジックに合わせたレコメンデーションが実現できます。

この数値はデータセット内の全てのアイテムに対する 相対的なスコアリング です。
各アイテムのスコアは 0 から 1 の間で、全てのアイテムのスコアの合計は 1 となります。
例えば、レコメンド対象の映画が 3 本しかない場合は、 0.6、 0.3、 0.1 のようになり、対象が 10,000 本の場合、各アイテムの平均スコアは 1 / 10,000 となります。

計算方法等の詳細については、 公式のブログ をご参照ください。

ためしてみる

早速ためしていきましょう！

前提

このアップデートを試す前に、以下に従い ソリューション (学習済みモデル) の作成まで済ませておく必要があります。

Amazon Personalize Getting started

キャンペーンの作成

作成済みのソリューションをデプロイして、キャンペーンを作成します。

作成済みデータセットグループの Dashboard 画面から Create new campaign (新しいキャンペーンを作成) ボタンをクリックします。

作成済みのソリューションバージョンを指定し (他は任意)、 Create campaign (キャンペーンの作成) ボタンをクリックします。

キャンペーンの作成ステータスが Active になるまでしばらく待ちます。

作成が完了すると、キャンペーンのテストがマネジメントコンソールからできるので、テスト用の User ID を入力してテストしてみましょう。

Get recommendations (レコメンデーションの取得) ボタンをクリックすると、レコメンデーションアイテムと一緒にスコアリング結果も取得することができました。

CLI で取得してももちろん同様の結果が得られます。

$ aws personalize-runtime get-recommendations \
--campaign-arn arn:aws:personalize:ap-northeast-1:xxxxxxxxxxxx:campaign/campaign-using-scores \
--user-id 1

{
    "itemList": [
        {
            "itemId": "466",
            "score": 0.0043079
        },
        {
            "itemId": "1544",
            "score": 0.0042353
        },
        {
            "itemId": "1580",
            "score": 0.0039171
        },
        {
            "itemId": "474",
            "score": 0.0036741
        },
        {
            "itemId": "3408",
            "score": 0.0035137
        },
        {
            "itemId": "2641",
            "score": 0.0030193
        },
        {
            "itemId": "587",
            "score": 0.0029323
        },
        {
            "itemId": "2716",
            "score": 0.0028162
        },
        {
            "itemId": "1573",
            "score": 0.0027067
        },
        {
            "itemId": "1393",
            "score": 0.0025739
        },
        {
            "itemId": "515",
            "score": 0.0025597
        },
        {
            "itemId": "25",
            "score": 0.0024938
        },
        {
            "itemId": "1073",
            "score": 0.0024364
        },
        {
            "itemId": "1019",
            "score": 0.0024356
        },
        {
            "itemId": "1923",
            "score": 0.0024212
        },
        {
            "itemId": "1129",
            "score": 0.0024064
        },
        {
            "itemId": "1183",
            "score": 0.0023887
        },
        {
            "itemId": "1101",
            "score": 0.0022543
        },
        {
            "itemId": "494",
            "score": 0.0022437
        },
        {
            "itemId": "1408",
            "score": 0.002216
        },
        {
            "itemId": "11",
            "score": 0.0022076
        },
        {
            "itemId": "380",
            "score": 0.0021826
        },
        {
            "itemId": "1407",
            "score": 0.0021254
        },
        {
            "itemId": "357",
            "score": 0.0020975
        },
        {
            "itemId": "788",
            "score": 0.0020394
        }
    ]
}

おわりに

Personalize はデータさえあれば簡単にレコメンデーションの機能の実装ができて便利ですね。
また、スコアリングの値も取得できるようになり、更に幅が広がりそうです！！！

また、本ブログの内容は 2020/4/15(水) 12:00 より YouTube Live で配信される「30分でわかる AWS UPDATE！」でも取り上げる予定ですので、ぜひご覧ください！
もしリアルタイムで見逃しても、アーカイブ動画から内容を確認できます。

参考

• Amazon Personalize とは
• Amazon Personalize が推奨アイテムのスコアの提供を開始
• Introducing recommendation scores in Amazon Personalize
• Amazon Personalize Get Started
• Amazon Personalizeをつかって簡単レコメンデーション

こんにちは、技術1課の小倉です。
2020/4/8にアップデートがあり、AWS Fargateがプラットフォームバージョン1.4をリリースしました！

AWS Fargate がプラットフォームバージョン 1.4 をリリース

プラットフォームバージョン1.4で追加された主な機能は以下です。

• Fargateタスクが Amazon Elastic File System (EFS) エンドポイントをサポート
  • タスクを作成するときにボリュームの追加でEFSが選択できるようになっています。

• 統合された20GBのエフェメラルボリュームが Fargate タスクに付属
• ネットワークパフォーマンスメトリックスが Amazon CloudWatch Container Insights で利用可能
  • Fargate上のタスクのCPU使用率などが確認できるようになっています。

• ECS Task Metadata Endpointバージョン4を介してネットワーク統計が Fargate で利用可能
  • ECS_CONTAINER_METADATA_URI_V4という変数が使えるようになっています。
  • Fargateタスクで実行されているコンテナから次のコマンドを使用して、メタデータエンドポイントにクエリを送信し、ネットワーク統計を含む統計を抽出できます。
    • curl ${ECS_CONTAINER_METADATA_URI_V4}/task/stats
  • Task Metadata Endpoint version 4

プラットフォームバージョンの履歴については以下のサイトから確認できます。2020/4/14現在、AWSドキュメントの英語サイトでプラットフォームバージョン1.4の詳細が記載されています。

AWS Fargate Platform Versions

詳細については以下のAWSブログに記載されています。

AWS Fargate launches platform version 1.4.0

AWS Fargateとは

AWS Fargate は、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) の両方で動作する、コンテナ向けサーバーレスコンピューティングエンジンです。サーバレスのため、サーバのプロビジョニングと管理が不要になります。AWS Fargate の料金は、稼働しているTaskに割り当てたCPUとメモリ量による時間単位の従量課金となっています。

AWS Fargate の料金

設定方法

Fargateのプラットフォームバージョン1.4の設定方法です。

タスク定義とクラスターの作成をしたあと、クラスターにサービスの作成をするところでプラットフォームバージョンを選択できる画面がでてきますので、ここで使用したいバージョンを指定します。1点注意は LATEST を選択しても1.4にならないので注意が必要です。

なぜLATESTが1.4ではないかですが、現在、1.4はユーザにテストをしてもらう期間としているとのことです。詳細は以下のAWSブログに記載されています。

AWS Fargate platform versions primer

まとめ

AWS Fargateがプラットフォームバージョン1.4をリリースしました。バージョンが上がったことで使える機能が増えていますが、プラットフォームバージョンを明示的に1.4を指定しないと使えませんので、注意が必要です。

また、本ブログの内容は2020/4/15(水) 12:00よりYouTube Liveで配信される「30分でわかる AWS UPDATE！」でも取り上げる予定ですので、ぜひご覧ください！
もしリアルタイムで見逃しても、アーカイブ動画から内容を確認できます。

こんにちは。技術4課の古川です。

AWS CodeCommit、 CodeBuild、CodeDeploy、または CodePipeline に Slack 通知を設定できることは、ご存知の方も多いと思います。

公式ブログ(https://aws.amazon.com/jp/about-aws/whats-new/2020/04/receive-notifications-for-aws-codebuild-codecommit-codedeploy-codepipeline-in-slack/)

によると、2020年4月2日より、AWSコンソールで数回クリックするだけでslack通知を設定できるようになったようですが、この記事だけでは何が簡単になったのかいまいちわかりません。

そこで本記事では、実際に検証してみたいと思います

目次

1. 概要
2. codecommit設定
3. AWS Chatbot設定
4. 通知確認
5. まとめ

1.概要

CodePipelineとCodeCommitのレポジトリを予め用意し、Slack通知のトリガーをプルリクエスト作成に設定します。

2.codecommit設定

コンソール画面でcodecommitの設定を行います。右上の通知設定から、通知作成を選択します

続いて、通知ルールの作成をします。通知名を任意で決めたら、詳細タイプを選択します。

詳細タイプは、公式ではデフォルトの「フル」が推奨となっています。例えば、「フル」 を選択した場合、プルリクエストの通知内容にコメントが含まれます。通知機能が強化された場合や通知内容に情報が追加された場合は、通知設定を変えることなく新しい形式の通知を受信できます。

今回は、プルリクエストが作成されると通知をトリガーするように設定します。

続いてSNSトピックを作成を選択し、Target typeを「AWS Chatbot（Slack）」に設定すると、AWS Chatbotのコンソール画面に遷移できます。

3.AWS Chatbot設定

AWS Chatbotのコンソール画面に遷移し、「新しいクライアント」を設定します。その際に、Amazon ChimeとSlackのどちらかを選択できるのですが、今回はSlackで設定します。

Slackを選択すると、AWS Chatbotが通知先のSlack ワークスペースのパーミッションを要求します。許可すると、下図のように対象のSlackチャンネルを設定するように求められます。

SlackがAWS Chatbotを正常に承認したら、設定したSlackワークスペースの設定画面から「新しいチャンネルを設定」をクリックします。

設定名は任意ですがここでは「test」とします。Amazon Cloudwatch Logsにログを発行するか選択し、通知を送りたいSlackチャンネルを選択します。今回は「times-furukawa」に通知を送りたいと思います。

アクセス許可の設定をします。今回はテンプレートを使用して、AWS Chatbotのアクセス許可を定義するIAMロールを作成します。ロール名は任意で、ポリシーテンプレートは選択しません。

次に通知オプションの設定ですが、ここが今回のアップデートの重要なポイントです。以前は予めSNSトピックを作成し、AWS Chatbotと連携させる必要がありました。しかし、今回のアップデートにより、SNSトピックを事前に作成せずとも、AWS Chatbotのチャンネル設定を行うことで、SNSトピックを自動で生成できるようになりました。

よって、通知設定は空欄で問題ありません。Codecommitレポジトリのリージョンに、SNSトピックを自動生成してくれます。

チャンネルの設定が完了しました。SNSトピックも自動生成させれいます。

4.通知確認

それでは、先ほど設定したプルリクエストの作成をトリガーとして、指定したSlackのチャンネルに通知が行くか確認します。

今回はレポジトリ「sls-demo-repo」のtestブランチをmasterブランチにマージする際のプルリクエストを作成します。

特に問題なく、「times-furukawa」に通知が届きました。

5.まとめ

実際に手を動かしてみて、簡単にSlack通知を作成することができました。

今回はcodecommitにSlack通知設定を行いましたが、他のcode兄弟にも設定可能です。

今回のAWSアップデートのように、局所的であるが使いやすくなるようなアップデートが日々行われております。

次回も役に立つアップデートを検証してみたいと思います。

こんにちは。ぱぴぷぺポインコと暮らしている高橋です。
「やってみよう」というと、猿とおねえさんが色々なことにチャレンジする某番組を思い出しますよね。

AWS Systems Manager (SSM) が便利という話をよく聞くので、一体どんなことができるのか? をまとめてみました。今回は概要の説明までですが、一部機能は当社ブログの手順をご案内しています。（2020/04/15時点の情報です）

AWS Systems Manager (SSM) とは

AWS SSMを用いることで、オンプレミス／AWS両環境で運用に必要な作業を、実施することができます。
・リソース状況の可視化
・定型作業の実施
・インタラクティブな操作
・アプリケーションの設定管理

20200212 AWS Black Belt Online Seminar AWS Systems Manager (P.10)

ということで、マネジメントコンソール上からオンプレミス、およびAWSのリソースを管理することができるサービスです。SSMという略称は、EC2に特化した前身のサービス「EC2 Simple Systems Manager」の名残のためのようです。

では、実際にどんなことをやれるのか。まずは概要の一覧です。

SSMでやれること

大きく6つに分かれています。

[全体]
・高速セットアップ：インスタンスをSSMで管理するよう自動構成

[運用管理]
・エクスプローラー(Explorer)：運用アイテム情報のダッシュボード
・OpsCenter：運用アイテム（対応が必要なイベント）の管理
・CloudWatch ダッシュボード：CloudWatch用のダッシュボードをカスタマイズ
・Trusted Advisor と PHD：Trusted Advisor と Personal Health Dashboard のダッシュボード

[アプリケーション管理]
・リソースグループ(Resource Groups)：タグによるサーバー群のグループ管理
・AppConfig：アプリケーション設定（機能グラフ等）の管理
・パラメータストア：設定パラメータの集中管理用データストア

[アクションと変更]
・自動化(Automation)：AWS環境全体に対する自動化処理の実行
・カレンダーの変更(Change Calendar)：実行可否を制御するカレンダー
・メンテナンスウィンドウ：自動化処理のスケジュールと順序の管理

[インスタンスとノード]
・コンプライアンス(Configuration Compliance)：コンプライアンスの適合状態ダッシュボード
・インベントリ(Inventory Management)：サーバー構成情報のインベントリを閲覧する
・マネージドインスタンス(Managed Instance)：SSM管理対象のサーバー群
・ハイブリッドアクティベーション(Activations)：オンプレミスサーバーをSSM管理下に入れる
・セッションマネージャー(Session Manager)：SSMを使ったサーバーへリモートアクセスする
・Run Command：サーバー群の上でコマンドを実行する
・ステートマネージャー(State Management)：サーバー群の構成を指定した状態に維持する
・パッチマネージャー(Patch Mangement)：サーバー群に指定ルールに基づきパッチを適用する
・ディストリビューター(Distributor)：サーバー群にパッケージをインストールする

[共有リソース]
ドキュメント(System Manager Documents)：SSMで実行する処理を記述したドキュメント

SSMをやってみる前に

SSMを使うためには、当該リソースを「マネージドインスタンス」(SSMで管理されたインスタンスのこと)にする必要があります。そのためには、以下の3 Stepが必要です。
・SSM Agentの導入
・SSM AgentからSSM APIへの経路確保
・IAMロールの付与
20200212 AWS Black Belt Online Seminar AWS Systems Manager(P.12)

今回は手順については触れません。詳しくはドキュメントを参照してください。
SSM エージェント の使用

料金について

料金についても確認しておきましょう。大体無料なのですが、一部機能は料金が発生します。発生する機能は以下です。こちらも詳しくはドキュメントを参照してください。
・OpeCenter
・AWS AppConfig
・パラメータストア
・オンプレミスインスタンス管理
・ディストリビューター
・オートメーション

AWS Systems Manager の料金

やってみよう

では実際にやってみましょう。(といっても今回は設定手順などは割愛し、概要の説明までです…)

高速セットアップ

SSMに関する設定を簡単にやってくれる機能です。

・AWS Identity and Access Management (IAM) instance profile roles for Systems Manager.
　（SSM用インスタンスプロファイル、IAMロールの設定）
・A scheduled, bi-monthly update of SSM Agent.
　（SSM Agentの隔週更新）
・A scheduled collection of Inventory metadata every 30 minutes.
　（インベントリ メタデータの収集(30分間隔)）
・A daily scan of your instances to identify missing patches.
　（パッチ適用状況の日次スキャン）
・A one-time installation and configuration of the Amazon CloudWatch agent.
　（CloudWatch Agentのインストールと設定）
・A scheduled, monthly update of the CloudWatch agent.
　（CloudWatchの月次更新）

これが設定画面です。ここで任意の設定をして「Set up Systems Manager」を選択すると、自動でセットアップしてくれるということですね。

各設定については、次の画面で確認することができます。

AWS Systems Manager 高速セットアップ

エクスプローラー(Explorer)

AWS リソースに関する情報を確認できる、カスタマイズ可能なダッシュボードです。

AWS Systems Manager Explorer

OpsCenter

AWSリソースに関連する運用作業項目(OpeItems)を表示、調査、解決できるダッシュボードです。
CloudWatch Eventsのルールとして登録します。

AWS Systems Manager OpsCenter

CloudWatch ダッシュボード

CloudWatchコンソールにあるダッシュボードをカスタマイズできます。

Systems Manager によってホストされる Amazon CloudWatch ダッシュボード

Trusted Advisor と PHD

AWS Trusted Advisor の通知、AWS Personal Health Dashboard のパフォーマンスと可用性のアラートを確認できます。

Systems Manager によってホストされる Trusted Advisor と Personal Health Dashboard

リソースグループ(Resource Groups)

リソースグループを作成して、AWS Systems Managerのコンソール画面からリソースグループ内に紐づけられたリソースを一元管理できます。

詳しくは当社ブログをご覧ください。

AWS Systems ManagerがAWSリソースグループビューが使えるようになりました！

AppConfig

EC2、コンテナ、およびサーバーレスアプリケーションの設定の変更をデプロイできます。
開発や本番など、環境毎に異なる設定情報をデプロイしたり、バリデーションチェックやカナリアデプロイもできるようです。

AWS AppConfig を使用したアプリケーション構成設定の安全なデプロイ

パラメータストア

コンフィグレーションや設定値をプレーンテキスト、あるいは暗号化(KMS)して保管、管理することができます。
例えばCloudWatchエージェント設定ファイルの保存などがおこなえます。

AWS Systems Manager パラメータストア

自動化(Automation)

繰り返しタスクの自動化、サーバーの構成検証、監査、EC2やオンプレサーバーの管理などができます。自動化の内容は、AWS提供のドキュメント、あるいは後述のドキュメント機能で作成したドキュメントを選択して決定します。

詳しくは当社ブログをご覧ください。

[初心者向け]SSM Automationをやってみる

【AWS Systems Manager Automation】カスタムオートメーションドキュメントで時間のかかる処理を実行する

カレンダーの変更(Change Calendar)

指定したアクション (Systems Manager Automation ドキュメントなど) が AWS アカウントで実行できるまたはできない日付と時刻の範囲を設定できます。
例えば自動化(Automation)で定期的に実行するタスクについて、土日は実行を許可しない、といったスケジューリングが可能です。

AWS Systems Manager Change Calendar

メンテナンスウィンドウ

オペレーティングシステムのパッチ適用、ドライバーの更新、ソフトウェアやパッチのインストールなどのアクションをスケジューリングできます。

以下、4つのタスク実行をサポートしています。
・Systems Manager Run Command コマンド
・Systems Manager オートメーションワークフロー
・AWS Lambda 関数
・AWS Step Functions タスク

そして、以下のようなことができます。
・SSM エージェント をインストールまたは更新。
・Systems Manager Run Command タスクを使用して PowerShell コマンドおよび Linux シェルスクリプトを実行。
・Amazon マシンイメージ (AMI) の構築、ソフトウェアのブートストラップ、Systems Manager オートメーションタスクを使用したインスタンスの設定。
・インスタンスをスキャンしてパッチ更新を探すなどの追加アクションをトリガーする AWS Lambda 関数を実行。
・AWS Step Functions ステートマシンを実行し、Elastic Load Balancing 環境からインスタンスを削除するタスクや、インスタンスにパッチを適用してから Elastic Load Balancing 環境に戻すタスクなどを実行。

AWS Systems Manager メンテナンスウィンドウ

コンプライアンス(Configuration Compliance)

マネージドインスタンスをスキャンして、パッチコンプライアンスと設定の不一致を確認できます。

AWS Systems Manager 設定コンプライアンス

インベントリ(Inventory Management)

マネージドインスタンスからメタデータを収集できます。収集できるメタデータは以下です。

アプリケーション：アプリケーション名、発行元、バージョンなど。
AWS コンポーネント：EC2 ドライバ、エージェント、バージョンなど。
ファイル：名前、サイズ、バージョン、インストール日、変更および最新アクセス時間など。
ネットワーク設定の詳細：IP アドレス、MAC アドレス、DNS、ゲートウェイ、サブネットマスクなど。
Windows 更新：Hotfix ID、インストール者、インストール日など。
インスタンスの詳細：システム名、オペレーティングシステム (OS) 名、OS バージョン、最終起動、DNS、ドメイン、ワークグループ、OS アーキテクチャなど。
サービス：名前、表示名、ステータス、依存サービス、サービスのタイプ、起動タイプなど。
タグ：インスタンスに割り当てられるタグ。
Windows レジストリ：レジストリキーのパス、値の名前、値タイプおよび値。
Windows ロール：名前、表示名、パス、機能タイプ、インストール日など。
カスタムインベントリ：カスタムインベントリの操作 に説明されるようにマネージドインスタンスに割り当てられたメタデータ。

AWS Systems Manager インベントリ

インベントリについて、関連する当社ブログです。

EC2 Systems ManagerのInventoryを検索して対象のインスタンスにRunCommandを実行したい！

マネージドインスタンス(Managed Instance)

マネージドインスタンスの一覧を確認、各種設定変更等ができます。
・エージェントの自動更新状況確認、設定
・インベントリのセットアップ
・リソースデータの同期（1 つ以上の AWS アカウントおよび 1 つ以上の AWS リージョンで実行されているインスタンスから収集されたメタデータを、1 つの S3 バケットに送信できる）
・パスワードのリセット
・IAMロールの変更
・マネージドインスタンスの登録解除

ハイブリッドアクティベーション(Activations)

オンプレミスサーバー、仮想マシン(VM)などをSSMにマネージドインスタンスとして登録します。

AWS Systems Manager ハイブリッドアクティベーション

ハイブリッド環境の導入手順はこちらです。
ハイブリッド環境で AWS Systems Manager を設定する

セッションマネージャー(Session Manager)

対象のマネージドインスタンスに接続し（セッションを開始）、シェルアクセスすることができます。Linux、Windowsともに対応しています。(AWS CLIからも接続可能)

概要については、当社ブログをご覧ください。

[New] Systems Manager Session Manager – SSH/RDPが不要になる（かもしれない）新機能の話

AWS CLIでポートフォワーディングをおこなうこともできます。

AWS Systems Manager のポートフォワーディング機能がリリースされました

ログ記録と監査

セッションマネージャーでは、ログ記録と監査に関して以下のことが可能です。
・セッションログを作成し、保存する。
・過去 30 日間にインスタンスに行われたすべての接続の詳細を示すレポートを生成する。
・SNSなど、AWS アカウントのセッションアクティビティの通知を生成する。
・AWS Lambda 関数の実行、CodePipeline の開始、または Run Command の実行など、セッションアクティビティの結果としての AWS リソース上の別のアクションを自動的に開始する。

セッションアクティビティのログ記録と監査

Run Command

マネージドインスタンスにログインすることなく、AWS CLIやマネジメントコンソールからコマンドを実行することができます。

コマンドの一例 [AWS-RunShellScript]
チュートリアル: Run Command で AWS Tools for Windows PowerShell を使用する
チュートリアル: Run Command で AWS CLI を使用する

AWS Systems Manager Run Command

ステートマネージャー(State Management)

SSMドキュメント (マネージドインスタンスで Systems Manager が実行するアクションを定義）の実行をスケジューリングできる機能です。以下のようなことができます。

・起動時に特定のソフトウェアを使用してインスタンスをブートストラップする。
・定義済みのスケジュールに従ってエージェント (SSM エージェント など) をダウンロードして更新する。
・ネットワーク設定を設定する。
・インスタンスを Windowsドメインに結合する (Windows インスタンスのみ)。
・ライフサイクルを通じてソフトウェアの更新でインスタンスをパッチする。
・ライフサイクルを通じて Linux および Windows マネージドインスタンスでスクリプトを実行する。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-state.html

パッチマネージャー(Patch Mangement)

マネージドインスタンスのOSパッチを自動で更新します。

AWS Systems Manager Patch Manager

ディストリビューター(Distributor)

Run Command やステートマネージャーなどのSSM機能を併用して、ソフトウェアパッケージを安全に保存、配布することができる機能です。
AWS Systems Manager Distributor

ドキュメント(System Manager Documents)

AWS Systems Manager ドキュメント (SSM ドキュメント) は、マネージドインスタンスで Systems Manager が実行するアクションを定義します。記述にはJSONやYAMLを使用します。
ドキュメントにはいくつかのタイプがあり、タイプ毎に使用する機能が異なります。

コマンドのドキュメント：Run Command, ステートマネージャー, メンテナンスウィンドウ
自動化ドキュメント：オートメーション, ステートマネージャー, メンテナンスウィンドウ
パッケージドキュメント：ディストリビューター
セッションドキュメント：Session Manager
ポリシードキュメント：ステートマネージャー
Change Calendarドキュメント：Change Calendar

AWS Systems Manager ドキュメント

あとがき

いかがでしたでしょうか。

いくつかの機能は、最近GAとなったようで（マネコン上 New と表示される）、まだまだ機能が増えそうな気がします。正直なところ、使い方がよく分かっていない機能もあるので、また別の機会にハンズオンしてみて「できたできた」と歌いたいと思います。

それではまた、ごきげんよう。

どんなときに録音をしたくないの？

サーバーワークスの通話録音しない対策

対策1：録音不可電話番号の設置

転送で通話録音対象から除外する設定

対策2の設定方法をご説明します。

転送はクイック接続を使っています。

クイック接続で設定する転送用の問い合わせフローを通話録音する人と通話録音しない人で使いわけて登録します。

まとめ

Amazon Connect の通話録音は簡単で安価で利用できる便利な機能です。
さらに録音した音声情報はテキスト化して要約したり、感情分析をするなどいろいろな活用が可能です。

しかし、録音すべきではない会話を扱うこともあるかもしれません。
録音をする・しないという単純な選択だけでなく、特定条件において録音をコントロールすることもAmazon Connectなら可能です。

今日ご紹介した通話録音のコントロールはとても小さな改善です。
サーバーワークスは、社内のAmazon Connect環境も日々改善を繰り返しています。

ご紹介するまでもない小さな失敗や改善経験もみなさまの導入支援に還元させていただいています。
現在は、在宅勤務に対応した電話環境構築のご相談も優先的に承っています。

ご相談はこちら▶ https://www.serverworks.co.jp/contact/aws.html

こんにちは。CI部の柳田です。
CodeCommit では IAM ポリシーを使って特定ブランチへの操作を制限することができるので、試しにやってみようと思います。

やりたいこと

master ブランチと develop ブランチのあるリポジトリ（本ブログでは test-repo ）で、特定ユーザが master ブランチの更新や削除をできないよう制限をします。
具体的には、master ブランチに対して以下をできなくしちゃいます。

• コミットのプッシュ
• ブランチのマージ
• プルリクエストのマージ
• AWS マネジメントコンソールからのファイル追加・更新
• ファイル削除（AWS CLI からのみできる操作）
• ブランチの削除

設定手順

1. IAM ポリシーの作成

「deny-action-master-branch」という IAM ポリシー名で以下ポリシーを作成します。
【】内は環境に合わせて設定してください。

{
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Deny",
                    "Action": [
                        "codecommit:GitPush",
                        "codecommit:DeleteBranch",
                        "codecommit:PutFile",
                        "codecommit:DeleteFile",
                        "codecommit:MergeBranchesByFastForward",
                        "codecommit:MergeBranchesBySquash",
                        "codecommit:MergeBranchesByThreeWay",
                        "codecommit:MergePullRequestByFastForward",
                        "codecommit:MergePullRequestBySquash",
                        "codecommit:MergePullRequestByThreeWay"
                    ],
                    "Resource": "arn:aws:codecommit:ap-northeast-1:【AWSアカウントID】:【リポジトリ名】",
                    "Condition": {
                        "StringEqualsIfExists": {
                            "codecommit:References": [
                                "refs/heads/master"
                            ]
                        },
                        "Null": {
                            "codecommit:References": false
                        }
                    }
                }
            ]
        }

2. IAM ユーザへ IAM ポリシーを紐付け

「deny-action-master-branch」という IAM ユーザを作成し、以下ポリシーを設定します。

• AWSCodeCommitPowerUser
• deny-action-master-branch（1. で作成したポリシー）

これで、IAM ユーザ「deny-action-master-branch」は、master ブランチへの更新や削除ができなくなりました。
制限対象の IAM ユーザが複数いる場合は、IAM グループにポリシーを設定するようにしましょう。

動作確認

作成した IAM ユーザ「deny-action-master-branch」を使って、 master ブランチの更新や削除ができなくなっているか確認します。
AWS マネジメントコンソールからの編集ができないこととコミットのプッシュができないこと、2点のみを載せていますが、プルリクエストのマージやブランチの削除も master ブランチに対してはできないです。

AWS マネジメントコンソールから編集ができないことを確認

IAM ユーザ「deny-action-master-branch」で AWS マネジメントコンソールにログインします。

master ブランチ

「修正できるかな」を追加して、コミットしてみましたが、権限がないためエラーとなります。

develop ブランチ

「修正できるかな」を追加して、コミットしてみました、問題なく実行できます。

コミットのプッシュができないことを確認

まずは、リポジトリからコードをクローンします。

master ブランチ

「GitPushできるかな(master)」を追加して、プッシュしてみましたが、権限がないためエラーとなります。

develop ブランチ

「GitPushできるかな(develop)」を追加して、プッシュしてみました。問題なく実行できます。

おわりに

IAM ポリシーを使った細やかな権限設定ができるのは、CodeCommit の良い点だと思います。
特定ブランチを特定ユーザのみ更新ができるようにしたい場合は是非活用してみてください。

参考資料

https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/auth-and-access-control-iam-identity-based-access-control.html
https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/how-to-conditional-branch.html

CSM課の佐野です。
CloudEndure Disaster Recoveryのご紹介も3つ目の記事になってしまいました。
前回の記事までに準備・フェイルオーバーと続いたので、今回はフェイルバック手順をご紹介したいと思います。
これまでのご紹介内容については、以下のブログをご覧くださいませ。

• 【その１：準備編】CloudEndure Disaster RecoveryでEC2をAZ間DR
• 【その２：フェイルオーバー編】CloudEndure Disaster RecoveryでEC2をAZ間DR

やりたいこと

以下のフェイルバックシナリオを仮定します。

• DR発生時はEC2「Windows2016」がAZ「ap-northeast-1a」から「ap-northeast-1c」にフェイルオーバー
• AZ「ap-northeast-1a」が復旧したら、「Windows2016」を元のAZ「ap-northeast-1a」にフェイルバックして戻す

このフェイルバック処理は、同VPC内のAZ間だけでなく、リージョン間DRを検討されている方には必須となると思われます。
操作はフェイルオーバーと大きく変わりません。さっそく確認していきましょう。

１．フェイルバック

DR発生の原因が取り除かれ、DR元だったAZが復旧したら、フェイルバック動作を行います。
フェイルオーバーしたリカバリ用のマシンが構築されていることを確認して、CloudEndureコンソール上の「Machines」の詳細画面の右上、「PROJECT ACTIONS」から「Prepare For Failback」を選択します。

以下の画面で「現在のターゲットマシンがソースマシンとして扱われる」と説明されていますね。確認して「CONTINUE」をクリックします。
その後、CloudEndureコンソールのプロジェクト名の横を見ると、「Preparing for failback to original Source」としてプロジェクト全体がフェイルバックのモードに入った状態になります。

CludEndureコンソールに新しくマシンを登録した際と同じく、データの初期同期が開始されます。
また、マシンの詳細には「FAILBACK SETTINGS」というタブが出現しますが、こちらはフェイルバック用のレプリケーションサーバについての設定項目です。準備編で設定した内容がそのまま反映されていますが、もし変更したい場合はここで設定をすることが可能です。

フェイルバックするEC2の初期同期～データの継続的レプリケーションに入ったら、「BLUEPRINT」の設定が可能です。
フェイルオーバー編を参考に、今度は元のAZに戻す方の設定を実施します。おそらく、サブネットやIPアドレスの設定がフェイルオーバーの時と変更になると思いますので、よく確認しながら設定してください。

フェイルバックも同じく、無停止フェイルバックテストと本番フェイルバックの両方が実施可能です。
詳細な手順につきましては、フェイルオーバー編とまったく同じになりますので、割愛します。
この手順を行うことで、元のAZ「ap-northeast-1a」にサーバをフェイルバックできました。

２．プロジェクトをDR前の状態に戻す

一連のフェイルバック動作で、プロジェクトに登録されたサーバをすべて元のAZ「ap-northeast-1a」にデータを保って戻すことができたら、CloudEndureコンソールでのプロジェクトのモードを「通常のオペレーション」＝「DR前の状態に戻す」ことが必要です。
CloudEndureコンソール上の「Machines」の詳細画面の右上、「PROJECT ACTIONS」から「Return To Normal Operation」を選択します。

フェイルバックの時と同じく、「現在のターゲットマシンがソースマシンとして扱われる」となり、データの向きが元に戻りますと説明されています。もちろんそのようにしたいので、「CONTINUE」で次に進みましょう。

ターゲットだったAZ「ap-northeast-1a」側のサーバがソースサーバとして初期同期が始まり、準備編の最後の状態までに戻りました。
プロジェクトの状態もフェイルバックから解除されていますので、追加でサーバを登録することも可能です。
長かったですが、これでフェイルバック作業は完了です！お疲れ様でした！

３．Windowsサーバでハマったこと

Windowsサーバでフェイルオーバー実行後にフェイルバックをすぐ実施すると、データの初期レプリケーションが長時間完了しない現象が何度か発生し、しばらくハマりました。。。
そこでOSにログインしてみると、なんとデスクトップ右下に「Windowsのライセンス認証エラー」が。
「コントロールパネル」＞「システム」の画面にも、ライセンス認証がされていないエラーが出ておりました。

もしかしてこれが原因かと思い、こちらのAWSドキュメントの手順でEC2インスタンスのメタデータサービスへのルーティング追加とWindowsライセンスを再認証すると、レプリケーションが完了できました。

CloudEndureエージェントはマシンの特定のため、EC2インスタンスのメタデータ情報を収集しています。
フェイルオーバー/フェイルバックはソースマシンとなるEC2インスタンスのOSの状態をそのまま保ちますが、AZ間の移行でサブネットのCIDRおよびIPアドレスが変化したことによって、元のOS上の情報ではメタデータサーバにアクセスできなくなったことが、初期レプリケーションが完了しないエラーと、Windowsライセンスの再認証が必要になった原因と思われます。
もしフェイルオーバー/フェイルバック直後に同様の事象が発生した場合は、上記の手順を試してみてください。

参考：“Windows のライセンス認証ができません”
参考：Understanding the Agent Installation Process

フェイルバック編のおわりに

3回の記事に分けてCloudEndure Disaster RecoveryでVPC内のAZ間でEC2をDRする手順についてご紹介しました。
準備とDRの流れのイメージさえつかめれば、あとの操作はCloudEndureコンソールでクリック作業なので、そこまで難しくありません。
AWS内でのDR対策にCloudEndure Disaster Recovery、そして本ブログがお役に立てれば幸いです。

さてこれまではほとんどAWS IoTの話でしたが、Jetson Nanoを利用し、エッジで機械学習 × IoTみたないことをやっていきます。

弊社はクラウドの会社なのでこういったデバイスを扱うことはほとんどないのですが、今回はPytorchのMNISTのサンプルを動かしてJetson Nanoの性能を見てみます。Pytorchなんで正確には「エッジでディープラーニング」というべきでしょうか。

なので今回はJetson Nanoの話です。

1. jtopコマンドのインストール

jtopはJetson Nanoの負荷状況を表示するコマンドです。まずはこれをpipでインストールしておきます。
pipがインストールされてなければ先にそちらをインストールしてください。

sudo -H pip install jetson-stats

2. サンプルのクローン

サンプルとして動かすノートブックをGitHubへあげておきました。

これをクローンします。jupyterがインストールされてなければ先にそちらをインストールしてください。

git clone https://github.com/KSMN455/pytorch-gpu-sample.git

こちらのサンプルはPytorchのMNISTのサンプルをもとに記述しています。

3. GPU vs. CPU

こちらのサンプルを使い、GPUで学習を実施した場合とCPUで学習を実施した場合で負荷と速度を比較したいと思います。

まあ結果は予想できますが。。。

ノートブックを上から順に実施してください。

3-1. GPUの場合

まずはGPUを使って学習。

train("cuda")

ワタシの環境では時間はこんな感じでした。

Pprocessing Time(sec): 951.2301895618439

だいたい16分くらい。

ちなみに学習中のjtopの表示はこんな感じ。GPU使用率が100%あたりで張り付いているのがわかります。

この後、温度が60℃以上まであがったので、うちわであおぎました。。。ファンを取り付けてないので人力冷却です。。。

3-2. CPUの場合

まずはCPUを使って学習。

train("cpu")

ワタシの環境では時間はこんな感じでした。

Pprocessing Time(sec): 9837.17104125022

遅ぇ。。。GPUの場合の約10倍で、2時間以上かかってます。。。

ちなみに学習中のjtopの表示はこんな感じ。各コアの使用率が100%あたりで張り付いているのがわかります。

こちらを実行中も温度が上がってきたのでうちわであおぎました。。。

4. まとめ

当たり前ですがGPUを利用した学習の方が圧倒的に早いです。MNISTの手書き文字くらいであればJetson Nanoでもやれてしまいますが、大規模なものだとクラウドで学習→エッジへデプロイとするのが良いかと思います。

次回はモデルの予測結果をデバイス-クラウド間・デバイス-デバイス間で連携する方法を検証したいと思います。