AWS無料期間がいつまでなのかを確認する

AWS無料枠を利用していて1年の期限が近づいてくると、あとどらくらい使えるんだろうときになることがあると思います。

しかし、AWSのコンソールを確認しても、明確にAWS無料枠の終了日が書いてある場所を見つけられません。
そこで、残りの期間を確認する方法をまとめてみました。

ざっくり考えてみると、以下の3つの方法が考えられると思います。

【無料期間の終了日を確認する方法】
1.Amazonからの終了日通知メールを確認する。
2.AWSの無料枠を開始したときの通知メールから逆算する。
3.AWSコンソールの最初の請求書を確認する。

1.Amazonからの終了日通知メールを確認する

これが一番確実な方法です。
いろいろなサイトやAmazonの説明を見ると

Your AWS Free Tier Period is Expiring

というタイトルのメールがAmazonから送られてくるようです。

しかしこの方法の欠点は、メールがおくられてくるまで期限がわからないことです。

私の場合、2020/2/29に無料枠を開始したはずですが、期限と思われる日の8日前(2021/2/21)になっても、まだAmazonからのメール通知はありません。
(明日(一週間前)にくるのかな?)

こんなに直前だと、ブログの引越しの準備をする期間がなくなってしまうんですけどね。

2.AWSの無料枠を開始したときの通知メールから逆算する

ということで、1.のAmazonからの終了通知メールが来ていない今、この方法が一番てっとりばやく、確実かと思います。

AWSの無料枠を契約したときに、Amazonから以下のメールが来ているはずですので、おそらくその日付の1年後(正確にいうと、1年後の1日前?)が期限と思われます。

私の場合、AWSの無料枠を契約したときに、

お客様の AWS アカウントの準備ができました – 今すぐ始めましょう

というタイトルのメールが来ていました。

Amazonからのメール

3.AWSコンソールの最初の請求書を確認する

これは苦肉の策になりますが、2.のメールが残っていないよーという方は、この方法でもだいたいのAWS無料枠の開始日を推測できます。

AWSコンソールの請求書画面を開き、下図のとおりプルダウンから一番古い請求書を開いてみましょう。

AWSコンソール

さらにここから、Elastic Compute Cloudを開いてみましょう。赤枠でかこっているように、EC2の利用時間が書かれています。

1ヶ月丸々EC2を利用した場合、700時間前後になっているはずですが、私の場合、2時間ちょっとしか使っていません。
EC2は無料枠を契約してすぐに作成したと記憶していますので、2020年2月の最終日と推測でき、2.で調べた2/29(うるう年だったんですね。)と一致しています。

ということで、3つほど、AWS無料枠の期限を確認(推測)する方法を記載してみました。

私の場合、あと1週間で無料枠が終わってしまうので、以下の記事で書いたAzureに引っ越すか、はたまた無料レンタルサーバーにするか早急に考えたいと思います。

http://k2-ornata.com/aws_to_asure_wordpress/

AWSの無料枠でSplunk Freeをインストールしてみた

Splunk のSPL言語を勉強したいんだけど、試せる環境がない!
そんなわけで、 WordPressを動作させているAWS上のインスタンスにSplunk Freeをインストールしてみました。
しかしながら、無料枠で構築しているインスタンスなので、ディスク容量が10GBと限られています。
したがって、ディスク容量をあけてから構築する必要がありました。

インストータをダウンロード後、ディスクを開けるところから始まる

最初に書いたとおり、t2.microというAWSの無料枠にSplunkをインストールする為にはディスク容量を開ける必要があります。
インストーラのサイズは380MB程度ですが、それをインストールする為には2GB程度の空き容量が必要となります。またその後にデータを取り込むことを考えると、もっと必要になりそうです。

2020.7.20 追記
インストール2日後に改めて環境を見てみると、Splunk が出力するログが膨れ上がっており、その影響でWordPressサーバがダウンしていました。😅
もしかしたら、ディスクの空き容量が5GBくらいないと厳しいかもしれません。

1.インストーラのダウンロード

Splunk のサイトにアクセスすると、Splunk Enterpriseの試用版をダウンロードすることが可能です。この試用版は15日経過後、Splunk Free版として使用し続けることができそうです。

