Author: AWS Japan Staff


AWSと.NET Core 2.0

昨日、.NET Core 2.0がリリースされ(訳注:このブログ記事の原文は2017/8/15に発行されています)、AWSでは .NET Coreプラットフォームに追加された新機能と完成度にとても興奮しています。今後数か月以内に、AWSサービスをアップデートして、.NET Core 2.0のファーストクラスのサポートを提供します。 2つの簡単な方法ですぐにAWS上で.NET Core 2.0を使い始めることができます。

 

AWS Elastic Beanstalkの利用

Elastic Beanstalkを使用すると、Webアプリケーションを簡単に展開できます。現在、.NET Frameworkおよび.NET Core 1.1がサポートされています。 Elastic Beanstalkプラットフォームは、すぐに.NET Core 2.0をサポートするように更新されるでしょう。 それまではデプロイメントパッケージをカスタマイズして、デプロイ中のインスタンスに.NET Core 2.0をインストールするようにBeanstalkに指示することができます。

ASP.NET CoreアプリケーションがBeanstalkにデプロイされると、AWS-windows-deployment-manifest.jsonというJSONマニフェストがツールキットによって作成され、Beanstalkにアプリケーションのデプロイ方法を指示します。 以前のブログ記事では、このマニフェストのカスタマイズ方法について説明しました。 この機能を使用して、デプロイ前にPowerShellスクリプトを実行して.NET Core 2.0をインストールすることができます。

最初のステップとして、ASP.NET Core 2.0プロジェクトにaws-windows-deployment-manifest.jsonというファイルを追加します。 aws-windows-deployment-manifest.jsonのプロパティウィンドウで、[Copy to Output Directory]フィールドを必ず[Copy Always]に設定してください。 このファイルは、通常、ツールキットによって生成されますが、ツールキットがファイルがすでに存在することが判明した場合は、代わりにデプロイメントウィザードで指定された設定で既存のファイルを変更します。

 

次に、下の内容をコピーしてaws-windows-deployment-manifest.jsonに貼り付けます。 これはASP.NET Coreアプリケーションをデプロイし、デプロイの前に./Scripts/installnetcore20.ps1 PowerShellスクリプトを実行することを示しています。

 

{
  "manifestVersion": 1,
  "deployments": {

    "aspNetCoreWeb": [
      {
        "name": "app",
        "parameters": {
          "appBundle": ".",
          "iisPath": "/",
          "iisWebSite": "Default Web Site"
        },
        "scripts": {
          "preInstall": {
            "file": "./Scripts/installnetcore20.ps1"
          }
        }
      }
    ]
  }
}

PowerShellスクリプトを追加するためのマニフェストを追加しました。 ASP.NET Coreプロジェクトに./Scripts/installnetcore20.ps1ファイルを追加します。 再度、[Copy to Output Directory]フィールドを[Copy Always]に設定して、デプロイメントパッケージに追加されていることを確認してください。 以下のスクリプトは、.NET Core 2.0インストーラをダウンロードし、インストーラを実行します。

 

$localPath = 'C:\dotnet-sdk-2.0.0-win-x64.exe'

if(!(Test-Path $localPath))
{
    Invoke-WebRequest -Uri 'https://download.microsoft.com/download/0/F/D/0FD852A4-7EA1-4E2A-983A-0484AC19B92C/dotnet-sdk-2.0.0-win-x64.exe' -OutFile $localPath
    & $localPath /quiet /log c:\InstallNetCore20.log
}

 

このスクリプトでは、Microsoftの公式リンクから.NET Core 2.0をダウンロードしています。 デプロイ中のダウンロードを高速化し、リンクの変更の影響を受けないようにするために、.NET Core 2.0インストレーションをElastic Beanstalk環境と同じリージョンにあるAmazon S3バケットにコピーすることをお勧めします。

デプロイメントマニフェストのカスタマイズにより、ASP .NET Core 2.0アプリケーションをElastic Beanstalkに簡単にデプロイできます。

 

Dockerベース サービスの利用

Amazon EC2 Container ServiceやAWS CodeBuildなどのDockerコンテナを実行するDockerベースのサービスについては、Docker Hubに発行されたDockerイメージを使用してすぐに開始できます。 たとえばコンソールでAWS CodeBuildプロジェクトを設定するときに、Docker HubからカスタムのDockerイメージを指定することができます。

 


.NET Core Dockerイメージの詳細については、GitHubリポジトリを参照してください。 AWSでDockerコンテナを実行する方法の詳細については、「Amazon ECS入門」を参照してください。

 

AWS SDK for .NET

.NET Core 2.0は.NET Standard 2.0をサポートしています。つまり、.NET Standard 2.0とそれ以下を対象とするNuGetパッケージは.NET Core 2.0でサポートされています。 AWS SDK for .NETは.NET Standard 1.3をターゲットとしています。このことはつまり、.NET Core 1.xまたは.NET Core 2.0の両方で利用できることを意味しています。

 

結論

.NET Core 2.0とAWSについて最新の情報を入手するには、AWS .NET開発ブログをフォローし、Twitterで私たちのツイートを見つけてください

 
(日本語翻訳はSA 福井が担当しました。原文はこちらです。)

AWS CodePipelineを利用したネストされたAWS CloudFormationスタックの継続的デリバリー

CodePipeline の更新 – CloudFormation スタックの継続的デリバリーワークフローの構築で、 Jeff BarrはInfrastructure as Codeについてと、AWS CodePipelineを継続的デリバリーに使用する方法について説明しています。 本ブログ記事では、ソースリポジトリとしてAWS CodeCommitを、ビルドおよびテストツールとしてAWS CodeBuildを使用した、AWS CodePipelineを使ったネストされたCloudFormationスタックの継続的デリバリーについて説明します。手動承認プロセスに従ってCloudFormationチェンジセットを使用してスタックをデプロイします。

AWS CodePipelineでは、次の4つのステージでパイプラインを作成します。

  • Source (AWS CodeCommit)
  • Build and Test (AWS CodeBuild および AWS CloudFormation)
  • Staging (AWS CloudFormation および 手動承認)
  • Production (AWS CloudFormation および 手動承認)

次の図に、パイプラインのステージと、各ステージのアクション、およびステージ間の遷移を示します。

CloudFormationテンプレート、テストスクリプト、およびビルドスペックファイルは、AWS CodeCommitリポジトリに格納されています。これらのファイルは、AWS CodePipelineのパイプラインのSourceステージで使用されます。

AWS::CloudFormation::Stackリソースタイプは、親スタックから子スタックを作成するために使用されます。 CloudFormationスタックリソースでは、S3バケットに格納される子スタックのテンプレートを必要とします。テンプレートファイルの場所は、リソース定義のPropertiesセクションにURLとして指定されます。

次のテンプレートは、3つの子スタックを作成します。

  • Security (IAM, セキュリティグループ)
  • Database (RDSインスタンス)
  • Web stacks (Auto ScalingグループのEC2インスタンス, ELB)

Description: Master stack which creates all required nested stacks

Parameters:
  TemplatePath:
    Type: String
    Description: S3Bucket Path where the templates are stored
  VPCID:
    Type: "AWS::EC2::VPC::Id"
    Description: Enter a valid VPC Id
  PrivateSubnet1:
    Type: "AWS::EC2::Subnet::Id"
    Description: Enter a valid SubnetId of private subnet in AZ1
  PrivateSubnet2:
    Type: "AWS::EC2::Subnet::Id"
    Description: Enter a valid SubnetId of private subnet in AZ2
  PublicSubnet1:
    Type: "AWS::EC2::Subnet::Id"
    Description: Enter a valid SubnetId of public subnet in AZ1
  PublicSubnet2:
    Type: "AWS::EC2::Subnet::Id"
    Description: Enter a valid SubnetId of public subnet in AZ2
  S3BucketName:
    Type: String
    Description: Name of the S3 bucket to allow access to the Web Server IAM Role.
  KeyPair:
    Type: "AWS::EC2::KeyPair::KeyName"
    Description: Enter a valid KeyPair Name
  AMIId:
    Type: "AWS::EC2::Image::Id"
    Description: Enter a valid AMI ID to launch the instance
  WebInstanceType:
    Type: String
    Description: Enter one of the possible instance type for web server
    AllowedValues:
      - t2.large
      - m4.large
      - m4.xlarge
      - c4.large
  WebMinSize:
    Type: String
    Description: Minimum number of instances in auto scaling group
  WebMaxSize:
    Type: String
    Description: Maximum number of instances in auto scaling group
  DBSubnetGroup:
    Type: String
    Description: Enter a valid DB Subnet Group
  DBUsername:
    Type: String
    Description: Enter a valid Database master username
    MinLength: 1
    MaxLength: 16
    AllowedPattern: "[a-zA-Z][a-zA-Z0-9]*"
  DBPassword:
    Type: String
    Description: Enter a valid Database master password
    NoEcho: true
    MinLength: 1
    MaxLength: 41
    AllowedPattern: "[a-zA-Z0-9]*"
  DBInstanceType:
    Type: String
    Description: Enter one of the possible instance type for database
    AllowedValues:
      - db.t2.micro
      - db.t2.small
      - db.t2.medium
      - db.t2.large
  Environment:
    Type: String
    Description: Select the appropriate environment
    AllowedValues:
      - dev
      - test
      - uat
      - prod

