Category: Advanced (300)

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の数千のチームが使用するベストプラクティスを選択することを可能にします。それは、コード変更を機能リリースから容易に分離し、安全且つ効率的な方法でこれらの機能リリースを自動化するというものです。

はじめに AWS CloudFormationを介してAmazon Elastic Cloud Compute (EC2) インスタンスをデプロイした後には、ソフトウェアのインストール、またはオペレーティングシステムの設定が必要になることがほとんどです。多くのAWSのお客様はCloudFormationのヘルパースクリプトの一つである cfn-init （2012年2月から利用可能）を使用していると思います。しかし、それ以後もAWSは、お客様のフィードバックに応じて多くの新機能とサービスをリリースしてきました。そのうちの一つはAWS Systems Managerです。このブログ記事では、AWS CloudFormationを介してデプロイされたAmazon EC2インスタンスに対して、AWS Systems Manager State Managerを使用してインスタンスを設定する、よりシンプルで堅牢な方法を紹介します。

多くのお客様から、AWS Control Towerによるガバナンスを実現する前に、Control Towerの発見的ガードレールだけを既存のAWSアカウントに適用したいという要望をいただいています。この度、既存のAWS OrganizationでAWS Control Towerを起動できるようになりました。これにより、お客様は既存のアカウントにてAWS Control Towerの発見的ガードレールのコンプライアンスを適用できるようになりました。加えて、我々はControl Towerの配下にアカウントを登録する機能も発表しました。Control Towerガバナンスをアカウントに拡張する前に、Control Towerのガードレールがアカウントにどのように影響するかを確認することをお勧めします。 このブログでは、AWS Config適合パックを使用してControl Towerガードレールを既存のアカウントに適用する方法を示します。AWS Control Towerに登録する前に、そのアカウントのリソースのコンプライアンスを評価できます。また、適合パックを変更し、管理されていないアカウントに発見的ガードレールのサブセットを適用する方法を示します。最後に、適合パックを使用して、AWS Control Towerがデプロイされていないリージョンに存在するアカウントのリソースを管理する方法を示します。

開発者がアプリケーションを開発・パッケージング・デプロイするための強力な手法として、コンテナ技術はその代表的な1つに挙げられます。そしてそのようなコンテナ技術における様々なユースケースをサポートすべく、AWSではAmazon Elastic Container Service (Amazon ECS) に代表される多様なサービスを提供しています。
面白法人カヤック の技術部／インフラエンジニアである 藤原 俊一郎 氏にゲスト投稿いただき、Amazon ECS をはじめとした各AWSサービスをビルディングブロックとして組み合わせて利用していく上での課題と、その解決策の実例を紹介します。