以下の画面のようにwgetでダウンロードすることが可能ですので、Linux(Ubuntu)のコマンドラインから直接ダウンロードできます。

以下、ダウンロードした際のコマンド画面です。AWSからダウンロードしているのであっという間にダウンロードできました。

2.ディスクの空き容量を増やす

インストーラをダウンロード後に空き容量を確認したところ、500MG程度空いていたのでいけるかなと思いましたが、やはりインストール中に容量不足のエラーが出て止まってしまいました。
そこで、以下の方法で不要なファイルを削除することにしました。

2.1 更新に伴い必要なくなったパッケージを削除

Ubuntu では apt-get autoremove コマンドを使うとOSの?更新に伴い不要となったパッケージを削除してくれるようです。

$ apt-get autoremove

これにより、下図のとおり300MB近く空きました。

2.2 パッケージキャッシュをクリア

これはどれくらい効果があったのかよくわかりませんでしたが、apt のパッケージキャッシュをクリアできるということだったので、以下のコマンドを実行しました。

$ apt-get clean

2.3 不要な linux-image パッケージを削除

以上で1.3GMくらいディスクに空き容量ができましたが、まだSplunkのインストールに失敗します。
そこで、古い linux kernel のパッケージを消すために以下のコマンドを実行しました。

$ dpkg -l ‘linux-‘ | sed ‘/^ii/!d;/'”$(uname -r | sed “s/(.)-([^0-9]+)/\1/”)”‘/d;s/^[^ ]* [^ ]* ([^ ])./\1/;/[0-9]/!d’ | xargs sudo apt-get -y purge

出典元:Cleanup Unused Linux Kernels in Ubuntu
https://markmcb.com/2013/02/04/cleanup-unused-linux-kernels-in-ubuntu/

なお、このコマンドを実行する前に、以下のコマンドでインストールされていパッケージと、今現在使っているLinuxカーネルを念のため確認しておくとよいようです。

$ dpkg -l ‘linux-image-*’
$ uname -r

以上で2GB近くの空き容量が出来、ようやくSplunkのインストールができるようになりました。

3.Splunkのインストールと起動

ここまで来たら、Splunk のインストールは非常に簡単です。以下のコマンドを実行します。

$ sudo dpkg -i <splunkのインストールパッケージ(.debファイル)>

インストールが始まると以下のようにおそらくhttps用の暗号鍵が作成されたあと、自動的にSplunkが起動すると思います。
なお、初期はhttpで起動するので、インターネット経由でアクセスする必要がある場合には、https で起動しなおしてください。方法はコマンドラインやWeb UI経由などいくつかあるようです。

もし自動起動しなかった場合は、以下の操作で起動可能です。なおこの際に上図のようにsudoをつけて起動しようとするとsplunkのパスワードを聞かれるようなので、以下のようにsplunk アカウントにスイッチした後、sudo を付けず実行します。
(なお、splunk アカウントはパッケージインストール時に勝手に作られるようです。)

$ cd /opt/splunk/
$ sudo su splunk
splunk~$ /opt/splunk/bin/splunk start

これでSplunkの起動が完了しましたが、AWS上で起動した場合、お家のPCからアクセスするにはネットワークACLやロードバランサーの設定、通信のhttps化をする必要があります。

この作業も結構大変だったので、別のページとして記載しておきたいと思います。

2020.12.19 後記

最近はもうSpunkをAWS上で利用しなくなったので、アンインストールすることにしました。(なんか、1GB以上使っているし。。)
しかしながら、下記のインストール済パッケージを確認するコマンドで確認してもSplunkが出てきませんでした。(もしかしたら、以前、パッケージ自体は削除したのかもしれませんが。。。)

$ sudo dpkg -l

また、他のサイトをいろいろと検索してみましたが、結局、Splunkの消し方がよくわからなかったので、/opt/splunk を丸ごと消すことにしました。

これで2GB以上、余裕ができましたー。(/dev/xvda1の部分)

WordPressのバックアップに必要な作業

3月から始めたブログの作成もそろそろ記事の数が50に近づいてきたので、バックアップをとっておこうと思います。

原稿(文章)はダッシュボードからエクスポート、画像はフォルダのバックアップ