Resources:
  SecurityStack:
    Type: "AWS::CloudFormation::Stack"
    Properties:
      TemplateURL:
        Fn::Sub: "https://s3.amazonaws.com/${TemplatePath}/security-stack.yml"
      Parameters:
        S3BucketName:
          Ref: S3BucketName
        VPCID:
          Ref: VPCID
        Environment:
          Ref: Environment
      Tags:
        - Key: Name
          Value: SecurityStack

  DatabaseStack:
    Type: "AWS::CloudFormation::Stack"
    Properties:
      TemplateURL:
        Fn::Sub: "https://s3.amazonaws.com/${TemplatePath}/database-stack.yml"
      Parameters:
        DBSubnetGroup:
          Ref: DBSubnetGroup
        DBUsername:
          Ref: DBUsername
        DBPassword:
          Ref: DBPassword
        DBServerSecurityGroup:
          Fn::GetAtt: SecurityStack.Outputs.DBServerSG
        DBInstanceType:
          Ref: DBInstanceType
        Environment:
          Ref: Environment
      Tags:
        - Key: Name
          Value:   DatabaseStack

  ServerStack:
    Type: "AWS::CloudFormation::Stack"
    Properties:
      TemplateURL:
        Fn::Sub: "https://s3.amazonaws.com/${TemplatePath}/server-stack.yml"
      Parameters:
        VPCID:
          Ref: VPCID
        PrivateSubnet1:
          Ref: PrivateSubnet1
        PrivateSubnet2:
          Ref: PrivateSubnet2
        PublicSubnet1:
          Ref: PublicSubnet1
        PublicSubnet2:
          Ref: PublicSubnet2
        KeyPair:
          Ref: KeyPair
        AMIId:
          Ref: AMIId
        WebSG:
          Fn::GetAtt: SecurityStack.Outputs.WebSG
        ELBSG:
          Fn::GetAtt: SecurityStack.Outputs.ELBSG
        DBClientSG:
          Fn::GetAtt: SecurityStack.Outputs.DBClientSG
        WebIAMProfile:
          Fn::GetAtt: SecurityStack.Outputs.WebIAMProfile
        WebInstanceType:
          Ref: WebInstanceType
        WebMinSize:
          Ref: WebMinSize
        WebMaxSize:
          Ref: WebMaxSize
        Environment:
          Ref: Environment
      Tags:
        - Key: Name
          Value: ServerStack

Outputs:
  WebELBURL:
    Description: "URL endpoint of web ELB"
    Value:
      Fn::GetAtt: ServerStack.Outputs.WebELBURL

Validateステージでは、AWS CodeBuildはAWS CodeCommitソースリポジトリの変更をチェックします。 ValidateTemplate APIを使用してCloudFormationテンプレートを検証し、子テンプレートと設定ファイルをS3バケットの適切な場所にコピーします。

次のAWS CodeBuildビルドスペックでは、TEMPLATE_FILES環境変数にリストされているCloudFormationテンプレートが検証され、AWS CodeBuildプロジェクトの環境変数TEMPLATE_BUCKETに指定されたS3バケットにコピーされます。 オプションとして、TEMPLATE_PREFIX環境変数を使用して、バケット内のパスを指定することもできます。これにより、構成ファイルの子テンプレートファイルの場所が更新されます。テンプレートファイルの場所は、親スタックのパラメータとして渡されます。

version: 0.1

environment_variables:
  plaintext:
    CHILD_TEMPLATES: |
      security-stack.yml
      server-stack.yml
      database-stack.yml
    TEMPLATE_FILES: |
      master-stack.yml
      security-stack.yml
      server-stack.yml
      database-stack.yml
    CONFIG_FILES: |
      config-prod.json
      config-test.json
      config-uat.json

phases:
  install:
    commands:
      npm install jsonlint -g
  pre_build:
    commands:
      - echo "Validating CFN templates"
      - |
        for cfn_template in $TEMPLATE_FILES; do
          echo "Validating CloudFormation template file $cfn_template"
          aws cloudformation validate-template --template-body file://$cfn_template
        done
      - |
        for conf in $CONFIG_FILES; do
          echo "Validating CFN parameters config file $conf"
          jsonlint -q $conf
        done
  build:
    commands:
      - echo "Copying child stack templates to S3"
      - |
        for child_template in $CHILD_TEMPLATES; do
          if [ "X$TEMPLATE_PREFIX" = "X" ]; then
            aws s3 cp "$child_template" "s3://$TEMPLATE_BUCKET/$child_template"
          else
            aws s3 cp "$child_template" "s3://$TEMPLATE_BUCKET/$TEMPLATE_PREFIX/$child_template"
          fi
        done
      - echo "Updating template configurtion files to use the appropriate values"
      - |
        for conf in $CONFIG_FILES; do
          if [ "X$TEMPLATE_PREFIX" = "X" ]; then
            echo "Replacing \"TEMPLATE_PATH_PLACEHOLDER\" for \"$TEMPLATE_BUCKET\" in $conf"
            sed -i -e "s/TEMPLATE_PATH_PLACEHOLDER/$TEMPLATE_BUCKET/" $conf
          else
            echo "Replacing \"TEMPLATE_PATH_PLACEHOLDER\" for \"$TEMPLATE_BUCKET/$TEMPLATE_PREFIX\" in $conf"
            sed -i -e "s/TEMPLATE_PATH_PLACEHOLDER/$TEMPLATE_BUCKET\/$TEMPLATE_PREFIX/" $conf
          fi
        done

artifacts:
  files:
    - master-stack.yml
    - config-*.json

テンプレートファイルがS3にコピーされると、CloudFormationはテストスタックを作成し、テストアクションとしてAWS CodeBuildをトリガーします。

AWS CodeBuildのビルドスペックでは、ネストされたCloudFormationスタックを使用して作成されたリソースが、CONFIG_FILEで指定された仕様に準拠しているかどうかをチェックするためのPythonスクリプト、validate-env.pyが実行されます。

version: 0.1

environment_variables:
  plaintext:
    CONFIG_FILE: env-details.yml

phases:
  install:
    commands:
      - pip install --upgrade pip
      - pip install boto3 --upgrade
      - pip install pyyaml --upgrade
      - pip install yamllint --upgrade
  pre_build:
    commands:
      - echo "Validating config file $CONFIG_FILE"
      - yamllint $CONFIG_FILE
  build:
    commands:
      - echo "Validating resources..."
      - python validate-env.py
      - exit $?

テストアクションが正常に完了すると、CloudFormationはテストスタックを削除し、パイプラインのUAT(訳者注:User Acceptance Test/ユーザ受け入れテスト)ステージに進みます。

このステージでは、CloudFormationはUATスタックに対して変更セットを作成し、変更セットを実行します。これにより、UAT環境が更新され、受け入れテストが可能になります。プロセスは手動承認アクションに進みます。 QAチームがUAT環境を検証して承認をおこなった後、プロセスはパイプラインのProductionステージに移行します。

このステージでは、CloudFormationはネストされた本番スタックの変更セットを作成し、プロセスは手動承認ステップに進みます。(通常は指定されたエグゼクティブによって)承認されると、変更セットが実行され、Productionデプロイメントが完了します。
 

