AWS エンタープライズサポート加入の自動化

AWS

情報システム部でAWS周りの運用保守をしている「ねぎ」です、こんにちは！

今回の記事では、保守運用の中でもそこまで多く工数は使わない、、、けど対応しなければならない回数が多くて面倒くさいと私は感じている、AWSアカウント発行時に行うエンタープライズサポート加入の自動化について書きたいと思います！

AWSのサポートレベル

すでにご存知の方も多いと思いますが、AWSサポートのレベルは以下の4つがあります。(記事作成 2022年11月7日時点)

  • デベロッパー
  • ビジネス
  • エンタープライズ On-Ramp
  • エンタープライズ

弥生では2022年7月より一番上位の「エンタープライズ」サポートに加入をしております。

AWS Support プラン比較 | デベロッパー、ビジネス、エンタープライズ、エンタープライズ On-Ramp | AWS Support

エンタープライズサポート加入後に行う運用保守

エンタープライズサポート加入時点の対象AWSアカウントはいくつあっても自動的にエンタープライズサポートに加入となります。 エンタープライズサポート加入時にビジネスのプランで加入していたとしても、エンタープライズサポートに自動的に引き上げてくれます。

ただし、エンタープライズサポート加入以降に追加されたAWSアカウントについては、自動的にエンタープライズサポートにはなりません。

じゃあ何をする必要があるかというと、サポートからエンタープライズサポートにして欲しい旨を起票する必要があります。

AWSアカウントが増えれば増えるほど、起票を実施しなければならないということです。

面倒ですよね、面倒だと思っています。少なくとも私は面倒だと思いました。

自動化しましょう。

エンタープライズサポート加入を自動化する

自動化のお話に入る前に、弥生の状況を少しご紹介します。

弥生ではControlTowerというAWSのサービスを使って、マルチアカウント環境で運用をしています。

AWSアカウントについては随時、新規発行を行っています。

2022年に入ってからは、以下のような推移でAWSアカウント数が増加していました。

年月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月
アカウント数 45 47 49 59 56 60 66 69 72 75

1月から10月までに増えたアカウント数は「30」、エンタープライズサポートに加入した7月からだと「9」アカウント増えていました。

自動化していないと9回はエンタープライズサポートに加入する対応をしなければならないといった状況でした。

9回だったら自動化しなくても大丈夫でしょ！

そうかもしれません、9回なら、、、

弥生では今後もアカウント数が増加していく傾向はしばらく続いていくと思っています。

やっぱり自動化ですよ、自動化。いつかあの日自動化しておいて良かったと、そう思う日が来るのです。

さてここからが本題の自動化です。

ControlTowerでアカウント作成をする際のイベント情報を、EventBridgeで受け取り、EventBridgeからCodeBuildを呼び出して、サポートAPIを使ってエンタープライズサポート加入のための起票を行うという流れで自動化を実現しました。

自動化を行った構成

それでは一つ一つ説明します。

ControlTowerは画面の入力項目に従ってAWSアカウントの新規発行をします。（ここは自動化と関係がないので、手順については省きます）

続いてEvnetBridgeですが、入力ルールの例としては以下となります。

{
  "source": ["aws.controltower"],
  "detail-type": ["AWS Service Event via CloudTrail"],
  "detail": {
    "eventName": ["CreateManagedAccount"]
  }
}

ControlTowerからアカウント作成時のイベントを受け取るための入力パターンとなります。

続いて入力トランスフォーマーです。

入力パス

{
  "account": "$.detail.serviceEventDetails.createManagedAccountStatus.account.accountId"
}

入力テンプレート

{
   "environmentVariablesOverride": [ 
      { 
         "name": "ACCOUNT_ID",
         "type": "PLAINTEXT",
         "value": <account>
      }
   ]
}

入力パスでアカウントIDを抽出し、CodeBuildの変数として渡すために、入力テンプレートを使って抽出したアカウントIDを「ACCOUNT_ID」という変数で上書きする設定を入れます。

次はCodeBuildです。

CodeBuild以外のAWSサービスでもサポートケースを起票するためのAPIを呼ぶことが出来るやり方であればもちろん問題ありません。

私はCodeBuildが好きです。それだけの理由です。

CodeBuildの環境はlinuxを選択し、その他の設定はデフォルトで問題ないかと思います。

サービスロールに付与する権限は、サポートAPIでケースを作成できる権限（support:CreateCase）を付与しておきます。

環境変数は、名前：ACCOUNT_ID、値：＜空白＞、タイプ：PLAINTEXTを設定しておきます。

EventBridgeの入力トランスフォーマーで設定したアカウントIDが上書きされます。

CodeBuildのBuildspecに以下のような内容を記載します。

aws support create-case --language ja --service-code "customer-account" --category-code "other-account-issues" --subject "エンタープライズサポートアクティベーション依頼" --communication-body "以下のメンバーアカウントをエンタープライズサポートへ変更してください。メンバーアカウントID："$ACCOUNT_ID --region us-east-1

CodeBuildの上記コマンドが実行されることにより、エンタープライズサポート加入のためのサポートケースが起票されます。

起票後は約1営業日程度で、AWS担当の方から該当のAWSアカウントに対してエンタープライズサポートに加入した旨の連絡が来ることで完了となります。

あとがき

どうでしたでしょうか？

地味な自動化だと思いますが、アカウント発行の頻度が多くなればなるほど、面倒になってくる運用だと思います。

そんなに大変じゃないから、ちょっと作業するだけだから

と、自動化しないで放置していると、いつの間にか色んな運用に追われて、忙しくて自動化が出来ないという負のループになってしまうかと思います。

自動化の醍醐味がクラウドサービスでもあるのではないかなと思いますので、地道な自動化によってより快適な運用保守、並びにAWSサービスの活用を今後も目指していきたいと思います。

一緒に働く仲間を募集しています

弥生では一緒に働く仲間を募集しています！

弥生で働くことに興味がありましたら、求人一覧をぜひご覧ください。

herp.careers