Amazon Web Services ブログ

Category: AWS CloudFormation

CloudFormation スタックセットを利用した複数のAWSアカウントやリージョンを横断したリソース展開

AWS CloudFormation は、AWS を利用するお客様の Infrastructure as Code モデルの実現に役立ちます。環境やアプリケーションを手作業でセットアップする代わりに、テンプレートを構築しそれを使用することで必要な全てのリソース ― これら一連のリソースは CloudFormation スタックと呼ばれます ― を作成します。このモデルでは、手作業に起因する失敗が発生する可能性が排除され、効率性が増し、時間が経過しても一貫した設定が保証されます。

本日、CloudFormation がよりいっそう便利になる新機能についてご紹介したいと思います。この新機能は、複数の AWS アカウントおよび/または複数のリージョンを利用する状況において Infrastructure as Code を実践するときにお客様が直面する課題の解決に役立つように設計されています。

アカウント ― 以前お話したように、多くの組織で多数の AWS アカウントが使用されます。AWS アカウントを階層化し、組織単位、あるいはOU（詳しく知りたい場合は「AWS Organizations – 複数の AWS アカウントのポリシーベースの管理」をお読みください）へグルーピングするために AWS Organizations が利用されています。事業、アプリケーション、そしてデベロッパーに対して複数のアカウントが運用されます。またアプリケーション毎に、開発、テスティング、ステージング、そして本番のそれぞれに対して別々のアカウントが作成されることもあります。

リージョン ― 巨大な（かつ今なお成長し続ける）AWS のリージョンもまた大いに活用されています。2つかあるいはそれ以上のリージョンにまたがるグローバルアプリケーションが構築され、洗練されたマルチリージョン・ディザスタリカバリ・モデルが実装されています。また、S3、Aurora、PostgreSQL、そして MySQL のデータをリアルタイムにレプリケートし、国や地域の規制にしたがって機密データを保管および処理するための場所を選択します。

複数のアカウントやリージョンへのこのような展開は、ガバナンスと一貫性に関していくつかの新しい課題をともないます。新しく作成される各アカウントが社内の標準に従って設定されていることを確認したいと、お客様は言われます。とりわけ、IAM ユーザーと IAM ロール、VPC と VPC サブネット、セキュリティグループ、コンフィグルール、ロギング、そして AWS Lambda 関数を、信頼性があり一貫した方法でセットアップしたいと望まれます。

スタックセットのご紹介

これらの重要なご要望を解決するために、本日 CloudFormation スタックセットをリリースしました。CloudFormation テンプレート内に AWS リソースの設定を定義すると、それから数回のクリックで複数の AWS アカウント及び/あるいはリージョンにそれらを水平展開できるようになりました。上述したクロスアカウントやクロスリージョンのシナリオを解決する AWS 機能のベースラインレベルのセットアップに、この機能を活用できます。一度セットアップしてしまえば、追加のアカウントやリージョンに対しても容易に展開することができます。

この機能は、常にクロスアカウントベースで動作します。管理者のアカウントによって、1つ以上のスタックセットが保持されるとともに1つ以上の対象アカウントへのデプロイが制御されます。この管理者アカウントは引き受け可能な IAM ロールを保持しなければいけません。また、対象アカウントは管理者アカウントに対して信頼を付与しなければいけません。どのようにこの作業を行うかについては、スタックセットのドキュメントの必要な条件をお読みください。

各スタックセットは、CloudFormation テンプレートを参照しアカウントとリージョンのリストを持ちます。全てのオペレーションは、スタックセット内のアカウント × リージョンの組み合わせそれぞれに対して適用されます。もしスタックセットが3つのアカウント（A1, A2, そしてA3）と4つのリージョン（R1, R2, R3, そしてR4）を参照する場合：

リージョンR1: アカウントA1, A2, そしてA3.
リージョンR2: アカウントA1, A2, そしてA3.
リージョンR3: アカウントA1, A2, そしてA3.
リージョンR4: アカウントA1, A2, そしてA3.

テンプレートをデプロイすると、まずアカウント/リージョンの組み合わせの1つに対して CloudFormation スタックの作成が開始されます。テンプレートは、各リージョン（順序を制御）と各リージョン内の複数のアカウント（並列度を制御）に順にデプロイされます。スタックの作成が失敗した場合にデプロイを終了するエラー閾値を設定することも可能です。

既存の CloudFormation テンプレートを使用することも可能ですが（アカウントとリージョンをまたいで動作する準備が整っていることを確認するよう注意してください）、新しいテンプレートを作成しても良いですし、あるいは AWS が予め用意するサンプルのテンプレートを使用することもできます。現在、一部のリージョン（中国を除く全てのパブリックリージョン）をサポートしていますが、そう長い時間をかけずにその他のリージョンにも展開できると予想しています。

スタックセットの使用

CloudFormation のコンソールからCloudFormation API を介して、あるいはコマンドラインからスタックセットを作成しデプロイすることが可能です。

コンソールなら、Create StackSet をクリックして開始します。自分自身のテンプレートを使うこともできますし、用意されたサンプルのテンプレートを使うこともできます。一連のサンプルの一番最後にある Add config rule encrypted volumes を使用してみます：

View template をクリックしこのテンプレートとテンプレートに記述されているルールの詳細を確認します：

このスタックセットに名前を付けます。今回選択したテンプレートはオプションのパラメータを受け取りますが、この値はこのタイミングで入力することができます：

次に、アカウントとリージョンを選択します。アカウント番号を直接入力するか、AWS 組織単位（OU）を参照するか、あるいはアカウント番号のリストをアップロードすることができます：

リージョンを設定しデプロイの順序を制御することができます：

デプロイメントのオプションを設定することも可能です。設定が完了したら Next をクリックして次に進みます：

スタックセットにタグを設定することができます。設定したタグは、このスタックセットのデプロイによって作成される AWS リソースに適用されます。

デプロイが始まり、コンソール上でデプロイのステータスを追跡することができます：

スタックのセクションを開いて各スタックを確認することが可能です。最初は各スタックのステータスは OUTDATED となっており、テンプレートがまだスタックにデプロイされていないことを示しています。問題なくデプロイが完了すると、ステータスは CURRENT に変わるでしょう。スタックがうまく削除できない場合には、ステータスは INOPERABLE に変わります。

