AWSコンソールに複数アカウントでログインしたい！

AWS案件を複数抱えていると、AWSコンソールを複数アカウントで比較したいこと…有りますよね！
ということでやり方です！

GoogleChromeでシークレットモードを使いましょう！WindowsならCTRL+SHIFT+Nです！これで通常とシークレットモードの２つ、アカウントを同時にオープンできます！

…これでは足りない人は、GoogleChrome拡張機能のMultiLoginを使いましょう！開いているタブごとにアカウントを変更することが出来ます！万事解決。

ZFS理解図

ZFSの簡単な理解図を作りました。
poolとかvolumeとかdataとかって何？って時に見ると良いと思います！

AWSと消費税

AWSを利用している皆さん、『東京リージョンにおけるAWSのサービス料金請求プロセスの明確化に関する御案内』というメール来てますよね！（２０１４年３月時事ネタ）

AWSの請求って『税金』の部分が見えないから意識しないですよね。意識しても取られてますが！ということで調べてみました。

…実は『AWS の請求に関するよくある質問』を読むとあっさり解決してしまうのですが、簡単に言うと『「既定のお支払い方法」に関連づけられた住所』に基づいた税金がかかります。

つまり東京リージョン以外のEC2とかを使っていても、税率が変わるとかは無いということですね。といっても日本では『売上税』は取られないのですが！

あと消費税について記載のある部分は『Amazon EC2 よくある質問』ですね。表示価格は消費税込みです。

MySQL冗長化モデル

以前作成したMySQLの冗長化モデルをご紹介。

• MySQL
• LVS
• iptables

を利用しています。

Master及びSlaveそれぞれの冗長化及びスケールについて、参考になる部分もあるかと。運用実績も１年以上経過し、稼働中の障害復旧もできているので大丈夫なんじゃないかな－と思います。

MySQL 冗長化モデル from Zaki_XL

『大事なことはタグに書く』的なお話

AWS EC2運用をしていると、『AWS運用に関する変数』をどうやって収納するか悩みますよね！OSのユーザー権限とも違うし、テキストで置いたらセキュリティ的にも…とか思うと夜も寝られません。

ということで、『EC2のタグに書いてしまえばいいじゃない！』という発想もあるよ！というお話です。

色々利点は有るのですが、一番の利点は『AWS Management Console上で確認・変更できる』ということじゃないでしょうか。

awscli+jqのサンプルコードを書いてみました。

# タグをつける
# 同一Keyに実行すると、上書きされる
aws ec2 create-tags --resources `curl -s http://169.254.169.254/latest/meta-data/instance-id` --tags "Key=TEST,Value=TESTValue"

# タグの値を取得
aws ec2 describe-tags --filters "Name=resource-id,Values=`curl -s http://169.254.169.254/latest/meta-data/instance-id`"|jq -r ‘.Tags[] | select(.Key=="TEST")|.Value’　⇒ TESTValue  or null

# タグを削除
# keyが存在しなくてもreturnはtrue
aws ec2 delete-tags --resources `curl -s http://169.254.169.254/latest/meta-data/instance-id` --tags "Key=TEST"

Amazonの買い物をGoogleCalendarへ登録するChrome拡張機能

Amazon.co.jpの買い物って、いつ届くか忘れますよね！
過去からのテロ攻撃って怖いですね。

…ということで、amazonの商品お届け予定日をGoogleCalendarに登録するChrome拡張機能を作りました！

Amazon2GoogleCalendar

Google Chrome拡張機能をインストールすると、Amazon.co.jpの『注文履歴を見る』ページにGoogleCalendarへ登録するボタンが追加されます。使い方簡単。

Amazonが公式にwebcal対応してくれればいいのにな…。

AWSのアクセスキーとシークレットキーを運用する

AWSより「AWS アカウントアクセスキーの管理方法に関する重要な変更」というメールを貰った皆さん！IAMできちんと運用してないですよ、と注意されたようなものですね！

…ということでAWSのアクセスキーとシークレットキーってどうやって運用するのが良いの？というお話。結論を先に言うと、『権限が限定されたAWSアクセスキーを作る』ということです。

以下本題。

セキュリティの根本的な考え方として、『WEBに公開しているシステムは、実行ユーザーで出来る全てのことをやられる可能性が有る』というのが有ります。

仮にApacheをApacheユーザーで実行していたとしたら、コンソールでApacheユーザーにスイッチした時に出来る事は全て出来る、と考えます。『ブラウザからアクセスしているから大丈夫』とか『ベーシック認証かけてるから大丈夫』なんて何の防御力も無いです。

つまり、『実行ユーザーには最低限の権限だけを与えて、ハックされても問題ないようにする』ということです。『入られない』ではなく、『入られても問題ない』を中心に考えよう、ということです。

この考えはAWSのユーザー管理も一緒です。つまり『AWSアクセスキーとシークレットキーが漏れても、権限を絞っておけば被害が抑えられる』と考えます。


これを実運用に落とし込みます。AWSは権限を、『IAMで作成するユーザー単位』で定義します。つまり、『このユーザーはAWSのどの機能まで使えるのか？』ということです。

新規作成されたAWSアカウントは『ルートアカウント』と呼ばれ、AWSへのアクセス権限がフルにあるということです。（Administrator・rootをイメージして頂ければよいかと）

その上でIAMでユーザーを新規作成し、画面に出てきたAWSアクセスキーとシークレットキーを控えておきます。

そのアカウントに最低限の権限を付与します。(S3にだけアクセスできる、とか)

あとはそのキーを利用すれば、最低限のセキュリティは守られるという事になります！

『入られる事を前提』と考えますと、『入り口を限定すること』『定期的にキーを変更すること』といった運用が必要、という事にもなりますね。