継続的デリバリーパイプラインの設定

 
CloudFormationテンプレートを使用して、継続的デリバリーパイプラインを設定します。 GitHubから入手できるcodepipeline-cfn-codebuild.ymlテンプレートは、フル機能のパイプラインを設定します。

このテンプレートを使用してパイプラインを作成するときは、次の項目を指定します。

  • AWS CodeCommitリポジトリ
  • 承認通知を送信するSNSトピック
  • アーティファクトが格納されるS3バケット名

CFNTemplateRepoNameには、CloudFormationテンプレート、設定ファイル、およびビルドスペックファイルが格納されているAWS CodeCommitリポジトリを指定します。

私のリポジトリには以下のファイルが含まれています:

継続的デリバリーパイプラインは、Create Stackをクリックするとすぐに配備されます。作成後、パイプラインは各ステージを実行します。 UATおよびProductionステージの手動承認により、パイプラインは継続的デリバリーを可能にします。


 

ネストされたスタックの変更の実装

 
ネストしたスタック内の子スタックを変更するには(たとえば、パラメータ値を更新する、またはリソースを追加または変更するなど)、親スタックを更新します。変更は適切なテンプレートファイルまたは設定ファイルで行い、AWS CodeCommitリポジトリにチェックインする必要があります。これにより、次のデプロイプロセスがトリガーされます:

 

まとめ

 
この記事では、AWS CodePipeline、AWS CloudFormation、AWS CodeBuild、および手動承認プロセスを使用して、Infrastructure as Codeとアプリケーションデプロイメントの両方で継続的デリバリーパイプラインを作成する方法を示しました。

AWS CodePipelineの詳細については、AWS CodePipelineのドキュメントを参照してください。数回のクリックで始めることができます。 すべてのCloudFormationテンプレート、AWS CodeBuildビルドスペックファイル、および検証を実行するPythonスクリプトは、codepipeline-nested-cfn GitHubリポジトリに公開しています。


著者紹介

 
Prakash PalanisamyはAmazon Web ServicesのSolutions Architectです。 Serverless、DevOps、Alexaを担当する他、Project Eulerでの問題解決をおこなっています。彼はまた、教育ドキュメンタリーを見て楽しんでいます。

(翻訳はSA千葉が担当しました。原文はこちら)

AWS SAM Local(ベータ版) – サーバーレスアプリケーションをローカルに構築してテストする

今回、新ツール、SAM Local のベータ版がリリースされました。これにより、簡単にサーバーレスアプリケーションをローカルに構築してテストできるようになります。この記事では、SAM Local を使用し、クイックアプリケーションの構築、デバッグ、デプロイを実行します。これにより、エンドポイントに curl コマンドを使用してタブやスペースで投票できるようになります。AWS は サーバーレスアプリケーションモデル(SAM)を昨年導入しました。これにより、デベロッパーはサーバーレスアプリケーションをより簡単にデプロイできるようになっています。SAM の基本にまだなじみがない場合は、私の同僚である Orr が SAM の使用方法について書いた素晴らしい記事を参照してください。5 分ほどで読めます。基本的に、SAM は AWS CloudFormation 上に構築された強力なオープンソース仕様で、サーバーレスインフラストラクチャをコードとして簡単に保持できるようにすることを目的としています。また、可愛いマスコットもついてきます。

SAM Localでは、SAM の優れた点をすべてローカルマシンで利用できます。

  • 以下を使って、AWS Lambda 関数をローカルに開発してテストすることができます。 sam local Docker
  • Amazon Simple Storage Service(S3)Amazon DynamoDBAmazon KinesisAmazon Simple Notification Service(SNS)など、既知のイベントソースからの関数の呼び出しをシミュレートできます。
  • SAM テンプレートからローカルな Amazon API Gateway を開始し、ホットリロードで関数を素早く繰り返すことができます。
  • SAM テンプレートを素早く検証し、さらに、その検証を linters や IDE で統合できます。
  • Lambda 関数についてインタラクティブなデバッグサポートを利用できます。

SAM Local のインストール方法はいくつかありますが、NPM を使用するのが一番簡単です。 npm install -g aws-sam-local で素早く入手できます。また、ソースから直接インストールすれば確実に最新バージョンを入手できます。 go get github.com/awslabs/aws-sam-local (「sam」ではなく、「aws-sam-local」という名前でバイナリが作成されます)

それでは、簡単な SAM アプリケーションを書き込んでスペースやタブでの投票を行ってみましょう。非常にシンプルな、しかし強力なアーキテクチャ、API GatewayLambda 関数を使用し、結果を DynamoDB に保存します。最後は API に curl を実行できる必要があります。 curl https://SOMEURL/ -d '{"vote": "spaces"}' そして投票数を取得します。

以下に、シンプルな SAM template.yaml を示します。

AWSTemplateFormatVersion : '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  VotesTable:
    Type: "AWS::Serverless::SimpleTable"
  VoteSpacesTabs:
    Type: "AWS::Serverless::Function"
    Properties:
      Runtime: python3.6
      Handler: lambda_function.lambda_handler
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref VotesTable
      Events:
        Vote:
          Type: Api
          Properties:
            Path: /
            Method: post

Lambda 関数に公開する [dynamo_i] テーブルを作成します。環境変数の TABLE_NAME を使用します。

このテンプレートの有効性をテストするため、 sam validate を呼び出してタイプミスがないことを確認します。返ってくるのは、 「Valid」です。 Lambda 関数の作業に進みます。

import os
import os
import json
import boto3
votes_table = boto3.resource('dynamodb').Table(os.getenv('TABLE_NAME'))

def lambda_handler(event, context):
    print(event)
    if event['httpMethod'] == 'GET':
        resp = votes_table.scan()
        return {'body': json.dumps({item['id']: int(item['votes']) for item in resp['Items']})}
    elif event['httpMethod'] == 'POST':
        try:
            body = json.loads(event['body'])
        except:
            return {'statusCode': 400, 'body': 'malformed json input'}
        if 'vote' not in body:
            return {'statusCode': 400, 'body': 'missing vote in request body'}
        if body['vote'] not in ['spaces', 'tabs']:
            return {'statusCode': 400, 'body': 'vote value must be "spaces" or "tabs"'}

        resp = votes_table.update_item(
            Key={'id': body['vote']},
            UpdateExpression='ADD votes :incr',
            ExpressionAttributeValues={':incr': 1},
            ReturnValues='ALL_NEW'
        )
        return {'body': "{} now has {} votes".format(body['vote'], resp['Attributes']['votes'])}

これをローカルにテストします。通信のために実際に DynamoDB データベースを作成し、このデータベースに名前を設定する必要があります。環境変数の TABLE_NAME を使用します。これには env.json ファイルを使用します。コマンドラインでパスすることもできます。最初に以下を呼び出します。
$ echo '{"httpMethod": "POST", "body": "{\"vote\": \"spaces\"}"}' |\
TABLE_NAME="vote-spaces-tabs" sam local invoke "VoteSpacesTabs"

これで Lambda をテストします。スペースの投票数が返されるので、理論的にすべて問題なく機能していることがわかります。すべてをタイプするのは手間なので、 sam local generate-event api でサンプルイベントを作成してローカル呼び出しにパスします。API をローカルに実行するだけなので非常に簡単です。実際に sam local start-api でやってみましょう。これでローカルエンドポイントに curl を実行し、すべてをテストできるようになりました。
次のコマンドを実行します。 $ curl -d '{"vote": "tabs"}' http://127.0.0.1:3000/ 「tabs now has 12 votes」(タブの現在の投票数:12)と返ってきます。当然ながら、この関数は最初から完璧に書けたわけではありません。何度か編集と保存を繰り返しました。ホットリロードの利点の1つに、関数を変更しても新しい関数をテストするための追加作業が必要ないことが挙げられます。これにより、開発における反復作業が大幅に削減されます。

ネットワークを介して実際の DynamoDB データベースにアクセスすることを避けたい状況を考えてみましょう。どのような選択肢があるでしょうか?たとえば、DynamoDB Local をダウンロードして起動することができます。それには java -Djava.library.path= を使用します。/DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb 次に、Lambda 関数で AWS_SAM_LOCAL 環境変数を使用し、動作についての決定を行います。関数を少し変更してみましょう。

