クラウドサービスは便利だけど、頼りすぎはダメ！

クラウドサービス頼みばかりだと、どんな弊害がある？

最近流行りのクラウドサービスのなかでも人気の「AWS（Amazon Web Services）」。

業界トップシェアを誇るだけあり、認知度だけでなく、提供しているノウハウも他サービスを圧倒しています。

オンプレミスでの構築と比べてメリットも多いため、実際に導入してみると「AWS なしでは成り立たない！」くらい快適になることも。

しかし、クラウドサービスは便利なばかりではありません。

今回は、AWS に過度に頼ると、どんな弊害があるのかを見ていきましょう！

初心者は要注意！AWS ばかりでは技術が身につかない

AWS の最大のメリットは、なんといっても「簡単に環境構築ができる」ことです。

たとえば、個人用のサーバを立ち上げたい場合、AWS アカウントさえあれば、コンソール画面から数ステップの操作だけで完了してしまいます。

また、AWS はクラウドサービス大手だけあり、公式リファレンスや AWS 関連のハウツーサイトも充実しています。

そのため、インフラ周りの知識が浅い初心者エンジニアでもさほど苦労せず、目的に合った環境構築をすることができるのです。

しかし、そんな初心者エンジニアが陥りやすいのが、「いつまでたっても技術が身につかない」罠。

どういうことか、実際にオンプレミスと AWS での環境構築方法を比べてみましょう。

オンプレミスで環境構築をした場合

まずは、AWS なしで環境構築を行うと仮定します。

1. サーバを用意
2. サーバに OS を導入
3. OS の設定
4. ネットワークの設定
5. Web サーバの導入と設定
6. データベースの導入と設定
7. メールサーバの導入と設定
8. それぞれの機能が連携できるよう設定

一般的には、このようなステップとなります。

しかし、初心者が実際にこの通りやろうとしても、十中八九、どこかのステップでつまずくはずです。

リサーチにかかる時間も含めれば、2週間以上かかってもおかしくありません。

試行錯誤を重ね、ときには先輩エンジニアのアドバイスを求めることもあるでしょう。

そうした経験と知識が、これからのエンジニア人生でおおいに役立つことになるのです。

AWS で環境構築した場合

一方、同じく初心者エンジニアが、AWS で同じ環境構築をするケースを考えてみましょう。

1. ネットワーク「Amazon VPC」の設定
2. 利用するサーバ「EC2インスタンス」の性能と OS を選択
3. Web サーバの導入と設定
4. データベース「AWS RDS」の導入と設定
5. メールサーバ「Amazon SES」の導入と設定
6. クラウドの設定を調整し、環境を整える

やることは同じでも、ほとんど AWS が提供しているサービスで事足りるため、オンプレミスと比べて半分ほどの時間で完了すると思います。

もちろん、初心者なのでつまずく箇所もあるでしょうが、「構築したのに動かない！」なんて事態にはほぼなりません。

ネットワークやデータベース、Web サーバの構築及び連携に関する知識がなくても、なんとかなるように出来ているのが AWS です。

つまり、初心者エンジニアは AWS ばかりに頼っていると、基礎が身についていない「初心者」から抜け出せなくなってしまいます。

クラウドサービスに慣れすぎてはダメ

薬物依存の悪循環サイクルの図を見たことはありますか？

これを、クラウドサービスに置き換えて考えてみましょう。

クラウドサービスに慣れすぎると、以下のように、クラウドサービスありきの考え方になってしまいます。

1. クラウドを利用すれば環境構築できるけど、クラウド以外では無理
2. クラウドなら簡単にできることが、オンプレミスだと面倒くさく思ってしまう

システム上、クラウドサービスを導入できなかったり、そもそも求める機能がクラウドサービスにない場合、何もできないエンジニアになってしまうのは嫌ですよね。

教訓①基礎的な技術と学び続ける姿勢はマスト

知識や技術だけが優秀なエンジニアの条件ではありません。

「プログラムやソースコードを書いたことはないけど、設計書の作成や要件定義はバッチリ！」というクラウドエンジニアだっています。

しかし、エンジニアたるもの、技術に対する探究心は是非とも持っておくべきです。

