Amazon Web Services ブログ

Category: Learning Levels

Amazon SageMaker ノートブックと AWS Service Catalog を使用して、セルフサービスで安全なデータサイエンスを実現する

Sanjay Garje と Vebhhav (Veb) Singh の共著あらゆる規模の企業が AWS クラウドに移行しています。エンタープライズチームのリーダーシップから、コストを抑えながら Amazon SageMaker に簡単にアクセスできる方法を模索しているという話を耳にします。これにより、データサイエンスを使った実験を促進し、新しいビジネスチャンスを開拓して現状を打破しています。このブログ記事では、Amazon SageMaker、AWS Service Catalog、および AWS Key Management Service (KMS) を使用してセルフサービスの安全なデータサイエンスを簡単に使えるようにする方法を紹介します。このブログ記事では、AWS Service Catalog が事前設定された AWS KMS キーを使用して、複雑で不要な詳細をデータサイエンティストに公開することなく、ノートブックインスタンスにアタッチされている機械学習 (ML) ストレージボリュームで保存されているデータを暗号化する方法を説明します。ML ストレージボリュームの暗号化は、一元化されたセキュリティチームやインフラストラクチャチームが事前設定および調整した AWS Service Catalog 製品で行われます。Amazon SageMaker ノートブックインスタンス、トレーニングジョブ、またはエンドポイントを作成するときに、AWS KMS キー ID を指定できます。そのキーが、アタッチされた ML ストレージボリュームを暗号化します。トレーニングジョブ用の出力 Amazon S3 バケットを指定できます。トレーニングジョブも、AWS KMS で管理されるキーで暗号化されます。モデルのアーティファクトをその出力 Amazon S3 バケットに格納するための KMS キー ID を渡すことができます。 AWS […]

Read More

AWS Service Catalog とAWS Marketplace の CloudEndure を使用して、AWS アカウントのプロビジョニングとサーバーの移行を自動化する

AWS クラウドに移行する予定の会社の移行プロジェクトに関与している場合は、移行の準備、ポートフォリオの発見、計画、設計など、さまざまな段階を経ることでしょう。ほとんどの場合、これらの段階の後に正念場を迎え、物理ベース、仮想ベース、またはクラウドベースのインフラストラクチャワークロードの AWS への移行を開始します。AWS のお客様は、CloudEndure (現在は AWS の会社) などのツールを使用して、アプリケーションの移行、災害復旧や AWS へのレガシーインフラストラクチャのバックアップを自動化します。移行中にお客様が直面する課題の 1 つに、サーバーを管理して、数百または数千の AWS アカウントで構成される階層的なアカウント構造に移動することがあります。このブログ記事では、新しい CloudEndure 移行プロジェクトのセットアップを自動化する方法と、お使いの環境で新しいアカウントを販売するたびに「アカウント自動販売機」を使用してこのプロセスを自動化する方法を学びます。 はじめに CloudEndure は、AWS への大規模な移行と障害復旧のデプロイを簡素化、迅速化、自動化するのに役立ちます。継続的なデータレプリケーションはバックグラウンドで行われ、アプリケーションの中断やパフォーマンスへの影響はありません。これにより、データがリアルタイムで同期され、カットオーバー/フェイルオーバーウィンドウが最小限に抑えられます。カットオーバー/フェイルオーバーが開始されると、CloudEndure は高度に自動化されたマシン変換とオーケストレーションプロセスを実行します。これにより、最も複雑なアプリケーションやデータベースでも、互換性の問題なく、最小限の IT スキルで AWS でネイティブに実行できます。AWS Marketplace から CloudEndure をデプロイできます。 このアカウントの自動販売機を作成するには、AWS Service Catalog、AWS Lambda、AWS Organizations などのネイティブの AWS のサービスを追加で使用します。また、CloudEndure との API 統合を使用して、アカウントの作成後に新しいプロジェクトをセットアップします。さらに、移行をサポートするために、販売したアカウントで AWS Direct Connect、Amazon Kinesis Data Firehose、Amazon S3 Transfer Acceleration などの追加の AWS のサービスを設定して、この参考用のサンプルソリューションを拡張できます。 このソリューションのサービス このソリューションで使用するサービスの簡単なレビューを次に示します。 […]