この最初のデプロイが終わった後は、 Manage StackSet をクリックし、アカウントかリージョンあるいはその両方を追加したり、更にスタックを作成したりすることが可能です。

現在利用可能

この新機能は、現在利用可能であり追加料金なしに使い始めることができます（作成されたAWSリソースに対してのみ料金をお支払い頂きます）。

— Jeff;

追伸 ― もし、役に立つテンプレートが出来上がって他のAWSユーザにも共有したいと思ったら、私達の AWS Labs GitHub リポジトリにプルリクエストを送ってください。

原文：Use CloudFormation StackSets to Provision Resources Across Multiple AWS Accounts and Regions（翻訳：SA畑史彦）

コンテナやサーバレスアプリのデプロイツールとしてのAWS CloudFormation

SA岩永です。AWS上にシステムを構築する際に、アプリケーションのデプロイをどのように行うか？については多様なやり方が考えられますが、今日はAWS CloudFormationを使ったデプロイをご紹介したいと思います。CloudFormationはインフラ構築のツールとして考えられている方も多いと思いますが、最近は特にAmazon ECSやAWS LambdaといったComputeサービスへのアプリケーションデプロイツールとしての活用が進んでいます。AWSのリソースはAWS Command Line Interface (CLI)やSDK等での操作が可能なので自作のツール等を使われるのはもちろん1つの選択肢ですが、もしCloudFormationを検討されたことのない方は、ぜひこの投稿を参考にして頂けるとありがたいです。

デプロイツールとしてのCloudFormationのメリット

最初に結論をまとめておきます。CloudFormationを使ったデプロイには以下の様なメリットがあります。

デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能
宣言的にデプロイが定義・実行できる
アプリケーションに関連する他のAWSリソースも合わせて管理可能

現在お使いのデプロイツールで、逆に上記の様な観点で困ったことのある方は、この投稿をじっくり読んで頂くと良いと思います。

デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能

例えばCLIで行う様なデプロイツールの場合、そのツール自体のインストール等が必要になりますが、CloudFormationであればブラウザからテンプレートを指定するだけでデプロイできます。CloudFormationの一番のメリットはここです。アプリケーションの構成を記述したYAML or JSONのテンプレートファイルを用意するだけで、すぐにデプロイが可能です。

CloudFormationも実態はAWSのAPIを実行しながらリソースを作成・更新しますが、CloudFormationの場合にはAPIの実行そのものをCloudFormationのサービス側でやってくれます。例えばECSのデプロイで新しいTask Definitionを作成した後でそれを指定してServiceを更新するという依存関係のある2回のAPI操作を順番に実行する必要がありますが、CloudFormationに1回命令を送るだけで後のAPI操作はCloudFormationのサービスが代わりにやってくれます。なので、デプロイが終わるまで実行プロセスが待っている必要もないですし、複数人の排他的実行も実現できますし、さらに現在の状態と過去の履歴というデータの保存までもやってくれます。

もちろん、CloudFormation自体もAWSのサービスなので、CLI/SDKでの操作は可能です。もしもデプロイをCLIで実行して終わるまで待ちたい、ということであれば、aws cloudformation deployというコマンドを使うと更新が終わるまでポーリングしながら待ってくれます。この場合に必要なものはAWS CLIのインストールのみなので、そこまでハードルの高いものではありません。

宣言的にデプロイが定義・実行できる

AWSのAPIを利用しながらデプロイツールを自作する場合には、リソースの作成順序に気を払いながら、かつ途中で失敗した場合のエラーハンドリング等も考慮しつつ手続き的に実装する必要があります。これはシンプルな構成であればそこまで難しくはないのですが、対応したい機能が徐々に増えてくるとだんだんと実装が複雑化してきてしまいます。

CloudFormationで使うテンプレートは、手続きを記述するのではなく、希望する状態を宣言的に定義するものです。そのため、複雑な構成であっても簡潔さを保って記述することができますし、多くのケースで各リソース間の依存関係も自動で判断されるので、実行順序を考えて記述する必要もありません。もちろん、テンプレートにはパラメータを設定することも可能なので、例えばECSであれば新しく作成したコンテナイメージ名をパラメータにしておくと、デプロイはそのパラメータを更新するだけで済みます。

アプリケーションに関連する他のAWSリソースも合わせて管理可能

ECSやLambdaは、それ単体だけで利用するケースよりも、他のAWSのサービスも合わせて利用されることが多いと思います。例えば、AWS Identity and Access Management (IAM)のRoleは良く使われますし、データベースとしてAmazon DynamoDBを使ったり、ECSのコンテナへの負荷分散にElastic Load Balancingを使うことは非常に多く、場合によってはアプリケーションのデプロイ時にそれらのリソースの更新も行いたいケースもあります。

CloudFormationでは他のリソースも合わせて定義して操作させられるので、そういったケースに非常に強力なツールとなります。アプリケーションと同じテンプレートで作成することもできますし、昨年リリースされたCross Stack Referenceという機能を使うと、先に作成しておいたリソースをアプリケーション側から参照するといった使い方もできます。

CloudFormationを使ったECSのデプロイ例

こちらは、ECSへの継続的デプロイメントについて紹介した以下のブログをご参照頂くのが良いです。

AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント

ブログで紹介されている構成では、GitHubへのコードのpushをトリガーにして、イメージのビルドからECSのServiceの更新まで一貫したものを紹介していますが、Service更新部分はCloudFormationテンプレートを使って実施しています。また、AWS CodePipelineがデプロイ方式としてCloudFormationに対応しているので、簡単に設定することが可能です。

参考のために、Task DefinitionとServiceとIAM Roleを定義するYAMLテンプレート例を貼り付けておきます。

https://github.com/awslabs/ecs-refarch-continuous-deployment/blob/master/templates/service.yaml

