Amazon Web Services ブログ

SAP on AWSにおけるVPCサブネットのゾーニングパターン

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。

企業のファイアウォール内に存在する必要があるSAPランドスケープの設計は比較的簡単ですが、内部からも外部からも接続する必要があるSAPアプリケーションの場合はそうではありません。これらのシナリオでは、必要なコンポーネントとその配置場所について悩むことがよくあります。

この一連のブログ記事では、SAPアプリケーションにおけるAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンを紹介し、例を用いてその使用方法を説明します。セキュリティグループルートテーブルおよびネットワークアクセスコントロールリスト(ACL)の構成と合わせて、よくあるお客様シナリオに基づいた詳細な図で補足しながら、接続経路ごとにいくつかのアーキテクチャ設計パターンを説明します。

アプリケーションを配置するサブネットを正しく見極めるには、アプリケーションへの接続方法を理解することが必要です。SAPアプリケーションに接続する方法をいくつか見てみましょう。

  • 内部専用接続: これらのアプリケーションは内部的にのみ接続します。SAPサポートチームを除き、外部からの接続は許可されていません。この場合、ユーザーまたはアプリケーションは、専用線または仮想プライベートネットワーク(VPN)を介して接続された企業ネットワーク内に存在する必要があります。SAP Enterprise Resource Planning(ERP)、SAP S/4HANA、SAP Business Warehouse(BW)およびSAP BW/4HANAはほとんどの組織で内部専用接続が必要なアプリケーションです。
  • 内部および管理された外部接続: これらのアプリケーションは内部的に接続しますが、既知の外部の関係者に限定した接続も提供します。例えば、内部プロセスからSAP PI(Process Integration)やSAP PO(Process Process Orchestration)を使用することができますし、既知の外部の関係者もホワイトリストに登録されたIPアドレスからソフトウェアのインターフェースに接続することができます。さらに、SAP SuccessFactors、SAP Cloud Platform、SAP AribaなどのSaaS(Software as a Service)ソリューションとの統合は、AWS上で実行されるSAPソリューションに機能を追加する場合にも望まれます。
  • 内部および管理されていない外部接続: SAP hybrisや社外に公開するSAP Enterprise Portalなどのアプリケーションがこのカテゴリーに分類されます。これらのアプリケーションには一般に外部接続が可能ですが、管理、構成および他の内部アプリケーションとの統合のためのコンポーネントなど、内部接続用のコンポーネントがあります。
  • 外部専用接続: ほとんどのコンポーネントが外部から接続可能であっても、アプリケーションにはバックアップ、接続制御、インターフェースなどの基本的な管理タスクのために内部から接続できる必要があるため、稀なシナリオです。このシナリオは滅多にないため、この一連のブログ記事では説明しません。

このブログ記事では、最初のカテゴリーのアプリケーション(内部でのみ接続可能なアプリケーション)で取り得るアーキテクチャパターンについて説明します。今後の記事で、残りの2つのシナリオについて説明します。3つすべてのシナリオにおいて、パッチ、更新プログラムの適用およびその他の関連するシナリオに対処するために、ネットワークアドレス変換(NAT)デバイス(IPv4の場合)Egress-Onlyインターネットゲートウェイ(IPv6の場合)を使用して、AWSリソースからインターネットに接続すると仮定します。さらに、この接続は、インバウンド(インターネットからAWSクラウドへの)接続要求を制限または排除する方法で管理します。

内部専用接続におけるアーキテクチャ設計パターン

このカテゴリーのSAPアプリケーションについて、データベースとアプリケーションサーバーを同じプライベートサブネットまたは分離したプライベートサブネットに配置する2つの設計パターンを見ていきます。

単一のプライベートサブネットにあるデータベースとアプリケーションサーバー

この構成には3つのサブネットがあります。

  • パブリックサブネット: SAProuterとNATゲートウェイまたはNATインスタンスをこのサブネットに配置します。SAPから指定されたパブリックIPアドレスのみがSAProuterに接続できます。詳細は、SAPノート28976 – リモート接続データシートを参照してください。(SAPノートの閲覧にはSAPサポートポータルへの接続が必要です)。
  • 管理用のプライベートサブネット: Microsoft System Center Configuration Manager(SCCM)などの管理ツール、管理者または踏み台ホストをこのサブネットに配置します。このサブネット内のアプリケーションは、エンドユーザーが直接接続するのではなく、エンドユーザーをサポートするために必要です。このサブネット内のアプリケーションは、パブリックサブネットに配置されたNATゲートウェイまたはNATインスタンスを介してインターネットに接続できます。
  • アプリケーションとデータベース用のプライベートサブネット: データベースとアプリケーションをこのサブネットに配置します。SAPアプリケーションは、SAP GUI経由またはSAP Webディスパッチャを介したHTTP/S経由でエンドユーザーから接続できます。エンドユーザーはデータベースに直接接続することはできません。

異なるプライベートサブネットにあるデータベースとアプリケーションサーバー

この構成には4つのサブネットがあります。パブリックサブネットと管理用のプライベートサブネットは以前のシナリオと同じ機能を持ちますが、3つ目のサブネット(データベースとアプリケーション用のプライベートサブネット)が2つに分割されています。データベース用のプライベートサブネットには、ユーザー環境からアクセスできません。

これらの2つのアプローチの間に大きな違いはないことが分かります。ただし、2つ目の方法では、データベース用のサブネットを別のルートテーブルとネットワークACLで保護することで、データベースをより安全に保護します。これにより、データベース層への接続をより効果的に制御、管理できます。

私たちの知識を活用

実装例を検討することで、詳細に落とし込んでみましょう。

シナリオ例

お客様は、SAP S/4HANA、SAP FioriおよびSAP BW on HANA(ABAPとJava)を導入する必要があります。これらのアプリケーションは、企業ネットワークからのみ接続可能である必要があります。SAML(Security Assertion Markup Language)によるシングルサインオン(SSO)のために、Active Directory(AD)またはActive Directory フェデレーション サービス(ADFS)との統合も必要です。SAP BWはレガシーアプリケーションとのファイルベースの統合も行い、この目的でSSHファイル転送プロトコル(SFTP)サーバーと通信します。SAP社はサポートのためにこれらのシステムに接続できる必要があります。SAP Solution ManagerのデータベースにはSAP ASEを採用し、SAPアプリケーションの集中監視および変更管理に使用します。すべてのアプリケーションは、SUSE Linux Enterprise Server(SLES)上で稼働していると仮定します。

AWS上のソリューション

この例では、ソリューション要素あたり1つのEC2インスタンスしか想定していません。ワークロードが水平方向にスケールする場合、または高可用性が必要な場合は、機能的に類似した複数のEC2インスタンスを同じセキュリティグループに含めることができます。この場合、セキュリティグループにルールを追加する必要があります。企業ネットワークとVPC間の接続には、IPsecベースのVPNを使用します。Red Hat Enterprise Linux(RHEL)またはMicrosoft Windows Serverを使用している場合は、セキュリティグループ、ルートテーブル、およびネットワークACLに設定変更が必要な場合があります。詳細については、オペレーティングシステムの製品マニュアル、またはAmazon Elastic Compute Cloud(EC2)のセキュリティグループのルールのリファレンスなど、その他の情報源を参照してください。プライマリーのADまたはADFSサーバー、レガシーSFTPサーバーなどの特定のシステムはオンプレミスに残ります。

ソリューションのアーキテクチャ図は以下です。

このアーキテクチャ図の設定例は以下を想定しています。

以下の表は、セキュリティグループの構成例です。セキュリティグループで定義されるルールの概要を示しています。正確なポート番号または範囲については、SAP製品のマニュアルを参照してください。

ネットワークトラフィックのフローは、以下のようなルートテーブルによって管理されています。

*AWS Data Providerは、Amazon CloudWatch、Amazon S3およびAmazon EC2のAWS APIに接続できる必要があります。詳細は、「AWS Data Provider for SAP Installation and Operations Guide」を参照してください。

インスタンスに追加の層のセキュリティが必要な場合、以下の表に示すようなネットワークACLを使用できます。ネットワークACLは高速かつ効率的で、前述の表に示すセキュリティグループに加えて、別の制御層を提供します。セキュリティの推奨事項については、「AWS Security Best Practices」を参照してください。

ある特定の時に(OSパッチ適用など)、EC2インスタンスから追加のインターネット接続が必要な場合があります。ルートテーブル、ネットワークACLおよびセキュリティグループは、この接続を一時的に許可するように調整できます。

ここまでの概要と今後の予定

このブログ記事では、内部専用接続が必要なアプリケーションにおけるサブネットのゾーニングパターンを例に説明してきました。他のサブネットのゾーニングパターンについては、このシリーズの次の記事を参照してください。

AWS上でSAPアプリケーション用のVPCを設定した皆様の経験についてもお聞きしたいと思います。この記事に関するご質問やご提案がありましたら、お気軽にお問い合わせください。

翻訳はPartner SA 河原が担当しました。原文はこちらです。

AWS Organizationsを利用したアカウント作成の自動化

こんにちは、ソリューションアーキテクトの千葉です。

本日はAWS Organizationsを利用したAWSアカウントの作成・管理の自動化方法についてご紹介します。

AWS Organizationsは、組織内のAWSアカウントを統合管理し、セキュリティを高めることができるサービスです。サービスコントロールポリシー (SCP)を利用することで、組織内のAWSアカウントに実行を許可するサービスとアクションを一元的に管理することができます。
AWS Organizationsのもう一つの特徴は、APIを通じて組織配下に新しいAWSアカウントを作成することができることです。これまでは、AWSアカウントを新たに作るにあたって、AWSアカウント作成、連絡先情報入力、お支払情報入力、(必要に応じて)一括請求設定といった手順をマニュアルで実施する必要がありましたが、AWS Organizationsを利用すればこれらの操作はCreateAccountというたった一つのAPIに置換えられます。

AWS Organizationsで作成されたメンバーアカウントには、マスターアカウントのユーザーからアクセス可能なIAMロールが自動作成されます。AWS Security Token Service (STS)を利用してこのIAMロールにアクセスする一時的なセキュリティ認証情報を取得し、AWS Command Line Interface (CLI)AWS SDKsを使って作成したメンバーアカウントに対して共通設定を施したり、定期的な環境チェックを実行したりすることができます。

それでは、アカウント作成およびSTSを利用したアカウント環境設定の手順を説明していきます。

 

メンバーアカウントの作成

まずは組織配下にメンバーアカウントを作成します。操作を実行するIAMユーザーまたはIAMロールには、以下のようにOrganizationsを操作する権限を与えておきます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                 "organizations:*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

