RIの推奨事項に表示されるEC2がSavings Plansで表示されない原因
はじめに
EC2が数台フル稼働しているAWSアカウントがあり、コスト削減しようと思ってCost Explorerから推奨事項を覗いてみました。
すると、RIの推奨事項では台数分きちんと表示されるにも関わらずEC2 Instance Savings Plansの推奨事項がないと出ました。
これはバグか...？と思ったのですが、ドキュメントに記載のある内容だったのでメモとして残しておきます。
事象
EC2が数台フル稼働しているアカウントでのRIの推奨事項
ここでは3個のRIの購入を薦められました。
同じアカウントでEC2 Instance Savings Plansの推奨事項
こちらでは1つも推奨事項がありませんでした。
EC2のRIとEC2 Instance Savings Plansは削減率が同じで同等のものだと思っていたのでなんでだろう(´～`)？と不思議に思っていました。
原因
EC2 Instance Savings Plansの推奨事項の画像の一番下に答えが出ていました！
選択したルックバック期間中、平均オンデマンド支出が 0.10 USD/時間未満である。
こちらが原因でした。
たしかにEC2を数台フル稼働していたもののオンデマンド金額では$0.1/時間以下でした。
きちんと書かれているのにまったく気づかなかったので逆にびっくりしましたね...。
ちなみにAWS公式ドキュメントですと以下に書かれています。現在英語のみ。
Understanding your Savings Plans recommendations - Savings Plans
Recommendations are generated for customers that have an average On-Demand spend of $0.10/hour during the lookback period (7, 30, or 60 days). If you recently purchased a Savings Plan, or if your Savings Plans recently expired, it might not be reflected in your Recommendations for up to 24 hours.
EC2 Instance Savings PlansだけでなくCompute Savings Plansの方も基準額（$0.1/時間）に満たない場合は推奨事項が表示されないようです。
おわりに
EC2 Instance Savings Plansにフル稼働のEC2が表示されないのにCompute Savings Plansの方は表示されたので、Compute Savings Plansの方にEC2分の料金が含まれていないのでは？と疑ってしまいました。
Compute Savings Plansの推奨事項は表示された時点でEC2,ECS,Lambdaのすべてのリソース分が含まれているんですね。
EC2が数台だけフル稼働しているアカウントでしか見られない事象で勉強になりました。
以上。
AWS 認定セキュリティ – 専門知識 (SCS-C01) に合格したのでメモ
はじめに
現状でAWSで出している認定は以下です。
参考（AWS 認定 – AWS クラウドコンピューティング認定プログラム | AWS）
プロフェッショナル認定は2019年1月に取得していて、そろそろ専門知識認定に手を出そうと思っていたので実務と関係があるセキュリティの専門知識を受けてみることにしました。
特にコンプリート欲はないので現業では他認定はスルー予定(ﾟεﾟ)。
プロフェッショナル認定取得時の記事。
rioner2525.hatenablog.com
試験で出そうな分野
試験内容の主な概要は以下の通りかなと思います。
分野1 インシデント対応 (12%分)
- セキュリティ侵害の疑いがあるインスタンスやアクセスキーをどうするか問題。
- 自動的にアラート出す構成にできるか問題。
- 具体的なインシデント例にどう対応するか問題。
分野2 ログ収集と監視 (20%分)
- 監視、アラートの構成にできるか、トラブルシューティングできるか問題。
- ログ収集の構成にできるか、トラブルシューティングできるか問題。
分野3 インフラストラクチャのセキュリティ (26%分)
- IAMなどのAWSサービスで不正アクセスされない構成にできるか問題。
- セキュアなネットワークインフラストラクチャの構成にできるか、トラブルシューティングできるか問題。
- ホストベースのセキュリティに関する問題。
分野4 ID とアクセスの管理 (20%分)
- AWSリソースへのアクセス認証および権限付与のシステムを構成できるか、トラブルシューティングできるか問題。
分野5 データ保護 (22%分)
- KMSキーの管理および使用に関するシステムを構成にできるか、トラブルシューティングできるか問題。
- 保存時および転送中のデータを暗号化するシステムを構成できるか問題。
参考（試験ガイド）
やった方がいいかもなこと
AWSのセキュリティ関連サービスを理解する
- AWS Black Belt の資料なら Security, Identity & Compliance あたりのサービスは確認しておく（できれば実機確認）。
- 他にもセキュリティグループとかNACLの動作とか他サービスのセキュリティ関連リソースも確認。
- 余裕があればKMSはCLIまで確認。
練習問題を解く
余裕があれば...
- Whizlabsの練習問題($20ぐらい？)を購入して解いてみる。→ 投稿主はこちらで購入しました。
- udemyで練習問題(1200円ぐらい？)を購入して解いてみる。
多分どちらもブラウザから日本語翻訳できると思います。少なくともWhizlabsの問題はある程度把握できるレベルで翻訳できていました。
問題文が意味不明に感じたら英語で読みましょう...
オンライン講習を受ける
- AWSパートナーネットワークに属しているならパートナー向けトレーニングから certified security などと検索してEラーニングや講習動画を確認する。
余裕があれば...
日本語字幕などは付けられないと思ったので投稿主は購入していません...
英語のリスニングができる人はudemyのコスパが良さそう。
感想
Whizlabsの練習問題をだいたい解けるレベルにしてから受験したら1発合格できました。
(･´ｰ･｀)
全く同じ問題は1問も出ませんが似たような問題が出たので参考になりました。
ただやはり全く使ったことのないサービスについてはミスが多かったです。
出来る限り実機を触って覚えることが大切なので、練習問題でミスったときはホントか～？と疑って実機確認しましょう！
Configルール一覧まとめ
はじめに
AWS基盤のガードレール構築のためにConfigルールを調査する機会があったので共有です。
公式ドキュメントは以下です。
AWS Config マネージドルールのリスト - AWS Config
公式ドキュメントが見づらいなぁと思ったので一覧で見れるようにまとめたものを置いておきます。
※内容は投稿時のものであり、参考にする際は必ず公式ドキュメントも確認してください。
Configルール一覧
めっちゃ見づらくなってしまった..._(:3｣∠)_
必要に応じてExcelだかスプレッドシートだかにコピペして見た方がいいかもです。
CloudWatch エージェントをインストールしてEC2から自動ログ吐き出し
はじめに
Cloudformation から EC2 インスタンスを立てる作業をしていたのですが、自動でログを吐き出して欲しいと言われて実装したときのメモです。
今回吐き出したいログは以下。
- /var/log/messages
- /var/log/secure
- scriptコマンドで吐き出されるログ
ssm はよく分かっていないので今回は使っていません。
使えるとssm経由でCloudWatch エージェントを管理できるので、もうちょっと楽にできるかもです。
必要な素材を用意
CloudWatch エージェント
公式ドキュメントからサーバのプラットフォームに応じて最新版をダウンロード。
Amazon Linux2 だと以下です。
今回は自アカウントのS3バケットに事前に置いておきました。
CloudWatch 用設定ファイル作成
公式ドキュメントを参考に作成。
今回はカスタムメトリクスを吐き出しとかはないので metrics セクションは不要です。
サーバ内でログが置いてある場所とCloudwatch ロググループでの吐き出し先を設定するだけです。
タイムスタンプも出してくれるのでscript側で気にすることはありません。
以下、具体例です。
ファイル名：awslogs.json
{
"agent": {
"run_as_user": "root",
"region": "ap-northeast-1",
# Cloudwatch エージェント自体のログ吐き出し場所。ログ吐き出しがうまくいかないときに確認します。
"logfile": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log"
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
# サーバ内ログ配置場所
"file_path": "/var/log/messages",
# ログ吐き出し先 Cloudwatch ロググループ名設定
"log_group_name": "ec2-messages.log",
# ログ吐き出し先 Cloudwatch ログストリーム名設定
"log_stream_name": "ec2-messages.log",
# タイムスタンプ形式設定
"timestamp_format": "%b %d %H:%M:%S"
},
...吐き出したいログの分をそれぞれ記載
]
}
},
# ログ吐き出し先のデフォルトになる Cloudwatch ログストリーム名設定
"log_stream_name": "ec2"
}
}
EC2起動時にユーザデータで自動設定するため、作成したawslogs.jsonファイルを自アカウントのS3バケットに事前に置いておきます。
ユーザデータ設定
messages、secureログは自動で出るのでscriptコマンドをユーザデータで仕込みます。
また、ユーザデータでコマンドを打ち込むときはエスケープが必要なこともあるので考慮しましょう。
以下、具体例です。
#!/bin/bash
# scriptコマンドを仕込む。
cat <<EOL >> /etc/profile
P_PROC=\`ps aux | grep \$PPID | grep sshd | awk '{ print \$11 }'\`
if [ "\$P_PROC" = sshd: ]; then
sudo script -faq /var/log/script
exit
fi
EOL
# 用意した CloudWatch エージェントをダウンロードしてインストール
aws s3 cp s3://バケット名/amazon-cloudwatch-agent.rpm /tmp/
rpm -U /tmp/amazon-cloudwatch-agent.rpm
# 用意した CloudWatch 用設定ファイルをダウンロード
aws s3 cp s3://バケット名/awslogs.json /tmp/
# 設定ファイルを指定して CloudWatch エージェント起動。
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/tmp/awslogs.json -s
ログ確認
うまくいくと CloudWatch ロググループからログを確認することができます。
scriptコマンドの操作ログについてはエスケープシーケンスも記録されてしまうため、精査するときは整形する必要があります。
おわりに
サーバに入らなくてもログを確認できるので楽できていいなぁと思いました。
特に後でどんなコマンド打ったっけーというのがマネジメントコンソールで確認できるのが助かります。
CloudWatch エージェントは監視でよく使われますが監査用(調査用)対策としても優秀ですね。
以上です。
個人的にCloudformation(yaml)でよく書くやつメモ
はじめに
私がCloudformation用のyamlテンプレート書くときにたびたび忘れるやつをメモしておきます。
パラメータ並び替え
Cloudformation スタック作成時にパラメータ入力を求めると、並びがランダムになってしまう。
Metadata の機能を使って並び替えを行う。
Parameters:
test1:
Description: test1 dayo
Type: String
AllowedValues:
- 1
- 2
Default: 1
test2:
Description: test2 dayo
Type: Number
Default: 1
test3:
Description: test3 dayo
Type: AWS::EC2::SecurityGroup::Id
Default: ""
Metadata:
AWS::CloudFormation::Interface:
ParameterGroups:
-
Parameters:
- test1
- test2
- test3
Resources:
...
Subの使い方
Sub は文字列の中で使う変数のような関数。
!Sub ${String}-test みたいに使う。この場合のStringに入れる文字列としてよく使うものはパラメータ､リソースの論理 ID･リソース属性｡
Parameters:
test:
Description: test dayo
Type: Number
Default: 1
Resources:
S3Bucket:
Type: AWS::S3::Bucket
Properties:
...
リソース例:
Type: AWS::xxx::xxx
Properties:
入力したパラメータ使用: !Sub ap-northeast-${test}
疑似パラメータ使用: !Sub com.amazonaws.${AWS::Region}.s3
他のリソースID使用: !Sub arn:aws:s3:::${S3Bucket}
他のリソース属性使用：!Sub ${S3Bucket.Arn} = !GetAtt S3Bucket.Arn 1つ上と同じ
UserData コマンド
UserData をテンプレートに仕込むときは !Sub のあとに | が必要。
また、!Base64 !Sub のように省略した関数の連続はNG。Fn::Base64: !Sub のようにどちらかは省略しないで書く。(参考)
UserData:
Fn::Base64:
!Sub |
#!/bin/bash
...
その他
なんか気づいたら追記します。
DeletionPolicy
DependsOn → お互いに依存しあうとエラーになるので注意。
Resources:
リソース例:
Type: AWS::xxx::xxx
DeletionPolicy: Retain # スタック消してもリソースが残ってほしいときに記載する。
DependsOn: # 記載すると指定したリソースが作成された後にこのリソース作成が行われる。
- SubnetA
- SubnetD
Properties:
...