Resources:
  ECSServiceRole:
    Type: AWS::IAM::Role
    Properties:
      Path: /
      AssumeRolePolicyDocument: |
        {
            "Statement": [{
                "Effect": "Allow",
                "Principal": { "Service": [ "ecs.amazonaws.com" ]},
                "Action": [ "sts:AssumeRole" ]
            }]
        }
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceRole

  Service:
    Type: AWS::ECS::Service
    Properties:
      Cluster: !Ref Cluster
      Role: !Ref ECSServiceRole
      DesiredCount: !Ref DesiredCount
      TaskDefinition: !Ref TaskDefinition
      LoadBalancers:
        - ContainerName: simple-app
          ContainerPort: 80
          TargetGroupArn: !Ref TargetGroup

  TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      Family: !Sub ${AWS::StackName}-simple-app
      ContainerDefinitions:
        - Name: simple-app
          Image: !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${Repository}:${Tag}
          EntryPoint:
            - /usr/sbin/apache2
            - -D
            - FOREGROUND
          Essential: true
          Memory: 128
          MountPoints:
            - SourceVolume: my-vol
              ContainerPath: /var/www/my-vol
          PortMappings:
            - ContainerPort: 80
          Environment:
            - Name: Tag
              Value: !Ref Tag
        - Name: busybox
          Image: busybox
          EntryPoint:
            - sh
            - -c
          Essential: false
          Memory: 128
          VolumesFrom:
            - SourceContainer: simple-app
          Command:
            - /bin/sh -c "while true; do /bin/date > /var/www/my-vol/date; sleep 1; done"
      Volumes:
        - Name: my-vol

CloudFormationを使ったLambdaのデプロイ例

Lambdaの構成管理およびデプロイには、AWS Serverless Application Model (SAM)を使うことができます。これはCloudFormationの拡張表記であり、例えば以下のようなテンプレートを書くと簡単にAmazon API GatewayとLambda Functionをデプロイ(初回は構築含む)をすることができます。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Outputs the time
Resources:
  TimeFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs6.10
      CodeUri: ./
      Events:
        MyTimeApi:
          Type: Api
          Properties:
            Path: /TimeResource
            Method: GET

Lambdaのデプロイを行う際、多くのケースでは依存ライブラリ等もまとめたzipファイルを作成し、Amazon Simple Storage Service (S3)にアップロードした上でFunctionを更新することになります。AWS SAMを使っているとこれをAWS CLIを使って簡単に実現できます。実装例は以下のドキュメントに詳しく紹介されています。

Lambda ベースのアプリケーションのデプロイメントを自動化する

まとめ

この投稿では、AWS CloudFormationをコンテナやサーバレスアプリケーションをデプロイするためのツールとしてご紹介しました。多くの実際のユースケースで利用可能なものですのでご参考にして頂ければ幸いです。サーバレスアプリのデリバリパイプラインまで含めた実装を実際にご覧になりたい場合には、AWS CodeStarで作成されるプロジェクトも参考になるかと思いますので合わせてご参考頂ければと思います。

新機能 – Amazon CloudWatch ダッシュボードでの API と CloudFormation のサポート

当社は、数年前に CloudWatch ダッシュボードの提供を開始しました。提供開始にあたって私が書いた投稿で、選択された CloudWatch メトリクスをグラフィカル形式で表示するダッシュボードをインタラクティブに作成する方法をご紹介しました。提供開始後に、フルスクリーンモード、暗いスキンのテーマ、Y 軸範囲のコントロール、名前変更の簡略化、永続的ストレージ、新しい視覚化オプションなどの追加の機能を導入しました。

新しい API および CLI
コンソールのサポートはインタラクティブな使用には非常に役立ちますが、多くのお客様から、ダッシュボードとその内部のウィジェットのプログラムによる作成と操作のサポートを求める声が寄せられました。ダッシュボードの動的な構築と管理、および対応する AWS リソースの作成と削除に応じたウィジェットの追加と削除が求めらました。その他のお客様からは、2 つ以上の AWS アカウント間で一貫したダッシュボードのセットを設定、管理する機能の要望が寄せられました。そして、CloudWatch ダッシュボードの API、CLI、AWS CloudFormation のサポートの提供が開始され、今すぐご利用いただけるようになったことをここに発表いたします。4 つの新しい API 関数 (および同等の CLI コマンド) があります。

ListDashboards / aws cloudwatch list-dashboards – アカウント内のすべてのダッシュボードのリスト、または共通のプレフィックスを共有するサブセットを取得します。

GetDashboard / aws cloudwatch get-dashboard – 1 つのダッシュボードの詳細を取得します。

PutDashboard / aws cloudwatch put-dashboard – 新しいダッシュボードを作成するか、既存のダッシュボードを更新します。

DeleteDashboards / aws cloudwatch delete-dashboards – 1 つ以上のダッシュボードを削除します。

ダッシュボードの概念
これらの関数とコマンドの使用方法を説明したいと思います。詳細な説明に移る前に、ダッシュボードの重要な概念と属性のいくつかを示します。

グローバル – ダッシュボードは AWS アカウントの一部であり、特定の AWS リージョンとは関連付けられていません。各アカウントは最大 500 個のダッシュボードを持つことができます。名前が付けられる – 各ダッシュボードには、AWS アカウント内で一意の名前があります。名前の長さは最大 255 文字です。グリッドモデル – 各ダッシュボードはセルのグリッドで構成されます。グリッドは全体で 24 個のセルで、必要なだけ高くすることができます。ダッシュボードの各ウィジェットはグリッド座標の特定のセットに配置され、整数値の数のグリッドセルにまたがるサイズです。ウィジェット (視覚化) – 各ウィジェットは、テキストまたは CloudWatch メトリクスのセットを表示できます。テキストは Markdown を使って指定し、1 つの値、折れ線グラフ、または積み上げ棒グラフとして表示できます。各ダッシュボードは最大 100 個のウィジェットを持つことができます。メトリクスを表示するウィジェットは、CloudWatch アラームと関連付けることもできます。ダッシュボードには、コンソール内から表示および編集できる JSON 表現があります。[Actions] メニューをクリックして、[View/edit source] を選択します。

ダッシュボードのソースは以下のとおりです。

この JSON は、実際のアプリケーションを構築する際の参考にしてください。ご覧のとおり、ダッシュボードの各ウィジェットに対して widgets 配列にエントリがあります。各エントリは、タイプ、位置、サイズで始まる 1 つのウィジェットを示します。