Read More

AWS Control Tower で AWS リソースのセルフサービスプロビジョニングを有効にする

お客様は、新しいビジネスユニットのオンボーディングやアプリケーションワークロードのセットアップを行うたびに、AWS Control Tower で新しいアカウントをプロビジョニングしています。場合によっては、組織はクラウドユーザー、開発者、およびデータサイエンティストに、新しいアカウントでセルフサービス標準化された安全なパターンとアーキテクチャをデプロイすることも求めます。以下にいくつか例を示します。 開発者またはクラウドエンジニアが、golden AMI から Amazon EC2 インスタンスを起動したいと考えています。 データサイエンティストは、承認済みの AMI とインスタンスタイプで Amazon EMR クラスターを起動したいと考えています。 データベース管理者は、新しくプロビジョニングされた AWS アカウントで承認済みの Amazon RDS データベースを起動する必要があります。 この記事では、AWS Control Tower の Account Factory を使用して新しい AWS アカウントをプロビジョニングする方法を示します。また、AWS Service Catalog を使用して、RDS データベースのポートフォリオなどのカスタム製品を新しいアカウントと共有する方法も示します。さらに、AWS Control Tower のガードレールを使用して新しいアカウントでガバナンスを実施する方法についても説明します。 このソリューションで使われる AWS のサービスは、以下のとおりです。 AWS Control Tower AWS Service Catalog AWS CloudFormation Amazon CloudWatch Amazon RDS AWS Organizations […]

Read More

VMware Cloud on AWSにおけるストレージオプションと設計

VMware Cloud on AWSはVMwareのSoftware-Defined Data Center (SDDC)技術をAWSのグローバルインフラストラクチャ上で提供するためVMwareとAWSが共同開発したソリューションです。 様々なストレージ要件のワークロードが存在する場合、利用可能なストレージオプションの種類を把握し、異なる条件下でそれらをどう使っていくことが最適であるかを理解することが重要です。 VMware Cloud on AWSは複数のストレージサービスと統合されており、VMware vSphereワークロードに対して選択肢と柔軟性を提供しています。しかしながら各サービスは特定のシナリオに最適化されており、ワークロード全体に対して最適な単一のアプローチというものはありません。正しいサービスを選択するには、まずVMware vSphereワークロードのストレージ要件やパフォーマンスの統計データを理解しなければいけません。それを踏まえた上で、お客様のワークロードに適したコスト、可用性、パフォーマンス要件を満たすストレージを計画、実装することができます。

Read More

AWS Systems Managerフリートマネージャーを活用してWindowsワークロードの問題をトラブルシューティングする

クラウドの運用担当エンジニアは、利用料金を予算内に抑えつつ、多数のEC2インスタンスの状態を健全に保つために問題の監視・追跡・解決の可能な仕組みを構築しなければならないという、コストとシステム安定性の両方面で責任を持つことになります。このブログでは、AWS Systems Managerの新機能であるフリートマネージャーと共にOpsCenterとAmazon CloudWatchを活用し、大規模環境で発生する運用上の問題をすばやく検知・追跡・解決する方法をご紹介します。

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 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 の使用開始」を参照してください。

Read More

新たに SaaS Journey Framework ホワイトペーパーを公開しました

AWS で SaaS Business Lead を務める Oded Rosenmann による記事です。 SaaS(Software as a Service)提供モデルは、多くの企業にとってますます魅力的になっています。 新規および既存のアプリケーション・プロバイダが、この提供モデルで成功を収めたいと望んでいる一方で、SaaS への移行はビジネスに大きな影響を与える可能性もあります。 多くの企業にとって、SaaS への移行は大きな変化をもたらす出来事であり、企業は自社のビジネスをあらゆる側面から検討する必要があります。サービスとしてのビジネスを定義、構築および運用するためには、製品の販売、マーケティング、開発、サポート、収益化の方法など、評価しなければいけない検討事項がたくさんあります。

Read More