Amazon Web Services ブログ

Sébastien Stormacq

Author: Sébastien Stormacq

Seb has been writing code since he first touched a Commodore 64 in the mid-eighties. He inspires builders to unlock the value of the AWS cloud, using his secret blend of passion, enthusiasm, customer advocacy, curiosity and creativity. His interests are software architecture, developer tools and mobile computing. If you want to sell him something, be sure it has an API. Follow him on Twitter @sebsto.

新しい ID フェデレーション – AWS でアクセスコントロールに従業員属性を使用する

AWS または他の多くのシステムのリソースへのアクセスを管理する場合、ほとんどの場合、ロールベースのアクセスコントロール (RBAC) を使用するでしょう。RBAC を使用する場合、リソースへのアクセス許可の定義、こうしたアクセス許可のポリシーによるグループ化、ポリシーのロールへの割り当て、個人、個人のグループ、サーバー、アプリケーションなどのエンティティへのロールの割り当てを行うことになります。多くの AWS のお客様は、組織内で同様のビジネス機能を共有している人などの関連するエンティティへのアクセス許可の付与を簡素化するためにそうしていると語っています。 たとえば、財務データベース管理者のロールを作成し、そのロールに財務に必要なテーブルやコンピューティングリソースへのアクセス権を付与することができます。データベース管理者の Alice がその部門に移動すると、彼女に財務データベース管理者のロールを割り当てます。 AWS では、AWS Identity and Access Management (IAM) のアクセス許可ポリシーおよび IAM ロールを使用して、RBAC 戦略を実装します。 リソースの増加により、スケーリングが困難になります。新しいリソースがシステムに追加されると、システム管理者は、その新しいリソースに対するアクセス許可をすべての関連するポリシーに追加する必要があります。何千ものリソースや数千のポリシーがある場合、これをどのように拡張すればよいでしょうか? 1 つのポリシーの変更がユーザーまたはアプリケーションに不要な特権を付与しないことをどのように確認すればよいでしょうか? 属性ベースのアクセスコントロール リソースが増え続ける状況の中、アクセス許可の管理を簡素化する新しいパラダイムが登場しました。属性ベースのアクセスコントロール (ABAC) です。ABAC を使用する場合、一致する属性に基づいてアクセス許可を定義します。ポリシーでは、ユーザー属性、リソース属性、環境属性など、あらゆるタイプの属性を使用できます。ポリシーは IF … THEN ルールになります。たとえば、 IF ユーザー属性 role == manager THEN 彼女は属性 sensitivity == confidential であるファイルリソースにアクセスできます。 ABAC アクセス許可コントロールを使用すると、リソースを追加するときにポリシーを更新する必要がなくなるため、アクセス許可システムの拡張が簡単になります。代わりに、リソースに適切な属性がアタッチされていることを保証する必要があります。ABAC では、ジョブロールごとにポリシーを作成する必要がないため、管理するポリシーの数を減らすことができます。 AWS では、属性はタグと呼ばれます。タグは Amazon Elastic Compute Cloud (EC2) インスタンス、Amazon […]

Read More

新機能 – シングルリージョン限定の Amazon DynamoDB テーブルをグローバルテーブルに変換する

