Amazon Web Services ブログ

AWS Localization

Author: AWS Localization

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 Config ベストプラクティス

AWS Config は、AWS リソースの設定履歴を維持し、ベストプラクティスと内部ポリシーに対して設定を評価するサービスです。この情報は、運用上のトラブルシューティング、監査、コンプライアンスのユースケースに使用できます。このブログ記事では、企業全体のガバナンスを可能にするツールとして AWS Config を使用する方法のベストプラクティスを紹介します。 1.すべてのアカウントとリージョンで AWS Config を有効にします。 これは、Center for Internet Security (CIS) が推奨する業界のベストプラクティスです。AWS Config を使用すると、AWS リソースの設定を監査し、設定のベストプラクティスに確実に準拠することができます。AWS CloudFormation StackSets を使用すると、共通の CloudFormation テンプレートを使用して、複数のアカウントとリージョンで AWS Config を有効にできます。 2.すべてのリソースタイプの設定変更を記録します。 AWS Config をセットアップするときは、AWS Config に記録する必要があるリソースタイプとして [すべてのリソース] を選択します。AWS Config は AWS で 60 を超えるさまざまなリソースタイプをサポートしているため、これにより包括的な設定監査が実施されます。新しいリソースタイプは、この設定を介して自動的に記録されます。3.1 つのリージョンでのみグローバルリソース (IAM リソースなど) を記録します。 これにより、IAM 設定アイテムの冗長コピーをすべてのリージョンで取得することがなくなります。それは費用の節約にもなります。 4.設定履歴とスナップショットファイルを収集する安全な Amazon S3 バケットがあることを確認してください。 Amazon S3 バケットは、AWS […]

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 を使用しての、Amazon ECS 継続的デリバリー用の自動設計図の共有

この記事は、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 […]

Read More

AWS Systems Manager Automation を使用して複数のアカウントとリージョンにある AWS リソースを管理する

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 […]

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

クラウドによる FRTB コンプライアンス向けトレーディング勘定リスク管理におけるインフラストラクチャの柔軟性高度化

バーゼル規制フレームワークは、規制裁定取引を防止するために、金融機関のトレーディング勘定とバンキング勘定の厳密な区分けを目指しています。これらの規制のトレーディング勘定要素 の見直し(FRTB:トレーディング勘定に関する抜本的見直し) は、厳格なリスクモデリングを適用することと引き換えに、金融機関が資本準備金のレベルを最適化できるようにすることでトレーディングのリスク管理を強化することを目指しています。FRTB は、資本準備要件を最小限に抑える内部モデルアプローチ (IMA)、または実装が容易な標準化アプローチ (SA) といった、十分に規定されたメカニズムの 1 つを適用することでリスク管理を追求することを金融機関に求めています。バーゼル III モニタリング報告書 (2019 年 10 月) によれば、欧州の大手銀行では、全体的な必要最小資本 (MRC) が 18.6% まで上がる可能性があることを示しており、個々の銀行への影響は、SA と IMA のどちらを使用してリスク資本要件を計算するかによって左右されます。限定的な影響度調査では、SA よりも IMA を導入する方が、資本効率を最大 10% 最適化できると結論付けています。しかし、期待に反して、市場分析では IMA の採用が減少していることを示されています。SA と比較して、IMA の実装はかなり複雑で費用がかかると認識されているため、いくつかの銀行は、IMA の計算適用について十分に調査しそのメリットを定量化しています。すべての銀行が SA を採用した場合は、システムリスクの可能性があるため、規制当局は、グローバルなシステム上重要な銀行 (G-SIB) がグローバルかつ体系的に IMA を実施することを求めています。この記事では、IMA と SA のどちらを実装するかに関係なく、リスクマネージャーとトレーディングデスクの責任者が、これらの課題に対処するためにこれまでのレガシーな IT システムを超える手段を検討しなければならない理由について説明します。

Read More

自分で事前にトレーニングした MXNet または TensorFlow のモデルを Amazon SageMaker に導入する