API を使用したダッシュボードの作成
特定のリージョンの各 EC2 インスタンスに対するウィジェットがあるダッシュボードを作成するとします。Python および AWS SDK for Python を使用して、次のように開始します (私のコードの未熟さはご容赦ください)。

import boto3
import json

cw  = boto3.client("cloudwatch")
ec2 = boto3.client("ec2")

x, y          = [0, 0]
width, height = [3, 3]
max_width     = 12
widgets       = []

次にインスタンスを反復処理し、それぞれに対して widget ディクショナリを作成し、それを widgets 配列に追加します。

instances = ec2.describe_instances()
for r in instances['Reservations']:
    for i in r['Instances']:

        widget = {'type'      : 'metric',
                  'x'         : x,
                  'y'         : y,
                  'height'    : height,
                  'width'     : width,
                  'properties': {'view'    : 'timeSeries',
                                 'stacked' : False,
                                 'metrics' : [['AWS/EC2', 'NetworkIn', 'InstanceId', i['InstanceId']],
                                              ['.',       'NetworkOut', '.',         '.']
                                             ],
                                 'period'  : 300,
                                 'stat'    : 'Average',
                                 'region'  : 'us-east-1',
                                 'title'   : i['InstanceId']
                                }
                 }

        widgets.append(widget)

位置 (x と y) をループ内で更新し、グリッドを作成します (位置を指定しない場合、ウィジェットは左から右へ、上から下へレイアウトされます)。

        x += width
        if (x + width > max_width):
            x = 0
            y += height

すべてのインスタンスを処理した後で、ウィジェット配列の JSON バージョンを作成します。

body   = {'widgets' : widgets}
body_j = json.dumps(body)

そして、ダッシュボードを作成または更新します。

cw.put_dashboard(DashboardName = "EC2_Networking",
                 DashboardBody = body_j)

コードを実行すると、次のダッシュボードが作成されます。

CloudWatch チームは、プログラムで作成されるダッシュボードにはテキストウィジェットを含め、ダッシュボードが自動生成されたことと、その操作を実行したソースコードまたは CloudFormation テンプレートへのリンクを含めることを推奨しています。つまり、ダッシュボードに対して手動の帯域外チェンジャーを実行しないことを推奨しています。前述したように、各メトリクスウィジェットは CloudWatch アラームと関連付けることもできます。アラームは、プログラムで作成するか、サンプル CPU 使用率アラームなどの CloudFormation テンプレートを使用して作成できます。これを行うように決定した場合、アラームのしきい値がウィジェットに表示されます。この詳細については、Tara Walker の最近の投稿「Amazon CloudWatch Launches Alarms on Dashboards」を参照してください。さらに一歩先に進んで、CloudWatch イベントと Lambda 関数を使って特定のリソースの作成と削除を追跡し、変更に合わせてダッシュボードを更新することができます。この方法については、「Keeping CloudWatch Dashboards up to Date Using AWS Lambda」を参照してください。

CLI を使用したダッシュボードへのアクセス
コマンドラインからダッシュボードにアクセスして操作することもできます。たとえば、シンプルなリストを生成できます。

$ aws cloudwatch list-dashboards --output table
----------------------------------------------
|               ListDashboards               |
+--------------------------------------------+
||             DashboardEntries             ||
|+-----------------+----------------+-------+|
||  DashboardName  | LastModified   | Size  ||
|+-----------------+----------------+-------+|
||  Disk-Metrics   |  1496405221.0  |  316  ||
||  EC2_Networking |  1498090434.0  |  2830 ||
||  Main-Metrics   |  1498085173.0  |  234  ||
|+-----------------+----------------+-------+|

そして、Disk-Metrics ダッシュボードを削除できます。

$ aws cloudwatch delete-dashboards --dashboard-names Disk-Metrics

ダッシュボードを定義する JSON を取得することもできます。

CloudFormation を使用したダッシュボードの作成
ダッシュボードは、CloudFormation テンプレートで指定することもできます。YAML 形式のシンプルなテンプレートを示します ( DashboardBody が依然として JSON で指定されています)。

Resources:
  MyDashboard:
    Type: "AWS::CloudWatch::Dashboard"
    Properties:
      DashboardName: SampleDashboard
      DashboardBody: '{"widgets":[{"type":"text","x":0,"y":0,"width":6,"height":6,"properties":{"markdown":"Hi there from CloudFormation"}}]}'

テンプレートをファイルに配置し、コンソールまたは CLI を使用してスタックを作成します。

$ aws cloudformation create-stack --stack-name MyDashboard --template-body file://dash.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/MyDashboard/a2a3fb20-5708-11e7-8ffd-500c21311262"
}

ダッシュボードを次に示します。

ご利用可能
この機能は今すぐ利用できます。本日から使い始めることもできます。ダッシュボードあたり最大 50 メトリクスを持つ 3 つのダッシュボードを無料で作成できます。追加のダッシュボードの料金は、CloudWatch 料金表ページに示すように、1 か月あたり 3 USD です。毎月新しい API 関数に対して最大 100 万回の呼び出しを無料で実行できます。それを超えた場合の料金は、1,000 回の呼び出しごとに 0.01 USD です。

— Jeff;

AWS クイックスタートの更新 – Tableau、Splunk、Compliance、Alfresco、Symantec

AWS クイックスタートは AWS で人気のソリューションのデプロイをサポートします。各クイックスタートは AWS のソリューションアーキテクトやパートナーが設計し、セキュリティや高可用性における AWS のベストプラクティスを活用しています。テストまたは本番稼働環境ですぐにクイックスタートをご利用いただけます。シングルクリックで起動できるクイックスタートには、広範囲にわたる内容を取り上げたデプロイメントガイドと AWS CloudFormation テンプレートが含まれています。クイックスタートは次の 7 つのカテゴリに分類されています。

開発運用
データベースとストレージ
ビッグデータと分析
セキュリティ & コンプライアンス
Microsoft & SAP
ネットワークとアクセス
その他

過去 2 か月間で 6 つの新しいクイックスタートをコレクションに追加し、合計数は 42 件になりました。次に、新しいクイックスタートの各カテゴリの概要をご紹介します。

