Amazon Web Services ブログ

Category: AWS CloudFormation

セルフマネージド型 Active Directory を AWS Control Tower に拡張

クラウドジャーニーの初期段階によくあるユースケースの 1 つとして、既存のアイデンティティサービス (Microsoft Active Directory など) を使用することが挙げられます。このブログでは、AWS Control Tower をセットアップして、AWS Managed Microsoft AD を介してユーザー認証をセルフマネージド型 Microsoft Active Directory に委任する方法について解説します。既存のオンプレミスの Active Directory を AWS Control Tower に接続する方法を、シミュレート環境でみていきます。 背景 AWS Control Tower には、マルチアカウント環境における SSO アクセスを簡素化するクラウドベースのサービス、AWS Single Sign-on (AWS SSO) が組み込まれています。ユーザー認証の管理は、AWS SSO を使用して、AWS Control Tower に接続されたディレクトリが行います。各ユーザーに割り当てられたアカウントアクセスおよび付与されたアクセス許可のレベルによって、認証が判断されます。 AWS SSO はアクセス許可のセットを使用します。これは、ユーザーのアクセス許可が、所定の AWS アカウントにアクセスするために有効かどうかを判断する、管理者定義ポリシーのコレクションです。アクセス許可のセットには、AWS が管理するポリシーまたは AWS SSO に保存されているインラインポリシーのいずれかが含まれています。ポリシーとは、基本的に、1 つまたは複数のアクセス許可ステートメントのコンテナとして機能するドキュメントのことです。所定の AWS アカウント内でユーザーがどのアクションを実行できるかまたはできないかは、これらのステートメントが判断します。アクセス許可のセットは […]

Read More

cfn-lint を使った AWS CloudFormation テンプレートの Git pre-commit バリデーション

AWS CloudFormation のツールはいまや黄金期をむかえています。cfn_nag や taskcat といったツールによって、1 つのリソースをアカウントにデプロイする前にテストと検証を実行することで、コードとしてのインフラストラクチャの取り扱いが容易になりました。このブログ記事では、linter を使って CloudFormation テンプレートを検証する方法について解説していきます。   linter とは、コードを精査して、そのコードを実行したときにエラーを発生させる可能性のある構文エラーやバグがないかを探すプログラムのことです。スタンドアロンのツールとして実行することも可能ですが、ビルド自動化やオーサリングなどのツールに組み込まれていることが多いです。 これまで CloudFormation による構文チェックは、サービス API の ValidateTemplate アクションに限られていました。このアクションを実行すると、テンプレートが正しい形式の JSON または YAML で書かれているかどうかがわかりますが、自分で定義した実際のリソースが検証されているわけではありません。数か月前、私はより良い選択肢がないか探しました。Stelligent の cfn_nag のようなツールは、テンプレートのリソースに追加の検証を実行できますが、これはセキュリティやベストプラクティスの観点から行われるものです。さらに探しているうちに、CloudFormation のサービスチームが、リソースやプロパティに有効な構文について説明したリソース仕様を公開していることを発見しました。 AWS CloudFormation linter の紹介 同じころ、Amazon の同僚である Kevin Dejong が、Python で自ら記述した CloudFormation linter のオープンソース化を準備していました。これは、私が求めていた必須項目のほとんどをクリアしていました。 組み込み関数の解析 (条件文を含む) 拡張可能なルールベースのアーキテクチャ 公開済みのリソース仕様に照らした検証 Python で記述されている (ええ、私は偏ってます) 私はこの linter の、とりわけ拡張性に強く引かれました。コミュニティのメンバーは、許容値や二者択一のリソースプロパティなど、リソース仕様の外部に存在する事柄について、新しい構文規則を追加することが可能になるからです。 当社は昨春、この linter を cfn-lint […]

Read More

AWS Service Catalog、AWS Organizations、AWS Lambda を使用して、アカウントの作成とリソースのプロビジョニングを自動化する