Amazon SageMaker は、ML モデルをトレーニングおよびホストするための容易なスケーラビリティとディストリビューションを提供するだけでなく、モデルをトレーニングするプロセスとモデルのデプロイメントを分離するようにモジュール化されています。これは、Amazon SageMaker 以外でトレーニングされたモデルを SageMaker に導入してデプロイできることを意味します。すでにトレーニングを受けたモデルがあり、パイプライン全体ではなく SageMaker のホスティング部分だけを使用したい場合は、これは非常に便利です。また、これは自分のモデルをトレーニングしないが、事前にトレーニングされたモデルを購入する場合にも便利です。 このブログ記事では、TensorFlow または MXNet でトレーニングした自分のモデルを Amazon SageMaker にデプロイする方法について説明します。以下は、プロセス全体の概要です。 ステップ 1: モデル定義を、選択したフレームワークで記述します。 ステップ 2: モデルを、そのフレームワークでトレーニングします。 ステップ 3: モデルをエクスポートし、Amazon SageMaker が理解できるモデル成果物を作成します。 ステップ 4: モデル成果物を Amazon S3 バケットにアップロードします。 ステップ 5: モデル定義、モデル成果物、Amazon SageMaker Python SDK を使用して、SageMaker モデルを作成します。 ステップ 6: SageMaker モデルをエンドポイントとしてデプロイします。 モデルとは何か?、そしてどうすれば手に入るのか? トレーニングされたモデルファイルとは、単にトレーニングプロセスによって作成されたモデル成果物です。これには、モデルのすべてのパラメータの値と、モデルのアーキテクチャに関する追加のメタデータが含まれていて、これらのパラメータが互いにどのように接続されているかを示します。フレームワークが異なると、モデルファイルをエクスポートする方法も異なります。 TensorFlow TensorFlow のモデルは、トレーニングされた TensorFlow Estimator からエクスポートできます。モデルファイルは、Amazon SageMaker がそれを理解できるようにするためのプロトコルに従わなければなりません。 単純な TensorFlow Estimator […]

Read More

Thorn が児童性的虐待、児童売買との闘いで Amazon Rekognition と連携

Thorn は、児童性的虐待資料の拡散を阻止し、児童人身売買業者に立ち向かうことに尽力している非営利団体です。Thorn のツールは、2017 年には性的搾取を目的とした児童人身売買の被害者 5,894 人を割り出し、性的虐待の録画が拡散された 103 人の子どもたちを救出しました。Thorn は Amazon Rekognition のような AWS 製品を使用して、調査時間を 65% 削減しました。これで、もっと速く、もっと多くの犠牲者を探すことが可能になります。 「Amazon Rekognition は Thorn のすばらしいパートナーです。子どもたちを性的虐待から守るという私たちのミッションにおいて画像および動画分析を活用できるのは Amazon Rekognition のおかげです」と Thorn の CEO、Julie Cordua 氏は言います。「加害者たちは最先端の技術を悪用し、子どもたちを食い物にしています。性的な目的で子どもたちをオンラインで売り、虐待の画像と動画を流通させ、虐待をライブストリーミングで配信しているのです。AWS は、この問題解決の一翼を担うことを決めました。パートナーとなってその製品を活用することで、食い物にされている子どもたちの早期発見と虐待撲滅に協力しています。AWS のように先端技術を持つ企業とのコラボレーションは、そうした子どもたちをいち早く見つけ、児童性的虐待資料の拡散に終止符を打つために必要なツールを作り上げるうえで非常に重要です」 性的搾取を目的とした児童売買に関する数千におよぶ広告を調査員がより効率的に、より早く鑑別できるように、Thorn は Amazon Rekognition を使用して Spotlight ツールを強化しています。インターネットに掲載されるこの種の広告は毎日およそ 150,000 にのぼるため、このツールの存在は児童売買との闘いにおいては欠かせません。 そうした広告から検出された情報は Spotlight に送られ、立件、被害者の身元特定、そして最終的にはその子どもの奪還に必要な情報を調査員に提供します。 「いくつかの重要な機能で Amazon Rekognition に依存している Spotlight は、決定的なツールと言えます。これにより、児童売買との闘いに尽力している人たちは、虐待や売買の膨大な資料を鑑別できるようになりました」と、Cordua は述べます。「とにかく、被害者の子どもが最優先です。調査時間が 65% 削減されたことで、さらに多くの被害者をさらに早く発見していきます」 Amazon Rekognition の詳細: […]

Read More