細かく言うとWordPressのアカウント設定などもバックアップしておいた方が良いと思いますが、記事のバックアップという意味では、原稿をエクスポートしたときに生成されるXMLファイルと画像やプラグイン等が含まれるフォルダを固めたZIPファイルがあれば良さそうです。

1.原稿のエクスポート

WordPressダッシュボードの左ペインから「ツール」-「エクスポート」を選択すると以下の画面が表示されます。
以下の画面のとおり「すべてのコンテンツ」を選択し、「エクスポートファイルのダウンロード」をクリックしてください。

すると「サイト名.WordPress.日付.xml」という名前でこれまで投稿したすべての原稿がダウンロードされます。
このファイルを適切な場所に保管しておきます。

2.wp-content フォルダの圧縮&ダウンロード

PCからWordPressのサーバにsshでログイン後、wordpress/htdocsディレクトリに移動します。(以下はAWSのbitnamiを利用している場合の場所)

/opt/bitnami/apps/wordpress/htdocs

この配下に wp-contentディレクトリがありますので、このフォルダ配下を丸ごとバックアップしておきます。

ディレクトリ配下を丸ごとバックアップするには、以下のコマンドを実行します。

zip -r wp-content.zip wp-content

-r オプションをつける事で、wp-content 配下にサブフォルダがある場合でも再帰的にバックアップしてくれます。
wp-content.zip はバックアップするファイルをまとめるZIPファイルの名前です。

zipファイルを作成したら、あとはそれを自分のPCにダウンロードするだけです。
ダウンロード方法は以下の通りです。自分のPCからWordPressにsshでログインできるようにしていれば、これでダウロードできると思います。

scp -i hogehoge.pem bitnami@xxx.xxx.xxx.xxx:/opt/bitnami/apps/wordpress/htdocs/wp-content.zip .

hogehoge.pemにて、sshの認証キーを指定してください。
また、xxx.xxx.xxx.xxxではWordPressサーバのIPアドレスを指定してください。

Zipファイルがダウンロードできたら、xmlファイルと同じく、適切な場所にバックアップしてください。

以上でバックアップが完了しました。できれば、InstantWPなどの環境を利用して正常に復元できることを確認することをお勧めします。

インスタンスをEIP(固定IP)にしてWordPressのSEOが変わるか確認してみた

WordPressをAWSで立ち上げてから、インスタンスのIPはパブリックIPのままにしていましたが、これだとインスタンスを再起動する度にIPが変わってしまう為、SEO 上よろしくないのではないかとおもっていました。
そこで今回、IPを固定にするEIP(Elastic IP)に変えてみて、検索結果が上位にくるようになるか確認してみることにしました。

パブリックIPからEIPへの変更は非常に簡単

もしかしたら、EIPにするとDNSの情報も書き直さないとアクセスできなくなるのではないかとおもっていましたが、そんな心配は無用でした。
以下の手順でEIPを作成し、既存のインスタンスに紐づけるだけで完成です。

1.EC2の画面に移動

Elastic IPを設定する為に、EC2の画面に移動します。

2.EIPの作成

左ペインからElasitic IPを選択すると、以下の画面が表示されますので、右上にある、「Elastic IP アドレスの割り当て」ボタンを押します。

すると以下の画面が表示されますので、AmazonのIPv4アドレスを選択したまま、「割り当て」ボタンを押します。

これで以下の通り、EIPとして割り当てられるIPアドレス(下の例では18.X.X.X)が決まります。

3.EIPのインスタンスへの割り当て

次に、先ほどのIPアドレスをチェックボックスでチェックした後、右上の「Actions」と書かれているプルダウンから「Elastic IP アドレスの関連づけ」を選択します。

Elastic IPアドレスは必ずインスタンスに割り当てましょう。

割り当てしていない Elastic IP アドレスは課金されるらしいので、必ずインスタンスに割り当てておきましょう。 

すると、以下の画面が表示されますので、インスタンスのプルダウンからElastic IPを割り当てるインスタンスを選択し、「関連付ける」ボタンを押します。
プライベート IP アドレスも指定できるようですが、ここはオプションのようで何もしなくても勝手にプライベートIPアドレスが割当たるので、放っておいてよいようです。

