PythonでとあるAPIを呼び出す処理を記述し実行したところ、以下のようなエラーが返ってきた。
420 Enhance your Calm
日本語訳にかけても意味不明でなんじゃこりゃ？って感じだったが、どうやら速度制限に引っかかった場合に返されるらしい。
そこでAPI呼び出し直前にsleep処理などを入れてみたが特に変わらず、あれこれするうちにリクエストのbodyをjson化していないことが原因っぽく、以下のような記述を追加することで出なくなった。
req_body = json.dumps(req_body)
なんかもうちょっとわかりやすいエラーメッセージなかったのかなとブツブツ言いつつ、一件落着。
API Gatewayのステージでステージ変数を設定し、Lambda側でバージョンとエイリアスを設定して紐付けて呼び出すよくある構成で構築し、API Gatewayの画面に出てきたURLを叩いてみると「Internal server error」と表示される。
API Gatewayのステージ変数はちゃんと設定できていて、リソースのテストでステージ変数を入力して実行するとちゃんとレスポンスが返ってくるし、
Lambda側のリソースベースのポリシーステートメントはちゃんと設定できている。
つまらないオチになりますが、結局原因はステージに表示されているURLをクリックしてもGET送信となるだけで、POSTやPUT送信にはならないことが原因でした。レスポンスが別タブで表示されている時点で気が付くべきでしたが、リソースメニューのテストではPOSTやPUTで送信してくれるので、ステージの方でもなんかうまいことURLをクリックするだけでPOST/PUTで送ってくれるのかと思い込んでいたという初歩ミスです。
ターミナルからcurlで実行するとちゃんとレスポンスが返ってきました。
2023年２月頃、AWSから以下のようなメールが届いた。
どうやら今使用しているDockerイメージのバージョンのサポートが3月で切れるらしい。ってことで、このバージョンをあげます。
CodeBuild→ビルドプロジェクト→対象のビルド→編集ボタン→環境、で今回はイメージのバージョンを「4.0」から最新の「6.0」に変更して完了です。
ただしこれ、バージョンによって使用可能なランタイムが変わってくるので以下を確認してご注意を。 docs.aws.amazon.com
以上！
LambdaからEFS上のファイルを操作する必要があったので、その設定方法をメモ書き。
まず、前提としてEFSはVPCの内側、Lambdaは外側にあるサービスなので、そのままでは当然アクセスすることができない。
解決策としてLambdaをVPCの中、さらにEFSがマウントポイントを貼っているSubnetの中に設置してやり、アクセスポイントで繋いでやることでLambda→EFSにアクセスすることが可能になる。イメージとしてはこんな感じ。
ではひとつひとつやっていきます。
Lambdaの設定の方ですが、VPC内のEFSにアクセスするために、LambdaをVPCの中に設置してやる必要があります。
まずはVPCの設定するためLambda実行ロールの権限の設定から。Lambdaの実行ロールは以下で確認、及び設定画面へ移動できます。
VPCの設定に必要な「AWSLambdaVPCAccessExecutionRole」、またついでにEFSへのアクセスに必要な「AmazonElasticFileSystemClientReadWriteAccess」、及びCloudWatchへのアクセス権「CloudWatchLogsFullAccess」も一緒に付与しておきます。
(ポリシー名)
そしてLambdaをVPCの中に設置する設定箇所がここの部分↓（※Lambda作成の手順に関してはここでは省略します）
ここでEFSが現状マウントされているEC2やFargateなどが存在するVPCとSubnetを指定してやります。今回はLambdaからEFSへアクセスするだけなので、セキュリティグループはインバウンド、アウトバウンド共に何もなしの内容で問題ない。
EFSがマウントされているSubnetは、EFS側の画面でも確認できます。
これで今↓のような感じで、LambdaがEFS（のマウントポイント）と同じ場所に配置された状態になります。
後はLambdaとEFSを繋いでいく作業になります。今回EFSは既にEC2などと繋いで利用している想定で、EFSをゼロから作成する部分の作業手順は他の記事に譲るものとします。
LambdaからEFSにアクセスするには、EFS側に「アクセスポイント」というインターフェイスが必要になります。EFSのマネジメントコンソールの画面では以下になります。こちらを作成してゆく。
入力する値は他の同様の記事にもある通り以下で指定します。ここの「パス」で指定したパスが、LambdaからEFSを操作する時の、EFS側のデフォルトパスとなります。
これでEFS側にLambdaからのアクセスを受けるアクセスポイントの作成まで完了しました。
今度はLambdaの方で、↑で作成したアクセスポイントを指定してファイルシステムのマウント設定を行います。「ファイルシステムID」で対象のEFSを選択、アクセスポイントIDに↑で作成したアクセスポイントのアクセスポイントIDを指定します（EFS側のアクセスポイント設定画面で確認可能）。「ローカルマウントパス」はLambda側のマウントパスになります。例えばここに「/mnt」と指定した場合、Lambdaの「/mnt」とEFSの「/data」ディレクトリがマウントされることとなり、例えばLambdaで「ls /mnt」を実行すると、EFS側の「/data」配下のファイルの一覧が表示される、という形になります。
ここまでくれば後は権限回りの設定のみで、以下の部分を設定していきます。
EFSのセキュリティグループにLambdaからのアクセスを許可するよう、LambdaのセキュリティグループのIDを指定します。EFSのセキュリティグループはコンソール画面の以下で確認可能。
LambdaのセキュリティグループIDは以下で確認可能でした。
これで以下の状態が完成したかと思います。お疲れ様でした！
2023/2/17、AWSのSOA（SysOps Administrator：SOA-C02）を受けて合格したので情報共有したいと思います。
何年か前にSAAは取得しており、同じアソシエイトクラスの資格なので同じくらいの難易度を想定していたのですが、全く違いました。
というのもこれ、プロフェッショナルクラスにした方がいいんじゃないの？っていうくらい難しかったです。出題範囲もめちゃくちゃ広いし、唯一ラボの試験がある資格ということで、サービスの概要をわかっていればいいという内容ではなく、各サービスの細かい設定項目やそのユースケース、さらに基礎的なサービスに関してはコンソールで実際に設定できる知識が必要になります。受験の際には「ナメてかからない」ことを強くお勧めします（私は最初そうして1度落ちました）。
SAAの時はUdemyの問題集のみで合格できたため、今回も最初はUdemyの「【SOA-C02版】AWS 認定SysOpsアドミニストレーター アソシエイト模擬試験問題集（全4回分294問）」だけを２周実践し受験しましたが、見事に落ちました。
その後他の関連ブログ記事のアドバイスを受け、TechStockのAWS WEB問題集サービスに課金し、そこで２ヶ月かけて700問近くの問題を解いてようやく合格したという経緯です。勉強方法としてとにかく問題を解いてわからないことをノートにまとめて書き出し、風呂に入っている時にそのノートを読み返す、ということを繰り返しました。またよく出題されるサービス（VPC, Subnet, AutoScaling, ALB, EC2, S3, etc）などに関しては可能な限り手を動かして構築ということもやりました。BlackBeltを全部目を通しておく、ということをアドバイスされている記事も多くありましたが、私の場合は一度も見ずにひたすら問題集だけこなした形でした。
あくまでも私個人のやり方ですが、筆記対策に関しては、まとめて書き出すことで自分なりに整理して腑に落とす形で頭にも記録にも残せる、また風呂の時間にそれを読み返すようにすることで反復復習を日常の中に組み込むことができるのでお勧めです。
一点だけ声を大にして言いたいことがあります。タイトルにもある通り、これを伝えたいがために今回この記事を書いた側面もあるのですが、それは、「AWS SOA は絶対に自宅でテストしてはいけない」ということです。
今回、私は試したことがなかったので初めて自宅でテストを受講したのですが、これでえらい目に遭いました。受験開始直後からマウスの反応がワンテンポ遅れるなというのは感じていたのですが、筆記テストの段階では４択の選択肢から一つポチっと選んで「次へ」ボタンを押す程度だったので支障というほどの影響はありませんでした。ところがラボの問題になるとコレが甚大な影響を及ぼし、というのも一つ一つの操作に10秒ほど要する、画面をスクロール=10秒、リソースの名前に「test」と入力するのにも、「t」で10秒、「e」で10秒、「s」で10秒、「t」で10秒、という具合で、とてもじゃないけどテストどころではない状況でした。監視員役の方にチャットで連絡するも外国の方なので自動翻訳の変な日本語で会話にならず、結局2問あるラボ問題の1問目も終えられずテストが終了してしまいました。回答はわかっているのに入力が遅すぎて、または何度もフリーズして、回答できない状況にやるせない気持ちになり、心底疲れました。。
今回、おそらくたまたま筆記の方で点を稼げていたためラボの分をカバーしてギリギリ合格となりましたが、ラボの割合は20%あるので影響は大きく、全ての人に起こるワケではもちろんないとは思いますが、私のような事象が発生するかもしれない可能性を考慮すると、ラボ問題があるSOAの試験は自宅ではなくテストセンターで受験する方が無難かと思われます。
ちなみに今回の私のPC環境ですが、2021年M1チップ搭載のMacBookProで、ネット接続はWifiでしたら事前のOnVue（自宅テストのアプリ）パフォーマンステストでも問題なく、ネットはサクサク動くような環境でした。Macとの相性が悪いとの記事もあったためWindowsだと起こらないのかもしれませんが、いずれにせよこのテストでの自宅受験の選択はリスクが大き過ぎると思いますので、避けた方が良いと思います。
前回は午後に受験して翌朝の5時に通知結果がメールで届いたのですが、今回は2日後の朝に通知が来ました。ラボのことがあったので気になり、翌日にAWS Training & Certificationのページに見にいったらすでに結果が出ていました。遅いなという時はこういうケースもあるかもしれないので、直接AWS Training & Certificationのページに見にいってみると良いかと思います。
以上、どなたかの参考になれば幸いです。
AWS Transfer Familyのパスワード認証の設定で、S3への接続設定の記事は結構あったが、EFSの方があまりなく若干追加で設定しないといけないことがあったので共有します。
まずはパスワード認証に必要なリソース（AWS Transfer Family, API Gateway, Lambda）をAWS公式のCloudFormationのテンプレートから作成します。こちらのリンクからダウンロードしてください。
このまま作成するとS3用のAWS Transfer Family（SFTPサーバー）が作成されてしまうので、EFS用に設定するため６６行目に1行追記します。
さらにEFS接続の場合はPosixProfileが必要になるため、Lambda関数でPosixProfileをレスポンスに含める記述を315～319行目あたりに以下を追記します。
if 'PosixUserId' in resp_dict and 'PosixGroupId' in resp_dict:
print("PosixUserId and PosixGroupId found - Applying setting for PosixProfile")
resp_data['PosixProfile'] = {"Uid": resp_dict['PosixUserId'], "Gid": resp_dict['PosixGroupId']}
else:
print("PosixUserId or PosixGroupId not found - PosixProfile not set in response")
※PosixProfile（PosixUser, PosixGroup）が何なのかに興味がある方はこちら→https://dev.classmethod.jp/articles/efs-accesspoint-option-settings/
あとは更新したテンプレートでCloudFormationを実行し、リソースを作成するだけです。CloudFormationの具体的な操作方法が必要な方は以下の記事の「1.2. CloudFormationテンプレートの実行編」を参照ください。
https://dev.classmethod.jp/articles/aws-transfer-family-sftp-with-password-method/
AWS Transfer Familyのマネジメントコンソールへログインし、「1」で作成されたサーバーの画面を開き、「IDプロバイダー」のセクションにある「呼び出しロール」のリンクを押下。
許可ポリシーの「許可を追加」で「AmazonElasticFileSystemFullAccess」権限を追加します（ここではいったんフル権限で設定しますが、必要に応じて最小権限のカスタマー管理ポリシーを作成･設定ください）。
あとはAWS Transfer Family（SFTPサーバー）に接続するユーザー情報を、Secrets Managerに登録するだけです。Secrets Managerのコンソール画面から「新しいシークレットを保存する」ボタンを押下し、シークレットのタイプで「そのほかのシークレットタイプ」を選択、「キー/値のペア」のセクションで以下のペアを登録します。
次のページでSFTPログイン時のユーザー名となる「シークレットの名前」を登録しますが、必ず「SFTP/」を最初に記述してから任意のユーザー名を記載してください（Lambda側で「SFTP/」で認識する仕様になっているため）。SFTPサーバーへログインする時はこの「SFTP/」以後のユーザー名で実行することになります。
これで準備は整ったので、SFTPサーバー経由でEFSに接続します。コマンドラインでも可能ですが、今回はWinSCPでログインしてみます。
無事ログインできたでしょうか？うまくいかない場合はAWS Transfer Familyのサーバーの画面で以下「テスト」の機能があり、そこでエラーメッセージが確認できるため見てみてください。
以上、どなたかのお役に立てられれば幸いです。Good Luck!
EFSへは踏み台サーバーのEC2経由でログインして利用していたが、作業効率が悪いのでWinSCPとかで繋げたいなということで、AWS Transfer Familyを利用することにした。手順は以下の通り（※EFSは作成済のものとする）
作成したSFTPサーバーを経由してEFSにアクセスするユーザーは、対象のEFSへの操作権限を持つロールが設定されている必要があるため、ユーザー作成前にそのロール及びポリシーを作成しておく
EFSってなぜかコンソール画面でARNが載っておらず、自分でリージョン情報やらアカウント情報やらをくっつけて作らないといけなくて、自分は東京リージョンにEFS作ってたんですが、リージョン名を「ap-norheast-1」としないといけないところを「ap-norheast-1a」とAZ名にしてしまっていてハマりました。
ちなみにここで「AmazonElasticFileSystemFullAccess」ポリシーを付与すると、WinSCPで接続した際にアカウント内の全てのEFSにアクセスすることができた。※AWSのBestPracticeの「最小権限」に基づいて、ポリシーは必要最小限の設定推奨
POSIXユーザーID/POSIXグループIDというのはアクセスポイントに割り当てられたユーザー情報のことで、今回作成したユーザーでSFTPサーバー経由でEFSにアクセスした際に適用される。例えばLinux上で「ls -la」コマンドでファイルの一覧を表示したときに記載がある「所有ユーザー：所有グループ」を「chown」コマンドなどでここで指定したユーザーIDやグループIDに変更することで、SFTPから指定の権限にてそのファイルを操作できるようになる。セカンダリグループIDでもう一つ別のグループも割り当てることができる。
ちなみにここで「Unable to load key file "new.ppk" (PuTTY key format too new)」などのエラーメッセージが出た場合（私は出ました）、鍵とWinSCPのバージョンが合っていないのが原因のため、以下記事を参考にしてもらえると解決すると思います。 ccportal.ims.ac.jp
以上、長々とお付き合い頂きありがとうございました！この記事がどなたかのお役に立てれば幸いです。
