AWS運用の基本とノウハウ。トップエンジニアが語る現場の知恵と実践的アプローチ

手探りで運用すること自体は、必ずしも悪いことではありません。AWSをはじめとするパブリッククラウドサービスは日々サービスリリースや機能アップデートがあるので、運用手法は変化し続けています。昨日までの課題が、翌日のアップデートで解決するといったこともあります。

本当に問題なのは、運用を任されているエンジニアの中で運用に関する知識が体系化されていないことが多い点です。AWSは200以上のサービスがあり、それを運用に当てはめる際に「これはどの運用に関わるサービスなのか」という整理ができていないケースが多いのです。

たとえば、システムの情報がない状態で「AWSのアーキテクチャの改善ポイントを教えてください」と質問をされても、すぐに回答するのは難しいです。しかし、最低限の情報としてシステム構成図があれば、どこから着手するか（見るべきポイント）、どのような流れで改善を進めていくか等を見積もることができます。運用に関しても同じことが言えると思います。システム構成図のような「地図」「フレームワーク」があれば、どこから運用設計や改善に着手するのか、どのような流れで運用改善を進めていけばよいのか、といった方針や道筋を立てることができます。構成図というのは、次のようなものです。

私もAWS運用の課題については、山﨑さんの意見に近いのですが、もう少し広い視点でお話しします。AWS以外のSE(System Engineer)やCI(Continuous Integration、継続的インテグレーション)と呼ばれる世界でも、設定の正解はドキュメントなどに記載されていることが多いです。例えば「Amazon EC2（Elastic Compute Cloud）※を建てるときはインスタンスタイプに気をつけましょう」というような設定情報は、AWSドキュメントを見れば分かります。

しかし、運用に関する資料を探そうとすると、なかなか見つけることができません。その背景として、日本のIT業界では、システムを納品した後の運用については、お客様に委ねられるケースが多く、その結果として十分な情報共有やサポートが継続しにくいという課題が生じやすい構造があるように思います。 具体的にはシステム開発を担ったベンダーが納品を終えると、その後の運用はクライアントが主体となり、開発を手掛けたベンダー側が継続して運用に深く関与する機会が持ちにくくなる、といったケースが少なくないのです。

その通りです。そうすると「どんな設定なのか」「どのようなシステム構成なのか」がわからなくなる。運用できない、あるいはいつの間にか運用されていない状態になることすらあります。そうした状態のまま数年後に問題が発生すると、関係者は緊急対応時に必要な情報も無いままに対応することとなり、混乱が起きることも少なくありません。アサインされた担当者も運用の正解がわからないため、何をすべきか判断できませんし、「見て見ぬふり」をされてしまうこともあり得るのです。

実は、そのような状況でAWS運用の「教科書」のようなものがあれば、担当者が問題を解決するときの大きな味方になると思ったことがこの本を執筆するきっかけでした。特にAWSはオンプレミスと違い一定の「癖」のようなものがあります。

運用において監視ツールの設定に関する技術書は数多く本屋に並んでいます。そしてAWSの本は試験対策や初期導入(CI)のものがほとんどを占めており、運用に関する本は皆無でした。運用監視の全体を俯瞰しつつAWSに注力した運用本がなかったため「AWSの運用に特化した本を出すことには一定の意義があるだろう」という結論に至りました。

はい、この3つはどれか一つだけ押さえればいいというものではなく、それぞれをしっかり理解しておくことが大切です。

私はインフラを担当することが多いので基盤運用が中心になりますが、例えば運用管理という観点では、お客様側で決められたセキュリティポリシーに従った運用や設計が求められます。そのときに運用管理という観点や知識がなければ、セキュリティポリシーという観点が抜け落ちてしまい、お客様が求めるものとは違ったシステムになってしまう可能性があります。

しかし、運用管理という観点や知識があれば、「御社のセキュリティポリシーを教えていただけますか」と私たちからお客様に確認することができたり、幅広い提案や会話ができたりするので、お客様からの信頼にもつながります。

一人のエンジニアが3つの運用をすべて担当することはあまりないと思いますが、「自分は基盤運用の担当だから他は関係ない」という認識ではなく、他の運用観点についても理解しようとする姿勢と最低限の知識があるだけでも、お客様との会話内容や自分の仕事に対する視点が変わってきます。

