AWSのVPCでIPv6にするべきか?

AWSVPCIPv6が使えるようになってからしばらく経つ。

そろそろIPv6にすべきなのか、IPv4にすべきなのかを考えてみた。

結論

  1. 特にIPv6を使う理由はなく判断しかねるならまだIPv4にしておいたほうが無難。
  2. IPv6だけで行けると確信できるならIPv6オンリーに。
  3. IPv4を排除しきる自身はないがIPv6を使いたい理由があるならデュアル構成。

業務用だとまだ1のほうが無難な感がある。なんならIPv6が必要になった後でIPv6を導入して3に移行とか。2022年の今でも、ごった煮で雑多なサービスを詰め込むようなケースでは、見切り発車的にIPv6オンリーにするのは危なそうな感じ。

IPv6のメリットは?

公式の見解はこちらだが、個人的にはEgress-Only インターネットゲートウェイを使える点と、CIDRの設計に悩まされずに済む点がメリットかなあ、という気がしている。

その他、パフォーマンスの向上は期待すべきでないらしいが、EKSIPv6を使ったほうがネットワークルーティング設定をシンプルにできるとかで、時折例外があるようなので、使うつもりのサービス+IPv6で調べておくのもいいかも。

注意点

AWSのサービス自体、IPv6完全対応とは言い難い。簡単に作り直せるサービスならいいが、いったん走りだしたら手出しが難しくなるもの(業務用は通常そうだと思うが)は見切り発車にしないほうがいい。

参考

AWS CLIをMFA付きで使う際のbatファイル(Windows用)

公式で公開されているMFAのためのコマンドを毎回コピペコピペで実行するのは嫌すぎるので、簡略に――作り込むほどのものではないので――バッチファイルを作って使うことにした。

言うまでもなくWindows用である。

内容

一部マスキングしているが、下記のような内容となる。

set AWS_ACCESS_KEY_ID=
set AWS_SECRET_ACCESS_KEY=
set AWS_SESSION_TOKEN=

aws sts get-session-token --serial-number arn:aws:iam::XXXXXXXXX:mfa/XXXXXXXXXX  --token-code %1 > tmp.json

for /f "usebackq" %%A in (`type tmp.json ^|  jq -r ".Credentials.AccessKeyId"`) do set AWS_ACCESS_KEY_ID=%%A
for /f "usebackq" %%A in (`type tmp.json ^|  jq -r ".Credentials.SecretAccessKey"`) do set AWS_SECRET_ACCESS_KEY=%%A
for /f "usebackq" %%A in (`type tmp.json ^|  jq -r ".Credentials.SessionToken"`) do set AWS_SESSION_TOKEN=%%A

--serial-numberには、AWSのマネジメントコンソールのSecurity credentialsのSign-in credentialsのAssigned MFA deviceにある値をハードコーディングしている。外部設定ファイルに入れたほうが使いまわしが効くのだが、業務用で他の人に配るならともかく、完全に個人用なので省略した。テンポラリファイルも作らなくてもなんとかする方法がありそうだが、これもわざわざ時間をかけて作り込むメリットがないのでオミットした。おかげで製作時間は多分10分くらいである。

余談ながら背景

先の実験でコンテナからTerraformを使うのは微妙という判断とあいなり、WSLを使ってみたところこれまたTerraformのコマンドキャンセルでコンソールから追い出される問題に遭遇し、しかたないので普段はWindowsからTerraformを使う状況に戻ってしまった。そこでしぶしぶ作ることにしたものである。

つまりAWS CLIを動かすのは途中経過で、Terraformを動かすのが最終目標なのだが、そのあたりの事情はバッチファイルの内容と対して関係しないため、タイトルはAWS CLI用とつけている。

参考

DockerでTerraformを利用してみる

しばらく暫定的にWindow直でTerraformを利用していたが、環境を再現しづらく、従って環境の統一もしづらい問題が気になる。ついでに、AWSをMFA付きで利用するにあたっては、いちいち公式で紹介されている手順を使うのも地味に手間がかかるので、こちらで紹介されているスクリプトを導入したいところ。

というわけで試してみることにした。

ちなみにTerraformの公式コンテナのページに曰く、

Running Terraform inside a Docker container requires more configuration than running the Terraform CLI executables directly. Unless you need container isolation, we recommend using the non-containerized Terraform CLI packages.

