AWSなどクラウド移行でよくある3つの失敗例と対策

本記事ではアマゾン ウェブ サービス（AWS）をはじめとするクラウド運用のよくある失敗例について、その原因と対策について紹介します。クラウドに関する基本的な知識を身に付けるだけでなく、具体的な失敗例から、その原因と回避策を学びましょう。

失敗例1：クラウド移行後に想定よりコストがかかった

1つ目の失敗例は、オンプレミスからクラウドへシステムを移行したが、想定していたよりもコストがかかってしまった例です。

クラウドは物理的なサーバやネットワーク機器を購入する必要がなく、基本的に使ったリソース分だけ支払う従量課金制です。そのため、導入コストを抑えシステムを構築し、運用が始まってから必要に応じてリソースを増減することができます。しかし、その一方でリソース管理を怠ると、結果的に期待していたほどコスト低減効果を得られないこともあります。

コストに関する失敗の原因と対策

運用開始時のリソースのまま運用を続けている

オンプレミスでは設計内容に応じてサーバなどの必要な機器を一括で調達するため、機器調達にかかるコストは運用を開始する前にほぼ決定します。しかし、従量課金制のクラウドは、オンプレミスと同じように運用開始時のリソースを変更しないでいると、不要になったリソースにも支払を続けることになり、クラウド化によって本来得られるはずのコスト削減効果は小さくなります。

想定外のアクセス急増

特にWebサイトなどインターネット環境からクラウド環境に対して不特定多数のアクセスがある場合、予想以上にアクセス急増があることを想定しておく必要があります。アクセス急増の要因は、あらかじめ想定できる要因とできない要因があります。

あらかじめ想定できる要因としては、キャンペーンやリリースなど自社が主体となって行うものです。SNSでの告知など宣伝活動をする前に、過去のアクセス数を基にコストを見積もり、予算的に問題ないか検討するようにしましょう。

一方で、想定外のアクセス急増が発生する要因としては、第三者によるSNS投稿が拡散されるなど自社にとってメリットでもあるものや、サイバー攻撃など自社にとってマイナスとなるものなどさまざまな要因があります。良い内容にしろ悪い内容にしろ、ニュースに取り上げられたためにアクセスが急増することも考えられます。

AWSではAWS Budgetsで予算を設定することで、ユーザーが定めた金額まで使用料が上がるとメールで通知することができます。

最適な料金プランを選択していない

AWSのAmazon EC2（仮想マシン）は、インスタンスの契約タイプが複数あり、同じEC2インスタンスでも、オンデマンドとスポットインスタンスでは最大で90%のコスト差が生じます^[※1]。用途に応じて最適なプランを選択し、コストを最適化しましょう。

例えば、ストレージサービスのAmazon S3には標準のもの以外にもGlacier Flexible Retrieval（旧 S3 Glacier）など複数のストレージクラスがあります。標準のS3はSSDで、GlacierはHDDとイメージするとわかりやすいです。標準のS3に比べてGlacierはストレージ料金が低価格ではありますが、データの取り出し速度が遅くなります。そのため、S3標準のストレージクラスは使用頻度の高いデータの保管場所として使用し、Glacierはバックアップや古いログなど使用頻度が低いデータの保管場所として利用するなど、保存したいデータの特性に合わせて使い分け、コストを最適化しましょう。

失敗例2：クラウドの設計・構築に想定より時間を要した

2つ目の失敗例は、クラウド運用開始前の設計・構築に時間をかけ過ぎてしまうケースです。特に初めてクラウド上にシステムを構築する企業にありがちな失敗例です。設計内容に基づきクラウド構築を開始したが、クラウドの仕様に慣れていなかったため設計の見直しが必要になり、結果として運用開始が遅れてしまう場合があります。

スケジュール通り進まない原因と対策

クラウドの設計・構築がスケジュール通り進まず失敗してしまう原因の1つは、自身のクラウド構築経験に見合わない大規模システムや難易度の高い要件を実現しようとすることにあります。初めて、あるいはそれほどクラウドの構築の実績がない場合、スモールスタートがおすすめです。クラウドはオンプレミスと違いリードタイムが非常に短くシステムの拡張・縮小が容易であることから、スモールスタートに適しています。スモールスタートなら、想定外の仕様があった場合の手戻りが少なく済み、大規模システムに比べて不具合の原因の究明も容易です。