Tableau Server (ビッグデータと分析)
AWS クイックスタートの Tableau Server は AWS Cloud で完全に機能する Tableau Server のデプロイをサポートします。デフォルト VPC でシングルノードを起動したり、新規または既存の VPC でマルチノードクラスターのデプロイメントができます。クラスターアーキテクチャについてはこちらをご覧ください: CloudFormation テンプレートは Tableau アクティベーションキーについてもプロンプトを表示します。

Splunk Enterprise (ビッグデータと分析)
AWS クイックスタートの Splunk Enterprise は、AWS クラウドで分散した Splunk Enterprise 環境のデプロイをサポートします。2 つ以上のアベイラビリティーゾーンと既存の VPC で開始したり、新しい VPC を作成することができます。アーキテクチャについてはこちらをご覧ください: テンプレートは S3 バケット名と Splunk ライセンスファイルへのパス (バケット内) のプロンプトを表示します。

UK OFFICIAL (セキュリティ & コンプライアンス)
AWS クイックスタートの UK-OFFICIAL は United Kingdom (UK) OFFICIAL により分類されたワークロードをサポートする、標準化された AWS クラウド環境をセットアップします。この環境は NCSC Cloud Security Principles と CIS Critical Security Controls にある対象サービスのガイドラインに準拠します (詳細はセキュリティコントロールマトリックスをご覧ください)。アーキテクチャについてはこちらをご覧ください:

Alfresco One
AWS クイックスタートの Alfresco One は、AWS クラウドで Alfresco One Enterprise Content Management サーバークラスターのデプロイをサポートします。既存の VPC にデプロイまたはパブリックサブネットやプライベートサブネットで新しい VPC をセットアップできます。アーキテクチャについてはこちらをご覧ください: クラスターを起動するには Alfresco のトライアルライセンスが必要です。

Symantec Protection Engine (セキュリティ & コンプライアンス)
AWS クイックスタートの Symantec Protection Engine は、1 時間以内に Symantec Protection Engine (SPE) をデプロイできるようにサポートします。デプロイが完了すると (新規または既存の VPC にデプロイが完了)、SPE の API を使用してマルウェア検出や脅威検出をアプリケーションに組み入れることができます。さらにプロキシと連携すれば、ウィルスやトロイの木馬またはその他のマルウェアが潜んでいないかトラフィックをスキャンすることもできます。アーキテクチャについてはこちらをご覧ください: クイックスタートを使用するには、SPE ライセンスを購入するか SPE AMI に登録してください。クイックスタートの詳細についてはクイックスタートのよくある質問をご覧ください。クイックスタートの設計に参加するにはクイックスタート協力者向けガイドをご覧ください。

— Jeff;

AWSでの疎結合データセットの適合、検索、分析

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する（あるいは反論する）ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています（例えば、日時が間違っている、地理座標が間違っているなど）。
最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。
データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。
関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。
このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。

異なる3つのデータセットを適合させて索引付けし、検索可能にします。
事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。
Amazon AthenaやAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

(more…)

AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント

同僚のJohn PignataがAmazon ECSに対する継続的デプロイメントパイプライン作成方法について素晴らしいブログを書いてくれました。

—

今日のビジネス環境では、新しいソフトウェアの反復を高速で提供することは競合に対するアドバンテージになります。企業がイノベーションを顧客に提供するスピード、変化する市場に適応するスピードは、ますます成功と失敗の違いを生む重要な要素になっています。

AWSは、企業がアプリケーションやサービスを高速に提供する組織の能力を向上させるDevOpsと呼ばれる文化哲学、実践、ツールの組み合わせを企業が採用できるように設計された一連の柔軟なサービスを提供します。

このポストでは、継続的デプロイメントと呼ばれるデプロイの実行方法について説明し、AWS CodePipeline、 AWS CodeBuild、および AWS CloudFormationを使用してAmazon ECS上のDockerコンテナとして提供されるアプリケーションの自動デプロイメントパイプラインを実装するためのリファレンスアーキテクチャの概要を説明します。

継続的デプロイメントとは？

俊敏性は、ITリソースのトラディショナルな提供方法に比べてクラウドコンピューティングが持つ重要な利点としてよく引用されています。他の部門が新しいサーバーをプロビジョニングするのに数週間か数ヶ月待つ代わりに、開発者はシングルクリックやAPIコールで新しいインスタンスを作成することができ、数分で使用開始することができます。この新たな速度と自律性は、開発者が新しい製品や機能を試し、できるだけ早く顧客に提供するこを可能にします。

製品の市場投入期間を短縮し、コードの品質を向上させ、より信頼性の高い製品やサービスのリリースを実現するために、開発チームはクラウド上でDevOpsの実践を採用しています。継続的デプロイは、新しいソフトウェアリビジョンが自動的にビルドされ、テストされ、パッケージ化され、本番環境にリリースされる、DevOpsの実践です。

継続的デプロイにより、開発者は完全に自動化されたソフトウェアリリースプロセスを通じて機能や修正を出荷できます。開発者は、数週間や数ヶ月にわたる大規模なリリースをバッチ処理し、手動で展開する代わりに、新しいソフトウェアリビジョンが準備され次第、自動化されたプロセスを使用してアプリケーションのバージョンを1日に何回も配信することができます。クラウドコンピューティングがリソースの調達期間を短縮するのと同様に、継続的デプロイは新しいソフトウェアのリリースサイクルを数週間～数ヶ月から数分間に短縮します。

このスピードと敏捷性を活用することには、次のような多くの利点があります。

新機能やバグ修正を迅速にすることができる : ソースコードリポジトリに置いてあるコードは、ビジネス価値をもたらしたり、顧客に利益をもたらすものではありません。新しいソフトウェアリビジョンをできるだけ早くリリースすることで、顧客はより迅速に利益を享受できるようになり、チームはより集中的なフィードバックを得ることができます。
変更セットが小さくなる : 大きな変更セットは、問題、バグ、およびその他の退化の根本原因を突き止める際に問題を引き起こします。より小さな変更セットを頻繁にリリースすることで、チームは発生した問題をより簡単に特定して修正することができます。
自働デプロイによりベストプラクティが促進される : ソースコードリポジトリにコミットされた変更は即座に自動プロセスによってデプロイすることができるため、チームはその変更が十分にテストされ、運用環境が厳重に監視されていることを確実にする必要があります。