組織が AWS のサービスの使用を拡大するにつれて、ビジネスプロセスの分離またはセキュリティ、コンプライアンス、請求のために複数の AWS アカウントを作成する必要性についてしばしば語られます。私たちが仕事をしている多くのお客様は、各ビジネスユニットで別々の AWS アカウントを使用しているため、組織のさまざまなニーズに対応できます。複数のアカウントを作成すると、運用上の問題が簡素化され、セキュリティやリソースの分離、トラブルの影響の到達範囲の縮小、請求の簡素化などの利点が得られますが、ベースライン設定の作成、ブートストラップ、設定に時間がかかります。お客様は、アカウントの作成とブートストラップをスケーラブルかつ効率的な方法で管理して、定義済みのベースラインを使用して新しいアカウントを作成し、ガバナンスガードレールを配置したいと考えています。最も重要なことは、時間とリソースを節約するために、お客様が自動化を望んでいることです。このブログ記事では、一般的なガードレールを自動化し、デフォルトユーザーの作成、カスタムネットワークの設定、AWS のサービスのキュレーションセットを使用した製品の既存の AWS 環境へのプロビジョニングなどのタスクを設定することにより、アカウントの作成と設定を自動化する方法を紹介します。このブログは、前のブログ記事 AWS Organizations を使用してエンドツーエンドのアカウント作成を自動化する方法で説明した実装を拡張します。 このブログ記事で説明されている AWS のサービス: AWS Organizations は、複数の AWS アカウントのポリシーベースの管理を提供します。AWS Organizations を使用すると、アカウントのグループを作成し、アカウント作成を自動化し、それらのグループのポリシーを適用および管理できます。 AWS Service Catalog は、AWS での使用が承認されているサービスのカタログを作成および管理できます。 AWS CloudFormation は、クラウド環境のすべてのインフラストラクチャリソースを記述およびプロビジョニングするための共通言語を提供します。AWS CloudFormation を使用すると、シンプルなテキストファイルを使用して、すべてのリージョンとアカウントにわたってアプリケーションに必要なすべてのリソースを自動化された安全な方法でモデリングおよびプロビジョニングできます。 AWS Lambda を使用すると、サーバーのプロビジョニングや管理を必要とせずにコードの実行が可能になります。料金は消費したコンピューティングの時間分だけを支払います。コードが実行されていない場合は無料です。 このブログ記事で使用されている用語: ルートアカウント – アカウントビルダーが AWS Service Catalog 製品として起動される単一の AWS アカウント。新しく構築されるすべてのアカウントは、このアカウントで実行されている AWS Organizations のルートの下に作成されます。 ベースラインテンプレート – このテンプレートには、新しく作成されたアカウントの AWS Service Catalog ポートフォリオで AWS […]

Read More

AWS CDKでエンタープライズアプリケーションを開発する

エンタープライズのお客様は、ガバナンスやコンプライアンス・品質管理のために Infrastructure as Code (IaC)を標準化しなければならない場合があります。さらに、IaCのライブラリやそのアップデートを中央集権的に管理しなければならない場合もあるでしょう。それらを実現するため、この記事では AWS Cloud Development Kit (AWS CDK) を利用してIaCのパターンを定義する方法や、AWS CodeArtifactを利用してIaCの更新リリースを統制する方法を紹介します。

Read More

AWS Control Tower アクションの追跡、およびワークフローの自動トリガーへのライフサイクルイベントの使用

現在、新規アカウントの作成やプロビジョニングに、AWS Control Towerをご利用になっているお客様が多く見受けられます。こういったお客様は、環境の作成に、AWS のネイティブなソリューションの使用をご希望されます。それが明文化された AWS のベストプラクティスに則っていることをご存知だからです。お客様は、作成したアカウントのスケーリングを行う際に、アカウントをさらに強化できる Control Tower の追加的な機能を利用することもできます。今回の記事では、ライフサイクルイベントの使用方法をご紹介していきます。これは、Control Tower’s Account Factory を使用して新しいアカウントを作成するなどのアクションが完了したことを追跡できるようにする、Control Tower における機能の 1 つです。今回は、このライフサイクルイベントで、自動化したワークフローをトリガーする方法についても、合わせてご紹介します。この記事では、次のようなサービスを使用しています。 AWS Control Tower AWS Service Catalog AWS CloudTrail Amazon CloudWatch Events Amazon SNS 背景 AWS Control Tower では、Well-Architected なマルチアカウントの AWS 環境構築のために、AWS Organizations、AWS IAM、AWS Config、AWS CloudTrail、および AWS Service Catalog などの AWS のサービスを複数使用します。これにより、組織単位 (OU) の中のアカウントでガードレールを有効化するなどのアクションを Control Tower が実行する際には、多くのプロセスが実行され、各サービスに対しては膨大な数の API 呼び出しが送られることになります。 […]

Read More

分散型環境における AWS Service Catalog を使用したインフラストラクチャデリバリーの標準化

