Amazon Web Services ブログ

Category: Management Tools

委任された管理者からAWS Configルールと適合パックをデプロイする

AWS Configルールの使用により、リソースの構成をベストプラクティスに照らし合せて評価し、決められた構成ポリシーに従っていない場合は修正することができます。 AWS Config適合パックを使用すると、AWS Organizations全体に適用されるAWS Configルールと修復アクションのセットを単一のパックで作成できます。これにより、Configルールの集中管理と展開が可能になります。 今までは、組織全体にまたがる適合パックとConfigルールの展開は、組織のマスターアカウントのみが実施できました。しかし、マスターアカウントを一括請求にのみ使用するお客様も多数おられます。お客様がセキュリティ、監査、コンプライアンスのための専用アカウントを持っている場合、代わりにその専用アカウントを使って組織全体にわたるConfigの展開を管理したいと考えるでしょう。このようなご要望にお応えして、AWS Organizationsの非マスターアカウントからConfigルールと適合パックのデプロイができるようになりました。このAWS Config新機能を使用すると、これらのConfigリソースをAWS Organizations全体に展開し管理できる権限を委任する管理者アカウントを登録できます。 このブログ投稿では、委任された管理者アカウントにて、組織全体に適合パックを展開し、AWS Configルールと適合パックを管理する方法について示します。

Read More

CloudFormation で cfn-init に代えて State Manager を利用する方法とその利点

はじめに AWS CloudFormationを介してAmazon Elastic Cloud Compute (EC2) インスタンスをデプロイした後には、ソフトウェアのインストール、またはオペレーティングシステムの設定が必要になることがほとんどです。多くのAWSのお客様はCloudFormationのヘルパースクリプトの一つである cfn-init (2012年2月から利用可能)を使用していると思います。しかし、それ以後もAWSは、お客様のフィードバックに応じて多くの新機能とサービスをリリースしてきました。そのうちの一つはAWS Systems Managerです。このブログ記事では、AWS CloudFormationを介してデプロイされたAmazon EC2インスタンスに対して、AWS Systems Manager State Managerを使用してインスタンスを設定する、よりシンプルで堅牢な方法を紹介します。

Read More

クラウドサービスの評価を最適化する方法