継続的デプロイはどのように動くのか？

継続的デプロイは、ソフトウェアのリリースに関連する活動を調整する自動化されたパイプラインによって実行され、プロセスの可視性を提供します。プロセスの最中に、リリース可能な成果物が構築され、テストされ、パッケージ化され、本番環境にデプロイされます。リリース可能な成果物には、実行可能ファイル、スクリプトファイルのパッケージ、コンテナ、または最終的にプロダクションに配信されなければならないその他のコンポーネントが含まれます。

AWS CodePipelineは、新しいソフトウェアリビジョンができるたびにコードのビルド、テスト、およびデプロイを実行する継続的デプロイおよび継続的デリバリーのサービスです。 CodePipelineは、コード変更の統合、可視化を行い、ワークフローを介して最終的にユーザーの提供します。このパイプラインは、ソースコードリポジトリからのコード取得、ソースコードのビルド、テスト、および本番環境へのデプロイといったステージを定義し、これらのステージが順番に実行されること、障害が発生した場合には停止することを保証します。

CodePipelineはデリバリパイプラインを強化し、プロセスを統合しますが、ソフトウェア自体をビルドまたはテストする機能はありません。このステージでは、CodePipelineは、フルマネージドのビルドサービスであるAWS CodeBuildなど、いくつかのツールと統合されます。 CodeBuildはソースコードをコンパイルし、テストを実行し、デプロイする準備が整ったソフトウェアパッケージを生成します。このサービスは継続的なデプロイパイプラインの構築とテストに最適です。CodeBuildはDockerコンテナのビルドを含む多くの異なる種類のビルド環境をネイティブサポートしています。

コンテナは、予測可能で再現可能な環境を実現し、ある環境でテストされた変更が正常に展開できるという高いレベルの信頼性を提供するため、ソフトウェア提供の強力なメカニズムです。 AWSは、Dockerコンテナイメージを実行・管理するためのいくつかのサービスを提供しています。 Amazon ECSは、非常に高い拡張性とパフォーマンスを持つコンテナ管理サービスで、Amazon EC2インスタンスのクラスタ上でアプリケーションの実行環境を提供します。 Amazon ECRは、フルマネージドのDockerコンテナレジストリで、開発者は簡単にDockerコンテナイメージの格納、管理、およびデプロイが可能です。

最後に、CodePipelineはデプロイメントを容易にするために、AWS Elastic Beanstalk、AWS CodeDeploy、AWS OpsWorksや、AWS LambdaまたはAWS CloudFormationを使用した独自のカスタムデプロイメントコードやデプロイプロセスなど、いくつかのサービスと統合されます。これらのデプロイアクションを使用してパイプラインの最後に新しく構築された変更を本番環境にプッシュすることができます。

Amazon ECSへの継続的デプロイ

これらのコンポーネントを組み合わせて、Dockerアプリケーションの継続的なデプロイパイプラインをECSに提供するためのリファレンスアーキテクチャを次に示します。

このアーキテクチャーは、CodePipelineを使用してECSおよびECRにコンテナをデプロイし、AWS上でフルマネージドの継続的デプロイパイプラインを構築する方法を示しています。この継続的デプロイのアプローチは、完全にサーバーレスであり、ソフトウェアの統合、ビルド、およびデプロイにマネージドサービスを使用します。

リファレンスアーキテクチャで作成されたパイプラインは、次のようになります。

このポストでは、このリファレンスアーキテクチャの各ステージについて説明します。開発者がランディングページの原稿を変更し、その変更をソースコードリポジトリにプッシュするとどうなるでしょう？

まず、Source ステージでは、ソースコードリポジトリシステムにアクセスするための詳細がパイプラインに設定されます。リファレンスアーキテクチャでは、GitHubリポジトリにホストされているサンプルアプリケーションがあります。 CodePipelineはこのリポジトリをポーリングし、新しいコミットごとに新しいパイプラインを実行開始します。 GitHubに加えて、CodePipelineは、AWS CodeCommitのGitリポジトリやAmazon S3に格納されたバージョン管理されたオブジェクトなどのソースロケーションもサポートしています。新しいビルドはそれぞれソースコードリポジトリから取得され、zipファイルとしてパッケージ化され、S3に格納され、パイプラインの次のステージに送られます。

Sourceステージでは、Amazon S3に格納されているテンプレートも定義されます。これは、アプリケーションのビルドが成功した後に、デプロイメントステージで使用されるデプロイメント環境を定義するテンプレートです。

Build ステージではCodeBuildを使用して、最新のソースコードに基づいて新しいDockerコンテナイメージを作成し、ECRリポジトリにプッシュします。 CodePipelineは、Jenkins、CloudBees、Solano CI、TeamCityなどのサードパーティのビルドシステムとも統合されています。

最後に、DeployステージではCloudFormationを使用して、新しく作成されたDockerコンテナイメージを指す新しいタスク定義リビジョンを作成し、新しいタスク定義リビジョンを使用するためにECSサービスを更新しています。こうすることで、ECSは新しいDockerコンテナをECRから取得し、サービスを再起動することによってデプロイを開始します。

パイプラインのステージがすべてグリーンになったら、Webブラウザでアプリケーションをリロードして、開発者の原稿の変更を本番環境で確認することができます。これは人手での作業は何もしなくても自動的に実行されます。

このパイプラインはすでにプロダクション状態であり、ソースコードリポジトリから新しいコードを取得し、チームがプロダクションにプッシュする将来の変更を出荷する用意ができています。また、拡張可能なので、新しいステップを追加して追加のステージを含めることもできます。たとえば、新しいコードリビジョンが本番環境に安全にデプロイされることを確認するために、テストステージを組み込んでユニットテストと受入テストを実行することができます。デプロイ後、新しいバージョンが稼動したことおよび、本番環境にデプロイされた変更セットの詳細について、電子メールまたはSlackチャンネルでチームにアラートを送るための通知ステップも追加することができます。

最後に

