AWS OpsWorks Stacks のよくある質問
全般
Q: AWS OpsWorks スタックとは何ですか?
AWS OpsWorks スタックは、アプリケーションやサーバーを AWS 上とオンプレミスで管理できるようにします。OpsWorks スタックでは、ロードバランシング、データベース、アプリケーションサーバーなどのさまざまなレイヤーを含むスタックとしてアプリケーションをモデリングできます。Amazon EC2 インスタンスを各レイヤーにデプロイして設定することも、Amazon RDS データベースなどのその他のリソースに接続することもできます。OpsWorks スタックでは、事前に設定したスケジュールに基づいて、またはトラフィックレベルの変化に応じてサーバーの自動スケーリングを設定でき、ライフサイクルフックを使用することで環境の規模に合わせて変更を調整します。Chef Solo を使用して Chef レシピを実行することで、パッケージのインストールと言語やフレームワークのプログラミング、ソフトウェアの設定などのタスクを自動化できます。
Q: AWS OpsWorks スタックと AWS OpsWorks for Chef Automate では、どうような点が異なりますか?
OpsWorks for Chef Automate は、Chef Server を即座にプロビジョニングし、バックアップやソフトウェアのアップグレードなど、Chef Server の運用に使用できる、設定管理サービスです。このサービスは、Chef の Supermarket クックブックやレシピに完全に対応しています。TestKitchen、Knife などのネイティブの Chef ツールをサポートしています。OpsWorks スタックは、Amazon EC2 インスタンスにインストールされている埋め込みの Chef Solo クライアントを使用して、AWS でのアプリケーションのモデル化、プロビジョニング、管理に役立つサービスです。
Q: AWS OpsWorks スタックはどのような人にお勧めですか?
AWS OpsWorks スタックはシステム管理者や運用志向の開発者で、高機能なエンドツーエンドの設定管理ソリューションをお探しの方にお勧めです。AWS OpsWorks スタックは環境をカスタマイズして制御するための、より優れた管理とオートメーションのツールを必要とする DevOps ユーザーを対象にしています。AWS OpsWorks スタックには以下のような特長があります。
制御。AWS OpsWorks スタックでは、簡単な操作でアプリケーションの全コンポーネントをモデル化し、アプリケーションとそれがサポートするインフラストラクチャのさまざまな面を設定できます。アプリケーションライフサイクルの定義された段階で Chef レシピ (詳細はこちら) を使用してスクリプト化された変更を実行できるため、アプリケーション、およびアプリケーションと関連コンポーネントとの間のやり取りをきめ細かく制御できます。レシピはソースコードと一緒に保存できるため、変更を簡単に追跡できます。1 回のデプロイから自動スケーリングでの増加にいたるまで、アプリケーションにはそのライフサイクル全体を通じて設定が反映されます。
オートメーション。これまで手動で行っていたアプリケーションのスケーリング、保守、デプロイといった手順を AWS OpsWorks スタックで設定すれば、それらのタスクが自動的に実行されます。例えば、アプリケーションを実行するインスタンスをお客様が指定した設定 (デプロイするコードなど) どおりにセットアップすること、負荷ベースまたは時間ベースの自動スケーリングによりアプリケーションをスケールすること、障害の生じたインスタンスの検出と交換を行ってアプリケーションの状態を維持することができます。AWS OpsWorks スタックでは、Chef レシピを使用して、新しいアプリケーションサーバーインスタンスの開始、アプリケーションサーバーソフトウェアの設定、およびアプリケーションのデプロイが行われます。独自の Chef レシピを適用して、データベースやモニタリングインフラストラクチャを変更することもできます。
Q: AWS OpsWorks スタックを使うと、どのようなことができるようになりますか?
AWS OpsWorks スタックでは以下に対するソリューションが利用できます。
あらゆるアプリケーションのモデル化とサポート。Amazon Linux、Ubuntu、RHEL、および Windows で選択した設定でアプリケーションをデプロイできます。AWS OpsWorks スタックでは、レイヤーを使用してアプリケーションをモデル化できます。レイヤーによって、一緒に管理するリソース一式の設定方法を定義します。例えば、Amazon EC2 インスタンス、Amazon EBS ボリューム、および Elastic IP アドレスにより構成されるウェブレイヤーをアプリケーションに定義できます。また、レイヤーごとに、インストールスクリプトや初期化タスクなどのソフトウェア設定を定義することもできます。インスタンスをレイヤーに追加すると、AWS OpsWorks スタックにより、指定された設定が自動的に適用されます。AWS OpsWorks スタックでは Chef レシピ (詳細はこちら) がサポートされるため、PostgreSQL、Nginx、Solr など、コミュニティで作成されたさまざまな設定を活用できます。例えば、CouchDB データベースに接続された Django にインストールされた複数の Python アプリケーションから構成されるアプリケーションを作成することができます。
自動化タスク。AWS OpsWorks スタックでは管理作業を自動化し、ユーザーの手間を省いて確実に実行します。自動フェイルオーバー、パッケージ管理、Elastic Load Balancing の設定、インスタンスのルールベースまたは時間ベースの自動スケーリングを利用できます。共通のタスクは自動的に処理されます。このオートメーションを拡張やカスタマイズすることも可能です。また、AWS OpsWorks スタックでは継続的な設定管理をサポートし、例えば自動スケーリングなどのライフサイクルのイベントに合わせ、環境の変化に適合するようインスタンス設定を自動的に変更します。AWS OpsWorks スタックを使えば、何台ものマシンにいちいちログインして設定を手動で更新する必要はありません。AWS OpsWorks スタックでは環境が変更されるたびに設定が更新されます。
Q: どのようなアプリケーションの種類が AWS OpsWorks スタックでサポートされていますか?
AWS OpsWorks スタックでは、シンプルなウェブアプリケーションから非常に複雑なカスタムアプリケーションまで、さまざまなアプリケーションのアーキテクチャがサポートされています。
Q: AWS OpsWorks スタックにはどのようにアクセスすればよいですか?
AWS OpsWorks スタックへのアクセスには、AWS マネジメントコンソール、AWS SDK、AWS コマンドラインインターフェイスをご利用になれます。
Q: AWS OpsWorks スタックはどのようなリージョンで利用できますか?
OpsWorks スタックのリージョン別の可用性の詳細については、製品およびサービス一覧 (リージョン別) を参照してください。
Q: AWS OpsWorks スタックと AWS CloudFormation では、どのような点が異なりますか?
AWS OpsWorks スタックと AWS CloudFormation のどちらでも、アプリケーションのモデル化、デプロイ、設定、管理、および関連アクティビティがサポートされます。両サービスとも、シンプルなウェブアプリケーションから非常に複雑なアプリケーションに至るまで、さまざまなアーキテクチャのパターンをサポートします。AWS OpsWorks スタックと AWS CloudFormation が違うのは、抽象化レベルと対象領域です。
AWS CloudFormation は土台を作るサービスで、ほぼあらゆる AWS リソースのプロビジョニングと管理を、JSON ベースのドメイン固有言語で行うことができます。AWS CloudFormation の目的は AWS に汎用的な基本構成機能を提供することなので、開発と運用については特にモデルを規定していません。ユーザーはテンプレートを定義し、それらを使用して AWS のリソース、オペレーティングシステム、アプリケーションコードのプロビジョニングと管理を行います。
一方、AWS OpsWorks スタックはより高レベルのサービスで、IT 管理者および運用志向の開発者に対して、高い生産性と信頼性を持つ DevOps 環境を提供することに重点を置いています。このため、AWS OpsWorks スタックではスタックやレイヤーといったコンセプトに基づく設定管理モデルを採用しており、デプロイ、モニタリング、自動スケーリング、オートメーションといった主要なアクティビティに対して統一された操作性を実現できます。AWS CloudFormation に比べると、AWS OpsWorks スタックのサポート範囲は、Amazon EC2 インスタンス、Amazon EBS ボリューム、Elastic IP、Amazon CloudWatch メトリクスなど、アプリケーション志向の AWS リソースに限られています。
Q: AWS OpsWorks スタックと AWS Elastic Beanstalk では、どのような点が異なりますか?
AWS OpsWorks スタックは設定管理プラットフォームですが、AWS Elastic Beanstalk はアプリケーション管理プラットフォームです。
AWS Elastic Beanstalk は、Java、.NET、PHP、Node.js、Python、Ruby、Go、Docker で開発されたウェブアプリケーションとウェブサービスをデプロイおよびスケーリングするための、使いやすいサービスです。ユーザーがコードをアップロードすると、残りは自動的に処理されます。
AWS OpsWorks スタックと AWS Elastic Beanstalk のどちらでも運用は自動化されますが、対象のニーズと目的が異なります。AWS Elastic Beanstalk は、オペレーションについて心配せずにウェブアプリケーションをデプロイしたいとお考えの開発者向けに設計されています。開発者はコードをアップロードするのみで、キャパシティーのプロビジョニング、ロードバランシング、自動スケーリングからアプリケーションの状態のモニタリングまで、デプロイが自動的に処理されます。開発者側でインフラストラクチャやリソースの設定をすることなく、アプリケーションが使用できるようになります。
一方、AWS OpsWorks スタックは、高度なカスタマイズとオペレーションの制御が必要であるとお考えの IT 管理者および DevOps エンジニア向けの、統合された設定管理プラットフォームです。AWS OpsWorks スタックでは、Chef レシピを活用して、ソフトウェアの設定、パッケージのインストール、データベースのセットアップ、サーバーのスケーリング、コードのデプロイといった運用が自動化されます。
Q: AWS OpsWorks スタックで作成されたリソースを、その他のサービスコンソールやコマンドラインインターフェイスを使用して管理できますか?
環境を構築するために OpsWorks スタックで使用するすべてのリソースはそれぞれのサービス内に表示されていますが、一般的にはリソースは OpsWorks スタックのみで管理し、OpsWorks スタックのオートメーションの弊害を防ぐ必要があります。ただし、以下のようないくつかの例外もあります。
- AWS OpsWorks スタックはレイヤーで指定された設定に基づいてインスタンス用ボリュームの作成や削除を行います。ボリュームのスナップショットが必要な場合、またはインスタンスを削除したときに保持したボリュームを管理する場合は、Amazon EC2 サービスから直接操作します。
- AWS OpsWorks スタックはレイヤーに必要なポート番号をデフォルト値とする、レイヤー用セキュリティグループを生成します。セキュリティグループのカスタマイズ、または新規のセキュリティグループの作成が必要な場合、EC2 サービスでこれを直接行うことができます。
- AWS OpsWorks スタックはインスタンスに SSH 接続するためにキーペアを使用します。キーペアの作成や管理は、Amazon EC2 サービスから直接行います。
- AWS OpsWorks スタックはスタックに追加したユーザーに対してデフォルト AWS IAM ポリシーを作成します。よりきめ細かい権限が必要な場合は、それらの権限を IAM のユーザーに追加する必要があります。
- AWS OpsWorks スタックはすべてのリソースのメトリクスを Amazon CloudWatch に送信します。メトリクスの参照やアラームの設定は、Amazon CloudWatch から直接行います。
Q: AWS OpsWorks スタックのインスタンスは Amazon EC2 インスタンスと同じものですか?
AWS OpsWorks スタックのインスタンスにより Amazon EC2 インスタンスが定義されます。また、そのインスタンスと関連リソース (アベイラビリティーゾーン、タイプ、関連付けられたボリューム) との関係も定義されます。AWS OpsWorks スタックの 1 つのインスタンスは、その存続期間全体では多くの Amazon EC2 インスタンスに対応しますが、一度に対応するのは 1 つのみです。これにより、AWS OpsWorks スタックは始動時にボリュームや Elastic IP などのリソースと AWS EC2 インスタンスとのバインドの整合性を確保できます。
Q: AWS OpsWorks スタックに何か制限はありますか?
デフォルトでは、最大 40 のスタックを作成することができ、各スタックには最大 40 のレイヤー、最大 40 のインスタンス、最大 40 のアプリケーションを保持させることができます。その他の AWS の制限についても注意してください。例えば、AWS アカウントのデフォルト制限では、作成できる Amazon EC2 インスタンス数は最大 20 までです。より多くのリソースが必要な場合、リクエストフォームに記載してください。ご要望を速やかに審査いたします。OpsWorks スタックのレイヤーごとにインストールできるパッケージ数にも上限があります。インストールするパッケージ数を増やすには、カスタムクックブックを使ってパッケージをインストールします。
Q: AWS OpsWorks スタックでは Windows Server がサポートされますか?
はい。AWS OpsWorks スタックでは Windows Server 2012 R2 がサポートされています。
Q: AWS OpsWorks スタックではオンプレミスサーバーがサポートされますか?
はい。AWS OpsWorks スタックでは、OpsWorks スタックエージェントのインストールが可能で、AWS パブリックエンドポイントに接続できるすべての Linux マシンがサポートされています。
Q: AWS OpsWorks スタックを利用するための、サーバーのネットワーク条件は何ですか?
サーバーが AWS パブリックエンドポイントに接続できることが必要です。
開始方法
Q: AWS OpsWorks スタックにはどのようにサインアップすればよいですか?
AWS OpsWorks スタックにサインアップするには、OpsWorks スタックの詳細ページにある [今すぐ始める] をクリックしてください。このサービスのご利用にはアマゾン ウェブ サービスのアカウントが必要です。お持ちでない場合は、AWS OpsWorks スタックプロセスの開始時にアカウントの作成を求めるプロンプトが表示されます。
アプリケーションの設定と管理
Q: AWS OpsWorks スタックを使用すると、アプリケーションのどの要素を制御できますか?
AWS OpsWorks スタックでは、ロードバランサー、サーバーソフトウェア、データベースなど、アプリケーション全体の設定が定義されます。インスタンスにデプロイされるソフトウェアパッケージ、および Elastic IP やセキュリティグループといったその他の設定詳細を定義するレイヤーを構築することにより、スタックのすべての部分を制御できます。リポジトリを指定し、必要に応じて Chef レシピを使用して、レイヤーにソフトウェアをデプロイし、ディレクトリやユーザーの作成、データベースの設定など Chef が実行できるすべての作業を自動化することもできます。OpsWorks スタックの組み込みのオートメーションを使用して、アプリケーションのスケーリングやインスタンスの障害からの自動復旧を行うことができます。アプリケーションが使用するインスタンスへの SSH アクセスをはじめとし、アプリケーションが使用するリソースの参照や管理ができるユーザーを制御できます。
Q: AWS OpsWorks スタックはどのようなソフトウェアバージョニングおよびリビジョン管理システムをサポートしますか?
AWS OpsWorks スタックは、デプロイするコードを Git や Subversion のような一般的なバージョン制御システムのみでなく、HTTP、プライベートまたはパブリックの S3 バンドルからも取得できます。例えば、Git リポジトリから取得したバージョンまたはブランチを OpsWorks スタックのアプリケーション定義に追加して、アプリケーションの特定のバージョンをデプロイできます。rsync または scp を使用して、お好みの場所から Chef レシピを使用してアプリケーションをデプロイすることもできます。
Q: AWS OpsWorks スタックはどのオペレーティングシステムをサポートしますか?
AWS OpsWorks スタックは現時点で、Amazon Linux、Ubuntu 12.04 LTS、Ubuntu 14.04 LTS、Windows Server 2012 R2 をサポートしています。
Q: AWS OpsWorks スタックでは Microsoft Windows をサポートしますか?
はい。AWS OpsWorks スタックでは Windows Server 2012 R2 がサポートされています。
Q: AWS OpsWorks スタックを使用して高い可用性を備えたアプリケーションをデプロイすることはできますか?
はい。アプリケーションが水平スケーリングをサポートする場合、複数のアベイラビリティーゾーンでインスタンスを作成することができます。またお使いのロードバランサーがインスタンス間のトラフィックをルーティングします。インスタンスのいずれかで障害が発生した場合、OpsWorks スタックの自動復旧によりインスタンスが交換されます。アクティブノードとパッシブノードを備えたデータベースなど、アプリケーションがその他の技術を使用して可用性の目標を達成している場合、Chef レシピを使用してアプリケーションを設定することができます。
Q: AWS OpsWorks スタックでアプリケーションをモデル化するには、どうすればよいですか?
AWS OpsWorks スタックには、アプリケーションをモデル化するための次のような 3 つのコンセプトがあります。
「スタック」は最上位レベルの管理単位です。スタックには、Amazon EC2 インスタンスと「レイヤー」と呼ばれるインスタンスの設計図のセットが格納されます。レイヤーはインスタンスの起動と管理に使用されます。アプリケーション、ユーザー許可、その他のリソースは、スタックのコンテキスト内で調査および制御されます。例えば、フロントエンドのロードバランサー、PHP サーバー、PHP アプリケーション、MySQL データベースなどのウェブアプリケーションの開発環境用にスタックを作成する場合があります。開発環境のスタックを複製することで得られる同じような設定を使用して、実動環境用のスタックを作成することもできます。
「レイヤー」はインスタンス、およびボリューム、Elastic IP のような関連リソースのセットアップ方法や設定方法の設計図です。レイヤーは SSL 設定のようなインフラストラクチャの設定を自動的にサポートします。また各レイヤーに、インストールスクリプト、初期化タスク、パッケージといったソフトウェア設定を定義することもできます。例えば、Ruby レイヤーを使用する場合、OpsWorks スタックで Rails のみでなくアプリケーションに必要なすべての Gem をインストールできます。またレイヤーには、Chef レシピ (詳細については、クックブックとレシピを参照) を使用して、インスタンスの状態の変化に対応する設定アクションを自動化できるライフサイクルイベント (詳細については、AWS OpsWorks のライフサイクルイベントを参照) があります。レイヤーには、時間ベースまたはロードベースの自動スケーリングを含めることができ、手動で操作することなく需要ピークを処理できます。
「アプリケーション」はリポジトリ（例えば Git、S3 など）からダウンロードしたソフトウェアで、レイヤーにデプロイされます。デプロイライフサイクルイベントを使用して、アプリケーションをデータベースに接続するなどの設定手順を自動化できます。OpsWorks スタックでは、スタックごと、レイヤーごとに複数のアプリケーションをデプロイできます。
Q: Chef とは何ですか、また AWS OpsWorks スタックは Chef をどのように使用しますか?
Chef は Chef Software, Inc. により提供されるオープンソースフレームワークで、アプリケーションの設定、デプロイ、管理を、コードを使って自動化します。AWS OpsWorks スタックでは Chef レシピを使用してソフトウェアコンポーネントを Amazon EC2 インスタンスにデプロイし、設定します。Chef のエコシステムは充実しており、AWS OpsWorks スタックに利用できる PostgreSQL、Nginx、Solr などのクックブックが豊富にあります。
Q: ライフサイクルイベントとは何ですか?
AWS OpsWorks スタックではライフサイクルの各ステージに応じたイベントが作成されます。これらのイベントは各インスタンスで Chef レシピをトリガーするのに使用され、特定の設定タスクが実行されます。OpsWorks スタックでは、Chef レシピを活用して、レイヤーのタイプに応じてイベントごとに基本的な管理が実施されます。カスタムレシピを作成して、特定のライフサイクルイベントに対応するためにアプリケーションに必要な、任意の設定変更をスクリプト化することもできます。以下のライフサイクルイベントがサポートされています。
Setup はインスタンスが初期化されたとき、または正常に起動したときにインスタンスに送信されます。例えば、Rails アプリケーションサーバー向けに、Apache、Ruby、Passenger、Ruby on Rails といった依存関係をインストールする Chef レシピをトリガーできます。
Configure はスタックの状態が変化するたびに、すべてのインスタンスに通知されます。例えば、新規インスタンスがアプリケーションサーバーレイヤーに正常に追加されると、設定イベントにより、OpsWorks スタックのロードバランサーレイヤーの設定を更新する Chef レシピがトリガーされ、追加されたアプリケーションサーバーのインスタンスが反映されます。
Deploy はアプリケーションがデプロイされるたびにトリガーされます。また、Rails アプリケーションサーバー向けに、アプリケーションを確認してダウンロードするのに必要なタスクを実行し、Passenger に再ロードを指示する Chef レシピをトリガーできます。
Undeploy はアプリケーションが削除されたときに送信されます。例えば、Undeploy イベントはデータベーステーブルの削除など、実行する必要があるクリーンアップ手順を指定するカスタムの Chef レシピを起動できます。
Shutdown はインスタンスが実際に停止する 45 秒前にインスタンスに送信されます。例えば、Shutdown イベントはサービスをシャットダウンするカスタムの Chef レシピを起動することができます。
Q: Chef のクックブックとレシピはどのように作成しますか?
最も簡単な方法は、既存の Chef レシピを使用することです。公開レポジトリで豊かなエコシステムが形成されており、そこには少しの修正で実行できるレシピから修正が不要なレシピまで、さまざまなレシピを含む Chef クックブックが存在しています。OpsWorks スタック入門ガイドには、サンプルの Chef レシピと、そのレシピがどのように動作するかの説明もあります。
Q: 独自の AMI を使用することはできますか?
はい。独自の AMI を使用するか、Chef スクリプトを使って OpsWorks スタックでサポートされている AMI をカスタマイズし、必要なエージェントやその他のソフトウェアをインストールできます。現時点では、独自の Windows AMI の使用はサポートされていません。
Q: Amazon EC2 ユーザーデータを使用してインスタンスのセットアップをカスタマイズすることはできますか?
いいえ。インスタンスのセットアップは Chef レシピによってのみ実行されます。
Q: AWS OpsWorks スタックではどのようなロードバランスオプションをサポートしています?
OpsWorks スタックでは、Elastic Load Balancing を使用すること、HAProxy でコミュニティの Chef レシピを使用すること、カスタムレイヤーや Chef レシピを使用して EC2 インスタンスにインストールしたロードバランサーを使用することができます。そのため、幅広いカスタマイズオプションが利用可能であり、アプリケーションのロードバランサ―をきめ細やかに制御することを可能にしています。
Q: AWS OpsWorks スタックがサポートする自動インスタンススケーリングオプションにはどのようなものがありますか?
OpsWorks スタックでは、実行中のインスタンス数を負荷に合わせて調整するために、時間ベースと負荷ベースのインスタンススケーリングがサポートされています。負荷ベースの自動スケーリングでは、CPU、メモリ、負荷にしきい値を設定し、インスタンスを追加作成するタイミングを定義できます。負荷のスパイクがなくなり、縮小スケーリングのしきい値に達すると、OpsWorks スタックは追加のインスタンスをシャットダウンします。時間ベースの自動スケーリングでは、インスタンスを作成や削除する時刻を定義できます。自動スケーリングプールのインスタンスはサイズが多様なため、段階的にスケーリングすることも、素早くスケーリングすることもできます。また複数のアベイラビリティーゾーンに対応するように設定し、信頼性を高めることができます。OpsWorks スタックは現時点では EC2 Auto Scaling をサポートしていません。
Q: AWS OpsWorks スタックはどのようなモニタリングオプションやアラームオプションをサポートしていますか?
OpsWorks スタックでは、すべてのインスタンスとボリュームのメトリクスを CloudWatch に送信します。これによりグラフの参照やアラームの設定が簡単にできるようになり、トラブルシューティングやリソースの状態に基づく自動アクションの実施に役立ちます。また、OpsWorks スタックのモニタリングビューでは、OpsWorks スタックによりインスタンスから収集される 13 のメトリクス (CPU、メモリ、負荷など) の 1 分間のモニタリング結果を表示することもできます。
Q: AWS OpsWorks スタックではどのようなデータベースがサポートされますか?
Amazon RDS などの AWS のサービスを使用することや、Chef レシピを使用して MySQL、Cassandra、MongoDB などのデータベースをインストールすることができます。そのため、幅広いカスタマイズオプションが利用可能であり、アプリケーションのデータベースをきめ細やかに制御することを可能にしています。
Q: AWS OpsWorks スタックはタグをサポートしていますか?
OpsWorks スタックでは、すべてのリソースに対し、関連するスタックとレイヤーの名前を使って自動的にタグ付けが行われます。これらのタグをコスト配分レポートと一緒に使用し、付けられたタグを利用して AWS の費用の整理や追跡を行うことができます。コスト配分とタグ付けの詳細については、AWS Account Billing を参照してください。
セキュリティ
Q: Amazon Virtual Private Cloud (VPC) 内で自分のアプリケーションを実行できますか?
はい。詳細については、OpsWorks スタックのドキュメントを参照してください。
Q: AWS Identity & Access Management (IAM) を AWS OpsWorks スタックと一緒に使用することは可能ですか?
はい。OpsWorks スタックでは、IAM のユーザー、権限、ロールがサポートされています。参照、デプロイ、管理など、ユーザーごとの権限を指定することができます。また、インスタンスに直接 SSH 通信を行うことができるユーザーを指定することもできます。OpsWorks スタックでは、 OpsWorks スタックへのユーザーアクセスを許可する IAM ロールがサポートされています。EC2 のような従属先サービスへのアクセスを許可する必要はありません。例えば、ユーザーによる EC2 アクションの実行を明示的に拒否できます。ただし、スタックのリソースをデプロイまたは管理するための OpsWorks スタックの権限が付与されていれば、そのユーザーは OpsWorks スタックから EC2 インスタンスを制御できます。これにより、OpsWorks スタックのユーザーが不注意で EC2 コンソールからインスタンスを停止してしまうのを防ぐことができます。
Q: 自分のインスタンスのどのポートを開放するかを管理できますか?
AWS OpsWorks スタックでは、標準的な一連の組み込みセキュリティグループが、レイヤーごとに 1 つ提供され、デフォルトでレイヤーに関連付けられています。また、スタックの OpsWorks スタックセキュリティグループ設定を使用すれば、独自のカスタムセキュリティグループを提供することもできます。このオプションでは、適切な EC2 セキュリティグループを作成し、作成した各レイヤーとセキュリティグループを関連付ける必要があります。ただし、作成時に組み込みセキュリティグループとレイヤーを手動で関連付けることもできます。カスタムセキュリティグループは、カスタム設定を必要とするレイヤーにのみ必要です。セキュリティグループの詳細については、「Amazon EC2 セキュリティグループ」を参照してください。OpsWorks スタックでは、インスタンスを設定するために、EC2 インスタンスからのポート 443 を通じたアウトバウンド接続が必要となります。
Q: AWS OpsWorks スタックはインスタンスで何を実行するのですか?
OpsWorks スタックではインスタンスでエージェントを使用して設定タスクを実行し、状態を知らせるハートビートが提供されます。エージェントはオペレーティングシステムの非特権ユーザーとして稼働します。すべてのインスタンスにはデプロイに使用するユーザーが含まれます。このユーザーはログイン権限やアクセス権限は一切持たず、デプロイするための権限しかありません。
Q: AWS のセキュリティとアプリケーション実行について、どこで詳細な情報を入手できますか?
AWS のセキュリティの詳細については、「アマゾン ウェブ サービス: セキュリティプロセスの概要」を参照し、セキュリティセンターをご覧ください。
請求
Q: アプリケーションがどれくらいの AWS リソースを使用したかどのようにチェックできますか? また、どのように請求書にアクセスできますか?
当期の請求額はいつでもアマゾン ウェブ サービスのウェブサイトで確認できます。アマゾン ウェブ サービスアカウントにログインして、[Your Web Services Account] の下の [Account Activity] をクリックしてください。OpsWorks スタックでは、すべてのリソースに対し、関連するスタックとレイヤーの名前を使って自動的にタグ付けが行われます。これらのタグをコスト配分レポートと一緒に使用し、付けられたタグを利用して AWS の費用の整理や追跡を行うことができます。
AWS OpsWorks スタックの構築を始めましょう