import os
import json
import boto3
if os.getenv("AWS_SAM_LOCAL"):
    votes_table = boto3.resource(
        'dynamodb',
        endpoint_url="http://docker.for.mac.localhost:8000/"
    ).Table("spaces-tabs-votes")
else:
    votes_table = boto3.resource('dynamodb').Table(os.getenv('TABLE_NAME'))

これでローカルエンドポイントがローカルデータベースに接続され、WiFi なしで簡単に作業できるようになります。

SAM Local はさらに、インタラクティブデバッグもサポートしています。Java や Node.js では、 -d フラグやポートをパスしてデバッガーをすぐに有効化できます。Python では、 import epdb; epdb.serve() などのライブラリを使用して接続できます。その後は、 sam local invoke -d 8080 "VoteSpacesTabs" を呼び出すことで、関数は実行を停止し、デバッガーの手順が完了するのを待機します。

これですべて機能するようになります。さっそくデプロイしましょう!

最初に sam package コマンドを呼び出します。これは aws cloudformation package のエイリアスです。このコマンドの結果を sam deploy に使用します。

$ sam package --template-file template.yaml --s3-bucket MYAWESOMEBUCKET --output-template-file package.yaml
Uploading to 144e47a4a08f8338faae894afe7563c3  90570 / 90570.0  (100.00%)
Successfully packaged artifacts and wrote output template to file package.yaml.
Execute the following command to deploy the packaged template
aws cloudformation deploy --template-file package.yaml --stack-name 
$ sam deploy --template-file package.yaml --stack-name VoteForSpaces --capabilities CAPABILITY_IAM
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - VoteForSpaces

これで API に以下が出てきます。

これで本稼働ステージに移り、投票が多い場合にはレート制限を追加します。ローカルで作業してクラウドに簡単にデプロイすることもできます。1度目のデプロイで問題なく機能したときは本当にいい気分です。

これで、投票して結果をライブで見ることができます。http://spaces-or-tabs.s3-website-us-east-1.amazonaws.com/

SAM Local により、サーバーレスアプリケーションのテスト、デバッグ、デプロイが簡単になることを願っています。CONTRIBUTING.md ガイドを用意しています。是非プルリクエストを送信してください。構築が終わった際には是非ツイートでお知らせください。最新情報の記事やドキュメントはこちらで確認できます。

Randall

AWS Summit ニューヨーク – 発表の概要

なんとも忙しい 1 週間でした。TaraRandallAna と私は、AWS Summit ニューヨークでの発表に関するブログ投稿を休みなく作成していました。手始めにその概要をご紹介しておきます。

Amazon Macie – この新しいサービスは、コンテンツを大規模に検出、分類、セキュリティ保護するうえで役立ちます。Macie は Machine Learning と自然言語処理 (NLP) を使用してパターンを検索し、疑わしい動作について警告します。また、ガバナンス、コンプライアンス、および監査に役立ちます。Tara の投稿をお読みになれば、Macie の使用方法をおわかりいただけます。つまり、対象のバケットを選択し、分類設定をカスタマイズして、Macie Dashboard で結果を確認します。

AWS GlueRandall の投稿 (豪華なアニメーション GIF 付き) では、この新しい ETL (抽出、変換、ロード) サービスについて紹介しています。Glue はサーバーレスでフルマネージド型です。投稿からおわかりのように、Glue はお客様のデータをクロールし、スキーマを推測して、Python で ETL スクリプトを生成します。お客様は、幅広い変換で場所から場所へデータを移動するジョブを定義し、それぞれをコードで表して人間が読み取れる形式で保存します。Glue は開発エンドポイントとノートブックを使用して、ビルドするスクリプトのテスト環境を提供します。また、Amazon Athena と Amazon Glue の統合や、Amazon EMR での Apache Spark および Hive についても発表しました。

AWS Migration Hub – この新しいサービスは、アプリケーションポートフォリオの AWS への移行を支援します。私の投稿で、主要なステップと、Migration Hub で移行作業を迅速化、追跡、簡略化する方法について説明しています。検出ステップから始めるか、直接移行を開始できます。Migration Hub は移行パートナーのツールと統合し、Server Migration Service および Database Migration Service 上に構築されます。

CloudHSM UpdateAWS CloudHSM の主要なアップグレードを行い、より多くのお客様がハードウェアベースのキー管理の利点を活用できるようにしました。このサービスは従量制で提供され、完全マネージド型です。これはオープンで標準に準拠しており、複数の API、プログラミング言語、暗号の拡張をサポートしています。CloudHSM は AWS の重要な部分であり、AWS マネジメントコンソールAWS コマンドラインインターフェイス (CLI)、および API コールからアクセスできます。詳細については、私の投稿をお読みになり、CloudHSM クラスターのセットアップ方法を参照してください。

S3 バケットをセキュリティ保護するための管理ルール – S3 バケットのセキュリティ保護に役立つ 2 つの新しいルールを AWS Config に追加しました。s3-bucket-public-write-prohibited ルールはパブリック書き込みアクセス許可を持っているバケットを識別し、s3-bucket-public-read-prohibited ルールはグローバル読み取りアクセス許可を持っているバケットを識別します。私の投稿で述べたように、これらのルールは設定変更に応じて、または定期的に実行できます。ルールでは、AWS に関する自動化された公式推論を使用する大きな取り組みの一環として、最先端の制約解決テクニックのいくつかを使用します。

すべてのお客様のための CloudTrail – Tara の投稿では、AWS CloudTrail が AWS のすべてのお客様が利用できるようになり、デフォルトで有効になることをお知らせしました。ボーナスとして、Tara は CloudTrail の主要な利点を確認し、イベント履歴の確認方法と、1 つのイベントの詳細を調べる方法を説明しました。また、CloudWatch イベントで使用する 2 番目の証跡を作成する方法も説明しました。

EFS 用の保管時のデータの暗号化 – 新しいファイルシステムを作成するときに、ファイルシステムでファイルのコンテンツを暗号化するために使用されるキーを選択するオプションが提供されました。暗号化は、業界標準の AES-256 アルゴリズムを使用して実行されます。私の投稿で、キーを選択し、それが使用中のキーであることを確認する方法を説明しています。

Jeff;

オートメーションを活用したCloudEndureによるAWSへの容易な移行

Carmen PuccioとMandus Mombergによる記事。 CarmenとMandusは、AWSパートナーソリューションアーキテクトで、移行に注力しています。

オンプレミス環境からクラウドへのソフトウェアやサービスの移行は、独自の考慮事項と要件を伴うことは明らかです。移行結果に自信を持たせるには、容易に拡張できる移行戦略が必要です。つまり、ワークフローの大部分を自動化する必要があります。なぜクラウド内の自動化が重要であるのかに関する文書が不足しているわけではありません。この記事では、AWSアドバンスト・テクノロジーパートナーであるCloudEndureを使用して自動化された移行を実行する方法を説明し、自動化されたテストを組み込むことに重点を置いて、アプリケーションが移行後に期待どおりに動作することを確信できます。

オンプレミスからAWSへのワークロードの移行には、慎重な計画と正確な実行が必要です。クラウドに移行するにはさまざまな戦略がありますが、移行を容易にするツールも数多くあります。すべての移行ツールは、ダウンタイムとアプリケーションワークロードの影響を最小限に抑え、AWSへの移行を容易にし、データ損失を最小限に抑える、という共通の目標を持っています。

ワークロードをクラウドにすばやく移動したい場合、通常リホスト方式(リフト&シフト)に従います。リホスト実行時の課題の1つは、移行されたアプリケーションが期待どおりに実行されていることを手動で確認するのにかかる時間です。適切な移行を検証するための自動化および迅速なテストパイプラインを組み込んだ移行は、成功する可能性が高いだけでなく、反復可能なプロセスを活用し、手動検証時間を短縮することで効率を向上させます。

ソリューションの概要

このブログ記事で説明するソリューションでは、CloudEndureAWS Database Migration Service(AWS DMS)を使用し、ソースAmazon VPCから目的のAmazon VPCへ、オンプレミスからAWSへの、Go Gitサービス(Gogs)の移行について説明します。このデモのために2つの異なるVPCを使用していますが、このブログポストで使用しているツールの自動化と組合せによって、オンプレミスからAWSへの移行を容易に実現することができます。CentOS 7が稼働するモックソース環境の設定では、AWS CloudFormationAnsibleの組合せを選択しましたので、あなたのテスト用AWS環境でご確認することができます。