何十万人もの AWS のお客様が Amazon DynamoDB を活用しています。AWS は 2017 年に、DynamoDB グローバルテーブルを提供開始しました。これは、マルチリージョン、マルチマスター対応の DynamoDB テーブルを独自のレプリケーションソリューションを構築して維持する必要なくデプロイできるフルマネージド型ソリューションです。グローバルテーブルを作成するときには、テーブルを使用できるようにしたい複数の AWS リージョンを指定します。DynamoDB は、これらのリージョンに同一のテーブルを作成して、進行中のデータ変更をそれらすべてに伝播するために必要なタスクのすべてを実行します。 AWS のお客様が DynamoDB グローバルテーブルを利用する主な 2 つの理由があります。クライアントに低レイテンシーの提供と、バックアップや災害対策の円滑化です。レイテンシーとは、ネットワークに転送要求を出してから実際にデータが送られてくるまでに生じる通信の遅延時間を指します。低いレイテンシーのアプリケーションでは、高い顧客エンゲージメントと、売上拡大が見込まれます。バックエンドをユーザーに近い複数のリージョンにデプロイすると、お客様のアプリケーションのレイテンシーが下がります。別のリージョンにデータをフルコピーしておくと、きわめてまれに起こるリージョン全体の不具合の際でもトラフィックをそのリージョンに切り替えやすくなります。AWS の CTO であるWerner Vogels 博士は以前に「障害は起こるものだ。あらゆるものは時間が経てば必ず障害が生じる」と述べています。 本日より、お持ちの DynamoDB テーブルはわずか数回のクリックでグローバルテーブルに変換できるようになりました。これには、直接AWS マネジメントコンソールから操作するか、または AWS コマンドラインインターフェイス (CLI) 、Amazon DynamoDB API のいずれかを使用します。これまでグローバルテーブルに変換できるのは空のテーブルだけでした。つまり、テーブルを作成する時点で、リージョン内のテーブルの使用法を推測する必要がありました。それが今回、テーブルのグローバル化や、既存のグローバルテーブルを別のリージョンへの拡張がいつでもできるようになりました。 レプリケーションの設定中であっても、ユーザーのアプリケーションではテーブルの使用を継続できます。テーブルにリージョンを追加すると、DynamoDB では既存のテーブルのスナップショットを使用して新しいレプリカの追加を開始します。DynamoDB で新しいレプリカを構築すると同時に、アプリケーションでは既存のリージョンに対して書き込みを継続します。進行中に生じたアップデートは最終的にはすべて新しいレプリカにレプリケーションされます。 AWS コマンドラインインターフェイス (CLI) を使用して DynamoDB グローバルテーブルを作成するために、まず米国西部 (オレゴン) リージョン (us-west-2) のローカルテーブルを作成します。 aws dynamodb create-table –region us-west-2 […]

Read More

新機能 – 加重ターゲットグループの使用によって Application Load Balancer がデプロイメントをシンプルに

クラウドコンピューティングのメリットのひとつは、インフラストラクチャをプログラム的に作成し、必要なくなったら破棄する可能性です。これは、アプリケーションをデプロイする方法を、開発者が根本的に変えることを可能にします。オンプレミスでアプリケーションをデプロイしていた頃、開発者はアプリケーションの新しいバージョンのために既存のインフラストラクチャを再利用しなければなりませんでした。クラウドでは、開発者がアプリケーションの新しいバージョンのために新しいインフラストラクチャを作成し、古いバージョンを破棄する前にしばらく並行して実行させておきます。この手法はブルー/グリーンデプロイメントと呼ばれます。これは、アプリケーションの 2 つのバージョン間のトラフィックを漸進的に切り替え、新しいバージョンでのビジネスメトリクスと運用メトリクスを監視して、問題が発生した場合にはトラフィックを前のバージョンに戻すことを可能にします。 ブルー/グリーンデプロイメントを導入するために、AWS のお客様は 2 つの戦略を導入します。最初の戦略は 2 番目のアプリケーションスタックの作成で構成されており、これには 2 番目のロードバランサーが含まれます。開発者は、DNS などの何らかの加重ルーティング手法を使用して、トラフィックの一部を各スタックに送ります。2 つ目の戦略は、ロードバランサーの背後にあるインフラストラクチャの交換で構成されています。どちらの戦略も、クライアントマシン上の DNS TTL およびのキャッシングに応じてバージョン間でのトラフィックの移動に遅延を生じさせる場合があります。これらは、追加のロードバランサーを実行するための追加コストと、追加のロードバランサーをウォームアップするための遅延の可能性を生じ得ます。 ターゲットグループはロードバランサーに、トラフィックを EC2 インスタンス、固定 IP アドレス、または AWS Lambda 関数などのどこに送るかを指示します。ロードバランサーを作成する時は、1 つ、または複数のリスナーを作成し、1 つのターゲットグループにトラフィックを送るためのリスナールールを設定します。 本日、AWS は Application Load Balancer のための加重ターゲットグループを発表します。これは、開発者がアプリケーションの複数バージョンにトラフィックをどのように分散させるかを制御できるようにします。 複数の加重ターゲットグループ 複数のターゲットグループをリスナールールの forward アクションに追加し、各グループの重みを指定することができるようになりました。例えば、8 および 2 の重みを持つ 2 つのターゲットグループがあるルールを定義すると、ロードバランサーはトラフィックの 80% を最初のターゲットグループに、20% をもう一方のターゲットグループにルーティングします。 今すぐ加重ターゲットグループで実験するには、この CDK コードを使用できます。これは、EC2 インスタンスと、それらの前にある Elastic Load Balancer で 2 つの Auto […]

