白”雪姫”の雑なエンジニアブログ

ダイアリーがなくなってしまったため、エンジニアブログとして再出発

JAWSDAYS 2024に参加してきました

JAWS DAYSって?

https://jawsdays2024.jaws-ug.jp/ JAWS-UG(AWS User Group – Japan)のオフラインイベント 多量にあるコミュニティが1度に介するビッグイベント。

国内ではSummitもあるけど、どちらかというと利用者ベース行われるコミュニティイベントです。

過去に参加してたことある?

実は、過去に1度いっており、その時には実は単なるモブとして参加していました。

ただ、この時はほぼほぼコミュニティの方とかと交流がないのと、機密情報がんじがらめの関係で参加できてないのと一緒の状態だったのです。 というか、ド緊張もするし、コミュニティに参加するとかいう概念もなかったのです。。

その時のことをちらっとXの方で呟いたら当時から企画に賛同されているテポさんからこんな感じだったんです。 っていう会話をして今回は、当日までワクワクしてました。

実際参加して何をしたか。

Time Schedule的に、実はいくつか参加を今回決めていました。

  • 元々の予定
    • Key Note
    • JAWS支部 re:Surgence~リブート支部代表たちによるパネルディスカッション~
    • フルAWSのマルチテナントSaaS生成AIアプリ「かぐたん」開発秘話
    • AWS認定 Specialityレベルで満点取った時の勉強法
    • AWSセンセーション私とみんなが作ったAWSセキュリティ
    • 🍻 懇親会 🍻 お昼を食べる暇のない過密スケジュール(笑)で予定してました。

ですが、情報が公開されていき、あるハンズオンがすごく気になり結局、以下に。

  • 実際に動いた予定
    • Keynote
    • スポンサー企業様を回る
    • お昼
    • AWS GameDay Network Topology Titans
    • 🍻 懇親会 🍻

振り返る

  • 現地到着 ここの入り口、毎回思うけど階段とか踏み外すんですよね。 そして、今回も漏れなく足を踏み外してそのままくじきました。早く着いたのもありそのままスタバさんへ。向かう途中の通りもJAWSDAYS一色のフラグになってましたね!(テンション上がります。)  

  • Keynote まさかのKeynoteスペシャルゲストに長崎さんがいらっしゃってる!! すごいありがたいお言葉という名のスピーチを見ていました。 コミュニティ活動ってすごいんだなぁ。と改めて実感

  • スポンサー企業様を回る 実はこんな企画があり、抽選でもらえるBuiilderCardsの日本語版がちょっと欲しかったのです。(昨年のRe:Inventで英語版が配られたらしい) 残念ながら抽選は外れてしまいましたが、スポンサー企業様を回ってる際にMIXI様から面白いお話しを聞かせてもらい、凄いトリッキーな使い方してるなー。でもユーザビリティ凄いなぁ。と思って楽しくなっていました。 おまけで、朝早い時間にXでよくお見かけしたさめさんも撮ってきました

  • お昼 現地到着までの所の足をくじいた件もあり、ちょっと座ってゆっくりご飯を食べたかったので一度会場を後にして、お昼を頂き、また会場に戻るという感じでした。

  • AWS GameDay Network Topology Titansに参加 もうね、これ、今までやってきた知識とか総動員して頑張ってきました。 普段やらないようなこととかをやれたので、すごく見になった。 特に「/8」でサブネットマスク作れるのか!とか「あー、なるほど?確かにそうすれば接続できるよね?」とかとかで楽しく再認識と学べたと思っています。 今回のテーマがネットワークだったということもあり、今までやってきたことの応用を覚えられたことがすごくよかったなって思っています。 ANSでも語られてない実践!!感じでした。 チームごとに順位を争う形だったのですが、最後の最後で入賞順位の3位に食い込みました(入賞は4位まで)

  • 🍻 懇親会 🍻 色々な方とお話しできて交流も広まったなぁという感じです。 同じ会社の人が登壇してたのもあって探してみんなで少しお話しするみたいなこともできたし、昨年末位から私も活発に動けるようになり、積極的に、当時から交流のあった友人等にご紹介をいただいたりしました。 最後は集合写真どこかにいます。

最後に

運営の皆様、スポンサー企業で参加された皆様、ボランティアスタッフの皆様、登壇された皆様、素敵な会をありがとうございます。 参加者としてすごく楽しい時間を過ごせました。 機会があれば今度こそスタッフ応募してみたいなと思いました(応募を知ったときには既に閉め切られておりました・・・・(笑))