CreateAccountのパラメーターには、アカウント名およびEmailアドレスを指定する必要があります。IamUserAccessToBillingパラメーターはメンバーアカウントのIAMユーザーにBilling情報へのアクセスを許可するかどうかの設定で、デフォルトでALLOWになっています。RoleNameパラメーターはメンバーアカウントに作成されるIAMロールの名前で、何も指定しなければOrganizationAccountAccessRoleという名前が割り当てられます。

import boto3
orgs = boto3.client('organizations',region_name='us-east-1')
createAccountRequest = orgs.create_account(
    "AccountName": "string",
    "Email": "string",
    "IamUserAccessToBilling": "string",
    "RoleName": "string"
    )

メンバーアカウントの作成は非同期でおこなわれるため、CreateAccountAPIのレスポンスに含まれるリクエストIDを指定してDescribeCreateAccountStatusを実行し、アカウント作成のステータスをトラッキングします。

createAccountRequestId = createAccountRequest["CreateAccountStatus"]["Id"]
while orgs.describe_create_account_status(CreateAccountRequestId=createAccountRequestId)["CreateAccountStatus"]["State"] != 'SUCCEEDED':
        time.sleep(5)

ステータスが”SUCCEEDEDになればメンバーアカウントの作成は完了です。DescribeCreateAccountStatusのレスポンスは以下のとおりです。AccoutIdは後の手順で利用します。

{
   "CreateAccountStatus": { 
      "AccountId": "string",
      "AccountName": "string",
      "CompletedTimestamp": number,
      "FailureReason": "string",
      "Id": "string",
      "RequestedTimestamp": number,
      "State": "string"
   }
}

 

STSを利用したメンバーアカウントの操作

STSは、AWS リソースへアクセスする一時的な認証情報を提供する機能です。STSの利用方法の詳細はこちらのドキュメントを参照してください。一時認証情報取得にはSTSのAssumeRoleアクションを実行する必要があるので、以下の操作を実行するマスターアカウントのIAMユーザー/IAMロールには以下のIAMポリシーを付与しておいてください。<MemberAccountId>には前手順で取得したメンバーアカウントのAWSアカウントIDを指定します。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<MemberAccountId>:role/OrganizationAccountAccessRole"
  }]
}

STSのAssumeRoleアクションを実行し、一時的な認証情報を取得します。

import boto3
from boto3.session import Session

sts = boto3.client('sts')
assumeRoleResult = sts.assume_role(
        RoleArn = 'arn:aws:iam::<MemberAccountId>:role/OrganizationAccountAccessRole',
        RoleSessionName = 'OrgMasterRoleSession'
        )

accessKeyId = assumeRoleResult["Credentials"]["AccessKeyId"]
secretAccessKey = assumeRoleResult["Credentials"]["SecretAccessKey"]
sessionToken = assumeRoleResult["Credentials"]["SessionToken"]

続いて、取得した一時認証情報でメンバーアカウントを操作するセッションを生成します。regionパラメーターはこの後実行する操作に合わせて指定してください。

session = Session(
        aws_access_key_id=accessKeyId,
        aws_secret_access_key=secretAccessKey,
        aws_session_token=sessionToken,
        region_name='us-east-1'
        )

あとはこのセッションを利用してメンバーアカウントに対して操作をおこなうだけです。OrganizationAccountAccessRoleにはAdministratorAccessポリシーがアタッチされているため、STSをサポートしているアクションであればすべて実行可能です。

試しに作成したメンバーアカウントに対してBillingアラートを設定してみましょう。

sns = session.client('sns')
cloudwatch = session.client('cloudwatch')
    
#create sns topic
snsTopicArn = sns.create_topic(Name='DefaultBillingAlertTopic')["TopicArn"]
sns.subscribe(
    TopicArn=snsTopicArn,
    Protocol='email',
    Endpoint=<YourEmailAddress>
    )

#create billing alert
alertName = 'DefaultBillingAlart'
cloudwatch.put_metric_alarm(
    AlarmName=alertName,
    AlarmDescription=alertName,
    ActionsEnabled=True,
    AlarmActions=[snsTopicArn],
    MetricName='EstimatedCharges',
    Namespace='AWS/Billing',
    Statistic='Maximum',
    Dimensions=[
        {
           'Name': 'Currency',
           'Value': 'USD'
        },
        ],
   Period=21600,
   EvaluationPeriods=1,
   Threshold=100,
   ComparisonOperator='GreaterThanOrEqualToThreshold'
   )

まとめ

リソースをプログラマブルに管理できることは、AWSを利用する大きな利点のひとつです。AWS Organizationsを利用することで、AWSアカウントについてもプラグラマブルに管理することが可能です。今回はBillingアラートを設定する例をご紹介しましたが、AWS CloudTrailAWS Configなどの有効化、AWS CloudFormationを利用した標準構成のデプロイなど、お客様がAWSアカウントを作成時に実行している操作を自動化することができます。ぜひOrganizationsを活用したアカウント管理をお試しください!

 

注1:SCPの権限制御は、アタッチされたアカウントのrootユーザーを含む、すべてのユーザーに影響を与える可能性がある強力な機能です。既存のアカウントに対してOrganizationsを適用する場合、SCPの動作を事前に検証し、実行する操作が既存環境に影響が出ないことを確認した上で有効化してください。

注2:Organizationsで作成したメンバーアカウントは削除することができませんのでご注意ください。

 

Amazon EC2インスタンスにホストベースの侵入検知システムアラートの監視方法

AWSリソースを安全に保護するためのアプローチとして、予防のための仕組み、検知のため仕組みといったそれぞれのレイヤーでのアプローチを検討頂くことを推奨しています。たとえば、Amazon EC2インスタンスにホストベースのコントロールを組み込むことで、アクセスを制限し、システムの動作やアクセスパターンに伴う適切なレベルの可視性を準備できます。これらのコントロールには、ホスト上のネットワークトラフィック、ログファイル、およびファイルアクセスを監視・分析するホストベースの侵入検知システム(HIDS)を含むことが一般的です。 HIDSは、通常、警告、自動修復ソリューションと統合され、攻撃、許可されていない活動、疑わしい活動、環境内の一般的なエラーを検出し対処します。

このブログ記事では、Amazon CloudWatch Logsを使用してオープンソースセキュリティ(OSSEC)HIDSからのアラートを収集、集約する方法を示します。 また、CloudWatch Logs サブスクリプションを組み合わせることで、Amazon Elasticsearch Service(Amazon ES)に分析データと可視化のアラートを配信し、一般的なオープンソースであるKibanaを使用し可視化まで行います。また皆さんが、すぐに試せるようにCloudFormationテンプレートを用意しましたので、ほとんどのデプロイメント作業を自動化させています。このソリューションを使用して、EC2 全体の可視性と洞察を向上させ、セキュリティ修復活動を促進することができます。たとえば、特定ホストがEC2インスタンスのスキャンを検知したらOSSECアラートをトリガーし、VPCネットワークACL(Access Control List)またはAWS WAFルールを実装して、送信元IPアドレスまたはCIDRをブロックすることができます。

ソリューションの概要
次の図は、この記事のソリューションの概要を示しています。

ソリューションの仕組みは次のとおりです。

1. ターゲットEC2インスタンスでは、OSSEC HIDSは、CloudWatch Logs エージェントがキャプチャするログに基づきアラートを生成します。 HIDSは、ログ分析、整合性チェック、Windowsレジストリ監視、ルートキット検出、リアルタイムアラート、およびアクティブな応答を実行します。詳細については、「OSSEC入門」を参照してください。
2. CloudWatch Logs グループはにアラートがイベントとして送信されます。
3. AWS Lambdaを介してイベントをAmazon ESに転送するために、CloudWatch Logs サブスクリプションがターゲットロググループに適用されます。
4. Amazon ESにはログに記録されたアラートデータがロードされます。
5. Kibanaはアラートをほぼリアルタイムで視覚化します。 Amazon ESはすべてのAmazon ESドメインにKibanaを標準でインストールした形で提供されます。

デプロイ時の考慮事項

この記事では、主なOSSEC HIDSのデプロイは、Linuxベースのインストールで構成されています。インストールでは、アラートが各システム内でローカルに生成されます。このソリューションは、デプロイの対象リージョンはAmazon ESとLambdaに依存します。 AWSサービスの可用性に関する最新情報は、Regionテーブルで確認できます。また、EC2インスタンスが必要なコンポーネントを適切にプロビジョニングするために、インターネットアクセスとDNS解決を持つAmazon VPC(Virtual Private Cloud)サブネットを識別する必要があります。

デプロイのプロセスを簡素化するために、テスト環境向けにAWS CloudFormationテンプレートを作成しました。このテンプレートを使用して、テスト環境スタックを既存のAmazon VPCサブネットに自動的にプロビジョニングできます。 CloudFormationを使用してこのソリューションのコアコンポーネントをプロビジョニングし、警告分析用にKibanaを設定します。このソリューションのソースコードはGitHubで入手できます。

Cloud Formation テンプレートは選択したリージョンで、下記の流れで展開されます。

1. CloudWatch LogsにアクセスするためのAWS Identity and Access Management(IAM)ロールが作成され、Amazon Linuxを実行する2つのEC2インスタンスにアタッチされます。注:サンプルHIDSアラートデータを提供するために、2つのEC2インスタンスが自動的に構成され、シミュレートされたHIDSアラートをローカルに生成します。
2. OSSEC、CloudWatch Logsエージェント、およびテスト環境で使用される追加パッケージをインストールして設定します。
3. ターゲットのHIDS Amazon ESドメインを作成します。
4. ターゲットのHIDS CloudWatch Logsグループを作成します。
5. Amazon ESにHIDSアラートを送信するために、Lambda関数とCloudWatch Logsサブスクリプションを作成します。

CloudFormationスタックがデプロイされた後、Amazon ESドメインのKibanaインスタンスにアクセスして、テスト環境のセットアップの最終ステップを完了することができます。これについては後で説明します。

このブログの投稿の範囲外にはなりますが、既存のEC2環境にOSSECを導入する場合は、監視対象のログファイル、完全性チェック用のディレクトリ、アクティブな応答など、必要な構成を決定する必要があります。通常、環境の最適化のためにシステムのテストとチューニングに時間を要すことがほとんどです。 OSSECのドキュメントは、このプロセスに慣れ始めるのに適しています。エージェントのインストールと別のOSSECマネージャを使用してイベントを一元的に処理してからCloudWatch Logsにエクスポートするという、OSSECの展開には別のアプローチをとることもできます。この展開では、エージェントとマネージャの間に追加のサーバーコンポーネントとネットワーク通信が必要です。 Windows ServerはOSSECでサポートされていますが、エージェントベースのインストールが必要なため、OSSECマネージャが必要です。 OSSECのアーキテクチャと展開オプションの詳細については、「OSSECアーキテクチャ」を参照してください。

ソリューションのデプロイ
手順の概要は次のとおりです。

