snaqme Engineers Blog

おやつ体験BOX snaq.me エンジニアによる開発プロダクトブログ

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

こんにちは!SRE を担当している多田です(@tada_infra).

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 マルチアカウント運用の実践と普及』と題して#推しテクを発表した

こんにちは!SRE を担当している多田です(@tada_infra).

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

techfesta.connpass.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 ならではの発表なのに背景をダンベルまみれにしなかったことくらいですが,運営の皆さん,登壇者の皆さん,聞いてくださった皆さんとても暖かく接してくださって登壇者としても楽しくイベント参加できました! これはオフラインとしてもイベントが実現された時にも登壇できるよう日々の取り組みをやってこうと思います.改めてありがとうございました!!

元記事

元記事はこちらです.

胸熱! Aurora MySQL in-place upgrades 機能を使って MySQL 5.6 => 5.7 にアップグレードする

あけましておめでとうございます! SRE を担当している多田です(@tada_infra).

re:Invent 中に Aurora MySQL 5.6 から 5.7 へアップグレードすることが容易になるアップデートが出るアナウンスがあり,業務で担当しているデータベースは MySQL 5.6 なので期待していたら遂に出ました! MySQL のバージョンの追随をしていきたいと思っており,スナップショットからの復元不要かつデータベースのデータを移行したりが不要でアップグレードできるんじゃないかと期待していたので, Aurora MySQL の in-place upgrades 機能を試してみました.検証してみた内容この記事にまとめていきます.

aws.amazon.com

機能の概要

in-place upgrades 機能の特徴はバックアップによる復元でのバージョンアップではなく数クリックでアップグレードできるところが特徴です.

Instead of backing up and restoring the database to the new version, you can upgrade with just a few clicks in the Amazon RDS Management Console or by using the AWS SDK or CLI.

To upgrade to Aurora MySQL 5.7, select the "Modify" option on the AWS Management Console corresponding to the database instance you want to upgrade, choose the version of Aurora MySQL 5.7 you want to upgrade to, and proceed with the wizard. The upgrade may be applied immediately (if you select the "Apply Immediately" option), or during your next maintenance window (by default). Please note that in either case, your database cluster will be unavailable during the upgrade and your database instances will be restarted.

更にドキュメントによるとすべてのデータを新しいクラスタボリュームにコピーする必要がなく,アプリケーションの構成変更を最小限に抑えアップグレードされたクラスタのテストも少なく抑えられるとあります.また, in-place upgrades 機能の仕組みとして Aurora クラスタをシャットダウンし,トランザクションロールバックや undo purge などの未処理の操作を完了させるのも特徴です.

This technique keeps the same endpoint and other characteristics of the cluster. The upgrade is relatively fast because it doesn't require copying all your data to a new cluster volume. This stability helps to minimize any configuration changes in your applications. It also helps to reduce the amount of testing for the upgraded cluster, because the number of DB instances and their instance classes all stay the same.

The in-place upgrade mechanism involves shutting down your DB cluster while the operation takes place. Aurora performs a clean shutdown and completes outstanding operations such as transaction rollback and undo purge.

関連ドキュメント

docs.aws.amazon.com

in-place upgrades の実践

in-place upgrades を試しに使ってみます.なお,アップグレード前のバージョンは 5.6.mysql_aurora.1.22.2 になります.

f:id:sadayoshi_tada:20210113191843p:plain

Aurora クラスターのバージョン変更

Aurora クラスターのバージョン変更を行います.対象クラスターを選んで 変更 >バージョンのセクションで今回は最新のAurora(MySQL 5.7) 2.09.1 を選択して他のパラメーターをいじらずに次のページに遷移します. f:id:sadayoshi_tada:20210114091211p:plain

変更の確認画面で変更対象の確認をしますが,バージョンアップグレードに伴いクラスターパラメーターグループ,DB パラメーターグループも自動で 5.7 のものに変更になっています.すぐに適用を選択し変更を行います.変更後,少し経つとステータスが アップグレード に遷移します.

f:id:sadayoshi_tada:20210114091504p:plain f:id:sadayoshi_tada:20210114092024p:plain

自分の検証環境では約10分ほどでアップグレードが完了しました.なお,アップグレード後はバックトラックを有効化していてもアップグレード前の時間帯に戻せないとドキュメントに記述があるのでこの点注意です. f:id:sadayoshi_tada:20210114094051p:plain f:id:sadayoshi_tada:20210114102019p:plain