本投稿はワールドワイドで金融業界を担当しているプリンシパル・テクニカルプログラムマネージャーの Jennifer Code による寄稿を翻訳したものです。 私の同僚の Ilya Epshteyn が、 金融機関が機密性の高いデータのためにAWSサービスを承認する方法 というタイトルのブログでご紹介したように、金融業界では一般的にクラウドサービスの正式な評価プロセスが存在します。これらの評価プロセスは深さや幅に関しては様々ですが、いずれのプロセスも、業界の期待とテクノロジーリスク管理の健全性を確保しつつ、ビジネス要件を満たすのにはどのクラウドサービスが最適かを決定しようとするものです。このブログでは、クラウドサービスに対する新たな評価プロセスを構築する、または既存の評価プロセスを最適化する際に役立つシンプルなガイダンスを提供します。 私は、お客様と頻繁に会ってお客様のガバナンスとクラウドの評価プロセスについてディスカッションをしますが、その中でよく耳にするテーマがいくつかあります。1つ目は、評価プロセスが正式に存在する場合であっても、オーナー不在の場合が多く、結果としてそのプロセスが達成すべきビジネス上の成果を必ずしも理解しないまま、チームがプロセスに従っているという問題です。強いオーナーシップがなければ、参加者と評価範囲に一貫性が保てません。また、時には、構造化されたフレームワークではなく、個々の専門知識とベストエフォートに依存しているため機能性に差異が生じている場合もあります。最後に、お客様は、ほとんど例外なく、知識の共有を進めつつ、繰り返し学ぶことによって、評価プロセスの質を一気に向上させる方法があるのではと感じています。 正式なクラウドサービス評価プロセスがとても重要なのはなぜでしょうか? 金融サービス会社は、テクノロジーリスクの監視を証明するという、共通の規制上の義務を負っています。従来、企業のリスクフレームワークは、サイロ化された「3 つのラインによる防御」または (3LoD) で構成されていました。第一のラインはリスクの所有者としてコントロールを実行するビジネス / 運用担当者、第二のラインはリスクのモニタリングとコントロールの評価を行うリスク管理担当者、第三のラインは独立または内部監査人、またはリスクアシュランス担当者で構成されています。これらの 3LoD はそれぞれ、テクノロジーリスク、一般的な社内のポリシーの収集、ならびに他の防御ラインによって行われた一連の評価・監査に合わせて自チーム内で文書化された手順についての責任を負ってきました。 この既存の企業リスクフレームワークにクラウドの評価プロセスを組み込むことで、組織は重要な技術上の意思決定がどのように行われたかを適切に証明できるようになります。また、リスクがどのように評価され、軽減されるか、コントロール環境の強さがリスクアペタイトにどのように適合しているかといった点を、クラウドベースのサービスの微妙な差異に焦点を当てつつ説明できるようになります。 クラウド評価を最適化するためのヒント 金融サービスのお客様の期待を念頭に置き、お客様がクラウド評価プロセスを構築または改善するために実行できる3つのアクションを提案します。 ガバナンス体制の正式化。ガバナンス体制が正式に確立されていない場合、金融サービス機関がとるべき最初のステップは、クラウドのガバナンスとコントロールに関してエンドツーエンドの責任を担うC-レベルの経営幹部を任命することです。 プラットフォーム コントロールの優先順位付け。クラウド評価を策定する際に、優先順位と要件について、クラウド・プラットフォームとビジネス・アプリケーション機能の区分を取り入れます。セキュリティとレジリエンスのためのプラットフォームレベルのコントロールを最初の優先事項として重要視します。ビジネス・アプリケーションの機能に視点が移った時に、クラウドプラットフォームから継承されたコントロールに基づいて評価を調整できるようになります。 継続的な改善の組み込み。 知識共有と継続的な改善は、Day 1から明確に優先されるべきです。積極的な透明性があることにより、コントロールが構築され評価が行われる際に、3つの防御ラインすべてにわたっての信頼が築かれることが期待されます。意識的かつ積極的な共有によって、コントロールが設計されており、最初の本番ユースケースに対しても効率的に実行することができるという自信につながります。 AWSの使用量と専門知識が増えるにつれて、コントロールの強化と適用範囲の継続的な改善も容易になります。 ガバナンス体制の正式化 重要な最初のステップはクラウドのガバナンスに対する完全な説明責任を持つ適切な Cレベルの経営幹部を特定することです。この個人は、はじめにクラウドのガバナンスとコントロールのトーン設定を行い − クラウドの評価、使用状況、および継続的なモニタリングのための構造とプロセスを構築する責任をもちます。重要なのは、組織全体の専門知識を活用して、十分に制御されながらアジリティのある環境を確立するよう促す意欲のある、強力でポジションの高いリーダーを任命することです。 そのガバナンスのリーダーは任命され次第、評価プロセスを形成する機能横断的な構造、成文化されたポリシーと必要となるガバナンスプロセスを正式化し、現在進行中の評価のサポートをしなくてはなりません。私の経験では、正式なガバナンスの枠組みに支えられた多様な専門知識を活用できるバーチャルなチームが最も効果的です。 効果的なクラウドガバナンスの考慮事項 効果的なクラウドガバナンスの目標を定め、専門知識を正当に評価する企業全体のクラウド戦略 は、導入と使用状況を測定しながら時間をかけて構築します。 クラウドガバナンスに責任のある経営幹部を任命、従事、およびコミットすることで全体的なガバナンス構造に統合し、継続的なモニタリングを行います。 知識が豊富で 参加を約束できる(3 つの防御ラインにまたがった)リスクとコントロールのステークホルダーをクラウドのガバナンス活動における正式な参加者 にします。 企業のガバナンス フレームワークとプロセスに準拠することで、クラウドイネーブルメントチームの存在を明確にします。 定義されたプロセスを組織に伝達するとともに、承認されたクラウドサービスのみを利用していることを確実にする自動強制機能を使用します。 プラットフォーム コントロールの優先順位付け 私と顧客とのやり取りでよく見られたパターンは、クラウドサービスを評価するにあたり、たった1つのアプローチを作成し、それを全てのパターンに当てはめようとするやり方です。これは典型的に、各サービスを個別に評価する形式をとり、多くの場合、体系的に完成された詳細なチェックリストを伴います。 なぜこれが理想的ではないのでしょうか? 第一に、これは各サービスへの脅威は同等であることを前提としています(したがって、同じ評価が必要なコントロールを決定する適切な方法とされます)。第二に、このタイプのアプローチでは、評価者が能力または機能により区別することは認めていません(たとえば、データを中心としたサービスとコンピューティング サービスの違いを考慮しません)。最も重要な点は、既存の統制基盤を考慮していないことです(したがって、追加のコントロールの必要性を過大評価してしまう可能性があります)。 私が見てきた中で最も効果的だったのは、交渉不可能な基盤を確立した上で、環境、データの機密性、ビジネスの重要性など、他の要因に基づいて必要なコントロールを追加する、段階的なコントロール フレームワークです。この区分けによって、不適切なレベルのリスクを発生させることなく、実験を行うことができます。具体的には、すべてのデータタイプ、すべての環境において最初から予防的統制でなければならないコントロールもありますが、その他のコントロールではモニタリングをサポートすることによって、発見的統制から始めることが許容できるかもしれません。適切にコントロールされたイノベーションが目標です。 […]