1. CloudFormationスタックを起動します。
2. Kibanaのインデックスパターンを設定し、アラートの探索を開始します。
3. Kibana HIDSダッシュボードを設定し、アラートを視覚化します。

1. CloudFormationスタックの起動

CloudFormationテンプレートを使用して、プロビジョニングプロセスを自動化しテスト環境を起動します。次の入力パラメータでは、展開のためにターゲットVPCとサブネット(インターネットアクセスが必要)を識別する必要があります。ターゲットサブネットがインターネットゲートウェイを使用する場合は、AssignPublicIPパラメーターをtrueに設定します。ターゲットサブネットがNATゲートウェイを使用する場合は、AssignPublicIPのデフォルト設定をfalseのままにしておきます。

まず、デプロイしたリージョンにあるS3バケットにLambda Function 展開パッケージを配置する必要があります。これを行うには、圧縮された展開パッケージをダウンロードし、同じリージョンバケットにアップロードします。 S3へのオブジェクトのアップロードの詳細については、「Amazon S3へのオブジェクトのアップロード」を参照してください。

また、スタックの作成後に環境にアクセスするための信頼できる送信元IPアドレスまたはCIDRブロックと、インスタンスに関連付けるEC2キーペアを提供する必要があります。 EC2キーペアの作成については、「Amazon EC2を使用したキーペアの作成」を参照してください。また、信頼できるIPアドレスまたはCIDRブロックは、Kibanaアクセス用にAmazon ESアクセスポリシーの自動作成のために使用されます。すべてのIPv4アドレスがインスタンスにアクセスできるようにする0.0.0.0/0を使用するのではなく、特定のIPアドレスまたはCIDR範囲を使用することをお勧めします。インスタンスへのインバウンドトラフィックの認可の詳細については、「Linuxインスタンスのインバウンドトラフィックの認可」を参照してください。

入力パラメータを確認したら(詳細は次のスクリーンショットと表を参照)、CloudFormationスタックを作成します。

Input parameter インプット パラメータの説明
1. HIDSInstanceSize テストサーバーのEC2インスタンスサイズ
2. ESInstanceSize Amazon ESインスタンスのサイズ
3. MyKeyPair デプロイ後にインスタンスに安全に接続できる公開鍵/秘密鍵のペア
4. MyS3Bucket ZIP展開パッケージを使用したS3バケット
5. MyS3Key ZIP展開パッケージ用の領域内のS3キー
6. VPCId ソリューションを展開するAmazon VPC
7. SubnetId 選択したVPC内のアウトバウンド接続を持つサブネットID(インターネットアクセスが必要)
8. AssignPublicIP サブネットがインターネットゲートウェイ経由で接続するように設定されている場合はtrueに設定します。サブネットがNATゲートウェイ経由で接続するように設定されている場合はfalseに設定されます
9. MyTrustedNetwork EC2インスタンスおよびAmazon ESエンドポイントへのアクセスをホワイトリストに登録するために使用される信頼できるソースIPまたはCIDRブロック

CloudFormationスタックの作成を継続するには:

1. 入力パラメータを入力して、次へを選択します。
2. 「オプション」ページで、デフォルトを受け入れて「次へ」を選択します。
3. レビューページで詳細を確認し、AWS CloudFormationがIAMリソースを作成する可能性があることを確認します。チェックボックスをオンにし、作成を選択します。 (スタックは約10分で作成されます)。

スタックを作成したら、CloudFormation OutputsタブのHIDSESKibanaURLをメモしてください。そして次のKibanaの設定手順に進みます。

2.Kibanaのインデックスパターンを設定し、アラートの調査を開始
このセクションでは、Kibanaの初期セットアップを実行します。 Kibanaにアクセスするには、CloudFormationスタック出力(前のセクションを参照)でHIDSESKibanaURLを見つけて選択します。これにより、Amazon ESインスタンスに自動的にプロビジョニングされるKibanaインスタンスが表示されます。 CloudFormation入力パラメータで指定したソースIPを使用して、Amazon ESアクセスポリシーが自動的に設定されます。次のようなエラーが表示された場合は、Amazon ESのアクセスポリシーが正しいことを確認する必要があります。

{"Message":"User: anonymous is not authorized to perform: es:ESHttpGet on resource: hids-alerts"}

Amazon ESドメインへのアクセスを保護する方法の詳細については、「Amazon Elasticsearchサービスドメインへのアクセスを制御する方法」を参照してください。

OSSEC HIDSアラートは現在Amazon ESに処理されています。 Kibanaを使用してアラートデータをインタラクティブに分析するには、Amazon ESで分析するデータを識別するインデックスパターンを設定する必要があります。索引パターンに関する追加情報は、Kibanaのドキュメントを参照してください。
インデックス名またはパターン ボックスに「cwl-2017.*」と入力します。インデックスパターンは、ラムダ関数内でcwl-YYYY.MM.DDとして生成されるため、月と日のワイルドカード文字を使用して2017のデータと一致させることができます。Time-field nameドロップダウンリストから@timestamp を選択し作成します。


Kibanaでは、ディスカバーペインを選択して、作成されているアラートを表示できるようになりました。リアルタイムに近いアラートの表示のリフレッシュレートを設定するには、右上の時間範囲(Last 15 minutesなど)を選択します。

自動更新を選択し、5秒などの間隔を選択します。

Kibanaでは、設定した時間枠内で5秒間隔で自動更新するように設定する必要があります。次のスクリーンショットに示すように、アラートがカウントグラフとともに更新されるはずです。

EC2インスタンスはCloudFormationによって自動的に設定され、アクティビティをシミュレートして次のようないくつかのタイプのアラートを表示します。

  • 成功したsudoからROOT実行 :Linuxのsudoコマンドが正常に実行されました。
  • Webサーバー400のエラー・コード : サーバーは、クライアント エラー(形式が不適切な要求構文、サイズが大きすぎる、無効なリクエスト・メッセージ・フレーミング、不正なリクエスト・ルーティングなど)によりリクエストを処理できません。
  • SSHのセキュアでない接続試行(スキャン) : SSHリスナーへの無効な接続試行。
  • ログインセッションが開かれました : システムでログインセッションが開かれました。
  • ログインセッションが閉じられました : システムのログインセッションが閉じられました。
  • 新しいYumパッケージがインストールされています : パッケージがシステムにインストールされています。
  • Yumパッケージが削除されました : パッケージがシステムから削除されました。

次のスクリーンショットに示すように、いくつかのアラートフィールドを詳しく見ていきましょう。

上記番号付きアラートフィールド(スクリーンショット)は、次のように定義されています

1. @log_group – ソースとなるCloudWatch Logグループ
2. @log_stream – CloudWatchログのストリーム名(InstanceID)
3. @message – ソースalerts.jsonからのJSONペイロードOSSECログ
4. @owner – アラートが発生したAWSアカウントID
5. @timestamp – Lambda関数によって適用されるタイムスタンプ
6. full_log – ソースファイルからのログイベント
7. location – ソースログファイルのパスとファイル名
8. rule.comment – 一致したOSSECルールの簡単な説明
9. rule.level – 0から16までのOSSECルール分類(詳細は、ルール分類を参照)
10. rule.sidid – 一致したOSSECルールのルールID
11. srcip – アラートをトリガした送信元IPアドレス。この場合、シミュレートされたアラートにはサーバのローカルIPが含まれています

また、Kibanaクエリーバーに検索条件を入力して、HIDSアラートデータをインタラクティブに調べることができます。たとえば、次のクエリを実行すると、ソースIPが10.10.10.10であるEC2 InstanceID i-0e427a8594852eca2のすべてのrule.level 6アラートを表示できます。

“rule.level: 6 AND @log_stream: "i-0e427a8594852eca2" AND srcip: 10.10.10.10”

シンプルテキスト、Luceneクエリ構文、またはJSONベースのElasticsearch Query DSLを使用して検索を実行できます。データの検索に関する追加情報は、Elasticsearchのドキュメントを参照してください。

3. Kibana HIDSダッシュボードの設定、アラートを視覚化

アラートの傾向とパターンを時間の経過とともに分析するには、グラフとグラフを使用してアラートデータを表現すると便利です。私はKibanaインスタンスにインポートできる基本ダッシュボードテンプレートを設定しました。

KibanaインスタンスにサンプルのHIDSダッシュボードのテンプレートを追加するには:

1. テンプレートを ローカルに保存し、Kibanaナビゲーションペインで[管理]を選択します。
2. 保存オブジェクト、インポート、およびHIDSダッシュボードテンプレートを選択します。
3. HIDSアラートダッシュボードエントリの右側にある目のアイコンを選択します。インポートされたダッシュボードに移動します。

Kibanaダッシュボードテンプレートをインポートして選択すると、次のスクリーンショットに示すように、HIDSダッシュボードが表示されます。このサンプルHIDSダッシュボードには、アラートの時間、アラートの種類、ルールレベルの内訳、上位10のルールソースID、および上位10のソースIPが含まれています。

アラートデータを詳細に調べるには、次の2つのスクリーンショットに示すように、フィルタするアラートタイプを選択します。

ソースIPアドレスや時間範囲などの基準に基づいてアラートの詳細を表示できます。 Kibanaを使用してアラートデータを視覚化する方法の詳細については、「Kibanaユーザーガイド」を参照してください。

まとめ

このブログ記事では、CloudWatch Logs を使用してOSSEC HIDSからほぼリアルタイムでアラートを収集し、CloudWatch Logsサブスクリプションを使用して、Kibanaとの分析と可視化のためにアラートをAmazon ESに渡す方法を示しました。このソリューションによってデプロイされたダッシュボードは、AWS環境における防御の深いセキュリティ戦略の一環として、EC2のセキュリティ監視を改善するのに役立ちます。

このソリューションを使用して、EC2への攻撃、異常な活動、およびエラーの傾向を検出することができます。また、システムの修復作業の優先順位付けや、VPCセキュリティグループルールVPCネットワークACLAWS WAFルールなど、追加のセキュリティコントロールを導入する場所を決定するのに役立ちます。

この投稿に関するコメントがある場合は、下の「コメント」セクションに追加してください。このソリューションの実装に関する問題や問題がある場合は、CloudWatchまたはAmazon ESフォーラムで新しいスレッドでお知らせ下さい。このソリューションのソースコードはGitHubで入手できます。 OSSEC固有のサポートが必要な場合は、「OSSECサポートオプション」を参照してください。

– Cameron (翻訳はSA酒徳が担当しました。原文はこちら:How to Monitor Host-Based Intrusion Detection System Alerts on Amazon EC2 Instances)

AWS ホットスタートアップ – 2017 年 3 月

あわただしい 3 月が過ぎたので、バスケットボールのことは忘れて、Tina Barr が紹介する今月のクールなスタートアップに注目しましょう。-Ana