アップグレード中のイベント

イベントメニューよりアップグレード中のイベントを確認することができるので,進行状況を確認したい場合はイベントメニューから参照ください.また,ドキュメントにも記載があるので合わせて確認するよいでしょう.

f:id:sadayoshi_tada:20210114093525p:plain f:id:sadayoshi_tada:20210114093614p:plain

アップグレード前後のバージョン確認

in-place upgrades 実行と合わせてアップグレード前後の MySQL クライアントに接続しバージョンアップグレードの状況を確認してみましたアップグレード実行後に一度 DB コネクションがロストするが,バージョンアップグレード完了後再度クエリを投げるとバージョン情報を返すようになるところを確認できました.

mysql>
mysql> select version(); <= バージョンアップグレード前
+------------+
| version()  |
+------------+
| 5.6.10-log |
+------------+
1 row in set (0.00 sec)
mysql> select version(); <= バージョンアップグレード実行後一時的にコネクションがロスト
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
mysql>
mysql> select version(); <=バージョンアップ完了後再接続
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    17
Current database: *** NONE ***
+-----------+
| version() |
+-----------+
| 5.7.12    |
+-----------+
1 row in set (0.02 sec)

まとめ

まずは,Getting Started として Aurora MySQL in-place upgrades 機能を使って MySQL 5.6 から 5.7 にアップグレードしてみました.バージョンが追随できていないし,5.7 使ってみたいと思ってもこれまでのオペレーションだと再度クラスターを作り直す手間があったと思います.,実際の移行の時は計画しっかりし適用箇所を考えなければいけないと思いますが,オペレーションが簡単に行えるのでこの機能は検討して使っていければと考えてます.

元記事

元記事はこちらです.

2020年終わりに

こんにちは スナックミー CTOの三好です @miyoshihayato 先月にスタートした弊社の技術ブログですが、まだ私は書いてなく、最低1本今年中に書きたかったので書きます。

スナックミーはどういうサービスでエンジニアの関わり方どうなっているのか長くなりすぎず書いていきます。 時間がない方は↓↓をざっとでもいいのでご覧ください

※ 適時スライドはアップデートしていきます

おやつ体験 snaq.me

snaq.meの概要を説明させてください。

f:id:snaqme-labs:20201228194557p:plain
スナックミーの概要

snaq.meがお届けするのは、お菓子という単なる「モノ」ではなく、おやつ時間、そしてワクワクしたり楽しんだりする体験、つまり『おやつ体験』です。 "毎月変わる100種以上のおやつ"から、食べきりサイズ(約20-30g)で8つお届けします。全てのおやつが人工添加物、ショートニング、白砂糖など不使用。ナチュラル素材のみからできているのが特徴です。 ジャンルはクッキー・パウンドケーキといった焼き菓子からドライフルーツ・ナッツ・米菓、羊羹・どら焼きなどの和菓子まで幅広く取り扱っています。

あらゆる声を大事にする

お客さまとのやり取りはLINEをサービス開始当初から導入しています。LINEを用いることでメールとは違い気さくに連絡をいただける方が多く、ポジティブや厳しいことなどさまざまなお声いただきます。そのような声を社内全体に共有するチャンネルが存在し、共有することでチャンネルが活性化し様々な声から施策が生まれることが多々あります。そのため、直接お客さまと関わらないのメンバーでも距離は近く感じられます。

データの活用

お客さまには届いた後におやつの評価や次回以降これを食べたいことを主張できるリクエストなどアクションをとってもらうことが可能で f:id:snaqme-labs:20201228202315p:plain お客さまの声や評価・リクエストのデータを用いて商品開発や次回お届けするおやつを決定しています。

製造から発送準備まで一貫

弊社特徴の一つなのが、このロジスティックス周り

  • 製造から発送準備までを内製化

  • 同じビル内で製造や出荷作業(ピッキング)

f:id:snaqme-labs:20201228205522p:plain 内製化し同じビル内で作業をしているので、どのようにおやつがパックされ、出荷(箱詰め)されてお客さまの手元に届くのかというこの流れを肌で感じることができます。 エンジニアは開発したシステムを利用する相手の顔が見えにくいですが、スナックミーではリアルなモノの流れを体験できます。

