AWS Health API へのアクセス - AWS Health

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Health API へのアクセス

AWS Health は、トランスポートとして HTTPS を使用し、メッセージシリアライズフォーマットとして JSON を使用する RESTful なウェブサービスです。アプリケーションコードから直接、AWS Health API にリクエストを行うことができます。この REST API を直接使用するときは、リクエストの署名と認証のためのコードを書く必要があります。AWS Health が提供するオペレーションとパラメータの詳細については、AWS Health API リファレンスを参照してください。

注記

AWS Health API を使用するには、AWS Support のビジネス、エンタープライズ On-Ramp、またはエンタープライズのサポートプランが必要です。ビジネス、エンタープライズ On-Ramp、またはエンタープライズのサポートプランのない AWS アカウントから AWS Health APIを呼び出した場合は、SubscriptionRequiredException エラーが表示されます。

AWS SDK を使用して AWS Health REST API コールをラップすることで、アプリケーション開発を簡素化できます。開発者が AWS 認証情報を指定すれば、ライブラリによって認証とリクエスト署名の処理が自動的に行われます。

AWS Health では、AWS Management Consoleに AWS Health ダッシュボードが用意されており、イベントや影響を受けるエンティティを表示および検索できます。「AWS Health ダッシュボード – アカウントヘルスについて始める」を参照してください。

エンドポイント

AWS Health API はマルチリージョンアプリケーションアーキテクチャに従い、アクティブ/パッシブ構成に 2 つのリージョンエンドポイントがあります。アクティブ/パッシブ DNS フェイルオーバーをサポートするために、AWS Health は単一のグローバルエンドポイントを提供します。グローバルエンドポイントで DNS ルックアップを実行して、アクティブなエンドポイントおよび対応する署名 AWS リージョンを判別できます。これにより、コードでどのエンドポイントを使用するかを把握できるため、AWS Health から最新の情報を取得できます。

グローバルエンドポイントにリクエストを行うときは、ターゲットとするリージョンエンドポイントに AWS アクセス認証情報を指定し、リージョンの署名を設定します。それ以外の場合は、認証が失敗することがあります。詳細については、「AWS Health API リクエストの署名」を参照してください。

次の表は、デフォルトの設定を示しています。

説明 署名リージョン エンドポイント プロトコル
[Active] (アクティブ)

us-east-1

health.us-east-1.amazonaws.com

HTTPS
パッシブ

us-east-2

health.us-east-2.amazonaws.com

HTTPS
グローバル

us-east-1

注記

これは、現在のアクティブなエンドポイントの署名リージョンです。

global.health.amazonaws.com

HTTPS

エンドポイントがアクティブなエンドポイントであるかどうかを判断するには、グローバルエンドポイント CNAME で DNS ルックアップを実行し、解決された名前から AWS リージョンを抽出します。

例 : グローバルエンドポイントでの DNS ルックアップ

次のコマンドは、global.health.amazonaws.com エンドポイントでの DNS ルックアップを実行します。次に、このコマンドは us-east-1 リージョンエンドポイントを返します。この出力は、AWS Health にどのエンドポイントを使用する必要があるのかを示しています。

dig global.health.amazonaws.com | grep CNAME global.health.amazonaws.com. 10 IN CNAME health.us-east-1.amazonaws.com
ヒント

アクティブなエンドポイントとパッシブなエンドポイントの両方が AWS Health データを返します。ただし、最新の AWS Health データは、アクティブなエンドポイントからのみ提供されます。パッシブなエンドポイントからのデータは、最終的にアクティブなエンドポイントと一致します。アクティブなエンドポイントが変更された場合は、ワークフローを再起動することをお勧めします。

高可用性エンドポイントのデモの使用

次のコード例では、AWS Health はグローバルエンドポイントに対して DNS ルックアップを使用し、アクティブなリージョンエンドポイントと署名リージョンを判断します。アクティブなエンドポイントが変更されると、コードはワークフローを再開します。

Java のデモの使用

前提条件

Gradle をインストールする必要があります。