今月は春の到来にふさわしい新しいスタートアップ 5 社を紹介します。

  • Amino Apps – 数十万のコミュニティのソーシャルネットワークを提供します。
  • Appboy – ブランドの顧客関係を強化します。
  • Arterys – 医用イメージ産業を変革します。
  • Protenus – 医療組織の患者データを保護します。
  • Syapse – 標的がん治療に役立つ全国のデータを共有します。

2 月のホッとスタートアップをお見逃しの場合は、こちらをご覧ください。

Amino Apps (ニューヨーク州ニューヨーク)
Amino ロゴ
Amino Apps は、興味ベースのコミュニティが、特にモバイルの面で、未発達で時代遅れであるという認識に基づいて設立されました。CEO の Ben Anderson と CTO の Yin Wang は、特定のトピックを専門に扱う独立したソーシャルネットワークを数十万も集めて、これらのコミュニティへのアクセスをユーザーに提供するアプリを作成しました。そのうち、最大級のコミュニティは 100 万を超す会員を擁しており、人気の高い TV 番組、ビデオゲーム、スポーツ、その他さまざまな趣味や興味などのトピックに基づいて構築されています。Amino は、世界中のコミュニティをホストし、現在 6 か国語で利用可能であり、今後サポート言語の数は増える予定です。Amino アプリの操作は簡単です。アプリ (iOS または Android) をダウンロードして、有効な E メールアドレスでサインアップし、プロフィール写真を選択して使用を開始するだけです。ユーザーは、コミュニティを検索して、興味があるものに参加できます。各コミュニティには、チャットルーム、メルチメディアコンテンツ、クイズ、シームレスなコメントシステムがあります。コミュニティがまだ存在していない場合は、Amino Creator & Manager アプリ (ACM) を使用して数分で作成できます。ユーザーが作成した最大級のコミュニティは、独自のアプリに変換され、コミュニティごとに会員の電話番号用のスペースと、アプリストアでのスペースが提供されます。Amino の数十万のコミュニティのグローバルネットワークは AWS のサービスで運営されています。毎日のようにユーザーは数百のモバイルアプリケーション間でコンテンツの生成、共有、操作を行っています。AWS のサービスである Amazon EC2Amazon RDSAmazon S3Amazon SQSAmazon CloudFront などを活用することで、Amino は引き続きユーザー向けの新しい機能を提供し、サービスのキャパシティーをスケールしてユーザーの増大に対応できます。企業としての Amino に関心がある方は、こちらの採用情報のページを参照してください。

Appboy (ニューヨーク州ニューヨーク)
2011 年、Bill MagnusonJon Hyman、および Mark Ghermezian は、テクノロジーを介してブランドと顧客の関係を強化し、血の通った関係にするための独特な可能性に着目しました。3 人は、ブランドと顧客の長期的な関係を築くための Appboy を作成し、それが今ではマーケティング、グロース、エンゲージメントの各チームの代表的なライフサイクルエンゲージメントプラットフォームになっています。モバイルの急成長が不可避の状況で、既存のマーケティングクラウドからは魅力的でシームレスなクロスチャネルエクスペリエンスが得られないと、多くのブランドが不満を高めていることが明らかでした。今日の大手のモバイルアプリおよびエンタープライズ企業は、マーケティングを次のレベルに引き上げるプラットフォームとして Appboy に信頼を寄せています。Appboy は、毎月約 7 億のアクティブなユーザーのプロファイルを管理し、さまざまなチャネルおよびデバイスにまたがって毎月 100 億を超えるパーソナライズされたメッセージをやり取りしています。Appboy は、顧客ごとに単一のビューを提供する全体的なユーザープロファイルを作成します。そのユーザープロファイルが、クロスチャネルのメッセージング、ライフサイクルエンゲージメントの自動化、キャンペーンの深い洞察および最適化の機会をもたらします。Appboy が提供するソリューションを使用することで、ブランドは、プッシュ通知、対象者を絞った E メール、アプリ内/ブラウザ内メッセージ、ニュースフィードカード、および Webhook を作成して、ユーザーエクスペリエンスと顧客エンゲージメントを強化できます。同社が誇りとする相互運用性により、さまざまな無料のマーケティング用ツールやテクノロジーに接続可能であるため、ブランドは完璧なスタックを構築して戦略と実験をリアルタイムで実現できます。AWS を使用することで、Appboy はすべてのサービスコンポーネントを動的にサイジングし、必要に応じて自動的にスケールアップ/ダウンできます。Appboy では、Elastic Load BalancingAWS LambdaAmazon CloudWatchAuto Scaling グループ、Amazon S3 などのさまざまなサービスを使用して、顧客からの予測不能な負荷にもキャパシティーをスケールして効率的に対応できます。最新のマーケティングトレンドおよび戦術の情報を得るには、Appboy のデジタルマガジン、Relate をご覧ください。Appboy は、#StartupsOnAir ビデオシリーズにも最近の特集で取り上げられ、AWS の使用方法に関する洞察を提供しています。

Arterys (カリフォルニア州サンフランシスコ)
医師からテスト結果を回収するには、時間と労力を要する場合があります。通常、臨床医はさまざまな手法を駆使して手動で医療イメージを測定し、評価を下します。Arterys の創立者である Fabien BeckersJohn Axerio-CiliesAlbert Hsiao、および Shreyas Vasanawala は、医療イメージ、特に MRI や CT スキャナーで生成されたものの貴重な情報をすべて役立てるには、より多くの計算および先端分析技術が必要であることに気づきました。臨床医は、測定を省略して主に定性的データに基づいて評価を下すことが少なくありません。Arterys の創立者は、データ駆動の医学を推進することを主眼としたクラウド/AI ソフトウェア企業を創立し、先進的なソフトウェア製品を使用して医療イメージの後処理を行うことを考えました。Arterys の製品は、イメージを一貫して適時かつ正確に数量化し、より迅速に結果を出して、より質の高い情報を治療医に提供します。これにより、患者の状態が効率的に追跡され、治療に関する意思決定の質が向上します。イメージの処理には、深層学習や分散クラウドコンピューティングなどの先端分析機能が使用されます。Arterys の最初の製品では、エクスパートと同じように正確に心臓の解剖のコンタリングを行うことができます。しかも、手動では 45〜60 分を要する作業が 15〜20 秒しかかかりません。また、Arterys のコンピューティングクラウドプラットフォームは完全に HIPAA 対応です。Arterys は、医療イメージの処理にさまざまな AWS のサービスを使用しています。深層学習および先端分析ツールを使用することで、Arterys は AWS G2 インスタンスを使用してウェブブラウザでレイテンシーなしでイメージをレンダリングできます。推論、レンダリングなどのすべてのコンピューティングニーズには Amazon EC2 を広く利用し、すぐには必要ないイメージのアーカイブには Amazon S3 を使用してコストを管理しています。また、Arterys では Amazon Route 53AWS CloudTrailAmazon EC2 Container Service も利用しています。Arterys が生み出しているテクノロジーについては、こちらのクイックビデオをご覧ください。Arterys は、#StartupsOnAir ビデオシリーズでも最近の特集で取り上げられ、製品の簡単なデモを提供しています。

Protenus (メリーランド州ボルティモア)
Protenus ロゴ
Protenus の創立者である Nick Culbertson および Robert Lord は、ジョンズホプキンス医科大学の医学生であったときに、電子カルテ (EHR) システムが患者の治療の改善と臨床データの効率的な共有に役立つことを初めて知りました。ただし、効率の向上とともに、大きな課題が生まれました。セキュリティおよびプライバシー上の深刻な懸念です。過去 2 年間、1 億 4 千件のカルテが侵害されており、これはアメリカ人の約 3 人に 1 人のカルトが侵害された計算になります。カルテには、秘密情報が含まれており、そのデータが侵害されると、患者の人生に大損害をもたらす可能性があります。たとえば、身元詐称、処方詐欺、メディケア/メディケイド詐欺、不適切な治療などのリスクが生じます。インテリジェンスコミュニティでの以前のキャリアや大手のヘッジファンドに関わって得た経験と知識を活かして、Nick と Robert は、Protenus のプロトタイプとアルゴリズムを開発しました。現在、Potenus は、全国の医療組織における患者データの侵害や悪用を検出するためのいくつかのソリューションを提供しています。先端分析機能と AI を駆使することで、Protenus の健康データに関するインサイトプラットフォームでは、EHR での患者データの適切/不適切な使用が見分けられます。また、プライバシーを保護して HIPAA 規制の準拠を支援し、患者およびプロバイダーの信頼を得ることができます。Protenus は、Amazon EC2 上に SaaS サービスを構築して運営しており、保護医療情報の保存に関する HIPAA 規制に準拠するために Dedicated Hosts および暗号化された Amazon EBS ボリュームを使用しています。また、Elastic Load Balancing および Amazon Route 53 を DNS に使用し、Protenus インスタンスに対するクライアント別の安全なアクセスを提供しています。患者のデータに対する脅威の詳細については、Protenus ブログの「Hospitals’ Biggest Threat to Patient Data is Hiding in Plain Sight」を参照してください。製品の詳細については、#StartupsOnAir シリーズの最近のビデオをご覧ください。

Syapse (カリフォルニア州パロアルト)
Syapse は、臨床医が標的がん療法の精密医療を使用して患者を治療するための包括的なソフトウェアソリューションを提供します。この療法では、遺伝子または分子プロファイリングを使用して設計および選択された治療が行われます。既存の病院 IT は、大々的な精密医療を駆使して患者を治療するために必要な堅牢なインフラストラクチャや臨床ワークフローをサポートしていませんが、Syapse はポイントオブケアで臨床医への患者データを集中的に管理して整理することができます。Syapse が提供するがん専門医向けのさまざまなソリューションにより、専門医は長期的に患者データの全容にアクセスし、推奨される治療や類似患者の臨床試験を確認して、結果を経時的に追跡できます。これらのソリューションは、全国の医療システムががん患者に最も革新的な治療を提供して患者のアウトカムを向上させるのに役立っています。大手の医療システムである Stanford Health Care、Providence St. Joseph Health、Intermountain Healthcare などは、Syapse を使用して患者のアウトカムの向上、臨床ワークフローの合理化、精密医療プログラムのスケールを行っています。Molecular Tumor Board (MTB) と呼ばれる専門家グループは、複雑なケースを検討し、患者データやドキュメントノートを評価して、治療勧告書を治療医に配布しています。Syapse でも、医療システムのスタッフ向けに所属機関のがん治療に関するインサイトを報告書で提供しており、がん治療サービスラインの品質の向上、ビジネス目標、変動要因の理解に役立つと思われます。Syapse では、Amazon Virtual Private CloudAmazon EC2 ハードウェア専有インスタンス、Amazon Elastic Block Store を使用して高パフォーマンスで、スケーラブルな HIPAA 対応のデータプラットフォームを構築しています。これを利用することで、医療システムは、精密医療を全国のがん患者の日常治療の一環とすることができます。詳細については、Syapse ブログを参照してください。また、#StartupsOnAir ビデオシリーズで Syapse に関する最新のビデオもご覧ください。製品、HIPAA の準拠、AWS の詳しい利用方法などが紹介されています。今月も素晴らしいホットスタートアップをご覧いただき、ありがとうございました。