APIGatewayとLambdaを使って決済システムのAPIを作る話・・・その3とまとめ

これまでの記事

予告の記事

その1の記事

その2の記事

WAFの設定1

WAFの設定2

全体構成

今回はおまとめ記事なので、ピンクの枠はありません

前回の記事でハマったポイント

  • Lmabda VPCによる制約
  • Lambdaからの無制限アクセスを制限するためのRDS Proxyが使う必要がある
  • Lambdaと同一VPC内にRDS Proxyが必要
  • RDS Proxy間で接続して解決

という感じでした。

前回ややこしくなってしまい書き切れなかった補足

Security Groupのところをややこしく書いてたので、図面を用意して 表にして見ました。

Security Groupやネットワークの情報整理

サブネットマスク

  • 右のVPC全体(192.168.0.0/23)
    • public-subetを192.168.0.0/24
    • private-subnetを192.168.1.0/24
  • 左のVPC全体(192.168.10.0/23)
    • public-subnetを192.168.10.0/24
    • private-subnetを192.168.11.0/24

Security Group

  • LambdaのSecurity GroupをSG-A
  • LambdaのVPCがいる方RDS ProxyのSecurity GroupをSG-B
  • LambdaがいるVPC peeringのSecurity GroupをSG-C
  • RDSがいるVPC PeeringのSecurity GroupをSG-D
  • RDSがいる方のRDS ProxyのSecurity GroupをSG-E
  • RDSのSecurity GroupをSG-F

として記載します。

セキュリリティグループの設定

  • SG-Aのインバウンド
タイプ プロトコル ポート範囲 ソース 備考
HTTP TCP 80 192.168.0.0/23
HTTPS TCP 443 192.168.0.0/23
  • SG-Aのアウトバウンド
タイプ プロトコル ポート範囲 ソース 備考
HTTP TCP 80 0.0.0.0/0
HTTPS TCP 443 0.0.0.0/0
DNS UDP 53 0.0.0.0/0
MySQL/Aurora TCP 3306 192.168.1.0/24
  • SG-Bのインバウンド設定
タイプ プロトコル ポート範囲 ソース 備考
MySQL/Aurora TCP 3306 SG-A
  • SG-Bのアウトバウンド設定
タイプ プロトコル ポート範囲 ソース 備考
MySQL/Aurora TCP 3306 SG-A
MySQL/Aurora TCP 3306 192.168.11.0/24
  • SG-Cのインバウンド設定
タイプ プロトコル ポート範囲 ソース 備考
MySQL/Aurora TCP 3306 192.168.0.0/23
MySQL/Aurora TCP 3306 192.168.10.0/23
  • SG-Cのアウトバウンド設定
タイプ プロトコル ポート範囲 ソース 備考
MySQL/Aurora TCP 3306 192.168.0.0/23
MySQL/Aurora TCP 3306 192.168.10.0/23
  • SG-Dのインバウンド設定
タイプ プロトコル ポート範囲 ソース 備考
MySQL/Aurora TCP 3306 192.168.0.0/23
MySQL/Aurora TCP 3306 192.168.10.0/23
  • SG-Dのアウトバウンド設定
タイプ プロトコル ポート範囲 ソース 備考
MySQL/Aurora TCP 3306 192.168.0.0/23
MySQL/Aurora TCP 3306 192.168.10.0/23
  • SG-Eのインバウンド設定
タイプ プロトコル ポート範囲 ソース 備考
MySQL/Aurora TCP 3306 SG-B
  • SG-Eのアウトバウンド設定
タイプ プロトコル ポート範囲 ソース 備考
MySQL/Aurora TCP 3306 SG-B
  • SG-Fのインバウンド設定
タイプ プロトコル ポート範囲 ソース 備考
MySQL/Aurora TCP 3306 SG-E
MySQL/Aurora TCP 3306 192.168.10.0/23

対抗のネットワークが複雑化している関係で、Security Groupを入れてたりIPやCIDR等を入れてますが、Security Groupを入れ子にすることをできる限り推奨します。

また、重要なところですが、 汎用性を広げる為、peering間では通信を全て許可していますが個々のサービスで制限をかける必要があります。

作業のおまとめ

