助け合いフォーラム
効率よく環境構築を行うにはどのAWSサービスを利用するのがよいか。
正解
AWS CloudFormation
解説
「テンプレート」と呼ばれる設計書にどのAWSリソースをどのように利用するかを記述すると、CloudFormationはテンプレートに書かれた通りにAWSリソースをプロビジョニングします。
同じ操作を何度も行う場合や、似たような環境を複数構築したいような場合に利用することができます。
WordPressとはWebページやブログを作成するオープンソースのソフトウェアです。WordPressを動作させるには、Webサーバーアプリケーション（Apache、Nginx）やデータベース（RDS）、プログラミング言語（PHP）などが必要です。
本設問ではこれらを整備した環境を部署ごとに個別に、つまり同じ環境を複数作成する必要があるため、CloudFormationを利用するのが効率的です。
以上より正解は
・AWS CloudFormation
です。
なお、CloudFormationではWordPressの動作環境をサンプルテンプレートとして公開しています。
・スケーラブルで耐久性の高い WordPress
その他の選択肢については以下の通りです。
・Auto Scaling
AWSリソースを自動的にスケーリングするサービスです。
環境構築はできないので、誤りです。
・AWS Elastic Beanstalk
アプリケーションのデプロイ（動作環境への展開）を行うための定番環境を自動で構築するサービスです。
定番の環境を選択して構築するので、独自のシステムを構築するようなケースには適していないので、誤りです。
・AWS CloudWatch Logs
AWSサービスやEC2インスタンスのOSやアプリケーションのログを収集し、一元管理するサービスなので誤りです。
参考
AWS CloudFormationは、AWSクラウド上で環境を自動的に構築するサービスです。JSONやYAML形式で記述されたテンプレートをもとに、AWSのインフラストラクチャを構築および管理します。
CloudFormationは「IaC（Infrastructure as Code）」を実現するAWSのサービスです。IaCとは、仮想サーバー、データベース、ネットワーク設定などのITインフラをコードで定義する技術です。IaCの主なメリットは、以下のとおりです。
・再現性のある環境構築 … 異なる複数の環境で一貫性のあるインフラ構成を再現できる
・環境の共有 … 定義されたコードを他のユーザーが使用できる
・変更管理の向上 … コードによりリソース構成やパラメータの変更管理が容易になる
・人的エラーの削減 … 手動操作を減らすことで、設定ミスなどのエラーが発生しにくくなる
CloudFormationを用いると、EC2やELBなどのサーバー環境だけでなく、CloudWatchのような運用支援サービスも含め、ほぼ全てのAWSリソースをコード化して、構築および運用を自動化できます。
[CloudFormationの利用イメージ]
■テンプレートとスタック
CloudFormationは、リソース構成を定義したテンプレートをもとに環境を構築し、その環境を「スタック」という単位で管理します。テンプレートはJSONまたはYAML形式で記述され、AWSリソースの構成や設定を定義する設計図の役割を果たします。
例えば、Webアプリケーションをリリースする場合には、必要なAWSリソース（VPCやEC2インスタンスなど）をテンプレートに定義し、CloudFormationがプロビジョニング（構築）します。もしWebアプリケーションが不要になった場合は、スタックを削除することで関連するリソースをまとめて解除できるため、不要になった環境を簡単に削除できます。
テンプレートは自分で記述して作成する方法以外にも、AWSが提供するサンプルテンプレートや、マネジメントコンソールのGUIを使用して作成できます。
[JSON、YAMLでの記述例（EC2インスタンス作成）]
[マネージメントコンソールのテンプレート作成画面（EC2インスタンス作成）]
■サービスロール
サービスロールは、CloudFormationに対して、ユーザーの代わりにスタック内のリソースを操作する許可を与えるためのIAMロールで、スタックの定義時に指定することができます。
サービスロールを指定すると、CloudFormationはスタックで実行されるすべての操作にこのロールの権限を使用します。これにより、ユーザーが直接各リソースに対するアクセス権限を持っていなくても、AWSリソースのプロビジョニングを行うことができます。
■スタックセット
AWS CloudFormationで作成したテンプレートを基に、複数のAWSアカウントで、または複数のリージョンでスタックを構築したい場合には「スタックセット（StackSets）」を利用します。管理者アカウントで作成したテンプレートを利用して、ターゲットアカウント（プロビジョニングを行うアカウント）とプロビジョニングを行うリージョンを指定することで、一度の操作で複数の同じ環境を構築できます。
テスト環境を複数構築したい場合や、新たにアカウントを払い出す際に下準備となる操作（IAMやセキュリティグループの設定など）をスタックセットとして作成しておく、といった利用ができます。
【AWS Service Catalog】
AWS Service Catalogは、主にCloudFormationテンプレートを製品として登録し、他のAWSユーザーへ共有できるサービスです。共有先のAWSユーザーは、セルフサービスで製品からAWS環境をデプロイ（構築）できます。製品の管理者は、製品のバージョンや、製品がいつ・誰に使用されたかを一元的に管理できるので、共有するAWS環境の一貫性とコンプライアンスを維持できます。
例えば、システム管理者が構築したAWS環境をService Catalogに登録してアプリケーション開発者に共有することで、アプリケーション開発者は容易に自身のAWSアカウント内に開発環境をデプロイできます。また、システム管理者は共有したAWS環境のバージョンや使用履歴を一元管理できます。
【環境構築の自動化サービス】
インフラ環境を自動的に構築・管理するサービスには、「AWS CloudFormation」のほかに「AWS Elastic Beanstalk」などがあります。
CloudFormationはインフラやサーバーに関する知識が必要ですが、多くのAWSサービスに対応しており、柔軟な設定が可能です。
Elastic BeanstalkはCloudFormationほどの柔軟性はありませんが、サーバーやインフラに関する深い知識がなくても、定番の構成を利用して簡単にアプリケーションを公開できます。
※詳細は「Elastic Beanstalk」の分野を参照してください。
Cloud formationとElastic Beanstalkがどうしてもわからない
どの解説を読んでもCloud formationとElastic Beanstalkの違いがどうしても理解できないです。
Cloud formationは、リソースを構築できるサービスで
Elastic Beanstalk はインフラ環境をの構築できるサービスであると認識しております。
今回の設問は、WordPress環境を部署ごとに用意するためのサービスを聞かれていますが、なぜElastic Beanstalkが不正解なのか理由を教えていただきたいです。
AWS初心者のためなかなか理解できず、、
ぜひ回答よろしくお願いいたします。
CloudFormationとElastic BeanstalkはどちらもAWS環境を自動的に構築できるサービスですが、それぞれ下記のような特徴があります。
CloudFormation
・インフラ環境をコード化して各AWSリソースを構築する
・コードの書き換えによって、細かいカスタマイズが可能
・複数の環境をまとめて管理できる
Elastic Beanstalk
・基本的にAWSが用意したインフラ環境の中から選択する
・CloudFormationよりも容易に構築が可能な分、柔軟なカスタマイズはできない
・インフラの専門的知識を持たない人でも、AWS環境の構築が可能
設問の「この環境は企業の部署ごとに個別に用意する必要がある」ことから、WordPress環境を部署ごとにカスタマイズする要件があることが分かります。
Elastic Beanstalkは前述のとおり、AWSが容易したインフラ環境の中から選択するので、部署ごとの細かいカスタマイズしたい要件には適していません。
一方、CloudFormationでは部署全体の共通コードを作成し、部署ごとに異なる部分のみコードを書き換えるだけで対応できます。
各サービスの作成画面だけでも触ってみると理解が深まると思います。
最後のデプロイさえしなければ料金もかからないので。
コメント
この投稿に対して返信しませんか？