Learn about AWS in 大阪「AWS環境の最適化を目指そう！～導入後のよくある課題の解決策は？～」セッションレポート
2025年2月6日、グランフロント大阪にて「Learn about AWS in 大阪」が開催されました。本ブログでは、Learn about AWS in 大阪に実際に参加したOps Today編集部員から、イベントの様子や講演レポートをお届けします。
今回は、Modern Infra Trackにて14時から開催されたセッション「AWS環境の最適化を目指そう！ ～導入後のよくある課題（コスト・セキュリティ・運用・ネットワーク）の解決策は？～」をリポートします。
Learn about AWS in 大阪とは？
Learn about AWS in 大阪は、ソニービズネットワークス株式会社主催、アマゾン ウェブ サービス ジャパン合同会社講演協力のもと、「AWS」 「生成AI」 「モダンインフラ」をキーワードとしたイベントです。幅広い技術レベルの人を対象としたセミナーセッションや、AI・AWSに関する各種展示・相談コーナーが設けられました。
今回Ops Today編集部では、大阪でAWSのイベントが開催されるという噂を聞きつけ足を運びました。ソニービズネットワークス株式会社、講演協力のアマゾン ウェブ サービス ジャパン合同会社の取材協力のもと、イベントの内容について詳しくお届けします。
セッション概要
| セッションタイトル | AWS環境の最適化を目指そう！ ～導入後のよくある課題（コスト・セキュリティ・運用・ネットワーク）の解決策は？～ |
| 概要 | 「 AWSを使い始めてもうXX年、インスタンスも増えて活用範囲も拡がってとても活躍してくれている、だけど一方で…」とAWS利用ユーザから弊社が良く相談される「コスト最適化」「セキュリティ維持管理」「運用自動化」「ネットワーク最適化」などを取り上げ、それら各課題をモダンインフラを活用してどう解決していけば良いか解説いたします |
| 登壇者 | ソニービズネットワークス株式会社 インテグレーション部クラウドCS課 ※2024 Japan AWS ALL Certifications Engineers に選出 折笠 丈侍 |
AWS導入後によくいただく相談
ソニービズネットワークス株式会社にて、AWSのプリセールスを10年務める折笠氏によると、お客様から以下のご相談が多く寄せられるそうです。
- コスト ※相談数は最多
円安、リソース増から増大したコストについて、どこをどう削れば良いのか？ - セキュリティ
現状のセキュリティに問題がないか？ - ログ・監視・トレース
オブザーバビリティを確保し、見える化したいがどこまでやるべきか。万が一の時の復旧方法は？ - 災害・脅威への対応
クラウド側で大規模災害が発生した時、どういった手順で復旧すればよいのか？
課題解決の目安：AWS Well-architected Frameworkを参照する
初めに、こうした課題を解決するための基本的な目安としてAWS Well-architected Frameworkが紹介されました。
AWS Well-architected Frameworkとは、AWS側が公式に提示しているシステム構築時のベストプラクティスを示すフレームワークです。
AWS Well-Architected フレームワークは、AWS でシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。このフレームワークを使用することによって、信頼性が高く、安全で、効率的で、費用対効果が高く、持続可能なシステムを設計して運用するための、アーキテクチャに関するベストプラクティスを学ぶことができます。
―AWS公式：AWS Well-Architected フレームワーク
このフレームワークには、以下の6つの柱が存在します。
このフレームワークは項目数も多く、すべて網羅しようとすると労力がかかります。よって、フレームワークの中から各ユーザー・企業ごとに必要なものからピックアップして実装していくことが勧められました。
AWS Well-architected Frameworkを押さえる上での課題
このフレームワークを押さえる時には、以下のような課題が生じてしまいます。
ベストプラクティスの項目数が多い
ベストプラクティスは全部で52項目も存在します。ゆえに、前述の通りこれらをすべてを網羅してAWSを利用開始しようとすると、莫大なコストと労力がかかります。
不可逆な設定値
ベストプラクティスの項目の中には、一度設定すると変更が出来ない/困難な項目があります。事前に検証してからの設定が推奨される項目については、ユーザー自身で検証・設計を行ったうえで設定を進める必要があります。こうした設計については、知見のあるAWSパートナーに相談することも一つの選択肢として考えられます。
まずは可観測性（オブザーバビリティ）から
オブザーバビリティ、つまり何を使い、どのようなツールで、どこまでモニタリングしていくのか？という検討を進める場合、まずはシステム自体の目的から見直していきます。
システムを利用するとき、そのシステムの稼働自体が目的であることはほぼないでしょう。実際の目的はそれぞれの企業の課題（ビジネスKPI）を達成することです。こうした企業の課題解決やビジネス目標に大きく関係する項目にフォーカスして進めていくことで、ノイズやコストを削減することが可能となります。
またオブザーバビリティには、以下の基本的な3つの柱があります。各項目にはこれらを取得するためのAWSのサービスを並べています。こうしたサービスの中から、ビジネス目標と照らし合わせて必要なサービスの選定を行うと良いでしょう。
- ログ
- AWS Cloudwatch logs (OSログ)
- AWS CloudTrail （APIコールログ）
- VPCフローログ（VPC内部トラフィックログ）
- 各AWSサービスのアクティビティログ
- AWS Systems Manager （アプリケーションログ）
- メトリクス
- Cloudwatch metrics
- トレース
- AWS X-Ray
アプリケーション分散トレース - AWS Distro for OpenTelemetry
オープンソースの分散トレーシングフレームワーク
- AWS X-Ray
オブザーバビリティの実装ガイドを活用する
オブザーバビリティのベストプラクティスもAWSが公開しています。
この中には、オブザーバビリティの基本的な考え方から、AWS CloudFormationやTerraform（テラフォーム）といったIaCツールを使って簡単にオブザーバビリティの全体のパッケージが実装できるツールも用意されています。オブザーバビリティの優先順位付けを行う際の手引きとして利用すると良いでしょう。
コスト最適化
コスト最適化は最もご相談が多い内容とのことです。まずは、AWSの課金の仕組みや料金要素を確認します。
AWSの料金要素として、以下の4つがあげられます。一般的には、1から順に多くの割合を占めます。
- ストレージ利用料
プロビジョニング（利用すると宣言）した量に課金が発生します。実効データ量が基準ではないため注意が必要です。 - サービス利用料
単価×稼働時間の従量課金制です。 - ネットワークデータ転送量
AWSから外部へ出ていくデータ転送量に対して、GB単位での課金が発生します。 - APIリクエスト回数
回数ベースで課金が発生します。単価は低いですが、モダンでクラウドネイティブなサービスの場合、リクエスト回数が跳ね上がることがあるので注意が必要です。
こうしたAWSの利用料には、ユーザーの責任範囲だったものをAWSに移すことが出来る、という付加価値が含まれています。クラウドネイティブな構成にすればするほどに、セキュリティ・可用性・運用管理といった部分をAWSに任せることが出来ます。
またAWSを利用することで、最新の設備が利用できるようになる、可用性・迅速性・拡張性・安全性の向上、管理工数の削減なども実現できます。結果的に、企業の競争力を上げたり、担当者の管理工数の削減につながり、ユーザーが本来注力したい部分に集中できるといった利点があります。ビジネス目標や企業課題の解決に向けたシステム構築にAWSを活用する理由として、こうした付加価値についても説明できると良いでしょう。
コスト最適化の役に立つツール
前述の通り、AWS利用料のうちストレージとコンピューティングがコストの多くを占めています。現状の構成で余剰リソースや余剰課金をあぶりだすためには、以下のようなツールが有用です。
- Compute Optimizer
AWSリソースの使用状況を分析し、最適なインスタンスタイプやサイズを提案します。 - Trusted Advisor
AWSのベストプラクティスに基づいて、アカウントの設定やリソースの使用状況をチェックし、セキュリティ、コスト削減、パフォーマンス向上などの提案を行います。 - Cost Explorer
AWSのコストと使用状況を視覚化し、分析するためのサービスです。過去の支出を確認したり、将来のコストを予測したりするのに役立ちます。
これらで現状のコストを見える化したうえで、アーキテクチャ変更が可能な場合にはサーバレス寄りにすることで料金は安くなります。しかし、アプリ改修などが走ることから、アーキテクチャ変更が難しい場合も多いでしょう。
コスト最適化のクイック戦略を具体的にご紹介
そこで、複雑な構成変更などが不要ですぐに着手できる、コスト最適化のクイック戦略が紹介されました。ここでは講演の中で紹介された方法をすべてご紹介します。
ストレージ
- EBS：世代更新
gp2からgp3へ変更する
★コスト削減だけでなく性能もUP! - 階層化
参照しないデータをEBS HDD または S3 Glacier(アーカイブ)に移行する - スナップショットの世代管理
予め世代数を指定して、その世代数分のスナップショットを作成し、指定した世代数を超える古いスナップショットを自動的に削除する設定に変更する
インスタンス
- 稼働時間の見直し
可能な対象については、時間帯・曜日などの指定で自動起動・停止する設定に変更する - 世代の更新
新しい世代に変更すると、同コストもしくはコスト減＆性能UP!
(例)m4,m5と頭につくインスタンスについては、6,7の世代が多く登場している - 長期予約割引購入（リザーブドインスタンス。Savings Plans）を利用する
常時起動が必須のインスタンスについては、2～3割引でもかなりのコスト減が可能 - アイドルタイムが多いマシンの見直し
Compute Optimizerで洗い出し- tシリーズインスタンス（ベースライン性能が低いが、バースト機能あり）に移行
- アイドルタイムの多いサーバに載っているジョブをLambdaに切り出し
（小サイズかつ短時間で終了する定期パッチ等のタスク）
その他
- 未使用のIPv4パブリックIPアドレスの整理
1つあたり600円ほど料金をとられるため、使用しないものは整理する - CDN（CloudFront）によるオリジン保護とデータ転送料の節約
WEBサーバ本体に対するアクセスをキャッシュで折り返すことが可能
攻撃からも保護が可能に - Cloudwatch Logs 不要なログの取り込みを減らす
Cloudwatch Logsは単価が高いため、無駄なログを取り込んでいないか確認する - 北米リージョン（北バージニア、オハイオ、オレゴン）を使う ※約20％コスト削減
設備の減価償却が終わっているリージョンのため、費用が安い
検証等、遅延が許されるもので利用すると◎
セキュリティ
責任共有モデルをおさえる
セキュリティ対策を考えるとき、まず初めにAWSの責任共有モデルについて押さえておきましょう。
AWSの責任共有モデルを一言でまとめると、「OSから上はユーザーの責任範囲、インフラはAWSの責任範囲」であるということです。OSから上で何か不具合が起こった場合には、AWSはデータを見る権限も、もちろんその責任もありません。
AWSのセキュリティサービスと、はじめに押さえるべきポイントとは？
AWSはセキュリティが最優先となっています。セキュリティのサービスは種類が豊富で、価格設定も低めです。各企業・ユーザーの必要性に応じて、ブロック式に組み合わせて有効化するだけで利用可能です。また、すべてのサービスを組み合わせるとハイレベルなSEIM環境（統合管理環境）も低コストで素早く実装可能です。
スタートアップ向けに最低限押さえるべき27の項目が、以下のページにまとまっています。0からAWSでシステムを立ち上げる際には、まずはこちらをご参照ください。
また、AWS Well-Architected フレームワークの6つの柱には、セキュリティが含まれます。このベストプラクティスには詳細情報と具体的な実装方法が掲載されているため、AWSでのセキュリティ対策を考える時には必読のページです。テーマごとにまとまっており、入り口としてこちらのページを利用して情報収集を行うと効率的に進めることが可能です。
災害対策―DRシナリオとネットワーキング
南海トラフの危険性などが高まる中で、AWSをはじめとするクラウドを利用する企業も増えています。災害のレベルは当然予知できないうえ、最悪の場合に備えるとかなりのコストがかかります。どこまでの対策を施すかは企業やシステムによって判断する必要があります。
AWSが定めている災害対策には以下の4段階があります。数字が大きいもののほうが、コストが高い一方で復旧にかかる時間を限りなくゼロに近づけることが可能となります。
- バックアップ/リストア
- パイロットライト
- ウォームスタンバイ
- マルチサイト（Act/Act）
多くの企業では、最も最低限のバックアップ/リストアを採用する企業が多いのが現実ですが、企業やシステムによってRTO（目標復旧時間）とRPO（目標復旧時点）が異なるため、それぞれの要件と予算に合わせて、公式情報と照らし合わせながら災害対策を施すのが良いでしょう。
災害対策（DRシナリオ）のクイック戦略
ここでは災害対策のクイック戦略が紹介されました。前提として、オンプレミス環境からAWSにリフトすることで、可用性や信頼性が向上されることから災害対策のひとつになります。そのうえで、シングルAZ・シングルリージョンでスモールスタートしたもののうち、DBや認証基盤のように確実にダウンタイムを作りたくないものだけはマルチAZ、マルチリージョンの構成を検討することをお勧めします。
障害時に備え、最低限スナップショットからの復旧が出来るよう事前に備えるところから始めましょう。ネットワーク面では、リモートアクセスを可能にしておき、オフィスに行くことが出来ない場合でもAWS環境へのアクセスが可能となります。ここを始点として、RTOとRPOの要件・費用対効果を基準にどこまで災害対策を行うか検討していくのが良いでしょう。
災害対策を考える際、AWS環境の災害対策シナリオでとどまってしまいネットワークの切り替えが考慮から漏れるということも多いです。そういった場合は、一元管理できるAWSパートナーへの依頼も検討することをお勧めします。
まとめ
本講演では、実際のお客様の声を基に、可観測性・コスト最適化・セキュリティ・災害対策のそれぞれにおいて、「まずはここから」という基礎的な方針をご紹介いただきました。
AWSをこれから利用したいという方も会場には多くいらっしゃる中で、具体的かつ今日からできるシンプルな手法をボリューム満点にご紹介いただいた講演で筆者自身もとても勉強になりました。講演は大盛況に終わりました。
この講演レポートがみなさまのAWS環境最適化の手助けになれば幸いです。
この記事をシェア