Read More

Amplify Console のプルリクエストプレビューと Cypress テストの機能を使い便利にアプリのテストを行う

Amplify Console を使うと、開発者は継続的なデプロイを行う Git ベースのワークフローの定義やフルスタックのサーバーレスウェブアプリケーションのホスティングが容易に行えるようになりますフルスタックのサーバーレスアプリの構造では、GraphQL API やデータおよびファイルストレージ、また認証もしくは分析のためのバックエンドのリソースが、React、Gatsby あるいは Angular といったフロントエンドフレームワークと統合されています。Amplify Console に関する詳細については、以前のブログ記事をご参照ください。 今回は、コードを実稼働状態にリリースする前の段階において、プレビュー URL を作成しプルリクエストについてエンドツーエンドのテストが行える機能を発表させていただきます。 プルリクエストプレビュー Amplify Console の設定で、開発者が Git レポジトリにプルリクエストを送信するたびにアプリケーションを一意の URL にデプロイできるようになりました。このプレビュー URL は、実稼働のサイトが使用するものとは完全に異なるものです。プルリクエストをご自身のコードレポジトリのメインブランチにマージする前に、Amplify Console の新機能で変更点を確認できます。Amplify CLI を介してプロビジョニングされたバックエンド環境も含むフルスタックのアプリでは、すべてのプルリクエストがプルリクエストが閉じられると削除される一時的なバックエンドをスピンアップします。これにより、実稼働環境から完全に分離された状態で変更点の確認が可能になります。Amplify Console では、プライベートの Git レポジトリに限り、プルリクエストのためのバックエンドインフラストラクチャを作成します。これにより、不要なプルリクエストによる余計なコスト発生を防ぎます。 この仕組みを理解するために、クラウドベース認証のバックエンドがあるウェブアプリケーションを作成し、Amplify Console でデプロイしてみることにします。最初に React アプリケーションを作成します (React のインストールについてはこちらをご参照ください) 。 npx create-react-app amplify-console-demo cd amplify-console-demo Amplify の環境を初期化します (先に、Amplify CLI のインストール方法をご確認ください) 。Amazon Cognito で提供されている、クラウドベース認証のバックエンドを追加します。Amplify CLI […]

Read More

追加のメタデータを使用した VPC フローログから学ぶ