私たちはこのアプローチを使用してあなた方がどのような種類のアプリケーションをユーザーに提供できるのか、またそれが製品開発プロセスにどのような影響を及ぼすのかを見せていただけることを楽しみにしています。クラウドは俊敏性において大きなメリットを発揮し、継続的デプロイなどの技術を実装する能力は、競争上の大きな利点を生み出します。

GitHub上のAWS Labs EC2 Container Service – Reference Architecture: Continuous Deploymentリポジトリには、独自の継続的デプロイパイプラインを起動するために必要なすべてのものを含むAWS CloudFormationテンプレートがあります。

ご質問、ご意見、ご提案がありましたら是非お知らせください！

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

AWS CloudFormation の更新 – YAML、クロススタック参照、簡略化された置換

AWS CloudFormation では、テンプレートを作成して、スタック全体 (関連する AWS リソースのコレクション) を宣言により表すことができます。スタックを定義し、希望のリソースとそれらの相互関係を指定および設定して、スタックの必要な数のコピーを起動できます。CloudFormation では、リソースを自動的に作成およびセットアップし、リソース間の順序付けの依存関係の対応に配慮することもできます。現在、CloudFormation には 3 つの重要な機能を追加中です。

YAML Support – CloudFormation テンプレートを YAML で記述できるようになりました。
クロススタック参照 – あるスタックから値をエクスポートし、別のスタックで使用できるようになりました。
簡略化された置換 – テンプレート内で文字列の置換をより簡単に行うことができます。

それらについて説明します。

YAML のサポート
CloudFormation テンプレートを YAML (「YAML はマークアップ言語ではない」の頭文字) で記述できるようになりました。これまでは、テンプレートは JSON で記述されていました。YAML と JSON の表現力は同等ですが、YAML は人間が読み取れる形式であるよう設計されているのに対して、JSON は (正直なところ) そうではありません。YAML ベースのテンプレートでは句読点の使用が少なく、記述と読み取りがかなり簡単です。また、コメントの使用が許可されます。CloudFormation は、ハッシュ結合、エイリアス、および一部のタグ (バイナリ、imap、ペア、TIMESTAMP、セット) の例外を除き、実質的にすべての YAML をサポートします。

YAML で CloudFormation テンプレートを記述する場合、同じ最上位の構造 (Description、Metadata、Mappings、Outputs、Parameters、Conditions、および Resources) を使用します。これは、パラメーター定義を図示したものです。

Parameters:
  DBName:
    AllowedPattern: '[a-zA-Z][a-zA-Z0-9]*'
    ConstraintDescription: 英字で始まり、英数字のみにする必要があります。
      
    Default: wordpressdb
    Description: WordPress データベース名
    MaxLength: '64'
    MinLength: '1'
    Type: String

YAML を使用すると、省略された新しい構文を使用して CloudFormation 関数を参照できます。たとえば、GetAtt、Base64、および FindInMap などです。既存の構文 ("Fn::GetAtt") または新しいタグベースの構文 (!GetAtt) を使用できるようになりました。”!” はタグの YAML 構文の一部であり、「論理 NOT」演算子ではないことに注意してください。古い構文を次に示します。

- Fn::FindInMap:
    - AWSInstanceType2Arch
    - Ref: InstanceType
    - Arch

新しい構文を次に示します。

!FindInMap [AWSInstanceType2Arch, !Ref InstanceType, Arch]

おわかりのように、新しい構文は短く簡潔になっています。ただし、2 つのタグを隣接して使用することはできません。2 つの形式を混ぜて、ネストすることもできます。たとえば、 !Base64 !Sub は無効ですが、 !Base64 Fn::Sub は有効です。

CloudFormation の API 関数 (CreateChangeSet、CreateStack、UpdateStack など) では、JSON または YAML でテンプレートを使用できるようになりました。 GetTemplate 関数は元の形式でテンプレートを返します。CloudFormation designer では現在は YAML テンプレートはサポートされませんが、ロードマップには含まれています。

クロススタック参照
AWS の多くのお客様は、1 つの “システム” CloudFormation スタックを使って環境 (VPC、VPC サブネット、セキュリティグループ、IP アドレスなど) を設定し、その他の複数の “アプリケーション” スタックを使って入力 (EC2 および RDS インスタンス、メッセージキューなど) を行っています。これまで、アプリケーションスタックで、システムスタックによって作成されたリソースを参照するための簡単な方法がありませんでした。

1 つのスタックから値を作成してエクスポートし、カスタム CloudFormation リソースを作成する手間をかけることなく、他のスタックでそれらを使用できるようになりました。最初のスタックでは次のような値がエクスポートされます。

Outputs: 
  TSSG: 
    Value: !Ref TroubleShootingSG
    Export:
      Name: AccountSG

次に、他のスタックは新しい ImportValue 関数を使用してそれらを参照します。

EC2Instance:
  Type: AWS::EC2::Instance
	Properties:
	  SecurityGroups:
  	    - !ImportValue AccountSG

エクスポートされた名前は AWS アカウントおよびリージョンで一意である必要があります。別のスタックで参照されたスタックを削除することはできず、エクスポートされた値を変更または削除することはできません。

簡略化された置換
多くの CloudFormation テンプレートでは、コマンドライン、ファイルパス、およびスタックが作成されるまでに完全に決定できないその他の値を作成するために、複雑な文字列操作を行っています。これまでは、この操作には fn::Join を使用する必要がありました。この結果、JSON 構文との組み合わせにより、理解や管理が困難な乱雑なテンプレートが作成されました。テンプレート開発のこの重要な側面を簡略化するため、当社は新しい置換関数である fn::Sub を導入します。この関数は変数 (構文 ${variable_name}で示される) を評価された値で置き換えます。以下の例をご覧ください。

configure_wordpress:
  commands:
    01_set_mysql_root_password:
      command: !Sub |
           mysqladmin -u root password '${DBRootPassword}'
      test: !Sub |
           $(mysql ${DBName} -u root --password='${DBRootPassword}' >/dev/null 2>&1 </dev/null); (( $? != 0 ))
    02_create_database:
      command: !Sub |  
           mysql -u root --password='${DBRootPassword}' < /tmp/setup.mysql
      test: !Sub |
           $(mysql ${DBName} -u root --password='${DBRootPassword}' >/dev/null 2>&1 </dev/null); (( $? !=0))