意訳: コンテナ上でTerraformを使うのは、CLIを直接設置するのに比べて必要な設定が多くなる。コンテナとして隔離しなくていいんだったらCLIをそのまま使ったほうがいいと思うよ。

だそうである。

やってみた感じ、たしかにこれは真実であった。

やること

  1. ベースイメージを決め、Dockerfileを作る
  2. AWS CLIで使うための設定ファイルを用意する
  3. docker-composeでビルドと起動
  4. コンテナに入って起動

コンテナを起動する際にterraformも起動する方式が、たぶんコンテナの精神には沿うのだろうが――たしかワンバイナリっぽく扱うのがカッコいいとされていたはず、公式のTerraformコンテナもそんな作りになっている――、今回の場合、それだとトライ・エラーがやりづらい。というわけで自分が使いやすいようにdocker execを使うことにした。

1. ベースイメージを決め、Dockerfileを作る

Terraformは公式がコンテナを用意してくれているのだが、開発しながら利用するにはAlpineで使いづらい。そのためあえて避け、amazon/aws-cli:latestにTerraformをインストールして使うことにした。もっとプレーンなイメージにAWS CLIとTerraformをインストールして使ってもいいわけだが、aws-cliがプリインストールされているAWSオフィシャルなAmazonLinux2という点が個人的にポイントであった。

Dockerfile

Dockerfileはこれだけ。

FROM amazon/aws-cli:latest

RUN yum update -y
RUN yum install -y unzip jq tar gzip
RUN curl  -OL https://releases.hashicorp.com/terraform/1.3.4/terraform_1.3.4_linux_amd64.zip
RUN unzip terraform_1.3.4_linux_amd64.zip -d /bin

ENTRYPOINT ["/bin/bash"]

tarやgzipリモートデスクトップに必要だった。

2. AWS CLIで使うための設定ファイルを用意する

これはaws configureをホスト(自分の環境ではWindows)側で実行し、docker-compose.ymlでボリュームをマウントすればOK。

    version: "3.9"
    services:
    terraform:
        container_name: terraform
        build: ./containers/terraform1.3
        tty: true
        volumes:
        - ./src:/src
        - ~/.aws:/root/.aws

3. docker-composeでビルドと起動

下記コマンドを打つ。

docker-compose up --build

4. コンテナに入って起動

下記コマンドを打つ。

docker-compose exec terraform /bin/bash

実際に利用してみた結果

結論、これはこれで手間がかかる。というのは、terraform applyをかけた後でキャンセルしただけでもコンテナからログアウトしてしまうため。

MFA認証がいらないならまた話が変わってきそうだが、要MFAだと、環境の統一はWSLで行うほうが良い印象。

究極的には、いっそクラウド版のTerraformやEC2上でTerraformを利用するにしくはないかも。

AWSのVPC作成に"VPC and more"が増えていたので使ってみた

今日別件でVPC画面を触っていたら、VPCに新しい操作画面が追加されていたので早速触ってみた。

なにこれ素敵

なんとVPCと一緒に作るリソース、すなわちSubnet、Route Table、igw、S3 Endpoint、Nat gatewayをセットで作ってくれる。

20221113133410

試してみたところ、これまでVPCを作るにあたって逐一別々に作らないといけなかったのが、実に簡単に作れた。S3 Endpointも採用されているあたりポイント高い。

CoolなScaffold

もちろん誰にとっても銀の弾丸になるというものではなく、Dynamo用のEndpointが欲しいなら自分で作らないといけなさそう。他には細かい点だがS3 Endpointのポリシーが全通しだったり、それぞれの名称(Nameタグ)が冗長気味だったりするのが気になるなら、そちらも自分で変えないといけないだろう。

ただScaffoldとして見れば最高にCoolだ。作ったリソースはちゃんと全部結果画面で表示してくれるから、この手のサービスでよくある"何が作られているのかわからなくて困る"ということもない。

もちろん気になる点がないならそのまま使ってもよさそうだ。

総じて、新規からVPCをマネジメントコンソールから作るなら検討に値するサービスと思える。

読書感想文:稼ぐ力を手にするたったひとつの方法 Kindle版

稼ぐ力を手にするたったひとつの方法 Kindle版を呼んだため、自分の中のまとめがてらにメモ。

相手の立場で物事を考える

というのが"たったひとつ"であるようだ。