-Tina Barr

新しい AWS コミュニティヒーロー (2017 年春)

新しい AWS コミュニティヒーローをご紹介します。

AWS コミュニティヒーローは、さまざまな方法で AWS に関する知識を広め、情熱を伝えます。ソーシャルメディア、ブログ投稿、オープンソースプロジェクト、個人的なイベント、ユーザーグループ、ワークショップなど、あらゆる手段を駆使して AWS から得た洞察を共有します。


Mark Nunnikhoven
Mark Nunnikhoven
は、個人、組織、コミュニティへのテクノロジーの影響について、特にプライバシーとセキュリティの観点から検討しています。「情報の守りを固める方法」を求めて、サイバー犯罪について調査し、デジタル世界に対するリスクと脅威の理解を深めようとしています。Mark は、Trend Micro の Cloud Research 担当副社長であり、長年に渡るアマゾン ウェブ サービスのアドバンストテクノロジーパートナーおよび AWS クラウドのセキュリティツールのプロバイダーでもあります。これまでに培った知識に基づいて、AWS クラウドを活用してセキュリティ環境の最新化を図る世界中の組織をサポートしています。特に自動化に注目し、寄稿講演、指導、AWS コミュニティへの参加を通じて DevOps と従来のセキュリティの橋渡し役を務めています。

SangUk Park
SangUk Park は、Megazone のチーフソリューションアーキテクトです。Megazone は、2012 年に韓国初の AWS パートナーとなり、韓国で AWS サポートを提供する唯一の AWS プレミアコンサルティングパートナーです。SungUk は、KT のパブリッククラウドおよび VDI 設計のシステムアーキテクトを務め、YDオンラインおよびネクソンジャパン (大手オンラインゲーム会社の 1 つ) でシステムオペレーションを手掛けた経験があります。「AWS 認定ソリューションアーキテクト – プロフェッショナル」および「AWS DevOps エンジニア – プロフェッショナル」の両方の認定を受け、『DevOps and AWS Cloud Design Patterns』などの AWS 書籍の著述、AWS クラウドに関する 4 冊の本の翻訳も行っています。AWS 韓国ユーザーグループコミュニティのコーリーダーとして当コミュニティの活性化に努め、AWS 韓国ユーザーグループのミーティングや AWS サミットを開催するとともに、AWSKRUG 江南システムエンジニアなどの小グループの会合を支援しています。また、開発者やシステムエンジニアを育成するために、多数の実践ラボを実施し、AWS イベントでユーザーグループのリーダーとしてブースを運営しています。SangUk は、優れた日本語のコミュニケーションスキルと日本での経験を活かして、日本の AWS ユーザーグループ (JAWS UG) と密接な関係を維持しています。日本のユーザーグループと韓国のユーザーグループ間で開催されるイベントにはファシリテーターおよび通訳者として参加しており、今後 APAC を超えたリージョン間コミュニケーションを促進しようと尽力しています。

James Hall
James Hall は、デジタル分野での勤務歴が 10 年を超えます。人気が高い jsPDF ライブラリの作者であり、英国のデジタルエージェンシー、Parallax の創立者/取締役です。LED ビルボードから、車のロックを解除するアプリ、大規模なウェブアプリケーションやツールまで、さまざまなプロジェクトでソフトウェア開発者を務めました。Parallax では、API Gateway のリリース直後に、サーバーレステクノロジーを使用してダヴィッド・ゲッタおよび UEFA のオンライン動画スタジオを構築しました。それ以降、Parallax はさまざまなサーバーレスプロジェクトやテクノロジーに関するコンサルテーションを提供しています。同社は、リーズでの AWS ミートアップを運営し、オンラインのビジネス構築について世界中の企業をサポートしています。James は、Lambda および関連するサービス上にウェブアプリケーションを効率よく構築できるサーバーレスフレームワークについて貢献し、プロモートしています。

Drew Firment
Drew Firment は、クラウド導入を推進する組織のビジネスリーダーやテクノロジーチームに協力しています。急速に進むアジャイル環境での大規模なテクノロジープログラム、エンタープライズプラットフォーム、および文化的な変革を率いた経験が 20 年以上に及びます。Capital One で初期に導入された AWS を実働環境に移行させてから、クラウドコンピューティングへのスケーラブルでサステナブルな移行を推進することに集中するようになりました。Drew は、戦略、ガバナンス、エンジニアリング、アジリティ、教育を総合して企業全体の人材変革を促進する作業に先駆けて取り組みました。また、Capital One のクラウドエンジニアリングカレッジを創立し、学習コミュニティ向けの革新的な成果ベースのカリキュラムを導入しました。彼のクラウド習熟プログラムには数千人の社員が登録し、開始以来、AWS 認定数は 1,000 を超えています。彼自身は 3 つすべての AWS アソシエイトレベル認定を受けており、AWS Lambda を使用した Amazon Alexa スキルのカスタム開発を楽しみ、クラウドコンピューティングの将来はサーバーレスであると信じています。また、A Cloud Guru のアドバイザリーパートナーとして、コミュニティソースの出版物の編集長も務めています。

ようこそ
新しい AWS コミュニティヒーローを温かくお迎えください!

-Ana

S3 ストレージ管理アップデート – 分析、オブジェクトのタグ付け、インベントリ、メトリクス

本日、皆様がお持ちのストレージとそのアクセスパターンを詳しく知るための 4 つの S3 機能についてご説明したいと思います。何をどのくらい保管しているのか、どのように使用しているのかを知ることができ、その結果として、S3 ストレージクラスの使用に関する情報に基づいた意思決定を行うことができます。これらの機能は、バケットに何十万、何千、何百万、何十億というオブジェクトを持っていても、S3 を使用するすべての人にとって価値があります。

以下が概要です:

S3 分析 – オブジェクトの格納状況と取得パターンを分析し、その結果を使って、最適なストレージクラスを選択することができます。あなたは S3 コンソールで表示される分析の結果を検査したり、お好みの BI ツールにロードし深掘りしても良いでしょう。そうすることで、ストレージの利用傾向を見て、それらが使い方や成長度合いにどのように関連しているのかがつかめます。

S3 オブジェクトのタグ付け – 複数のキーと値のペア(タグ)をそれぞれの S3 オブジェクトに関連付けることができ、いつでも変更することができます。タグは、アクセスの管理と制御、S3 ライフサイクルポリシーの設定、S3 分析のカスタマイズ、CloudWatch メトリクスのフィルタリングに使用できます。バケットをデータレイクと考えることができ、タグを使用してそのデータレイクの中のオブジェクトの分類を作成できます。これは、バケットとプレフィックスを使用するよりも柔軟性があり、オブジェクトの名前を変更、移動、またはコピーせずに意味付けの変更を行うことができます。

S3 インベントリ – S3 インベントリを使用して、ビジネスワークフローやビッグデータのジョブを加速できます。この機能は、毎日または毎週の単位で、バケットの全部または一部の内容(プレフィックスによって識別される)の CSV 形式のフラットファイル表現を提供します。

S3 CloudWatch メトリクス – 13 種類の Amazon CloudWatch メトリクスを監視やアラームを設定することで、S3 を活用するアプリケーションのパフォーマンスを向上させる可能性があります。

詳細を見てみましょう。

S3 分析
S3 のユーザは、標準、標準 IA (標準低頻度アクセス)、Glacier と 3 つのストレージクラスを選択することができます。S3 のオブジェクトライフサイクル管理を使用して、オブジェクトが期限切れになるか、標準 IA もしくは Glacier に移行するかを指定することができます。

S3 分析機能は、オブジェクトについて、標準と標準 IA のどちらを選択したら良いのかの必要な情報を提供します。多くの顧客は、処理を容易にするために、複数の異なるタイプまたはカテゴリの情報を 1 つのバケットに格納するため、バケット内のオブジェクトのサブセット(共通のプレフィックスまたはタグ値によって定義)で分析を実行できます。各サブセットはフィルタによって定義されます。各バケットは最大 1,000 のフィルタを持つことができます。私の jbarr-public バケットのフィルタは次のとおりです:

プレフィックスが www で始まるオブジェクトを分析する簡単なフィルタを定義する方法は次のとおりです:

代わりにタグ名と値でフィルタリングすることができます。type という名前のタグに page という値を持つオブジェクトを分析する方法は次のとおりです:

各フィルタは、任意の好みの数のタグが付いた、多くとも1つのプレフィックスを指定することができます。分析内容を毎日ファイルにエクスポートすることもできます:

1 つ以上のフィルタが配置されると、分析は毎日実行され、フィルタをクリックするだけで分析を表示できます。たとえば、私の Archive と設定したフィルタをクリックすると、次のように表示されます:

この分析から、多くの良い情報が読み取れます!以下のようなことがわかります。

  • 127 日を振り返ってみると、30 日以上経過したオブジェクトのほとんどはアクセス頻度が低いことがわかります。私は、これらのオブジェクトを標準 IA のストレージに移行するライフサイクルルールを作成することで、コストを削減できます。
  • この時点で、私のストレージの大半(6.39 PB)は標準ストレージにあり、ほんの少しだけが標準 IA にあります(実のところ、私のバケットにはあまりデータがありませんでした。S3 チームは、私のアカウントにいくつかのテスト用メトリクスをロードしてくれました。非常に寛大です!)。
  • 127 日間の観測期間にわたって、標準ストレージの 16 %から 30 %くらいのデータが 1 日単位で、リトリーブされました。
  • 30 〜 45 日後、45 〜 60 日後、60 〜 90 日後、90 〜 180 日後、180 日以上後のオブジェクトは、まれにしかアクセスされず、標準 IA に配置するのに適しています。

ストレージクラス分析は、コンソール、CLI、または S3 API を使用して設定できます。

詳細は、Amazon S3 分析 – ストレージクラス分析 をご覧ください。

S3 オブジェクトのタグ付け
既存のロケーションベースの S3 オブジェクト管理モデル(バケットとプレフィックス)加えて、タグ付けは、そのオブジェクトは何か?という観点に基づいてストレージを管理する機能を提供してくれます。たとえば、部門の名前でオブジェクトをタグ付けし、そのタグに基づいてアクセスを許可する IAM ポリシーを構築することができます。これにより、単にタグを変更するだけで変更を反映させることができるなど、多くの柔軟性が得られます。

