この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2020/5/26 クラスメソッド株式会社主催「活用パターンから学ぶ！AWSコスト最適化ウェビナー」にご参加頂いた方から頂戴した質問と、その回答を公開します。
Q&A
Q. Savings Plansと比べたReserved Instanceの利点はなにか残っていますでしょうか？
A. Standard リザーブドインスタンスの場合、AZ指定にはなりますがキャパシティ確保が保証されるメリットはございます。（インスタンスタイプの枯渇を回避） こちらのブログに比較表などがございまので、ご参考になれば幸いです。
Q. CostExploererでSavingsPlans適用対象リソースについて、各サービス別(EC2等)で表示する方法はございますでしょうか
A. サービス別に表示する方法が現時点で用意されておりません。 例として、Fargateのコミット額を決めるような際には、Cost & Usage Report で過去のFargateの利用費のみを抽出してコミット額を決めていく必要があります。
Q. S3やCloudWatgh ECR 等にVPCエンドポイントを置く場合のデメリットや気をつけたほうが良いことはありますでしょうか？
A. VPCエンドポイントが利用できるのは同一リージョン内のみになります。S3（ゲートウェイタイプ）の場合、エンドポイント料金は必要ありませんが、その他のサービス（インタフェースタイプ）についてはエンドポイント毎に料金が発生するという点ではコスト面のデメリットがございます。
Q. EC2上パッケージを乗せる場合、メーカーの最小値を参考にサイジングするのが妥当でしょうか？
A. パッケージ製品だとパッケージ側のサポート受けれない可能性あるので必須要件は満たす必要あると思います。
Q. EC2リソース等を見直しで、CloudWatchのグラフでCPUやメモリ等のグラフから判断する場合、チェックすべきポイントはAWS公式等でまとまっているのでしょうか？それとも自身の判断ではなく、はじめからAWS Compute Optimizer を利用するのが無難なのでしょうか？
A. システムごとに特性が異なりますので、チェックすべきポイントはシステムごとにご判断頂く必要がございます。AWS Compute Optimizer の推奨値も同じシステムごとに判断頂く必要がございますので、参考としてご利用ください。
Q. 同リージョン内、別AZ間の「EC2インスタンス同士」もしくは「EC2⇔RDS」の通信は料金がかかるが、同リージョン内、同AZ内の「EC2インスタンス同士、EC2⇔RDS」の転送料金はかからないという認識であっていますか？
A. ご認識のとおりです。
Q. EC2 インスタンスについて、T3 ではなく T3a を利用する上での注意する点として、何かありますでしょうか？
A. 東京リージョンで 「T3A」が利用できるアベイアビリティゾーンは、 ap-northeast-1a (apne1-az4)、ap-northeast-1d(apne1-az2) の2つになりますので、ご注意ください。また、ソフトウェアによってはインストール時にCPU判定をして非対応が起こりうる可能性はございます。「T3」からの移行をご検討の際は、AMIを取得し動作確認をお願いいたします。
Q. 東京リージョンでなく北米リージョンにEC2インスタンスを作成するにあたり、なにか法的な違いを考慮する必要はありますか？
A. 個人情報やソフトウェアが海外で取り扱われることで何か懸念をされているようでしたら、自社の法務部に規制がありますかご確認ください。どうすれば規制に準拠できるかについてはAWSのセキュリティに関するホワイトペーパーなどを参照してください。 北米リージョンを開発環境としての利用目的で気になされているようでしたら、開発にはダミーデータを用いるなどして気をつけていただければと思います。
Q.日本向けサービスで東京以外のリージョンを用いる場合、気をつけるべき大きなポイントはレーテンシー以外にありますか？
A. その海外リージョンのみを使うのであればレイテンシーが許容されますか、気をつけていただければと思います。もし海外リージョンと東京リージョン間でデータのやりとりが発生する場合、リージョン間のトラフィックとなりネットワークコストが割高にならないか注意は必要です。
Q. 改善レポートの内容は、Trusted Advisorの内容とほぼ同様で、より具体的な改善アイデアなどを担当者が付加してくれるような感じではない、というイメージでしょうか。
A. ご認識の通りです。改善レポートでは何かしら担当者が付き、提案を行う類のものではございません。
Q. S3バケット料金の節約を検討しております。ざっくりで恐縮ですが、何かポイントがあればご教示頂けますでしょうか？
A. S3は以下の方法でコスト最適化いただけます。
ストレージクラスを活用する
長期間保持が不要なログなどについては、ライフサイクルの設定を行い、一定期間後に削除します。
長期間保持するオブジェクトにいてストレージクラスの変更を検討ください。S3は以下のストレージクラスが用意されております。ライフサイクルポリシーで、オブジェクトの作成日に基づいてストレージクラスを移動いただけます。
| ストレージクラス | 説明 |
|---|---|
| Starndard(標準) | よくアクセスされるデータ向け |
| Standard-IA (標準-低頻度アクセス) | 長期保管で、あまりアクセスされないデータ向け |
| One Zone-IA | 長期保管で、あまりアクセスされず、クリティカルではないデータ向け |
| Glacier | 長期保管で、あまりアクセスされず、アーカイブするクリティカルなデータ向け |
例として、アクセスログを最初はStarndard、3ヶ月後からStandard-IA、半年後からGlacierというように段階的に移動させることができます。
なお、Glacierにつきましては、取り出す場合に時間とお金がかかってしまい注意が必要です。取り出すことは基本ないけど、保存はされておかないといけないというような要件でご検討ください。
各ストレージクラスの料金につきましては、以下を参照ください。
Amazon S3 の料金
S3 Intelligent-Tieringを使用する
S3 Intelligent-Tieringは、実際のアクセスパターンに基づいて、高頻度/低頻度という2つのアクセス階層のストレージに自動移動します。低頻度アクセス階層では高頻度アクセス階層よりも安価に利用できます。
S3 Intelligent-Tieringは手軽に設定でき、レイテンシも気にならず大変使いやすいです。ただし、Standard-IAのほうが低頻度アクセス階層よりもコスト削減できますので、事前にアクセスがないと予想されるなら最初からStandard-IAを設定ください。アクセスが読めない場合は S3 Intelligent-Tiering と使い分けていただければと思います。
不完全なマルチパートアップロードファイルを削除する
マルチパートアップロードファイルは、複数の部分ファイルを同時に送信して広帯域のネットワークを有効に利用できますが、失敗時は無駄なファイルが残ってしまいます。
無駄なファイルが蓄積しコスト増の原因になっていることがありますので、マルチパートアップロードを行っているバケットでは定期的にクリーニングされるように設定が推奨されます。
無駄なファイルの調べ方や設定方法の詳細につきましては以下のブログを参照ください。
ウェビナー資料
当日使用した資料はこちらになります。
0
