Category: Management Tools

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

現在、新規アカウントの作成やプロビジョニングに、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 呼び出しが送られることになります。 […]

多くのエンタープライズのお客様では、共通のセキュリティに関するデザインパターンやベストプラクティスとして、マルチアカウント戦略の導入を通じたアプリケーションの分離を行っています。かなりのお客様が、開発 (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 […]

この記事は、AWS Dev Tech のスペシャリスト SA である Mahmoud ElZayet が執筆しました  現代的なアプリケーション開発プロセスは、各組織がスピードや品質を継続的に向上することを可能にしています。このような革新的なカルチャーにおいては、小型の自律的なチームに、アプリケーションの全ライフサイクルがゆだねられます。ただ、こういった敏速かつ自律的なチームは、製品デリバリーを加速する一方で、コンプライアンスや品質保証、およびコードデプロイのためのインフラストラクチャに対するコストを生じさせます。 標準化したツールやアプリケーションリリース用コードを用いることで、チーム間でベストプラクティスを共有でき、冗長的なコードを削減し、オンボーディングを加速し、一貫性のあるガバナンスを作り上げながらリソースのオーバープロビジョニングを減らせます。   概要 今回の記事では、標準化され自動化されたデプロイ設計図を、AWS Service Catalog を使用して提供する方法をご紹介していきます。これは、製品チームによる Amazon ECS でのアプリケーションリリースワークフローの改善と迅速化に役立ちます。ここでの手順を実施していただくと、お客様の製品チームが ECS 上でコンテナ化されたアプリケーションをリリースするために使用できる、サンプル設計図が作成できます。この設計図のコンセプトは、サーバーレスや Amazon EC2 をベースとするデプロイなど、他のテクノロジーにも適用が可能です。 本稿で提供するサンプルテンプレートやスクリプトはデモ用に用意したものなので、実稼働環境でそのまま使用するには適しません。これらのリソースになじんだ後で、手元にあるツールや、チームのスキル、そして適用すべき規格や規制をすべて考慮しながら、実稼働環境向けにカスタマイズしたバージョンを作成してください。   前提条件 ここでのソリューションには、次に挙げる各リソースが必要です。 AWS アカウント での管理者アクセス権限 AWS CLI   サンプルシナリオ Example Corp という企業では、アプリケーションやサービスを AWS 上で開発するために、いくつかの製品チームを抱えています。同社内の各チームは、ECS 上の AWS Fargate で管理するコンテナ化したアプリケーションのデプロイに関心を示しています。ここでは、Example Corp. における主幹ツール管理チームとして、各チームが Fargate で迅速にアプリケーションをリリースできることを目指します。さらに、すべてのベストプラクティスやガバナンス要件を、各チームが準拠することも保証していきます。 事情を単純にするために、製品チームはすでに構成済みであり、サービスのデプロイ用に AWS のアカウントを共有しながら、同じドメイン、アプリケーション、もしくはプロジェクトで作業をしていると想定します。この 1 つのアカウントを通じ、チーム全体が同じ ECS […]

AWS Systems Manager Automation で AWS リソースの一般的な管理およびメンテナンスタスクが容易になります。Systems Manager Automation を使用すると、ご自分で記述したりコミュニティで公開されたドキュメントを使用したりできる AWS Systems Manager ドキュメント（SSM ドキュメント）の形式で前もって定義済みのタスクやワークフローを実行できます。SSM ドキュメントは、Systems Manager が AWS リソースに対して実行するアクションを定義しますこれらのドキュメントは Systems Manager メンテナンスウィンドウを使ってスケジューリングが可能です。さらに、Amazon CloudWatch Events を使用して、AWS リソースへの変更に基づいてドキュメントをトリガーしたり、AWS マネジメントコンソール、AWS CLI、または AWS SDK を通して直接実行したりできます。ドキュメントの各ステップでの実行を追跡したり、ステップの承認を要求したりできます。また、変更を段階的にロールアウトして、エラーが発生した際に自動停止することもできます。 AWS のお客様の多くは複数の AWS アカウントを使用しています。たいていは、AWS Organizations を使用してアカウントを階層に配置し、それらを組織単位（OU）にグループ化しています。OU は、一括請求 (コンソリデーティッドビリング)、ワークロードの分離、管理の分離など、さまざまな目的に使用できます。お客様は、アプリケーションごとに開発、テスト、ステージング、および本番用に個別のアカウントを組織内で作成することがよくあります。 すべてのアカウントに共通する反復的なタスクがあっても、前述のマルチアカウント構造ではそれらを個別に管理することは困難な場合があります。お客様から、次のような一般的なタスクを 1 つの中央/管理アカウントから実行したいとの要望がありました。 パッチ管理 ゴールデン Amazon マシンイメージ (AMI) の作成 SSM エージェントを使用したソフトウェアエージェントの更新 Amazon EC2 インスタンスの開始/停止/再起動 Amazon […]

多くの 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 […]

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、シニアエバンジェリストの亀田です。 AWS Control Tower が東京リージョンで利用可能となりましたのでお知らせいたします。 AWS Control Tower Control Tower はセキュアなマルチアカウント AWS 環境をセットアップおよび管理するために利用できるサービスです。複数の AWS アカウントやチームがある場合、クラウドのセットアップと管理はそれぞれのコンプライアンスポリシーなどに照らし合わせて設定を行う必要があり、複雑で時間のかかる作業になってしまうケースが多くあります。Control Tower では、新しくセキュアなマルチアカウントの AWS 環境を、セットアップし管理するための最も簡単な方法が提供され、AWS が何千ものエンタープライズのクラウド移行業務を通して確立した、ベストプラクティスに基づいて開発されています。 Control Tower を用いて一度ガバナンスとベストプラクティスを設定した後は、追加の AWS アカウントは、数クリックだけでプロビジョニングすることができるようになります。

この記事では、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  のサンプルコードを参照してください。

この記事は Integrating Okta with AWS Single Sign-On in an AWS Control Tower environment を翻訳したものです。 AWS Control Tower は、AWS Single Sign-On (AWS SSO) とのすぐに使用できるネイティブ統合を提供し、ユーザー、ロール、マルチアカウントアクセスを管理します。お客様の組織によっては、外部アイデンティティプロバイダーとの統合による認証と承認の処理など、より複雑な SSO 要件があります。Okta は、クラウド向けに構築されたエンタープライズグレードの ID 管理サービスですが、多くのオンプレミスアプリケーションと互換性があります。AWS Marketplace で Okta を見つけて登録することができます。このブログ投稿では、Okta でユーザー、エンタイトルメント、アカウント、ロールを管理できるように、AWS Control Tower、AWS SSO、Okta を外部 ID プロバイダーとして統合する方法を説明します。

2009 年に Amazon CloudWatch の立ち上げを行った際（Elastic Load Balancing、Auto Scaling、および Amazon CloudWatch の Amazon EC2 の新機能をリリース）、EC2 インスタンスのパフォーマンスメトリクス（CPU 負荷、ディスク I/O、ネットワーク I/O）を追跡し、それらを 1 分間隔でロールアップし、2週間にわたり保存しました。当時、パフォーマンスメトリクスは、インスタンスの状態をモニタリングし、 Auto Scaling をドライブするために使用されました。現在の CloudWatch は、はるかに総合的で洗練されたサービスになっています。最新の追加機能には、 すべての EBS ボリュームタイプに対して 1 分単位のメトリクス 、CloudWatch Lambda Insights、Metrics Explorer などが含まれます 。 AWS パートナーが CloudWatch メトリクスを使用して、あらゆる種類のモニタリング、アラート、コスト管理のためのツールを作成しました。パートナーはメトリクスにアクセスするために、それぞれの顧客の ListMetrics 関数と GetMetricData 関数の呼び出したポーリングフリートを作成しました。 これらのフリートは、各パートナーの顧客が作成した AWS リソースの数と、リソースごとに取得される CloudWatch メトリクスの数に比例して拡張が必要です。このポーリングは、各パートナーで行う必要のある単に差別化されていない手間のかかる作業です。この作業は、付加価値がなく、もし他のことに充てればより良い投資ができる貴重な時間を奪っています。 新しい Metric Streams AWS パートナーや他のユーザーが CloudWatch […]