オブジェクトのライフサイクルのどの部分でも、それらを作成、更新、または削除することができます。タグは、IAM ポリシー、S3 ライフサイクルポリシー、および先ほど紹介した分析フィルタで参照できます。各オブジェクトは最大 10 個のタグを持つことができ、オブジェクトの各バージョンは異なるタグセットを持ちます。タグを利用して、ライフサイクルポリシーにてオブジェクトの有効期限を管理したり、特定のタグに関するアクティビティを反映する CloudWatch メトリクスを設定しても良いでしょう。

各オブジェクトのプロパティページには、現在のタグセットが表示され、それらのタグを編集できます:

また、CLI または S3 API からタグを設定してアクセスすることもできます。これら 2 つの方法のいずれかを使用する場合は、常に完全なタグセットの単位で設定する必要があります。たとえば、オブジェクトに 4 つのタグがあり、5 つ目のタグを追加する場合は、現在のセットを読み込み、新しいセットを追加してから、セット全体を更新する必要があります。

タグは、クロスリージョンレプリケーションを介してリージョン間で複製できますが、ソース側の IAM ポリシーでは s3:GetObjectVersionTagging 及び s3:ReplicateTags アクションを有効にする必要があります。

タグの費用は、10,000 個のタグにつき月額 0.01 ドルです。タグを追加または更新するリクエスト(それぞれ PUT および GET)は、通常の料金で課金されます。

詳細は、S3 オブジェクトのタグ付け を参照してください。

S3 インベントリ
S3 の LIST 操作は同期的で、一度に 1,000 個までのオブジェクトと、2 回目の LIST を開始するために使用するキーを返します。これは小規模から中規模のバケットやシングルスレッドのプログラムでは効果的ですが、大規模なバケットや複数のスレッドと組み合わせて使用するのは難しくなるかもしれません。

S3 インベントリを使用すると、バケットのインベントリレポートを毎日または毎週という形で受け取ることができます。プレフィックスを使用してレポートをフィルタリングしたり、サイズ、ストレージクラス、およびレプリケーションステータスなどをオプションのフィールドとして含めることができます。レポートは、ご自身のアカウントの S3 バケットに送信することも、適切な権限設定を使用して別のアカウントに送信することもできます。

以下は、www で始まるすべてのオブジェクトに対して、WebStuff という名前の、毎日のインベントリレポートをリクエストする方法の例です:

また、宛先のバケット(jbarr-s3-inventory)に書き込むための S3 権限を与える必要があります。使用したポリシーは次のとおりです(詳細は、Amazon S3 インベントリおよび Amazon S3 分析に対するアクセス権限の付与 を参照):

このインベントリのメカニズムは、マニフェスト、マニフェストのチェックサム、およびデータファイルの 3 つのファイルを作成します。マニフェストには、データファイルの場所とチェックサムが格納されています:

{
   "sourceBucket":"jbarr-public",
   "destinationBucket":"arn:aws:s3:::jbarr-s3-inventory",
   "version":"2016-11-30",
   "fileFormat":"CSV",
   "fileSchema":"Bucket, Key, Size, LastModifiedDate, ETag, StorageClass",
   "files":[
      {
         "key":"jbarr-public/DailyInventory/data/cf1da322-f52b-4c61-802a-b5c14f4f32e2.csv.gz",
         "size":2270,
         "MD5checksum":"be6d0eb3f9c4f497fe40658baa5a2e7c"
      }
   ]
}

解凍された後のデータファイルの外観は次のとおりです:

インベントリレポートを使用して毎日または毎週の処理ワークフローを強化する場合は、S3 通知機能の設定を忘れないでください!チェックサムファイルは他の 2 つのファイルの後に書かれていますので、安心して活用することができます。また、ライフサイクルポリシーを使用して、累積されていくインベントリファイルのコレクションを管理することを忘れないでください。

補足として、毎日または毎週のレポートを使用すると、複数の LIST 操作を何度も行うことと比較して最大 50 %節約できます。この機能の詳細については、Amazon S3 ストレージインベントリを参照してください。

S3 CloudWatch メトリクス
S3 は、ストレージ、リクエスト、およびデータ転送のメトリクスを CloudWatch に公開できるようになりました。ストレージメトリクスについては毎日レポートされ、追加料金なしで利用できます。リクエストとデータ転送のメトリクスは 1 分間隔で(処理待ち時間の後に)利用可能で、いつもの CloudWatch 課金レートで請求されます。 S3 分析の場合と同様に、CloudWatch メトリクスは、バケット全体でレポート化できますし、プレフィックスまたはタグを介して選択されたサブセットについて収集してレポート化することもできます。

メトリクスのフルセットは次のとおりです:

Storage Requests Data Transfer
  • Bucket Size Bytes
  • Number Of Objects
  • GET
  • LIST
  • PUT
  • POST
  • DELETE
  • ALL
  • HEAD
  • 4xx Errors
  • 5xx Errors
  • Total Request Latency
  • First Byte Latency
  • Bytes Uploaded
  • Bytes Downloaded

このメトリクス、S3 および CloudWatch コンソールで利用できます。私のバケットの S3 コンソールでの Total Request Latency の外観は次の通りです:

View in CloudWatch (CloudWatch で表示)をクリックし、任意のメトリックの CloudWatch アラームを設定することもできます。こちらは、私のバケットが 100 MB より大きくなった場合、通知を受けようと設定しているところです:

詳細は、S3 バケットにリクエストメトリクスを設定する方法 をご覧ください。

今すぐ利用可能
昨年末に、これらの機能にアクセスできるようになりました。アップデートされた S3 Console からアクセスできます。他にも多くの新機能が含まれています(詳しくは Introduction to the New Amazon S3 Console をご覧ください)。

– Jeff ; (原文:S3 Storage Management Update – Analytics, Object Tagging, Inventory, and Metrics / 翻訳: SA 焼尾)

 

Amazon CloudWatch がダッシュボードにアラームを追加

Amazon CloudWatch は、AWS のリソースに関するメトリックス、ログ、イベントをリアルタイムで提供および収集することで、アマゾン ウェブ サービスで実行しているアプリケーション、システム、ソリューションをモニタリングできるサービスです。CloudWatch では、リソースのレイテンシー、エラー発生率、CPU 使用率などの主要メトリックスが自動的に測定されます。さらにお客様から提供されたログやシステムデータに基づくカスタムメトリックスのモニタリングも可能です。昨年 11 月、Amazon CloudWatch に新しいダッシュボードウィジェットが追加され、すべてのメトリックスのデータを視覚化できるようになりました。CloudWatch に追加されたダッシュボードのアラームにより、お客様は AWS で実行しているソリューションやリソースの状態を把握しやすくなりました。このアラームの追加により、アラームとメトリックスを同じダッシュボードウィジェットで確認して、データに基づくトラブルシューティングと分析を行うことができます。

CloudWatch のダッシュボードは、複数のリージョンにまたがる AWS リソースを統合されたビューでモニタリングする際の可視性を高めるためのものです。CloudWatch のダッシュボードは高度にカスタマイズ可能であるため、ユーザーは独自のダッシュボードを作成して使用率、パフォーマンス、請求予定額、そして今回のアラーム状態など、さまざまなメトリックスのデータをグラフィカルに表示できます。アラームは、各メトリックスの値と指定したしきい値の関係を経時的に追跡します。アラームの状態が変わると、Auto Scaling ポリシーなどのアクションが実行されます。または、Amazon SNS に通知が送信されます。ダッシュボードにアラームを追加するという新たな方法により、CloudWatch のユーザーは、複数のリージョンにまたがって AWS のリソースやアプリケーションをモニタリングして事前にアラートを受け取る手段が増えました。さらに、ダッシュボードに追加されたアラームでは、メトリックスのデータをグラフで確認できます。アラームには次の 3 つの状態があります。

  • OK: アラームのメトリックス値はしきい値に達していない
  • INSUFFICIENT DATA: データ不足。最初にトリガされたアラームのメトリックス値は、データ不足のため、[OK] 状態か [ALARM] 状態か判定できない
  • ALARM: アラームのメトリックス値はしきい値に達している

ダッシュボードでは、[ALARM] 状態は赤、[INSUFFICIENT DATA] 状態はグレイ、[OK] 状態は無色で表示されます。ダッシュボードのアラームは、Line、Number、Stacked area の各ウィジェットで表示できます。

  • Number ウィジェット: 目的のメトリックスの最新の値をすばやく効率的に確認できます。最新のメトリックスデータに応じてアラームの状態が変わるたびに背景色が変わります。
  • Line ウィジェット: 選択したメトリックスのコレクションの実値を線グラフで表示します。ダッシュボードにアラームのしきい値と状態が水平線で示されます。この水平線を境に、しきい値に達しているかどうかが一目でわかります。
  • Stacked area ウィジェット: 選択したメトリックスのコレクションについて正味の合計結果をグラフで表示します。Stacked area ウィジェットは、メトリックスの上に別のメトリックスをロードして、メトリックスの分布と貢献度を示します。オプションとして、メトリックスの貢献度をパーセントで表示することもできます。アラームのしきい値と状態も水平線で表示されます。

現在、アラームに関連する複数のメトリックスを同じウィジェットに追加する作業が進行中です。この機能はお客様からのフィードバックに基づいて進化しています。

ダッシュボードにアラームを追加する CloudWatch
ダッシュボードでアラームを使用する方法を簡単に確認しましょう。AWS コンソールで、CloudWatch サービスに移動します。CloudWatch コンソールで、[Dashboards] を選択します。[Create dashboard] ボタンをクリックして CloudWatchBlog ダッシュボードを作成します。

CloudWatchBlog ダッシュボードを作成すると、このダッシュボードにウィジェットを追加するためのダイアログボックスが表示されます。ここでは、ウィジェットを追加する手順をスキップして、ダッシュボードにアラームを追加する手順に進むことにします。したがって、[Cancel] ボタンをクリックして、CloudWatch コンソールの [Alarms] セクションに進みます。

CloudWatch コンソールの [Alarms] セクションでは、現在のリージョンのすべてのアラームとその状態が一覧表示されます。

既に述べたように、アラームには 3 種類の状態があります。上に示したコンソールには、アラームごとに状態が表示されています。必要に応じて、コンソールのフィルタを使って状態の種類別にアラームを表示することもできます。たとえば、状態が [ALARM] のアラームだけを確認するとします。この場合は、現在のリージョンで状態が [ALARM] のアラームをフィルタで絞り込みます。

これで、現在の状態が [ALARM] になっている 2 つのアラームだけが表示されます。1 つは、Amazon DynamoDB テーブルのプロビジョニングされた書き込みキャパシティーユニットをモニタリングするためのものであり、別の 1 つは、アクティブな Amazon Elasticsearch インスタンスの CPU 使用率をモニタリングするためのものです。