これで以下の通り、インスタンスにElastic IPが割り当たりました。

パブリックIPアドレスから Elastic IPに切り替える場合、これで作業は完了です。DNSの設定変更などは不要で、いままでのドメイン名でインスタンス上で動いているWordPressにアクセスできました。

EIPに切り替えても。。。

いまのところWordPressへのアクセスは増えていないので、SEOは変わっていない気がします。。。ね。

AWSへのポートスキャンをネットワークACLで止めてみた

先日、GuardDuty を設定してから、海外からHTTPやSSHに対してポートスキャンやブルートフォース攻撃を受けていることがわかったので、ネットワークACLで止めることにしました。
最初はセキュリティゲートウェイ(SG)で止めようとしたのですが、SG は許可設定しかできないみたいなので諦めました。

VPCからネットワークACLの設定を行う

そういえばネットワークACLってどこから設定するんだっけ?と最初、悩んでしまいましたので、ネットワークACLにたどり着くところから説明しておきます。

1.VPCの設定画面に移動

AWSマネジメントコンソールにログイン後、”VPC”で検索します。

VPCの画面の左ペインにある「ネットワークACL」を選択します。

ここでメイン画面の中から「インバウンドのルール」タブを選択すると、現在のフィルタリングルールが表示されます。
この例では、VPC内のすべて(3つ)のサブネットはこのルールで守られている(関連づけられている)ようですね。

2.ネットワークACLの編集

ネットワークACLが一つしかないのでそのまま「アクション」のプルダウンから「インバウンドルールの編集」を選択します。

以下の画面に切り替わりますので、ここで「ルールの追加」ボタンを押します。

そして、新しいルールを記述しますが、今回はDENYルールを記載しますので、既存のルール(ルール番号100)より若いルール番号(以下の例では10)を設定します。

この後、保存ボタンを押すと以下のとおり新規に作成したルールが既存のルールより優先して適用されます。

これでGuardDutyで頻発していたポートスキャンやブルートフォースが発生しなくなるはずですので、少し様子を見てみたいと思います。

AWSでsudo的な権限昇格(その1:スイッチロールの設定)

これまでは、AWSコンソールでデータを確認するだけの場合、一般ユーザでログインし、設定に変更を加えたい場合、rootでログインしていました。
しかし、私の場合、AWSをテスト的に使っており、頻繁に設定変更をおこないたくなるので、いちいちログインし直すこの運用はとても面倒に感じていました。
また、rootでログインしているとGuardDutyが毎回アラートを発砲してしまうので、それも避けたいと考えていました。

そこで今回は、AWSコンソールでLinuxで言うsudo的な運用ができるように、スイッチロールの設定をしてみました。

スイッチロール機能で同一アカウント内で最低限の権限昇格が可能

AWSにはスイッチロール機能というものがあり、パスワードを要求せずに簡単に権限昇格をさせることが可能です。
だだし、パスワードを要求しない分、権限を与えすぎるとrootユーザでログインしたのと変わらなくなり、かなり危なくなりそうなので注意が必要と思われます。

1.IAMでスイッチ先のロール作成

rootユーザでAWSコンソールにログイン後、IAMに移動します。

上記画面の左上にある「ロールの作成」ボタンを押すと、以下の画面が表示されます。
ここで、左から2番目の「別のAWSアカウント」を選択し、現在使っているAWSアカウントIDを入力します。

「別のAWSアカウント」とありますが。。。

実は同一のAWSアカウントも入力可能ですので、同じAWSアカウント内でロールを切り替えたい場合は、こちらを選択してください。
もちろん、別のAWSアカウントのロールに切り替える場合もこちらを使います。

そして、「次のステップ:アクセス権限」ボタンを押すと、今回作成するロールに与えるポリシー(権限)を選択できます。

ポリシーの選択は慎重に。。。

下の例ではAdministratorAccessを設定していますが、実はあとで変更しています。あまり権限を与えすぎると、このユーザIDを乗っ取られた時に、何でもできてしまいますので。

上記画面から「次のステップ:タグ」を押すと、タグの設定ができます。ここは任意ですので、自分がわかりやすいようにタグをいくつか付けて、「次のステップ:確認」を押します。

