S3で有効期限付きの署名付きURLを作成する

S3で署名付きURLを利用してユーザごとに別々のURLを発行できるようにしてみたいと思います。

手順

対象のディレクトリに対するアクセス権を無効にする

まずは署名付きURLを利用するコンテンツを配置するディレクトリに誰もアクセス出来ないようにアクセス権を設定します。

基本的にはなにもしなくてOKです。
バケットポリシーに何も指定しなければ暗黙的拒否扱いになり、オブジェクトへのアクセスは拒否されます。

署名付きURLをつくる

署名付きURLを作成していきます。
例として「/wawawa/s3_index.html」というコンテンツに署名URLを作成していきます。

署名付きURLはAWSCLIを使うことで作成できます。
以下のようなコマンドを実行します。

aws s3 presign s3://kabegiwa-secret/wawawa/s3_index.html --expires-in 3600

実行すると以下のようなURLが応答されます。
URLはコマンドを実行するたびに新しいものが生成されます。

https://kabegiwa-secret.s3.amazonaws.com/wawawa/s3_index.html?AWSAccessKeyId=AKIAJ4M6D6DG7LQHQ53A&Expires=1511184525&Signature=mFMiY7%2BMoJm%2FOsWB1D6Wp0jWqj8%3D

ちなみにコマンドのオプションの--expires-in 3600はこの署名付きURLは3600秒有効だという意味です。
URLの生成から3600秒=1時間経過するとこのURLは無効となり、アクセスできなくなります。

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

S3へのアクセスログを記録する

S3にはアクセスログを記録する機能があります。
その機能を有効にすると、別のS3バケットにログを記録することができます。

手順

ログ格納用のバケットを作成する

まずはログを格納するためのバケットを作成します。
バケットの名前はなんでもよいです。
今回は「kabegiwalog」という名前のバケットを作成しました。

バケットのログ記録を有効にする

アクセスログを記録したいバケットで「ログ記録」機能を有効にします。

アクセスログを記録したいバケットに移動し「プロパティ」タブを選択、「サーバーアクセスのログ記憶」を選択して、さきほど作成したバケットをターゲットバケットに指定します。
ターゲットプレフィックスは特に指定がなければそのままで構いません。

アクセスログを確認してみる

上記の設定をして1時間くらいするとログが書き出されるようになりますのでしばらく待ちます。

1時間後…
アクセスログが無事格納されました！

ログの中身については以下の公式ドキュメントが役に立ちます。

docs.aws.amazon.com

まとめ

S3でアクセスログを記録することができました。
ただ、このログの記録はベストエフォートであり、確実に記録される保証はありません。(実際はほとんど欠落することはないようですが)

即座に保存されるわけではなく、保存されるのにしばらく時間がかかるのもデメリットです。

ですが、かんたんでログの記録そのものには料金はかかりませんので、検討してみるのもいいかもしれません。

Amazon Web Services パターン別構築・運用ガイド 一番大切な知識と技術が身につく

S3と独自ドメインでウェブサーバを構築する

S3にはストレージとして利用する以外にもうひとつの使い方があります。
それは静的コンテンツを公開するWebサーバとしての使い方です。

S3には静的ウェブホスティング機能というものがあり、この機能を有効にするとS3に保存したファイルをWebサイトとして公開することができます。

手順

独自ドメイン名でS3バケットを作成する

独自ドメイン名でS3バケットを作成します。
たとえば当ブログのドメイン名でもある「www.kabegiwablog.com」で運用するのであれば「www.kabegiwablog.com」というバケットを作成します。

静的ウェブホスティングを有効にする

作成したバケットのプロパティを開き「Static website hosting」を選択します。
設定項目が開くので「このバケットを使用してウェブサイトをホストする」を選択し、「保存」します。
「インデックスドキュメント」と「エラードキュメント」はそれぞれ「index.html」と「error.html」で構いません。

バケットポリシーを設定する

現時点ではアクセス許可をだれにもしていない状態ですのでバケットポリシーでオブジェクトへのアクセス許可を与えます。