エンジニアとチームの関わり方

エンジニア限らずスナックミー全体は様々なチームと連携しながら事業を展開しています。 f:id:snaqme-labs:20201229210256p:plain

体験

snaq.meの購入前から購入後のマイページまで、ユーザーの”おやつ体験”に関わる様々な部分の構築を行なっています。 購入導線やおやつの好みの診断、評価・リクエストなどのページがあります。A/Bテストを通して各ページの改善や、データサイエンティストやデザイナーと共にUI/UXの向上などユーザーの体験向上を目指しています。 スナックミー全社員「永遠のβ版」という概念を持っており、お客様のフィードバックを活用しサービス改善を続けていき、製菓業界の枠組みにとらわれない挑戦を続けてまいります。

体験チームインタビューはこちら↓↓

おやつのテーマパークを一緒に作りませんか?

商品開発

今まで数千という商品を扱いユーザーの構成や行動、今までの商品に対する評価や味覚、食感の好み、リクエスト数、アンケートなどから得た知見をバイヤーやパティシエに共有し、多角的に話合いながら、新しいおやつの開発に役立てています。

商品開発チームインタビューはこちら↓↓

ほっこりおやつタイムを豊かにするデータ分析

オペレーション (ロジスティックス)

製造管理・出荷管理のソフトウェアの部分は弊社で開発しています。 例えば出荷作業に関しては、音声ピッキングを導入し、出荷効率を5~10倍アップさせることができました。 スナックミーの特徴として、

  • 毎月取り扱うおやつを数十%入れ替え (新商品含む)

  • 製造方法が異なる

  • 少量多種 (少ない量で多くの種類を製造)

などです。製造ラインは1種類1つがよくある中、スナックミーでは製造方法が異なり毎日数十種類存在する条件でもスケールできるオペレーション構築を目指していきたいと思っています。

f:id:snaqme-labs:20201229212405p:plain
出荷スペース

オペレーションチームインタビューはこちら↓↓

おやつを届けるオペレーションとエンジニアリング

CS

CSチームで考えることは

  1. 問い合わせを発生しない環境

  2. エンゲージメントを高める

この2つにあり、問い合わせを発生させない環境づくりは基本としてあるものの、エンゲージメントを高めることも意識的に行っています。 問い合わせが来るものだけを対応せず、私たちから連絡を取っていくようにしています。例えば評価内容から苦手な評価を多くつけている方には好き嫌いがないか確認し次回のボックスに活かすようにしています。

カスタマーサービスチームインタビューはこちら↓↓

様々な声を全体に浸透させていきたい

技術スタック

f:id:snaqme-labs:20201230184709j:plain

PHPからPythonへ移行中

フロントはReact × Redux、ロジスティックスはRails、基盤は AWS (一部GCP)でスナックミーを支え、開発手法はスクラムになっています。

最後に

2020年1月はエンジニアは4名だったメンバーが、2021年1月からエンジニアは8名(育休含む)に心強いメンバー増えます。 ここ1年で人数は倍になりスナックミーとしてできることが多くなってきました。しかし、成し遂げたいことは多くありメンバーは足りていません。一緒にブランドを構築し、技術力もアップしませんか? 少しでも興味もった方は気軽に連絡お待ちしております。

2021年は更なる飛躍の年に!! 外部発信も来年は精力的にやっていきます

engineers.snaq.me

www.wantedly.com

AWS SSO と GSuite を連携した認証のフローを作ってみよう!

こんにちは! SRE を担当している多田です(@tada_infra).

自分の会社では AWS アカウントのログイン形式がこれまでは IAM ユーザーによるアカウントに直ログインになっていたのですが,それを AWS SSO を入れてログイン方式を変更しました.ユーザー管理はデフォルトだと ID 管理が SSO で発行されるユーザーになりますが,業務で GSuite を使っているし,GSuite が IdP として使えるため,AWS SSO の IdP を GSuite で設定する場合の検証をしてみました.次の AWS ブログに手順が載っていたのでその内容に沿って検証したことをまとめます.

aws.amazon.com

aws.amazon.com

設定内容

SSO 側からサービスプロバイダー情報をコピーする

