CloudFormation で作成したリソースの変更や削除の制御方法をまとめた
また json をガシガシ書く日が始まりそうです。那須です。
CloudFormation 便利ですね。ある程度決まった形の構成を作る時なんかはテンプレート準備しておけばすぐにその構成を作れます。 まあ作るのは簡単なんですが、更新や削除ってすでに運用に入っていると心理的にやりにくかったりしますよね。 たとえば、このリソースだけは絶対変更させたくない！とか、削除されたら困る！とか。
というわけで、CloudFormation で作成したリソースの更新や削除についてどんな制御ができるのか、自分の頭の整理を兼ねてまとめてみました。
スタックポリシーで更新＆削除させない
スタック作成時にスタックポリシーを設定しておくと、指定された更新アクションができなくなります。 例えば、下記のように何も更新させないスタックポリシーを設定したとします。
{ "Statement": [ { "Effect": "Deny", "Action": "Update:*", "Principal": "*", "Resource": "*" } ] }
VPC で何か変更しようとすると…
そのまま進めると、スタックポリシーで拒否されてるよ！ってエラーが出てロールバックされます。
スタックポリシーを変更させない
じゃスタックポリシー変更しちゃえばいいんじゃないの？ということで、スタック更新時に一時的にスタックポリシーを上書きする場合があります。 これをやられたらダメな場合は、そのユーザに下記のような IAM ポリシーを適用しましょう。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "cloudformation:SetStackPolicy", "Resource": "*" } ] }
その後、スタック更新の流れで、このようにスタックポリシーを設定します。
{ "Statement": [ { "Effect": "Allow", "Action": "Update:*", "Principal": "*", "Resource": "*" } ] }
するとスタックポリシーをいじることはダメ！とエラーがでます。
スタックを削除させない
スタックポリシーはスタック内のリソースが対象でしたが、CloudFormation はスタックそのものも削除できるのでこれも気をつけないとダメですね。 スタックポリシーでいくら削除アクションを拒否してたとしても、スタックそのものの削除に対しては無力です。
まず、スタックそのものを削除させたくない場合は、スタックの削除保護を有効にします。
削除保護の変更をクリックして
有効化します。
削除保護が有効になっているのがわかりますね。
削除保護が有効の場合は、スタックを削除しようとしてもこのように削除させてもらえません。
スタックの削除保護を変更させない
じゃあスタックの削除保護を無効にしてしまえばいいよね？ってことで、削除保護設定を変更されるとスタックを削除されてしまう可能性がありますよね。 それを防ぐために、IAM ポリシーで削除保護の設定変更を下記のように制御します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "cloudformation:UpdateTerminationProtection" ], "Resource": "*" } ] }
この IAM ポリシーがついているユーザで削除保護の設定を変更しようとすると、このようなエラーになって削除保護設定を変更できなくなります。
スタックが削除されてしまってもリソースは削除しない
ミラクルが起きてスタック削除されてしまう可能性はないの？本当に！？と心配な方もいらっしゃるかと思います。 私もわりと心配性なので、可能性は０ですよ！って言い切る自信はまあないです。 そんな方のために DeletionPolicy があります。
例えば NACL で絶対守らせたい内容があって、それだけは削除させたくない！って場合は、下記例のように "DeletionPolicy" : "Retain" を対象リソースに追加しておきます。全部削除されたくないなら、全リソースに追加するだけです。
{ "Type": "AWS::EC2::NetworkAcl", "DeletionPolicy" : "Retain", "Properties": { "VpcId": { "Ref": "VPC" }, "Tags": [ { "Key": "Name", "Value": "mecha-daiji" } ] } }
頻繁に更新や削除を制御する場面はないかもしれないけど
知らないより知ってた方がいざという時にすぐ対応できるのでいいですよね。
トライアルですがリモートワークが BeeX で始まりました
最近楽しいことがたくさんあって気分は最高です、那須です。
久々に技術とは関係ないことを書いてみようと思います。
私が所属している BeeX では、今日からリモートワークトライアルが始まりました。 私はすでにほぼ毎日リモートワークですが、他のメンバーは一部の人だけが自由にやっている、という状態でした。 今回はその様子をお伝えします。
リモートワークを始めるにあたって会社が場所を提供
うちの場合は、NewWork という東急さんが展開しているシェアオフィスを今日から自由に使えるようになっています。
www.newwork109.com
関東はあちこちにありますが、私は兵庫県に住んでいるのでこの勉強カフェに行ってみる予定です（今日はたまたま東京にいます）
www.newwork109.com
ちなみに、私は普段は↓このシェアオフィスを借りて最高の環境で仕事させていただいてます！
大人のワーカーが選ぶ会員制ワークスペースー Joe's Workspace Busico.
リモートワーク＝家で仕事 ってイメージの方もいると思いますが、家にいると集中できなかったり、私の場合だと子どもたちと遊びたくなるので、無理やり外に出るようにしてます。 そして早めに家に帰ってきてから、ごはん、お風呂、続きのタスクを集中してやる、って流れにしています。
初日の様子
初日から早速使ってみたメンバーが Slack で状況を書いてました。みんな外の世界に興味津々です。
なんで全社でリモートワークが始まったのか？
分かりませんｗ
たまたま私がリモートワークで採用されてそれをきっかけにやってみるかーって思ったのか、リモートワークという言葉が巷によく出てくるようになったからなのか、事情は知らないのですがまあとりあえずいいことなのでうまく根付くといいなーと思っています。Facebook や Twitter で誰かが書いてくれるのを期待しておきますｗ
リモートワークって実際どうなの？
私はリモートワークを始めるといろんないい面が見えてきました。
- 家族と一緒に暮らせる（これが一番！）
- 家でも仕事できるので通勤って概念が薄くなる
- 仕事のプロセスが見えないので結果を強く意識するようになる
とまあ、ほかにもありますがほんとにいいことが多いです。3 番目に書いた結果の話ですが、これは人によっては嫌な面なるのかもしれません。
個人的に思うリモートワークが絶対必要な理由
労働人口が減るのが分かっている一方で、仕事したくてもできない人たちがいます。リモートワークって、この仕事したくてもできない人たちがいい条件で仕事できる手段になりえると思うんですよね。
例えば、
- 私のように関西やその他関東圏以外に住んでるけど家庭の事情で関東にいけない、でも素晴らしいスキルはある
- 育児等でしばらく仕事してなかったけど少しずつ時間ができてきたので昔のように仕事したい、でもやりたい仕事が関東圏にしかない
- 通勤そのものが苦痛でそれだけで体力消耗して仕事がはかどらない、自分のペースで仕事したいけど今の会社がそれを許してない
というふうに困ってる人たちが生き生きと仕事できるいい仕組みなので、私たちのようなエンジニア/コンサルタントにとっては必要な仕組みだと思います。 というか、これが当たり前になる社会に早くなってほしいと心から思っています。
まだトライアルだけど本稼働させたい
このトライアルでリモートワークしてよかった点やこれは改善した方がいい点を全員で洗い出して、リモートワークを正式に運用できるように本気出してやっていこうと思います。トライアルで終わってしまうのは嫌だｗ
一緒にリモートワークしてくれる人募集！
BeeX では AWS/Azure/GCP 等のクラウドエンジニアや、SAP テクニカルコンサルタントを募集してます！
採用ページは今リニューアルの真っ最中でもうすぐコンテンツが増えます。
BeeX に来て、仕事内容も働き方もバージョンアップしませんか？
とりあえず話を聞きたい、だけでも OK なのでいつでもご連絡くださいね！
プロフィールに Twitter のリンクをつけてますので、そこから DM なりしてもらうか、BeeX 採用ページから連絡いただくか、手段はなんでもいいので皆さんからの連絡まってますね！
www.beex-inc.com