すると、設定の確認画面が表示されますので、ここでロール名等を入力し、「ロールの作成」ボタンを押します。

これで、新しいロールが作成されました。

2.IAMでスイッチ元のポリシーの作成

次にログインIDに対してスイッチロールさせる為のポリシーを作成します。

IAMの画面の左ペインから「ポリシー」を選択後、メイン画面の左上に表示される「ポリシーの作成」を選択します。
すると以下のポリシー作成画面が表示されますので、「JSON」タブに切り替え後、以下の画面のとおり、記述を行ってください。

一応、記述内容をテキストにしておきますので、コピペした後、「アカウントID」と「ロール名」の部分を書き換えてもらえればOKです。

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::(スイッチ先のアカウントID):role/(1.で設定したロール名)"
    }
}

上記の記述が終わったら、「ポリシーの確認」ボタンを押します。

すると、ポリシーの名前を記入する画面が表示されますので、それを記入後、「ポリシー の作成」ボタンを押してください。

3.ユーザーにロールへのアクセス権限を付与

権限昇格をさせたいユーザーに2.で作成したポリシー(AdminGroupRoleへのスイッチを許可したもの)を割り当てます。
IAMの画面の左ペインから「ユーザー」を選択後、メイン画面からポリシーを割り当てたいユーザーを選択します。

するとユーザーの概要画面が表示されますので、「アクセス権限」タブの中から「アクセス権限の追加」ボタンを押します。

すると以下の画面が表示されますので、「既存のポリシーを直接アタッチ」を選択後、先ほど作成したポリシー(AdminSwitchPolicy)を選択します。

その後、「次のステップ:確認」ボタンを押すと確認画面が表示されますので、そのまま「アクセス権限の追加」ボタンを押します。

4.実際にスイッチロールしてみる

これでスイッチロールが可能となりましたので、許可したアカウントにてAWSコンソールにログイン後、画面右上に表示されている「ユーザー名@アカウントID」をクリックし、表示されたプルダウンの中から「スイッチロール」を選択します。

すると以下のロール切り替え画面が表示されますので、スイッチ先のアカウント(スアカウントID)とロール(ロール名)、色(背景色)を指定し、「ロールの切り替え」ボタンを押してください。

うまくいけば、画面右上のログイン情報(ロール名@アカウントID)の背景が指定した色に切り替わり、元のログインユーザーではできなかった操作ができるようになります。

以上で、スイッチロールが正常に動作することが確認できました。

しかし、この設定のままだと、ログイン可能なユーザーであれば誰もが特権を持つことができるようになってしまいますので、次回は、スイッチロールができるユーザを制限する方法をアップしたいと思います。

AmazonのGuardDutyを有効化してみた(その3.メール通知)

先日、GuardDuty を有効化しましたが、今の設定では、AWSにログインしない限り、不正なアクセスに気がつくことができません。
そこで、GuardDuty でアラートが発生した際にメールが送信されるように設定してみました。

SNSとCloudWatchを利用しメールを送信

SNSとCloudWatchを利用することで、GuardDutyで検知したアラートをメールで通知することが可能です。

1.Amazon SNSでトピックの作成

まず、Amazon SNSの画面に移動します。すると以下の画面が表示されるので、指示に従いトピック(メッセージチャネル)を作成しましょう。

トピック名について

トピック名にスペース(空白)は使えないようですので、注意してください。

トピック名を入力し、「次のステップ」を押すと以下の画面が表示されます。いくつか設定項目がありますが、トピック名以外はオプションなので、そのまま「トピックの作成」ボタンを押しても問題ありません。

すると以下のようにトピックが作成されます。

2.Amazon SNSでサブスクリプションの作成

トピックを作成した後は、サブスクリプションの作成を行います。
ここでは、作成したトピックで利用するプロトコル(Eメール)やエンドポイント(送信先)を指定します。

プロトコルとエンドポイントを指定後、「サブスクリプションの作成」を実行すると、サブスクリプションが以下のように作成されます。

この時だと思いますが(若干うろ覚え)エンドポイントに指定したメールアドレスに確認のメールが届きますので、必ず「Confirm subscription」のリンクをクリックしてください。

メールのリンクをクリックすることで、先ほど作成したトピックのステータスが「確認済み」となります。