SSO 側の IdP を変更するために ID ソースを選択セクションで外部 ID プロバイダーの項目を選択します.次に,サービスプロバイダー情報のうちAWS SSO サインイン URL,AWS SSO ACS URL,AWS SSO 発行者 URLを控えておきます.

f:id:sadayoshi_tada:20201228060510p:plain f:id:sadayoshi_tada:20201228060818p:plain

GSuite でカスタム SAML アプリケーションを設定する

次に,GSuite 側の設定を行います.GSuite の管理画面に移動し,アプリ>SAMLアプリ>アプリを追加>カスタム SAML アプリの追加を選択します.カスタム SAML アプリの設定ウィザードに則って進みます.まずは,アプリ名ですがこれは任意の名前を入力して次に進みます.

f:id:sadayoshi_tada:20201228150432p:plain

次に,SSO の設定で使うため IdP メタデータをダウンロードして次に進みます. f:id:sadayoshi_tada:20201228150529p:plain

次に,サービスプロパイダの詳細設定を行います.SSO の URL を画像の箇所にコピーして転記していきます.署名付き応答にもチェックを入れて次に進み保存します

f:id:sadayoshi_tada:20201228153618p:plain

最後の属性マッピングは何もせず,完了ボタンを押します.これで GSuite の設定完了です.

f:id:sadayoshi_tada:20201228153909p:plain

SSO 側の連携設定

最後に,SSO と GSuite の連携設定を詰めていきます.はじめに GSuite のカスタム SAML アプリケーション追加設定時にダウンロードしていたメタデータをアップロードします.

f:id:sadayoshi_tada:20201228154223p:plain

アップロードが終わったら最後に確認画面です.ID ソースの変更を承認するのでACCEPTと欄に入力して ID ソースを変更します.問題なければ変更が反映されます.

f:id:sadayoshi_tada:20201228154304p:plain f:id:sadayoshi_tada:20201228154637p:plain

動作確認

最後に動作確認をします.SSO のエンドポイント URL https://XXX.awsapps.com/start にアクセスすると GSuite のユーザー認証に飛びます.

f:id:sadayoshi_tada:20201228154456p:plain f:id:sadayoshi_tada:20201228154738p:plain

ユーザー認証後,設定が問題なければ SSO のログイン後ページに遷移することを確認できました.

f:id:sadayoshi_tada:20201228154920p:plain

まとめ

AWS SSO の IdP として GSuite を設定する検証を行ったのでその内容をまとめました.自分が働く会社では GSuite が業務の中心にありその ID も使うので IdP として投入できれば,入社・退社の手続きでアカウントを消すだけで業務アプリケーションのログイン情報も消せてよく,IAM ユーザーによるログイン管理からも開放されるので効果を感じられました.同様の設定を考えられている方の何か参考になれば幸いです.

関連記事

labs.snaq.me

元記事

元記事はこちらです.

AWS Client VPN のユーザー認証を Active Directory 認証で行う

こんにちは! SRE を担当している多田です(@tada_infra).

AWS Client VPN の相互認証を検証した時の課題が VPN 接続ログに誰が VPN を使っているかが記録されてなかったことです.ユーザー認証の仕組みは Active Directory 認証と SAML 認証が用意されているのですが,この記事では Active Directory 認証を試した内容をまとめていきます.

docs.aws.amazon.com

検証シナリオ

シナリオとしては,これまで ACM のサーバー及びクライアント証明書による相互認証だったところを Active Directory 認証の基盤として Simple AD を使って認証するように変更しています.Simple AD を新規に作り,その中で認証するユーザーを作成・管理するような形に変更します.それ以外の設定は変わりません.

f:id:sadayoshi_tada:20201228002910p:plain

設定内容

ユーザー認証設定としてやるのは①Simple AD をプライベートサブネットに作成およびユーザーの作成,②ユーザー認証でエンドポイントの再作成および Client VPN 各種再設定です.

①Simple AD をプライベートサブネットに作成およびユーザーの作成

まず,ユーザー認証基盤である Simple AD の作成とユーザーの作成を行います.ただ,この記事では Client VPN の設定部分にフォーカスするようにしたいため,Simple AD の作成やユーザー作成部分は公式ドキュメントの説明に譲り,割愛します.

docs.aws.amazon.com

②ユーザー認証でエンドポイントの再作成および Client VPN 各種再設定