多くのエンタープライズのお客様では、共通のセキュリティに関するデザインパターンやベストプラクティスとして、マルチアカウント戦略の導入を通じたアプリケーションの分離を行っています。かなりのお客様が、開発 (Dev) 、品質保証 (QA) 、そして実稼働 (Prod) といった開発ライフサイクル (SDLC) の各フェーズに合わせ、環境全体で完全な分離を実現するために、個別の AWS アカウントを作成する手法を選択しています。しかしながら、アカウント作成時点でアプリケーションからの要件が完全に理解できていない場合、必要なインフラストラクチャコンポーネントをプロビジョニングすることが困難になり得ます。加えて、作成されたアカウントが増えるに従い、それらの異なるカウント間でのインフラストラクチャのコンプライアンスと一貫性を実現するための手法を模索しなければなりません。 AWS Service Catalog は、こういった課題に対処するため役立ちます。これにより開発者は、どのような環境においても、インフラストラクチャコンポーネントを、素早く、安全かつ簡単にデプロイできるようになります。次の図は、このワークフローを示しています。ここでは、アプリケーションにおける Dev/QA/Prod 用の各アカウントが、実稼働および非実稼働向けのインフラストラクチャコンポーネントを共有するために、AWS Service Catalog が使用されています。 お客様の多くに、AWS Service Catalog を使用するメリットは「一枚のガラス」を通すようにインフラストラクチャがプロビジョニングできることである、と捉えていただいていますが、実はこれには、製品のデプロイを自動化する機能も備わっています。前出の図にあるワークフローでは、アプリケーションのアカウントで共有している各製品は、それぞれの継続的統合/継続的デリバリー (CI/CD) パイプラインから、直接デプロイすることが可能です。これにより、コードおよびインフラストラクチャの依存関係と、各チームに分散した個別コンポーネントの所有権とを、開発者が固く結びつけることができる環境が提供されます。 このモデルからは、次のように 2 つの主要なメリットが得られます。 中心チームは、承認されたインフラストラクチャのバージョンを定義することで、コンプライアンスと標準化を実施できるようになります。 アプリケーション所有者が、使用すべきインフラストラクチャコンポーネントを自身で選択できる、セルフサービス型の環境が提供されます。 次の図で、このプロセスをさらに詳細に説明しています。ここでは、インフラストラクチャの定義は Shared Services チームにより処理されます。このチームにより、アプリケーションアカウントとの間で共有する、ネットワークやコンピューティングベースのリソースに関するカタログが作成されます。アプリケーションの所有者には、各要件に最も適合するコンポーネントを決定する役割があり、各所有者は複数のバージョンをが共有できます。これらの製品は、アプリケーションの CI/CD プロセスの一環として、AWS CodePipeline などの AWS のサービスを使用してデプロイされます。この、インフラストラクチャのデプロイ手法には、セキュリティ上のメリットもあります。アプリケーションパイプラインのアクセス権限は、基盤となっている AWS のサービスではなく、最小権限を保証しながら AWS Service Catalog ポートフォリオに対し適用されるからです。 AWS Service Catalog アカウントポートフォリオの共有を活用する CI/CD パイプラインの自動構築は、次の GitHub レポジトリから Amazon […]

Read More

会社標準の AWS Service Catalog 製品に対するマルチリージョン、マルチアカウントカタログを設定する方法

多くの AWS のお客様が、AWS での使用に承認されている IT サービスのカタログを作成して管理するために AWS Service Catalog を導入しています。AWS Service Catalog のハブアンドスポークモデルを使用すれば、組織は事業部門 (LOB) に配信する IT サービスを一元管理できます。私と一緒に作業しているお客様の何人かは、組織全体のクラウドエンジニアリングチームなど、一元化されたチームによって管理されるグローバルカタログをセットアップする方法についての推奨事項を求めています。組織には、Amazon EC2 インスタンスや Amazon RDS データベースを作成する標準的な方法など、一連の一般的かつ標準化された AWS Service Catalog 製品があり、それを複数の AWS リージョンの複数の AWS アカウントを使用し、複数の LOB に配信することを考えています。組織は、ハブアンドスポークモデルの各スポークアカウントにポートフォリオをセットアップする必要があることを理解しており、スポークの AWS アカウントにそれぞれログインする代わりに、単一のガラスペイン (ハブアカウントのダッシュボードなど) からポートフォリオを管理する方法を求めています。ハブアンドスポークポートフォリオを管理するための単一のガラスペインは、スポークアカウントとして設定された数十から数百の AWS アカウントを持つ大企業には必要なものになっています。 このブログ記事では、ハブアカウントを単一のガラスペインとして使用して AWS Service Catalog を設定し、複数の AWS アカウントや複数のリージョンのハブアンドスポークポートフォリオを管理する方法について説明します。このアプローチにより、ハブアンドスポーク製品向けのハブアンドスポークモデルのポートフォリオ、製品、ポートフォリオのアクセス許可、その他の運用面を一元的に作成して管理できます。 どのような機能かを説明する前に、まずは AWS Service Catalog の主要な概念をいくつか確認しましょう。 AWS Service Catalog 製品は、構成情報と一緒に AWS […]

