Category: Advanced (300)

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

多くのエンタープライズのお客様では、共通のセキュリティに関するデザインパターンやベストプラクティスとして、マルチアカウント戦略の導入を通じたアプリケーションの分離を行っています。かなりのお客様が、開発 (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 Key Management Service (AWS KMS) が AWS KMS API エンドポイントに接続する際に使われる Transport Layer Security (TLS) 1.2 暗号化プロトコルにおいて新しいハイブリッド型のポスト量子暗号（耐量子暗号）鍵交換アルゴリズムをサポートするようになりました。これらの新しいハイブリッドポスト量子アルゴリズムは、古典的な鍵交換による実証済みのセキュリティと、標準化作業で評価中の新しいポスト量子鍵交換の潜在的な耐量子安全特性を組み合わせたものです。これらのアルゴリズムの中で最も高速なものは、古典的な TLS ハンドシェイクと比較して約 0.3 ミリ秒のオーバーヘッドがあります。追加された新しいポスト量子暗号鍵交換アルゴリズムは、Kyber のラウンド 2 バージョン、Bit Flipping Key Encapsulation（BIKE）、および Supersingular Isogeny Key Encapsulation（SIKE）です。標準化に参加している各組織は、米国国立標準技術研究所（NIST） のポスト量子暗号の標準化プロセスの一環として、アルゴリズムを NIST に提出しています。このプロセスは、複数年にわたる数ラウンドの評価にまたがり、2021 年以降も続く可能性があります。 以前のハイブリッド量子暗号 TLS に関するブログ投稿で、AWS KMS がラウンド 1 バージョンの BIKE と SIKE を備えたハイブリッドポスト量子暗号 TLS 1.2 をリリースしたことを発表しました。ラウンド 1 のポスト量子暗号 アルゴリズムは引き続き AWS KMS でサポートされていますが、ラウンド […]

多くのゲームでデータベースが不可欠の部分であることは周知の事実です。けれども、ゲーム開発者としては、データベースのエンジニアリングではなく、優れたゲームの構築にすべての時間と専門知識を捧げたいでしょう。 わかります。私も、データストレージについて考えるのではなく、コリジョンボリュームの修正、フレームレートの引き上げ、あるいは完璧な制御システムの作成に気をかけたいです。では、それを簡単に行いましょう。この記事では、AWS の高速で柔軟な NoSQL サービスである Amazon DynamoDB を使用して、ゲームにデータベースを追加するのがいかに簡単であるかを示します。 DynamoDB は、キーをデータに関連付ける非リレーショナルデータベースです。データベース、特にゲームでの使用に詳しくない場合は、ゲームでのデータベースの基本的な使用法と、リレーショナルデータベースと非リレーショナルデータベース (ときに SQL と NoSQL と呼ばれる) の違いについて説明したこの記事「素晴らしいゲームのためのマネージドデータベース」をご覧ください。 Dynamo DB テーブルの作成 DynamoDB は、NoSQL データベースですが、SQL データベースから借用した用語テーブルを使用します。この場合のテーブルは、実際にはデータベースに格納されるアイテムの主要な機能を定義したものにすぎません。 DynamoDB には、テーブルを識別するためのテーブルのプライマリキーが常にあり、このキーはデータベースに保存されているすべてのアイテムに対して一意である必要があります。 便利なヒントは、プライマリキーが複数の値のハッシュになる可能性があることです。したがって、単一の一意の属性がない場合は、異なる属性を組み合わせて一意の値を作成できます。たとえば、名前とバージョン番号を持つアイテムです。「broadsword」という名前のアイテムは 10 個あり、「version 1」のアイテムは 100 個ありますが、「broadsword version 1」は 1 個しかありません。 DynamoDB には、オプションで、アイテムをすばやく並べ替えることができるソートキーもあります。たとえば、プレイヤーのソートキーはプレイヤークラスであるかもしれません。これにより、ゲーム内のすべてのファイタークラスのリストを取得するクエリが高速化されることでしょう。データベース内のアイテムを一意に識別するための代替方法でするセカンダリキーを持つこともできます。 このデモでは、プレイヤーキャラクターの属性を表す非常にシンプルなオブジェクトを作成します。オブジェクトには一意のプレイヤー ID、プレイヤーレベル、強さと知力の 2 つの統計が含まれます。プレイヤー ID がプライマリキーになり、このデモ用のソートキーやセカンダリキーはありません。 注意: 自分で練習したい場合は、ソートキーとして機能するプレイヤークラスを追加できます。 DynamoDB テーブルを作成する手順は次のとおりです。 AWS コンソールを開きます。 DynamoDB を検索して選択します。 DyanamoDB コンソールのホームページから [テーブルの作成] を選択します。 […]

AWS Systems Managerを使うと、マネージドインスタンスへのパッケージデプロイの順序を制御できます。マネージドインスタンスとして管理できるものには、Amazon Elastic Compute Cloud（Amazon EC2）インスタンス、他のクラウド環境で稼働するVMを含む仮想マシン（VM）、そしてオンプレミスサーバーがあります。ハイブリッドインフラストラクチャの構成管理手順を自動化したいお客様もいらっしゃるでしょう。そのためには、特定のマネージドインスタンス上で特定のパッケージを順序立てた方法で実行し、インストール順序においてそれぞれのパッケージが干渉し合わないようにする必要があります。現在、Systems Manager Distributorパッケージを使用することで、マネージドインスタンスにソフトウェアパッケージを公開できます。ただし、それらが1回限りのインストール用に構成されている場合、パッケージの実行はマネージドインスタンスで同時に発生する可能性があります。

運用部門の管理者は、エージェントのアップデートやパッチ適用状況のチェックのような一般的な設定を組織全体に適用したいとお考えではないでしょうか。2020/07/28にAWS Systems Manager Quick SetupはAWS Organizationsをサポートしました。この機能によって、Systems Managerの設定を簡単に、組織のアカウント全体に定義できるようになりました。この操作はOrganizationマスターアカウントから行います。Quick Setupは、Organization全体または、特定のAWS Organization Units(OU)を選択して適用することが出来ます。このブログ記事では、組織内のマルチアカウントに対して、Systems Manager Quick Setupの設定オプション(Configuration options)を展開するベストプラクティスをご紹介します。

このブログ投稿では、フェデレーションユーザーに対して、AWS Systems Manager Session Managerへのアクセス権限を属性ベースのアクセスコントロール（ABAC=Attribute Based Access Control）にて設定する方法を示します。SAMLセッションタグを使用することで、外部IDシステムで定義された属性をAWS内のABACの判定の一部として使用できます。たとえば、AWS Identity and Access Management（IAM）ユーザーが所属する部門に基づいて、特定のマネージドインスタンスへのアクセスを許可することができます。フェデレーションユーザーが使用できる属性の詳細については、「新しい ID フェデレーション – AWS でアクセスコントロールに従業員属性を使用する」を参照してください。

世界中の企業でクラウドコンピューティングの導入が急速に増加しており、クラウドジャーニー（クラウド活用を進める過程）の中で、さまざまな移行パターンが選ばれています。モノリシックなレガシーアプリケーションをそのまま使用してクラウドに移行することは「リフト・アンド・シフト」とも呼ばれるアプローチであり、クラウド移行の有力な手法の1つです。一方で、お客様が移行パターンについての知識を深めるにつれ、クラウドネイティブツールを最大限に活用できるようにリフト・アンド・シフト方式を最適化する必要があります。

昨年、AWS AppConfigをリリースしました。これはアプリケーション設定の作成、管理及び迅速なデプロイを行う、AWS Systems Managerの新機能です。AppConfigを使用すると、デプロイメントを行う前にアプリケーション設定を検証でき、制御及び監視可能な方法で設定をデプロイできます。 AWS AppConfigを使用すると、アプリケーションコードのデプロイメントとは独立して、設定の変更をデプロイ可能です。つまり、アプリケーション設定を更新しても、アプリケーションの再起動やサービスの停止を行う必要がありません。AWS AppConfigを使用すれば、アプリケーションは更新した設定をすぐに使用できます。具体的には、AWS AppConfig API、AWS CLIやAWS SDKを使用することで、更新した設定を取得することができます。 ローンチ以来、お客様はさまざまなユースケースにAWS AppConfigを採用しており、なかでもコードのデプロイメントとは独立して新機能をリリースする機能がトップユースケースの1つでした。アプリケーション設定のデプロイメントはコードのデプロイメントより高速です。なぜならコンフィグレーションファイルは、ビルドステージを必要とせず、アプリケーションを停止すること無く実行中にデプロイすることができるためです。 機能リリースにあたって、バックエンドサービスの設定とフロントエンドの設定を正しい順序で行う必要があります。そのためには、しばしば複数のチームや手作業を調停する必要があります。こういった手作業によるデプロイメントは、カスタマーエクスペリエンスに影響を与える作業遅延を引き起こす可能性があります。 複数の環境、アプリケーションやリージョンに、アプリケーション設定をデプロイするという手動タスクをシンプルにするために、我々はAWS AppConfigとAWS CodePipelineの統合を発表しました。このローンチは、お客様が AWSの数千のチームが使用するベストプラクティスを選択することを可能にします。それは、コード変更を機能リリースから容易に分離し、安全且つ効率的な方法でこれらの機能リリースを自動化するというものです。