継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

NAT Gateway の自動作成・削除を SSM オートメーションを使って回してみた

タダです.

ずっと起動しておく必要ないけど,特定の時間帯にだけ自動作成・削除される NAT Gateway が必要になり,SSM オートメーション を使ったパターンを考えてみたのでこの記事でどんなことをやったかを紹介します.

概要

SSM Automation の AWS-UpdateCloudFormationStack を使って NAT Gateway の自動作成と削除を定期実行しています.このオートーメーションでは自動で作成される Lambda が指定して CloudFormation テンプレートでスタックの更新をかけます.パラメーターとして3つの定義が必要です.

パラメーター名 備考欄
LambdaAssumeRole CloudFormation を実行するための Lambda 用 IAM ロール
StackNameOrId 更新をかける CloudFormation スタック名
TemplateUrl 自動作成と削除の S3 にアップロードしたテンプレートまでの URL

docs.aws.amazon.com

NAT Gateway の作成と削除のテンプレートを予め S3 にアップロードしておくのですが,以下のようなテンプレートをアップロードしてます.Conditions の中で作成と削除それぞれの処理を分岐しています.また,作成のテンプレートを使って NAT Gateway を作成しておきます.

作成用テンプレート

Parameters:
  CreateNatGateway:
    Description: Enable NAT Gateway.
    Type: String
    Default: true

Conditions:
  CreateNatGateway:
    !Equals [true, !Ref EnableNatGateway]

Resources:
  NatGatewayRoute:
    Type: AWS::EC2::Route
    Condition: EnableNatGateway
    Properties:
      RouteTableId: rtb-xxx
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId: !Ref CreateNatGateway

  CreateNatGateway:
    Type: AWS::EC2::NatGateway
    Condition: EnableNatGateway
    Properties:
      AllocationId: !GetAtt NatGatewayEIP.AllocationId
      SubnetId: subnet-xxx

  NatGatewayEIP:
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

削除用テンプレート

Parameters:
  CreateNatGateway:
    Description: Enable NAT Gateway.
    Type: String
    Default: false

Conditions:
  CreateNatGateway:
    !Equals [true, !Ref EnableNatGateway]

Resources:
  NatGatewayRoute:
    Type: AWS::EC2::Route
    Condition: EnableNatGateway
    Properties:
      RouteTableId: rtb-xxx
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId: !Ref CreateNatGateway

  CreateNatGateway:
    Type: AWS::EC2::NatGateway
    Condition: EnableNatGateway
    Properties:
      AllocationId: !GetAtt NatGatewayEIP.AllocationId
      SubnetId: subnet-xxx

  NatGatewayEIP:
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

そして,オートメーションの実行のロールと Lambda 用の IAM ロールも定義しておきます.オートメーションの実行のロールには SSM オートメーションの実行と Lambda を作成するための CloudFormation の権限を与えておき,Lambada の IAM ロールには CloudFormation の変更権限と NAT Gateway の作成と変更権限を与えておきます.

SSM オートメーションの定期実行設定

定期実行設定は CloudWatch Events で行い,作成と削除それぞれ作成します.これで定期的に実行され,事前に作ったスタック に対して更新がかかり,作成の時は NAT Gateway 作成とルートテーブルへの関連づけ処理が走り,削除の時は NAT Gateway 削除とルートテーブルから NAT Gateway の経路削除が走ります.なお,EIP は削除対象に入っていないようにしているので定期実行時には作成や削除されず元々確保した EIP を使えます.

f:id:sadayoshi_tada:20210206140833p:plain

まとめ

NAT Gateway の自動作成と削除を SSM オートメーションを使って実現したのでその設定内容をまとめました.Lambda を使ってこの辺を仕組み化することも考えたのですが,Lambda をメンテするよりも CloudFormation テンプレートを適宜使い分けて定期実行するように SSM オートメーションで定義するほうがメンテのコストは低いと思いこの手法を使いました.同じことをやりたいと思っている方の参考になれば幸いです!

