CloudFormation テンプレートのパラメータは自由に順序決めやグループ分けできるよ

最近CloudFormation（以下CFn）テンプレートばっかり作ってるナスです。

テンプレートの中に自由に値を渡せる「パラメータ」ってのがありますが、このパラメータ数が多ければ多いほど最初のスタック作成時の入力がめんどくさいですよね？
しかもパラメータの項目がきれいに並んでいればまだいいのですが、よくわからない順番で聞かれたりします。 せめてパラメータの順番だけでも思い通りにしたいなーと思ってたら、、ありました。 2011年に初めて同じ願望を抱いてから7年、ようやく願いが叶ったようです。

というわけで今回は、CFnテンプレートでパラメータの順序を決める方法をご紹介します。

パラメータの順序を指定しないとどうなる？

とりあえず適当にパラメータを書いてみます。

{
    "Parameters": {
        "DBPort": {
            "Default": "3306",
            "Type": "Number"
        },
        "DBPwd": {
            "NoEcho": "true",
            "Type": "String"
        },
        "InstanceName": {
            "Type": "String"
        },
        "AZ": {
            "Type": "AWS::EC2::AvailabilityZone::Name"
        }
    }
}

これでスタックを作成するとこうなりました。

んー、なんとなくパラメータ名でソートされる感じですかね？わからんけど。

パラメータ順序は簡単に指定できる

例えば、 InstanceType の下に AZ を持ってきたい場合はこんなふうにテンプレートにメタデータを追加します。ついでなので、インスタンス関連と DB 関連をグループ分けしてみました。parameters のリストの順番がそのままスタック作成時に上から順番に並びます。

{
    "Parameters": {
        "DBPort": {
            "Default": "3306",
            "Type": "Number"
        },
        "DBPwd": {
            "NoEcho": "true",
            "Type": "String"
        },
        "InstanceName": {
            "Type": "String"
        },
        "AZ": {
            "Type": "AWS::EC2::AvailabilityZone::Name"
        }
    },
    "Metadata": {
        "AWS::CloudFormation::Interface": {
            "ParameterGroups": [
                {
                    "Label": {
                        "default": "Instance Group"
                    },
                    "Parameters": [
                        "InstanceName","AZ"
                    ]
                },
                {
                    "Label": {
                        "default": "DB Group"
                    },
                    "Parameters": [
                        "DBPwd","DBPort"
                    ]
                }
            ]
        }
    }
}

↑でスタックを作成すると結果はこうなります。

ドキュメントも↓にちゃんとありました。
docs.aws.amazon.com

ふと思ったこと

この内容を知ったのはつい最近ですが、もしかしたら実は何年も前から存在してたんですかね… 自分だけでは気づけないことに気づくためにJAWS-UGの勉強会やハンズオンとかにもっと参加するか。

EC2 インスタンスに IP アドレスで Web アクセスするのだけはやめよう

ナスです。

ふと AWS Shield の存在を思い出したついでに、これだけはやめようねってことを伝えたいと思います。ちなみに、AWS Shield については以前に記事を書いていますので↓を見てください。
nasrinjp1.hatenablog.com

AWS Shield の適用リソース

ELB(ALB, CLB), CloudFront, Route53 に対して、AWS Shield Standard が適用されます。しかも意識することなく。

上で書いたことを踏まえてやめた方がいいこと

タイトルの通りです。理由はざっと書くと↓こんな感じですね。

• EC2 インスタンスには AWS Shield Standard が適用されない。DDoS 攻撃とか受け放題
• IP アドレスが変わったらアクセス URL が変わるのでいろいろめんどい
• 冗長構成や負荷分散、AutoScaling にも対応できない、などなど

Route53 でドメイン管理しつつ、A レコードを ELB のエイリアスで登録しておけば、EC2 インスタンスに何かあっても ELB のターゲットに復旧した EC2 インスタンスを付け替えるだけでオールオッケーです。こうすることで、上で書いたやめた方がいい理由の内容にすべて対応できますね。

これまでは、Route53 や ELB を使う理由として抽象化が 1 つのキーポイントだったと思いますが、それだけではなくて AWS Shield が DDoS や SYN フラッドから守ってくれるので、ユーザが意識しなくても Web アクセスに対するセキュリティレベルがグンと上がる、というのが抽象化に並ぶポイントになります。

最後に

普段意識していないから忘れがちですが、こういう内容は提案や設計でお客さんと話する時にとても大事だと思いますので、時々思い出してあげましょう。というか AWS Shield の存在が薄すぎてかわいそうなので大事にしてあげましょう（そう思ってるの私だけ？