CloudEndureはアプリケーションサーバの移行を担当し、AWS DMSはEC2インスタンス上で実行されているMySQLサーバからGogs DBを、完全に管理されたAmazon RDSデータベースに再構築する役目を負います。このデモンストレーションのためDMSを活用し、RDSへのデータベースのレプリケート方法を示しました。もう1つの選択肢として、データベース移行において、CloudEndureによるEC2へのリホストを行うことができます。

CloudEndureは起動時に、移行後のインスタンスでカスタム後処理スクリプトを呼び出す機能があります。この機能を使用すると、カスタム構成を実行し、自動化された承認テストを実行して、移行されたサーバでアプリケーションが正常に動作していることを確認できます。

移行の信頼性のため、AWS Lambda、AWS SNS、AWS SQS、CloudEndureの後処理機能を活用して、一連のテストを実行するための自動テストパイプラインを構築しています。すべてのテストが正常に完了すると、ソース環境から構築されたイメージを使用して高可用性Gogs環境をデプロイするAWS CloudFormationテンプレートが自動的に起動されます。

次の図は、この記事で取り上げる移行プロセスを示しています。

プロセスの仕組みは次のとおりです。

  1. Ansibleは、AWS Application Discovery Service、CloudEndureエージェント、およびGogsソースサーバの再設定およびテストに使用されるスクリプトをインストールします。
  2. AWS DMSは、GogsソースDBサーバを宛先RDSインスタンスに移行します。
  3. CloudEndureエージェントが実行されると、ブロックレベルのコピーが開始され、GogsソースサーバとAWSの初期同期が実行されます。
  4. CloudEndureが初期同期を完了すると、Continuous Data Protection(CDP)エンジンは新しいデータのリアルタイム同期を開始し、サーバはAWSでのテスト準備完了としてマークされます。 CloudEndure.pyスクリプトはconfig.ymlファイルのhosttomigrate変数に基づいて移行を開始します。 (この変数は、CloudEndureダッシュボードにインスタンス名として表示されます)。
  5. CloudEndure.pyスクリプトはCloudEndure APIを呼び出し、ソースインスタンスの最新のスナップショットからテストインスタンスを開始します。
  6. CloudEndureは、最新のスナップショットから宛先に新しいインスタンスを起動し、CloudEndure.shポストプロビジョニングスクリプトを実行します。このスクリプトは次の処理を行います。
    1. DMSが複製しているRDSインスタンスを指すようにGogsを再構成し、Gogsサービスを再起動します。
    2. Gogsサービスが稼動しているかどうかを確認します。稼働している場合、CloudEndure.shポストプロビジョニングスクリプトはCloudEndure_PostProcessing.pyスクリプトを呼び出します。このスクリプトはCloudEndure Pass / Fail SNSトピックに成功通知を送信します。メッセージの例は次のようになります。

      "Message": "{"instanceId": " i-0bb669daff4b1eea1","Pass": "True"}"

    3. CloudEndure Lambda関数は、CloudEndure Pass / Fail SNSトピックに登録されています。ラムダ関数は成功メッセージを探します。成功メッセージを受信すると、着信インスタンスIDに基づいてAmazon Machine Image(AMI)を作成し、AMI情報をAmazon SQSに送信します。 CloudWatchでLambda関数のステータスを追跡できます:
  7. CloudEndure.pyスクリプトは、移行されたインスタンスに関するメッセージをSQSキューに常にポーリングします。メッセージを受信すると、AMIが準備完了であるかどうかを確認します。準備ができたら、スクリプトはGogs CloudFormationテンプレートを起動し、AMI IDをパラメータとして渡します。 CloudFormationテンプレートは、次のような高可用性環境を展開します;

始めましょう

移行プロセスの仕組みが分かりましたので始めてみましょう。まず、CloudEndureでアカウントを設定する必要があります。アカウントをお持ちでない場合は、AWS SaaSサブスクリプションマーケットプレイスのCloudEndure Migration製品ページで登録できます。[1]

アカウントを設定し、CloudEndureのウェブサイトのスタートガイドに従ったら、以下のファイルに慣れておく必要があります。完全な解決策はGitHub上でより詳細に説明されています。

Ansibleプレイブック、変数、ファイル:

  • playbooks/files/CloudEndure.sh  – このファイルはCloudEndureが移行後のスクリプトを実行する/ boot/ce_conversionにデプロイされます。 GogがRDSを指すように再構成し、サービスをテストするために使用されます。
    • reinvent-ent312-source-instances.yml CloudFormationテンプレートは、このファイルのすべてのent312.five0.ninja
      を、Auto Scalingを使用して高可用性のGogs環境用のELBロードバランサを指し示すAmazon Route 53ドメインエイリアスに置き換えます。この値は、CloudFormationテンプレートのGogsDNSパラメータを介してテンプレートに渡されます。
  • playbooks/cloudendure_agent_install.yml
    • einvent-ent312-source-instances.yml CloudFormationテンプレートは、CloudEndure UserNameとパスワードをCloudEndureUserとCloudEndurePasswordのCloudFormationテンプレートのパラメータに基づいて、この「AnEure Playbook」の「Install CloudEndure」セクションに設定します。

CloudEndure.pyスクリプトで使用される移行スクリプトconfig.yml:

ファイルを編集して、次の情報を入力します。

  • username – CloudEndureのユーザー名
  • password – CloudEndureのパスワード
  • hosttomigrate – CloudEndureダッシュボードで移行するホストの名前。 CloudEndureが最初のレプリケーションプロセスを開始するまで、この値はダッシュボードで使用できません。
  • stackname –CloudFormationスタックの名前。 CloudFormationスタックに名前を付けるときに、CloudEndureBlogDemoのデフォルト値を変更することを選択した場合にのみ、これを変更してください。
  • keypairname – Gogs自動スケーリングスタックを起動するためのキーペア
  • gogsdns – Gogs自動スケーリング用にELBロードバランサにマップするRoute 53ドメインエイリアス

CloudFormation テンプレート:

  • reinvent-ent312-migrated-gogs.template
    • この値は、Gogs自動スケーリングのELBロードバランサにマップするRoute 53ドメインエイリアスです。パラメータGogsDNSNameは、CloudEndure.pyスクリプトの実行時にconfig.ymlのgogsdns値に基づいて渡されます。

AWS CloudFormationを使用してソリューションをデプロイする

次に、移行を詳しく見て、各ステップを実行してみましょう。このデモンストレーションでは、CloudFormationテンプレートは、AWSアカウントの別個の仮想プライベートクラウド(VPC)でソース環境を紡ぎ出し、同じアカウント内の宛先VPCに移行します。

まず、AWS CloudFormationテンプレートをAWSアカウントに展開する必要があります。
テンプレートをダウンロードして、独自の実装の出発点として使用することもできます。

テンプレートの選択」ページで、テンプレートURLのデフォルト設定を維持し、「次へ」を選択します。

デフォルトのスタック名のままにするか、スタックの名前を入力し、下のスクリーンショットごとに値を入力します。

Gogsを構成する際に必要なため、ソースデータベースのユーザー名とパスワードに設定した値に注意してください。次の2つの画面で「次へ」および「次へ」を選択し、「AWS CloudFormationがカスタム名でIAMリソースを作成する可能性があることを確認します」というチェックボックスをオンにして、「作成」を選択します。

CloudFormationがアカウント内のリソースを作成するまでには数分かかります。 {YourStackName} -SourceInstanceResourcesがCREATE_COMPLETEとマークされたスタックが表示されたら、ログインしてGogsを設定できます。

CloudFormationで作成したカスタムDMSタスクは、Gogs DBが存在するかどうかによって異なりますので、CloudFormationスタックが完了する前にGogsをインストールして設定する必要があります。 (この執筆時点では、CloudFormationはDMSリソースをサポートしていませんが、移行の特定の側面について自動化を構築するための具体的な方法の1つを示したいと思います。)

スタックの[出力]タブで、AnatileSourceInstanceを見つけます。 SSHを次のコマンドで値を使用してインスタンスに追加します。