Read More

【Edit in the Cloud】ご利用のポストプロダクションアプリケーションをAWS仮想デスクトップ インフラストラクチャにデプロイするために

今や仮想化は、クリエイティブな専門家が在宅勤務で仕事をする上で必要な環境となりました。本ブログでは、AWSクラウド上でポストプロダクションアプリケーションを実行する場合に重要な考慮事項を説明します。

Read More

Amazon EC2 スポットインスタンスを活用したウェブアプリケーションの構築

本記事は、EC2スポットインスタンススペシャリスト シニアソリューションアーキテクトのIsaac Vallhonratによる寄稿です。 Amazon EC2 スポットインスタンスを使うと、AWS クラウド内の使用されていない EC2 キャパシティーを用いて、オンデマンド料金に比べ最大 90% の割引価格でご利用いただけます。スポットインスタンスは、バッチジョブ、ビルド等のCI/CDパイプライン、負荷テスト、コンテナ化されたワークロード、ウェブアプリケーション、ビッグデータの分析クラスター、ハイパフォーマンスコンピューティング(HPC)用計算クラスターなど、複数のインスタンスタイプで柔軟に実行できる、耐障害性を備えたワークロードに最適です。このブログ投稿では、スポットインスタンスでウェブアプリケーションを実行するための方法とベストプラクティスについて説明し、これによりもたらされるスケールと費用節減の両方のメリットを得られるようにします。 スポットインスタンスには中断という特徴があります。この特徴を踏まえて、これから構築するウェブアプリケーションはステートレスかつ耐障害性があり、また疎結合されていることが望ましいです。また永続データの保持には Amazon ElastiCache, AmazonRDS, Amazon DynamoDB などの外部データストアを使用する必要があります。 スポットインスタンスのおさらい 2009 年に提供開始されたスポットインスタンスは、ここ最近のアップデートや関連サービスとの統合によって、お使いのワークロードで格段に活用しやすくなっています。ウェブアプリケーションを構築する方法の詳細に入る前に、スポットインスタンスの動作の概要のおさらいにお付き合いください。 まず、スポットインスタンスは EC2 の購入オプション、買い方のひとつです。 他の購入オプションである、オンデマンドインスタンス、リザーブドインスタンスやSavings Plansで起動した場合と比べて、EC2インスタンスとして提供するハードウェアに違いはありません。スポットインスタンスと他の購入オプションの違いはただ一つ、EC2 サービスが容量を必要とする場合には、2 分前に通知したのち、EC2サービスがスポットインスタンスを中断する、という動作です。つまり、大幅な割引価格で提供する代わりに、オンデマンドインスタンスやリザーブドインスタンスからの起動需要が高まってきたとき、スポットインスタンスの使用していたキャパシティをEC2サービスに戻し、需要に応える、というのがスポットインスタンスサービスの動作原理です。 スポットインスタンスは、スポットキャパシティプールと呼ばれる、いわば空きキャパシティがある限り起動できます。スポットキャパシティプール(スポットプール)とは、とは、インスタンスタイプ (m5.large など), オペレーティングシステム種別(Linuxなど), アベイラビリティーゾーン (us-east-1a など) が同一である、Amazon EC2 サービスが使用していない(空の) EC2 インスタンスの集合を指します。属性の異なるプール同士はそれぞれ独立したプールとして区別されます。例えば、us-east-1aゾーンのLinux向けm5.largeのスポットプールと、us-east-1bゾーンのLinux向けm5.largeのスポットプールは、独立した別のプールです。このそれぞれに空きがあるとき、スポットインスタンスを起動し、使用できます。 スポットインスタンスの料金は Amazon EC2 サービスによって設定され、各プールの EC2 インスタンスの需要と供給の長期的な傾向に基づき、徐々に調整されます。スポット料金は急激に変化することはなく、突然のスパイクや変動がないことが期待できます。 EC2 マネジメントコンソールと API の両方から、最大過去 3 か月間の価格履歴データを表示できます。次の図は、バージニア北部 (us-east-1) リージョンにおける m5.xlarge […]