Java の例を使用するには
  1. GitHub からAWS Health 高可用性エンドポイントのデモをダウンロードします。

  2. デモプロジェクトの high-availability-endpoint/java ディレクトリに移動します。

  3. コマンドラインウィンドウで次のコマンドを入力します。

    gradle build
  4. 次のコマンドを入力して AWS 認証情報を指定します。

    export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" export AWS_SESSION_TOKEN="your-aws-token"
  5. 次のコマンドを入力してデモを実行します。

    gradle run
    例 : AWS Health イベント出力

    このコード例は、AWS アカウントの過去 7 日間の最新の AWS Health イベントを返します。次の例では、出力に AWS Config サービスの AWS Health イベントが含まれています。

    > Task :run [main] INFO aws.health.high.availability.endpoint.demo.HighAvailabilityV2Workflow - EventDetails(Event=Event(Arn=arn:aws:health:global::event/CONFIG/AWS_CONFIG_OPERATIONAL_NOTIFICATION/AWS_CONFIG_OPERATIONAL_NOTIFICATION_88a43e8a-e419-4ca7-9baa-56bcde4dba3, Service=CONFIG, EventTypeCode=AWS_CONFIG_OPERATIONAL_NOTIFICATION, EventTypeCategory=accountNotification, Region=global, StartTime=2020-09-11T02:55:49.899Z, LastUpdatedTime=2020-09-11T03:46:31.764Z, StatusCode=open, EventScopeCode=ACCOUNT_SPECIFIC), EventDescription=EventDescription(LatestDescription=As part of our ongoing efforts to optimize costs associated with recording changes related to certain ephemeral workloads, AWS Config is scheduled to release an update to relationships modeled within ConfigurationItems (CI) for 7 EC2 resource types on August 1, 2021. Examples of ephemeral workloads include changes to Amazon Elastic Compute Cloud (Amazon EC2) Spot Instances, Amazon Elastic MapReduce jobs, and Amazon EC2 Autoscaling. This update will optimize CI models for EC2 Instance, SecurityGroup, Network Interface, Subnet, VPC, VPN Gateway, and Customer Gateway resource types to record direct relationships and deprecate indirect relationships. A direct relationship is defined as a one-way relationship (A->B) between a resource (A) and another resource (B), and is typically derived from the Describe API response of resource (A). An indirect relationship, on the other hand, is a relationship that AWS Config infers (B->A), in order to create a bidirectional relationship. For example, EC2 instance -> Security Group is a direct relationship, since security groups are returned as part of the describe API response for an EC2 instance. But Security Group -> EC2 instance is an indirect relationship, since EC2 instances are not returned when describing an EC2 Security group. Until now, AWS Config has recorded both direct and indirect relationships. With the launch of Advanced queries in March 2019, indirect relationships can easily be answered by running Structured Query Language (SQL) queries such as: SELECT resourceId, resourceType WHERE resourceType ='AWS::EC2::Instance' AND relationships.resourceId = 'sg-234213' By deprecating indirect relationships, we can optimize the information contained within a Configuration Item while reducing AWS Config costs related to relationship changes. This is especially useful in case of ephemeral workloads where there is a high volume of configuration changes for EC2 resource types. Which resource relationships are being removed? Resource Type: Related Resource Type 1 AWS::EC2::CustomerGateway: AWS::VPN::Connection 2 AWS::EC2::Instance: AWS::EC2::EIP, AWS::EC2::RouteTable 3 AWS::EC2::NetworkInterface: AWS::EC2::EIP, AWS::EC2::RouteTable 4 AWS::EC2::SecurityGroup: AWS::EC2::Instance, AWS::EC2::NetworkInterface 5 AWS::EC2::Subnet: AWS::EC2::Instance, AWS::EC2::NetworkACL, AWS::EC2::NetworkInterface, AWS::EC2::RouteTable 6 AWS::EC2::VPC: AWS::EC2::Instance, AWS::EC2::InternetGateway, AWS::EC2::NetworkACL, AWS::EC2::NetworkInterface, AWS::EC2::RouteTable, AWS::EC2::Subnet, AWS::EC2::VPNGateway, AWS::EC2::SecurityGroup 7 AWS::EC2::VPNGateway: AWS::EC2::RouteTable, AWS::EC2::VPNConnection Alternate mechanism to retrieve this relationship information: The SelectResourceConfig API accepts a SQL SELECT command, performs the corresponding search, and returns resource configurations matching the properties. You can use this API to retrieve the same relationship information. For example, to retrieve the list of all EC2 Instances related to a particular VPC vpc-1234abc, you can use the following query: SELECT resourceId, resourceType WHERE resourceType ='AWS::EC2::Instance' AND relationships.resourceId = 'vpc-1234abc' If you have any questions regarding this deprecation plan, please contact AWS Support [1]. Additional sample queries to retrieve the relationship information for the resources listed above is provided in [2]. [1] https://aws.amazon.com/support [2] https://docs.aws.amazon.com/config/latest/developerguide/examplerelationshipqueries.html), EventMetadata={})

Java リソース

  • 詳細については、AWS SDK for Java API リファレンスInterface HealthClient およびソースコードを参照してください。

  • DNS ルックアップのこのデモで使用しているライブラリの詳細については、GitHub で dnsjava を参照してください。

Python デモの使用

前提条件

Python 3 をインストールする必要があります。

Python の例を使用するには
  1. GitHub からAWS Health 高可用性エンドポイントのデモをダウンロードします。

  2. デモプロジェクトの high-availability-endpoint/python ディレクトリに移動します。

  3. コマンドラインウィンドウで次のコマンドを入力します。

    pip3 install virtualenv virtualenv -p python3 v-aws-health-env
    注記

    Python 3.3 以降では、virtualenv をインストールする代わりに、組み込みの venv モジュールを使用して仮想環境を作成できます。詳細については、Pythonのウェブサイトで venv - Creation of virtual environments を参照してください。

    python3 -m venv v-aws-health-env
  4. 次のコマンドを入力して仮想環境をアクティブ化します。

    source v-aws-health-env/bin/activate
  5. 次のコマンドを入力して依存関係をインストールします。

    pip install -r requirements.txt
  6. 次のコマンドを入力して AWS 認証情報を指定します。

    export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" export AWS_SESSION_TOKEN="your-aws-token"
  7. 次のコマンドを入力してデモを実行します。

    python3 main.py
    例 : AWS Health イベント出力

    このコード例は、AWS アカウントの過去 7 日間の最新の AWS Health イベントを返します。次の出力は、AWS セキュリティ通知の AWS Health イベントを返します。

    INFO:botocore.credentials:Found credentials in environment variables.
    INFO:root:Details: {'arn': 'arn:aws:health:global::event/SECURITY/AWS_SECURITY_NOTIFICATION/AWS_SECURITY_NOTIFICATION_0e35e47e-2247-47c4-a9a5-876544042721', 
    'service': 'SECURITY', 'eventTypeCode': 'AWS_SECURITY_NOTIFICATION', 'eventTypeCategory': 'accountNotification', 'region': 'global', 'startTime': datetime.datetime(2020, 8, 19, 23, 30, 42, 476000, 
    tzinfo=tzlocal()), 'lastUpdatedTime': datetime.datetime(2020, 8, 20, 20, 44, 9, 547000, tzinfo=tzlocal()), 'statusCode': 'open', 'eventScopeCode': 'PUBLIC'}, description: 
    {'latestDescription': 'This is the second notice regarding TLS requirements on FIPS endpoints.\n\nWe
    are in the process of updating all AWS Federal Information Processing Standard (FIPS) endpoints across all AWS regions 
    to Transport Layer Security (TLS) version 1.2 by March 31, 2021 . In order to avoid an interruption in service, we encourage you to act now, by ensuring that you connect to AWS FIPS endpoints at a TLS version of 1.2. 
    If your client applications fail to support TLS 1.2 it will result in connection failures when TLS versions below 1.2 are no longer supported.\n\nBetween now and March 31, 2021 AWS will remove TLS 1.0 and TLS 1.1 support from each FIPS endpoint where no connections below TLS 1.2 are detected over a 30-day period. 
    After March 31, 2021 we may deploy this change to all AWS FIPS endpoints, even if there continue
    to be customer connections detected at TLS versions below 1.2. \n\nWe will provide additional updates and reminders on the AWS Security Blog, with a ‘TLS’ tag [1]. If you need further guidance or assistance, please contact AWS Support [2] or your Technical Account Manager (TAM). 
    Additional information is below.\n\nHow can I identify clients that are connecting with TLS
    1.0/1.1?\nFor customers using S3 [3], Cloudfront [4] or Application Load Balancer [5] you can use
    your access logs to view the TLS connection information for these services, and identify client
    connections that are not at TLS 1.2. If you are using the AWS Developer Tools on your clients, 
    you can find information on how to properly configure your client’s TLS versions by visiting Tools to Build on AWS [7] or our associated AWS Security Blog has a link for each unique code language [7].\n\nWhat is Transport Layer Security (TLS)?\nTransport Layer Security (TLS Protocols) are cryptographic protocols designed to provide secure communication across a computer network 
    [6].\n\nWhat are AWS FIPS endpoints? \nAll AWS services offer Transport Layer Security (TLS) 1.2 encrypted endpoints that can be used for all API calls. Some AWS services also offer FIPS 140-2 endpoints [9] for customers that require use of FIPS validated cryptographic libraries. \n\n[1] https://aws.amazon.com/blogs/security/tag/tls/\n[2] https://aws.amazon.com/support\n[3] 
    https://docs.aws.amazon.com/AmazonS3/latest/dev/LogFormat.html\n[4] https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html\n[5] https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html\n[6] https://aws.amazon.com/tools\n[7] https://aws.amazon.com/blogs/security/tls-1-2-to-become-the-minimum-for-all-aws-fips-endpoints\n[8] 
    https://en.wikipedia.org/wiki/Transport_Layer_Security\n[9] https://aws.amazon.com/compliance/fips'}
  8. 完了したら、次のコマンドを入力して仮想マシンを無効にします。

    deactivate

Python リソース

AWS Health API リクエストの署名

AWS SDK または AWS Command Line Interface (AWS CLI) を使用して AWS へのリクエストを行う場合、これらのツールで、設定時に指定されたアクセスキーを使用して自動的にリクエストに署名されます。例えば、以前の高可用性エンドポイントデモの AWS SDK for Java を使用する場合、自分でリクエストに署名する必要はありません。

Java コードの例

AWS SDK for Java で AWS Health API を使用する方法の例については、このコード例を参照してください。

リクエストを行うときに、AWS Health への通常のアクセスには、AWS ルートアカウントの認証情報を使用しないことを強くお勧めします。IAM ユーザーの認証情報を代わりに使用できます。詳細については、IAM ユーザーガイドAWS アカウントのルートユーザーアクセスキーをロックするを参照してください。

AWS SDK も AWS CLI も使用しない場合は、リクエストを自分で署名する必要があります。AWS 署名バージョン 4 を使用することをお勧めします。詳細については、『AWS』の「AWS 全般のリファレンス API リクエストの署名」を参照してください。