これをやっておかないと、次のCloudWatchの設定をいくらやってもメールが届きません。(私はこれで少しはまりました。)

3.ClowdWatchでルール作成

これでメールを送信する準備が整いましたので、次にCloudWatchを使ってGuardDutyのイベントを送信対象とするルールを作成します。
以下のCloudWatch画面の左ペインから「ルール」を選択します。

すると、以下の画面が表示されますので、「ルールの作成」ボタンを押します。

ボタンを押すと、以下の画面が表示されますので、イベントソースとターゲットを指定します。

指定の方法は以下の通りです。

イベントソースとして「イベントパターン」を選択後、以下の通り設定します。
・サービス名:「GuardDuty」
・イベントタイプ:「GuardDuty Finding」
・イベントパターンのプレビュー:特に編集しなければすべてのGuardDutyのアラートが送信されます。編集する場合は、以下を参考にしてください。

イベントパターンのプレビューの編集例
例)7.0〜8.9までの重要度のアラートが発生した場合のみ通知したい場合

{ “source”: [ “aws.guardduty” ],
“detail-type”: [ “GuardDuty Finding” ],
“detail” : { “severity”: [7.0,7.1,7.2,7.3,7.4,7.5,7.6,7.7,7.8,7.9,8.0,8.1,8.2,8.3,8.4,8.5,8.6,8.7,8.8,8.9 ] }
}

ターゲットとして「SNSトピック」を選択後、以下のとおり設定します。
・トピック:1.で設定したトピック名
・入力の設定:インプットトランスフォーマー
・最初のテキストフィールド記入例:
{“type”:”$.detail.type”,”title”:”$.detail.title”,”description”:”$.detail.description”,”severity”:”$.detail.severity”,”updatedAt”:”$.detail.updatedAt”,”createdAt”:”$.detail.createdAt”,”arn”:”$.detail.arn”}
・次のテキストフィールド記入例:
“GuardDuty で以下の脅威を検知しました。”
“種別  :””タイトル:”
“説明  :<description>”
“重要度 :<severity> “
“更新日時:<updatedAt>”
“作成日時:<createdAt>”
“ARN   :<arn>”

以上を設定後、右下の「設定の詳細」ボタンを押すと、以下の画面が表示させますのでルールの名前などを設定し、「ルールの作成」ボタンを押します。

「ルールの作成」ボタンを押すと、以下のようにルールが作成されます。

4.GuardDutyのアラートを待つ

以上でGuardDutyでアラートが発生するとエンドポイントで指定したメールアドレスにアラートメールが届くようになっているはずです。

もし早く確認したければ、GuardDutyの画面の左ペインから「設定」を選択し、その中から「結果サンプルの生成」を押せば擬似的にアラートを出すことができますが、大量に出てしまうので、個人的にあまりおすすめはしません。

ちなみにGuardDutyのアラートをすべて受け取るようにしていると、毎日数通以上のメールがきてしまうと思いますので、ある程度重要度の高いアラートのみ通知させた方がよさそうです。

AmazonのGuardDutyを有効化してみた(その2.検知状況)

GuardDuty を有効化してから、ちょうど無料期間30日の半分、15日が経過しました。(すっかり有効化したことを忘れそうになっていましたが。。。)
そこで、現在の検知状況と無料期間が終わったあとの予想料金を調べてみました。

ポートスキャンのみを検知。以外と攻撃されていない?

ひさびさにGuardDutyを覗いてみたところ、rootログイン以外にポートスキャンらしきものが検知されていました。(真ん中のリストの真ん中の行)
カウントに89とあるので、89回スキャンされたということでしょうか?ここはよくわかりません。

右ペインの影響を受けるリソースのところにHTTP(80 Port)とあるので、このportへのアクセスはブロックしておいた方がよさそうですね。
たしかに、HTTPSでWordPressを提供しているので、HTTPは不要ですね。

また、右ペインを下までスクロールしていくと、攻撃者の情報も出てきます。

どうやら、11日前から2日前までの間、ロシアのPetersburg Internet Network ltd.というプロバイダを使っている誰かからポートスキャンされているようですね。

無料期間が過ぎても費用は0.00 USD?