Read More

既存のAWSアカウントを AWS Control Tower へ登録する

AWS Control Tower のリリース後、多くのお客様からいただいていたご要望がありました。既存のAWS Organizations に AWS Control Tower をデプロイすることと、組織が持つ他のアカウントにもガバナンスを拡張することです。 このたび、AWS Control Tower を既存の AWS Organization にデプロイできるようになったことをアナウンスいたします。一方で、AWS Control Tower をデプロイする前に作成した AWS アカウント(ここでは「未登録アカウント」と呼びます)は、デフォルトでは AWS Control Tower ガバナンスの範囲外になります。そのため、これらの未登録アカウントは明示的に AWS Control Tower へ登録する必要があります。 既存アカウントを AWS Control Tower へ登録することで、アカウントベースライン(基本設定)と追加のガードレールが配備され、継続的なガバナンス(Continuous Governance)が有効になります。なお、アカウントを登録する前には、適切なデューデリジェンス(事前評価)を行う必要があります。以下に記載されている「考慮すべき事項」セクションの追加情報を参照してください。 このブログでは、AWS Organizations 内の 未登録 AWS アカウントと 未登録 OU(Organization Units = 組織単位)内のアカウントを、プログラムによって AWS Control Tower へ登録する方法を解説します。

Read More

AWS Config 適合パックを使用したAWS Control Tower発見的ガードレールの実装

多くのお客様から、AWS Control Towerによるガバナンスを実現する前に、Control Towerの発見的ガードレールだけを既存のAWSアカウントに適用したいという要望をいただいています。この度、既存のAWS OrganizationでAWS Control Towerを起動できるようになりました。これにより、お客様は既存のアカウントにてAWS Control Towerの発見的ガードレールのコンプライアンスを適用できるようになりました。加えて、我々はControl Towerの配下にアカウントを登録する機能も発表しました。Control Towerガバナンスをアカウントに拡張する前に、Control Towerのガードレールがアカウントにどのように影響するかを確認することをお勧めします。 このブログでは、AWS Config適合パックを使用してControl Towerガードレールを既存のアカウントに適用する方法を示します。AWS Control Towerに登録する前に、そのアカウントのリソースのコンプライアンスを評価できます。また、適合パックを変更し、管理されていないアカウントに発見的ガードレールのサブセットを適用する方法を示します。最後に、適合パックを使用して、AWS Control Towerがデプロイされていないリージョンに存在するアカウントのリソースを管理する方法を示します。