関連記事

sadayoshi-tada.hatenablog.com

AWS Backup のクロスアカウント管理によるバックアップを行う

タダです.

別記事で AWS Backup で EC2 の AMI 取得をやってみたのですが,今回は AWS Backup のクロスアカウントでの AMI 管理をやってみようと思って設定したのでこの記事で設定内容をまとめていきます.

docs.aws.amazon.com

AWS Backup のクロスアカウント設定

クロスアカウントでのバックアップを管理するには AWS Organizations のサービス設定で 有効化を行います.これで管理アカウントでの AWS Backup アクセスができるようできます.

f:id:sadayoshi_tada:20210204010141p:plain

また,AWS Backup の Backup のメニューからクロスアカウント管理ページに移動し,サービスアクセスを有効化します.これで設定は完了です.バックアップを行う対象アカウントでバックアッププランを設定すればバックアップの管理を一元的に確認できるはずです.バックアッププランは前回記事と同様に他のアカウントでも設定したとします.

f:id:sadayoshi_tada:20210204005553p:plain

クロスアカウントモニタリングから取得された各アカウントの AMI バックアップをアカウント別で確認できました.

f:id:sadayoshi_tada:20210204010516p:plain

まとめ

簡単ですが,AWS Backup のアカウントまたぎでの設定を行ったのでその内容をまとめました.設定自体は簡単で,統合管理をしたい場合はクロスアカウント管理設定で行うと見やすく管理できます.

関連記事

sadayoshi-tada.hatenablog.com

カスタムランタイム の Lambda をコンテナイメージ化してみた

タダです.

Lambda のアップデートで昨年の re:Invent でコンテナサポートされました.

aws.amazon.com

自前のコンテナイメージを実行できるならカスタムランタイムで設定している Lambda の処理をコンテナイメージ化してみようと思い,下記の記事でカスタムランタイムで実行していた Lambda をコンテナイメージ化して変更してみました.この記事で対応内容を書いていきます.

sadayoshi-tada.hatenablog.com

コンテナサポート対応設定

実行環境のコンテナは ECR に格納する必要があり,これまでとの違いは Dokcerfile を用意する必要がある点です.AWS から Lambda のコンテナイメージが提供されており,そのイメージを使っていきます.

サポートされているすべての Lambda ランタイム (Python、Node.js、Java、.NET、Go、Ruby) のベースイメージを提供しているため、コードと依存関係を簡単に追加することができます。Amazon Linux ベースのカスタムランタイム用のベースイメージも用意しており、これを拡張して Lambda ランタイム API を実装する独自のランタイムを含めることができます。

f:id:sadayoshi_tada:20210127081551p:plain gallery.ecr.aws

ECR に格納する Dockerfile を次のように定義しました.AWS CLI を使った処理を行ったので AWS CLI を入れて,カスタムランタイムで使っていた bootstrap とカスタムランタイムの関数内で書いていたロジックをスクリプト化して実行するようにしました.

Dockerfile

FROM public.ecr.aws/lambda/provided:latest
RUN yum install -y awscli
COPY bootstrap /var/runtime/bootstrap
COPY xxx.sh /var/runtime/xxx.sh
RUN chmod 755 /var/runtime/bootstrap /var/runtime/xxx.sh
CMD ["xxx.handler"]

bootstrap

#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
  HEADERS="$(mktemp)"
  # Get an event. The HTTP request will block until one is received
  EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
  # Extract request ID by scraping response headers received above
  REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
  # Run the handler function from the script
  RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
  # Send the response
  curl -X POST "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response"  -d "$RESPONSE"
done

ECR にコンテナイメージをプッシュする

コンテナイメージを ECR に格納していきます.ECR で表示するコマンドを順次実行していきます.