十分かどうかわわかりませんが、GuardDutyは働いてくれていることがわかりましたので、今度は無料トライアルの状況を確認してみました。

するとどうでしょう、GurdDutyで監視してくれた各ログの量は以下の通りで、無料トライアル終了後の日次推定コスト0.00 USDとなっています。

CloudTrail ログ940.0 イベント
VPC フローログ25.15 MB
DNS ログ41.24 MB

まあ、このサイトは貧弱で1日に10人も見にきてくれないサイトではありますが、、、まさか0とは思いませんでした。もしかすると、1ヶ月で見ると多少費用がかかるのかもしれませんが。。。

これなら、無料期間が終了した後も使い続けてもいいかもしれません。

AWS Configの機能と、利用した場合の料金の増加について

CloudTrail が人を軸にしてAWSに対する操作を記録するのに対し、Configは各操作対象(何に)を軸にして操作を記録していく機能になります。

CloudTrail はデフォルトで動作しているのに対し、Configはデフォルトでは動作していないので、利用するには初期設定してあげる必要があります。
しかしながら、ここで気になるのがConfigを新たに利用し始めることによるAWS料金の増加です。ログの記録にS3を利用することになるなど、あまり経験のない人には料金の予測がつかず、利用を躊躇してしまうと思います。

しかし、Configの機能はAWSを利用している人であれもが誰もが使っておいた方がよさそうですので、今回、Configの機能を確認しながら、実際利用するとどれくらい料金がが増加するのかを調べてみました。

Config設定後、$0.07/月の料金増加(Configルール未使用の場合)

以下の画面は、Configを利用する前の料金です。
AWSの無料枠内でWordPress用にEC2のインスタンスを1つ作成し、独自ドメインでアクセスできるようにRoute53を利用しています。
実質、Route53の料金$0.55/月(税込)のみです。日本円でいうと60円/月だと思いますので、レンタルサーバとくらべるとめちゃくちゃ安いです。

この状態から、まずはConfigの初期設定をしてみました。

1.記録する対象とログの保存先を設定

操作を記録する対象(リソース)とログの保存先(S3)を設定します。今回は、リージョン内の機能以外に、IAMなどの操作も記録したいので、「グローバルリソースを含める」に追加でチェックを入れました。

2.通知設定とConfigへの権限設定

1.の画面を下にスクロールしていくと、SNS(Simple Notification Service)と権限(ロール)の設定項目があります。特に今回は変更しないので、そのまま「次へ」ボタンをクリックしました。

3.Configルールの設定

Configルール設定をしておくと、そのルールに違反する設定をした場合に警告を出してくれるようになります。(なるはずです。)
現時点(2020.5.22)で88個のルールがあるようですが、これを設定した分だけ料金があがりそうな気がするので、とりあえず、どれも有効にはせず、「次へ」を押しました。

4.設定の確認と利用開始

設定内容が表示されますので、間違いがなければ、「確認」を押しましょう。

20分くらい経過すると、以下のように対象リソースが表示されます。

せっかくなので、今回のS3バケットの作成が記録されているか確認してみる為、上図のリソースの中にある「S3 Backet」をクリックしてみました。

そして、リソース識別子をクリック。

すると、右上に「設定タイムライン」というボタンがあるので押してみます。以下のように、今日の9:37に作成されたことが記録されていました。

ちゃんと動いているようですね。(あたりまえか。。)

5.実際にS3バケットが作成されているか確認してみる

さらにS3バケットが実際に作られているか確認してみます。

どうやら無事に作成されており、Configのログが書き込めるか確認する為?のファイルが置かれているようです。

6. Config設定後の請求書を確認してみる

約1時間前にConfigを設定したばかりなので、まだ反映されていないかもしれませが、この時点で請求書を再度確認してみました。

結果としては、特に変化はなく$0.55/月のままです。
まだS3に何も書き込まれておらず、Configルールも設定していないからかもしれません。
噂では前払い料金がかかるはずなので、もう少し様子を見て見たいと思います。

(2020.5.26追記)
翌日、再度請求書を確認したところ、料金が$0.07増えていました!(以下の図の右側、Configの項目)