しかし、大規模なシステムをオンプレミスから一気にクラウド移行したい、あるいは難易度の高いシステムをクラウド上に構築することが求められたなどの場合には、社外の構築ベンダーに支援を求めることも選択肢の1つです。弊社でもお客様の要望や状況に合わせて、クラウド環境の設計・構築・運用・管理を代行するマネージドサービスを提供しています。

失敗例3：セキュリティ対策の不備によるセキュリティ事故の発生

失敗の3例目は、クラウドの設定不備などにより、セキュリティ事故が発生してしまうことです。セキュリティ事故は、自社に留まらず顧客データの流出など社外まで影響を及ぼす可能性があるため、絶対に避けたい失敗です。近年AWSで発生した2件のクラウド運用時のセキュリティ事故の実例から、原因と対策について考えましょう。

高額請求からサイバー攻撃が発覚した事例

ある企業へのクラウドの請求額が突然高額になり、数台規模のはずの仮想サーバが100台に増えていたという事例があります^[※2]。調査の結果、攻撃者がアクセスキーを不正に入手し、そのアクセスキーを使って利用中のクラウドにインスタンスを複数台新たに立ち上げ、マイニング（仮想通貨の発掘）に利用していたことがわかりました。マイニングは多くのリソースを消費することから、この企業は数日で約100万円の高額請求をされています。

この事例のきっかけとなるアクセスキーが流出した原因はアクセスキーの使いまわしと考えられています。

クラウドの認証には、IDとパスワードに加え、今回のサイバー攻撃の原因となったアクセスキーが用いられます。そのため、アクセスキーについても十分に注意して管理する必要があります。複数人もしくは組織をまたいで広範囲で使い回さないなど、正しい運用を心がけましょう。

また、運用面に加えてシステムの脆弱性があると、サイバー攻撃を受けた際の原因究明が困難になります。定期的にアップデートを実施するようにしましょう。そのほかにも、多要素認証により不正ログインを防止すること、IAMによりインスタンスを追加できるユーザーを限定すること、AWS Configによりインスタンス作成時の通知をすることが本事例の被害を防ぐための対策として挙げられます。

検証環境の設定不備によるサイバー攻撃が発生した事例

ある企業が運用しているクラウド上のサーバにバックドアが仕掛けられていることが発覚しました^[※3]。このサーバの本番環境はインターネットには直接接続されておらず、社内からのVPNでのみアクセス可能な環境でしたが、検証環境にはインターネット上のすべてのIPからアクセス可能でした。調査の結果、攻撃者によってバックドアが仕掛けられたサーバを検証環境のVPCから本番環境のVPCにそのまま移動したことが原因だと判明しました。

AWSの移行失敗例

この事例では、インターネットにつながった検証環境のセキュリティに以下の不備があったことが原因だと判明しました。

• 検証環境のパスワードの脆弱性
• 検証環境におけるセキュリティ監視が不適切

検証環境は一時的な環境であることから、セキュリティ意識が低くなりがちです。しかし、今回の事例のように検証環境で構築したものを本番環境へコピーするなどして流用する場合には、アクセスログの監視や、アンチウイルスソフトを導入など本番環境同様のセキュリティ対策を施すことが必要です。

まとめ

本記事ではAWSをはじめとするクラウド運用の失敗例について、その原因と対策を解説しました。失敗例の多くは人為的ミスによるものであり、最悪の場合には、サイバー攻撃によって自社のみではなく他社や顧客にまで被害を及ぼすこともあります。

設計や設定の不備が1つでもあるとサイバー攻撃につながる可能性があり、漏れなく対策を実施するためには一定の知識とスキルが必要です。また、パブリッククラウドサービスの技術とサービスは日々更新されており、サービスの更新に合わせて情報をアップデートすることも大切です。クラウドの知識やスキルアップ、また情報収集を継続的に続けましょう。

それでは負担が大きく社内だけで設計・構築・運用を実施することに不安がある場合は、クラウドのマネージドサービスの活用も検討すると良いでしょう。弊社でも、お客様の要望や状況に合わせて、クラウド環境の設計・構築・運用・管理を代行するマネージドサービスを提供していますので、ご相談ください。

関連資料をダウンロード

出典

• [※1] Amazon Web Services「Amazon EC2の料金」
• [※2] LAC 「サイバー救急センターレポート 第8号」P.14-P17
• [※3] LAC 「サイバー救急センターレポート 第8号」P.9-P13