Read More

AWS CDKでクラウドアプリケーションを開発するためのベストプラクティス

この記事では、AWS Cloud Development Kit (AWS CDK) を中心とした、大規模なチームで複雑なクラウドアプリケーションの開発を組織化するための戦略について説明します。AWS CDK では、開発者や管理者は、TypeScript、Python、Java、C#などの使い慣れたプログラミング言語を使ってクラウドアプリケーションを定義することができます。アプリケーションは、Stage、Stack、Constructに整理されており、ランタイムロジック (AWS Lambda コードやコンテナ化されたサービスなど) と、Amazon Simple Storage Service (Amazon S3) バケット、Amazon Relational Database Service (Amazon RDS) データベース、ネットワークなどのインフラストラクチャコンポーネントの両方において、モジュール化された設計手法を可能にしています。 この記事では、AWS CDKの基本的なコンセプトに関する簡単なチュートリアルではなく、より実践的な内容について説明します。ローカルでコードを書きテストする方法や、本番環境や様々なステージングアカウントにデプロイする方法、そしてチームのアプリを整理して、より大きな組織で活用する方法について説明します。 AWS CDKを初めてご利用になる方は、AWS CDK Intro Workshop から始めることを強くお勧めします。この記事では、いくつかの高度なトピックを扱っていますが、基礎を把握しておくと良いでしょう。詳細については、AWS CDKリファレンスドキュメントとGitHub リポジトリにある aws-cdk-examples  のサンプルコードを参照してください。

Read More

CloudKnox と AWS Control Tower を使用して AWS でのマルチアカウントのアクセス許可管理を自動化

この記事は、AWS の ISV ソリューションアーキテクチャリーダーであるKanishk Mahajan、CloudKnox の カスタマーサクセス責任者であるゲスト寄稿者 Maya Neelakandhan 氏によるAutomate multi account permissions management in AWS using CloudKnox and AWS Control Towerを翻訳したものです。 はじめに AWS のアクセス許可管理により、セキュリティチームとクラウドインフラストラクチャチームは、ID アクセス許可の誤用からクラウドリソースを保護できます。クラウドセキュリティでは、AWS 組織内のすべての AWS アカウントで、最小権限ポリシーを継続的に適用する必要があります。 マルチアカウント戦略を持つことは、リソースの分離を強化するためのベストプラクティスです。また、規制やコンプライアンスのニーズを満たし、オペレーションコストを追跡し、セキュリティをさらに強化するのにも役立ちます。AWS Control Tower は、AWS のベストプラクティスを使用して、Well-Architected マルチアカウントのベースラインを確立します。また、AWS アカウント全体でのガバナンスも有効にします。多くのお客様は、AWS Control Tower を使用してマルチアカウントの AWS 環境を管理および統制しています。AWS Control Tower を使用したマルチアカウント AWS 環境の管理の詳細については、「AWS Control Tower の使用開始」を参照してください。 CloudKnox は APN アドバンストパートナーです。<a

Read More

re:Invent 2020におけるマネジメントとガバナンス関連セッションのご紹介

AWS re:Inventは、お客様と関わり合い、サービスや機能に関して学び、共有できる、エキサイティングな時期です。現在のパンデミックにより、今年のre:Inventは11月30日から12月18日までの 3 週間にわたって完全オンライン、無料で開催されます。そうです、あなたには参加する権利があるのです。 AWS re:Invent 2020はバーチャルで開催され無料です!!! このブログでは、AWSでのマネジメントとガバナンスに関するセッションのハイライトを紹介します。これらは、ビジネスの俊敏性とガバナンスコントロールの両者を維持しながら、AWS環境を有効化し、プロビジョニングし、そして運用するために、役立つセッションです。各セッションは、世界各地のお客様に向け複数回ブロードキャストされ、すべてあなたの家で快適な環境でご視聴いただけます。これらのセッションのメリットを享受するため、re:Inventに登録してください。

Read More