Amazon Virtual Private Cloud のフローログでは、VPC のネットワークインターフェイスを出入りする IP トラフィックに関する情報を取得することができます。フローログのデータは、Amazon CloudWatch Logs またはAmazon Simple Storage Service (S3) に発行できます。 2015 年にVPC フローログを開始したため、VPC 全体の接続性の問題、侵入の検出、以上の検出、またはコンプライアンスの目的でのアーカイブをトラブルシューティングするなどのさまざまなユースケースにそれを使用してきました。今日まで、VPC フローログは、ソース IP、ソースポート、宛先 IP、宛先ポート、アクション (accept、reject) およびステータスなどの情報を提供します。VPC フローログは一度有効になると、エントリは、次のようになります。 この情報はほとんどのフローを理解するのに十分であった一方で、IP アドレスをインスタンス ID に一致させるため、またはフローの方向性を推測して意味のある結論を得るために、追加の計算と検索が必要でした。 今日、ネットワークフローをより良く理解するために、フローログレコードに含めるために、追加メタデータの可用性を通知しています。豊かなフローログにより、ログデータから意味のある情報を抽出するために必要な計算やルックアップの回数を減らすことで、スクリプトを簡素化し、後処理の必要性を完全に排除することができます。 新しい VPC フローログを作成するときに、既存のフィールドに加えて、次のメタデータを追加することができるようになりました。 vpc-id : ソース Elastic Network Interface (ENI) を含む VPC の ID。 subnet-id : ソース ENI を含むサブネットの ID。 instance-id : ソースインターフェイスに関連付けられたインスタンスの Amazon […]

Read More

AWS System Manager Sessions Manager を使用した新しい機能 – Port Forwarding

昨今不変のインフラストラクチャアーキテクチャパターンを採用しているお客様が増えており、更新ごとにインフラストラクチャ全体を再構築およびリデプロイしています。SSH や RDP を介してサーバーに接続して、設定を更新したり、ソフトウェアの更新をデプロイしたりすることはほとんどありません。ただし、既存のアプリケーションをクラウドに移行する場合、Amazon Elastic Compute Cloud (EC2) インスタンスに接続して、さまざまな管理タスクまたは運用タスクを実行するのが一般的です。攻撃にさらされる面を減らすために、AWS では、ジャンプホストとも呼ばれる Bastion ホストを使用することをお勧めします。この特別な目的の EC2 インスタンスは、インターネットからのプライマリアクセスポイントになるように設計されており、他の EC2 インスタンスへのプロキシとして機能します。 EC2 インスタンスに接続するには、まず Bastion ホストに SSH/RDP 接続し、そこから宛先の EC2 インスタンスに接続します。 攻撃にさらされる面、Bastion ホストを管理するための運用上の負荷、および発生する追加コストをさらに削減するために、AWS Systems Manager Session Manager は、独自の Bastion ホストを実行および操作する必要も、 EC2 インスタンスで SSH を実行する必要もなく、 EC2 インスタンスに安全に接続できます。インスタンスに Systems Manager のエージェントがインストールされており、Systems Manager API を呼び出す IAM アクセス許可がある場合、AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) を使用して、Linux または Windows EC2 […]

Read More

Amplify コンソール – フルスタックのサーバーレスウェブアプリのためのホスティング