Read More

AWS Config 適合パックの紹介

AWS Config  適合パック(コンフォーマンスパック)を紹介できることを大変嬉しく思います。適合パックは、共通のフレームワークとパッケージモデルを用いて、ポリシー定義から監査、集計レポートに至るまで、大規模なAWS リソースのコンプライアンス設定を管理するのに役立ちます。 注:本記事の原文は2019年12月に公開されていますが、2020年4月に適合パックの追加(AWS Control Tower ガードレール適合パック、CIS コンプライアンスパック)が行われたことに伴い、今回改めて翻訳を実施致しました。 適合パックとは 適合パックを使用すると、コンプライアンスルールのパッケージを作成することができます。このパッケージはAWS Config ルールと修復アクションの両方を単一のエンティティにまとめたもので、大規模な展開を容易にします。そして、これらを組織全体に展開し、顧客や他のユーザーと共有できます。さらに、適合パックによりコンプライアンス・レポートも簡素化されます。これからは適合パックレベルでのレポートが可能になり、そこから従来通り個別のルールやリソースのレベルへ詳細化していくことも可能です。既存のレポート機能はすべてそのまま機能したままで、異なるチーム、異なるコンプライアンス体制、もしくは異なるガバナンス体制によって管理されたコンプライアンスセットを論理的にグルーピングすることができます。 適合パックは、AWS CloudFormation と同様にマークアップを使用して記述されます。必要なのはルールをResourcesセクション内で宣言するのみです。残りは AWS Config によって行われます。オプションで、AWS CloudFormation と同じようにParameters セクションを用いることで、より柔軟な適合パックを構築することもできます。なお、適合パックは YAML 形式のファイルで記述されます。 注意:適合パックの特徴は、それらが不変 (immutable)であることです。個々のルールは、アクセス権限やアカウントの権限に関係なく、デプロイされたパックを外部から変更することはできません。さらに、パックが組織のマスターアカウントによって展開されている場合、組織のメンバーアカウントによって変更することはできません。これにより、企業全体のコンプライアンスを管理する際に、セキュリティと確実性がさらに高まります。

Read More

クラウドを展開する上で確立すべきガバナンス、リスク、コンプライアンス

ビジネスリーダーやテクノロジーリーダーと話すと、彼らは新しい製品やサービスを迅速に市場に投入することが必要だと話します。その一方で、彼らはセキュリティを継続的に確保する必要もあります。また同時に、時間とともに変化するビジネスニーズにワークロードを適応させながら、回復力のある環境を維持する必要があります。このブログシリーズでは、AWSのベストプラクティスを共有して、お客様がこれらのセキュリティ、スケーラビリティ、および適応性の要件を満たすようにAWS環境を計画するのを支援します。 私の目標は、クラウド環境の配備を管理するための設計上の考慮事項についてお客様をガイドすることです。このブログシリーズでは、今後、このガイダンスに沿った一般的なユースケースとパターンの実装を解説するブログを投稿していきます。

Read More

AWS License Managerをつかってライセンス使用数を管理する方法

AWS License Manager を使うことで、ソフトウェアライセンスを効率的にクラウドに持ち込むことができます。AWSでサードパーティのライセンスを使ったアプリケーションを構築したり、オンプレミスのワークロードをAWSに移行したりする際、BYOL(bring-your-own-license)を用いてコストを節約可能です。これはすでにお持ちのソフトウェアライセンスをクラウドリソースとして再利用することによって実現されます。今回は、AWS License Manager を使用して、一元的にこれらのライセンス使用数を管理する方法についてご説明します。

Read More