AWSのITコストを削減 Simpline

選ばれ続けること

 

エンジニアブログ

ホーム - エンジニアブログ - 2015年10月

EC2Configの機能を利用したカスタムメトリクスを試してみました①

2015.10.30

batchiです。
EC2Configの機能を利用したカスタムメトリクスを試してみたので、
2回に分けて紹介したいと思います。

プロローグ


メモリの使用率やディスクの空き容量をCloudwatchでモニタリングしたい。WindowsServerで。
標準メトリクスには含まれていないので、カスタムメトリクスとして設定する必要がある。
どうやらそれを実現するためのサンプルスクリプトが提供されているようだ。

ということで探してみたところ該当ページを見つけたのでアクセスしてみると、
http://aws.amazon.com/code/7932034889155460

WS000000

Errorが。
何ということでしょう。

調べていくうちに、どうやらもうサンプルスクリプトの
提供はされていないようだとじわじわ理解していきますが、
念のためサポートに問い合わせてみます。

回答の要旨は以下のとおり。

・現時点では提供していないですよ
・代替案としてEC2Configによる送信機能をお勧めしていますよ
・サンプルスクリプトの機能は包含されていますよ
・詳しくは下記ドキュメントを参照してくださいよ
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/UsingConfig_WinAMI.html#send_logs_to_cwl

ということで改めて上記のドキュメントに沿って設定していきます。

設定


http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/UsingConfig_WinAMI.html#send_logs_to_cwl
-CloudWatch へのパフォーマンスカウンタの送信と CloudWatch Logs へのログの送信

上記のドキュメントには情報が盛り沢山なので、
今回試したいことに必要な部分だけかいつまんでいきます。

(Coudwatch Logsに関する部分はすべてスキップします)
 


ステップ 1: IAM のアクセス許可を設定する


IAMユーザーないしIAMロールで設定。
今回はcloudwatchに対するアクションだけの権限を持った
IAMユーザーを作成してみました。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:*"
],
"Resource": [
"*"
]
}
]
}





ステップ 2: CloudWatch Logs 統合を有効にする


プログラムからEC2ConfigService Settingsを開き、
Enable Cloudwatch Logs integrationのチェックボックスをポチッとします。

ドキュメントには下記のような記述がありますが、
4.AWS.EC2.Windows.CloudWatch.json という名前の構成ファイルを作成します。

私が試した環境ではすでに該当の構成ファイルがサーバ内に存在していたので、
「作成」というよりは「編集」というほうがしっくり来ます。

ステップ3以降は上記Jsonファイルに関わる工程となりますが、
予め作成しておいて格納するもよし、
直にメモ帳などで開いて編集するもよしです。



ステップ 3: CloudWatch と CloudWatch Logs の認証情報を設定する


JsonファイルのCloudwatchセクションを探し、
パラメータを入力します。



















AccessKey ステップ1で作成したIAMユーザーのアクセスキー。
※IAMロールの場合は不要
SecretKey 同上。シークレットキー。
Region Cloudwatchのリージョン。
NameSpace 名前空間。
Cloudwatchの画面上の表示にも影響してくる※下画像参照

名前空間
「カスタムメトリックス」の下の、
青く塗りつぶしている部分にNamespaceの値が表示されます。

通常のメトリクスでは「AWS/EC2」「AWS/S3」のような値が入っている部分です。


ステップ 4: CloudWatch と CloudWatch Logs に送信するパフォーマンスカウンタとログを設定する


ここがなかなか個人的に苦労した部分なので、
以降の手順を次回の更新に回して説明していこうと思います。

それではまた。

AmazonLinuxにModSecurityをインストールした際のメモ

2015.10.30

T2.microです。
AmazonLinuxにModSecurityをインストールした際のメモを記載します。

環境


OS


AmazonLinux
・amzn-ami-hvm-2015.03.0.x86_64-gp2

web


Apache
・httpd-2.2.29-1.5.amzn1.x86_64

WAF


mod_security
・mod_security-2.8.0-5.27.amzn1.x86_64
・mod_security_crs-2.2.8-2.5.amzn1.noarch

 

注意点


1.ルールの適用については必ずテスト環境で導入試験を行うこと


これはWAF導入の際はもちろんのこと、
WAF自体とルールのアップデートを行う際にも必ず実施する。

2.性能面での考慮


適用するルールが増えるとその分レスポンスが遅くなることに注意する。

 

導入


ModSecurity本体をインストールする
 #yum install mod_security

OWASP Core Rule Set(セキュリティールール)をインストールする
#yum install mod_security_crs

Apacheを再起動する
/etc/init.d/httpd restart


 