1. クラウドサービスを利用すれば実現可能だけど、それはどうしてだろう？
2. クラウドサービスなしで実現するためには、どうしたらいいだろう？

このような気持ちを常に忘れず、日々スキルを磨いていくことが大事ですよ。

安易に手を出すべからず。クラウドサービス利用の失敗事例

ここでは、正しい技術とクラウドの知識を持っていれば防げたかもしれない、クラウド活用の失敗例を2つ紹介します。

オンプレミスでの環境なら大した痛手でなくても、クラウドサービスの場合は甚大な被害を被る恐れがあるのです。

クラウドサーバの賃貸借契約が切れて、全データが消失

2020年11月に起きた、クラウドデータ消失事件です。

詳細は、以下のページをご覧ください。

【「ふくいナビ」クラウドの全データ消失、NECキャピタルソリューション社内手続ミスが原因】
https://scan.netsecurity.ne.jp/article/2020/11/10/44794.html

クラウドサービスは、サービスの利用分だけ代金を支払う「従量課金」制がほとんどです。

この失敗例では、サーバの賃貸借契約の手続ミスにより、契約期限を過ぎてしまった結果、クラウドサーバ上に保管していたデータがすべて消えてしまいました。

全データが一切復元不可能なのであれば、クラウドサーバとしてはあるべき姿なのですが…。

この事故は、「クラウドだから安心だよね！」という過信が引き起こした結果ともいえるでしょう。

AWS で作成した IAM ユーザが不正利用された挙句、高額請求された

これは、筆者の知人から聞いたとても怖い話です。

AWS ルートアカウントと IAM ユーザ

AWS を利用する場合、「AWS ルートアカウント」と「IAM（Identity and Access Management）ユーザ」が必要です。

AWS ルートアカウントは、AWS リソースに対して何でもできる権限を持ちます。

そのため、AWS アカウントの発行後は、基本的には利用しないよう運営することが原則です。

一方、IAM は AWS のリソースを管理する仕組みで、様々なアクセス権を持つユーザを作成できます。

IAM をもとに作成されたユーザのことを、IAM ユーザといいます。

そして、「管理者レベル」「開発者レベル」「参照だけできるレベル」といった感じで、役割に応じたユーザの作成ができるのです。

当然ながら、IAM ユーザの認証情報は厳重に管理しなければなりません。

情報漏洩で高額請求が来るはめに

ところが、エンジニアの知識不足のせいで、「管理者レベル」の認証情報が漏洩してしまったのです。

その結果、高性能の EC2インスタンスが全リージョンで起動されてしまい、高額請求のアラートが来ました。

こうした事態は、IAM ユーザに対して「MFA（多要素認証）」の仕組みを導入していれば防ぐことができます。

そもそも MFAは、クラウドを活用するのであれば、当然やるべき対策です。

今回はアラートに気づけたからよいものの、もし気づかず長期間放置していたら…身の毛がよだちますよね。

教訓②「便利」と「正しさ」は必ずしも両立しない

クラウドサービスは、技術的な知識がなくても使える便利な存在です。

しかし、「簡単に使える」からといって、「正しく使える」とは限りません。

「なんとなくクラウドってカッコいいし、今風だから使ってみようかな？」と軽い考えで手を出すと、痛い目を見ることもあるのです。

クラウドサービスを「正しく」利用するには、そのサービスに対する知識はもちろん、技術的な知識も十分あることがベストです。

さいごに

クラウドサービスのなかでも、AWS はエンジニア初心者でも使いやすい仕様になっています。

しかし、過度に AWS に頼りすぎると、技術力の低下や思わぬ事故を引き起こすことになりかねません。

AWS に対する正しい認識をもって、賢くサービスを使いこなしたいものですね。

こちらの記事もオススメ！

2020.07.27IT・コンピューターの歴史特集IT・コンピューターの歴史をまとめていきたいと思います！弊社ブログにある記事のみで構成しているため、まだ「未完成状態」...
2020.07.27IT偉人の誕生日特集現在のITがあるのは、「IT偉人」のおかげ！そこで今回は、IT偉人の誕生日をまとめていくことで、時代の流れを追えるよう...

さいごの一言