本書では、システムのライフサイクルを「システム企画」「要件定義」「基本設計」「詳細設計」「開発」「テスト」「運用」の7つの段階で説明しています。そのうち「運用」は、サービス提供が終了するまでシステムを安定的に稼働させるフェーズです。

システムのライフサイクルにおいて、もっとも対応期間が長いのは「運用」であり、10年以上運用するシステムもあります。

設計構築は様々な技術を駆使するのでフォーカスされがちですが、運用を怠るとビジネスに大きな影響が出ます。例えばECサイトが止まると、止まった時間だけ売上の機会損失が発生します。

例えば、Amazonの過去の事例では、1分間のダウンタイムで数百万ドルの損失が発生したと言われています。システム運用はビジネス上も非常に重要なのです。

その通りです。構築が終わってから運用を考えるのではなく、要件定義や設計段階から運用のことも同時に考えておくべきです。後から運用方法を変更しようとしても設計変更が必要になると、すでに稼働しているシステムを止める必要があり、改修のコストが大きくなります。そのため、運用を見据えた設計が重要です。

AWSの基本的なサービスである、ネットワークサービス、コンピューティングサービス、ストレージサービス、データベースサービス、負荷分散サービスなどをまず理解することが重要です。まずこれらの基本知識を理解した上で、他の機能に広げていくとよいでしょう。

まず押さえておくべきなのはVPC（Virtual Private Cloud）※です。これはAWS上に作る仮想ネットワークで、この中に仮想サーバーなどのAWSリソースを作成します。次にEC2（Elastic Compute Cloud）という仮想サーバーを提供するサービス、そしてS3（Simple Storage Service）※というデータ保存のためのサービス、RDS（Relational Database Service）※というデータベースのサービスなどになります。

よくあるのは、IAM（Identity and Access Management）※ロールの理解です。初学者だと「EC2のOSにログインした認証情報を使って他のAWSサービスと連携する」と思ってしまう人がいるのですが、それとは別にAWSサービスを操作するためにIAMロールなどの認証情報が必要になります。この考え方の違いが理解できないとつまずくことが多いです。

RDSについては、オンプレミスでサーバーを管理していた人にとって感覚が違います。RDSを使うとAWSが大部分を管理してくれるので運用の負荷が下がります。本書では、オンプレミス、EC2、RDSの違いについても説明しています。

オンプレミスではすべてを自分で管理する必要がありますが、RDSではアプリケーションからの利用だけを管理すればいいので、バックアップやミドルウェアのパッチ※などはAWSが提供してくれます。

選び方は要件ベースです。例えば「Webサーバーを継続的に稼働させたい」という要件があれば、ロードバランサー※を使って複数台で構成を組むことが考えられます。要件に合ったものを選んで組み合わせるのが基本です。

基本的には、アカウントを共有して使うよりは、個々人のアカウントを用意することが多く、そちらが推奨されます。1つのユーザーを共有すると、誰がいつアクセスしたのかの管理や監視が難しくなります。また、権限の面でも、担当者ごとに必要な権限だけを付与するのが難しくなり、広い権限を設定せざるを得なくなります。 個人のアカウントを用意しておけば、その人に必要な権限だけを与えられるというメリットがあります。

共有利用しないのがベストです。監査準備のためのCloudTrail※というサービスがあり、AWS上の操作のログを取ることができるのですが、アカウント、AWSだとIAMユーザーを共有使用すると操作者の特定ができなくなります。例えば、トラブル発生時に「誰がこの設定を変更したのか」を追跡できず、責任の所在が不明確になります。

本書では、IAMユーザーの作成から始まり、適切な権限管理、パスワードポリシーの設定など、セキュリティを確保しながら効率的に運用するための方法を解説しています。特に重要なのは「最小権限の原則」で、必要最低限の操作権限のみを付与することを推奨しています。

ルートユーザーは全ての操作権限を持つため、通常の作業では使わず、必要最低限の操作権限に限定したIAMユーザーを作成して利用することが重要です。

はい。最近のお客様は一つのAWSアカウントではなく、複数のAWSアカウントを運用しています。10個、20個、多い企業では100個以上のアカウントを運用していることもあります。