# ECR ログイン
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin xxx.dkr.ecr.ap-northeast-1.amazonaws.com
# Dockerfile のビルド
docker build -t xxx .
# タグつけ
docker tag xxx:latest xxx.dkr.ecr.ap-northeast-1.amazonaws.com/xxx:latest
# イメージのプッシュ
docker push xxx.dkr.ecr.ap-northeast-1.amazonaws.com/xxx:latest

Lambda 関数の設定

ECR にコンテナイメージを格納できたら Lambda 関数を作っていきます.これまでの差異は関数作成時にコンテナイメージを選択することです.前の工程でプッシュしたイメージのlatestバージョンを選択して,他の設定を行って Lambda 関数をデプロイします.

f:id:sadayoshi_tada:20210129004551p:plain f:id:sadayoshi_tada:20210129004640p:plain

デプロイ後のコード部分を見に行くとコンテナイメージがデプロイされているからコードは見えない仕様になっています.イベント発火後の処理をコンテナ内で設定しておけばこれまで通りカスタムランタイムの Lambda で実行していたのと同様の処理を実行できました.

f:id:sadayoshi_tada:20210129004856p:plain

まとめ

カスタムランタイムの Lambda をコンテナイメージに置き換えたのでその対応をまとめました.カスタムランタイムの Lambda をデプロイするのに Lambda Layer の設定が必要でコードの他にも管理するものがありましたが,コンテナイメージをメンテするだけで同じことができるようになったのは管理範囲が狭まりました.開発時にコンテナイメージを使って開発しているのであれば,開発・デプロイがしやすいのかと思いました.自社でも普及していきたいと思います.

JTF2021w で『スタートアップ企業でのAWS マルチアカウント運用の実践と普及』と題して#推しテクを発表した

タダです.

1/24 開催の「July Tech Festa 2021 winter #推しテク総選挙」にて「スタートアップ企業でのAWS マルチアカウント運用の実践と普及」という AWS 管理をしていくなかでアカウントを分割し,組織に分離したアカウントを使ってもらえるよう浸透させていく取り組みをお話ししました.この記事で発表を振り返ってきます.

techfesta.connpass.com

発表資料

発表資料はこちらです.

動画も出ました.

www.youtube.com

当日の発表は後日 YouTubeアーカイブされるので他のセッションも見えてなくて残念...と思っている方は是非登録することをオススメします. www.youtube.com

他のセッションの発表資料も connpass の資料一覧から見ることができます.

techfesta.connpass.com

発表の振り返り

発表は以前の JAWS-UG 朝会で発表していたものをアップデートした内容なんですが,当時はマルチアカウント化しはじめた頃でとりあえずステージング出来たくらいのタイミングでした.その頃からステージングが使われず,普及のために動き出したことがアップデートとして話せたと思います.

sadayoshi-tada.hatenablog.com

発表で言えてなかったこととして,課題に感じたアーキテクチャの変更が1アカウントのままだとやり辛いことの中でシステム全体も含んでいたのですが,デプロイ周りも今自動化できているものもあれば手動デプロイしているものもあります.手動デプロイをなくすための検証もし辛いなと思っていたので環境を分離したかった感じです.

あと,副次的な効果ですが,ステージングをつくったりして環境を分離したことでよかったのが開発チームとの密な連携が取れている気がします.うちは社内システムと外向けシステムで大きく分かれているんですが,外向けは CTO が見ているので普段からコミュニケーションを取りやすいものの社内システムチームは会社の構造上アカウント分離していたころフロアが違ったりあんまり接点がなかったのですが,この機会に接点を持ってコミュニケーションを取れるようになりました.この繋がりがあったからステージング使われてないとかじゃあどうする?って話もしやすくなったのを実感したので,他チームとの連携を作るのも今のロール的に不可欠だなぁと痛感しました.

質問いただいた事

Masa さんから ssosync を使って運用しているのかという質問をいただきました.今のところ使ってなくても ID が同期されないといったトラブルに見舞われていないので使っていないのですが,ssosync の存在を知らなかったのでこの機会に試して適用を検討させていただきます.教えていただきありがとうございました🙇‍♂️

