Quantcast
Channel: 技術 –サーバーワークスエンジニアブログ
Viewing all 1210 articles
Browse latest View live

Cloud AutomatorでAMI作成で元のEC2インスタンスのタグを引き継ぐようになりました

$
0
0

本日から「EC2: AMIを作成」アクションで作成したAMIが元のEC2インスタンスのタグを引き継ぐようになりました。

元のEC2インスタンスのタグを引き継ぐ機能について

これまでは元のEC2インスタンスと同じタグを付けたい場合においても、Cloud Automatorでジョブ作成をする際にタグを設定する必要がありました。しかし、今回のリリースで元のEC2インスタンスのタグをそのまま引き継ぐようになったので、今後はEC2インスタンスと同じタグをジョブ作成時に指定する必要はなくなり、タグ付の入力の手間を減らすことができます。

元のEC2インスタンスのタグを引き継ぐ設定方法

デフォルトで有効になります。個別に設定の必要はありません。
また、すでに登録済みのジョブについても元のEC2インスタンスのタグが引き継がれるようになります。

よくある質問

EC2インスタンスについているタグを上書きしてAMIを作成したい

Cloud Automatorの「EC2: AMIを作成」ジョブの設定値で上書きしたいタグを指定してください。
「EC2: AMIを作成」ジョブのタグ設定値が優先されてAMIが作成されます。

EC2インスタンスのNameタグが引き継がれない

Nameは現行の仕様通り Cloud Automator Source Instance Name として引き継がれます。

EC2インスタンスのタグが一切引き継がれない

すでに30個を越えるタグがEC2インスタンスについている場合は、Cloud Automatorの管理用タグとの関連でタグ上限を超える恐れがあるため元のEC2インスタンスのタグは引き継がれません。
EC2インスタンスに30個を超えるタグが付いている場合でも、EC2インスタンスのNameとCloud Automatorジョブ登録時に指定したタグはAMIに付与されます。

終わりに

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

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


【新AWS認定!】AWS 認定データベース — 専門知識 が来月からスタートします

$
0
0

タイトルの通り、いよいよ来月からAWS 認定データベース – 専門知識 の試験スタートが予定されております!

2020年1月でベータ試験の実施が終了し、サンプル問題こちらより公開されております。現時点では 2020年4月6日から試験開始 の予定となっているようです。

AWS 認定データベース — 専門知識 とは

まずは本試験の概要について、試験ガイドより抜粋した内容は以下の通りです。

「AWS 認定データベース — 専門知識」 (DBS-C01) 試験は、データベースロールを遂行する人を対 象としています。この試験では、データベースに関する全体的な理解度 (例: 設計、移行、展開、 アクセス、保守、自動化、監視、セキュリティ保護、トラブルシューティング) を評価します。

つづいて本試験に関する出題分野と比重について、試験ガイドより抜粋した内容は以下の通りです。

ドメイン  割合 
ドメイン1:ワークロード固有のデータベース設計  26%
ドメイン2:展開および移行  20%
ドメイン3:管理および運用  18%
ドメイン4:監視およびトラブルシューティング  18%
ドメイン5:データベースセキュリティ  18%

より詳細な情報はこちらからご確認ください。

現段階ですでに他11の認定を取得されている方々にとってはさらなるコンプリートの奪還、いや奪冠をかけたものとなるのではないでしょうか。

これまでの専門知識 試験についておさらい

AWS公式の技術ドキュメントはとても充実しており、専門知識 試験といえど基本的にはドキュメントにて公開されている内容の理解が問われます。しかし、試験ごとに高度な専門領域の理解がベースにないと一筋縄ではいかない点が「専門知識」試験たる所以かと思います。

決してそのすべてではありませんが、各試験を突破するにあたって知っておくべき専門知識の一例をご紹介します。

対象の認定試験 知っておくべき専門知識
AWS 認定ビッグデータ – 専門知識  Hadoopエコシステム (Apache HBase、Apache Spark、Apache Luceneなど)
AWS 認定高度なネットワーキング – 専門知識 BGP (AS_PATH属性、LOCAL_PREF属性など)
AWS 認定セキュリティ – 専門知識 暗号化技術 (SSL/TLS、対称・非対称暗号化方式など)
AWS 認定機械学習 – 専門知識 データサイエンス領域の専門的知識 (各学習アルゴリズム、モデル評価指標など)
AWS 認定 Alexa スキルビルダー – 専門知識 スキル申請〜審査〜公開までの過程や条件、Alexa搭載デバイスなど

※ 2020年4月13日以降はAWS 認定データ分析 – 専門知識 と名称・バージョンが新たになります

AWS 認定データベース — 専門知識 ではどうか

本試験に関する推奨される経験や知識について、試験ガイドより抜粋した内容は以下の通りです。

推奨される AWS の知識

• 一般的なデータベーステクノロジーを使用した 5 年以上の経験。

• AWS に関する 2 年以上の実務経験。

• オンプレミス環境および AWS クラウド環境のリレーショナルデータベースおよび NoSQL データベースに関する経験および専門知識。

サンプル問題の選択肢にもPostgreSQLのバックアップ・リストアコマンドが選択肢にあることからAWSだけにとどまらず、多少なりとも OSS / 商用の各データベースエンジン固有の知識も求められることが推察できます。

・・・そりゃ、そうですよね (笑)

最後に

AWSでは幅広い認定試験のほか体系的に学べるトレーニングメニューが用意されており、技術者としては興味の尽きることがありません。弊社でも各拠点の猛者たちが専用Slackチャンネルに集い、新しい試験の開始を待ち望んでおります。合格できた暁には、学習内容をこのブログでレポートしようと思います!

以上、AWSの新認定に関するお知らせでした!

 

Amazon Connect で上限緩和申請

$
0
0
本エントリーではAmazon Connectの上限緩和について最新情報をお届けします。

Amazon Connect のサービスクォータ

Amazon Connectにもサービスクォータ(旧名称:サービス制限)が存在しています。

– インスタンスあたりの電話番号数
– インスタンスあたりのユーザー数
– インスタンスあたりのキュー数
といった項目は不足すれば構築時に気がつく項目です。

一方
– インスタンスあたりの同時呼び出し数
は、運用後に気がつくかもしれない項目でうっかりひっかかってしまたら大変です。
お客様との接触機会をロスすることに直結してしまいます。
本番運用前にサービスクォータの内容をチェックして運用上問題がないか確認をすることをおすすめします。

Amazon Connect のサービスクォータ調整

そんな、Amazon Connect サービスクォータ が2020年2月に変更されました。
2020-03-03時点では英語版のドキュメントで最新化されていますが、日本語版は古いままのようですのでお気をつけください。
クォータは調整されていくため、使用しているアカウントに設定されたクォータはドキュメントで説明されるクォータと異なる場合があります。
AWS Service Quotas で現在のAWSアカウントで適用されている クォータを確認するようにしてくださいね。
 
2020年2月の変更では以下の調整をしたようです。
– チャット機能への対応
– 既存の電話の制限を強化
 
わたしが気になった調整値を3つご紹介させていただきます。
 
アカウントあたりの Amazon Connect インスタンス数
Amazon Connect instances per account
5 → 2
 
インスタンスあたりの同時呼び出し数
Concurrent calls per instance
100 → 5
 
インスタンスあたりの電話番号数
Phone numbers per instance
10 → 5
 

Amazon Connect のサービスクォータ 上限緩和申請

上記含めほとんどのクォータは上限緩和申請をすることによって、必要なクォータに引き上げることが可能です。
運用開始前にチェックをして余裕をもった適正値での申請をおすすめします。
サーバーワークスのAWSリセールサービス(pieCe)にご契約しているお客様は、弊社サポートサイトからご連絡いただければ弊社にて申請の代行をさせていただきます。
 

Amazon Connect の特殊な上限緩和申請

Amazon Connect は他のAWSサービスと少し異質な上限緩和申請が存在しています。

その1)03番号の取得

東京に住所があれば03番号の取得を申請することができます。
複数の03番号を取得することも可能です。
 
必要要件と手続方法は下記ドキュメントをご参照ください。
アジアパシフィック (東京) リージョン の Amazon Connect インスタンスの電話番号を取得する方法
 
サーバーワークスでは自社利用はもちろん、お客様が利用する03番号の取得について複数実績がございます。
03番号をはじめて申請する際はどこの会社もなにかとつまづきがちです。
サーバーワークスのAWSリセールサービス(pieCe)にご契約しているお客様は、提出する書類や提供の時期感等のご相談に対応させていただくことが可能です。
弊社サポートサイトからお気軽にご相談ください。

その2)電話できる国

通常国内利用のケースが多いかと思いますが、要件によっては海外への電話も必要になるかと思います。
Amazon Connectでは海外に電話をかけることも可能です。
しかし、デフォルトで発信できる国には制限があります。
 
こちらについても上限緩和申請で、電話をかけることができるようになります。
ただしすべての国に対応しているというわけではないので、ご希望の国と地域を申請して相談してください。
逆に電話をかけられる国々を制限するリクエストを送信することもできます。
サーバーワークスでは多くの国への上限緩和申請を行った案件の実績がございます。
 

まとめ

今日は運用開始前にチェックしたい Amazon Connect のサービスクォータについて説明をさせていただきました。
AWSのほかサービスに慣れている人も、Amazon Connectの構築経験がある人も、これからAmazon Connectにチャレンジする人も最新情報でサービスクォータをチェックして必要な上限緩和を事前に行うように注意してくださいね。

AWS Lambda の Provisioned Concurrency について調べてみた

$
0
0

はじめに

こんにちは、技術一課の山中です。

もう春ですね。春は好きです。こんな時だからこそ、春を感じて過ごしたいです。

Provisioned Concurrency とは

2019 年 12 月に発表された機能です。

https://aws.amazon.com/jp/about-aws/whats-new/2019/12/aws-lambda-announces-provisioned-concurrency/

この機能を利用すると、初期化処理の完了した AWS Lambda の実行環境を事前にプロビジョニングしておくことができます。
これまでは、 AWS Lambda のコールドスタート対策として、 CloudWatch Events で定期的に対象の Lambda ファンクションを起動するような方法がとられていましたが、この機能を利用するとより簡単に対策を行うことができそうです。

料金

通常の AWS Lambda の料金は以下のとおりです。 ※ 東京リージョンの場合

項目 料金
リクエストに応じた料金 1 M リクエスト当たり、 0.20 USD
コンピューティング料金 1 GB のコンピューティング環境で 1 秒間実行するにつき、 0.000016667 USD

これに対して、 Provisioned Concurrency を有効にする場合、以下に基づいて料金が発生します。 ※ 東京リージョンの場合

項目 料金
Provisioned Concurrency を有効にしている間かかる料金 1 GB のコンピューティング環境を 1 秒間確保すると、 0.000005384 USD
リクエストに応じた料金 1 M リクエスト当たり、 0.20 USD
コンピューティング料金 1 GB のコンピューティング環境で 1 秒間実行するにつき、 0.000012562 USD

例えば、関数に 1,024 MB のメモリを割り当て、 Provisioned Concurrency を 2 時間有効にしたとしましょう。
プロビジョニングした同時実行数は 1,000 とします。
2 時間の間に関数を 120 万回実行し、 1 リクエストにつき 1 秒間稼動しました。
この場合の料金は以下のように計算されます。

1. Provisioned Concurrency の料金

  • Provisioned Concurrency の料金は、 GB / 秒当たり、 0.000005384 USD
  • Provisioned Concurrency が有効になっている合計秒数は、 2 時間 → 7,200 秒
  • プロビジョニングした同時実行の合計 (GB) は、 1,024 MB → 1 GB なので、同時実行数 1,000 × 1 GB → 1,000 GB
  • Provisioned Concurrency の合計量 (GB / 秒) は、 1,000 GB × 7,200 秒 → 7,200,000 GB / 秒

よって、以下のようになります。

Provisioned Concurrency 料金 → 7,200,000 GB/秒 x 0.000005384 USD = 39 USD

2. リクエスト料金

  • リクエストに応じた料金は、 1,000,000 リクエスト当たり 0.20 USD

よって、以下のようになります。

リクエスト料金 → 1,200,000 リクエスト × 0.20 USD / 1,000,000 リクエスト = 0.24 USD

3. コンピューティング料金

  • コンピューティング料金は、 GB / 秒当たり、 0.000012562 USD
  • 合計コンピューティング時間 (秒) は、 1,200,000 リクエスト × 1 秒 / リクエスト → 1,200,000 秒
  • 実行コンピューティングの合計量 (GB / 秒) は、 1,024 MB → 1 GB なので、 1,200,000 秒 × 1 GB → 1,200,000 GB / 秒

よって、以下のようになります。

合計コンピューティング料金 → 1,200,000 GB / 秒 × 0.000012562 USD = 15 USD

4. 合計料金

合計料金 → Provisioned Concurrency の料金 + リクエスト料金 + コンピューティング料金 = 39 USD + 0.24 USD + 15 USD = 54.24 USD

よって、この例では東京リージョンだと 54.24 USD 程度の料金が発生することがわかりました。

使ってみる

検証用に以下 2 つの Amazon API Gateway + AWS Lambda の組み合わせを用意しました。

1. Provisioned Concurrency を有効にした API

リクエスト URL プロビジョニングされた同時実行数
xxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/enabled 100

2. Provisioned Concurrency は無効の API

リクエスト URL プロビジョニングされた同時実行数
xxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/disabled 0

このリクエスト URL に対して、 ApacheBench からリクエストをして計測していきます。

Provisioned Concurrency を有効にした API

Provisioned Concurrency を有効にした API に対して、実行した結果は以下のとおりです。
一瞬でレスポンスが返ってきました。

$ ab -n 100 -c 100 https://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/enabled
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking xxxxxx.execute-api.ap-northeast-1.amazonaws.com (be patient).....done


Server Software:
Server Hostname:        xxxxxx.execute-api.ap-northeast-1.amazonaws.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
Server Temp Key:        ECDH P-256 256 bits
TLS Server Name:        xxxxxx.execute-api.ap-northeast-1.amazonaws.com

Document Path:          /dev/enabled
Document Length:        0 bytes