ssh -i {KeyPairYouAssociatedWithTheStack}centos@{ValueFromAnsibleSourceInstance}

インスタンスにSSHしたら、次のコマンドを実行して、更新とCloudFormationのユーザーデータステップが完了していることを確認します。

sudo tail -f /var/log/cloud-init.log

クラウド・イニシエータがインスタンスのブートストラップを終了すると、以下のようなメッセージが表示されます。

Mar 7 18:30:29 ip-10-10-138-101 cloud-init: Cloud-init v. 0.7.5 finished at Tue, 07 Mar 2017 18:30:29 +0000. Datasource DataSourceEc2. Up 369.01 seconds

これでインスタンスへのキーペアを追加する必要があります。そのため、SSHを使用してソースインスタンスに使用したり、Gogを構成したりすることができます。ローカルマシン上で、鍵ペアを保存したディレクトリから、次のコマンドを使用して秘密鍵をクリップボードにコピーします。

cat {KeyPairYouAssociatedWithTheStack}.pem | pbcopy

Ansibleソースインスタンスで、次のコマンドを実行します。

vi key.pem

プライベートキーをviウィンドウに貼り付け、ファイルを保存します。次に、次のコマンドを実行してアクセス許可を変更します。

chmod 400 key.pem

次のコマンドを実行して、ssh-agentが有効になっていることを確認します。エージェントpidを受け取る必要があります(たとえば、Agent pid 417)。

eval `ssh-agent`

ssh-agentにSSH鍵を追加し、空のパスフレーズを入力するためにEnterキーを押します。

ssh-add key.pem 
今度は、あなたのソースGogs DBをAnsible経由でプロビジョニングできます:

ansible-playbook -i playbooks/hosts playbooks/database_provision.yml

ソースのGogsインスタンスをプロビジョニングします。

ansible-playbook -i playbooks/hosts playbooks/gogs_provision.yml

GogsがAnsible経由で設定されると、ログイン環境でGogsをログインして設定することができます。 CloudFormationのSourceInstanceResourcesスタックのOutputsタブにGogsSourceInstanceの値が必要です。

http://{ValueFromGogsSourceInstance}:3000

「Gogsのユーザーパスワード」フィールドに、CloudFormationのソースデータベースのユーザー名とパスワードから前述した値を入力します。

Gogsであなたの選択したユーザーとパスワードを登録することができます。このデモンストレーションの後半に注意してください。

CloudFormationのDMSスタックが完了したら、セットアップを調べることができます。レプリケーションインスタンスが表示されます。

送信元と宛先の両方のエンドポイントも表示されます。

データベース同期を実行するタスクも表示されます。

DMSの検証が終了したら、AnatileSourceInstance SSHウィンドウに戻り、次のコマンドを実行してApplication Discovery ServiceとCloudEndureをインストールします。

ansible-playbook -i playbooks/hosts playbooks/aws_cli_ads_agent_install.yml

ansible-playbook -i playbooks/hosts playbooks/cloudendure_agent_install.yml

CloudEndureダッシュボードにログインすると、サーバーが表示されます。 CloudEndureはAWSへの最初のブロックレベル同期を完了する過程にあるため、テストの準備が整っている、と表示されるまでに時間がかかることがあります。

CloudEndure DashboardのINSTANCE NAMEの値は、config.ymlファイルのhosttomigrate変数に設定する必要がある値です。
CloudEndure.pyスクリプトを実行して、移行を初期化します。

python scripts/CloudEndure.py

スクリプトの出力例を見るには、READMEを見てください。

スクリプトが終了すると、Lambda関数から作成されたAMIを使用して、AutoScalingと共に高可用性Gogs環境が表示されます。

高可用性のGogs環境がヘルスチェックに合格し、ELBロードバランサの背後でサービスを受けるには数分かかりますが、最終的には、ソース環境で作成したユーザー名を使ってサインインし、RDSを使用するように設定された移行済みGogs環境にアクセス可能です。これは、DMSタスクが移行元GogsデータベースをRDSに移行するのに成功したことを証明します。

サマリー

この記事では、オンプレミス環境からAWSへの移行をスピードアップするために、自動化とテストをツールキットに組み込む方法を示しました。慎重な計画と構成では、移行シナリオ全体で再利用できる一連のツールが用意されています。これにより、ワークロードをより迅速に移行できるようになり、移行後に期待どおりアプリケーションが動作しているという確信が得られます。

 

このブログの内容は、第三者の製品を推奨するものではありません。このブログは情報提供を目的としています。

[1]このブログ記事の手順に従う際に発生した費用については、あなたが責任を負います。

(翻訳は諸岡が担当しました。原文はこちら)

 

LumberyardがGitHubで公開されました!

本日とてもエキサイティングなご報告をさせていただきます。LumberyardのソースがGitHubで公開されました。コミュニティーの皆様からの特に多いご要望の1つでしたが、ようやく実現でき大変嬉しいです。こちらのURL(www.github.com/aws/Lumberyard)をご確認ください。

ゲームを制作する事はチャレンジングですが、GitHubを活用することで2つの手法が容易になります。

 

LumberyardをGitHubから取得できます。

これまでは、Lumberyardを標準インストーラーからインストールする事がLumberyardを入手いただく唯一の方法で、ソースを含めたすべてのLumberyardが新たに別のディレクトリに保存されました。ですので継続的にLumberyardをアップグレードすることはうんざりする作業だったかもしれませんが、GitHubを活用することで劇的に変わります。

 

本日よりLumberyardソースコードをGitHubリポジトリから容易に直接取得して管理する事が可能となります。新たなバージョンのLumberyardをインテグレートすることも今までよりとてもシンプルな操作で可能です。そして、今後の新たなLumberyardのリリースは別々のブランチで提供されますので、任意のバージョンのインテグレートも可能となります。さらに!あなた自身のGitHubアカウントを作成してGitHubであなたのプロジェクトを管理したり、リモートリポジトリであなたのチームとの共同作業も容易にできるようになります。

Lumberyardの改良やバグ修正を送っていただく事も可能です。

これまでは、Lumberyardの開発者は最大50行までのLumberyardのコードをフォーラムを通して送っていただく事が可能でしたが、簡易な修正にしか適用できませんでした。(このような状況にもかかわらず、これまで修正を送っていただいた皆様に御礼を申し上げます!)本日より、GitHubを活用することで、どのようなサイズの改良やバグ修正でも容易にLumberyardチームに送っていただく事が可能となります。プルリクエストにより、必要となるコードを複数のファイルにまたがるような場合でも、正確な方法で管理できます。皆様からのフィードバックとサポートは我々を突き動かす大きな要因で、皆様とともにこのエンジンを創り上げていける事はとてもエキサイティングです。

メインブランチで安定したLumberyardを提供し続けていく事は我々にとってとても重要ですので、プルリクエストがすぐにはマージされるわけではなく、承認された変更は将来のリリースに反映される可能性があるということにご留意ください。継続的にプルリクエストは確認させていただきます。プルリクエストが採用されました皆様はリリースノートにクレジットさせていただきます!

もう一点、我々のリポジトリからフォークする事も可能です(詳しくはリポジトリ中のReadme.mdファイルをご参照ください)がLumberyardは引き続き「AWS Customer Agreement」と「Lumberyard Service Terms」の元にライセンスされております。この点にご留意いただければ公開リポジトリとすることも可能ですので、ログインせずに取得する事も可能となります。

いつでもお気軽にご意見をお聞かせください。今後の数ヶ月でScript Canvasや新たなアニメーションツール等さらにいくつかのエキサイティングな要素の提供も予定していますのでお見逃しなく!Lumberyardに関します様々な情報はチュートリアルやコミュニティフォーラム、さらにドキュメントからも得られます。

LumberyardのGitHub公開に関します詳細はこちら(www.github.com/aws/Lumberyard)をご参照ください。

本記事の作者について

Todd Gilbertsenは1980年台からゲームエンジンの制作、ビデオゲームだけでなく、様々なソフトウエア開発のプロフェッショナルとして活動を続けており、ゲーム開発者がクリエイティブに開発を進めるためのツールやテクノロジーの開発をする事に情熱を注いでおります。ToddはLumberyradのシニア・テクニカルプロダクトマネージャーです。

(翻訳は下田が担当しました。原文はこちら)