Security Groupの表だけで結構大変なことになってしまいましたが順番を書くと

  1. API Gatewayを作る
  2. Route 53とCertificate ManagerのDNS認証で用いて証明書を作る、この時、設置するリージョンに気をつけること
  3. Lambda用のSecurity Groupを作る
  4. Lambdaを作る
  5. VPC peering用のSecurity Groupを作る
  6. VPC peeringを接続する
  7. RDS Proxy用のSecurity Groupを作る
  8. RDS Proxyを作る
  9. RDSのSecurity Groupの編集をする
  10. 接続確認
  11. 疎通確認後、API GatewayにWAFを取り付け
  12. 動作検証

と言った形になります。

作った後の感想

こういう物ほど、Cloud formationが使えたら良いなぁとか思いました。 正直、入れ子になりすぎてどれがどれ? 見たいな事は多々ありました。

なんで作らなかったって?? ここまで書いておいて何ですが、 実は、取得していた認証規格の関係でコードと呼ばれる物にすると 全て、「コードテスト」と「セキュリティ基準」に満たす必要があり、そちらの方に工数を取られてしまう と言う観点で、当時は諦めました。

今後はできれば良いなぁとかそういうのを作れたら良いなぁとか最近思ってます。

APIGatewayとLambdaを使って決済システムのAPIを作る話・・・その2

前回

予告の記事

前回の記事

全体構成

今回はピンク枠のお話し。

注意事項等

前回の記事とをお読みください。

今回のお話で利用するサービス

  • Lambda Function
  • VPC Peering
  • RDS Proxy
  • Security Group

構築に当たっての条件

  • Lambda Functionは、
    • TCP:3306(MySQL/Auroraポート)だけアウトバウント
    • HTTPSは無制限にアウトバウンド
  • RDSは、 RDSのあるVPCのサブネットLambda Functionのおいてあるサブネット のインバウンドを許可

実際にやったこと

元々の設計では。。。

  • VPC間でピアリングを行う
  • VPC間で相互ルーティング
  • RDSのおいてあるVPCにRDS Proxyを設置
  • セキュリティグループ設定、調整
    • 具体的に
      • RDSが所属するサブネットからRDS Proxyからの接続を許可
      • RDS Proxyが所属するサブネットから Lambda Functionが所属するサブネットを許可
      • Lambda FunctionからRDS Proxyへ接続するアウトバウンドを許可
  • Lambda FunctionからRDS Proxyを経由してRDSに接続できることを確認

・・・のはずでした。 追加でやったこと

  • Lambda Functionに所属するVPCにRDSProxyを作成
  • セキュリティグループを再調整
    • 具体的に
      • Lambda Functionが所属するセキュリティグループから Red& RDS Proxyのサブネット接続できるようにアウトバウンドを許可
      • Lambda FuncrtionがあるVPCのRDS Proxyから接続できるようにRDSがあるVPCのRDS Proxyのセキュリティグループでインバウンドを許可
      • RDSがあるVPCのRDS ProxyからLambdaのサブネット許可を取り消し
    • 再度、Lambda FunctionからRDSProxyを経由してRDSに接続できることを確認

なんでこんなことになったのか(ハマりポイント)

実は、元々の設計ではこういった形になってました。

初期設計では、RDS ProxyはRDSの所属している側にしか存在してませんでした。 また、RDSは別のAPIサーバとも接続されている関係から、 Lambdaに無制限に接続させない ということからLambda はRDS Proxyでの接続は必須になっていました。

ですが、、またもAWS公式 VPC Lambda(VPCに所属させるLambda)は、 同じVPC内のみ という制限がありました。

そこを調べるのにリリースされてしばらく経っているということもあり、資料を探すのに結構かかりました・・・。

所感

やってみてわかったことですが、色々制限がある というのはやはり頭を使うということ それと、構成がややこしくなる でした。

なので、予告編・その1・その2と書いてきたので全体的な構成は説明は完了となります。

最後のまとめ編のその3を書こうかとおもいます。

APIGatewayとLambdaを使って決済システムのAPIを作る話・・・その1

前置き

予告編と記事を1つ挟んで、改めて作っていこうと思います。 APIGateWayとLambdaを使って決済システムのAPIを作るお話しです。

全体構成

今回お話しするのはピンクの枠となっている部分です。