CloudWatchBlog ダッシュボードをトラブルシューティング手段として利用し、Elasticsearch ソリューションとそのインスタンスの問題を特定して診断するシナリオを検討してみましょう。まず、Amazon Elasticsearch の CPU 使用率のアラームとして [ES Alarm] を [CloudWatchBlog] ダッシュボードに追加します。アラームを追加するには、目的のアラーム (この例では [ES Alarm]) の横にあるチェックボックスを選択します。次に、アラームを選択した状態で、[Add to Dashboard] ボタンをクリックします。

表示された [Add to dashboard] ダイアログボックスで、CloudWatchBlog ダッシュボードを選択できます。ここで、アラームを表示するウィジェットの種類を選択することもできます。ES Alarm を Line ウィジェットで表示することにし、[Add to dashboard] ボタンをクリックして、このアラームをダッシュボードに追加します。

[ES Alarm] が [CloudWatchBlog] ダッシュボードに正常に追加されると、確認メッセージが CloudWatch コンソールに表示されます。

コンソールの [Dashboards] セクションに移動して [CloudWatchBlog] ダッシュボードを選択すると、[ES Alarm] アラームの Line ウィジェットがダッシュボードに表示されます。[ES Alarm] ウィジェットをダッシュボードの一部として保存するには、[Save dashboard] ボタンをクリックして、このウィジェットのダッシュボードへの追加を確定します。

既に説明したように、CloudWatch ダッシュボードを使用する利点の 1 つは、さまざまなリージョンからの複数のアラームをダッシュボードに追加できることです。この例では、ダッシュボードを Elasticsearch ソリューションのトラブルシューティング手段として利用しているので、このソリューションに関連するいくつかのアラームとメトリックスを [CloudWatchBlog] ダッシュボードに表示することにします。そのため、Elasticsearch インスタンス用に別のアラームを作成してダッシュボードに追加します。まず、コンソールの [Alarms] セクションに戻り、[Create Alarm] ボタンをクリックします。

[Create Alarm] ダイアログボックスが開いて、このリージョンで現在利用可能なすべてのメトリックスが表示されます。メトリックスの要約で、Elasticsearch のために 21 のメトリックスが追跡中であることを簡単に確認できます。[ES Metrics] リンクをクリックして、アラームの作成に使用できる各メトリックスを表示します。

Elasticsearch インスタンスのために表示された個別のメトリックスの中から、新しいアラームを関連付けるメトリックスを選択します。[WriteLatency] メトリックスを使うことにして、このメトリックスの横にあるチェックボックスを選択して [Next] ボタンをクリックします。

次の画面で、アラームの詳細として、名前、説明、アラームのしきい値、時間、アラームのアクションを入力します。新しいアラームの名前を ES Latency Alarm とし、他の残りのフィールドにも入力します。[Create Alarm] ボタンをクリックして、新しいアラームの作成を終了します。

アラームの追加が正常に終了すると、Alarms コンソールの上部に確認メッセージボックスが表示され、新しく作成したアラームの状態がアラームリストに表示されます。

次に、[ES Latency Alarm] を [CloudWatchBlog] ダッシュボードに追加します。アラームの横にあるチェックボックスを選択して [Add to Dashboard] ボタンをクリックします。

[Add to Dashboard] ダイアログボックスが開いたら、今回は [Stacked area] ウィジェットを選択します。このウィジェットを使用して [ES Latency Alarm] を [CloudWatchBlog] ダッシュボードに表示します。[Add to Dashboard] ボタンをクリックして、[ES Latency Alarm] ウィジェットをダッシュボードに追加します。

コンソールに戻ると、ウィジェットが正常に追加されたことを確認するメッセージが表示されます。[Dashboards] セクションで [CloudWatchBlog] ダッシュボードをクリックすると、ダッシュボードに 2 つのウィジェットが表示されます。このウィジェットをダッシュボードに保存するには、[Save dashboard] ボタンをクリックします。

最後に、CloudWatch の新しい機能であるダッシュボードのアラームでは、他のリージョンのアラームやメトリックスをダッシュボードに追加して全体をトラブルシューティングの対象にすることができます。アラームウィジェットを使ってダッシュボードにメトリックスを追加してみましょう。コンソール内で、現在のリージョンである米国東部 (オハイオ) から、米国東部 (バージニア北部) リージョンに移動します。

CloudWatch コンソールの [Metrics] セクションに進みます。このセクションに、米国東部 (バージニア北部) リージョンで使用されるサービスのメトリックスが表示されます。

Elasticsearch ソリューションは、Lambda 関数をトリガーして EmployeeInfo DynamoDB データベースの CRUD (作成、読み込み、更新、削除) のすべての変更を DynamoDB ストリーム経由でキャプチャし、それらの変更を Elasticsearch ドメインである taratestdomain 内に書き込みます。したがって、DynamoDB のテーブルメトリックスを追跡するためにメトリックスを [CloudWatchBlog] ダッシュボードに追加します。

そこで、[EmployeeInfo] データベースの [ProvisionedWriteCapacityUnits] メトリックスを [CloudWatchBlog] ダッシュボードに追加します。

[Add to Dashboard] ダイアログで、[CloudWatchBlog] ダッシュボードを選択し、このメトリックスを [Number] ウィジェットで表示することを選択します。

これで、米国東部 (バージニア北部) の [ProvisionedWriteCapacityUnits] メトリックスが [CloudWatchBlog] ダッシュボードに追加され、その Number ウィジェットが米国東部 (オハイオ) のアラームと一緒にダッシュボードに表示されます。この更新をダッシュボードに保存するには、もうおわかりだと思いますが、[Save dashboard] ボタンをクリックします。

 

まとめ
ダッシュボードの開始方法は簡単です。アラームを前もってモニタリングする新たな手段としてリージョンをまたいでダッシュボードのアラームを使用し、トラブルシューティング計画を策定して、目的のメトリックスを確認できます。また、最初にメトリックス UI でメトリックスを選択し、次にメトリックスの視覚化に適したウィジェットの種類に変更することもできます。ダッシュボードのアラームは、Line、Stacked area、Number の各ウィジェットで表示できます。さらに、ダッシュボードでアラームと並んでいる Text ウィジェットを使用して、アラームの状態の変更を処理する方法に関するステップや所見を追加することもできます。

Amazon CloudWatch のウィジェットおよびその他のダッシュボードのウィジェットの詳細については、Amazon CloudWatch ドキュメントおよび CloudWatch の「開始方法」を参照してください。

Tara

新機能 – AWS リソースのタグ付け API

AWS のお客様は、Amazon EC2 インスタンスAmazon EBS ボリュームAmazon S3 バケットなどのリソースを整理するためにタグをよく利用します。過去 2 年間、AWS ではタグ付けをより便利で強力なものにするために努めてきました。たとえば、Auto Scaling 時のタグ付け、リソースあたり最大 50 個のタグの使用、コンソールで作成する、共通のタグを共有するリソース (リソースグループとも呼ばれます)、タグの使用を強制する Config ルールを使用するオプションなど、さまざまな機能のサポートが追加されています。お客様は、何千というリソースを管理し、各リソースで最大 50 個ものタグを使用するようになると、タグ付けの作業を簡素化するためのツールやオプションが必要になります。この度、新しいリソースのタグ付け API が利用可能になりました。新しい API は、AWS SDKs または AWS Command Line Interface (CLI) から使用できます。これまでは AWS Management Console からのみアクセス可能であったリソースグループの同じオペレーションにプログラムからアクセスできるようになりました。

概要: コンソールベースのリソースグループのオペレーション
新しい API 関数について詳しく説明する前に、コンソールベースのグループ化およびタグ付けモデルを確認しておきましょう。複数のリージョンにまたがる検索機能を使用して AWS リソースを見つけてタグを付ける機能は、すでに利用できるようになっています。たとえば、次のようにリージョンの長いリストを選択して、各リージョンの EC2 インスタンスを検索できます。

すべての必要なリソースを見つけて選択したら、[Create a new tag key] をクリックして必要なタグキーを入力して、新しいタグキーを追加できます。

次に、各インスタンスの値を入力します (新しい [ProjectCode] 列)。

これで、P100 のタグが付いたすべてのリソースを含むリソースグループを作成できます。

リソースグループを作成したら、[Resource Groups] メニューをクリックしてすべてのリソースを見つけることができます。

この機能の詳細については、「Resource Groups and Tagging for AWS」を参照してください。

新しい、リソースのタグ付け API
今回発表された API を使用すると、リソースのタグ付け、タグ解除、タグを使用したリソースの検索のすべてをユーザーのコードから行うことができます。新しい API 関数を使うと、単一の関数セットで複数のリソースタイプを操作できるようになります。新しい関数は以下のとおりです。

TagResources – 最大 20 個のリソースにタグを一度に追加します。

UntagResources – 最大 20 個のリソースからタグを一度に削除します。

GetResources – リソースのリストを取得します。オプションとして、タグとリソースタイプのいずれかまたは両方でリソースをフィルタできます。

GetTagKeys – アカウントで使用されているすべての一意なタグキーのリストを取得します。

GetTagValues – 指定したタグキーのすべてのタグ値を取得します。これらの関数は、以下の AWS のサービスおよびリソースタイプをサポートしています。

AWS のサービス リソースタイプ
Amazon CloudFront ディストリビューション。
Amazon EC2 AMI、カスタマーゲートウェイ、DHCP オプション、EBS ボリューム、インスタンス、インターネットゲートウェイ、ネットワーク ACL、ネットワークインターフェイス、リザーブドインスタンス、リザーブドインスタンスのリスト、ルートテーブル、セキュリティグループ – EC2 Classic、セキュリティグループ – VPC、スナップショット、スポットバッチ、スポットインスタンスリクエスト、スポットインスタンス、サブネット、仮想プライベートゲートウェイ、VPC、VPN 接続。
Amazon ElastiCache クラスター、スナップショット。
Amazon Elastic File System ファイルシステム。
Amazon Elasticsearch Service ドメイン。
Amazon EMR クラスター。
Amazon Glacier ボールト。
Amazon Inspector 評価。
Amazon Kinesis ストリーム。
Amazon Machine Learning バッチ予測、データソース、評価、ML モデル。
Amazon Redshift クラスター。
Amazon Relational Database Service DB Instance、DB オプショングループ、DB パラメータグループ、DB セキュリティグループ、DB スナップショット、DB サブネットグループ、イベントサブスクリプション、リードレプリカ、リザーブド DB インスタンス。
Amazon Route 53 ドメイン、ヘルスチェック、ホストゾーン。
Amazon S3 バケット。
Amazon WorkSpaces WorkSpace。
AWS Certificate Manager 証明書。
AWS CloudHSM HSM。
AWS Directory Service ディレクトリ。
AWS Storage Gateway ゲートウェイ、仮想テープ、ボリューム。
Elastic Load Balancing ロードバランサー、ターゲットグループ

 

主要事項
以下は、新しい API 関数または同等の CLI コマンドを使用するコードの構築やスクリプトの記述を行う際の留意事項です。