Tamakiさんからどうして SSO を絶対やりたいというツイートしたのかって質問をもらったのですが,緊張してうまく答え切れていなかったので改めて回答させてもらいます.前職でシングルサインオンのサービスを使っていてシングルサインオンの便利さやメリットを実感できていたからこそパスワードの強度や管理が人依存になっている自社では絶対パスワード認証ログインを辞めたいと思ったから SSO を入れたかったのです.

sadayoshi-tada.hatenablog.com

登壇環境

登壇環境については非常にかっこいい感じにしたかったのですが,全然映えはないですw 他の方も見てみたい...

f:id:sadayoshi_tada:20210125094448p:plain

まとめ

登壇の振り返りや質問いただいたことを書いてみました.オンラインイベントなので喋る時はもちろん1人ですが,ツイートを追ったりして反応をくださっているのほんとうにありがたかったし,内容も良いという反応があると嬉しすぎてニヤけますね...いつも見る側の立場だったので登壇させてもらえて貴重な機会をいただき本当にありがとうございます.その辺の気持ちはこのツイートにしたためました.心残りとしては Zoom ならではの発表なのに背景をダンベルまみれにしなかったことくらいですが,運営の皆さん,登壇者の皆さん,聞いてくださった皆さんとても暖かく接してくださって登壇者としても楽しくイベント参加できました! これはオフラインとしてもイベントが実現された時にも登壇できるよう日々の取り組みをやってこうと思います.改めてありがとうございました!!

EC2 の AMI 取得を AWS Backup で管理する

タダです.

既に多くの方の記事は出ていますが,AWS Backup を使って EC2 のバックアップ取得を初めてやったので設定方法をこの記事にまとめていきます.

AWS Backup とは

AWS Backup はマネージドのバックアップサービスでバックアップポリシーに基づいて自動的にバックアップを一元的に管理できるのが特徴です.また,バックアップを使っての復元も可能です.バックアップおよびリストアがサポートされている AWS リソースは次のものです.

担当するシステムにおいて EC2 のバックアップが保持されてない状態だったので AWS Backup を使って AMI バックアップを自動化することにしました.

AWS Backup の設定

AWS Backup の設定は大きく2ステップでできます.

1. バックアッププラン/バックアップルールの設定

まずは,バックアッププランとバックアップルールを設定します.バックアッププラン名とルール名に任意の値を入力し,今回は毎日 AM 12:00 にバックアップを取る設定を定義しています.

f:id:sadayoshi_tada:20210120163138p:plain f:id:sadayoshi_tada:20210120163145p:plain

また,バックアップは1世代保持するように下記の設定を入れました.その他の設定はデフォルト設定にしています. f:id:sadayoshi_tada:20210120163312p:plain

2. バックアップのリソースを紐づける

バックアッププランによってバックアップされるリソースを設定します.リソースを割り当てるをクリックして,追加していきますが,入力するのは割り当て名リソースを割り当てるのセクションです.画像のリソース設定ですとリソースタグが Name の中でも hoge とついているリソースをバックアップする設定になります.

f:id:sadayoshi_tada:20210120163447p:plain f:id:sadayoshi_tada:20210120163501p:plain

以上で AWS Backup の設定が完了です.

バックアップの結果確認

AMI でバックアップが取れていることを確認できたのでバックアップが意図通りに動作しています.

f:id:sadayoshi_tada:20210120145853p:plain

まとめ

AWS Backup で AMI バックアップを取ってみました.設定は簡単でこれまでは仕組み化が必要だった部分がなくなったので運用負担が減りました.サードパーティの製品が使えなかったり,仕組み化したものをメンテナンスする負担から解放されたい場合おすすめの手法だなと思いました.次は Organizations と組み合わせてバックアップ方法を試してみようと思います.