AWS Amplify コンソールはフルスタックウェブアプリケーションのホスティングサービスで、使用したいソースコードリポジトリからの継続的なデプロイメントが可能です。Amplify コンソールは、2018 年 11 月に AWS re:Invent で発表されました。それ以来、チームはお客様のフィードバックに耳を傾け、迅速にイテレーションを行って 新しい機能をいくつかリリースしました。以下はそれらの簡単な要約です。 キャッシュの即時無効化 Amplify コンソールでは、コンテンツ配信ネットワーク、つまり CDN を介して、サーバーレスバックエンドを使用する単一ページのウェブアプリ、または静的サイトをホストすることができます。CDN は、世界中のエッジロケーションでファイルをキャッシュする分散されたサーバーのネットワークで、ウェブファイルアセットの低レイテンシー分散を可能にします。 これまで、CDN でコンテンツを更新するには、キャッシュを手動で無効化し、変更がグローバルに伝播されるまで 15~20 分待つ必要がありました。頻繁な更新を行うために、開発者はアセットヘッダーに短い TTL (time-to-live) を設定する (これによって更新は速くなりますが、パフォーマンスには悪影響が生じます) などの次善策を講じていましたが、今では、より迅速なデプロイメントとより高速なパフォーマンスの間で妥協する必要はありません。Amplify コンソールは、リポジトリに対するコミットコードごとに変更を構築して CDN にデプロイし、これらはブラウザで即時に表示できます。 「Deploy To Amplify Console」ボタン GitHub でプロジェクトソースコードをパブリッシュするときは、Readme ドキュメントに「Deploy To Amplify Console」ボタンを提供することによって、他の開発者がアプリケーションを簡単に構築してデプロイできるようにすることが可能です。ボタンをクリックすると Amplify コンソールが開き、コードをデプロイするための 3 つのステップのプロセスを提案します。 このプロセスをこれらのプロジェクト例でテストして、こちらのドキュメントも参照してください。独自のコードリポジトリへのボタンの追加は簡単で、この行を Readme ドキュメントに追加するだけです (GitHub URL の username と repository の名前を置き換えるようにしてください)。 [![amplifybutton](https://oneclick.amplifyapp.com/button.svg)](https://console.aws.amazon.com/amplify/home#/deploy?repo=https://github.com/username/repository) 手動でのデプロイメント […]

Read More

新着 – カーネルパニックをトリガーし、応答しない EC2 インスタンスを診断

オンプレミスのデータセンターにデプロイされたシステムで作業を行っていたころ、ときどき、応答しないサーバーのデバッグをしなければならないことがありました。その場合、通常は誰かに頼んで、フリーズしたサーバーでマスク不可能割り込み (NMI、non-maskable interrupt) ボタンを物理的に押してもらうか、あるいはシリアルインターフェイス (はい、シリアルです。RS-232 など) を介してコマンドコントローラーに信号を送信してもらう必要がありました。このコマンドによってシステムがトリガーされ、フリーズしたカーネルの状態がファイルにダンプされて、さらなる分析が行われます。このようなファイルは通常、コアダンプあるいはクラッシュダンプと呼ばれます。クラッシュダンプには、クラッシュしたプロセスのメモリのイメージ、システムレジスター、プログラムカウンター、その他フリーズの主要因を特定するのに役立つ情報が含まれています。 本日発表された新しい Amazon Elastic Compute Cloud (EC2) API を使うと、EC2 インスタンスでのカーネルパニックの生成を、リモートでトリガーすることができます。EC2:SendDiagnosticInterrupt API は、物理マシンで NMI ボタンを押す場合と同様に、診断割り込みを、実行中の EC2 インスタンスに送信します。それにより、インスタンスのハイパーバイザーがマスク不可能割り込み (NMI、non-maskable interrupt) をオペレーティングシステムに送信します。NMI 割り込みを受信したときのオペレーティングシステムの挙動は、システムの設定に依存します。通常はカーネルパニックの状態に入ります。カーネルパニックの挙動もオペレーティングシステムの設定に依存し、クラッシュダンプデータファイルの生成がトリガーされたり、バックトレースが取得されたり、差し替えのカーネルがロードされたり、システムが再起動されたりします。 組織内でこの API を使用できる人を管理するには IAM ポリシーを使用します。以下に例を示します。 クラウドエンジニアやシステムエンジニア、あるいはカーネル診断やデバッグ作業のスペシャリストが、クラッシュダンプの中からカーネルがフリーズした原因を分析するための非常に重要な情報を見つけ出します。ダンプを調べるときは、WinDbg (Windows) や crash (Linux) といったツールを使用します。 診断割り込みの使用 この API の使用プロセスは、3 つのステップからなります。まず、割り込みを受信したときの OS の挙動を設定しておく必要があります。 Windows Server AMI のメモリダンプは、デフォルトですでにオンの状態になっています。メモリダンプが保存された後の自動再起動も選択されています。メモリダンプファイルのデフォルトの場所は %SystemRoot% です。これは C:\Windows に相当します。 これらのオプションには、次の場所に進むとアクセスできます。 スタート > […]

Read More