結局のところ仮想マシン0台構成は現実的か

# はじめに
昨今モダン化やマネージドサービスをどんどん活用しようという流れから、嫌厭されがちな仮想サーバですが、果たして０にすることは可能なのでしょうか。
政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針でも、サーバを自ら構築するのではなく、マネージドサービスを活用し、仮想サーバを利用しない構成を求めているため、仮想サーバを極力利用しない構成が望まれている昨今の情勢から、仮想サーバが残るケースはあるのか、代替手段はあるのかを考察します。

https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/17ef852e/20221228_resources_standard_guidelines_guideline_01.pdf

# 理想
![スクリーンショット 2023-07-22 18.12.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/603a6c34-57e2-027a-3cb0-7519261bbe03.png)


構成上EC2が存在しない構成です。
ECS FargateタイプやLambdaを利用し、DBもマネージドサービスであるAuroraやDynamoDBを採用することで、仮想サーバを利用することがない構成です。
この場合、OSのメンテナンス（パッチあてなど）やOSのセキュリティを検討する必要がないため、運用コストの低減に繋がります。本質的でない部分の管理をAWS側にシフトできるという構成です。

https://aws.amazon.com/jp/compliance/shared-responsibility-model/

# 仮想サーバが残ってしまうケース
以下ケースが想定されます。
* パッケージ製品を利用するケース
→これは仕方のないケースかもしれません。どうしても利用したい製品がEC2にしか対応していない場合などは、利用する他ないでしょう。とはいえ、昨今ではSaaS化されている例も多く、費用対効果を検討の上、SaaSを利用することも選択として検討しても良いかと思います。
* メンテナンスで、 DBへの接続など踏み台的な使い方をするケース
→これも悩ましいケースです。 基本的に、コンテナのデプロイやLambdaのデプロイにおいて、EC2を利用するケースはないと思いますが、 DBへの接続は必要なこともあリます。後続で詳細を記載します。
* 開発環境として利用するケース
→Cloud9を利用し開発環境として利用するケースの場合は、EC2が存在しえます。これも致し方ないかと思います。とはいえ、ビルド環境などは、CodeBuildがありますので、デプロイに関連する環境はCodeシリーズを利用しマネージドサービスで自動化することが理想です。

# DBへの接続においてEC2を利用するべきか
前段で、 DBへの接続が必要な場合、EC2が必要となるケースが想定されることに触れました。
では、EC2を利用する他ないのでしょうか。考えうる構成をリストアップします。
* EC2を利用する
最もシンプルな方法です。EC2をメンテナンス用として構築し、EC2から DBに対してクエリを発行するパターンです。EC2は外部公開せず、SSMで接続するパターンです。
![スクリーンショット 2023-07-22 18.06.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/d90c5a77-d395-9af0-5009-23a4d4833e51.png)
* ECSonFargateを利用する
![スクリーンショット 2023-07-22 18.11.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/bcddf6fd-0271-c5a9-1d76-deeba647102e.png)

以下記事を参考にさせていただきました。詳細な設定方法などは割愛しますが、ECS上で、SSM Agentを動作させ、SSMのポートフォワーディングで踏み台的にコンテナにアクセスし、そこから DBにクエリを発行するパターンです。この構成だと、EC2を利用しなくてもすみそうです。

https://zenn.dev/quiver/articles/1458e453118254

* Lambdaを利用する
![スクリーンショット 2023-07-22 18.19.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/d1a727fe-c5d1-95c3-941b-30e55983b064.png)
これは、Lambdaを利用して、 DBにクエリを発行する構成です。
とはいえ、前段の２つとは違い、対話型で利用できないのが難点です。

* CodeBuildを利用する
![スクリーンショット 2023-07-22 18.19.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/584167/73ff6616-f17d-f03c-f1f5-aefc507c37e2.png)
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接続に対応すればなぁ・・・と思っていますが、今後に期待です！
仮想マシンを０台にすることも場合にはよりますが、可能ですね！