Articles in AWS

普段はお仕事で Rocket.Chat を利用しているわけですが、基本的にはスポットインスタンスを利用しています。

スポットインスタンスである以上は避けられないのがスポットインスタンスの中断なわけでして、スポットインスタンスの料金履歴を見ながら比較的料金が安定しているインスタンスタイプとアベイラビリティゾーンを選んでいたわけです。

それでも起きるときには起きるものです。久しぶりにインタラプトが発生してスポットインスタンスが逝きました。

中のデータ？

もちろん、一緒に逝きました。バッドプラクティスを実現していた結果です。

これでは良くない。ということで、きちんと対策を取っていきます。（この記事は大作でもあります。）

S3 には、ユーザーが任意の Key-Value データを保管できるオブジェクトメタデータという仕組みがあります。

単純なデータを格納できるので敢えてデータベースを用意しなくても済むというメリットがあります。

そして、S3 API には、オブジェクト自体を取得せずにオブジェクトの情報を取得する HeadObject という API があります。

API のリファレンスにはオブジェクトメタデータも取得できると書いてありますが、Ajax で呼び出したときには実はメタデータは取れません......。

しばらく悩んでいて、GitHub の AWS JS SDK Issues にもレポートが合ったので Watch していたのですがやっと原因がわかりました。

その昔、こんな記事を書きました。

S3 と連携して CodePipeline で EC2 Image Builder を動かす

CodePipeline を利用して Lambda を起動して EC2 Image Builder を呼んでいました。

その後、S3 から EventBridge 経由で直接いろいろなサービスを連携できるようになったので、ノーコードで Step Functions のフローにできるんじゃないか？と思いやってみた次第。

今年も新しい AWS 認定取ってきた。AWS Solution Architect - Professional です。

長年 AWS を触ってきているけど、エンタープライズ向けソリューションアーキテクト向けとも言える認定試験なので、普段は全く触ったことが無いサービス（触れる機会がない）や、大規模の設計に関する知識を問われるので勉強も大変というアレです。

AWS 認定インストラクターになってからガチで AWS を改めて学んでますけど、今回は中々の戦いでしたわ。180分フルに使ったわ・・・・・・。

特定の属性を持たない項目を洗い出してなんとかする。というシチュエーション。

必要なデータなら入れるときに弾きなさいよ。というところでもあるけれど、必須ではないけど・・・。というような場面は、まあありえるか。

EC2 Image Builder を使うと AMI のビルドをパイプライン化できるというのは、以前にも書いたけれども。

• EC2 Image Builder で MT の AMI を構築

今回は、S3 と CodePipeline を連携させて、S3 に MT のファイルをアップすると自動で AMI 作成して結果を Slack に通知してくれる仕組みを作った。

AWS ElasticBeanstalk を使ったデモ環境を作ろうと Node なでもアプリをデプロイしたところ中々動かなかったのでメモ。

サンプルアプリじゃなく、イメージをアップロードできるギャラリーサイトを作ってたのです。

コース実施が無い日程がちょうどあったので、AWS 認定試験を受けてきた。今回受験したのは次の2つ

• AWS 認定 SysOps アドミニストレーター - アソシエイト
• AWS 認定 デベロッパー - アソシエイト

結果は無事合格。得点も自分で思っていたよりも取れてた。これでアソシエイト・レベルは取ったので次はプロフェッショナル・レベルと専門知識だな。

10年前の今日、AWS 東京リージョンが爆誕しました。

東日本大震災直前のリリースで、震災後の復旧にも多大な貢献をしたのも記憶に新しいところ。

そんな記念すべき日に（多分）合わせて大阪リージョン爆誕です。
もともと、2018年に東京リージョンのバックアップ（DR対策）としてオープンしていた大阪ローカルリージョンがスタンダードリージョンにアップグレードされた感じですね。

AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services

ということで、大阪リージョンと東京リージョンを VPC ピアリング接続して速度を測ってみた。

これまでは、Movable Type AMI 版 を使っていましたが、個人無償版 + AWS な構成に変更することに。

Movable Type 環境構築の手間もあって AMI 版だったわけですが、EC2 Image Builder で AMI を作るパイプラインを作ったので、MT のアップデートに合わせて新しい AMI を作っていけばOK。

AWS EC2 Image Builder というサービスがあります。

Production Ready ないわゆるゴールデンマスターになる AMI の構築は結構手間で、実際の環境を構築してからイメージ作成をおこなう手順が必要でした。

EC2 Image Builder は、この作業を自動化してくれるのと、セットアップされた内容の検証も自動でやってくれるサービス。

朝イチのニュースで S3 が PrivateLink をサポートしたよ。っていうのがあったので、よくある話のオンプレ環境からインターネットを経由しないで S3 にアクセスする。を試してみた。

ニュースはこちら。

これまでも、S3 は、ゲートウェイ型の VPC エンドポイントをサポートしていたので、VPC 内に Proxy Server を用意してごにょごにょ。とすればできる。というストーリーで話をするのだけれども、PrivateLink で出来るようになったので不要な EC2 を立ち上げなくても良くなる。

結論から言うと、Aurora Serverless のクラスター止まらんかった。。。

正確に言うと、EC2 インスタンスが止まればそれに合わせてクラスターも停止していた。

よく分からないのは、Database Connections が 0 のときも動き続けていること。Data API で検索とかしているから外からの呼び出しが常々あるというのなら分かるけど、アクセスログを見る限りそんなこともなさげ。

このままでは効率悪いので一旦普通に戻す。

素のやつで検証しよう・・・。

このブログは、Movable Type で作っているけれども、データベースを試しに Aurora Serverless にしてみた。

パフォーマンス的には全然問題ない。あとはコスト面がどうなるのかちょっと様子を見てみたい。

なぜ、Aurora Serverless にしたのか？

AWS Amplify は、これまでちゃんと試したことがなかったので。Amplify Docs で公開されてる Vue を使ったチュートリアルをやってみた。

一言で言って、なんて簡単にサービスが作れちゃうんだ。

AWS を使い始めてはや5年以上。

個人的な使用と、前職の職場環境での利用と、Movable Type の AWS 版を色々触ることがメインで、ユーザーへの提案とか仕事ではしていなかったので認定資格は取っていなかったけれど、認定トレーナーになるためには、Solution Architect Associate が必要ということもあり試験を受けてきた。

結果としては、無事に Solution Architect Associate と Cloud Practitioner の試験に合格。めでたい。

試験内容は、来年にも更新されるらしいけど、問題の傾向をまとめておく。