大事なことであるのはたしか。そして自分のことばかり考えているとおろそかになりやすいのもたしかで、よく気を付けないといけない。

実力と社内政治

それ以上に、社内の泥臭い人間関係や人間の感情と、実務能力との兼ね合いについての記述のほうが個人的に興味を惹かれた。

自分はエンジニアなのでどちらかというと実務能力のほうを重視するのだが、そちらに偏重すると上手くいくはずのことが上手くいかなかったりして、おかしなことになるのは痛感している。自分自身が痛い目を見たことも一度や二度ではない。

IT業界での開発プロジェクトはそれでなくても困難が多い。本来必要なだけの時間が用意できないことは珍しくなく、初めてみるまで予想だにしなかった落とし穴が後から見つかるなどザラ、やりたいことが途中で変わることも珍しくなく、ひたすら不確定要素と戦い続けねばならないのが開発プロジェクトだ。

そんな難事にチームで当たろうというのに、メンバー同士で嫌がらせをしたり足を引っ張ったりしていたら世話がないのだが、残念ながらいつもいつもチーム一丸となって事にあたれるとは限らない。というより、大なり小なりなにかしらあるもので、スクラムが語るような理想的な姿が最初から最後まで完全に保たれているようなチームは今のところ見たことがない。この本の中で語られている、"上司は利用する相手、メンバーは競争相手"という殺伐とした姿は、残念ながら一面の真理であろう。

理想的なチームを見てみたくもある

しかし理想的なチームがどこにもないと決めつけるのは早計、と考えるのは楽観的すぎるであろうか。必ずしもそうとは言えないとも思う。雑多な人間が大量に集まる大規模なチームだと難しいかもしれない。だが少人数のチームであれば、構築することはできるのではないか。

そういった観点で今後の仕事を考えてみたいところである。

Visual Studio Code Draw.io Integrationを試してみた

Draw.ioをVSCodeから使えるという拡張機能Draw.io Integrationを試してみた。

こんな感じ

20221108163424

素晴らしいことに、編集結果をエクスポート作業なしに普通のsvgファイルとして扱うことができる。

20221108163828

ということは、VSCodeをいれていない人にも作成した図を共有できるはず。クラウド型のツールは権限がない人に共有したいがアカウントがなくてできない、なんてケースがしばしばあるのだが、ただファイルが共有できればいいだけというお手軽な条件を満たすだけで良いのは個人的にかなりポイント高い。

Visual Studio Live Shareと組み合わせれば、会議中に話しながら修正することもできるのではなかろうか。

感想

  • ローカルのVSCodeでDraw.ioを気軽に扱えるのは驚き。
  • 微妙にもっさり感を感じることがあるものの妥協できるレベル。多彩な表現が欲しいなら採用を検討する価値あり。
  • 当たり前だがVSCodeが必要なので、VSCodeを使わない人が手を出すのはちょっと大変かも。

長く使えることを期待したい。

Terraformを使えるならAmplifyを使わずにS3+CloudFrontでよさそう

この比較記事をたまたま見ていたのでメモ。

結論、現段階では、Terraformを使っているならS3+CloudFrontでよいという印象。

Amplifyは、手軽さとのバーターなのである意味当然なのだが、カスタマイズ性が弱い。たとえばDevelop環境のCloudFrontにWAFをセットしてアクセスを固定IPで制限したい、と思っても、現時点(20221108)まだできない。

この例については今後できるようになるかもしれないが、問題はそこではない。柔軟なカスタマイズがしたくても対応できないデメリットがもったいない、ということだ。

Terraformをすでに使っており、かつAWSの学習コストをサンクコスト扱いできるなら(できる人は多いはずだ。むしろ、それができない状況でAWSを使うべきだろうか)、というかなり重い前提がつくのだが、無理にAmplifyを使えるよう頑張るくらいなら、素直にS3+CloudFrontをTerraformで構築するほうが、かえって工数も短縮できるように思う。過去のコードを流用できれば――ちなみに自分のコードはここで公開する予定―――リソースを用意する程度はそう難しくない。

ただ一方で、カスタマイズが必要ない軽い用途で、お手軽にマネジメントコンソールからポチポチやるだけで自動デプロイまで用意できるのは、Amplifyの素晴らしい点である。Terraform他のIaCを使っておらず、かつ要件的にも問題なければ、Amplifyに検討の価値があるのは間違いない。