はじめに
昨今モダン化やマネージドサービスをどんどん活用しようという流れから、嫌厭されがちな仮想サーバですが、果たして０にすることは可能なのでしょうか。
政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針でも、サーバを自ら構築するのではなく、マネージドサービスを活用し、仮想サーバを利用しない構成を求めているため、仮想サーバを極力利用しない構成が望まれている昨今の情勢から、仮想サーバが残るケースはあるのか、代替手段はあるのかを考察します。
理想
構成上EC2が存在しない構成です。
ECS FargateタイプやLambdaを利用し、DBもマネージドサービスであるAuroraやDynamoDBを採用することで、仮想サーバを利用することがない構成です。
この場合、OSのメンテナンス（パッチあてなど）やOSのセキュリティを検討する必要がないため、運用コストの低減に繋がります。本質的でない部分の管理をAWS側にシフトできるという構成です。
仮想サーバが残ってしまうケース
以下ケースが想定されます。
- パッケージ製品を利用するケース
→これは仕方のないケースかもしれません。どうしても利用したい製品がEC2にしか対応していない場合などは、利用する他ないでしょう。とはいえ、昨今ではSaaS化されている例も多く、費用対効果を検討の上、SaaSを利用することも選択として検討しても良いかと思います。 - メンテナンスで、 DBへの接続など踏み台的な使い方をするケース
→これも悩ましいケースです。 基本的に、コンテナのデプロイやLambdaのデプロイにおいて、EC2を利用するケースはないと思いますが、 DBへの接続は必要なこともあリます。後続で詳細を記載します。 - 開発環境として利用するケース
→Cloud9を利用し開発環境として利用するケースの場合は、EC2が存在しえます。これも致し方ないかと思います。とはいえ、ビルド環境などは、CodeBuildがありますので、デプロイに関連する環境はCodeシリーズを利用しマネージドサービスで自動化することが理想です。
DBへの接続においてEC2を利用するべきか
前段で、 DBへの接続が必要な場合、EC2が必要となるケースが想定されることに触れました。
では、EC2を利用する他ないのでしょうか。考えうる構成をリストアップします。
- EC2を利用する
最もシンプルな方法です。EC2をメンテナンス用として構築し、EC2から DBに対してクエリを発行するパターンです。EC2は外部公開せず、SSMで接続するパターンです。
- ECSonFargateを利用する
以下記事を参考にさせていただきました。詳細な設定方法などは割愛しますが、ECS上で、SSM Agentを動作させ、SSMのポートフォワーディングで踏み台的にコンテナにアクセスし、そこから DBにクエリを発行するパターンです。この構成だと、EC2を利用しなくてもすみそうです。
-
Lambdaを利用する
これは、Lambdaを利用して、 DBにクエリを発行する構成です。
とはいえ、前段の２つとは違い、対話型で利用できないのが難点です。 -
CodeBuildを利用する
CodeBuildからクエリ実行するパターンです。デプロイ時に DBの変更をする場合などには向いているのかなと思います。 -
CloudShellを利用する
これは、あまり現実的ではないかもしれませんが、CloudShellから DBに接続を行うパターンです。
とはいえ、CloudShellはインターネット経由での接続となるため、 DBをパブリックサブネットに配置し、CloudShellのグローンバルIPからの接続を許可する必要が出てきます。
そろそろVPC接続に対応してほしい。。。。
まとめ
| # | 方式 | メリット | デメリット | 評価 |
|---|---|---|---|---|
| 1 | EC2方式 | 手っ取り早く作れる。OSがあるため、一般的な方法で利用可能 | OSのメンテナンスやセキュリティ対策が必要 | OSのメンテナンスを意識する必要があるものの、誰もがイメージできる使い方であるため、緊急時でも特に違和感なく利用できる方式である。 |
| 2 | ECSonFargate方式 | OSの管理が不要、事前にイメージを作成しておけば高速に展開できる | Agentのアップデートなどコンテナイメージのメンテナンスが必要 | OSのメンテナンスが不要となる構成であり、緊急時でもコンテナをデプロイすれば利用できるため、おすすめ |
| 3 | Lambda方式 | OSの管理が不要 | 対話型での利用ができない、都度クエリをコードに記載する必要がある、実行時間に制限がある | ２の方式以上にメリットがあるとは思えないため、利用する理由が見つからない |
| 4 | CodeBuild方式 | OSの管理が不要、デプロイと合わせて実行可能 | 対話型での利用ができない | デプロイ時に決められた操作を行うなどの場合は、この方式が良い。とはいえ緊急時にアクセスする観点ではこの構成だけでは不十分 |
| 5 | CloudShell方式 | OSの管理が不要、対話型の利用もできる、事前構築不要 | インターネット経由でのDB接続が前提となる | 現時点ではパブリックサブネットに DBを配置する構成をとならければならないため現実的ではない。とはいえ、今後のアップデート次第では、この方式が理想。 |
個人的には Fargateを利用する方式と、CodeBuildを利用する方式がおすすめです。
CloudShellさえ、VPC接続に対応すればなぁ・・・と思っていますが、今後に期待です！
仮想マシンを０台にすることも場合にはよりますが、可能ですね！