各アカウントにIAMユーザーを作ると、100個のIAMユーザーが必要になるので非常に面倒です。そこで、AWSアカウントに専用の「踏み台アカウント」を一つ作り、そこでIAMユーザーを一元管理します。

その踏み台アカウントから権限に応じて、各アカウントにアクセスする権限を管理すれば、アカウントごとにIAMユーザーを作る必要がなくなります。

AWS IAM Identity Center と呼ばれるシングルサインオン※を提供する仕組みもあり、一つの場所でユーザーを作成すれば、あとはそのユーザーにどのアカウントへのアクセスを許可するかという権限管理だけで済むようになっています。

また、AWS Organizations※というサービスを使うと、複数のAWSアカウントを一元管理できます。特にサービスコントロールポリシー（SCP）という機能を使うと、組織単位でアカウント内の操作を制限できるので、より効率的な管理が可能になります。

為替変動でコストが上昇すると「何とかしなければ」という話になりますが、コスト管理はAWS運用の一環として常時行うべきものです。

AWSは、コスト削減のためのサービスをいろいろと提供しています。古くはReserved Instances※という予約して一括で払うことで割引を受ける機能や、その進化版であるSavings Plans※、コストを最適化するための AWS Compute Optimizer ※などがあります。最近ではCost Optimization Hub※というAWS Organizations環境下で有効活用できるサービスも登場しています。

AWSアカウントが、不要なリソースが整理されないまま放置され、簡単に「ゴミ箱」のような状態になり得ることには注意が必要です。「誰が作ったか不明で、削除するのが怖い」といった判断が積み重なることが原因です。これを防ぐためには、各AWSリソースの作成者、用途、責任者を明確に記録し、追跡可能な状態にしておくことが重要です。また、コスト最適化のためには「現場の協力と理解」が必要となるのですが、現場は現場で本来の業務もあるため、コストに関する作業の割り込みに対して、なかなか動いてくれないこともあるというのが実情です。

近年提唱されているのが「Cloud Center of Excellence（CCoE）」※という概念です。経理部門、情シス部門、アプリ部門等が一丸となってコスト管理に取り組む組織的アプローチです。トップダウンでコスト管理の重要性を示すことが効果的です。

進め方としては、AWSリソースを棚卸して未使用なもの、不要なものを見つけて削除することから開始するのが良いでしょう。不要なリソースの削除はセキュリティリスクを低減させる事にも役立ちます。そして、残ったものはスペックを適正化し、常時起動が必要かどうかを判断します。さらに、常時起動が必要なものだけReserved InstancesやSavings Plansを購入して割引料金で使うという手順を紹介しています。

私が担当しているお客様では、不要なバックアップをまとめて削除しただけで年間1,500万円のコスト削減になったケースがあります。

また、リソースを削減すると管理コストも減ります。例えばIAMユーザーが100個あっても実際に使われているのが10個だけなら、不要なものを削除することで管理対象が減り、管理する側の時間的コストや運用コストも削減できます。金銭的コストだけでなく、運用負荷の軽減にもつながるのです。

不要リソースの削除、スペック最適化、未使用時停止、常時稼働リソースへの割引料金プラン適用という流れで進めることで、効率的にコスト最適化を実現できます。

そうですね、やはり一番大事なのは「作って終わりじゃない」という意識をチーム全体で強く持つことじゃないでしょうか。「システムは作るよりも、その後の運用の方が何倍も大変なんだ」と言われますが、これは本当にその通りで。2023年のAWS re:Inventで、CTOのWerner Vogels博士もキーノートで話されていた通り、初期構築のコストよりも、実際に動き始めてからの運用コストの方がずっと大きいという現実があります。

だからこそ、AWSを正しい形で使い続けるためには、日々の地道な運用、つまり「作りっぱなしにしない」という姿勢が何よりも重要になってきます。組織で、チームで対応しない限り、意図せずあっという間に環境が“ゴミ箱化”してしまい、無駄なコストが膨らんでしまう。だから、常に学び続け、既存のやり方に疑問を持ち、改善を続けることが求められます。結局のところ、日々の小さな積み重ねと改善が、将来的に大きな成果に繋がっていくんだと、私はそう信じています。