Concurrency Level:      100
Time taken for tests:   0.311 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      48200 bytes
HTML transferred:       0 bytes
Requests per second:    321.42 [#/sec] (mean)
Time per request:       311.119 [ms] (mean)
Time per request:       3.111 [ms] (mean, across all concurrent requests)
Transfer rate:          151.29 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       11   59  14.9     71      73
Processing:    27   46  14.7     47     173
Waiting:       26   45  14.5     46     170
Total:         74  104  15.3    104     184

Percentage of the requests served within a certain time (ms)
  50%    104
  66%    110
  75%    115
  80%    119
  90%    122
  95%    125
  98%    130
  99%    184
 100%    184 (longest request)

Provisioned Concurrency は無効の API

続いて Provisioned Concurrency は無効の API に対して実行します。
やはり、先ほどと比べるとかなりレスポンスまでに時間がかかっています。

$ ab -n 100 -c 100 https://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/disabled
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking xxxxxx.execute-api.ap-northeast-1.amazonaws.com (be patient).....done


Server Software:
Server Hostname:        xxxxxx.execute-api.ap-northeast-1.amazonaws.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
Server Temp Key:        ECDH P-256 256 bits
TLS Server Name:        xxxxxx.execute-api.ap-northeast-1.amazonaws.com

Document Path:          /dev/disabled
Document Length:        0 bytes

Concurrency Level:      100
Time taken for tests:   4.248 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      48200 bytes
HTML transferred:       0 bytes
Requests per second:    23.54 [#/sec] (mean)
Time per request:       4248.289 [ms] (mean)
Time per request:       42.483 [ms] (mean, across all concurrent requests)
Transfer rate:          11.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       11   71  20.7     79      82
Processing:    58  990 301.6    957    3028
Waiting:       54  989 301.8    957    3028
Total:         83 1060 306.1   1036    3107

Percentage of the requests served within a certain time (ms)
  50%   1036
  66%   1068
  75%   1093
  80%   1112
  90%   1164
  95%   1213
  98%   2301
  99%   3107
 100%   3107 (longest request)

この後にすぐ、同じリクエストを実行してみた結果が以下です。
この結果から、レスポンスで時間がかかっていた原因として、コールドスタートが起因していることが考えられますね。

$ ab -n 100 -c 100 https://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/disabled
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking xxxxxx.execute-api.ap-northeast-1.amazonaws.com (be patient).....done


Server Software:
Server Hostname:        xxxxxx.execute-api.ap-northeast-1.amazonaws.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
Server Temp Key:        ECDH P-256 256 bits
TLS Server Name:        xxxxxx.execute-api.ap-northeast-1.amazonaws.com

Document Path:          /dev/disabled
Document Length:        0 bytes

Concurrency Level:      100
Time taken for tests:   0.268 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      48200 bytes
HTML transferred:       0 bytes
Requests per second:    373.68 [#/sec] (mean)
Time per request:       267.612 [ms] (mean)
Time per request:       2.676 [ms] (mean, across all concurrent requests)
Transfer rate:          175.89 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       66   69   5.0     66      80
Processing:    21   35   8.8     34      94
Waiting:       21   35   8.8     34      94
Total:         87  104   9.8    104     160

Percentage of the requests served within a certain time (ms)
  50%    104
  66%    107
  75%    110
  80%    110
  90%    114
  95%    121
  98%    138
  99%    160
 100%    160 (longest request)

おわりに

金額に注意は必要ですが、 Provisioned Concurrency を使うとコールドスタートで使うのをためらっていたケースでも AWS Lambda を検討しやすくなりますね。

VPC間でVPN接続してみた件

$
0
0

こんにちは。技術5課の冨塚です。
最近寒さが続きなにもやる気がでない中ふとVPN接続ためしたので書き留めたいと思います。

AWS環境との通信するには以下の3つがあり、今回はVPN接続について記載します。

  • インターネットからアクセス
  • VPN接続してアクセス
  • DirectConnet接続してアクセス

VPN接続するにあたり、設定が必要なコンポーネントや対向装置への設定投入などやることを整理する意味でまとめていけたらと思います。

やりたいこと

AWSでサイト間VPN接続を実現したい

構成図

今回構築した環境の構成図が以下になります。

東京リージョンとバージニアリージョン間でVPN接続をしています。
東京リージョンでは、VGW,CGWを利用して、バージニアリージョンではVyOSを利用してみました。
各リージョンのプライベートサブネットに配置したEC2同士が通信できればやりたいこと達成となります。

1.バージニアリージョン対応

この項ではバージニアリージョンでやったことを記載します。

すること

  • VyOS構築
  • 確認用EC2構築

VyOS構築

VyOSはVyattaがBrocadeに買収された時にフォークしてできたソフトウェアルータです。そのBrocadeも今は。。。
では実際に構築していきます。

  1. EC2コンソールへアクセスし、「インスタンスの作成」をクリック
  2. 検索エリアでvyosを入力し、AWS MarketplacesからVyOSの「選択」をクリック

  3. インスタンスタイプに応じた料金内容が表示されるので「Continue」をクリック

  4. インスタンスタイプを選択し、「確認と作成」をクリック

  5. 作成VPCやセキュリティグループを選択し「起動」をクリック

  6. 起動したVyOSを選択し右クリック > ネットワーキング > 送信元/送信先の変更チェックを無効化

    EC2のデフォルト動作では自身のIPアドレス以外へのパケットは破棄されてしまうため、この設定をすることでVyOS配下のEC2へパケットを転送できるようになります。

これでVyOSの構築は完了になります。設定内容については後述します。確認用のEC2の作成手順は特記事項ないので割愛します。Amazon Linux 2で構築しました。

2.東京リージョン対応

この項では東京リージョンでやったことを記載します。

すること

  • カスタマーゲートウェイ(CGW)作成
  • 仮想プライベートゲートウェイ(VGW)作成
  • サイト間のVPN接続設定
  • ルートテーブルでルート伝播を有効化する

カスタマーゲートウェイについては拠点側のルータ装置(今回はVyOS)を想定しています。

カスタマーゲートウェイ作成

カスタマーゲートウェイを作成する上で対向装置のIPアドレス情報が必要になりますので、予め用意してください。今回はVyOSへ割り当てたグローバルIPアドレスを利用しました(EIPではないのですが、利用する際はEIPを推奨します)。

  1. VPCコンソール > カスタマーゲートウェイ へ移動し、「カスタマーゲートウェイ作成」をクリック
  2. カスタマーゲートウェイ名とルーティング方法、IPアドレスを入力し「カスタマーゲートウェイの作成」をクリック

カスタマーゲートウェイはこれだけになります。

仮想プライベートゲートウェイ作成

  1. VPCコンソール > 仮想プライベートゲートウェイ へ移動し、「仮想プライベートゲートウェイの作成」をクリック
  2. 仮想プライベートゲートウェイ名とASNを入力し「仮想プライベートゲートウェイ」をクリック

  3. 仮想プライベートゲートウェイをVPCと関連付け

仮想プライベートゲートウェイもこれだけになります。
今回はASNはAWS側指定のものを利用するように設定しています。対向ルータ装置もしくは拠点側で同一のASNが使わていない事を確認の上ご利用ください。

サイト間のVPN接続設定

  1. VPCコンソール > サイト間のVPN接続設定 へ移動し、「VPN接続の作成」をクリック
  2. VPN名と先に作成したCGW/VGWの情報を入力して「VPN接続の作成」をクリック

  3. 作成したVPN設定をクリックし、「設定のダウンロード」をクリック

  4. 拠点側で利用するルータに合致する選択肢をプルダウンから選び「ダウンロード」をクリック

ルートテーブルでルート伝搬を有効化する

  1. 拠点側のルート情報を受信するルートテーブルを選択し、「ルート伝達の編集」をクリック

  2. 作成したVGWの伝播にチェックを入れ「保存」をクリック

これで東京リージョンの準備は完了になります。

拠点ルータ(VyOS)設定投入

サイト間のVPN接続設定の際にダウンロードした拠点側ルータ用のConfigファイルの設定情報を投入していきます。当環境ではVyOSへ設定を投入していきますが、利用環境に応じて読み替えて頂けると幸いです。
※グローバルIPアドレスはマスクしています

VyOS設定

VyOSはデフォルトユーザがvyosとなりますので、以下のコマンドでログインします。

ssh -i "<秘密鍵名>" vyos@<vyosグローバルIPアドレス>

成功すると以下出力されます。

Welcome to VyOS

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
vyos@ip-172-31-80-194:~$

VyOSはsetコマンドで設定変更が可能です。ダウンロードしたConfigファイルのsetから始まる行を何も考えずにコピー&ペーストしていきます。
設定モードへ移動してペーストします。投入後は設定反映のためcommitコマンドを実行します。

vyos@ip-172-31-80-194:~$ config
[edit]
vyos@ip-172-31-80-194# set vpn ipsec ike-group AWS lifetime '28800'
thentication mode 'pre-shared-secret'
---- snip ----
[edit]
vyos@ip-172-31-80-194# commit
[edit]
vyos@ip-172-31-80-194#

設定内容を確認します。section形式だと長いのでset形式で出力してみます。

vyos@ip-172-31-80-194:~$ show configuration commands 
set interfaces ethernet eth0 address 'dhcp'
set interfaces ethernet eth0 duplex 'auto'
set interfaces ethernet eth0 hw-id '12:af:ed:21:68:d7'
set interfaces ethernet eth0 smp-affinity 'auto'
set interfaces ethernet eth0 speed 'auto'
set interfaces loopback lo
set interfaces vti vti0 address '169.254.132.114/30'
set interfaces vti vti0 description 'VPC tunnel 1'
set interfaces vti vti0 mtu '1436'
set interfaces vti vti1 address '169.254.148.14/30'
set interfaces vti vti1 description 'VPC tunnel 2'
set interfaces vti vti1 mtu '1436'
set protocols bgp 65001 address-family ipv4-unicast network 0.0.0.0/0
set protocols bgp 65001 neighbor 169.254.132.113 address-family ipv4-unicast soft-reconfiguration inbound
set protocols bgp 65001 neighbor 169.254.132.113 remote-as '64512'
set protocols bgp 65001 neighbor 169.254.132.113 timers holdtime '30'
set protocols bgp 65001 neighbor 169.254.132.113 timers keepalive '10'
set protocols bgp 65001 neighbor 169.254.148.13 address-family ipv4-unicast soft-reconfiguration inbound
set protocols bgp 65001 neighbor 169.254.148.13 remote-as '64512'
set protocols bgp 65001 neighbor 169.254.148.13 timers holdtime '30'
set protocols bgp 65001 neighbor 169.254.148.13 timers keepalive '10'
set service ssh client-keepalive-interval '180'
set service ssh disable-password-authentication
set service ssh port '22'
set system config-management commit-revisions '100'
set system console device ttyS0 speed '9600'
set system host-name 'ip-172-31-80-194'
set system login user vyos authentication encrypted-password '*'
set system login user vyos authentication plaintext-password ''
set system login user vyos authentication public-keys deploy-st key 'AAAAB3NzaC1yc2EAAAADAQABAAABAQCfME/IO8ytCTvATXlNezTVMI28ekRd4eK81Dne8iPLzOnv2ByJABXYNX+kkWIfF8RM+1dPATnoURqmWwjp9xD3mlLHarjqj6Wbg4Rsnkh/oRUDfoyAjrIbNkihz8VZpf3XrPHRCn+FJybQ40k7CWs90eAlfsjhr6Ecds7pbP9iA48b26R
09YGbb4tUHZzpluRlAzAjy3M+1sbUQwM0ZOpDk4h3XojZJL0TFp/NcDLPdV5hVbyhyDo1Q+dr2tUFLL0Td3/NjcV7gfK0MhK/yoVasPu+nfNocbC/aulLIvN7GVCec5Q72KDsRuvWok0R+Y2uUa1tkEuJJwP+SkpfJ0cb'
set system login user vyos authentication public-keys deploy-st type 'ssh-rsa'
set system login user vyos level 'admin'
set system ntp server 0.pool.ntp.org
set system ntp server 1.pool.ntp.org
set system ntp server 2.pool.ntp.org
set system syslog global facility all level 'notice'
set system syslog global facility protocols level 'debug'
set system time-zone 'UTC'
set vpn ipsec esp-group AWS compression 'disable'
set vpn ipsec esp-group AWS lifetime '3600'
set vpn ipsec esp-group AWS mode 'tunnel'
set vpn ipsec esp-group AWS pfs 'enable'
set vpn ipsec esp-group AWS proposal 1 encryption 'aes128'
set vpn ipsec esp-group AWS proposal 1 hash 'sha1'
set vpn ipsec ike-group AWS dead-peer-detection action 'restart'
set vpn ipsec ike-group AWS dead-peer-detection interval '15'
set vpn ipsec ike-group AWS dead-peer-detection timeout '30'
set vpn ipsec ike-group AWS ikev2-reauth 'no'
set vpn ipsec ike-group AWS key-exchange 'ikev1'
set vpn ipsec ike-group AWS lifetime '28800'
set vpn ipsec ike-group AWS proposal 1 dh-group '2'
set vpn ipsec ike-group AWS proposal 1 encryption 'aes128'
set vpn ipsec ike-group AWS proposal 1 hash 'sha1'
set vpn ipsec ipsec-interfaces interface 'eth0'
set vpn ipsec site-to-site peer XX.XX.151.165 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer XX.XX.151.165 authentication pre-shared-secret 'd_LrgFOxLRQ5dc99sgpUQkXhp.zhviy1'
set vpn ipsec site-to-site peer XX.XX.151.165 connection-type 'initiate'
set vpn ipsec site-to-site peer XX.XX.151.165 description 'VPC tunnel 1'
set vpn ipsec site-to-site peer XX.XX.151.165 ike-group 'AWS'
set vpn ipsec site-to-site peer XX.XX.151.165 ikev2-reauth 'inherit'
set vpn ipsec site-to-site peer XX.XX.151.165 local-address '172.31.80.194'
set vpn ipsec site-to-site peer XX.XX.151.165 vti bind 'vti0'
set vpn ipsec site-to-site peer XX.XX.151.165 vti esp-group 'AWS'
set vpn ipsec site-to-site peer XX.XX.119.98 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer XX.XX.119.98 authentication pre-shared-secret 'gwrdNZbCfNt8WrmyhWlPNjgO59I411rs'
set vpn ipsec site-to-site peer XX.XX.119.98 connection-type 'initiate'
set vpn ipsec site-to-site peer XX.XX.119.98 description 'VPC tunnel 2'
set vpn ipsec site-to-site peer XX.XX.119.98 ike-group 'AWS'
set vpn ipsec site-to-site peer XX.XX.119.98 ikev2-reauth 'inherit'
set vpn ipsec site-to-site peer XX.XX.119.98 local-address '172.31.80.194'
set vpn ipsec site-to-site peer XX.XX.119.98 vti bind 'vti1'
set vpn ipsec site-to-site peer XX.XX.119.98 vti esp-group 'AWS'

AWSからダウンロードできる設定ファイルと動作するVyOSのバージョンの差異だと思うのですが、いくつかのコマンドがそのままでは実行できませんでした。試してみる際にはバージョンを確認してからご利用ください。
また、AWS側ルートテーブルへデフォルルート(0.0.0.0/0)を伝搬させたくない場合は、network <Network CIDR>で伝搬するネットワークを絞ってみてください。

前:set protocols bgp 65001 neighbor 169.254.132.113 soft-reconfiguration 'inbound'
後:set protocols bgp 65001 neighbor 169.254.132.113 address-family ipv4-unicast soft-reconfiguration inbound

前:set protocols bgp 65001 network 0.0.0.0/0
後:set protocols bgp 65001 address-family ipv4-unicast network 0.0.0.0/0

VyOSのセキュリティグループへ以下を追加

タイプ プロトコル ポート範囲 ソース
カスタムプロトコル ESP(50) すべて <VPNトンネル1 外部IPアドレス>
カスタムプロトコル ESP(50) すべて <VPNトンネル2 外部IPアドレス>
カスタムUDPルール UDP 500 <VPNトンネル1 外部IPアドレス>
カスタムUDPルール UDP 500 <VPNトンネル2 外部IPアドレス>

動作確認

ここまできたらあとは接続確認をするだけです。Pingの通信確認ができれば問題ありません。

AWS側状態確認

まずはAWS側のVPNトンネルの状態を確認していきます。設定に問題がなければ下記画像のようにAWS側でトンネルステータスがアップしていることが確認できますね。

ルート伝搬有効化したルートテーブルの状態を確認してみます。VyOS側で設定したデフォルトルート(0.0.0.0/0)が追記されていることが確認できます。

VyOS動作確認

次にVyOS側の状態を確認していきます。まずはike/ipsecのステータスを確認します。
問題なくike/ipsec共にステータスがupしていますね。

vyos@ip-172-31-80-194:~$ show vpn ipsec sa
Connection                      State    Up          Bytes In/Out    Remote address    Remote ID    Proposal
------------------------------  -------  ----------  --------------  ----------------  -----------  ------------------------------------------------
peer-XX.XX.119.98-tunnel-vti   up       17 minutes  9K/13K          XX.XX.119.98     N/A          AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
peer-XX.XX.151.165-tunnel-vti  up       23 minutes  7K/12K          XX.XX.151.165    N/A          AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

vyos@ip-172-31-80-194:~$ show vpn ike sa
Peer ID / IP                            Local ID / IP               
------------                            -------------
XX.XX.151.165                          172.31.80.194                          

    Description: VPC tunnel 1

    State  IKEVer  Encrypt  Hash    D-H Group      NAT-T  A-Time  L-Time
    -----  ------  -------  ----    ---------      -----  ------  ------
    up     IKEv1   aes128   sha1_96 2(MODP_1024)   no     3600    28800  

 
Peer ID / IP                            Local ID / IP               
------------                            -------------
XX.XX.119.98                           172.31.80.194                          

    Description: VPC tunnel 2

    State  IKEVer  Encrypt  Hash    D-H Group      NAT-T  A-Time  L-Time
    -----  ------  -------  ----    ---------      -----  ------  ------
    up     IKEv1   aes128   sha1_96 2(MODP_1024)   no     3600    28800

次にルーティングテーブルを確認してみます。
VGWをアタッチしたVPCNのCIDR(10.200.0.0/16)が表示されていれば、VyOSとVGW間でルート情報のやりとりができていることになります。

vyos@ip-172-31-80-194:~$ show ip route 
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

S>* 0.0.0.0/0 [210/0] via 172.31.80.1, eth0, 01:18:49
B>* 10.200.0.0/16 [20/100] via 169.254.148.13, vti1, 00:20:04
C>* 169.254.132.112/30 is directly connected, vti0, 00:26:26
C>* 169.254.148.12/30 is directly connected, vti1, 00:20:36
C>* 172.31.80.0/20 is directly connected, eth0, 01:18:51
vyos@ip-172-31-80-194:~$

次にBGPで送信/受信しているルート情報をみてみましょう。
まず送信しているルート情報から確認します。

vyos@ip-172-31-80-194:~$ show ip bgp neighbors 169.254.132.113 advertised-routes 
BGP table version is 9, local router ID is 172.31.80.194, vrf id 0
Default local pref 100, local AS 65001
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0/0        0.0.0.0                  0         32768 i
*> 10.200.0.0/16    169.254.148.13                         0 64512 i

Total number of prefixes 2

次に受信しているルート情報を確認します

vyos@ip-172-31-80-194:~$ show ip bgp neighbors 169.254.132.113 received-routes 
BGP table version is 0, local router ID is 172.31.80.194, vrf id 0
Default local pref 100, local AS 65001
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.200.0.0/16    169.254.132.113        200             0 64512 i

Total number of prefixes 1

VyOS側のBGPテーブルを確認します
東京リージョンのルート情報である 10.200.0.0/16 が表示されていれば相互通信の準備が完了です。

vyos@ip-172-31-80-194:~$ show ip bgp 
BGP table version is 9, local router ID is 172.31.80.194, vrf id 0
Default local pref 100, local AS 65001
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0/0        0.0.0.0                  0         32768 i
*> 10.200.0.0/16    169.254.148.13         100             0 64512 i
*                   169.254.132.113        200             0 64512 i

Displayed  2 routes and 3 total paths

疎通確認用EC2

[ec2-user@10-200-21-14 ~]$ ping 172.31.80.194
PING 172.31.21.169 (172.31.21.169) 56(84) bytes of data.
64 bytes from 172.31.21.169: icmp_seq=1 ttl=254 time=165 ms
64 bytes from 172.31.21.169: icmp_seq=2 ttl=254 time=166 ms
64 bytes from 172.31.21.169: icmp_seq=3 ttl=254 time=165 ms
64 bytes from 172.31.21.169: icmp_seq=4 ttl=254 time=165 ms
^C
--- 172.31.21.169 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 165.761/166.031/166.730/0.496 ms

通信できましたー!!

ついでにVyOSでパケットキャプチャしてみます。

vyos@ip-172-31-80-194:~$ sudo tcpdump -i any -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
12:47:07.483590 IP 10.200.21.14 > 172.31.21.169: ICMP echo request, id 4890, seq 1, length 64
12:47:07.484346 IP 172.31.21.169 > 10.200.21.14: ICMP echo reply, id 4890, seq 1, length 64
12:47:07.484359 IP 172.31.21.169 > 10.200.21.14: ICMP echo reply, id 4890, seq 1, length 64
12:47:08.484346 IP 10.200.21.14 > 172.31.21.169: ICMP echo request, id 4890, seq 2, length 64
12:47:08.484479 IP 10.200.21.14 > 172.31.21.169: ICMP echo request, id 4890, seq 2, length 64
12:47:08.485105 IP 172.31.21.169 > 10.200.21.14: ICMP echo reply, id 4890, seq 2, length 64
12:47:08.485117 IP 172.31.21.169 > 10.200.21.14: ICMP echo reply, id 4890, seq 2, length 64
12:47:09.486258 IP 10.200.21.14 > 172.31.21.169: ICMP echo request, id 4890, seq 3, length 64
12:47:09.486373 IP 10.200.21.14 > 172.31.21.169: ICMP echo request, id 4890, seq 3, length 64
12:47:09.486965 IP 172.31.21.169 > 10.200.21.14: ICMP echo reply, id 4890, seq 3, length 64
12:47:09.486977 IP 172.31.21.169 > 10.200.21.14: ICMP echo reply, id 4890, seq 3, length 64
12:47:10.488162 IP 10.200.21.14 > 172.31.21.169: ICMP echo request, id 4890, seq 4, length 64
12:47:10.488294 IP 10.200.21.14 > 172.31.21.169: ICMP echo request, id 4890, seq 4, length 64
12:47:10.488924 IP 172.31.21.169 > 10.200.21.14: ICMP echo reply, id 4890, seq 4, length 64
12:47:10.488936 IP 172.31.21.169 > 10.200.21.14: ICMP echo reply, id 4890, seq 4, length 64

上記結果から東京リージョンにあるEC2(Tokyo-1)とバージニアリージョンになるEC2(Virginia-1)間で通信できていることが確認できました。

まとめ

  • VyOSを利用することでVPN接続の確認ができました。
  • 本ブログではVyOSからデフォルトルート(0.0.0.0/0)を伝搬していますが、複数のVPN接続構成を実現する際はバージニアリージョンから伝搬するルートはVPCのCIDR(172.31.0.0/16)に絞るなど考慮が必要です。
  • 余裕があればStaticなVPN構成にもチャレンジしたい。

それではよいAWSライフをお送りください。

AWS 認定ソリューションアーキテクト – アソシエイト試験の新バージョンが受験可能になりました!

$
0
0

こんにちは、技術1課の小倉です。
2020/2/25にアップデートがあり、AWS 認定ソリューションアーキテクト – アソシエイト試験の新バージョンが2020/3/23から受験できるようになりました。旧バージョンの試験は2020/3/22まで受験可能です。

AWS 認定ソリューションアーキテクト – アソシエイト試験の新しいバージョンが利用可能に

新バージョンの試験情報ですが、ここは旧バージョンと変更はありません。

形式 : 複数の選択肢と複数の答えがある問題
タイプ : アソシエイト
実施形式 : テストセンター
時間 : 130 分間
受験料金 : 15,000 円(税別)
言語 : 英語、日本語、韓国語、中国語 (簡体字)

2020/3/3現在の試験の申込サイトのキャプチャ画像です。旧バージョンは試験名のあとに(Retires March 22, 2020) と書かれています。同じ試験名が2つありますので、2020/3/22までに試験を予約する場合は間違わないように注意してください。新バージョンは2020/3/23以降の日程で試験の予約ができます。

旧バージョンを申し込もうとすると確認のポップアップが表示されます。

模擬試験も新バージョンが用意されていて、旧バージョンは試験名のあとに(Retires March 22, 2020) と書かれています。模擬試験は新バージョンでも今すぐ受験できます。

試験ガイドの比較

試験内容が試験ガイドに記載されていますので、新旧バージョンの試験内容を比較します。
大きく違うところは新バージョンでは分野が5から4に減っています。そして、新旧を見比べると分野1から4の記載内容は表現は違いますがほとんど変わっていませんでした。

試験ガイドは公式サイトにリンクがありますので、そちらからご確認をお願いいたします。
AWS 認定ソリューションアーキテクト – アソシエイト

  新バージョン 旧バージョン (2020/3/22まで受験可能)
分野1 レジリエントアーキテクチャの設計 30% 回復性の高いアーキテクチャを設計する 34%
分野2 高パフォーマンスアーキテクチャの設計 28% パフォーマンスに優れたアーキテクチャを定義する 24%
分野3 セキュアなアプリケーションとアーキテクチャの設計 24% セキュアなアプリケーションおよびアーキテクチャを規定する 26%
分野4 コスト最適化アーキテクチャの設計 18% コスト最適化アーキテクチャを設計する 10%
分野5 オペレーショナルエクセレンスを備えたアーキテクチャを定義する 6%

※レジリエント : 回復力、耐久力
※オペレーショナルエクセレンス : 運用上の優位性

各分野ごとの項目を確認しましたが、新バージョンは分野5がなくなり、分野2,3,4の範囲が広がっているように見えます。内容が多いので、各分野ごとの項目の比較は最後に補足として記載いたします。

サンプル試験問題

新バージョンのサンプル試験問題もすでに公開されていますので、どのような問題がでるのか雰囲気を確認できます。

サンプル試験問題

新旧の模擬試験を受けてみた

どんな感じで変わっているかを確認するために新旧の模擬試験を受けてみました。
感想としては新バージョンは、最近リリースされたサービスが多くでてきたので、最近リリースされたサービスの知識も必要となり、旧バージョンよりも難しくなっています(問題を解くのに時間ぎりぎりまでかかってしまいました)。また旧バージョンは現在ではAWSのアップデートで改善されているけど、改善前のことが答えになったりしているので、新バージョンで受験することをおすすめします。

また、問題文の日本語が若干わかりにくいときがありますので、そのときは画面上部で英語に切り替えられます。英語のほうが内容を理解しやすい時もあるため、日本語がわからないときは英語に切り替えてみましょう。

新バージョンの模擬試験の情報です。

形式 : 複数の選択肢と複数の答えがある問題
タイプ : アソシエイト
実施形式 : オンライン
時間 : 30 分間
問題数 : 20 問
受験料金 : 模擬試験 2,000円(税別)
言語 : 英語、日本語、韓国語、中国語 (簡体字)

まとめ

AWS 認定ソリューションアーキテクト – アソシエイト試験の新バージョンが受験できるようになりました。資格は自身のスキルアップのためであったり、会社で評価されるなど、持っていて損はしないものです。AWSを使っているのであればAWS 認定ソリューションアーキテクト – アソシエイトの取得を目指してみてはいかがでしょうか。

また、本ブログの内容は2020/3/5(木) 12:00よりYouTube Liveで配信される「30分でわかる AWS UPDATE!」でも取り上げる予定ですので、ぜひご覧ください!

補足 : 各分野ごとの項目比較

各分野ごとの項目を比較しました。新バージョンのかっこ内の数字は旧バージョンと同じ内容の項番を記載しています。
新旧で違いのあるところをオレンジで書いてあります。

新バージョン 旧バージョン (2020/3/22まで受験可能)
分野1
1.1 多層アーキテクチャソリューションの設計 (1.3) 1.1 信頼性と回復性の高いストレージを選択する。
1.2 可用性の高いアーキテクチャやフォールトトレラントなアーキテクチャの設計 (1.4) 1.2 AWS サービスを使用した分離機構を設計する方法を定義する。
1.3 AWS のサービスを使用したデカップリングメカニズムの設計 (1.2) 1.3 多層アーキテクチャソリューションを設計する方法を定義する。
1.4 適切な回復力のあるストレージの選択 (1.1) 1.4 可用性またはフォルトトレラント性 (あるいはその両方) が高いアーキテクチャを設計する方法を定義する。
分野2
2.1 ワークロードに対する伸縮自在でスケーラブルなコンピューティングソリューションの識別 (2.3) 2.1 パフォーマンスの高いストレージとデータベースを選択する。
2.2 ワークロードに対するパフォーマンスとスケーラブルなストレージソリューションの選択 (2.1) 2.2 キャッシュを使用してパフォーマンスを向上させる。
2.3 ワークロードに対するパフォーマンスが高いネットワーキングソリューションの選択 (2.2 範囲が広がっている) 2.3 伸縮性と拡張性を備えたソリューションを設計する。
2.4 ワークロードに対するパフォーマンスの高いデータベース ソリューションの選択 (2.1)  
分野3
3.1 AWS リソースへのセキュアなアクセスの設計
(3.3 範囲が広がっている)
3.1 アプリケーション層をセキュリティ保護する方法を定義する。
3.2 セキュアなアプリケーション階層の設計 (3.1) 3.2 データをセキュリティ保護する方法を定義する。
3.3 適切なデータセキュリティオプションの選択 (3.2) 3.3 単一の VPC アプリケーション用のネットワークインフラストラクチャーを定義する。
分野4
4.1 コスト効率が高いストレージソリューションの識別 (4.1) 4.1 コスト最適化ストレージを設計する方法を定義する。
4.2 コスト効率が高いコンピューティングおよびデータベース サービスの識別 (4.2 データベースが追加されている) 4.2 コスト最適化コンピューティングを設計する方法を定義する。
4.3 コスト最適化ネットワークアーキテクチャの設計  
分野5
5.1 オペレーショナルエクセレンスを実現するソリューションの設計特性を選択する。

 

AWS Cloud WatchでEC2のCPU使用率が0%と表示される

$
0
0

こんにちは!技術三課の三木です。

新型肺炎対策としてリモートワーク(在宅勤務)をするようになりました。陽のささぬマンションの1階に住んでいるせいか、部屋が1日中寒いことに悲しみを覚えています。春が待ち遠しいです。

さて、今日はAmazon Cloud Watch(以下Cloud Watch)で、EC2(Nitro系)のCPU利用率が0%になってしまう現象について記載します。

この記事の内容を三行でまとめると

  • CloudWatchのメトリクスで、EC2のCPU使用率(CPUUtilization)が0%となることがある
  • Nitroベースのインスタンスのメトリクス値は常に整数で取得される

  • 上記仕様によって、CPU利用率が0.23%など一定値を下回っている場合は、0%と表示される

Windows ServerのCPU利用率(CPUUtilization)が0%と表示される(Cloud Watch)

何が起きたか


2つのEC2インスタンスは、どちらも同じAMI(Windows Server 2016)から、同じ日に作成したものです。

しかし、片方のインスタンスだけCPU Utilizationが0%の時間がある状態です。

またCPU負荷がかかった際は出力されており、全くデータが取得出来てない訳でもありませんでした。


加えて、CPU Utilization以外のメトリクスは取得出来ています。

画像は同時刻のNetworkInメトリクスですが、こちらは常に数KBを示していました。

何が原因か

Cloud Watchの公式ドキュメントに以下の記載がありました。

Nitro ベースのインスタンスのメトリクス値は常に整数 (0 と正の整数) で、Xen ベースのインスタンスの値は小数をサポートしています。したがってNitro ベースインスタンスでインスタンスの CPU 使用率が低い場合は、0 に切り下げられて表示される場合があります。
『インスタンスの利用可能な CloudWatch メトリクスのリスト表示』

今回利用しているr5.largeはNitroベースのインスタンスであるためこれに該当する、というのが答えでした。

試しにメトリクスを「グラフ化したメトリクス > 統計」を「最大」にして各値を見てみると、確かにすべて整数値であることが分かります。


まとめ

Nitroベースのインスタンスはそもそもの仕様が異なることが多いので、EC2周りで「おかしいぞ?」となった際は気を付けてみることをおすすめします。

なお、Nitroベースのインスタンスは以下にまとめられています。

『AWS Docs – Amazon EC2 > インスタンスタイプ』

参考になれば幸いです。

Amazon EC2(Nitro System)のEBSパフォーマンスが向上しました!

$
0
0

こんにちは、技術1課の小倉です。
2020/2/26にアップデートがあり、Amazon EC2(Nitro System)のEBSパフォーマンスが向上しました!

AWS Nitro System 型 Amazon EC2 インスタンスを追加することにより、EBS 最適化パフォーマンスを 36% 高速化

こちらは2019/12に同様のアップデートがあったのですが、そこで対象となっていなかったインスタンスタイプ(G4dn、I3en、Inf1、M5a/M5ad、R5a/R5ad、T3/T3a、z1d)が今回のアップデートでAmazon EBSのパフォーマンスが向上されています。

Nitro システムを使用する Amazon EC2 インスタンスで、36% 高速化された Amazon EBS 最適化インスタンスのパフォーマンスをサポート (2019/12)

Nitro Systemとは

Nitro Systemを説明する前にNitro Systemが出る前について簡単に説明します。
Amazon EC2のネットワーク、ストレージ、セキュリティの3つの機能はすべてホストOS(Hypervisorの下で稼働するOS)でソフトウェア処理されており、一部ホストOSのリソースを使用していました。そのため、ホストOSの処理でゲストOSに引き渡したCPUやメモリなどのリソースを一部確保してしまい、ゲストOSが割り当てられたリソースをすべて使えないということが起きていました。

Nitro SystemではホストOSで行っていたネットワーク、ストレージ、セキュリティの処理を専用のハードウェアであるNitro Systemにオフロードさせています。そのため、Amazon EC2の性能が上がっています。
※オフロード : システムの処理を他の機器に処理させて負荷を軽減する仕組み

2020/3/4現在、Nitro Systemのインスタンスタイプは以下です。
Nitro ベースのインスタンス

  • A1、C5、C5d、C5n、G4、I3en、Inf1、M5、M5a、M5ad、M5d、M5dn、M5n、p3dn.24xlarge、R5、R5a、R5ad、R5d、R5dn、R5n、T3、T3a、および z1d
  • ベアメタル: c5.metal, c5d.metal, c5n.metal, i3.metal, i3en.metal, m5.metal, m5d.metal, r5.metal, r5d.metal, u-6tb1.metal, u-9tb1.metal, u-12tb1.metal, u-18tb1.metal, u-24tb1.metal, and z1d.metal

EBS最適化とは

EBS最適化が有効の時はEC2へのサービス通信とは別にEBSへの専用の帯域幅を確保しますので、サービス通信の影響を受けません。EBS最適化が無効の時はEBSとサービス通信が同じ通信経路を通りますので、サービス通信が大量に発生するとEBSへの通信にも影響がでます。現在は、旧世代(c3/m3/r3/t2 など)を除けばデフォルトでEBS最適化が有効になっています。

Supported Instance Types
※日本語サイトでは一部帯域(Mbps)の数値が英語サイトと異なっていましたので、英語サイトのリンクを記載しています。

今回のアップデートでは、EBS最適化が有効なEBSへのネットワークの帯域幅が拡張し、パフォーマンスが向上したという内容でした。既存のNitro Systemで本アップデートを有効にする場合は、EC2の停止/起動をすることで有効にすることができます。

まとめ

Nitro Systemという言葉はあまりなじみがないかもしれませんが、現行のEC2の基盤となるプラットフォームです。もしこのブログを読んで、非Nitro SystemからNitro Systemのインスタンスタイプに変更したいと思った方は以下のブログを参考にしてみてください。Nitro Systemに変更するときENA(Elastic Network Adapter)のドライバーのインストールが必要ですので、ご注意ください。
[EC2] Nitroインスタンスへ変更してみた [Windows]
[EC2] Nitroインスタンスへ変更してみた [Amazon Linux]

また、本ブログの内容は2020/3/5(木) 12:00よりYouTube Liveで配信される「30分でわかる AWS UPDATE!」でも取り上げる予定ですので、ぜひご覧ください!


Amazon Transcribe が個人情報を識別して、自動的に PII を隠蔽してくれるようになりました

$
0
0

はじめに

こんにちは、技術一課の山中です。
毎日暖かいですね。最近もう半袖で過ごしているのですが、以前会社で半袖で過ごしていた時に、「みんな長袖なのに一人だけ半袖だと変な人に見られますよ」と言われたことを思い出しました。

本ブログでは、 Amazon Transcribe にてアップデートされた PII の自動編集機能を試していきます!

PII とは

PII とは、 Personally Identifiable Information の略で、個人を識別できる情報のことを指します。
具体的には以下のような情報のことです。

  • フルネーム
  • 住所
  • メールアドレス
  • 社会保証番号 / マイナンバー
  • パスポートの番号
  • 免許証の番号
  • クレジットカードの番号
  • 生年月日
  • 電話番号

個人のプライバシーを保護するために、音声を文字起こしする時に上記のような内容を保護することはとても重要です。
今回のアップデートで、 Amazon Transcribe が自動で PII を識別して隠蔽してくれるようになりました。

対応言語

2020/03/05 時点でこの自動編集機能に対応している言語は、米国英語のみです。

試してみる

早速試してみましょう!

1. サンプル音声データの用意

はじめに、文字起こしをする音声データを用意する必要があります。
個人情報満載の音声ファイルを日本語で作って読み込ませたのですが、英語しか対応していないことに気づき、私のつたない英語を録音しました。
内容は以下のような内容です。

Good morning, everybody.
My name is Daishi Yamanaka, and today I feel like sharing a whole lot of personal information with you. Let's start with my Social Security number 1234567890.
My credit card number is 3456789054327654 And my CVV code is 000 My bank account number is 0003212 My email address is yamanaka@sample.co.jp, and my phone number is 09012345678.
Well, I think that's it.
You know a whole lot about me. And I hope that Amazon transcribe is doing a good job at redacting that personal information away. Let's check.

大丈夫かな…

2. S3 バケットに配置

用意した音声データを S3 バケットに格納します。

3. 文字起こしのジョブ作成

文字起こし用のジョブを作成します。

ジョブ名を入力し、言語は English (United States) を選びます。

Input data には先ほど格納した音声データのパスを入力しましょう。

次のページで、 Automatic content redaction にチェックを入れます。
これを入れることで、文字起こししたテキストから個人情報を自動識別し、 [PII] に置き換えてくれます。

Include unredacted transcript in job output にチェックを入れると、 [PII] に置き換える前のテキストも出力してくれるようです。
今回はテストなので、チェックしておきましょう。

Create ボタンを押すと、ジョブが走り始めます。

ほどなくして、ステータスが Complete に変わりました!!
ジョブを開くと、隠してほしい部分が [PII] に変わっていることがわかります。

Good morning. Every body.
My name is [PII]. And today I feel like shelling. Ah, hold growth off personal information with you. Yes, that with my social Security number. [PII]
It's you know my credit called Number is [PII] [PII] And my C B V cold is [PII] My bank account number is [PII] My email address is [PII] [PII] [PII] [PII] [PII] [PII] and my phone number is [PII] [PII] [PII] Sleep well.
I sing. So that's it. You know the whole world about me and I hope that I was on tricycle. Transcribe is doing a good job, but get back. Take that personal information away.
That chick

(私の英語のせいで、 PII 以外の部分も想定と異なっていますが、気にしないでください悲)
また、 PII を置き換える前と置き換えたあとのテキストは Download full transcript からそれぞれダウンロードできます。

終わりに

いかがだったでしょうか?
とても簡単に PII を隠すことができました!!
早く日本語に対応してくれることを祈るばかりです。

また、本ブログの内容は2020/3/5(木) 12:00よりYouTube Liveで配信される「30分でわかる AWS UPDATE!」でも取り上げる予定ですので、ぜひご覧ください!

参考

AWS Single Sign-On(SSO)でAWSアカウントへシングルサインオン

$
0
0

AWS Single Sign-On(SSO)を使って、AWS Organizationsに含まれるAWSアカウントへのシングルサインオンをできるようにしてみました。

AWS Single Sign-On(SSO)とは

AWS Single Sign-On (SSO) により複数の AWS アカウントとビジネスアプリケーションへのアクセスを簡単に一元管理できるようになり、ユーザーはすべての割り当て済みアカウントとアプリケーションに 1 か所から 1 度のサインオンでアクセスできるようにします。AWS SSO では、AWS Organizations のすべてのアカウントへの SSO アクセスとユーザーアクセス権限の一元管理が簡単になります。SSO は個々のアカウントで追加セットアップをすることなく、アカウントに必要なアクセス許可を自動的に構成および保持します。一般的なジョブ機能に基づいてユーザーにアクセス権を割り当てたり、特定のセキュリティ要件を満たすようにこれらのアクセス許可をカスタマイズしたりできます。また AWS SSO には、Salesforce、Box、Office 365 など多くのビジネスアプリケーションに対する組み込み統合が含まれています。

AWS Single Sign-On

前提

  • AWS OrganizationsでAll featuresが有効になっている
  • AWS Organizationsのマスターアカウントで操作できる権限がある

今回やること

AWS Single Sign-On > 開始方法 のステップに沿ってやりました。

ステップ 1: AWS SSO を有効にする

現時点でAWS SSOを有効にできるリージョンは下記となります。
残念ながら東京は含まれないため、今回はオハイオで有効にします。

  • Europe (London)
  • Europe (Ireland)
  • Asia Pacific (Singapore)
  • Asia Pacific (Sydney)
  • Europe (Frankfurt)
  • US East (N. Virginia)
  • US East (Ohio)
  • Canada (Central)
  • US West (Oregon)

マネージメントコンソール > AWS SSO

「AWS SSOを有効にする」をクリックします。

有効化されました。
ユーザーポータルのURLというのが自動生成されていますが、まだログインできるユーザーを作成していないので、そのままにしておきます。

AWS Organizationsの画面でも有効化されたことが確認できます。

ステップ 2: ディレクトリを選択する

AWS SSOでは、ユーザー情報などを登録・参照するデータベースとして、「AWS SSO」か「Active Directory」を選択できます。
Active Directoryを使う場合は、Microsoft ADまたはAD Connectorを使う必要がありますが、今回はAWS SSOのディレクトリを使います。

マネージメントコンソール > AWS SSO > 設定

デフォルト設定でIDソース、認証、プロビジョニングが全てAWS SSOとなっているので設定は不要です。

ステップ 3: AWS アカウントへの SSO の設定

ユーザーとグループを作成

マネージメントコンソール > AWS SSO > ユーザー > ユーザーの追加

ユーザー登録に必要な項目は、「ユーザー名」「Eメールアドレス」「名」「姓」「表示名」です。

その他にもオプションとして「連絡方法」「職務関連情報」「住所」「設定」「additional attriibutes」の設定が可能です。

ユーザーをグループに追加という画面に遷移します。
IAMと同様でグループに権限を割り当てることが推奨されているため、ここでグループを作成し、ユーザーに割り当てます。

アクセス権限の管理をシンプルにするために、個々のユーザーではなくグループに直接アクセスを割り当てることをお勧めします。

ユーザーアクセスを割り当てる

今回は2つのグループを作成して、ユーザーに割り当ててみました。

ユーザーのパスワード設定

作成したユーザーにメールが届くので、文中の「Accept Invitation」をクリックします。

パスワード設定をします。

ユーザーがアクティブ化されました。

SSOのポータルにログイン可能になりましたが、権限が無いので以下の画面になります。

AWSアカウントへの権限をグループに割り当てる

マネージメントコンソール > AWS SSO > AWS アカウント

ユーザーにアクセスさせたいAWSアカウントを選択し、「ユーザーの割り当て」をクリックします。

権限を与えたいグループを選択します。

グループに与えるアクセス権限を設定します。
「新しいアクセス権限セット」をクリックします。

今回は既存の職務機能ポリシーのPowerUserAccessを選択してみました。
AWSアカウントへログインすると、PowerUserAccessポリシーのついたIAM Roleが適用されます。

これで設定完了しました。

動作確認

ポータルのURLから作成したユーザーでログインすると、AWS Accountが見えるようになっています。

クリックすると、2つのリンクが表示されます。

  • Management console
  • Command line or programmatic access

AWSアカウントのマネージメントコンソールへのログイン

Management consoleをクリックすると、AWSアカウントにログインできました。
フェデレーションログインとなっています。

AWSアカウントへのAPIアクセス

programmatic accessをクリックすると、下記の情報が表示されます。
こちらのアクセスキーなどを使えば、すぐにAPIを利用できます。

感想

シングルサインオンというと、フェデレーションとか信頼とかトークンとか難しい知識が必要になることが多い印象ですが、今回の構成では非常に簡単に設定できました。
今回はやらなかったですが、Active Directoryで一元管理したい場合はより便利かもしれないと思いました。

AWS Configで全リージョンの情報を10分で取得してみた

$
0
0

どこにも訪問しないのにスーツを着てきてしまった技術5課の山崎です。

今回はAWS ConfigについてAWSから下記のアップデートがあったことを受けて、どれくらい簡単に全リージョンの情報を取得できるのか試してみました

高度なクエリの AWS Config マルチアカウント、マルチリージョンのサポートの紹介

AWS Configについて

ドキュメントには下記のように記載されています。

AWS Configは、AWSアカウントにあるAWSリリースの設定詳細ビューを提供します。これには、リソース間の関係と設定の履歴が含まれるため、時間の経過と共に設定と関係がどのように変わるかを確認できます。

AWS Configでは以下のことができます。

・AWSリソースの設定が最適な設定であるかどうかを評価する。
・AWSアカウントに関連付けられているサポート対象リソースの現在のスナップショットを取得する。
・アカウント内にある1つ以上のリソースの設定を取得する。
・1つ以上のリソースの設定履歴を取得する。
・リソースが作成、変更、または削除されるたびに通知を受け取る。
・リソース間の関係を表示する(特定のセキュリティグループを使用するすべてのリソースを確認する場合など)。

参照ドキュメント:AWS Config とは

AWS Configの利用方法については下記の弊社ブログをご覧ください。 AWS Configを使えばリソースの関連を確認できます ~変更作業前の影響範囲確認に

もっと深く知りたい方はBlackBelt資料も合わせてご覧ください 20190618 AWS Black Belt Online Seminar AWS Config

早速、試してみた

Config画面から高度なクエリを選択します すると、発行できるサンプルクエリの一覧が表示されます。(2020年3月5日現在で58個のサンプルクエリがあります) 今回はNot Encrypted EC2 Volumesのクエリを発行して、暗号化されていないボリュームを抽出します。 続いてクエリエディタ画面にアグリゲータの作成があるので、ここを選択 アグリゲータ名を任意で記入 ソースアカウントの追加で、現在操作しているアカウント番号を登録します。ここで他のアカウントのリソースもConfigで見れるようにしたい、つまりマルチアカウントでConfigを利用したい場合は別途、追加したい別アカウントのIDを登録してください。
※ただし、その場合は追加した別アカウントの方で承認作業を行う必要があります。 次にリージョンを選択します。ここでマルチリージョンにConfigを適用することができます。今回は全リージョンにチェックを入れて、将来のAWSリージョンも含めるようにしました。 すると、クエリエディタで作成したアグリゲータが選択できるようになります。以下、アグリゲータを選択しない場合と選択した場合の比較です。

【アグリゲータを選択しない場合】 東京リージョンのリソースのみが表示されます。

【アグリゲータを選択した場合】 別リージョンのリソースも表示されるようになりました

まとめ

今回のアップデート内容を試してみたところ、10分程度で簡単に試行することができました。これを機会にConfigの様々な使い方を調べていきたいと思います。

Amazon CloudWatch アラームで複数アラームの組み合わせが可能に!

$
0
0

こんにちは、技術1課の小倉です。
2020/3/4にアップデートがあり、Amazon CloudWatch アラームで複数のアラームを組み合わせることが可能になりました!

Amazon CloudWatch で複数のアラームを組み合わせ可能に

例えばEC2でCPU使用率とディスクの読み書きのCloudWatch アラームを設定して、両方ともしきい値を超えたときにSNSからアラートを通知できるようになります。

EC2のCPU使用率を監視している時、CPU使用率が高い状態(使用率が100%で処理できない状態ではなく、95%付近で処理を続けている状態)は、異常な状態ではなく、クラウドから提供されているリソースを有効に使用していると私は考えています。CPU使用率だけで監視をしている場合はしきい値を超えたらアラート通知がきてしまいますが、[CPU使用率] + [別の要素] を組み合わせることで、異常ではないCPU使用率のアラート通知を軽減できる可能性があります。

[別の要素]の具体例として、EC2でWebサーバを稼働させていて、[CPU使用率] + [ネットワーク入力(EC2に入ってくる通信量)]で複数アラートを設定したとします。[ネットワーク入力]はクライアントからのアクセスが多ければ増えてきますので、[CPU使用率] + [ネットワーク入力]でどちらもしきい値を超えていればクライアントからの通信に影響が出る可能性がありますので通知をします。もしこのWebサーバが夜間に日次バッチ処理をしていてCPU使用率が高くなった時は、サーバ単体の処理のため、[ネットワーク入力]のしきい値は超えず、通知はこなくなり不要な通知を減らすことができます。

以下のサイトに記載がありますが、2020/3/10現在、複数アラームのアクションで指定できるのはSNSのみです。

Creating a Composite Alarm (英語サイト)

CloudWatch アラームとは

CloudWatch アラームを説明するためにまずはCloudWatch メトリクスを説明します。
CloudWatch メトリクスとは一定の間隔で取得するシステムのパフォーマンスに関するデータです。例えばEC2のCPU使用率であれば、なにも設定することなくCloudWatch メトリクスのコンソール画面で5分おきのCPU使用率をグラフで確認することができます。

また、EC2はCPU使用率以外にも取得しているデータはあり、他のAWSサービスでは別のデータを取得しています。
参考 : インスタンスメトリクス

CloudWatch アラームは取得したメトリクスにしきい値を設定し、しきい値を超えたら通知などを行うことができる機能です。こちらもEC2のCPU使用率を例であげると、CPU使用率がxx%を超えたらSNSでメール通知をするという設定ができます(画像はCPU使用率が10%を超えたらアラーム状態になる設定)。

設定手順

今回のアップデートでは、CloudWatch アラームの設定条件で複数アラームを組み合わせることが可能になりました。設定手順は以下です。

  • 複数アラームの設定に必要なCloudWatch アラームを2つ作ります(今回はEC2のCPU使用率とネットワーク入力)。

CloudWatchのコンソールから左の[アラーム]をクリックし、[アラームの作成]をクリックします。

メトリクスの条件の指定で[メトリクスの選択]をクリックします。

メトリクスの選択で、[EC2] – [インスタンスタイプ別メトリクス] で対象EC2のCPUUtilizationにチェックを入れて、[メトリクスの選択]をクリックします。

メトリクスと条件の指定の画面で、下にスクロールし、しきい値を入力して[次へ]をクリックします(画像はCPU使用率が10%より大きくなったらアラーム状態にする設定)。

アクションの設定画面で通知の[削除]をクリックして設定を消し、[次へ]をクリックします。

名前と説明の追加の画面で、[アラーム名]と[アラームの説明]を入力して、[次へ]をクリックします。

プレビューと作成の画面で設定内容を確認して、[アラームの作成]をクリックします。

CPU使用率のアラーム作成と同様の手順で、メトリクス [NetworkIn]、しきい値 [50000000]で設定します。
設定後の状態です。

  • 作成した2つアラームを使用して複合アラームの設定をします。

先ほど作成した2つのアラームにチェックを入れ、[複合アラームの作成]をクリックします。

複合アラームの条件を指定の画面で、条件をANDに変更して[次へ]をクリックします。
ANDは、CPU使用率とネットワーク入力の両方がアラーム状態になったら複合アラームもアラーム状態になります。ORだとどちらか1つがアラーム状態であれば、複合アラームはアラーム状態になります。

アクションの設定画面で、通知の設定をします。既存でSNSの設定があれば、[既存のSNSトピックを選択]を選択し、なければ、[新しいトピックの作成]を選択して通知先の設定をします。設定が終わったら、下に画面をスクロールして[次へ]をクリックします。

名前と説明の追加の画面で、[アラーム名]と[アラームの説明]を入力して、[次へ]をクリックします。

プレビューと作成の画面で設定内容を確認して、[複合アラームの作成]をクリックします。

設定後の状態です。

試しにCPU使用率を上げてみます( 負荷をかけるため yes > /dev/null & をEC2上で10回実行)。
CPU使用率はアラーム状態になりましたが、複合アラームはOKのままです。

この状態でさらにネットワーク入力に負荷をかけます(数GBのファイルをEC2にアップロード)。
CPU使用率とネットワーク入力のしきい値を超えたため、複合アラームもアラート状態になりました。

アクションで設定した宛先にもメールが届いています。

まとめ

複数のアラームを組み合わせることで、不要なアラート通知を減らすことができるかもしれません。現在CloudWatch アラームを使っている方、これからCloudWatch アラームを使い始める方は複数アラームの導入を検討してみてはいかがでしょうか。

また、本ブログの内容は2020/3/11(水) 12:00よりYouTube Liveで配信される「30分でわかる AWS UPDATE!」でも取り上げる予定ですので、ぜひご覧ください!

Amazon DynamoDB 用 NoSQL Workbench が GA されました

$
0
0

はじめに

こんにちは、技術一課の山中です。
春ですね、春です。

NoSQL Workbench とは

NoSQL Workbench は AWS から提供されている DynamoDB のためのツールで、macOS 及び Windows で利用可能です。
先日までプレビュー版として提供されていましたが、先日 GA されました!!

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/workbench.html

このツールでデータの可視化や追加、更新等ができる他、データモデリングやクエリ開発等が行えます。
本ブログではデータモデリング部分をご紹介したかったのですが、内容が重くなってきたので、インストールしてクエリを発行するところまでやってみたいと思います。

事前準備

ダウンロード

まずは、 NoSQL Workbench をダウンロードします。 macOS と Windows 用のリンクがあるので、注意してください。
今回は macOS 版をダウンロードしました。

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/workbench.settingup.html

試してみる

NoSQL Workbench を開き早速使ってみましょう!

アプリケーションを開くと以下のような画面がでてきます。
デフォルトで、 AWS が提供するサンプルデータが用意されているようです。

バージョンを確認すると、 1.0.0 となっていました。

今回はお試しなので、 Operation builder を開いてみます。
開くと、ローカル PC で設定している AWS のクレデンシャル情報がでてきました。

~/.aws/config の情報を持ってきているようです。
利用したいクレデンシャルカードで Open をクリックすると、その権限で参照可能な DynamoDB テーブルを表示してくれます。

試しに、一つテーブルを選択してみましょう。
テーブル名を選択すると、格納されているアイテムが表示されました。

右上の Build operations から Query を選びます。

Partition key や Sort key の範囲指定などプライマリーキーに対する条件指定や、各種細かい指定ができます。
Execute を選択するとクエリが実行されます。

また、 Generate code を選択するとクエリのコードが生成されます。
これは便利!

以下は生成された Python のコードです。

# Before running the code below, please follow these steps to setup your workspace if you have not
# set it up already:
#
# 1. Setup credentials for DynamoDB access. One of the ways to setup credentials is to add them to
#    ~/.aws/credentials file (C:\Users\USER_NAME\.aws\credentials file for Windows users) in
#    following format:
#
#    [<profile_name>]
#    aws_access_key_id = YOUR_ACCESS_KEY_ID
#    aws_secret_access_key = YOUR_SECRET_ACCESS_KEY
#
#    If <profile_name> is specified as "default" then AWS SDKs and CLI will be able to read the credentials
#    without any additional configuration. But if a different profile name is used then it needs to be
#    specified while initializing DynamoDB client via AWS SDKs or while configuring AWS CLI.
#    Please refer following guide for more details on credential configuration:
#    https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html#configuration
#
# 2. Install the latest Boto 3 release via pip:
#
#    pip install boto3
#
#    Please refer following guide for more details on Boto 3 installation:
#    https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html#installation
#    Please note that you may need to follow additional setup steps for using Boto 3 from an IDE. Refer
#    your IDE's documentation if you run into issues.


# Load the AWS SDK for Python
import boto3
from botocore.exceptions import ClientError

ERROR_HELP_STRINGS = {
    # Common Errors
    'InternalServerError': 'Internal Server Error, generally safe to retry with exponential back-off',
    'ProvisionedThroughputExceededException': 'Request rate is too high. If you\'re using a custom retry strategy make sure to retry with exponential back-off.' +
                                              'Otherwise consider reducing frequency of requests or increasing provisioned capacity for your table or secondary index',
    'ResourceNotFoundException': 'One of the tables was not found, verify table exists before retrying',
    'ServiceUnavailable': 'Had trouble reaching DynamoDB. generally safe to retry with exponential back-off',
    'ThrottlingException': 'Request denied due to throttling, generally safe to retry with exponential back-off',
    'UnrecognizedClientException': 'The request signature is incorrect most likely due to an invalid AWS access key ID or secret key, fix before retrying',
    'ValidationException': 'The input fails to satisfy the constraints specified by DynamoDB, fix input before retrying',
    'RequestLimitExceeded': 'Throughput exceeds the current throughput limit for your account, increase account level throughput before retrying',
}

# Use the following function instead when using DynamoDB Local
#def create_dynamodb_client(region):
#    return boto3.client("dynamodb", region_name="localhost", endpoint_url="http://localhost:8000", aws_access_key_id="access_key_id", aws_secret_access_key="secret_access_key")

def create_dynamodb_client(region="us-east-1"):
    return boto3.client("dynamodb", region_name=region)


def create_query_input():
    return {
        "TableName": "CustomerAndOrders",
        "KeyConditionExpression": "#b3f70 = :b3f70",
        "FilterExpression": "#b3f71 = :b3f71",
        "ExpressionAttributeNames": {"#b3f70":"customerId","#b3f71":"deliveryAddress"},
        "ExpressionAttributeValues": {":b3f70": {"S":"123"},":b3f71": {"S":"there"}}
    }


def execute_query(dynamodb_client, input):
    try:
        response = dynamodb_client.query(**input)
        print("Query successful.")
        # Handle response
    except ClientError as error:
        handle_error(error)
    except BaseException as error:
        print("Unknown error while querying: " + error.response['Error']['Message'])


def handle_error(error):
    error_code = error.response['Error']['Code']
    error_message = error.response['Error']['Message']

    error_help_string = ERROR_HELP_STRINGS[error_code]

    print('[{error_code}] {help_string}. Error message: {error_message}'
          .format(error_code=error_code,
                  help_string=error_help_string,
                  error_message=error_message))


def main():
    # Create the DynamoDB Client with the region you want
    dynamodb_client = create_dynamodb_client(region="eu-west-1")

    # Create the dictionary containing arguments for query call
    query_input = create_query_input()

    # Call DynamoDB's query API
    execute_query(dynamodb_client, query_input)


if __name__ == "__main__":
    main()

おわりに

いかがだったでしょうか?
今回は少しだけ触ってみたのですが、結構簡単に使うことができました。
今度はデータモデリング等をこれでやってみたいとおもいます!

また、本ブログの内容は 2020/3/11 (水) 12:00 より YouTube Live で配信される「30分でわかる AWS UPDATE!」でも取り上げる予定ですので、ぜひご覧ください!

参考

AWS WAFのAWSマネージドルールに匿名IPリストが追加になりました!

$
0
0

こんにちは、技術1課の小倉です。
2020/3/6にアップデートがあり、AWS WAFのAWSマネージドルールに匿名IPリストが追加になりました!

AWS マネージドルールの匿名 IP リストが AWS WAF に追加

匿名IPリストには、接続元情報を匿名化するサービスからのリクエストをブロックするルールが含まれています。そのルールのなかにはVPN匿名プロキシサーバTorノード(接続元を匿名化する仕組みの一つ)、ホスティングプロバイダーのような匿名ネットワーク(接続元を匿名化)からのリクエストをブロックするルールも含まれています。以下はブロック可能な例です。

  • CloudFrontやWAFで地域制限をかけているサービスに対して、接続が許可されていない地域から接続が許可された地域の匿名プロキシサーバを経由した通信をブロック
  • 匿名ネットワークの背後にあるボットから発信される悪意のあるトラフィックをブロック

また、匿名IPリストは無料で利用できます。

AWS WAFとは

WAF(Web Application Firewall)は、Webアプリケーションへの攻撃を検知・防御するセキュリティ対策ができます。例えばSQLインジェクションなど既知の脆弱性を狙った通信からシステムを守ることができます。AWS WAFは防御したい内容をルールとして追加して管理することができます。本アップデートはこの追加できるルールにAWSが管理しているルールがあるのですが、そのルールの種類が増えたという内容です。

ただ、WAFを導入してもAWS内の環境を完璧に守ってくれるわけではありません。あくまで攻撃によるリスクを低減する対策です。ですから、AWS内でもセキュリティ対策は必要です。

設定手順

事前準備として、ALBとEC2(Webサーバ)は構築済みの状態です。
WAF & Shieldのコンソールを開いて、左の[Web ACLs]をクリックし、リージョンを使用するリージョンに変更(画像は東京リージョン)して、[Create web ACL]をクリックします。

Describe web ACL and associate it to AWS resourcesの画面で、[Name]、[]を入力し、[Resource type]は今回はALBを使うので、Regional resources (Application Load Balancer and API Gateway)を選択します。

下にスクロールして、[Add AWS resources]をクリックします。

[Application Load Balancer]を選択し、構築済みのALBにチェックを入れ、[Add]をクリックします。
画面が戻りますので、[Next]をクリックします。

Add rules and rule groupsの画面で、[Add rules] – [Add managed rule groups]をクリックします。

Add managed rule groups画面で、[Add managed rule groups]の横にある▼をクリックして広げます。
Ruleの一覧から[Anonymous IP list]のAdd to web ACLをクリックします。
※ブロックせずに通信を確認したい場合は、[Set rules action to count]をクリックします。誤検知がないかどうかを確認できます。

下にスクロールして、[Add rules]をクリックします。

Rulesに匿名IPリストのルールが追加されたことを確認して、[Next]をクリックします。

Set rule priorityの画面は今回はなにも変更せず、[Next]をクリックします。

Configure metricsの画面は今回はなにも変更せず、[Next]をクリックします。

Review and create web ACLの画面で内容を確認して、下にスクロールして[Create web ACL]をクリックします。

設定できました。

ここからは匿名IPリストの動作確認です。
この状態でなにもせずにブラウザからALBのDNS名にアクセスすると、Webサイトにアクセスできます。

会社のVPNサーバに接続した後に同じアクセスをするとWebサイトへのアクセスが拒否されます。

WAFのコンソールのログを確認するとBlockのログが出力されています。
WAF & Shieldのコンソールを開いて、左の[Web ACLs]をクリックし、作成したweb ACLsをクリックします。

Overviewタブを選択して、下にスクロールします。

SourceIPは公開できないのですが、ActionがBLOCKと表示されているところはVPN経由でWebサイトにアクセスしたログです。

余談ですが、この設定をしたまま数時間放置していたらいろんなところからアクセスがきていて、BLOCKのログが増えていました。おそらくボットだとは思うのですが、短時間で知らないところからのアクセスがあったので、この匿名IPリストの必要性を感じました。

まとめ

AWS WAFにて匿名IPリスト設定が可能になりました。設定して短時間で接続元が不明な通信がいくつかきていましたので、匿名IPリストの設定が有効に働くケースはあります。接続元が不明な通信を防ぎたいという要件がありましたら、設定をご検討してみてはいかがでしょうか。

また、本ブログの内容は2020/3/11(水) 12:00よりYouTube Liveで配信される「30分でわかる AWS UPDATE!」でも取り上げる予定ですので、ぜひご覧ください!

Amazon Connect の一部料金が秒単位課金になりました!

$
0
0

はじめに

こんにちは、技術 1 課の山中です。
春ですね。早くお花見したいですよね。

というわけで、この度 Amazon Connect の一部料金が秒単位課金になりましたので、ご紹介します!!!

Amazon Connect が 1 秒あたりの料金で課金することを発表、テレフォニーのコストを最大 5% 節約

Amazon Connect とは

そもそも Amazon Connect とは、については弊社ブログをご参照ください。

http://blog.serverworks.co.jp/tech/tag/amazon-connect/

なにが変わったの?

今回のアップデートに伴い、これまでの分単位での課金から、 料金ページ の以下項目が秒単位課金の対象となりました。

  • 音声使用: 1 分あたり 0.018 USD
  • 1 分あたりの受信通話の使用 (USD)
  • 1 分あたりの発信通話 (USD)

音声使用の料金については、最初の 10 秒間が経過して以降の利用に対して秒単位の課金となります。
また、テレフォニー料金 (受信および発信通話料金) は最初の 1 分間が経過した後の料金が秒単位課金となります。

たとえば

日本からの直通ダイアルにて、受信および発信を東京リージョンの Amazon Connect にて行った場合の音声使用とテレフォニー料金を試算してみましょう。

2 分 30 秒の受信通話を行った場合

1.音声使用

音声使用の秒単位の料金は 0.018 USD ÷ 60 秒 = 0.0003 USD/秒 なので、

0.0003 USD/秒 × 150 秒 = 0.045 USD

2.受信通話の使用

東京リージョンでの受信通話の料金は 0.003 USD/分 なので、秒単位の料金は 0.003 USD ÷ 60 秒 = 0.00005 USD/秒 となり、

0.00005 USD/秒 × 150 秒 = 0.0075 USD

3.合計金額

0.0525 USD の料金が発生します。

0.045 USD + 0.0075 USD = 0.0525 USD

秒単位課金の前は、 0.0630 USD なので、 16 % くらい安くなっていますね。

0.018 USD/分 × 3 分 + 0.003 USD/分 × 3 分 = 0.0630 USD

6 秒の発信通話を行った場合

1.音声使用

音声使用は 最初の 10 秒間が経過して 以降の料金という条件があるため 6 秒でも 10 秒分の料金がかかります。

0.0003 USD/秒 × 10 秒 = 0.003 USD

2.発信通話の使用

東京リージョンでの発信通話の料金は発信先が日本であれば 0.1000 USD/分 なので、秒単位の料金は 0.1000 USD ÷ 60 秒 = 0.001666667 USD/秒 となり、

0.001666667 USD/秒 × 6 秒 = 0.010000002 USD

3.合計金額

0.013000002 USD の料金が発生します。

0.003 USD + 0.010000002 USD = 0.013000002 USD

秒単位課金の前は、 0.118 USD なので、 88 % も安くなっていますね。

0.018 USD/分 × 1 分 + 0.1000 USD/分 × 1 分 = 0.118 USD

注意点

料金ページ のとおり、受信・発信料金とは別に、 1 日あたりの電話番号に対する料金は変わらずかかりますのでご注意ください。

おわりに

いかがだったでしょうか。
Amazon Connect にも秒単位課金が導入され、より低コストでコールセンターを構築できるようになりました。
Amazon Connect には弊社も力を入れておりますので、ぜひお問い合わせください!!

https://www.serverworks.co.jp/services/amazon_connect.html

また、本ブログの内容は2020/3/5(木) の YouTube Live でも軽く触れておりますので、ご覧ください。


AWS Certified Database – Specialty (AWS 認定データベース – 専門知識)に合格しました

$
0
0

SRE2課 佐竹です。

AWS Certified Database – Specialty 合格しました。最速合格のうちの1人なれて光栄です。

はじめに

本日は「AWS Certified Database – Specialty」について記載します。

AWS Certified Database – Specialty は、AWSの12個目の資格試験です。この資格試験ですが、「ベータ期間 (予定) 2019 年 12 月 2 日〜2020 年 1 月 10 日」というベータ期間がありました。「こちら」に過去掲載されていましたが、この情報は既に削除されています。この期間中は以下の制限の元受験可能です。

  1. 試験は言語「英語」のみ
  2. サンプル問題 も  Practice Exams もなし
  3. 合格結果は約2か月後に送付される
  4. Betaで合格した場合、本試験の申し込み日と同時に合格となる(資格は申し込み開始日から3年間有効)
  5. Beta期間では受験用は「半額」になる
  6. 試験時間はGA版よりも問題数が多く長い。具体的にはBeta版は230分で85問でした

というものです。私は2020年1月10日にこの試験を英語で受験しました。以下その時の記憶と現時点の情報を記載します。

AWS Certified Database – Specialty(Beta)の準備

サンプルもなかったので、正直ほとんど勉強をしていないのですが、以下はプラスに働いたと考えています。
※言い訳:2020年1月13日にネットワークスペシャリティを受験する予定があったのでそっちが忙しかった

試験ガイド(英語)を読む

以下、当時のBeta版のものをテキストでメモしていました。これをみて「Workload-Specific Database Design」の26%はかなり重たいと思ったことを覚えています。

Domain 1: Workload-Specific Database Design 26%
Domain 2: Deployment and Migration 20%
Domain 3: Management and Operations 18%
Domain 4: Monitoring and Troubleshooting 18%
Domain 5: Database Security 18%
 
Domain 1: Workload-Specific Database Design
1.1 Select appropriate database services for specific types of data and workloads
1.2 Determine strategies for disaster recovery and high availability
1.3 Design database solutions for performance, compliance, and scalability
1.4 Compare the costs of database solutions
 
Domain 2: Deployment and Migration
2.1 Automate database solution deployments
2.2 Determine data preparation and migration strategies
2.3 Execute and validate data migration
 
Domain 3: Management and Operations
3.1 Determine maintenance tasks and processes
3.2 Determine backup and restore strategies
3.3 Manage the operational environment of a database solution
 
Domain 4: Monitoring and Troubleshooting
4.1 Determine monitoring and alerting strategies
4.2 Troubleshoot and resolve common database issues
4.3 Optimize database performance
 
Domain 5: Database Security
5.1 Encrypt data at rest and in transit
5.2 Evaluate auditing solutions
5.3 Determine access control and authentication mechanisms
5.4 Recognize potential security vulnerabilities within database solutions
これは、現在の「試験ガイド」でも特に変更がないようです。

参考にした資料

以下を見たくらいです。

あとは途中で読むのをやめてしまいましたが、「RDB技術者のためのNoSQLガイド」を自腹で購入して少し読みました。以下にリンクを紹介しておきます。これはRDBしか知らない私のような人がNoSQL(と言われるDB群)について概要を知るにはとてもよかったです。

参考になった資格試験

正直なところ、以下の2つをしっかり勉強していることでこの資格試験はかなり楽になります。

  1. AWS 認定セキュリティ – 専門知識
  2. AWS 認定ビッグデータ – 専門知識

この2つを受けることで、セキュリティ面の基礎知識を得つつ、またどのようなものが「RDSに向いていないか」、また反対に「データベース(RDS)の活躍の場所はここだ」ということがわかります。これから「AWS 認定データベース – 専門知識」を受けたいと考えられている方は先にこの2つをクリアされることをお勧めします。特に「AWS 認定セキュリティ – 専門知識」だけでも受けてください。

参考になった経験

最も参考になったのは、結局自分の過去の経験でした。RDSの運用はAurora含めて5年以上あります。また、以下のブログを記載してきました。これらを記載してきたことで脳内に記憶がうまく定着してくれたようでした。

この5年間、RDSの公式ドキュメントを追いかけたことは数知れずで試験中も「あーこれかー」ということが何回もありました。

試験に登場したAWSのサービス

以下のサービスが登場した記憶があります。上に行くほどよく出てくると思ってもらって問題ありません。

RDS with MySQL, PostgreSQL, Oracle and SQL Server
Aurora both PostgreSQL and MySQL interfaces (and Server-less)
DynamoDB (and global tables)
CloudFormation
DMS
AWS Schema Conversion Tool
Elasticache Redis
KMS
Amazon Neptune
Amazon DocumentDB

これから受験する方へ

現在は、「サンプル問題」もありますし、「Practice Exams(模擬試験)」も準備されています。言語も日本語が選べます。「AWSの認定試験に合格すると貰える特典を有効活用しよう」にも記載していますが「模擬試験」は資格を1つでも持っていたら無料で購入できます。この2つを受けた結果を反芻することで、RDSの経験が長い人は比較的容易に合格点をクリアできると思います。

反省

私が自分で思った弱点を以下に記載します。

RDSとAuroraは実務でかなり触っていますが細かいところがわかっていないと気づけました。例えばKMSによる暗号化やクロスリージョンの対応などはまだまだ自身が甘いと思いました。他にもAuditの対応などは実務でなかなかやらないため、勉強の必要アリと感じました。クロスリージョンも経験が乏しいですし、Aurora Serverless は実は触ったことすらありません。
DynamoDBとElastiCacheも実務ではまったく触ることがないため、ここもウィークポイントでした。CloudFormationを使ったDeployはRDSでは経験が薄すぎました。

DMSとSCTは使わないまでもお客様への提案は複数していたためになんとなくわかっていた感じです。前職で、DumpのDB移行ばっかりやっていたので、ある程度移行は経験値がありました。

英語の問題ってどう?

英語は、私はまずTOEICが700点くらいなのでそんなに得意ではないです。ただし、日々RDSのAWS公式ドキュメントを探すときに英語で探すという癖がついているので、おおよその英単語がなんとなくわかってしまうという状態でした。それが幸いとなり受かっただけで、全然知らない経験のないフィールドで英語で解けと言われると単語がわからなくて困ると思います。
あとは、230分(実際は220分で10分は説明やアンケート調査の時間となっています)で85問の英語を解くというのが凄まじく根気のいる作業でして、これが耐えられるかどうかが1つのポイントかと思いました。

最後に

Beta試験に合格すると、取得日が受験日まで巻き戻ります。なので今回2020年1月10日になっていました。

ですが、以下の通り有効期限は試験がGAした3月10日から3年間となっておりました。安心ですね。

最後に、これで取得したAWSの資格試験は10個となりました。あと2個の取得を頑張りたいのですが「機械学習」も「Alexaスキルビルダー」もクリアする必要があるのかちょっとだけ悩んでいます。

このブログがお役に立てば幸いです。

【Amplify】Amplify Console に CLI のインターフェースが追加されました!

$
0
0

こんにちは、技術1課の加藤です。

Amplify 使ってますか?
とっても便利な Amplify ですが、ついに Amplify Console と Amplify CLI の紐付けがされたみたいです。

早速ご紹介していきます!

AWS Amplify とは?

雑に書くと、AWS が提供する OSS の開発プラットフォームです。
モバイルアプリケーションおよびWebアプリケーションを構築するために必要なツール群を総称したもので、具体的には、

  • iOS, Android, Webアプリと統合するためのライブラリ
  • UIコンポーネント
  • コマンドラインインターフェース ( Amplify CLI )

を提供しています。

Amplify Console とは?

一方 AWS Amplify Console というのは、サーバーレスウェブアプリケーションのデプロイ・ホストをするための AWS サービスのひとつです。

Git のブランチを指定し、環境名などを設定するだけで、簡単に継続的デプロイ環境を構築、ホスティングまで行ってくれます。

Basic認証の機能やリダイレクト設定、デプロイ時のメール通知などの機能も標準で搭載されているため、静的サイトのホスティングに非常に便利です。

Amplify Console に CLI のインターフェースが追加された #とは

前述の通り、 AWS Amplify には CLIツールがあります。
数回のコマンドを叩くだけで簡単にAPIや認証機構を作成できる超絶便利なものですが、元々 Amplify Console とは統合されていませんでした。

つまり今までは Amplify CLI を用いてAPIや認証機構を実装し、
別途 Amplify Console を使って継続的デプロイの構築やフロントエンドのホスティングを行う必要があったわけです。

今回のアップデートでは、CLIの amplify add hosting コマンドに、新しく Hosting with Amplify Console という選択肢が増えます。

これにより、あらゆる設定を CLI を通して行うことができるようになった、というわけです。

使い方

簡単なハンズオンを用意したのでぜひ触ってみてください。
なお試す際には以下のコマンドで Amplify の最新版をインストールしておいてください。

$ npm install -g @aws-amplify/cli

(※ ぼくの環境では、yarnを利用してglobalインストールするとうまく動きませんでした。まだ細かな検証はできていないのですが、同様のnpm でインストールする方が確実かもしれません。)

またフロントエンドにVue.jsを用いますので、Vue CLIをインストールしておいていただけるとスムーズです。

$ npm install -g @vue/cli
or
$ yarn global add @vue/cli

1. Vueプロジェクトを作成する

今回は sabatest という名前で環境を作成してみます。
途中で設定を聞かれますが、defaultのまま Enter を押してください。

$ vue create sabatest
Vue CLI v4.2.3
? Please pick a preset: (Use arrow keys)
❯ default (babel, eslint) // Enter
Manually select features
$ cd sabatest

2. Amplify の設定を行う

初めて Amplify CLI を利用する場合、 Amplify で使用する IAM ユーザーの作成などを以下のコマンドで行います。

$ amplify configure

指示に従い、設定を完了してください。

3. Amplify プロジェクトを初期化

Amplify プロジェクトを作成します

基本的にはデフォルト設定で Enter を押し続ければ OK です。
途中、環境名 (a name for the environment)を聞かれる箇所がありますので、そちらだけ任意の値を入力しておいてください (今回はdevで進めます)

$ amplify init
? Enter a name for the project sabatest
? Enter a name for the environment dev
? Choose your default editor: Vim (via Terminal, Mac OS only)
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using vue
? Source Directory Path: src
? Distribution Directory Path: dist
? Build Command: npm run-script build
? Start Command: npm run-script serve
Using default provider awscloudformation

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html

? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use default

 

4. Amplify Console を用いたホスティング設定を追加

ここからアプリケーションをホスティングする設定を CLI から追加してみます。

今回追加された Amplify Console を用いたデプロイには、2つの種類があります。

  1. Continuous deployment (Git-based deployments)
  2. Manual deployment

1は Git ベースの継続的デプロイ環境を作成する選択肢です。つまり変更が指定したブランチに Push されると自動的にデプロイが走るようになる、ということです。

一方2は手動デプロイとなりますので、CLIから明示的にコマンドを打つことによってデプロイを行います。Gitリポジトリにコードをあげていない場合や継続的デプロイまではいらないかな、というときはこちらを選択してあげてください。

今回はお試しですので、ひとまず手動デプロイを試してみましょう。

amplify add hosting コマンドでホスティング設定を追加します。

$ amplify add hosting
? Select the plugin module to execute Hosting with Amplify Console (Managed host
ing with custom domains, Continuous deployment)
? Choose a type Manual deployment

You can now publish your app using the following command:

Command: amplify publish

設定ができたら、以下のコマンドでデプロイしましょう。
途中本当に続けるの? と聞かれるので優しく Enter を押してあげてください。

$ amplify publish
... (中略)...
✔ Zipping artifacts completed.
✔ Deployment complete!
https://dev.xxxxxxxxxx.amplifyapp.com

これでホスティングが完了します。
最終行に表示された URL にアクセスしてみましょう。Vue の初期ページが表示されていれば成功です。

 

簡単ですね。

おまけ

ちなみに手動デプロイではなく継続的デプロイを選択すると、実は Amplify Console のコンソール画面がブラウザで開かれます。
Gitリポジトリサービスの認証作業などが必要になるので、そこは CLI に閉じられなかった様子。ちょこっとおしいですねー。

IAM ユーザー作成もコンソール使って行いますし CLI に全部完結、とはなかなかいかなそうですね。

さいごに

Amplify CLI から簡単に Amplify Console を利用できるようになりました。
これにより CLI ツールを使って、バックエンドの設定からホスティングまでまるっと行うことができるようになりました。進化が止まりませんね。

今回のブログの内容は、3/11にYouTubeにて配信した AWS UPDATE でも紹介しております!
リンクを貼っておきますので、ぜひご覧ください!

【YouTube配信】「30分でわかる AWS UPDATE!」第2回を配信しました!

AWS Lambdaで不要なCloudWatch Logsのログストリームを削除する

$
0
0

はじめに

はじめまして、技術4課の水垣です。サーバーワークスに転職して、早くも半年が過ぎました。
AWS&アプリケーション開発をガリガリと進めていけるように、もっと力をつけないとです。

今日は、カラになったCloudWatch Logsのログストリームを定期的に自動削除する仕組みを作っていきたいと思います。
ロググループに「次の期間経過後にイベントを失効」(保持設定)をしているけど、ログストリームが日にち単位で作成されていて、空のログストリームが残り続けているような環境に有効かなと思います。

動作確認はしていますが、適用する際には自身でも事前に検証をお願いします。

Amazon CloudWatch Logsの概念

AWSの公式サイトで、CloudWath Logsの用語と概念がまとめられていますので、サクッと目を通しておくと後が楽です。基本大事。

Amazon CloudWatch Logs の概念

何をしたいか

  • CloudWatch Logsにはログの保持設定機能があり、保持期間を過ぎたログは自動的に削除される
  • ただし、この削除対象となるのはログストリーム内のログイベントのみ(ログストリームは削除されない)
  • ログストリームが日にち単位等で作成されるような場合、中のログイベントは保持設定により削除されるが、ログストリームは空でも残り続ける
  • 邪魔なので、この保持期間が過ぎたログストリームを定期的に自動で削除したい

どんな仕掛けでやるか

  • 専用のサーバーは用意したくない → 起動した分だけの課金がいい → サーバーレス → AWS Lambda
  • 削除は定期的に自動でしたい → スケジュール実行で上のLambdaを発火させたい → Amazon CloudWatch Events
    構成図

削除対象のログストリームを何で判断するか

  • ひとまず、取得できるログストリームの情報を実際に確認してみる
  • サクッと確認したいので、describe系のAWS CLIコマンドを探す(Python環境があるならPythonで確認もあり)
  • describe-log-streams を使って、ログストリームの情報を見てみる

$ aws logs describe-log-streams --log-group-name /aws/connect/one-lambda
{
    "logStreams": [
        {
            "logStreamName": "2020/02/25/09/stream-NpuEk_WgdNW5aqsYYF7DqA==",
            "creationTime": 1582622638973,
            "firstEventTimestamp": 1582622633017,
            "lastEventTimestamp": 1582622656471,
            "lastIngestionTime": 1582622663900,
            "uploadSequenceToken": "49602288682431489398299098678286773935908565265655327074",
            "arn": "arn:aws:logs:ap-northeast-1:<アカウントID>:log-group:/aws/connect/one-lambda:log-stream:2020/02/25/09/stream-NpuEk_WgdNW5aqsYYF7DqA==",
            "storedBytes": 2107
        },
... 上のオブジェクトを1つのログストリーム情報として、/aws/connect/one-lambdaロググループ内のログストリームがリストで出力される
    ]
}

  • 名前から推測すると、lastEventTimestamp lastIngestionTime が使えそう
    • 最後の出力 < 保持期限の日時(例えば今日より3日前とか)
  • describe-log-streams の公式ページを参照してみる
    • https://docs.aws.amazon.com/cli/latest/reference/logs/describe-log-streams.html
    • Outputの項目で、lastEventTimestamp lastIngestionTime を確認
    • lastEventTimestamp
      • 最新のログイベントの時刻。 1970年1月1日00:00:00 UTCからのミリ秒数。 取り込みから1時間以内に更新されるが、まれな状況では時間がかかる場合がある。
    • lastIngestionTime
      • 1970年1月1日00:00:00 UTCからのミリ秒数で表される取り込み時間。
    • 今回は最新のログイベント時刻 lastEventTimestampでやってみる

ログストリームの削除

Lambda

Lambda関数を作成していきます。基本設定は以下のようにしました。

  • Python 3.8
  • Lambdaロール
    • デフォルトで作成されるロールを使用
    • IAMロールの画面から、CloudWatchLogsFullAccessを追加でアタッチする
  • 環境変数
    • LOG_GROUP_NAME:削除対象のロググループ名(例:/aws/connect/input-wav)
    • RETENTION_PERIOD:保持期間(例:10)
  • タイムアウト・CPU
    • 削除する件数が多い場合は、CPUとタイムアウトを上げて調整する

import datetime
import os
import time
import logging

import boto3


LOG_GROUP_NAME = os.environ.get('LOG_GROUP_NAME')
RETENTION_PERIOD = os.environ.get('RETENTION_PERIOD')   # 保持期間

logger = logging.getLogger()
logger.setLevel(logging.INFO)

logs = boto3.client('logs')


def lambda_handler(event, context):
    # 削除基準日 = Lambdaが起動した日 - 保持期間
    # 起動日の前日を1世代として保持期間(世代)より前を削除
    # 保持期間:3 ・ 起動日:2020/3/6 ・ 削除基準日:2020/3/3 ・ 削除:2020/3/2から前

    logger.info('【Start】Logstream-Cleaner Cleaning')

    # 起動日の00:00:00のdatetimeインスタンスを作成
    startup_date = datetime.datetime.today().replace(
        hour=0, minute=0, second=0, microsecond=0
    )
    deletion_date = startup_date - \
        datetime.timedelta(days=int(RETENTION_PERIOD))
    logger.info('削除基準日:%s', deletion_date)

    # Unixタイムスタンプに変換(lastEventTimestamp形式に合わせてミリ秒3桁までの整数化)
    global deletion_timestamp
    deletion_timestamp = int(deletion_date.timestamp() * 1000)

    # 削除対象のログストリームを取得
    target_streams = find_target_streams(next_token=None)
    logger.info('対象件数:%d', len(target_streams))

    # 削除する
    for stream in target_streams:
        # logger.info('対象:%s', stream['logStreamName'])
        logs.delete_log_stream(
            logGroupName=LOG_GROUP_NAME,
            logStreamName=stream['logStreamName']
        )

    logger.info('【Conmplete】Logstream-Cleaner Cleaning')
    return {
        'statusCode': 200
    }


def find_target_streams(next_token: str) -> list:
    """
    describe_log_streamsを利用して、ログストリームを取得する(Max50/回)。
    取得したログストリームを、lastEventTimestamp < 削除基準日タイムスタンプで対象を抽出。
    自身を再帰呼出しし、nextToken(続き)がある限り処理を継続。

    Parameters
    ----------
    next_token : str
        describe_log_streamsの結果に含まれるnextToken

    Returns
    -------
    target_streams : list
        対象のログストリーム名のリスト

    See Also
    --------
    https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/logs.html#CloudWatchLogs.Client.describe_log_streams
    """
    # 対象を抽出する
    def is_target_stream(stream):
        return stream.get('lastEventTimestamp') < deletion_timestamp

    # describe_log_streamsの制限で1回にMax50。もっとある場合はnextTokenで続きをdescribe
    if next_token is None:
        describe_response = logs.describe_log_streams(
            logGroupName=LOG_GROUP_NAME,
            orderBy='LastEventTime'
        )
    else:
        describe_response = logs.describe_log_streams(
            logGroupName=LOG_GROUP_NAME,
            orderBy='LastEventTime',
            nextToken=next_token
        )

    # describeの結果から対象のログストリームのみ抽出する(filterの戻りはiterator object)
    itr_streams = filter(is_target_stream, describe_response['logStreams'])
    target_streams = list(itr_streams)

    # 続きがないならリターン
    if 'nextToken' not in describe_response:
        return target_streams

    # API制限(1秒間に5トランザクションの回避)
    time.sleep(0.3)

    # nextTokenがあるので、自分を再帰呼出しして、続きから対象を抽出、結果をリストに追加
    target_streams.extend(find_target_streams(describe_response['nextToken']))

    return target_streams


if __name__ == "__main__":
    lambda_handler(object, object)

CloudWatch Events

  • ルール → スケジュールを作成して、定期的にLambdaを発火させたい
  • Cron式で指定できます(記載方法はAWSサイトを確認してください)
  • 今回は、「毎週 月曜日 00:00(JST)」に起動
    • スケジュールの指定は UTC なので、設定は「毎週 日曜日 15:00(UTC)」となります
    • Cron式: 0 15 ? * SUN *
  • ターゲットに作成したLambda関数を指定します
    CloudWatchEvents

おわりに

サクッと作れるかなと思ってましたが、describeで1回で取得できるMax50件が落とし穴でした。
ちょっと頭の中を吐き出しながら書いたので冗長な記述もありますが、やってみると色々と学ぶことが多いですね。
それでは、また。Have a nice Serverless!

Amplify を用いてウェブとネイティブのマルチプラットフォーム対応する

$
0
0

こんにちは、技術1課の加藤です。
最近 Amplify にハマって色々と触ってみているのですが、 Amplify って複数のクライアントプラットフォームに対応しているんですよね。

マルチプラットフォームに対応しているからにはやっぱり複数のプラットフォームでバックエンドを共有したいもの。

というわけで今回は React を使ってウェブアプリとネイティブアプリを作成し、同じ認証情報を使ってログインしてみます。

1. React ウェブアプリ

まずはウェブアプリ + 認証機構の実装を行います。

1-1. React アプリの作成

$ npx create-react-app react-amplify
$ cd react-amplify

一応、ちゃんと動くか確認します。

$ yarn start
or 
$ npm start

以下の画面が開けばOKです。

確認が終わったら Ctrl + C で開発サーバーを止めておきます。

1-2. AWS 接続情報の設定

以下のコマンドで AWS 接続情報の設定をします。
(すでに設定が済んでいる場合はこの手順は省略可能です)

$ amplify configure

1-3. Amplify プロジェクトの作成

$ amplify init
Note: It is recommended to run this command from the root of your app directory
? Enter a name for the project react-amplify
? Enter a name for the environment dev
? Choose your default editor: Vim (via Terminal, Mac OS only)
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using react
? Source Directory Path:  src
? Distribution Directory Path: build
? Build Command:  npm run-script build
? Start Command: npm run-script start
Using default provider  awscloudformation

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html

? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use amplify

1-4. 認証機能のバックエンドリソースを作成

$ amplify add auth
Using service: Cognito, provided by: awscloudformation

 The current configured provider is Amazon Cognito.

 Do you want to use the default authentication and security configuration? Defau
lt configuration
 Warning: you will not be able to edit these selections.
 How do you want users to be able to sign in? Username
 Do you want to configure advanced settings? No, I am done.

設定を確認します。

$ amplify status

Current Environment: dev

| Category | Resource name        | Operation | Provider plugin   |
| -------- | -------------------- | --------- | ----------------- |
| Auth     | reactamplifyxxxxxxxx | Create    | awscloudformation |

大丈夫そうであればデプロイします。

$ amplify push

1-5. フロントエンドのコードに認証機能を実装

簡単に実装します。
まずは必要なライブラリのインストールから。

$ yarn add aws-amplify aws-amplify-react
or
$ npm install aws-amplify aws-amplify-react

src/App.js を開き以下のように編集します。

import React from 'react';
import logo from './logo.svg';
import './App.css';
import Amplify from 'aws-amplify';  // 追加
import awsconfig from './aws-exports';  // 追加
import { withAuthenticator } from 'aws-amplify-react';  // 追加

Amplify.configure(awsconfig);  // 追加

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
      </header>
    </div>
  );
}

export default withAuthenticator(App);  // 編集

1-6. 実装した認証機構を使ってアカウントを作成

ではアカウントを作成してみましょう。 yarn start するとブラウザにログイン画面が表示されます。
[Create account] を選択し、アカウント作成画面に移ります。

必要な情報を入力して [CREATE ACCOUNT] を押下します。
このあと登録したメールアドレスに認証コードが発行されるので、アドレスは普通に使えるものを入力してください。

 

 

Confirmation Code を入力して、 [CONFIRM] を押下してください。
これでアカウントが作成されます。

登録した Username および Password を使ってログインできることを確認してください。

ログインが完了すると、 React の初期ページが表示されます。

2. React Native アプリ

ウェブアプリケーションでの実装が確認できたので、次はReact Native のアプリケーションを作ってみましょう。
今回は Expo を用いて実装します。

2-1. React Native アプリの作成

expo cli を用いてアプリを作成します。以下のコマンドを実行してください。
なお途中テンプレートを聞かれるので、 blank を選んでください。

$ expo init react-native-amplify
$ cd react-native-amplify

こちらもひとまずちゃんと動くか確認します。

$ yarn start
or
$ npm start

こんな画面が出てきます。

ぼくはiOSアプリで動きを確認したいので、 Run on iOS simulator を選び、シミュレータを起動します。
iOS シミュレータを使う方法に関しては Expoのドキュメント を参考にしてください。(Android を試したい方はこちら )

以下のような画面が立ち上がればOKです。

2-2. バックエンドリソースの設定

さて、ここから共通のバックエンドリソースを使う設定を行っていきます。
といっても難しいことはありません。
以下のように、コマンドと数回の選択を行うだけ。余裕。

$ amplify pull

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html

? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use amplify
? Which app are you working on? xxxxxxxxx
Backend environment 'dev' found. Initializing...
? Choose your default editor: Vim (via Terminal, Mac OS only)
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using react-native
? Source Directory Path:  /
? Distribution Directory Path: /
? Build Command:  npm run-script build
? Start Command: npm run-script start

? Do you plan on modifying this backend? Yes

これにより、 amplify ディレクトリ および aws-exports.js ファイルが生成されます。

2-3. フロントエンドのコードに認証機能を実装

必要なライブラリをインストールします。

$ yarn add aws-amplify aws-amplify-react-native
or
$ npm install aws-amplify aws-amplify-react-native

./App.js を開き、以下の通り修正します。

import React from 'react';
import { StyleSheet, Text, View } from 'react-native';
import Amplify from 'aws-amplify';  // 追加
import awsconfig from './aws-exports';  // 追加
import { withAuthenticator } from 'aws-amplify-react-native’;  // 追加

Amplify.configure(awsconfig);  // 追加

function App() {  // 編集
  return (
    <View style={styles.container}>
      <Text>Open up App.js to start working on your app!</Text>
    </View>
  );
}

export default withAuthenticator(App);  // 追加

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

この状態でシミュレータを動かしたら以下のエラーが発生しました。。。

Unable to resolve “@react-native-community/netinfo” from “node_modules/@aws-amplify/core/lib/Util/Reachability.native.js”

@react-native-community/netinfo が必要とのことなので、インストールします。

$ yarn add @react-native-community/netinfo
or
$ npm install @react-native-community/netinfo

改めてシミュレータを動かしたところ、ちゃんと動きました

2-4. ログインしてみる

さて、正しく環境が作れていれば、ここで先ほど作成したユーザーでのログインが可能なはずです。
試してみましょう。

シミュレータを立ち上げると、ログイン画面が表示されます。
ここに先ほど作成したユーザーの Username および Password を入力してみましょう。

ログインして、 React Native の初期ページが表示されれば、完了です。

まとめ

マルチプラットフォームの対応はどうやるんだというのが気になり、今回 React を使ってウェブアプリとネイティブアプリを実装してみました。

簡単ですので、ぜひ試してみてください。

Amazon WorkSpacesのサポート問い合わせに関するTips

$
0
0

こんにちは、CSM課の城です。
この3月から部署移動となりました。
CSMはカスタマーサクセスマネージャーの略になりますが、そんなことより在宅勤務で私のお腹回りが大変ピンチです。
お腹が空いたら何かをつまんでしまう、そこには忍耐の欠片もないので改善していく所存です。

さて、在宅勤務といえばAmazon WorkSpacesが注目されていますが、とても便利で簡単なWorkSpacesと言えども、トラブルがないわけではありません。
そんな時に、どのようにトラブルシューティングやAWSサポートへ問い合わせをする際に何を用意しておくべきかという点について、具体的に紹介していきます。

1.対象のトラブルについて

今回、紹介する内容については、主に次のケースについての内容となります。

  • WorkSpacesに接続できない、または、認証に失敗する
  • WorkSpacesがUnhealthyになる

2.問い合わせ全般について必要なこと

AWSへのサポート問い合わせについては公式にガイドラインが提示されています。
もちろんWorkSpacesの問い合わせについても、こちらのガイドラインに沿って問い合わせをした方がより早く問題を解決出来ると考えていいでしょう。

上記、ガイドラインを踏まえ、事象の内容、及び、対象をお知らせする必要があります。

  • 事象の発生日時、タイムゾーン
  • 事象が収束しているかどうか
    • 事象が収束している場合は収束日時、タイムゾーン
  • 事象の内容
    • エラーメッセージがある場合はエラーメッセージ全文
    • WorkSpacesでエラーや操作不能の状態になっている場合は、そのスクリーンショット画像
    • 事象が収束しているか否か
    • 以前はログインや認証が成功していたかどうか
  • 事象が発生しているWorkSpaceのWorkSpace ID
  • 事象が発生しているWorkSpaceが紐づいているDirectory ID

3.クライアントのログ

WorkSpacesの接続に関するトラブルについては、クライアントの情報が必要となることが多いので、下記の情報はあらかじめ伝えておいた方が良いでしょう。

  • クライアントのOS、及び、バージョン
  • WorkSpacesクライアントのバージョン
  • クライアントのログ

クライアントのログについては、下記に保管されていますので、問い合わせ時に、Zipにするなどして丸ごとアップロードしましょう。
バージョンにより保存場所が異なるので注意が必要です。

【Windows】
[2.5.x]
%LOCALAPPDATA%\Amazon Web Services\Amazon Workspaces\1.0\Logs
%LOCALAPPDATA%\Teradici\PCoIPClient\logs

[3.0.x]
%LOCALAPPDATA%\Amazon Web Services\Amazon WorkSpaces\logs

【Mac】
[2.5.x]
/Users//Library/Logs/Amazon Web Services/Amazon WorkSpaces/1.0

[3.0.x]
/Users//Library/Application Support/Amazon Web Services/Amazon WorkSpaces/logs

4.WorkSpaceに対してリモートデスクトップ接続できる場合はWorkSpaceのログ

WorkSpacesクライアントからログインできない場合でも、リモートデスクトップで接続できる場合があります。
その場合、WorkSpaceにてログを取得し、AWSサポートに共有します。
こちらについてはファイルサイズがサポートケースに添付できる上限を越えるかと思いますので、その旨を伝え、アップローダ―を共有していただきましょう。
リモートデスクトップ接続するにはリモートデスクトップ接続可能なユーザー、例えばDomain Adminsグループに所属するユーザーでアクセスすることが可能です。
また、リモートデスクトップ接続に必要なポート(TCP/UDP 3389)をセキュリティグループで許可しておく必要があります。

WorkSpaceのログ取得方法については、下記となります。

  1. WorkSpace に接続します。
  2. WorkSpace 内で PowerShellを管理者権限で立ち上げます。
    2-1. [Start] をクリックします。
    2-2. 検索ボックスに “powershell”と入力します。
    2-3. 検索結果より “Windows PowerShell” を右クリックし、[管理者として実行] をクリックします。
  3. 以下のコマンドを実行します。
    powershell.exe -NoLogo -ExecutionPolicy ByPass -NoProfile -File “C:\Program Files\Amazon\WorkSpacesConfig\Scripts\Get-WorkSpaceLogs.ps1”
  4. デスクトップに WorkSpaceLogBundle_.zip ファイルが出力されるのを待ちます。

5.最近の変更について

事象が以前から発生していたものではなく、最近発生したものである場合、なにかしら変更をしていないかということを確認すると原因が判明することがあります。
例えばですが、私は以前、AD Connectorに登録しているサービスアカウントのパスワード変更によってWorkSpacesにログインできなくなってしまったことがありました。
トラブルの際は、何か直近で変更をかけていないか確認してみましょう。

さいごに

Amazon WorkSpacesはリモートワークを導入するには、サイジングを厳密に行う必要がなかったり、従量課金であったりと、メリットの多いマネージドサービスです。
ただし、運用するにあたってはトラブルが全くないわけではないので、どう対応すべきかを把握しつつ運用することが重要かと思います。

ではでは。

Viewing all 1210 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>