${} または ${variable}を生成する必要がある場合は、単純に ${!} または ${!variable}を記述します。

対象の更新
このリリースの一部として、AWS Key Management Service (KMS)、EC2 スポット群、および Amazon EC2 Container Service のサポートを追加しました。詳細については、「CloudFormation Release History」を参照してください。

今すぐ利用可能
これらのすべての機能は今すぐご利用いただけます。

— Jeff;

New – AWS CloudFormation の変更点

AWS CloudFormation を使用すると、AWS リソースのコレクション (「スタック」) を制御された予想可能な方法で作成、管理、および更新できます。CloudFormation を使用して、本番ワークロードを稼働するためのスタックの更新が 1 日に何十万回も実行されています。お客様は、初回のテンプレートを定義した後、要件が変わるとテンプレートを修正します。

通常「コードとしてのインフラストラクチャ」と呼ばれるこのモデルを使用すると、開発者、アーキテクト、および運用担当者の各チームが AWS リソースのプロビジョニングと構成を詳細に制御できるようになります。この制御と説明責任の詳細さは、CloudFormation を使用する際に最もはっきりとわかる利点の 1 つです。ただし、CloudFormation には、それほどはっきりとはわからないものの、同じくらい重要な利点がいくつかあります。

整合性 – CloudFormation チームは、AWS チームと連係して、リソースの作成、更新、および削除のセマンティクスについて、新しく追加されたリソースモデルでも整合性を保つようにしています。また、EBS ボリュームや RDS ボリュームの暗号化用の KMS キーなど、関連リソースの再試行、べき等性、および管理について説明できるようにしています。

安定性 – どのような配信システムでも、結果整合性に関連する問題は頻繁に発生し、必ず対処する必要があります。CloudFormation チームではこのような問題を十分認識しており、変更のプロパゲーションが必要な場合には、配信を実行する前に、自動的にそのプロパゲーションが完了するのを待つ仕組みになっています。多くの場合、CloudFormation チームはサービスチームと連係して、API と成功シグナルが CloudFormation で適切に使用できるよう調整されていることを確認します。

均一性 – CloudFormation では、スタックが更新される際に、インプレース更新とリソース置換のいずれかが選択されます。

この作業はすべて一定の時間がかかり、関連サービスが公開または更新される前にテストを完了できない場合もあります。

更新のサポートの向上
先述のように、AWS の多くのお客様が、本番スタックの更新を管理するのに CloudFormation を使用しています。お客様は、既存のテンプレートを編集 (または新しいテンプレートを作成) した後、CloudFormation の更新スタックオペレーションを実行して、変更を有効にします。

新しいテンプレートやパラメータ値に合わせてスタックが更新される際に CloudFormation が実行する変更の詳細について知りたい、というお問い合わせが、多くのお客様から寄せられています。変更のプレビューを行い、その変更が期待通りであることを確認してから、更新を実行するためです。

CloudFormation のこの重要なユースケースに対応するために、「変更セット」という概念を導入しました。変更セットを作成するための第 1 段階として、お客様は、更新対象のスタックに対する変更内容を送信します。CloudFormation では、更新対象のスタックが新しいテンプレートやパラメータ値と比較され、変更セットが作成されます。お客様は、この変更セットを確認してから、適用 (実行) するかどうかを選択できます。

この新しいモデルにより、変更される可能性のある内容を詳細に知ることができるだけではなく、更新をより詳細に制御できるようにもなります。IAM を使用すると、UpdateStack、CreateChangeSet、DescribeChangeSet、および ExecuteChangeSet といった CloudFormation の特定の機能の使用を制御できます。例えば、ほとんどの開発者に変更セットの作成とプレビューを許可するものの、実行は経験豊富な開発者で構成される少人数のグループのみに許可する、といった具合です。自動化項目をいくらか追加すると、データベースサーバーやネットワークといった主なリソースを変更しようとするとアラートが発生する、または追加の承認を要求するといった設定を行うこともできます。

変更セットを使用する
変更セットに関連する操作を順を追って見ていきましょう。AWS コマンドラインインターフェイス (CLI)、AWS Tools for Windows PowerShell、および CloudFormation API を使用して、通常と同じ機能を利用できます。

今回は、まず、1 つの EC2 インスタンスで LAMP スタックを実行するスタックを作成します。リソースが作成されます。

その後、より複雑なアーキテクチャを利用することにします。同僚から適切なテンプレートをもらいました。「信頼するが確認する」という原則に基づいて、テンプレートを使用するとどうなるかを確認するために、変更セットを作成します。[Create Change Set] をクリックします。

その後、新しいテンプレートをアップロードして、変更セットに名前を割り当てます。テンプレートでパラメータを使用する場合は、ここで値を入力できます。

ここでは、既存のタグを変更することも、新しいタグを追加することもできます。スタックの詳細オプションを設定することもできます (当然、詳細オプションは、変更セットを実際に実行するまで適用されません)。

1、2 回クリックして設定を確定すると、テンプレートが分析され、スタックに適用した場合の結果がチェックされ、変更のリストが表示されます。

変更を有効にするには、ここで [Execute] をクリックします。変更セットの適用を見送ることも、他の方法を探すために変更セットをいくつか作成することもできます。準備が整ったら、変更セットを指定して、実行します。

CloudFormation がアクションを開始し、変更セットに沿って変更が実装されます。

数分後には、スタックの新しい構成が整い、完全に運用できるようになります。

これで完了です。先述のように、実行する変更セットを選択する前に、複数の変更セットを作成して、試してみることができます。この場合、実装しなかった変更セットは不要になるので、破棄します。

ロールバックを管理する
スタックの更新に失敗した場合、可能な限り、更新前の状態にロールバックされます。ロールバックオペレーションは失敗することもあります。多くの場合、ロールバックが失敗する原因は、CloudFormation の範囲外で行われた変更です。最近、ロールバックの結果をより適切に制御できるよう、新しいオプションが公開されました。このオプションの詳細については、Continue Rolling Back an Update for AWS CloudFormation stacks in the UPDATE_ROLLBACK_FAILED state をご覧ください。

今すぐ利用可能
変更点は今すぐ利用できます。ぜひご使用ください。

–
Jeff