バケットの「アクセス権限」から「バケットポリシー」を選択してバケットポリシーエディターに以下のように入力します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.example.com/*"
        }
    ]
}

"Resource": "arn:aws:s3:::www.example.com/*"の箇所は自分のバケットのARNに読み替えてください。

実際に設定されたかどうか確認してみます。
S3に任意の内容の「index.html」ファイルをアップロードし、S3のエンドポイントのURLを指定してブラウザでアクセスしてみると、以下のようにファイルの中身が見れるはずです。

S3のエンドポイントのURLは静的ウェブホスティングを有効にした際と同じく、バケットのプロパティを開き「Static website hosting」を選択したところに記載があります。

Route53で独自ドメインを設定する

S3へのアクセスはできるようになりました。
つづいて独自ドメインでアクセスできるように設定します。

具体的にはAレコードのAlias機能を利用します。

Route53で「Create Record Set」を選択して、それぞれ以下のように設定します。

• Name - www.
• Type - A - IPv4 address
• Alias Target - バケットの一覧が出てくるので今回作成したバケットを選択

　

以上で設定は完了です。
さて、独自ドメインでアクセスしてみると、S3上のオブジェクトにアクセスできるようになっているはずです。

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

Amazon Linux で snmpwalk を利用する

Amazon Linuxでsnmpwalkを利用しようとしたときにCommand not foundって言われたので簡易メモ。

インストール

sudo yum -y install net-snmp-utils

確認

snmpwalk -v 2c -c public localhost

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

Windows Server 2016 にSNMPサービスをインストールする(英語版)

zabbix 3.0でWindows Server 2016 SNMPサービスを入れる方法をご紹介します。

環境

以下のAWS環境標準のWindows Server 2016のAMIを利用。

Microsoft Windows Server 2016 Base - ami-4325fa25
Microsoft Windows 2016 Datacenter edition. [English]

手順

Windows Serverの準備

SNMPサービスをインストールする

左下のWindowsマークのスタートメニューをクリックし、「Server Manager」を選択します。

「Dashboard」から「Add role and featrures」を選択します。

「Next」を選択します。

そのまま「Next」を選択します。

ここもそのまま「Next」を選択します。

ここでも「Next」を選択します。

中盤までスクロールして「SNMP Service」にチェックをいれます。

するとウインドウが開くので、「Add Features」を選択します。

「Next」を選択します。

「Install」を選択します。

「Close」で閉じます。
以上でSNMPサービスのインストールは完了です。

SNMPサービスの設定

「Server Manager」の右上の「Tools」をクリックし、「Services」を選択します。

一覧の中から「SNMP Service」を探して、右クリックで「Properties」を選択します。

「Secrurity」タブを選択し、「Accept community names」の「Add」ボタンを押下します。

「Community rights」を「READ ONLY」にし、「Community Name」になにか任意の名前を入力します。
入力したら「Add」を選択します。

「Accept SNMP packets from any host」をのラジオボタンをONにします。
そして「OK」を押せばSNMPの設定は完了です！

まとめ

以上でWindows Server 2016(英語版)へのSMPサービスのインストールすることができました。

SNMPをつかってZabbixなどの監視装置と連携することも可能です。
それらについてはまた別記事でご紹介しようと思います。

ひと目でわかる Windows Server 2016

Windows Server 2016 で拡張ネットワーキングをONにする【AWS】

AWS上のWindows Server 2016で拡張ネットワーキングをONにして見たいと思います。

そもそも拡張ネットワーキングとは？

拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。拡張ネットワーキングは追加料金なしで使用できます。

Linux の拡張ネットワーキング - Amazon Elastic Compute Cloud

ということです。
つまり有効にするだけで通信が早くなるというすぐれものです。

拡張ネットワーキングを有効にする手順

環境

• Windows Server 2016 Base
• m4.large

Intelネットワークドライバをインストールする

以下のURLからIntelネットワークアダプタドライバーをダウンロードします。

downloadcenter.intel.com

「ProWinx64.exe」というファイルがダウンロードされたかと思います。
それを「ProWinx64.zip」に拡張子を変更します。

「ProWinx64.zip」を展開します。

コマンドプロンプトを開き、「ProWinx64.zip」を展開したフォルダに移動して以下のコマンドを実行してINFファイルを追加/インストールします。

pnputil -i -a PROXGB\Winx64\NDIS65\vxn65x64.inf 

Windows Server をシャットダウンします。

拡張ネットワーキングを有効にする

ローカルのPCなどの別の環境でいかのコマンドを実行して拡張ネットワーキングを有効にします。
Trueと応答されればOKです。

AWSCLIの場合

aws ec2 modify-instance-attribute --instance-id  i-xxxxxxxxxxxxxxxx --sriov-net-support simple

PowerShellの場合

Edit-EC2InstanceAttribute -InstanceId i-xxxxxxxxxxxxxxx -SriovNetSupport "simple"

拡張ネットワーキングが有効か確認する

デバイスマネージャーを開き、「ネットワークアダプター」の下に「Intel(R) 82599 Virtual Function」があることを確認します。

インスタンスに拡張ネットワーキングの属性が設定されている確認します。
"Value": "simple"となっていればOKです。

AWSCLIの場合

 aws ec2 describe-instance-attribute --instance-id i-xxxxxxxxxxxxxxxx --attribute sriovNetSupport --query 'SriovNetSupport'

PowerShellの場合

Edit-EC2InstanceAttribute -InstanceId i-xxxxxxxxxxxxxxxx -SriovNetSupport "simple"

上記2つがOKであれば拡張ネットワーキングは有効化されています。

まとめ

有効にするだけで通信がはやくなるのでどんどん設定していきましょう！

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

AWSのキー管理を比較してみた【KMS/CloudHSM】

AWSで利用できるキー管理のそれぞれの利点についてまとめてみました。

KMS

キーの保存場所/制御方法

• AWSにキーが保存される
• AWSのサービスや、その環境で動作するアプリケーションでキーが利用できる

キーの管理

• 定義ポリシーをAWSが実行してキーの仕様を制御する
• AWSが責任をもって実行する

料金

• キー単位と使用量単位で料金がかかる

CloudHSM

キーの保存場所/制御方法

• AWS内で実行されるHSMにキーが保存される
• AWSのサービスや、その環境で動作するアプリケーションでキーが利用できる

キーの管理

• 自作のコードまたはSafenet APIでキーを管理することができる
• 自分たちで責任を持って管理する

料金

• 1時間あたりの課金
• CloudHSM Classicを利用する場合は前払い料金が発生する

3rdparty製ツール(AWS MarketPlace)

キーの保存場所/制御方法

• ツールによる(ローカル環境でもAWS内でも)
• EC2インスタンスでキーが利用できる

キーの管理

• ツール(ベンダー)による

料金

• 1時間あたりの課金または1年単位での支払い

自作ツールでの管理

キーの保存場所/制御方法

• ツールによる(ローカル環境でもAWS内でも)
• EC2インスタンスでキーが利用できる

キーの管理

• ツール(ベンダー)による

料金

• ツール(ベンダー)による(場合によっては安くすむかも)

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

VGWのパス決定の優先順位まとめ

VGWの外のトラフィックのパスに複数のオプションがある場合は、以下のようにパスが特定されます。

パス決定の優先順位

1→2→3→4の順にパスが特定されます。

1. 範囲の狭いIPアドレスプレフィックス
   172.24.0.0/16より172.24.1.0/24より172.24.1.1が優先される
2. 静的ルートを使用したVPN接続
3. Direct Connectのパス
4. AS_PATHを利用した動的(BGP)ルートを使用したVPN接続

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

AWS Well-Architected Framework 5つの柱まとめ

AWS Well-Architected Framework 5つの柱について自分なりにまとめてみました。

セキュリティ

• すべてのレイヤーをセキュリティで保護する。
• リソースの変更やインスタンス内部へのログインなどログを記録する。
• セキュリティの確保を自動化させる。

信頼性

• 障害からの復旧、回復が迅速にできるようにする。
• 障害からの復旧を自動化する。
• 可用性を向上するため適切にスケーリングを設定する。
• 長年の勘とかに頼らない。

パフォーマンス効率

• 最新の技術を導入してその恩恵をうける。
• 分単位でデプロイを行う。
• サーバレスアーキテクチャを利用する。
• 適切な技術を導入する。

コストの最適化

• 不必要なコストを排除する。
• データセンターへの投資をやめる。
• 支出を分析する。
• マネージドサービスを利用して使用量を抑える。

運用上の優秀性

• コードで運用作業を実施する。
• 変更処理を自動化する。
• 想定外の障害などに対応するためのテストを行う。
• 手順は常に最新に保つ。

参考資料

https://aws.amazon.com/jp/architecture/well-architected/ http://media.amazonwebservices.com/jp/wp/Well-Architected_Whitepaper_v2_JP.pdf

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

AWSの設計におけるベストプラクティス

AWSでの設定におけるベストプラクティスみたいなものを自分なりにまとめてみました。

スケーラビリティを確保する

• インフラをシームレスにスケールできることがAWSの利点。
• AWSのすべてのレイヤーでスケーラビリティを活用するべき。
• 理想的なシステムはスケールアウトするだけでなく、不要なインスタンスが稼働し続けないようにシステムをスケールダウンするようなシステム。

インフラ環境を自動化する

• リソースのプロビジョニング、終了、設定は可能な限り自動化する。
• 例えば異常のあるリソースの検出と代替リソースの起動を自動化する。
• リソースの変更時に通知を受信するようにする。

リソースを使い捨てにする

• 各インスタンスの設定を同一にし、リソースのデプロイを自動化する。
• 使用していないリソースは削除する。
• 固定IPアドレスはできるだけ利用せず、新しいIPアドレスに自動的に切り替える。
• 古いインスタンスと新しいインスタンスをかんたんに置き換えられるようにしておく。

疎結合化する

• 独立したサービスでアーキテクチャを設計する。
• システムのレイヤー間にAWSのマネージドサービスを活用して疎結合化させる。
• ELBとSQSを利用するとかんたんに疎結合に近づくことができる。

AWSのサービスを最大限利用して設計する

• すべてをEC2インスタンスのサーバの内部で実施するのではなく、AWSサービスを利用することを検討する。
• マネージドサービスを利用してサーバレス化させる。

データの特性にあったデータベースを選択する

• 要件にあったデータベースを適切に選んで利用する。
• Read/Writeやストレージのサイズ、レイテンシーなどを考慮する。
• データベースにあわせて業務を決めるのではなく、業務をもとにデータベースを洗濯する。

SPOFをなくす

• 一箇所の障害によってシステム全体が停止するのを避けるため、冗長性を保たせる。
• 物理ハードが故障した場合でもサービスを維持し続けられるように設計する。

コスト効率をあげる

• コストを最適化する。
• リソースのサイズやタイプが適切かどうか確認する。
• 使用されていないリソースを終了する。
• マネージドサービスを積極的に利用し、利用料を下げる。

キャッシュを利用して通信料を抑える

• CloudFrontなどのキャッシュサービスを利用する。
• キャッシュを利用することで通信コストやレイテンシーなどを軽減することができる。

セキュリティを確保する

• ユーザには権限は利用する最小の権限しか与えない。
• データのやり取りは暗号化する。
• アクセスログを記録する。

参考資料

AWS Black Belt Online Seminar 2016 クラウドのためのアーキテクチャ設計 -ベストプラクティス-

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

EC2Schedulerをつかってみる

今回はEC2SchedulerというAWS公式が提供しているEC2インスタンスの起動停止をスケジューリングできるツールを利用してみたいと思います。

EC2Schedulerとは?

AWS公式が提供しているEC2インスタンスの起動停止をスケジューリングできるツールです。
EC2に起動停止の時間などを記載したタグをつけることで、インスタンスを毎日自動的に起動/停止してくれます。

EC2Schedulerをつかってみる

実際にEC2Schedulerを使ってみたいと思います。

CloudFormationテンプレートのダウンロード

以下からec2-scheduler.templateをダウンロードします。

docs.aws.amazon.com

CloudFormationスタックをつくる

マネジメントコンソールのCloudFormationから「スタックの作成」を選択します。

「テンプレートの選択」でさきほどダウンロードしてきたec2-scheduler-.templateを選択します。
選択したら「次へ」すすみます。

「スタックの名前」に任意の名前をつけます。
「パラメータ」はデフォルトのままいったん「次へ」でかまいません。

オプションも一旦そのまま「次へ」でかまいません。

CAPABILITYの「AWS CloudFormationによってIAMリソースが作成される場合があることを承認します」にチェックをいれ、「作成」を選択します。

スタックが作成されるのでしばらく待ちます。
「状況」が「CREATE_COMPLETE」となったら完了です。

インスタンスにEC2Schedulerのタグをつける

EC2Schedulerでスケジュール起動停止したいインスタンスを選択し、タグを設定します。
設定するタグの例は以下の表に示します。
時間はUTCでしか記載できないので注意が必要です。

EC2Schedulerのタグの例

タグ値の例	説明
0800;1800;utc;all	インスタンスは08:00に開始し、18:00にすべての曜日に停止します。
1000;1700;utc;weekdays	インスタンスは1000から開始し、月曜日から金曜日の17:00に停止します。
1030;1700;utc;mon,tue,fri	インスタンスは1030に開始し、月曜日、火曜日、金曜日にのみ17:00に停止します。
0815;1745;utc;wed,thu	インスタンスは0815に開始し、水曜日と木曜日のみ1745に停止します。
none;1800;utc;weekdays	インスタンスは、月曜日から金曜日の18:00に停止します。インスタンスは手動で起動する必要があります。
0800;none;utc;weekdays	インスタンスは月曜日から金曜日の08:00に開始します。インスタンスを手動で停止する必要があります。
none;none;utc;weekdays	インスタンスは手動で開始および停止する必要があります（自動アクションは実行されません）。
0800	インスタンスは08:00に開始され、Amazon DynamoDBテーブルに格納されているデフォルトのアクティブ日にデフォルトの停止で停止します。
0800;1800	インスタンスは、Amazon DynamoDBテーブルに格納されているデフォルトの有効日数で、08:00に開始し、18:00に停止します。
0800;1800;utc	インスタンスは、Amazon DynamoDBテーブルに格納されているデフォルトの有効日数で、08:00に開始し、18:00に停止します。
default	インスタンスは、デフォルトのスケジュールで開始および停止します。
True	インスタンスは、デフォルトのスケジュールで開始および停止します。
EMPTY	インスタンスに対して実行されるアクションはありません。
Random String	インスタンスに対して実行されるアクションはありません。

以下公式ドキュメントから抜粋
Automated Deployment - EC2 Scheduler on AWS

EC2Schedulerが実行されたか確認する

マネジメントコンソールの「CloudWatch」から「メトリクス」、「EC2Scheduler」と選択します。

「Region」を選択します。

するとEC2Schedulerを設定したインスタンスのリソースIDを設定したが表示されるので、EC2Schedulerの実行状態を確認したいインスタンスのリソースIDを選択します。

グラフが0か1になっているのがわかるかと思います。
0が停止で1が起動です。
今回は1405;1420;utc;weekdaysと設定してみましたので設定通り14:05起動(1)、14:20に停止(0)されていることがわかります。

まとめ

EC2Schedulerをつかってインスタンスの自動起動停止を実施してみました。
夜間はインスタンスを停止するなど、コスト削減の基本ですのでこういったものを利用してみるのもいいかもしれません。

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

ALBでターゲットが全てunhealthyとなったときの動き

ALBでの動作

ALBでは対象のターゲットがヘルスチェックでunhealthyとなっても通信がターゲットに対して行われます。
そして、ALBでは正常なターゲットが含まれているAZがない場合、すべてのターゲットにリクエストをルーティングします。

おそらくフェイルオープンのような思想で設計されているのだと思います。

なにか障害が発生した際に全面断にするような運用をしたい場合には、セキュリティグループで拒否したり、待受ポート番号を変更したりなど、バックエンドインスタンス側に手を入れる必要があるかと思います。

参考:CLBでの動作

CLBの場合はヘルスチェックに失敗したインスタンスにリクエストをルーティングは行われない仕様で、動作に違いがありますので注意が必要です。

ですので全面断をかんたんに実装したい場合にはCLBのほうが適しているかもしれません。

Amazon Web Services　定番業務システム12パターン設計ガイド

Route53でTTLに0を設定したときの動作

Route53のTTLの設定は0から2147483647の間で設定することができます。

0を設定した場合は以下のような動作になります。

Route53でTTLに0を設定したときの動作

キャッシュせずに毎回、名前解決が実行されます。
そして、Route53からはTTL:0のレコードが返却されます。

(ただし、TTLに従って名前解決を行うかはクライアントやDNSキャッシュサーバの設定などに依存します。)

一般的にレコードをキャッシュさせたくない場合にはTTLに0などの短い値を設定するのが有効です。

参考

Nginxでのデフォルトの設定ではTTLにかかわらず名前解決を起動後の1回のみしか実施しない仕様になっています。

papix.hatenablog.com

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

旧バージョンのAmazonLinuxを利用する

マネジメントコンソール上からでは最新版Amazon Linuxしか選択することができません。

基本的には最新版の利用でかまいませんが、現行環境と環境を統一したいときなど、古いバージョンのAmazon Linuxを利用したいときがあるかと思います。

今回は最新ではないAmazon Linuxを入手する方法をご紹介します。

手順

EC2インスタンスの作成時に、コミュニティAMIを選択します。

そして検索で「Amazon Linux 2016」のように過去のバージョンを検索すると、該当のバージョンが出てきますのでそのAMIを利用してインスタンスを作成します。

ただ、コミュニティAMIは公式以外の第三者もAMIを公開しています。
公式のものが利用したい！という場合には以下のAWS CLIを実行し、amazonと表示されれば公式のものです。

aws ec2 describe-images --image-ids ami-xxxxxxxx --region ap-northeast-1 --query 'Images[].ImageOwnerAlias'

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

AWSCLIでS3全体を暗号化する

AWSCLIのaws s3 cpコマンドではオプションで--sseを指定することでAES256で暗号化することが可能です。

この際にコピー元とコピー先に同一のパスを指定することでパスを変えずに、オブジェクトを暗号化することが可能です。
具体的には以下のようにコマンドを実行します。

 aws s3 cp s3://kabegiwa-bucket/ s3://kabegiwa-bucket/ --recursive --sse

コピー元とコピー先にバケットを指定し、--recursiveで再帰的に--sseで暗号化しています。

また、このコマンドをcronなどに設定することで定期的にバケット全体を暗号化することが可能です。

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-