Client VPN エンドポイントを再作成していきます.変わるのは大きく2カ所です.1つは認証オプションをユーザー認証に設定し,①で作成した Simple AD を指定することと,DNS サーバーの箇所に Simple AD の DNS サーバーの IP アドレス2つを記載することが変わりますが,それ以外は初回の記事と同じ設定で定義しました.また,受信の認証ルールおよびルートテーブルも初回と二回目の記事と同様の設定に行いました.

f:id:sadayoshi_tada:20201228001612p:plain f:id:sadayoshi_tada:20201228001739p:plain

動作確認

エンドポイントの設定が完了後クライアント設定ファイルをダウンロードして VPN クライアントアプリのプロファイルを追加しました.接続を試みるとユーザー認証画面が表示されます.Simple AD の Administrator で認証してみます.

f:id:sadayoshi_tada:20201228002119p:plain

認証が成功し,VPN 接続のログを確認してみたところユーザー名の欄に Administrator が表示されているので意図した通りの設定ができました.

f:id:sadayoshi_tada:20201228002330p:plain

まとめ

Client VPN のユーザー認証方式として Active Directory の認証パターンを試したので検証内容をまとめました.Active Directory 認証パターンも試したのですが,もう1つの SAML 認証パターンも試したいと思っており,AWS SSO との連携をしてみたいと考えているのでその内容は次回以降の記事に書いていきます!

関連記事

labs.snaq.me

labs.snaq.me

元記事

元記事はこちらです.

AWS Client VPN の IP アドレスを固定化してインターネットと通信する

こんにちは! SRE を担当している多田です(@tada_infra).

AWS Client VPN 検証の続きです.前回の記事でプライベートサブネットの EC2 への VPN 接続が可能になりました.次に,VPN を繋いだ IP アドレスで業務システムへのアクセス制限をしたいといった要件で検証した内容です.

labs.snaq.me

検証シナリオ

Client VPN が接続できるネットワークと分離した社内のシステム用のネットワークがあると仮定します.要件として ELB + EC2 の業務システムにアクセスできる IP を絞りたいというものがあります.そこで,Client VPN に繋いでインターネットと通信する際は NAT Gateway を経由させることで IP アドレスを固定化します.

f:id:sadayoshi_tada:20201227185255p:plain

パブリックサブネットに Client VPN を関連づけることでインターネットに通信を出すことができますが,接続時にネットワークインターフェースが変わってグローバル IP アドレスも変わってしまうため固定化するために NAT Gateway を使っています.

f:id:sadayoshi_tada:20201227200427p:plainf:id:sadayoshi_tada:20201227200437p:plain

設定内容

前回記事内容に追加する形で設定を行う場合を想定します.やるのは①NAT Gateway をパブリックサブネットに作ってプライベートサブネットのルートテーブルに関連づける,②ルートテーブルと受信の承認ルールの変更する

①NAT Gateway をパブリックサブネットに作ってプライベートサブネットのルートテーブルに関連づける

NAT Gateway を作成し,パブリックサブネットに作ります.作成後,パブリックサブネットが使っているルートテーブルに関連づけます.設定の詳細は下記の解説ページに譲り割愛します.

aws.amazon.com

②ルートテーブルと受信の承認ルールの変更する

受信の承認ルールに0.0.0.0/0 の許可を追加します.ルートテーブルにも同様に0.0.0.0/0 の経路を追加します.

f:id:sadayoshi_tada:20201227203227p:plain

f:id:sadayoshi_tada:20201227203454p:plain

動作確認

NAT Gateway を経由できているのであれば,インターネットに接続できて EIP のアドレスで通信するはずです.検証用に NAT Gateway には 3.113.152.210 を EIP を設定しているので, 使用中の IP アドレス確認をしてみます.

意図通りの設定ができていることを確認できました.

f:id:sadayoshi_tada:20201227203856p:plain

まとめ

今回は,Client VPN を使いつつ IP アドレスの固定化を行ってみました.相互認証での検証は以上になるのですが,相互認証方式だと1つ課題があります.それは接続のログにユーザー名が表示されないことです.この課題を次の記事でユーザー認証方式に切り替えた内容でまとめます.

f:id:sadayoshi_tada:20201227204212p:plain

元記事

元記事はこちらです.