注意点

  • 必ずしもAWSのベストプラクティスに準じているわけではありません
  • プログラムの内容は非公開であり、当該環境内で今回出てくる物は説明するサービスしか構成図に載せてません
  • 決済と記載していることからセキュリティの認証系を取るための参考構成としてください
  • 構成図はピンクの枠を変更することから毎回の記事には載せますが、検証環境のアカウントが用意できなかったため設定時の画像はあっても細切れとなります
  • 左のVPCに関しては、細かい所が出せないため、細かい説明はしません。

今回のお話で利用するサービス

構築にあたっての条件

  1. APIの本体(Lambda Function)はPrivateNetworkに置くこと
  2. 決済を実行するときにAPIは一度環境外(グローバル)に情報を投げること
  3. グローバルに出る際には固定IPであること(投げる先がIPアドレスが指定となっているため)
  4. 決済後の処理情報は、必要な情報のみを別のAWSアカウント・別VPCに存在するRDSに保存すること

実際にやったこと

  • VPCにプライベートサブネットとパブリックサブネットを作成する
  • パブリックネットワークにNAT Gatewayを配置する(AZ単位でそれぞれ1つずつ)
  • API Gatewayを作成する
  • Certification Managerを用いてDNS認証の証明書を作成する。
  • API Gatewayでカスタムドメインを有効化して証明書を紐付け、AWSから発行されたドメインを無効化する
  • AWS WAFをリージョンで作成する
  • AWS WAFをAPI Gatewayに紐付ける

ハマったことと所感

この時ハマったことが2箇所ほどありました。

ステージを作ってあげないとそもそもAWS独自のURLが発行されないこと、AWS WAFを紐付けられないことを当時は知らず 半日くらい時間を溶かしました。 また、独自URLが発行されないが故に、「API Gatewayって何に使うのよ?」となっていました。

こちらも理解するのに少し時間がかかりましたが、実行していた当初、設計上ではVPC外だったので「バージニアに作る」という感覚で居たのですが、証明書が一向に出てこないとなった末に、API Gatewayのリージョンに作成してみたら動きました。

後から調べて分かったのですが、AWS公式にも「エッジ最適化ではus-east-1」で作ってね

と書いてありました。

備考

前記事より、記事記載形式を変更することにしました。 そのため見やすい、見にくいがありましたらコメントいただければと思います。

ちょっと近辺のアップデート〜YUBIKEY導入してみた〜

前回の記事でシリーズみたく 書くよって言ったのに書かなくてごめんなさい。

タイトルですが、YUBIKEYを導入してみました。 今回導入したのはこちら

実際の画像です。

導入した経緯

答えは単純で、ワンタイムパスワードが増えすぎて訳が分からなくなるときがあった ただこれだけです。

やってみよう

ということでやってみました。

  1. AWSマネジメントコンソールにログインします。 ※今回はルートユーザにYUBIKEYに導入したかったので、ルートユーザでログインしてますが通常は権限を絞ったIAM等を利用してください。 また、IAMの場合は、導入箇所が異なる場合がありますので確認してください。
  2. 画面右上のユーザ名をクリックして、プルダウンからセキュリティ認証情報を選択します
  3. 遷移した画面で、MFAデバイスの割り当てをクリックします。
  4. 選択画面でSecurity Keyを選択、名称を付けて次へをクリックします。
  5. PINコードの入力を求められるので任意の数字を入れます。(必須です)

入力後

6. 許可を求められるので、登録完了します。

設定でハマったところ

実は、5番の2個目の画像でポップアップでなんで先に進まないの?って考え込みました。 で、よくサイト内の所を見てみたら PINコードを入力した後、触ってね。 って言うことで、PINコード入力後、タッチする必要がありました。 そのため、タッチして無くてそのままタイムアウトみたいな事が何度かありました・・・。

丁度目線から隠れるところにあったので気がつかなかったのですが、どうやら光っていたようです。。

実際切り替えてみて

添付の通りどっちで認証するの?求められるのがワンクッションおかれるようになりました。 が、タッチ一発で2FAが認証されるようになったのですごく、楽になりました。

AWSのみに限らず、YUBIKEY対応の所は徐々に入れていきたいなと思います。

なぜなら、タッチするだけで2FAが完了するので、楽だし効率化できるから!

注意すること

とはいえ、YUBIKEYはUSBなので、紛失・盗難はたまた、機器故障が発生したときには認証が出来なくなります。 Authenticaterとかもそうですが、アプリもスマートフォンの故障の可能性もあり得ます。 そのため、実施の際は、可能なら複数を設定しておいた方が良いのかなと思います。