9 月の AWS Black Belt オンラインセミナーのご案内

【注意】セミナーの実施日程について更新がありました.最新の実施日程は,こちらをご覧ください.

こんにちは。プロフェッショナルサービスの宮本です。AWS Black Belt オンラインセミナー9月の配信についてご案内させて頂きます。ソリューションカットでは、AWSにおけるDDoS対策について、サービスカットでは、BlackBelt初開催となる、AppStream2.0や、多くの機能アップデートが行われたサービスを中心にお送りいたします。

 

9月の開催予定

サービスカット

9/6(水) 18:00-19:00 Amazon AppStream 2.0
9/13(水) 18:00-19:00 Amazon Aurora
9/19(火) 18:00-19:00 AWS DMS

※通常とは異なり、火曜日開催となりますのでご注意ください。
9/27(水) 18:00-19:00 Amazon CloudFront + AWS Lambda@Edge

ソリューションカット

9/5(火) 12:00-13:00 AWSでのDDoS対策

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

こんにちは、Amazon Macie: コンテンツを自動的に発見、分類、保護する

Jeffと私が初めてこのサービスを聞いたとき、私たちはMacieという名前の意味が知りたくなりました。もちろん偉大な研究者であるJeffは、Macieという名前を調べ、二つの意味があることを発見しました。フランス語とイギリス英語両方からの語源があり、典型的な少女の名前で、様々な意味を持っていました。Macieの一つめの意味は”武器”を意味する名前です。もう一つの意味は、力強く、さっぱりとした、優しい人の表す名前です。ある意味、これらの定義はふさわしいです。本日、私たちはAmazon Macieという新しいセキュリティサービスの提供開始を喜んで発表します。機械学習によって、AWS上に保存された機密情報の特定し、データ侵害、情報漏えい、Amazon Simple Storage Service (S3)への不正アクセスから保護をします。よって、Amazon Macieが、あなたの保存データを悪意のあるアクセスから保護する、”さっぱりとした”ユーザーインターフェースを備えた”優しい”サービスとして、AWS顧客にとって”力強い””武器”になることを私は想像できるのです。ふー、喋り過ぎました。たった一文でMacieの全てを表現するなんて!やはり、私はみなさんとAmazon Macieの凄さを共有するのに興奮しています。

Amazon Macieは、Amazon S3に保存されているデータを自動的に発見し分類する、機械学習を用いたサービスです。しかし、Macieはそれだけではありません。一度Macieであなたのデータが分類されれば、それらにビジネス価値が割り当てられ、継続的に監視し、アクセスパターンに基づいて疑わしい振る舞いを検知します。Macieの主要機能は以下です。

  • データセキュリティの自動化:データの分析、分類、処理し、過去のパターン、データに対するユーザー認証、データアクセス場所、アクセス時間を把握する
  • データセキュリティと監視:利用ログデータの監視して異常検知したり、CloudWatch EventsやLambdaによってレポートされる問題を自動解決する
  • プロアクティブなデータ保護のためのデータ可視性:保存データの詳細を管理者向けに可視化すると同時に、手動入力いらずで即時保護を提供する
  • データ調査とレポート:管理者向けにレポーティングやアラートを構成可能にする

どのようにAmazon Macieはこれらを実現するのか?

自然言語解析(NLP)の機械学習アルゴリズムを使って、MacieがS3バケットにあるデータの分類を自動化します。加えて、Amazon Macieはデータアクセスパターンを動的に分析する予測分類アルゴリズムも利用し、学習によって疑わしい振る舞いの可能性を知らせてくれます。Macieは個人特定情報(PII)や機密個人情報(SP)を検知するエンジンとしても動作します。MacieはAWS CloudTrailを利用しながら、継続的にS3バケットへのPUTリクエストのCloudTrailイベントを確認し、自動的に新しいオブジェクトの分類をほぼリアルタイムで行います。

MacieがAWSクラウド上のセキュリティやデータ保護にとって強力な道具であるだけでなく、ガバナンスやコンプライアンス要件、監査基準などにおいてもあなたを助けます。多くの人は既に、現時点でEUの最も厳しいプライバシー規制である、2018年5月25日に施行される一般データ保護規則(GDPR)を知っています。Amazon Macieは個人特定情報(PII)を認識し、ダッシュボードとアラート機能を提供することで、顧客にデータの暗号化や仮名化によるGDPRへの準拠を可能にします。Lambdaクエリと共に利用すると、MacieはGDPRの懸念に対応する協力な道具になります。

Amazon Macieサービスツアー

それではAmazon Macieの詳細を見るためのツアーを開始しましょう。

まず最初に、私はMacieのコンソールにログインし、Macieのセットアップ処理を始めます。Get Startedボタンを押すことで私のデータの分類と保護を開始することができます。

下画面の通り、Amazon Macieサービスを有効化するには、このサービス用の適切なIAMロールを作成しなければなりません。また、私のアカウントでAWS CloudTrailを有効化する必要があるでしょう。

私はこれらのロールを作成し、私のアカウントでAWS CloudTrailサービスを有効化しました。Macieをより簡単にセットアップするために、Macieユーザーガイドから提供されているCloudFormationのサンプルテンプレートを利用することもできます。それは、必要なIAMロールとポリシーを作成するので、あとやるべきことはCoudTrailドキュメントに記載されている通りに証跡を設定するだけです。

もしあなたが複数のAWSアカウントをもっている場合は、Macieサービスを有効化したアカウントがマスターアカウントになることに注意してください。他のアカウントもMacieサービスと連携できますが、それらはメンバーアカウントということになります。メンバーアカウントのユーザーは、Macieコンソールにアクセスするために、マスターアカウントへフェデレートアクセスするためのIAMロールを使う必要があるでしょう。

さあ、IAMロールが作られ、CloudTrailが有効化されたら、Enable MacieボタンをクリックしてMacieによるデータ監視と保護を開始しましよう。

あるアカウントで一度Macieサービスが開始すると、サービス画面が表示され、そのアカウントにおける既存アラートが表示されます。今回、私はサービスを開始した直後なので、アラートはまだ存在していません。

Macieサービスのツアーで、ここから私のS3バケットとMacieを連携していきましょう。ただし、Macieが監視を開始するだけであれば、あなたはS3バケットを指定する必要はありませんでした。なぜならサービスは既に情報の分析や処理のためのAWS CloudTrail管理APIを使用しているからです。このMacieツアーでは、私は特定のバケットにおけるCloudTrailのいくつかのオブジェクトレベルAPIイベントを監視しようと思います。

S3と連携するために、MacieコンソールのIntegrationsタブに移動します。Integrationsタブでは、二つの選択肢:AccountsServicesがあります。AccontsオプションはメンバーアカウントがMacieと連携するために使用され、あなたのデータ保存ポリシーを設定します。特定のS3バケットとMacieを連携したい時は、ServicesタブからServicesオプションをクリックします。

MacieとS3サービスを連携させると、証跡とS3バケットが作成され、S3データイベントに関するログが保存されます。始めるには、Select an accountドロップダウンを使いアカウントを選択します。アカウントが選択されると、連携可能なサービスが表示されます。Addボタンをクリックして、Amazon S3サービスを選択します。

さて、Macieに分析させたいバケットを選択したので、Review and Saveボタンを押して確認画面に行き、オブジェクトレベルロギングを行うことを確認してからSaveボタンをクリックします。

次に、このMacieツアーでは、どのようにMacieのデータ分類をカスタマイズするか見ていきましょう。

前述の通り、Macieは自動的にあなたのデータを監視し、分類します。Macieがあなたのデータを特定すると、ファイルとコンテントタイプでそのデータオブジェクトを分類します。また、Macieはサポートベクターマシン(SVM)も使用し、ファイルのメタデータに加えてS3オブジェクト内のコンテンツも分類します。深層学習/機械学習の研究分野において、サポートベクターマシンは教師あり学習モデルであり、データの分類や回帰分析のための学習アルゴリズムを持っています。Macieは、たくさんのコンテンツタイプのデータによってSVMを学習させ、あなたが書いたかもしれないソースコードが含まれていようとも、データコンテンツの正確な検知に最適化されます。