料金明細を確認してみたところ、Configuration item毎に$0.003かかるようで、私の場合、24アイテムある(設定したときは23アイテムでしたが)ので、$0.072という計算らしいです。(よく見ると、東京ではなくバージニアで作ってしまっていますが。。。後で変えられるのでしょうか?)

だいたい10円/月くらいなので使い続けてもまったく問題ないですね!
今後機会があれば、今回スルーしたConfigルールも使ってみたいと思っています。

AWS上のWordPressから 自ドメインでメールを送信をする

以前、AWS上でWordPressを立ち上げ、WP Mail SMTP プラグインを使ってメールを送信できるようにしました。

しかし、その時に設定した環境では、送信されるメールの送信元アドレス(Googleのメールアドレス)と送信元サーバ(Amazon)が異なる為、受信したメーラー側で以下のような警告が発生してしまいます。

自分にメールしているだけなので大きな問題はありませんが、ちょっとかっこ悪いのと、SPFやDKIMが使えるかどうかも確認してみたかったので、AWSから自ドメイン(k-ornata)のメールアドレスを送信元にしてメールを送信してみることにしました。

Amazon SES に送信元ドメインを登録し、Route 53にレコードを登録するだけでOK

DNSとしてroute53を利用している前提ですが、Amazon SES に送信元にしたいドメインを登録し、その勢いでroute 53に必要なレコードを登録するだけで設定が完了します。

1.SES から自ドメインを登録

SES Homeにアクセスし、左ペインから Domains を選択します。

「Verity a New Domain」をクリックし、以下の通り、自ドメイン名の入力と、「Generate DKIM Setting」のチェックを入れます。

2.Route 53へのレコード追加

上の画面で「Verity This Domain」をクリックすると、以下のようにDNSサーバに登録するTXT, CNAME, MXレコードの情報が表示されます。
今回はDNSとして Route 53 を使いますので、「Use Route 53」のボタンを押すだけです。

すると以下のように確認画面が表示されますので、必要に応じて(自ドメインでメールを受信したい場合)「Email Receiving Record」にチェックを入れ、「Create Record Sets」にチェックを入れます。

すると、以下の画面が表示され、ドメインの確認とDKIMの設定をAWSが自動で開始してくれます。

処理が完了(だいたい5分くらい)すると、(AWSコンソールの?)管理者のメールアドレスに、以下2通のメールが送られてきます。

ドメインの確認が完了した旨の通知メール
DKIM の設定が完了した旨の通知メール

メール受領後、再度、SES Home の Domainsを確認すると、ステータスが pendingから verified に変わっているのが確認できます。

3.自ドメインでのメール送信確認

以上で自ドメインでメール送信できるようになりましたので、テストメールを送ってみます。
以下のとおり、SES Home のDomains から今回登録したドメインにチェックし、「Send a Test Email」を押します。

すると以下のとおり、テストメール送信用のウィンドウがでますので、各項目を入力し、「Send Test Mail」を押します。

すると、Toで指定したメールアドレスにテストメールが送られてきます。

上記のとおり、Fromがちゃんと自ドメインで送られてきており、SPFやDKIMもパスしています。(簡単すぎて、SPFやDKIMの理解にはつながらないかもしれませんが。。)
なお、Fromの@の左側は(たぶん)何でも大丈夫です。(ユーザの有無とかは気にしなくてよさそうです。)

また、ToはSES Home のEmail Addressesにてverifiedになっているものを使ってください。もしそれ以外のアドレスに送付しようとすると、以下のように「検証されていない」と怒られます。

これはセキュリティ面を考慮し、デフォルトでは検証済のアドレスにしか送れないようにしているらしいです。(これを解除する方法があるらしいですが、ここでは触れません。)

4.WordPressのWP Mail SMTP の送信元アドレスを自ドメインに変更

WordPressからメールを送信する時にWP Mail SMTP プラグインを使っている場合、その送信元アドレスを今回設定した自ドメインのものに変更します。
そしてテストメールを送信してみると、以下の通り、自ドメインのメールアドレスからメールが送信されてくることが確認できます。

これでWordPressのメール環境はスッキリしましたが、あまりにも簡単だったので、SPFやDKIMの勉強にはならなかった気がします。
機会を見て、もうすこし掘りさげてみたいと思います。