AWSのコミュニティJAWSが主催するEKSのワークショップ案内が来ていて、せっかくなので申し込んでみた
JAWS-UG コンテナ支部 #27 EKSワークショップ ハンズオン – connpass
仕事で、LambdaやDynamoDB。ECSあたりは使う機会はあるにはあるんだけど、EKSはまだちょっとない。
実際問題、EKSを使うようなアプリケーション開発ってどうなるだろうな？という興味と、AWS資格を取るうえで実際に触って覚えるのが一番と思ったことが動機。
なにより、オフラインでのワークショップが久しぶりなんですよね。
あまり、オフラインのコミュニティワークショップに出かけてコミュニケーションが取れたためしが無いくらい、コミュニケーションベタではあるのですが、いいきっかけにすることができればとは思っています。
ぶっちゃけ勉強自体は座学でも動画でもできなくはない。
それでも、動き出すというところに意味がると思っているので、あとはちゃんと意味があるように動くというところです。
たまたまですが、イベントにいくつか参加しました
ここのところ、登録はすれどもなかなか参加できなかったりしていたのでちょっと久しぶりです
ソフトウェアアーキテクチャメトリクス – Forkwell Library #44
ソフトウェアアーキテクチャメトリクス – Forkwell Library #44 – connpass
毎度おなじみのForkwellさんによるイベント。今回は「ソフトウェアアーキテクチャメトリクス」という本の訳者さんが登壇。
オライリー本なので、なんとなくタイトルからアーキテクチャに対しての何かしらのメトリクスを取得するための手法だとかがまとまっているのかな？と思っていたのですが、そうではないよう。
10人のアーキテクトが思い思いに話をしている内容であって、訳者の方いわく「エッセイ」だと。
なるほど。
オライリー本は、時々そんな感じのエッセイ本を出しますよね。
言ってしまうと、まだ話をまとめるには時期尚早ということなのかもしれないな、と思った。
NECグループAWS活用の裏側大公開｜Well-Architectedフレームワークとコミュニティ
NECグループAWS活用の裏側大公開｜Well-Architectedフレームワークとコミュニティ – connpass
こちらはAWSに焦点を当てたもの。
でも、よくよく考えて見るとこちらもアーキテクトの選択で何を重要視するのか？だったり、選択したアーキが正しかったのかを振り返るという観点では通じるものがあるかもしれないな？と思った。
AWSの資格試験では基本的にUdemyを中心に勉強をすることが多いのですが、存在は知っていてもちゃんとWell-Architectedフレームワークを読んだことないな、と思いました。
落ち着いて考えてみると、一度それを頭に読み込んでから資格勉強したほうがいいのでは。。。と今更ながらに思ったわけです。
AWS Well-Architected – 安全で効率的なクラウドアプリケーション (amazon.com)
このあたりの資料はそれなりの頻度で更新されていきます。
そもそものAWSサービス自体が追加されていくので結構たいへんですよね。。。
イベントでは、どうやってこれらのレビューをやっていくのかとかも話されていたので興味深かったです。
一方で、自社でそこまで回していくのは、それなりに規模がないと厳しいような気もしましたが、そのあたりはしっかりと学んでいないものの言い訳なのかも。
うーん、勉強しないとですね
前に取得したAWSの資格SAAが今年の10月に有効期限切れを起こしてしまうので、それまでに更新するか、ひとつ上のSAPを取得する必要があります。
というわけで、どうせならSAPを取ってしまおうかと思いのんびりと勉強を始めようかと。
まずはIAMからです。
「IAM Permission Boundaries」と紹介されていて日本語訳はアクセス許可の境界と出ているけど、さっぱり意味がわかりませんでした。
マネージドコンソールに入ってみると確かに有りますね
IAM エンティティのアクセス許可境界
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html
許可ポリシーとは別に定義されているように、許可の境界を定義しても、その定義した許可が適用されるわけではなく、あくまで境界を定義するのみ。
この境界が定義されていると、許可ポリシーをいくら割り当ててもこの境界の範囲内でしか適用されなくなるようです
ちょっと注意が必要になるのはリソースベースのポリシー適用時。
リソースベースのポリシーでも、IAMユーザに対するもの、IAMロールに対するもの、IAMロールセッションに対するものとで考え方が異なるということです。
この内、IAMロールに対してリソースベースのポリシーを適用した場合はアクセス許可の境界の制限を受け、それ以外は許可の制限を超えてアクセスすることができるそうです。
許可の境界を設定すると、指定されたIAMユーザはその権限範囲を超えるロールの作成やユーザの作成ができなくなる。。。？
なので、安全にIAMユーザ作成などの権限を移譲することができる、、と書いてある。
アクセス許可の境界を使用した他のユーザーへの責任の委任https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate
上記例で考えると、作成したアクセス許可の境界を、IAM作成時に指定することをポリシーで強要することで実現していることがわかる。
分からなくもないけど、なんとなく、現実にどこまで使っているんだろうか疑問に思う機能だなぁと思った。
AWS の勉強をしていると時々出てくるVPCエンドポイント。
単語レベルでは覚えていても理解しているとは言い難いところが多いので、一度自分なりに整理して理解に努めて見る
VPC エンドポイント
https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/vpc-endpoints.html
そもそもAWSでいうエンドポイントとは、AWSのサービスに対してアクセスするための必要なURLのようなものとの認識です。
RDSなどがそうですが、サービスによっては構築時にエンドポイントが作成され、エンドポイントに対して接続することでそのサービスを利用することができるようになります。
VPCエンドポイントは、例えばVPC内に配置されたECSやEC2などに構築されたサービスから、パブリックなインターネットを介すことなく他のAWSサービスに対してアクセスを行うために用いられます。
これによってVPC内のリソースから安全かつ高速なアクセスを提供することができます。
実際のところAWS内でインターネットゲートウェイを介してサービスを呼出す際は、パブリックなネットワークを経由せずに、AWSネットワーク内にとどまるため、料金もかかりません。
（VPN経由でAWSサービスにアクセスした場合は転送量がかかる）
しかし、その制御はあくまでAWS側でやってくれているのであって明示的なものではなく、VPCエンドポイントを作成せずにアクセスするにはインターネットゲートウェイなどを必要とします。
ゲートウェイ型は初期に導入されたエンドポイントで、S3とDynamoDBのみが対応しています。
それ以降のエンドポイントはインターフェース型で提供されており、S3のみゲートウェイ型とインターフェース型の両方に対応しています。
Gateway Load Balancerエンドポイントは、セキュリティサービスであるGateway Load Balancerを用いてセキュリティ検査を行う際、トラフィックをインターセプトするために用いられるため、他の二つのエンドポイントとは基本的に異なるものと考えています。
S3をのぞいたサービスに関しては、ゲートウェイエンドポイントとインターフェースエンドポイントの二つで選択肢はないですが、S3の場合にはどちらを用いるのか、その違いを把握しておく必要があります。
ゲートウェイエンドポイントを用いる場合、利用者はサービスのグローバルIPを用いてサービスに対してアクセスをします。
この時、エンドポイントの設定が完了すると、VPCルートテーブルにゲートウェイへのルートが追加され、その先はAWS側でうまいこと処理されてサービスに届きます。
それと引き換え、インターフェースエンドポイントでは、VPC内にサービスアクセス用のENI（ElasticNetworkInterface）が作成され、サービス利用者はそのプライベートIPに対してアクセスをするという形をとります。
また、インターフェースエンドポイントに対してセキュリティグループを設定することが可能なので、細かいコントロールをしたい場合には有効かもしれません。
インターフェースエンドポイントはゲートウェイエンドポイントの拡張であり、互換性を持ち、同じVPC内にこれら二つのエンドポイントを用いることができます。
注意しなければならないのは、インターフェースエンドポイントは時間当たりの料金と、インターフェースを介した通信トラフィックは課金対象となる点です。
インターフェースエンドポイントはサービスごとに用意する必要が生じるため、増えれば増えるほど料金が増すので、本当にトラフィックをプライベートにする必要があるのかは検討が必要そうです。
ゲートウェイエンドポイントに関しては課金対象とならないためそれら違いを理解したうえで利用する必要があります
オンプレミスからのアクセスといっても、VPNやDirectConnectを利用した際の話。
この時、PrivateNetwork経由でS3へアクセスするためにインターフェースエンドポイントを利用することができるというもの
Amazon S3 simplifies private connectivity from on-premises networks
https://aws.amazon.com/jp/about-aws/whats-new/2023/03/amazon-s3-private-connectivity-on-premises-networks/
VPCエンドポイントのインターフェースエンドポイントにて、プライベートDNSオプションが利用可能になったとのこと。
VPCエンドポイントがVPC内からのアクセスに対するエンドポイントを提供するのに対して、複数のリージョン間でレプリケートされたS3を一番近いロケーションに対してルーティングするためのグローバルエンドポイントを提供するのがマルチリージョンアクセスポイント。
この機能に対して、クロスアカウントでレプリケートされたものも対象とする更新が行われたとアナウンスがあった
Announcing cross-account support for Amazon S3 Multi-Region Access Points
https://aws.amazon.com/jp/about-aws/whats-new/2023/03/cross-account-support-amazon-s3-multi-region-access-points/
ただ、このアナウンスで何が変わったのかがいまいち理解できていない。
手順としては、クロスアカウントでパーミッションを与えてレプリケーションを可能にし、その後にマルチリージョンアクセスポイントを設定するような流れなので、どのあたりが新規にサポートされた部分なんだろうか？
DirectConnectからS3に直結！「AWS PrivateLink for Amazon S3」を試してみたhttps://dev.classmethod.jp/articles/privatelink-for-amazon-s3/
「Amazon S3 インターフェースエンドポイント（PrivateLink）ではプライベート DNS をサポートしていません」 の意味を絵をかいて腹落ちさせてみたhttps://dev.classmethod.jp/articles/s3-privatelink-diagram/
Configuring replication when source and destination buckets are owned by different accounts
https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-walkthrough-2.html
Amazon S3 マルチリージョンアクセスポイント
https://aws.amazon.com/jp/s3/features/multi-region-access-points/
VPC エンドポイント
https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/vpc-endpoints.html
Gateway Load Balancer エンドポイント (AWS PrivateLink)
https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/vpce-gateway-load-balancer.html
Types of VPC endpoints for Amazon S3
https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#types-of-vpc-endpoints-for-s3
Gateway Load Balancer の使用開始方法
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/gateway/getting-started.html
2つのVPCエンドポイントの違いを知る
https://dev.classmethod.jp/articles/vpc-endpoint-gateway-type/
AWSのBlogを見ていたら、こんな記事が
新着 – Amazon CloudFront で Amazon S3 Object Lambda を使用してエンドユーザーのためにコンテンツをカスタマイズする
https://aws.amazon.com/jp/blogs/news/new-use-amazon-s3-object-lambda-with-amazon-cloudfront-to-tailor-content-for-end-users/
AWSのサービスは多岐にわたっているけれど、いくつかのサービスは全く新しいものというよりは、既存のサービスの組み合わせで出来ていることもある。
今回紹介されているS3 Object Lambdaも名前からそうなんだろうと想像はついたんだけど、聞いたことはなかったので触ってみた
https://aws.amazon.com/jp/s3/features/object-lambda/
S3に配備されたファイルを取得したりする際に、前処理としてLambdaを走らせることができるというものらしい。
単純にS3格納時に処理してしまえばいいのでは？と思ったが、画像などを複数のアプリケーションで共用するケースには難しくなってしまう。
S3にはオリジナルを配備し、アプリケーションごとに必要な加工を施して提供するという場合には間にLambdaなどで処理を挟み込めれば楽だ。
それら用途を考えた際に、アクセスする経路を作るのがS3 Access PointでそこにLambdaを関連付けるのがObject Lambda Access Point。。。
言ってる意味はわかるがややこしくなってきそうだ
Using Amazon S3 Object Lambda to Dynamically Watermark Images as They Are Retrieved
https://aws.amazon.com/jp/getting-started/hands-on/amazon-s3-object-lambda-to-dynamically-watermark-images/
Pythonで書かれたLambdaをS3 Get時に呼び出すことによって、ObjectLambda経由で呼び出された際には画像に対して文字を埋め込むというチュートリアル。
Lambda Layerがうまく関連づかなくてエラーになってしまったけど、マネージドコンソールで設定したら問題なく実施できた
今回のAWSブログで紹介されていたエイリアスももちろん確認。
CloudFrontまでは設定してはいないけれど、この機能周りに関しては少しは理解が進んだかな。
今回は、画像に対して文字を埋め込むという内容だったけれど、元画像に対しての処理としてはサイズ変更や拡張子変更などのほうがユースケースとしては多そうだ。
もちろん、それらはクライアントサイドでもできるだろうけれど。
一方で、そのたびにLambdaが走るというのは積み重なると結構な金額になってしまわないのだろうか？は気になる。
利用目的がはっきりしているのであればやはり、S3格納時に処理をするべきだし、セキュリティ的な意味合いがないのであればこれらの処理に関してはクライアント側で処理することも選択肢の一つとして考えるべきだと思う。
Lambdaを逐次走らせるという利点を考えるのであれば、やはり動的な処理ということなんだろうな。
これじゃないとNGな処理に関しては何があるのか、気がついたらまた考えてみよう。
昨日、AWSのイベントであるAWS INNOVATEが開催されました
https://innovate-modernapps-apj.virtual.awsevents.com/home
しばらくはアーカイブが有効なので、ちょこちょこと見直しておきたい。
カンファレンスでは、実際のところそこまで細かい内容には触れないので、良し悪しだとは思うんだけど、
ざっくりと全体像をつかむという意味ではわかりやすい。
特にAWSみたいに多くのサービスを提供していると、自分が触ったことがあるところ以外に関しての知識がSAA取得時に勉強したところから止まっている・・・・と言うより忘れているんですよね。
オープニング、コンテナ、サーバレス
このあたりはざっくりと確認して復習してます
そろそろ、止まっているDAの勉強再開とSAPの勉強を始めないといけないな。
先日あった、技術書店13で購入した「HANDS-on LINEBOT」に従う形ではあるんだけど、一通りのLINE-BOTを作る工程を学んだ
HANDS-on LINEBOT
https://techbookfest.org/product/3EUnJ5WbexvCDyMgSJS1qb?productVariantID=1bFbTUsxUPrDGXzGCQQNUF
BOTというと、LINEだけでなくTwitterやSlackなど、様々なところで昔からあるんだけど、恥ずかしながらこれまで作ったことはなかったんですよね。
興味自体はあったといえばあったんだけど、あくまでなんとなくであって、特にそれを使って何かをしたいかな？とも思わなかったというのが理由ではあります。
じゃ、今回なにかそういう新しいきっかけがあったのか？と言われると、特にはないんだけど、LINEの公式アカウントだったりミニアプリは結構面白いかな、と思っているんですよね。
iOSなりAndroidなりにアプリを提供しようとすると、AppleやGoogleに対して審査を通す必要が出てきてしまいますし、何より手間がかかる。
そこをLINEに乗っかることが出来るのであれば、結構楽にいいコミュニケーションチャネルを構築できるのでは？と前々から思っていました。
そういう事をしようと考えると、LINE-BOTは抑えておきたい内容です
当然のようにLINE-BOTの本なので、LINEメッセージの受け答えや、メッセージの種類。それぞれの表現などに関して学ぶことが出来たのは言うまでもないですが、他にもいくつか収穫はあったかな、と思います。
今回の最終形は、バックエンドをAWSのLambdaとDynamoDBで構築するというもの。
ただ、開発としてはローカルで行っていきます。
Lambdaに関してはnodeで動かすわけですが、DynamoDBに関してはDockerで提供されているものを使う形でした
amazon/dynamodb-local
https://hub.docker.com/r/amazon/dynamodb-local/
aaronshaf/dynamodb-admin
https://hub.docker.com/r/aaronshaf/dynamodb-admin
こんなのがあったんですね～。
クラウドネイティブなサービスを開発するうえで、ローカルでの開発をどうするのか？は正直わかっていませんでしたが、こういうものを利用することで、ローカルとプロダクションを同じように出来るんだな、と。
さらに、Serverless用の環境構築ツールとしてServerless Frameworkを使っていました
Serverless framework
https://www.serverless.com/framework
正直これに関しては、例えば AWS であれば Cloud Formation だったり、CDK ( Cloud Development Kit ) を使うのに比べてのメリットってなんだろう？がそこまでよくわかっていません。
マルチクラウド環境で使える・・・？でも定義に思いっきりAWSとか描いたりしているもんなぁ。。。と。
CDKとの比較で考えると、YAMLかコードか？というところが大きい気もする。
ただ、このあたりのCaIは私は経験値が少なすぎます。
積極的に、こういう場合はどうなるんだろう？をやっていくべきなんでしょうね
もう一つは、それなりに対応が可能なLINE-BOTの実装例としてのサンプルコードですね。
今回の実装はExpressを使っているので、あくまでその一つのサンプルにはなりますが。
そもそもの話として、LINEで出来るのは基本的にはメッセージのやり取りではあるので、今回の構成はそれほど大きく変えることなく使い回せるのでは？と思います。
もちろん、今回の実装例をもとに、別のフレームワークなどで実装してみて練習するというのもいいな、と思いました。
LINE-BOT関係でいうと、次はこのあたりを使って見ると、よりいろいろなサービスを使う形ができて面白そうだ
試験日まで毎日励ますサーバーレスLINE Botを作ろう(マネジメントコンソール編)
https://blog.usize-tech.com/encourages-serverless-linebot/
もちろん、何かしらのチュートリアルみたいなものをやって、それをブラウザで見るというのは一つの経験ではあるんだけど、LINEのような普段使っているプラットフォームで、自分が組んだプログラムが応答を返してくれるというのは、素直に面白いと思うのです。
先日、友人から子供に対してレゴのプログラミング教室か、Unityのプログラミング教室とか、そういうところに通わせようかと思っているんだけど、どう？って聞かれたのです。
その時には、何がしたいのか次第だよな・・・とか、実際にオフラインで教わることが出来るのであればレゴとかがいいけど、オンラインであれば物理的な部品が絡んでくるレゴはやめたほうがいいんじゃない？と返したのですが、こういう、リアクションが返ってくるようなプログラムから、プログラミングの世界に入っていくのも結構ありなんだろうな、と思ってしまいました。
先日、AWS のオンラインセミナーシリーズであるBlack Beltを見ていたら、こんなものが
見る限りでは、まだまだ改良の余地がありそうな顧客体験に感じるけれど、ちょっと未来的ですよね、SmartMirror。
そこで、SmartMirrorに関してちょっと調べてみた
そもそもの話、鏡とは？ということに関してもちゃんと知らないことに気がつく。
そもそも鏡とガラスってどう作られるのか？ガラスはなんか砂を溶かしてやるって漫画で見たぞ？
こちらのサイトを見る限りでは、鏡＝ガラス＋銀 or アルミニウム背面のようだ。
SmartMirrorでは、背面としてディスプレイを使うし、鏡自体もマジックミラーを使うらしい。
ラズパイを用いる
作り上げるにはRaspberryPiを使うと、すでに世の中にはノウハウが溜まっていて楽そうだ。特にOSSでMagicMirrorを作るためのプラットフォームが用意されている
MagicMirror²
https://magicmirror.builders/
調べてみるとYouTubeにもDIY動画などが上がっていて、意外と簡単に作ることができそうだ。
実装そのものは、技術的には別に問題なくできそうだ。
とは言え、作ったとして何にどう使うのか？を考えてみたい。
事例としてよく挙げられている内容としては、鏡に天気予報やニュース、メッセージなどを出すということなんだけど・・・
スマホでいいよね？
という結論に至ってしまう。もしくはスマートウォッチ。
鏡に文字が浮かび上がるのは、未来感もあるし、言ってしまうとSF的な感じもする。
ロマンだ
だけどせっかくなら有用な利用用途を考え出したい。
スマホなどと違って、鏡であること。
それであって、RaspberryPiで出来るレベルの表現
思いつかないな。。。
とりあえず、いつの日かロマンを追い求めて作り出すかもしれないので、見つけたサイトを備忘録に載せておくことにする
AWSのAPI Gatewayを触っていて、若干混乱してきたので、簡単ではあるけれどまとめる
API Gateway が対応しているAPIのタイプとしては下記の4種類
・HTTP API
・WebScoket API
・REST API
・REST API (プライベート)
GCPで提供しているAPI GatewayプロダクトであるApigeeでは、WebScoketに対しての対応が正直いまいちなので、そういう意味ではWebScoketを試してみたいが、WebScoketクライアント用意したりするのも面倒なので、ここでは通常のREST APIを題材とする
まずは、APIの集合体に対しての名前付けとプロトコルの選択をする。
REST APIを選択したはずなのに、WebScoketが選択肢として残っているのは意味があるのだろうかと疑問を感じるが、気にしない。
ちなみにエンドポイントタイプのデフォルトは”リージョン”。エッジ最適化を選択すると、CloudFrontが用いられる形のグローバル利用を想定したAPIになる。
ここでは、GithubAPIを例にして作ってみることにする
初期状態ではAPIのRootが存在するだけ。ここからリソースやメソッドを追加していく。まずはGistのAPIを作ってみようと思うので、リソースの追加でGist。メソッドとしてGetを追加してみる。
GETメソッドを追加すると上記のセットアップ画面に。
「統合タイプ」という日本語がどうなのか？という気がするが、呼び出しとして何を利用するのかを選択することができる。
多くのAPI GatewayチュートリアルではLambdaを呼び出すつくりになっている。
既存のAPIをEC2や別途提供しており、それを呼び出す形であればHTTPになる。
試しに、GithubAPIを直接呼び出してみる
・統合タイプを「HTTP」
・HTTPメソッドを「GET」
・エンドポイントURLを「https://api.github.com/gists」
にする
メソッドを作成するとこのような画面になる
ブロックが大きく分けて4つ。
| メソッドリクエスト | クライアントから見た時のこのAPIの呼び出し仕様の定義 |
| 統合リクエスト | 統合先（最終的な呼び先、ターゲット）をどう呼ぶのか |
| 統合レスポンス | 統合先からのレスポンスをどう処理するかを定義。 基本的にはそのままだと思う |
| メソッドレスポンス | クライアントに返すレスポンスの定義 |
“テスト”をクリックし、実際にメソッドを走らせてみると、レスポンスとしてGithub.comから結果を受け取れていることが確認できる。
これでメソッドとしては作ることができたのだが、本家のAPIではいくつかのQueryParameterを受け取ることができる。せっかくなのでこれも実装する
「メソッドリクエスト」にて「URLクエリ文字列パラメータ」を追加する。本来はどれも任意のパラメータだが、試しにpageとper_pageを必須にしてみる
見ると、統合リクエスト側にも自動的に追加されていた
クエリパラメータを指定せずにテストをしてみると、エラーに・・・ならない。
よく見ると、メソッドリクエストに黄色△マークが出ている。
結論からいうと、デフォルトでは値の検証機能はなぜかOFFになっていて、明示的に指定する必要があった。
「設定」欄にある「リクエストの検証」を選択する
それにしても、UIが鉛筆マークがついているとはいえ、何が設定値なのかの判別が難しすぎる。非常にわかりづらいと思うのは私だけであろうか。
これで実行すると、期待通り400エラーとなってくれ、パラメータを指定することで結果が正しい形で取得出来ていることが確認できる。
次にsinceパラメータを試してみる。
ちょっと意地悪で、日付書式不足を設定してみると
書式のバリデータに引っかかったようで、レスポンス本文にエラーが出ている。
ただ、ステータスコードは200となってしまっている。
ログを見ているとわかるのだが、実際のところGithubからは422が返却されている。
これは、API Gatewayの設定で「メソッドレスポンス」と「統合レスポンス」を正しく設定していないことに起因する。
デフォルトでは、すべてのレスポンスがステータスコード200で返却するようになっているのだ。
とりあえず、ありえそうなメソッドレスポンスを定義して
統合から何が返ってきたときにどのメソッドレスポンスを関連付けるかを設定します
そもそも、デフォルトが200というのがおかしいのであって、統合から200が返ってきたときだけ200を返却し、定義にない返却値の場合は500にしておいた。
デフォルトのマッピングは、項目でいうと「HTTPステータスの正規表現」を空にするとよい
これで、クエリパラメータの書式エラーは500となった。
未定義のステータスコードがデフォルトになってしまうというのはどうなんだろう？
そのまま返してくれればいいのになってことで、デフォルトをなくしてみると
結局500エラーで、しかもInternal Server Errorときたものだ。
ままならぬ。
本当はバージョン管理周りをまとめたかったのだが、そこまで行きつかなかったので次回に。。
以前、書いたように AWS 認定資格である Solution Architect Associate 試験を昨日受けてきて、無事に合格しました
SAAは問題の難易度というか深さでいえば、それほど深くはないんでしょうけれど、出題範囲がとても広いので覚えるのが大変。
出題範囲の中心は主要サービスとはいえ、実際に自分で使ったことがないサービスが多いので、様々なケースにおいて何を選択すればよいのか？ということに関しては、合格した今でも不安が残ります。
だからこそAssociateレベルなんでしょうけれど。
実際のところ、これを取得したところでAWSに関して詳しくなったという実感はなく、こういうケースはどうなんだろう？という問いに、実際に実施できるのか？に関しては難しい。
いわゆる、「全然わからん」という状態になっている気分です。
というわけで、やはり次は開発だろうということで、Udemyにてコースを購入。勉強し始めました
Ultimate AWS Certified Developer Associate
https://www.udemy.com/course/aws-certified-developer-associate-dva-c01/
ちゃんと使えるように、SAAで勉強した内容をもとに実際に触って学んでいきたいところ。
いやはや、学びは尽きないですね。
自分のレベルが低いことはわかってはいるものの、少しずつでもマシになれるように頑張るぞっと
追記
よくよく見てみたら、スコアを発見。
720点合格で787点ということで、結構ギリギリだった。。。危ない危ない