設定ファイルを修正


● /etc/httpd/conf.d/mod_security.conf
<IfModule mod_security2.c>
# Default recommended configuration
SecRuleEngine On #On → DetectionOnly

DetectionOnly にすることで攻撃を検知しても
アクションを行わずにログに出力するのみとなる。

 

● /etc/httpd/conf.d/mod_security.conf
# Include modsecurity.d/activated_rules/*.conf
Include modsecurity.d/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf

たとえばSQLインジェクションのルールのみを使用する場合は上記のように、
Include modsecurity.d/activated_rules/*.confをコメントアウトし、
modsecurity_crs_41_sql_injection_attacks.confのみをIncludeする。

 

ログの確認


デフォルトでは以下のファイルにログが出力される。
(ログの出力先は/etc/httpd/conf.d/mod_security.confに書いてある)

/var/log/httpd/modsec_audit.log
正常なリクエストが攻撃と判定されている可能性があるかを事前に確認しましょう。

 

参考


http://dev.classmethod.jp/cloud/ec2-wafweb-application-firewall/
http://dev.classmethod.jp/cloud/aws/ec2-amazon-linux-waf-modsecurity-install/
http://j-caw.co.jp/blog/?p=1331

分析におけるAWS導入事例を集めてみました!

2015.10.21

~今回のテーマは、分析におけるAWS導入に関する事例です。
以下に比較してみます。

 






























 比較項目

 株式会社ベルシステム24ホールディングス 様

 AWS選定理由

 『最も速く低コストにかつ高性能に実現できると判断』

 カスタマーエクスペリエンスの向上を目指すために検討を開始。
 大量のデータを瞬時に分析する必要性と極力早く低コストでつくりあげる必要があった。
 その中でAWS上に構築するのが最も速く低コストにかつ高性能に実現できると判断した。

 導入効果

 『コスト、期間ともに最小で分析環境を構築』

 自前で構築した場合の数百分の1(数ヶ月想定が1週間)で完成。
 100億件のデータを瞬時に分析できるようになった。
 また付帯効果として、インフラ部分の人的リソースを開発などの上流にシフトできた。

 利用している主な
 AWSの機能

 Amazon VPC、Amazon EC2、Amazon Direct Connect、
 Amazon Cognito、Amazon S3、Amazon Route 53、
 Amazon Redshift、Amazon CloudSearch

 AWS事例ページ


 






























 比較項目

 株式会社NTTドコモ 様

 導入理由

 『オンプレミス同等の運用が可能、かつ拡張性を踏まえて選定』

 安全性を担保するために、オンプレミス以外では基準をクリアすることは
 厳しいと考えていた高い情報セキュリティ基準をクリアできた。
 さらに、AWS のプロフェッショナルサービスの支援を受けながら、
 拡張性等も踏まえて選定をした結果、AWS 製品を採用するにいたる。

 導入効果

 『システム間連携の容易性と高い拡張性』

 AWS で稼働している多くのシステムと設定の変更のみでシステム連携が可能となった。
 メインのデータの分析は Amazon Redshift で実行しているが、
 用途に応じてデータを切り出したり、
 事前・事後処理を行ったりといった拡張が可能となった。

 利用している主な
 AWSの機能

 Amazon VPC、Amazon EC2、Amazon Direct Connect、
 Amazon S3、Amazon RDS、Amazon Redshift

 AWS事例ページ


 






























 比較項目

 株式会社インティメート・マージャー 様

 導入理由

 『調達が迅速に行え、運用負荷軽減につながるサービスが豊富』

 データの急増、増加するシステムの開発案件への対応の為、
 少人数でもスピード感をもってインフラ基盤を構築でき、
 日々蓄積されていく運用上の負荷をいかに軽減できるが重要な課題であった。
 AWSは調達が迅速に行えること、運用負荷を軽減するマネージドサービスが
 豊富であることも採用の大きな決め手となった。

 導入効果

 『規模をスケールさせる速さが飛躍的に向上、運用も安定』

 ①マネージドサービスを利用②サーバを構築する際はオートスケールを利用
 とすることで規模をスケールさせる速さが飛躍的に向上。
 運用面でもマネージドサービスを中心にした各機能の拡充を行っていった結果、
 サーバー台数が当初の10 倍超になった今も安定して運用できている。

 利用している主な
 AWSの機能

 Amazon VPC、Amazon EC2、Amazon ELB、Amazon SQS、
 Amazon S3、Amazon Route 53、Amazon RDS、
 Amazon CloudFront、Amazon ElastiCashe、AWS Lambda

 AWS事例ページ


http://www.infilic.co.jp/