AWS Cloudwatch Syntheticsを試してみる（Route53との違い）
CloudwatchにSyntheticsの新機能が追加されたので使ってみました。
サイトの死活監視が可能なようで、
Route53のHealthCheckと少し被っているのかと思ったのですが、
Route53よりも、より詳細なリクエストを送ることが可能なようです。
まずはベーシックなハートビートのモニタリングを動かしてみました。
機能概要
ハートビートのモニタリングでは、
指定したURLへのリクエストが成功するかを検証します。
いわゆるサイトの死活監視です。
設定方法
対象のURLをAmazonのサイトにしてみます。
https://www.amazon.co.jp/
URLの欄を入力するとスクリプトに反映されるようです。
こちらで作成し、2~3分ほど待ちます。
作成されると裏側でS3やLambdaが自動生成されるようです。
多分裏ではcloudformation(SAM)が動いているっぽいですね。
実行後のイメージ
実行後に下記アウトプットが取得できました。
HARファイル
ログ
自動生成されたスクリプトが実行された際のログが出力されるようです。
S3へのエビデンス保存
さらに、上記がS3に保存されているため、過去に遡ってスクリーンショットを見ることができます。
aws s3 ls s3://cw-syn-results-xxxxxxx-ap-northeast-1/canary/www-amazon-co-jp-f81-bf25b112823a/successes/2020/05/03/14/05-37-778/ 2020-05-03 23:05:39 1265313 00-loaded-loaded.png 2020-05-03 23:05:39 105985 2020-05-03T14-05-19-265Z-log.txt 2020-05-03 23:05:39 678506 results.har.html
Route53との違い
Route53ヘルスチェックの死活監視との主な違いは下記かと思いました。
Route53のメリット
- 複数拠点から死活監視が可能
- 複数拠点からのリクエスト成功率を統計的に判断材料としている
Syntheticsのデメリット
Syntheticsは単一リージョンのLambdaからの死活監視なので、
例えば対象リージョンのLambdaに障害があった場合が心配です。
死活監視としては信頼性に弱みがあるかと思いました。
AWS clientVPN 分割トンネル(split-tunnel)とは何か
AWS Client_vpnで分割トンネル(split-tunnel)と言う設定項目があったのですが
ドキュメントを読んだだけだと動作がよく分からなかったので調べてみました。
AWS Client VPN エンドポイントの分割トンネル - AWS Client VPN
デフォルトでは、AWS Client VPN エンドポイントがある場合、すべてのクライアントトラフィックは AWS Client VPN トンネル経由でルーティングされます。AWS Client VPN エンドポイントで分割トンネルを有効にすると、AWS Client VPN エンドポイントルートテーブル上のルートが AWS Client VPN に接続されているデバイスにプッシュされます。
構成図
上記構成を例に、有効時、無効時の動きを試してみました。
・ClientVPNで0.0.0.0/0のルーティングを設定済み
・クライアントではインターネットアウト(0.0.0.0/0)のルーティングを持つ
Your PCの部分は、自宅のPCとかだとお考えください。
split-tunnel無効時
下記2つが存在する場合、(1)が優先されます。
上図の構成例では、インターネット(0.0.0.0/0)への経路が重複します。
split-tunnel無効時には(1)が優先され
下記の赤線経路でインターネットへアクセスが行われます。
(1)ClientVPNで設定したルートテーブル
(2)接続クライアントが持つルートテーブル
split-tunnel無効時に、ClientVPNに接続したPCのnetstat結果は下記です。
defaultのルートに上書きして172.25.0.1宛てのルートがあることが分かります。
netstat -r Routing tables Internet: Destination Gateway Flags Netif Expire 0/1 172.25.0.1 UGSc utun2 default 192.168.10.1 UGSc en0
split-tunnel有効時
下記2つが存在する場合、(2)が優先されます。
上図の構成例では、インターネット(0.0.0.0/0)への経路が重複します。
split-tunnel有効時には(2)が優先され
下記の赤線経路でインターネットへアクセスが行われます。
(1)ClientVPNで設定したルートテーブル
(2)接続クライアントが持つルートテーブル
split-tunnel有効時に、ClientVPNに接続したPCのnetstat結果は下記です。
上記と比較し、default（192.168.10.1）となっていることが分かります。
netstat -r Routing tables Internet: Destination Gateway Flags Netif Expire default 192.168.10.1 UGSc en0 172.25/27 172.25.0.2 UGSc utun2
何が良いのか
では、分割トンネル(split-tunnel)を有効化しておく利点は
無駄な通信を発生させずに済むところです。
利用者観点では下記です。
・無駄にAWSのNW利用料が発生しない（低コスト）
・無駄なNetworkを経由しない（速度）
ただ、会社の規約等で通信経路を統一させる必要がある場合や、
ルーティングを強制させたい場合は無効化させておく必要がありそうです。
個人的な考えとしては、特に要件が厳しくなければ有効化させた方が良いと思います。
（初心者向け）AWS ClientVPNを設定してみる
リモートワークがどの会社でも進んでいますね・・・
割と問合せの多いClientVPNを調べてみましたのでブログにまとめてみようと思います。
ClientVPNの概要
clientVPNの概要は下記が分かりやすいと思います。
AWS Client VPN の詳細 - AWS Client VPN
ポイントは下記です。
・End Userがインターネット経由でClientVPNエンドポイントへ接続
・ClientVPNエンドポイントからVPC内のサブネットへアクセス可能
（サブネット内へENIを作成しNAT感覚で利用）
・Subnetと接続のあるリソースを利用可能
（DirectConnect、VPCピアリング等）
・接続を制限するために認証機能がある
認証方式は2つありますが、この記事では相互認証について扱います
詳しくはこちらです。
クライアント認証と認可 - AWS Client VPN
相互認証の設定の流れ
相互認証での設定の流れはざっと下記です。
(1)認証局の構築
(2)証明書（ACM）の設定
(3)ClientVPNのAWS側設定
(4)ClientVPNクライアント設定（インストール）
(5)ClientVPNクライアント側設定
(6)VPN接続
(7)認証局の運用
検証の構成図
今回の検証では下記構成で設定してみました。
目的は、外部インターネットからClientVPNでアクセスし、
VPC内のEC2にローカルIPでアクセスすることです。
(1)認証局の構築と(2)証明書（ACM）の設定
EC2（AmazonLinux2）で認証局を構築します。
こちらの認証局のEC2は上記の構成図には登場しません。
別の場所で構築しても大丈夫です。
https://docs.aws.amazon.com/ja_jp/vpn/latest/clientvpn-admin/authentication-authrization.html
cd ~ sudo yum install git -y git clone https://github.com/OpenVPN/easy-rsa.git cd easy-rsa/easyrsa3 ./easyrsa init-pki ./easyrsa build-ca nopass ./easyrsa build-server-full server nopass ./easyrsa build-client-full client1.domain.tld nopass mkdir acm cp pki/ca.crt acm/ cp pki/issued/server.crt acm/ cp pki/private/server.key acm/ cp pki/issued/client1.domain.tld.crt acm cp pki/private/client1.domain.tld.key acm/ cd acm/ #ここでエラーが出る場合は、EC2へ適切なIAMRoleを付与しているかを確認してみてください。 aws acm import-certificate --certificate file://server.crt --private-key file://server.key --certificate-chain file://ca.crt --region region
ドキュメント内では、クライアント証明書もアップロードしていますが、
クライアント証明書の認証機関 (発行者) がサーバー証明書の認証機関 (発行者) と異なる場合にのみ、
クライアント証明書を ACM にアップロードする必要があります。
そのため、ここではクライアント証明書はアップロードしません。
下記を実行時に、入力が促されますが、なんでも大丈夫です ./easyrsa build-ca nopass Common Name (eg: your user, host, or server name) [Easy-RSA CA]:clientVPN-test
(3)ClientVPNのAWS側設定
ClientVPNを設定します。
ここで、作業前に全体像を整理します。
下記図に示すように、Subnet内のリソースにアクセスさせるために
複数の箇所で設定が必要となります。
(A)ClientVPN エンドポイント作成
まず、ClientVPNエンドポイントを作成します。
構成図で言う、下記の赤字部分です。
AWSの画面で言うと、下記の設定です。
スプリットトンネルは有効化しておきます。
(B) ClinetVPNとSubnetを紐付け
続いて、ClinetVPNとSubnetを紐付け設定します。
図の下記赤字部分です。
紐付けたいVPCとSubnetを入力します。
Subnetを紐付けると、ルートテーブルも自動的に作成されます。
このルートテーブルにより、clientVPNのエリアからSubnetへのルーティングが可能となります。
続いて認証を設定します。
今回はSubnetの通信に送信を許可したいので、
「172.30.5.0/24」を入力します。
(C) セキュリティグループの設定
続いてセキュリティグループの設定をします。
図の下記赤字部分です。
また、接続先のEC2へ、このセキュリティグループ、または
IPアドレスからの接続が許可されている必要があります。
全て設定した後、利用可能状態になるまで待ちます。
私の環境では10分ぐらいかかりました。
(4)ClientVPNクライアント設定（インストール）
AWS側の設定の準備ができたので、次はクライアントの設定です。
AWSが提供するClientをインストールします
https://aws.amazon.com/jp/vpn/client-vpn-download/
(5)ClientVPNクライアント側設定
続いて「クライアント設定のダウンロード」を押下します
「〜.ovpn」のファイルがダウンロードされますのでテキストエディタで開きます。
下記のようになっているかと思います。
client dev tun proto udp remote xxxxxxxxxxxxxxxxxxxxxxxxxxx.prod.clientvpn.ap-northeast-1.amazonaws.com 443 remote-random-hostname resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server cipher AES-256-GCM verb 3 <ca> -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END CERTIFICATE----- </ca> reneg-sec 0
ここに追記していきます。
追記内容は(1)で作成した下記ABの内容です
(A)client1.domain.tld.keyの下記で囲まれた部分
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY——
(B)client1.domain.tld.crtの下記で囲まれた部分
-----BEGIN CERTIFICATE——
-----END CERTIFICATE——
追加後のイメージは下記です。
client dev tun proto udp remote xxxxxxxxxxxxxxxxxxxxxxxxxxx.prod.clientvpn.ap-northeast-1.amazonaws.com 443 remote-random-hostname resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server cipher AES-256-GCM verb 3 <ca> -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END CERTIFICATE----- </ca> reneg-sec 0 <cert> -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END CERTIFICATE----- </cert> <key> -----BEGIN PRIVATE KEY----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END PRIVATE KEY----- </key>
Clinet VPNのアプリを開き、File > ManageProfilesを選択します。
下記はMacでの実行例です。
Add Profileから上記で作成したファイルを選択し、適当な名前をつけます
(6)VPN接続
Connectボタンを押下します
Connectedと表示されれば接続されています。
これで、Subnet内のEC2にローカルIPで直接アクセスできます。
ssh 172.30.5.120 __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ 1 package(s) needed for security, out of 5 available Run "sudo yum update" to apply all updates.
(7)認証局の運用
こちらは繋がった後の運用作業です。
相互認証では、クライアント側も機密データ（証明書）を保持します。
そのためクライアント側で問題が発生した場合には、その対応をする必要があります。
（例えば社員がパソコンを無くしてしまった時、その端末は接続不可となるよう設定すべき、など）
その場合、下記に従い、証明書失効リストを作成し
クライアントVPNエンドポイントにインストールすることで
クライアント証明書を無効化させ、接続を不可とします。
上記の例で言うと、パソコンを無くした社員に配布していたクライアント証明書を無効化させる流れです。
下記にサンプルがあるので実際に試してみます。
https://docs.aws.amazon.com/ja_jp/vpn/latest/clientvpn-admin/cvpn-working-certificates.html
(1)を実施したEC2上でコマンドを実行します。
./easyrsa revoke client1.domain.tld Using SSL: openssl OpenSSL 1.0.2k-fips 26 Jan 2017 Please confirm you wish to revoke the certificate with the following subject: subject= commonName = client1.domain.tld Type the word 'yes' to continue, or any other input to abort. Continue with revocation: yes Using configuration from /home/ec2-user/easy-rsa/easyrsa3/pki/xxxxxxxxxxxxx Revoking Certificate xxxxxxxxxxxxxxxxxxx. Data Base Updated IMPORTANT!!! Revocation was successful. You must run gen-crl and upload a CRL to your infrastructure in order to prevent the revoked cert from being accepted.
CRLファイルを作成
./easyrsa gen-crl Using SSL: openssl OpenSSL 1.0.2k-fips 26 Jan 2017 Using configuration from /home/ec2-user/easy-rsa/easyrsa3/pki/xxxxxxxxxxx An updated CRL has been created. CRL file: /home/ec2-user/easy-rsa/easyrsa3/pki/crl.pem
CRLファイルをインポート
aws ec2 import-client-vpn-client-certificate-revocation-list --client-vpn-endpoint-id xxxxxxxxxx --region ap-northeast-1 --certificate-revocation-list file:///xxxxxxxxxxx/crl.pem { "Return": true }
こちらを実行すると、クライアント証明書が無効化され、接続が不可となります。
AWS WAFv2とWAF classicの違いを簡単にまとめ
AWS WAF がいつの間にかWAF Classicという名前になっている・・・・
そして今のWAFはWAFv2と呼ぶらしいです。
何が違うのか分からなかったので触ってみました。
主な変化点
WCU
WAF v2にはWCUという概念が導入されています。
WCUは遠足のおやつのような概念です。
遠足のおやつは300円までと決まっており、好きなお菓子の組み合わせを値段を見ながら300円に収まるように選びます。
WAFでも、似たようにWebACL1つにつき、1500WCUまでというスコア上限が決まっており、
好きなルールの組み合わせをWCUのスコアを見ながら全体で1500WCUに収まるように選びます。
例：wordpress用のルールグループ：100WCU
AWSの選ぶIPブラックリストルール：25WCU
この1500という値は上限緩和申請により、上乗せが可能ですが、
あまりたくさんのルールは追加できないと思っておいた方が良いです。
基本的には複雑なルールほどWCUが高いです
docs.aws.amazon.com
また自作ルールもWCUが適応されます。目安は下記です。
docs.aws.amazon.com
マネージドルール
マネージドルールという概念が追加されました。
こちらはルールをある程度良かろうという物がまとめられた物です。
以前からも、そのような機能はありましたが、下記が大きく異なります。
マネージドルール中の、ルール別の設定が可能
以前は、ルールの集合を適応するときは、
まとめて適応するかどうかだったのですが、
WAFv2からは、マネージドルールの中の、さらにどのルールを適応・除外するかを選択できます。
より柔軟なルールの記載が可能に
ネストされたルールにより、より柔軟なルールの記載が可能になりました。
ちなみにこちらはAWSコンソールからでは設定が不可のようです。
docs.aws.amazon.com
他にも細かな違いはありますが、主な変化点は上記かと思いました。
また触ってみたらブログ書きたいと思います。
AWS Database Specialityに合格できました
AWS Database Specialityに合格できました。
合格エントリ
下記の合格エントリを参考にさせて頂きました。
自分はベータ版でなく、普通の試験を受けました。
blog.serverworks.co.jp
medium.com
勉強したこと
RDS・Auroraのドキュメントをひたすら読み込みました。
AuroraはBlackbeltも参考にさせて頂きました。
aws.amazon.com
aws.amazon.com
特にホワイトペーパーとかは読まず、
各DBで、トラブルシューティングのページがあるので
試験ガイドの「監視およびトラブルシューティング」の対策として
こちらは特に読み込んで行きました。
結果・感想
結果は800点ぐらいでした。
やはり新しい試験というのは面白いです。
問題が古い試験だとベストプラクティスから外れているものもあり
あまり勉強のしがいがありませんが、
新しい試験だと自分の実力を試されている気がします。
そして、Auroraのアップデートの多さに驚きました。普段いかに自分が使いなせていないかを痛感しました。
Auroraを好きになる試験だと思います。
AWS Certified Machine Learning – Specialtyに合格できました
先日、AWS Certified Machine Learning – Specialtyに合格できました。
勉強方法
まずは模試試験を受け、自分のレベルと、何を学ばないと行けないかを把握しました。
aws.amazon.com
その後、勉強方法について調べました。
こちらがよくまとまっていました。
qiita.com
ただこちら情報量が多く、結局何を勉強するか悩んだのですが、
私の場合、基礎をしっかり学びたい想いがあったので、
模試の結果から併せて考え、下記を中心に勉強しました。
こちらを1冊読みきりました。
www.amazon.co.jp
こちらは前半の半分程度を読みました。
www.amazon.co.jp
こちらは前半の2割程度を読みました。
www.amazon.co.jp
ある程度バランス取りながら上記のオライリーの本を読んでいたところ
試験日も近くなったので、仕上げでSagemakerのドキュメントを読み
本試験を受けてみたら合格できました。
結果は750点が合格ラインで、800点程度でした。
あと私は試験終わってから知ったのですが、
各アルゴリズムの概要を知るのに、下記のyoutubeチャンネルが結構分かりやすかったです。
本を読んでみても分からんという場合、見てみると良いと思います。
www.youtube.com
【EFS Single File Restore】AWS backupとEFSの連携でファイル単位のリストアを試してみる
AWS BackupでEFSとの連携が便利になり、
EFSでのファイル単位のリストアができるようになりました。
機能を使ってみる機会がありましたのでメモ的に書いてみます。
aws.amazon.com
ユースケースとしては、ユーザやシステムが誤ってファイルを消してしまった場合のリカバリが考えられます。
ドキュメントの細かい箇所を読み込んで行くと、
おおよそ下記のメリット/デメリットがあることが分かりました。
デメリット
- 復元に時間（数分程度）がかかる
- 復元の容量に応じて料金が発生する
検証準備
まずは検証の準備です。
EC2にEFSをマウントし、EFS内に適当なファイルを2つ作成します。
ls -lh /mnt/efs/test/bkup/ 合計 8.0K -rw-rw-r-- 1 ec2-user ec2-user 2 1月 28 03:10 1.txt -rw-rw-r-- 1 ec2-user ec2-user 2 1月 28 03:10 2.txt
AWS Backupで、オンデマンドバックアップ(EFS)を取得します
その後、EFS内のファイルを一つ消してみます
rm /mnt/efs/test/bkup/1.txt ls -lh /mnt/efs/test/bkup/ 合計 4.0K -rw-rw-r-- 1 ec2-user ec2-user 2 1月 28 03:10 2.txt
リストア実施
上記で消してしまったファイルをリストアします。
AWS Backupの画面から、ファイルリストアを実行します。
パスはマウントポイントからのパスを記入します。
上記の例は、下記の場合の例です。
マウントポイント「/mnt/efs」
ファイルフルパス「/mnt/efs/test/bkup/1.txt」
指定するパス「/test/bkup/1.txt」
リストアが実行されると復元がジョブとなり、コンソールで確認できます。
ジョブが完了すると、マウントポイント直下に
「マウントポイント/aws-backup-restore_*」の形式で
ファイルがリストアされています。
ls -ld /mnt/efs/aws-backup-restore_* drwxr-xr-x 3 ec2-user ec2-user 6144 1月 28 03:09 /mnt/efs/aws-backup-restore_2020-01-29T09-05-15-134Z drwxr-xr-x 4 ec2-user ec2-user 6144 1月 28 03:09 /mnt/efs/aws-backup-restore_2020-01-29T09-20-26-282Z
ちなみに、バックアップ中に指定したファイルが存在しない場合は、
空のフォルダが作成されていました（ただし復元ジョブは成功の扱い）
ls -lh /mnt/efs/aws-backup-restore_2020-01-29T09-05-15-134Z/ 合計 36K drw--w---- 2 root root 38K 1月 29 09:05 aws-backup-lost+found_2020-01-29T09-05-15-135Z
上記はファイル単位でのリストアでしたが、
フォルダ単位のリストアも可能なため、
誤操作によるファイル削除等のリカバリには有効な機能です。
AWS EFSを利用する際には利用を検討してみる価値ありです。