Macieはデータオブジェクトやファイルに対して一つのコンテンツタイプを割り当てますが、あなたはコンテンツタイプやファイル拡張子を有効化や無効化することもできます。それにより、それらオブジェクトをMacieサービスの分類対象に含めたり除外することができます。Macieがデータを分類したら、1から10までのリスクレベルがそのオブジェクトに割り当てられます。10が最もリスクが高く、1が最もリスクレベルが低いです。

Macieのデータ分類をカスタマイズするためには、Settingsタブに行きます。Macieの分類設定にて、有効化や無効化が可能な選択肢が表示されます。

このMacieツアーでの例として、File extensionを選んでみましょう。Macieが追跡し、分類に使用するファイル拡張子のリストが表示されます。

テストのために、Androidアプリケーションのインストールファイルであるapkファイル拡張子を編集し、ドロップダウンリストからNo – disabledを選択し、Saveボタンをクリックして、このファイルの監視を無効にします。もちろん、後でこの設定は戻します。Android開発用バイナリファイルも含めて全てのデータファイルの安全を維持したいからです。

最後に、Macieによるデータ分類に関して述べると、このサービスはあなたのデータオブジェクトがどのように分類されたかを可視化します。あなたが保存したデータ資産を、コンプライアンスにとって、個人情報にとって、ビジネスにとって、どれほど重要な情報が保存されているかの点で浮き彫りにします。

さて、今までMacieが分類し監視するデータの探検をしてきました。このサービスのツアー終着駅は、Macieダッシュボードです。

Macieダッシュボードは、Macieによるデータ監視と分類によって集められた全てのデータや活動の完全な絵を提供します。ダッシュボードはカテゴリー毎のメトリクスとビューによって、データを色々な視点から表示することができます。このダッシュボード画面の中で、メトリクス画面からResearchタブへ直接行き、メトリクスに基づいたクエリを作成し実行することも可能です。これらのクエリは、起こりうるセキュリティの課題や問題を通知するためのカスタマイズされたアラートに使用できます。ここでは、ResearchタブやAlertsタブのツアーは行いませんが、Macieユーザーガイドには、これらの機能に関するより多くの情報があります。

ダッシュボードに話を戻すと、非常にたくさんの情報源がMacieダッシュボードにはあるため、このツアーで全てのビュー、メトリクス、機能をご紹介することはしません。ここでは、ダッシュボード機能の概要をお伝えいたします。

ダッシュボードメトリクス(Dashboard Metrics) – 次のカテゴリーで監視したデータ:

  • ハイリスクS3オブジェクト(High-risk S3 objects):リスクレベル8から10のデータオブジェクト
  • 全イベント発生回数(Total event occurrences):Macieが有効化されてからの全てのイベント発生回数
  • 全ユーザーセッション(Total user sessions):CloudTrailデータの5分間スナップショット

ダッシュボードビュー(Dashboard Views) – 監視したデータや活動の様々な観点での表示ビュー:

  • S3 objects for a selected time range
  • S3 objects
  • S3 objects by personally identifiable information (PII)
  • S3 objects by ACL
  • CloudTrail events and associated users
  • CloudTrail errors and associated users
  • Activity location
  • AWS CLoudTrail events
  • Activity ISPs
  • AWS CloudTrail user identity types

まとめ

さて、ここでこの新しくエキサイティングなAmazon Macieサービスのツアーを終了します。Amazon Macieはセンセーショナルな新サービスで、機械学習と深層学習の力を使って、Amazon S3に保存されているデータを特定し保護します。自然言語解析(NLP)によって、データ分類を自動化するので、あなたはAmazon Macieを有効化するだけで、精度の高い分類と即時保護を簡単に始めることができます。インタラクティブなダッシュボードは、あなたの情報がどこで何が誰によっていつアクセスされたかを示すので、あなたの環境における大量のデータ、データアクセス、API呼び出しを分析できます。製品ページAmazon Macieユーザーガイドを参照し、Amazon Macieについてもっと知りましょう!

Tara

(翻訳はセキュリティSA桐山隼人が担当しました。原文はこちら

【確定版】8 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー8月の配信について,ご案内させて頂きます。今後の配信予定について一部変更があったため,改めて最新版の配信予定についてお知らせいたします.

 

8月の開催予定

 

サービスカット

8/2(水) 18:00-19:00 AWS X-ray
8/9(水) 18:00-19:00 Amazon DynamoDB
8/23(水) 18:00-19:00 AWS MobileHub

ソリューションカット

8/22(火) 12:00-13:00 Deployment on AWS
8/29(火) 12:00-13:00 Amazon Redshift テーブル設計詳細ガイド

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

AWS Migration Hub – エンタープライズアプリケーションの移行の計画と追跡

1週間に約1回、私はシアトルのエグゼクティブブリーフィングセンターで現在の有力なAWSのお客様に話します。一般的に私はイノベーションプロセスに重点を置いていますが、アプリケーションの移行を含む他のトピックについても議論することがあります。企業がアプリケーションポートフォリオを移行する場合、企業は構造化された整然としたやり方でそれを実行したいと考えています。これらのポートフォリオは、通常、何百もの複雑なWindowsおよびLinuxアプリケーション、合理的なデータベースなどで構成されています。お客様は、進め方についてはまだ不確実であることがわかります。これらの顧客と一緒に働く時間を費やした後、彼らの課題は一般的に次の3つの主要カテゴリに分類されることがわかりました。

ディスカバリー – お客様は、各アプリケーションを動かす全ての部分について、深くて完全な理解を得たいと考えています。

サーバー&データベース移行 – オンプレミスのワークロードとデータベースのテーブルをクラウドに転送する必要があります。

追跡/管理 – 大規模なアプリケーションポートフォリオと複数の移行が並行して行われるため、アプリケーション中心の方法で進捗状況を追跡および管理する必要があります。

ここ数年、私たちは最初の2つの課題に取り組む一連のツールを立ち上げました。 AWS Application Discovery Serviceはシステム情報の検出と収集のプロセスを自動化し、AWS Server Migration Serviceはクラウドへのワークロード移行を処理し、AWS Database Migration Serviceは最小のダウンタイムでリレーショナルデータベース、NoSQLデータベース、データウェアハウスを移行します。 RacemiCloudEndureなどのパートナーは、独自の移行ツールも提供しています。

新しいAWS Migration Hub

今日、これらAWSサービスとパートナー移行ツールをAWS Migration Hubに統合しています。ハブは、前述のツールへのアクセスを提供し、移行プロセスをガイドし、Migration Acceleration Program(MAP)で説明されている方法論および原理に従って、各移行の状況を追跡します。

ここにメイン画面があります。移行プロセス(ディスカバリー、移行、および追跡)の概要を示します。

Start discovery」をクリックすると、移行プロセスのフローが表示されます。

ディスカバリー手順をスキップしてすぐに移行を開始することもできます。

AWS移行サービス(Server Migration ServiceまたはDatabase Migration Service)のデータ、パートナーツール、またはAWS Application Discovery Serviceによって収集されたデータを使用し、サーバーリストが作成されます。

自分用の最初のアプリケーションを作成するには、「Group as application」を選択することができます。

移行するアプリケーションを特定したら、そのアプリケーションをHubの「Applications」セクションで追跡できます。

移行ツールは承認されている場合、アプリケーションの移行ステータスページに表示するために、ステータスの更新と結果を自動的にMigration Hubに送信します。ここでは、Racemi DynaCenterCloudEndure Migrationが担当する部分の移行を実施したことがわかります。

Migration Hub Dashboardをチェックすると、移行のステータスを追跡できます。

Migration Hubは、AWSと移行パートナーの移行ツールと連携して動作します。詳しくは、Integrated Partner Toolのリストをご覧ください。

 

今すぐ利用可能

AWS Migration Hubは、必要となる移行ツールが利用可能な様々なAWSリージョンの移行を管理できます。Hub自体は米国西部(オレゴン州)地域で運営されています。Hubは無料です。移行の過程で消費するAWSサービスに対してのみお支払いいただきます。

クラウドへの移行を開始する準備ができていて、何らかの支援が必要な場合は、Migration Accelerationパートナーのサービスを利用してください。これらパートナーは、大規模な移行を繰り返し実践・提供することを通じて移行コンピテンシーを獲得しています。

Jeff;

(翻訳は諸岡が担当しました。原文はこちら)