互換性 – 古いサービス固有の関数は利用可能であり、引き続き使用できます。

書き込み権限 – 新しいタグ付け API は、AWS のサービス別の固有な既存ポリシーに別の権限を追加します。たとえば、EC2 インスタンスにタグを追加するには、 tag:tagResourcesEC2:createTags へのアクセス権が必要です。

読み取り権限 – タグとタグ値にアクセスする関数を呼び出すには、 tag:GetResourcestag:GetTagKeys、および tag:GetTagValues へのアクセス権が必要です。

料金 – これらの関数やタグの使用に伴う課金はありません。

今すぐ利用可能
新しい関数は最新バージョンの AWS SDKs でサポートされています。新しい関数を使用して、すべての商用の AWS リージョンでリソースにタグを付けて利用できます。

Jeff;

AWS のサイトですか?AWS Lambda を使用したドメインの識別

以下のゲスト投稿で、私の同僚である Tim Bray は IsItOnAWS.com を構築した方法について説明しています。このサイトは、AWS の IP アドレスレンジのリストと Tim が記述した Lambda 関数を使用して、お気に入りのウェブサイトが AWS で実行されているかどうかを調べることを目的としています。

Jeff;


AWS のサイトですか?
クリスマスの時期に遊び半分でプログラミングをしていたら、おもしろい Lambda 関数ができました。きっと気に入ってもらえると思います。指定したドメイン名 (または IP アドレス) (IPv6 でも可能) が、公表されている AWS IP アドレスレンジ に含まれているかどうかを調べてくれます。IsItOnAWS.com で実際に試してみることができます。構築の過程では、1 つの Lambda 関数で別の Lambda 関数を作成しています。JSON 形式の IPv4 および IPv6 CIDR で提供されているレンジのリストはここです。説明書はここで、Jeff Barr のブログ もあります。以下は、JSON 形式の IP レンジの例です。

{
  "syncToken": "1486776130",
  "createDate": "2017-02-11-01-22-10",
  "prefixes": [
    {
      "ip_prefix": "13.32.0.0/15",
      "region": "GLOBAL",
      "service": "AMAZON"
    },
    ...
  "ipv6_prefixes": [
    {
      "ipv6_prefix": "2400:6500:0:7000::/56",
      "region": "ap-southeast-1",
      "service": "AMAZON"
    },

これを見た瞬間、「IsItOnAWS.com ができるのではないか」と思いました。可能だと分かったので、これを構築しました。以下のようなサイトにしたいと思いました。

  1. サーバーレス (クールな人たちはみんなそうしているので)
  2. シンプル (数字の範囲の中で数値を調べるというシンプルな課題なので)
  3. 高速。当然ですよね。

データベースか否か
構築はとても明快に思えました。IP レンジを表にまとめ、アドレスを調べるということです。テーブルはどこに配置すればいいでしょうか。Amazon DynamoDB にしようかと思いましたが、実質的に数値のレンジから検索するのは明快ではありませんでした。明快な所で SQL データベースも考えましたが、上記の 2 番目に当てはまりません。Redis やそれに似た方法を考えましたが、インスタンスのプロビジョンが必要で、上記の 1 番目に当てはまりません。数日間この問題を考え続けて行き詰ってしまいました。その時、1 つの疑問が浮かびました。レンジのリストはどれほど大きいのだろう。エントリの数は 1000 未満であることが分かりました。そうであれば、そもそもデータベースは必要ないのではないでしょうか。JSON を配列して、バイナリサーチすることにします。そうすると、配列はどこにすればいいでしょうか。Amazon S3 なら簡単でしょう。でも、上記の 3 番目を見てください。S3 は高速ですが、すべてのリクエストのループにそれが必要でしょうか。それで、配列リテラルとしてレンジを含む小さなファイルを生成し、それを IsItOnAWS Lambda 関数自体の中に含めることにしました。この方法だと、IP アドレスが変更されるたびに関数を再構築してアップロードする必要があります。アドレスを気にするのであれば、Amazon Simple Notification Service (SNS) トピックへの受信登録をし、変更されるたびに通知が届くようにできます (最近の私の経験によると、週に 1、2 回の頻度です)。そして、サブスクリプションを Lambda 関数に結び付けておきます。これで、だれもが必要とする道具をそろえることができたと感じました。

Lambda 関数は 2 つあります。1 つめは、 newranges.js で、変更通知を取得し、IP レンジのデータから JavaScript を生成し、2 つめの Lambda 関数である isitonaws.js へアップロードします。これには JavaScript が含まれています。注意深い読者の方は、これはすべて Node ランタイムに関係するとお分かりでしょう。典型的な async または waterfall である新しいレンジ関数は、当初思っていたよりはやや複雑です。

Postmodern IP アドレス
最初のタスクは IP レンジの取得で、直接的な HTTP GET です。その後、JSON をより検索しやすい形にします。当然ですが、IPv4 と IPv6 の両方のレンジがあります。作業を容易にするため、単純な文字列や数字のマッチングで検索できる 1 つの配列にまとめようと思いました。IPv6 アドレスは JavaScript の数値で扱うには大きすぎるので、文字列にする必要があります。IPv4 のスペースが IPv6 の ("::ffff:0:0/96") に組み込まれている方法はやや驚きでした。BMP マッピングが低ビットの Unicode に組み込まれているようなものだと思っていました。このような方法になっているのはなぜかと漠然と考えはしましたが、調査はしていません。すべての CIDR をクラッシュして整然とした検索可能な配列にするコードは煩雑になりましたが、目的は達成できます。

Lambda の中に Lambda を構築する
次に、実際に IsItOnAWS リクエストを扱う Lambda を構築します。zip ファイルである必要があり、NPM に作成に必要なツールがあります。後は、圧縮されたバイトを S3 に詰め込んでアップロードすれば、新しい Lambda 関数を作成できます。鋭い方はお気づきでしょうが、いったん zip を作成すれば、直接 Lambda にアップロードできます。フローを精錬するために後で生成された「レンジ」データ構造をダウンロードして確認したかったので、S3 を中間のステップとして使用しました。実際の IsItOnAWS ランタイムは、名前でアドレスを探すために DNS を「たたく」ことと、レンジ配列に使用したのと同じ形式にするために多少工夫すること以外は、かなりシンプルです。HTML テンプレートの作成などはせず、zip の中のファイルを読み込み、表示されない <div> があれば、それを結果に置き換えただけです。ただ、バイナリサーチの手法をコードにする必要はありました。10 年に 1 度あるかないかの作業でしたが、楽しくできました。

ピースをまとめる
すべてのコードを実行できるようになったら、Amazon API Gateway を使用して世界につなげてみたくなりました。以前これを実行したときは複雑な作業でしたが、今回は「プロキシリソースを通じて Lambda プロキシと統合された API を作成する」を参照していたので、比較的単純で予想外の事態はほとんど生じないと思えました。ただ、その説明は主に API の構築 (例:JSON in/out など) についてで、実際の使用例にはあまり触れられていません。実際に HTML を人に送信してブラウザに読み込ませる方法などは書かれていませんでしたが、その方法を考えるのは難しくありませんでした。以下はその方法です (Node より)。

context.succeed({
  "statusCode": 200,
  "headers": { "Content-type": "text/html" },
  "body": "<html>Your HTML Here</html>"
});

一度すべてを API Gateway に接続できたら、最後のステップは isitonaws.com をそこに向かわせることです。そのため、このコードを記述したのは 12 月から 1 月にかけてでしたが、ブログにまとめるのは今になっています。当時は、Amazon Certificate Manager (ACM) 証明書は API Gateway で使用できませんでした。そして、時は 2017 年になり、証明書を承認して接続するのに古い学校の式典のようなことをする暇はありません。ACM により、証明書のプロセスはまったく思考を要しないものになっています。ACM と Let’s Encrypt が世に出たおかげで、今や非 HTTPS サイトを作成する理由は何もなくなりました。両方ともすばらしいツールですが、私のように API Gateway や CloudFront など AWS のサービスを使用している方であれば、ACM のほうがなじみやすいでしょう。自動更新もされる点は、きっと気に入るはずです。それで今や、ドメイン名を HTTPS と CloudFront 経由で API Gateway API に接続するのはとても簡単にできます。「API Gateway API のホスト名としてカスタムドメイン名を使用する」を参照してください。初めて試して、私の場合はうまくいきましたが、注意点があります (2017 年 3 月時点の話ですが)。最後のステップで ACM 証明書を API に接続する時、数分間、接続のために待機しなければなりませんが、これは普通のことです。幸い、私はあまり気にしていなかったため、あせって更新やキャンセルその他の操作はしませんでしたが、もしそうしていたら問題が生じていたかもしれません。ところで、API Gateway を使用する副次的な効果として、CloudFront を通してすべて実行されます。そのため、データベースを使わないので、高速な処理を期待できます。実際、ここバンクーバーでの話ですが、処理は高速に行われています。速度を計測する必要がないほど高速です。「IP レンジの変更」 SNS トピックに E メールで受信登録もしているので、変更があれば随時 E メールが送信されます。私はその通知を見てうれしくなります。自分の Lambda が新しい Lambda を記述して、すべてが自動で、手を煩わされずに、スムーズかつ高速に行われていると分かるからです。

Tim Bray シニアプリンシパルエンジニア

AWS グローバルサミット近日開催!

AWS ブログチームに参加して最初にしたことの 1 つは、ニューヨーク市で昨年 8 月に開催されたサミットへの出席でした。お客様すべてにお会いし、Game Day を見て、AWS コミュニティの活気を肌で感じ、これから Jeff と一緒にブログを書いていく中で経験するであろうことが一層楽しみになりました。今年の AWS サミットの日程が発表されました。クラウド分野に新しい人も長年のユーザーも、AWS サミットでは常に新しい発見があります。これは世界中で開催される無料のイベントで、AWS プラットフォームに一層慣れ親しんでもらうことを目的としています。幅広いトピックをカバーし、より深い技術を習得できるよう、数多くの学習の機会を提供するプログラムを作成しました。参加すると、AWS のインフラストラクチャおよびアプリケーションの設計、デプロイ、運用に必要なスキルを開発できます。サミットは、北米、南米、アジアパシフィック、欧州、中東、日本、中華圏の各地で開催されます。開催都市と日付の詳細なリストについては、AWS サミットのページを参照してください。現在、サンフランシスコ、シドニー、シンガポール、クアラルンプール、ソウル、マニラ、バンコクの 6 つの都市で登録を受付中です。AWS イベント RSS フィードの受信登録や @awscloud のフォロー、また Facebook ページもご覧ください。サミットでは様々な新しいことを学べるだけでなく、私や Jeff に会場でばったり出会い、ブログステッカーを手に入れられるかもしれません。

-Ana