Lambdaコンソール画面のモニタリング表示に必要だったアクセス許可

Lambdaのコンソール画面で引っかかった事象と解決方法の備忘録になります。

背景

社内で開催するAWSハンズオンで使うAWSアカウントに、参加者向けのポリシーを作る必要があった。 ハンズオンではLambdaをメインに触ってもらうが、他の案件や施策などで作った関数は非表示または実行できないように細かく設定していた。

事象

Lambdaコンソール画面のモニタリングタブを開くと表示されるはずのCloudWatch metricsなどが表示されない。エラーメッセージもないので何が悪いのか分からない状態。 CloudWatch関係のアクセス許可は設定済み。

何も表示されないモニタリングタブ

解決策

Lambdaの「ListVersionsByFunction」へのアクセス許可を与える。

表示されるようになったモニタリングタブ

解決のヒントは他のタブにありました。「エイリアス」「バージョン」タブを見ると「ListVersionsByFunction」のアクセス許可がないことを伝えるエラーメッセージがあったので許可を与えてみたところ、モニタリングタブも表示されるようになりました。

「バージョン」タブのエラーメッセージ

ListVersionsByFunctionとは？

事象は無事解決しましたが、せっかくなのでこの「ListVersionsByFunction」は何か調べてみました。 ListVersionsByFunction - AWS Lambda
list_versions_by_function - Boto3 1.34.39 documentation これは指定した関数名のバージョン固有の構成を含むバージョンのリストを返してくれるAPIになります。 以下のコードでどんなリクエストが返ってくるのか試してみました。

import json
import boto3

client = boto3.client('lambda')

def lambda_handler(event, context):

    response = client.list_versions_by_function(
        FunctionName='XXXX', #関数名を指定（必須）
        MaxItems=2 #リクエストに含むバージョンの最大数（任意）
    )

    print(json.dumps(response))

リクエストの結果は以下になります。（一部マスキング）

{
    "ResponseMetadata": {
        "RequestId": "9cdf1a2d-a8c5-40c1-8ac1-8dfd84d25a77",
        "HTTPStatusCode": 200,
        "HTTPHeaders": {
            "date": "Mon, 12 Feb 2024 06:21:58 GMT",
            "content-type": "application/json",
            "content-length": "1211",
            "connection": "keep-alive",
            "x-amzn-requestid": "XXXXX-XXXX-XXXX-XXXX-XXXXXXXX"
        },
        "RetryAttempts": 0
    },
    "Versions": [
        {
            "FunctionName": "XXXX",
            "FunctionArn": "arn:aws:lambda:ap-southeast-2:XXX:function:XXX:$LATEST",
            "Runtime": "python3.12",
            "Role": "arn:aws:iam::XXX:role/service-role/XXX-role-XXX",
            "Handler": "lambda_function.lambda_handler",
            "CodeSize": 543,
            "Description": "",
            "Timeout": 10,
            "MemorySize": 256,
            "LastModified": "2024-02-00T16:26:22.000+0000",
            "CodeSha256": "XXXXXXXXXX",
            "Version": "$LATEST", #最新バージョン
            "TracingConfig": {
                "Mode": "PassThrough"
            },
            "RevisionId": "XXXXX-XXXX-XXXX-XXXX-XXXXXXXX",
            "PackageType": "Zip",
            "Architectures": [
                "x86_64"
            ],
            "EphemeralStorage": {
                "Size": 512
            },
            "SnapStart": {
                "ApplyOn": "None",
                "OptimizationStatus": "Off"
            }
        }
    ]
}

取得するバージョンの最大数に2を指定しましたが、指定した関数にはバージョンが１つしかないので最新バージョンの構成情報だけ入っています。
リクエスト内容を見るとランタイムやロール名にメモリサイズなどの構成情報が取得できているのが分かります。CLIで構成情報を見たいときや、Lambdaの構成管理ツールを自作したいことがあればこのAPIを使うのが良さそうですね。
推察ですが、モニタリングタブのCloudWatch metrics表示するときにはこのAPIで取得できるバージョンとロール名の情報を使っているでしょうか？

若手エンジニアのやる気がまぶしかった初AWS GameDay

先日2023 Japan AWS Top Engineers/2023 Japan AWS All Certifications Engineers/2023 Japan AWS Jr. Champions受賞者に招待された「AWS GameDay Cloud Ops Co-op(以降GameDay)」に参加してきました。問題のネタバレにつながりそうな内容は書かない前提でブログやSNSに書いていいと話があったので、様子や感想を書いておこうと思います。
＊賞に関して気になった方は文末の参考に関連リンクを貼ってありますので、そちらをご参照ください。

GameDayとは

そもともGameDayとは？概要をサイトから抜粋します。

AWS GameDay

AWS GameDay は、チームベースの環境で、AWS ソリューションを利用して現実世界の技術的問題を解決することを参加者に課題として提示する、ゲーム化された学習イベントです。従来のワークショップとは異なり、GameDay は自由で緩やかな形式で、参加者は固定概念にとらわれずに探索し、考えることができます。

当日の様子

AWSJAPAN APNブログでの当日のレポートです。シナリオの一部も紹介されています。

AWS GameDay Cloud Ops Co-op 2023 年 12 月開催レポート | AWS JAPAN APN ブログ

私の様子

今回のチーム組成方法はくじ引きなので、上位入賞するに強いメンバーと同じチームになるくじ運が必要だったと思います。
受賞者が招待されているGameDayなので、AmbassadorやTop Engeneersの方と組めたら心強い、色々学びたいと思ったり、逆に足を引っ張ることにならないようにがんばらないと思ってました。
くじ引きの結果、私のチームは以下の通りになりました。

チーム構成：
1.他社Jr.ChampionsだけどAWSをあまり触れていない
2.１人目と異なる他社の若手インフラエンジニア。クラウド未経験でAWSを触るのはこのイベントが初めて
3.私。AWSでアプリ開発運用はしたことあるが、インフラ領域の運用経験はなし

あれ？？クラウド未経験者がいる。。。？
受賞者向けのイベントだと思っていたのでクラウド未経験の方がいたのには正直驚きました。メンバー全員の利用経験を鑑みると上位入賞を狙うよりも今回は楽しむことを優先することにしました。

Game開始！！

ルール説明が終わった後早速始まりました。
今回はモブでやるというルールがあったので、チームでどうやって作業を進めるか相談してから問題に取り組み始めました。特にリーダーは決めなかったですが、私だけ中堅だったので自然とリーダーの振る舞いをしていたと思います。

問題の方ですが、テーマ通り運用課題がお題となっており、普段のAWSの実務経験、特にトラブルシューティング経験が少ないと難しい問題が多かったと思います。またヒントも少ないので未経験者はさらに厳しそうです。
経験が少ない自チームは悩みながらも、不足している経験を補うために活発にコミュニケーションを取りながら解いていきましたが、残念ながら半分ぐらいしか解けませんでした。 ＊お題の一部は先述したAWSJAPAN APNブログに記載があるので興味あれば読んでみてください。

結果は22位/25位と残念な順位となりました。
やはり悔しかったのか初めてAWSを触った若手インフラエンジニアの方は「次はリベンジしたい。資格を取ったり、AWSの案件に入ったりして経験を積みたい！！」と強い向上心が芽生えており、
中堅の私からはその若手がまぶしく見えたのと、感化されて次に向けてAWSを触る機会を増やしたいと強く思えたと思います。

所感

・非常に楽しかった！ 約4時間ずっとAWSコンソール画面とにらめっこして頭をずっと使って疲れましたが、やはり実際に触ったりアレコレ会話しながら進めるのは楽しかったです。
・自社の方が上位入賞してよかった！！他チームに入っていた自社社員が上位入賞していました！メンバー構成を見ると羨ましいなと思いつつも、私の代わりに成果を出してもらってホッとしました。
・技術力向上のモチベーションがアップした！！普段遭遇しないシステム構成での問題を解いたり、触ることが少ないAWSサービスを触れることで技術力不足を痛感しました。また、同チームの若手の活気からもやる気をもらうことができました。

参考

2023 AWS Top Engineers クライテリアのお知らせ | AWS JAPAN APN ブログ
2023 AWS ALL Certifications Engineers クライテリアのお知らせ | AWS JAPAN APN ブログ
2023 AWS Jr. Champions クライテリアと申し込みサイトのお知らせ | AWS JAPAN APN ブログ

Infrastructure from Codeに入門してみた

はじめに

当ブログはQiita Advent Calendar2023に投降した下記ブログの転載＋加筆になります。 初アドカレついでにQiitaを試してたのですが、運営している本ブログにも載せます。

qiita.com

Infrastructure from Code（IfC）とAmptについて少し学習したので、整理して書きたいと思います。

きっかけ

ServerlessDays Tokyo2023のAWS Eric JohnsonのセッションでIfCという単語を初めて聞いたのですが、中身について触れなかったので何なのか分からなかったのとIaCと何が違うのか気になったためです。

https://tokyo.serverlessdays.io/

Infrastructure from Codeとは何か

アプリケーションコードから必要なクラウドリソースを推測して、自動でアプリケーションの基盤となるインフラストラクチャをクラウドにプロビジョニングするアプリケーション構築のプロセス。

例えば、アプリケーションコード内にAPIのGETやPOSTが書かれていれば、CDNにAPIサーバが必要だと推測して、AWSならCloudFrontにAPI Gateway、Lambdaのリソースを自動でプロビジョニングしてくれるようです。

背景

サーバーレスアーキテクチャの開発ではクラウドリソースのプロビジョニングにはInfrastructure as Codeのプロセスで行っていましたが、アプリケーションの開発者からすると下記の課題があったようです。 インフラストラクチャコードもコードではあるものの、アプリ開発者にとってはインフラにあたるので極力インフラストラクチャコードすらも書かないようにしたいという思いがあるようにも見えます。

　①多量のインフラストラクチャコードを書く必要がある

　②アプリケーションコード側にサービス制御のコードが書けない。

　③アプリケーションコードとインフラストラクチャコードが密結合になり変更が容易でない。

①はインフラストラクチャコードは何十、何百行と書く必要があり、さらにサーバーレスだと複数のサービスを組み合わせてアプリを開発するので、サービスの数だけインフラストラクチャコードが増えてしまい作業時間が増えて、アプリケーションコードを書くのに割ける時間が減ってしまう。

②はタイムアウトや処理中断時の制御はアプリケーション側でも検討するが、制御するコードはインフラストラクチャコードに書かないといけない。例えばLambdaのタイムアウト時間。

③どのアプリケーションコードがどのインフラストラクチャ上で動くのか宣言しておく必要があり、どちらかに変更があると、もう片方への影響調査や改修が発生してしまう。

IaCの例

課題を具体的にコードで例えてみます。 趣味で開発していたBedrockへリクエスト送受信をするだけのLambda関数をSAMテンプレートコード化してみました。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: An AWS Serverless Specification template describing your function.
Resources:
  bedrocktest:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: .
      Description: ''
      MemorySize: 128
      Timeout: 70-----②
      Handler: lambda_function.lambda_handler-----③
      Runtime: python3.11
      Architectures:
        - x86_64
      EventInvokeConfig:
        MaximumEventAgeInSeconds: 21600
        MaximumRetryAttempts: 2
      EphemeralStorage:
        Size: 512
      Layers:
        - arn:aws:lambda:us-east-1:XXXXXXXXXX:layer:boto3-1_28_73:2
      RuntimeManagementConfig:
        UpdateRuntimeOn: Auto
      SnapStart:
        ApplyOn: None
      PackageType: Zip
      Policies:----以下②
        - Statement:
            - Sid: VisualEditor0
              Effect: Allow
              Action:
                - bedrock:*
              Resource: '*'
            - Effect: Allow
              Action:
                - logs:CreateLogGroup
              Resource: arn:aws:logs:us-east-1:XXXXXXXXXX:*
            - Effect: Allow
              Action:
                - logs:CreateLogStream
                - logs:PutLogEvents
              Resource:
                - >-
                  arn:aws:logs:us-east-1:XXXXXXXXXX:log-group:/aws/lambda/bedrock_sample:*

たった1つの関数ですがSAMテンプレートコードの場合はインフラストラクチャコードが45行になりました。実際のアプリだともっとたくさんの関数があるでしょうし、他のサービスも使うとその数だけコード量が増えます。また、関数間やサービス間の通信に認証認可のためのコードも書く必要が出てくると思われます。 これが課題①にあたるところになります。

課題②はTimeoutやPoliciesがそれらにあたると思われます。処理のタイムアウト時間や他サービスとの通信制御をするためのコードはアプリ側ではなく、インフラストラクチャコードに書かざるえません。

課題③はHandlerと②がそれらにあたると思われます。Lambdaのお約束として、Handlerに書かれたLambda関数ハンドラーをアプリケーションコード側にも書く必要があります。そのため、Lambdaから他サービスに移植したいとなったときはアプリケーションコードを改修が必須となります。また、他AWSサービスと連携させたいときには、アプリケーションコードだけでなく、インフラストラクチャコードに連携するAWSサービスとの認証認可のコードを書く必要が出てきており、アプリケーションコードとインフラストラクチャコードが密結合になっていると言えるのではないでしょうか。

＊課題②③はコードスニペット内の該当コード右側に「②」「③」を付記しています。

Self Provisioning Rumtime

課題に関して、解釈的アプローチで考えていった結果、アプリケーションコードとインフラを紐づける部分を自動的に推測してプロビジョニングさせることを思いつき「Self Provisioning Rumtime」と名付けたようです。

　①アプリケーションロジックから必要なリソースとアクセス権限を推測させる

　②イベントハンドラーでサービス制御を処理

　③サービスとの通信を構造から自動的にマッピングさせる

この3点について、クラウドアーキテクチャを設計したことがある方は頭の中の思考や設計書で似たようなことしていた経験があるかと思います。 機能要件で求められているある機能のアーキテクチャを設計するときに、数分で処理が終わりそうな機能要件に対してはLambdaを選ぼう。もし、数分で終わらないときを考慮してタイムアウト時間を設けるようにしよう。処理結果をもしS3に保管する必要があるなら、LambdaにS3への書き込み許可を付与するロールを作ろうと言った経験です。 Self Provisioning Rumtimeはまさしくこの思考を自動でやろうというアイデアと言えそうです。

サービス

簡単にですが、IfCのサービスを紹介します。何をベースにしているかで４つに分類できるらしく、既存のアプリケーションコードに簡単に導入できそうなサービスもあれば、一から開発が必要なサービスもあり、使ってみたいときは導入するアプリの状況によって検討することになるかなと思います。

プログラミング言語ベース：Wing、DarkLang クラウドリソース定義のための新しいプログラミング言語を利用する。

SDKベース：Ampt、Nitric アプリケーションコードに独自の SDK を導入して利用する。

Annotations + Frameworks：Encore、Shuttle 既存のプログラミング言語にフレームワークにライブラリの追加やアノテーションを付けて対応している。

Pure Annotations：Klotho 既存のアプリケーションコードのインラインコメントでアノテーションすることで対応する。

ぱっと見ると、プログラミング言語ベースは最もと導入難易度が高く、記載順に導入難易度が下がっていく感じがします。

実際にどうプロビジョニングされるのか

冒頭の技術カンファレンスで紹介されていたという理由でAmptの場合、Lambdaはどのようなコードからプロビジョニングされるのか見てみます。

• Ampt構成

コードの前に少しだけAmptの構成を説明します。

簡易構成図と手順

こちらはAmptのサイトにある構成図と実際に操作した経験からイメージした簡単な構成図とアプリ開発の流れになります。図の右側は学習内容と動きから想定されるイメージのため誤っている可能性がある点ご承知おきください。 先述した通り、AmptはSDKベースのサービスです。開発するにはSDKが必要です。ソースコードの管理はGitHubになります。 また、クラウドプラットフォームがありRuntimeやアプリ管理のコンソール画面などの機能を備えています。

ユーザーはAmptのSDKをインストールした開発端末上でアプリ開発を行い、デプロイを行います（図の①）。するとAmptがRumtime機能によりソースコードの解析を行い（図の②）、クラウド上に必要なリソースをプロビジョニングしてアプリが稼働するクラウドインフラを構築します（図の③）。構築したアプリの状況はAmptのコンソール画面にアクセスして管理を行います（図の④）。

• コード例

では、どうLambdaだと推測してプロビジョニングされるのかスケジュールタスクのコードを例に説明します。

//1時間毎にログを出力する。
schedule.every("1 hour", () => {
  console.log("I run every hour!");
});

「.every」はスケジューリングを定義するためのメソッドで、時間指定やcron形式を用いて定期実行を可能にします。このコードでは1時間ごとにログ出力を行います。AmptのRumtimeはこのコードから何のサービスをプロビジョニングすべきか推測を行います。例では、スケジューリングを行えるサービスとログ出力を行うコンピューティングサービスが必要だと推測して、AWSにあるそれらに該当するサービスであるEventBridgeとLambdaをプロビジョニングする。という流れになるようです。

もう１つ例をあげてみます。

//タイムアウトを20分に設定したコード。
schedule.every("12 hours", { timeout:1200000 } () => {
  console.log("I run every 12 hours!");
});

前と同じスケジューリングのコードですが、「timeout」のハンドラーが存在しています。タスクのタイムアウトをミリ秒で指定でき、例では1200000ミリ秒＝20分を指定しています。このスケジュールタスクをプロビジョニングするとき、timeoutの指定通りに最低20分は稼働するコンピューティングサービスを選択する必要があるため、タイムアウトが最大15分であるLambdaではなく、Fargateをプロビジョニングする判断をするようです。

所感

• サーバーレスにはインフラストラクチャを意識させないという要素がありますが、背景から推察するとIaCではまだどのインフラにアプリを乗せるかといったインフラストラクチャを意識させる部分があり、真のサーバーレスに近づけるためにも新しいプロビジョニング方法が求められていたのかなと思いました。

Fighting off faux-serverless bandits with the true definition of serverless — Momento

• Self Provisionig Rumtimeで自動化する3点は自分も開発で苦労していた部分で、自動化できないのかと考えたこともありましたが、本当に自動化するサービスが実現していたことに驚きました。
• 触ったサービスの特性やまだ歴史が浅いのもありますが、本格的に導入するのはまだ厳しそうに感じました。でも、クラウドインフラストラクチャを一切意識せずにアプリ開発ができるので、小規模な個人開発や新規サービスのモックアプリ開発で導入してみるのはありかもしれないと思います。
• 今回書けなかったですが、学習にあたってAmptのアカウントを作成し、サンプルアプリをプロビジョニングするところまで触ってみました。CLIやブラウザベースのコンソール画面から操作できるのですが、UIとしてもクラウドインフラストラクチャを意識させるようなところはなく、最初の印象としてはAmptはIfCの考えを徹底しているサービスだなと感じています。触ってみたところは、別途ブログにしたいと思います。
• これが本格的に普及したらクラウドエンジニアの仕事が減るかもしれない…

参考

学習のために見たサイトと動画です。

Infrastructure from Code (IfC)

AWS re:Invent 2022 - Unleash developer productivity with infrastructure from code (COM301) - YouTube

State of Infrastructure-from-Code 2023 - Klotho

Infrastructure-from-Code vs Infrastructure-as-Code

Ampt

ServerlessDays Tokyo2023に参加してきました

はじめに

掲題の技術イベントに参加してきました。当イベントへは初参加だったのですが、豪華ゲストが登壇していたり、久しぶりに生で話を聴けたり、他社のエンジニアと交流できたりして良い刺激やサーバーレスに関する示唆を感じることができました。

イベント概要

サーバーレスに関するテクノロジーカンファレンスです。

日本での開催は4年ぶりとなり、海外のAWS Heroや元Amazon DynamoDB担当の方など海外からも複数のゲストが登壇しておりました。

テーマ：「もっとうまくやりたい、誰よりも上手にやりたい」

日時：

　１日目カンファレンス：2023/9/23(土) 9:00-17:30＊～20:00頃まで懇親会

　２日目ワークショップ：2023/9/24(日)

　＊１日目のカンファレンスのみ参加

会場：クラスメソッド（日比谷フォートタワー26階）

イベントサイト＆アジェンダ：https://tokyo.serverlessdays.io/

少しだけ会場の様子

serverlessdaysの旗

serverlesspressoで注文したコーヒーと予約票

AWSが会場で提供していたコーヒーです。スマホから「serverlesspresso」と呼ばれるコーヒー注文サービスを使って注文できました。 こちらにチュートリアルとコードがあります。

https://serverlessland.com/reinvent2021/serverlesspresso

セッション

メモは取っていましたが、下記のQiitaブログの方が詳細に書かれているのでリンクを貼っておきます。 セッションは３会場に別れていましたが、こちらの方のブログは私と全て同じセッションを受講しておりました。

※筆者の方には本当に感謝しております。

https://qiita.com/minorun365/items/b03fed43fabc245fad38

https://qiita.com/minorun365/items/3ea48a1bbb94f5b1d020

懇親会

ピザとお酒（私はお茶）を片手に同じテーブルになった方と受講できなかったセッションの情報交換や感想、果ては抱えている技術的課題の相談などをしました。数個でも新しい知見を得ることができてよかったです。また、話しかけた人の素性を後で知って驚くなど懇親会があるオフラインイベントらしい出会いがあったのも面白かったです。

※AWS12冠Tシャツを着ている方を数名見かけましたが、懇親会”後”に気づいたのでお話できなかったのは残念です。

所感

初めてサーバーレスと呼ばれたサービスだと言う「AWS Lambda」は今年で生誕9年目と知って、そんなに経つのかと驚きました。サーバーレスでサービスやシステムを開発する場合、パブリッククラウドにあるFaaSやPaaSに分類されるサービスとCI/CDツールを組み合わせて開発するサーバーレスのエコシステムができあがっていたように個人的に思います。AWSだとAPI Gateway、Lambda、DynamoDB、S3、EventBridge、CloudFormationといった組み合わせが一例です。

しかし、キーノートや亀田さんからのサーバーレスの変遷を聴いていると、TiDB Serverlessやmoment、Cloudflare、winglangなどパブリッククラウド以外のサービスの拡充によりサーバーレス開発のパラダイムシフトが起きつつあるなと感じました。

将来、パブリッククラウドを使わずに、「快適な開発者体験」ができるサーバーレスサービスを使って、高速なサービス開発をするのが一般的になるときがくるかもしれません。

※よくよく考えるとコンピュータの歴史では「集中」と「分散」を繰り返していると言われますが、サーバーレスならではの「分散」の時代がやってくるのかもしれませんね。

AWS Certified Cloud Practitioner新試験（CLF-C02）の変更点を調べてみた

目次

はじめに

最近発表されたのですが、AWS Certified Cloud Practitioner（以下CLF）の新試験（CLF-C02）が2023/9/19から始まるみたいです。

AWS Certified Cloud Practitioner 認定 | AWS 認定 | AWS

CLFはAWS認定の中でも入門的な位置付けの試験で、AWSまたはクラウドを学習するときに最初の目標として受験計画を立てる方も多いかと思います。そのような位置付けから試験変更の影響を受ける人も多いかと思います。ちょっと現試験（CLF-C01）からの変更点を調べてみたので、大きい変更点だと感じた3点を記載します。

比較対象

変更点はAWSから提供されている下記の試験ガイドを比較しています。
現試験：CLF-C01試験ガイド

https://d1.awsstatic.com/ja_JP/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf

新試験：CLF-C02試験ガイド
https://d1.awsstatic.com/ja_JP/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide_C02.pdf

１．「移行」が試験対象に追加！

CLF-C01では「移行」に関する知識は対象外と明記されていましたが、CLF-C02では対象外項目には明記されておらず「第1分野クラウドのコンセプト」に「1.3: AWS クラウドへの移行の利点と戦略を理解する。」が追加されています。
　
対象スキルに下記２点が記載されており、これらに関する設問が増えるかと思われます。
　• AWS Cloud Adoption Framework (AWS CAF) の利点の理解 (ビジネスリスクの軽減、環境・社会・ガバナンス [ESG] パフォーマンスの向上、収益の増大、運用効率の向上など)
　• 適切な移行戦略の特定 (データベースのレプリケーション、AWS Snowball の使用など)

AWS CAFは「AWSクラウド導入フレームワーク」の事で、クラウド導入による組織への影響と導入のためのスキルやプロセスをまとめた枠組みの様です。

AWS クラウド導入フレームワーク

また、試験範囲内のAWSサービスにも下記が移行分野として追加されていました。
実際に出題されるか分かりませんが、学習しておいた方が良さそうです。　
　• AWS Application Discovery Service
　• AWS Application Migration Service
　• AWS Database Migration Service (AWS DMS)
　• AWS Migration Hub
　• AWS Schema Conversion Tool (AWS SCT)
　• AWS Snow ファミリー
　• AWS Transfer Family

２．「セキュリティとコンプライアンス」の出題比率が5%アップ！

AWS認定の試験ガイドには、その試験が対象とする分野と出題の比率が記載されています。合計100%になるように割り振られており、比率を見てどの分野に勉強時間を割くか検討できたり、AWSがどこを大事にしているか推察する材料になります。
　
CLFは4分野あり、「セキュリティとコンプライアンス」の出題の比率が25%→30%にアップしています。問題数にすると12問→15問と3問程度の増加で、気にするほどでもないかもしれませんが合格を確実にするためんも注力して学習したほうが良いと思います。

ちなみに、アップがあるならダウンもあるわけで下記2分野が下がっています。
　・クラウドのコンセプト　26%→24%（2%ダウン）
　・請求、料金、サポート　16%→12%（4%ダウン）
請求と料金の知識はAWSを使う上で大事だと思うのですが、昨今の状況からセキュリティの方が重要と判断したんでしょうか。当試験以外で問われない分野だったと思うのでAWS認定全体での学習機会が元々少なかったのですが、さらに学習機会が減りそうです。お金のことなので大事だと思うのですが。

３．「付録」のページ数が倍になった！≒覚えることが増えた

試験ガイドの巻末には試験範囲のツール・技術コンセプトやAWSサービスが羅列してある「付録」があり、出題される可能性ある単語やAWSサービスを把握することができます。

CLF-C01は3ページだったのが、CLF-C02は6ページとなりページ数だけでも覚えることが増えたことが分かります。今回の試験更新まで約4年経ってるいるので、その間に追加されたAWSサービスを踏まえれば妥当だと思いますが、初めてAWSを学習する人にとっては一つの壁になりそうです。

最後に

以上、簡単にはなりますがCLF新試験の大きい変更点だと感じた3点でした。変更内容から覚えることが増える前に現試験で合格を目指そうとする人や今から新試験を想定した学習計画を立てる人もいるかと思いますが、このブログの内容が試験学習の一助になれば幸いです。

「# JAWS-UG初心者支部#54 AWS SAM HandsOn SAM、FastAPI、Mangum での API 開発ハンズオンをやってみる」に参加しました

久しぶりにハンズオン形式の勉強会に参加しました。

せっかくなので久しぶりに備忘兼ねてブログにしておきます。

Comassの勉強会ページ

https://jawsug-bgnr.connpass.com/event/278270/

◇参加目的

　・AWS SAMの概要・使い方を知りたい

　・Lambdaを使ったAPI開発の雰囲気を知る

　・AWS SummitのLTに興味がある

◇API開発ハンズオン内容

　詳細内容や手順はハンズオンページを見て頂ければと思いますが、SAM、FastAPI、Mangum とを組み合わせて、API GatewayとLambdaを使った簡易的な API 開発とOpenAPIを使ってAPIのドキュメント化を体験する内容となっております。

　ハンズオンページ：

　https://aws.amazon.com/jp/builders-flash/202304/api-development-sam-fastapi-mangum/

　●ハンズオンで使ったツールやサービス

　ハンズオンで私が初めて触ったツールやサービスについて紹介します。

　　・AWS Serveless Application Model

　　　サーバーレスアプリケーション構築用のオープンソースフレームワークです。

　　　CloudFormationの拡張機能でより簡潔にテンプレートを記述できるようです。また、ローカル環境にビルドして様々な方法で検証が可能であり、実際の環境に構築する前にローカルでデバッグできるのは良さそうだと感じました。

　　　勉強会中の質問で、「SAMの使い道や他（Amplifyなど)との違い」を聴かれていたのですが、「サーバーレスサービスを使ったバックエンド機能の自動構築に使える。サービスは限られているので、その範囲の構築をするなら便利。範囲外のサービスを使うならCloudFormationやCDKで書いた方がよい」と回答されておりタメになりました。

　　・FastAPI

　　　https://fastapi.tiangolo.com/ja/

　　　PythonでAPIを構築するためのWebフレームワークです。PythonでAPI開発をするときの一般的なOSSという認識で名前は知っていました。特徴はハンズオンページに記載されています。

　　・Mangum(読み：マンガム）

　　　https://mangum.io/

　　　AWS Lambda で ASGI アプリケーションを実行し、Lambda Function URL、Amazon API Gateway、Application Load Balancer、Lambda@Edge の各イベントを処理するためのアダプタだそうです。このハンズオンで初めて聞きました。

　　　FastAPIと互換性があり、LambdaでAPIを構築するときにFastAPIとMangumを使うことで書かないといけないソースコード量を減らすことができるようです。

　　　一例として、Lambdaの標準方法でコーティングする場合と比較して、下記の冗長的なソースコードの記述量を削減できるみたいです。

　　　　・イベントオブジェクトからデータを読み込んで、メソッドごとの分岐条件を書く

　　　　・レスポンスするJSONを書く

　●ハンズオンの副次的な学び

　　　当初目的ではなかったですがハンズオンの流れで知ることができました。

　　　・Lambdaのコンテナイメージを作成して関数を構築する実例

　　　・AWSサービスの最新バージョンの確認手順

　　　　→AWSの公式ドキュメントではなく、Githubのリリースノートを参照していた。

　　　・Cloud9のローカル環境でWebアプリを立ち上げる方法

◇AWS Summit LT

　　　初めて参加する方向けに過去のAWS Summitの写真を見ながら雰囲気を伝えたり、どんなセッションがあるのか、何に参加するのか話をしておりました。ゲームのセッションが人気あるねという話題が出て、バイオハザードのセッションに行く人がいらして羨ましかったです。私が見たときは既に満席でした泣　代わりにスクエニさんのセッションを登録しましたが、AWSエンジニア受賞発表の時間と被り、泣く泣くキャンセルしました。。。

　　　また、メモをどうやって取っていたかという話題も出ました。電源や座席のサイズの問題でノートでメモを取っていたと話を聴き、勉強会終了後に慌ててノートを買いに行きました笑　数年ぶりのオフラインイベントで忘れていたのですが、私もノートにメモを取っていたのを思い出してので聞いて良かったです。

◇最後に

　久しぶりのハンズオンの勉強会参加とブログ執筆でした。 　API開発の雰囲気を知ることができてよかったです。LTを聞いて明日からのAWS Summitが楽しみになりました！！

最後までご閲覧ありがとうございました。

AWS Certified Data Analytics - Specialty合格記録

2022年2月に「AWS Certified Data Analytics - Specialty (DAS)」に合格したので勉強の記録と所感を残します。

目次

前提知識と経験

以下のクラウド系の資格を持っています。

• AWS Certified Solutions Architect - Associate(SAA)
• AWS Certified Solutions Architect - Professional (SAP)
• AWS Certified Developer - Associate (DVA)
• Google Cloud Certified Professional Cloud Architect (PCA)
• Google Cloud Certified Professional Data Engineer (PDE)

また、仕事でも最近はAWSのサーバレスサービスを使ったシステムとソリューションの開発をしています。

受験理由

技術的好奇心と今後AWSを使っていく機会が多くなるので知識を深めていきたいためです。
今回初めてSpecialty分野を受験したのですが、GCPの類似試験であるPDEを持っていたので似た知識を活かせると考えてDASを受けることにしました。

勉強期間

2021年12月～2022年2月初週までで、実際の勉強時間は約50～60時間でしょうか。

試験概要

AWSのデータ分析ソリューションサービスの理解を問う試験になります。 　 試験時間：180分 　 　 問題：65問 (SAPより10問少ない） 　* 合格ラインスコア：750（ラインレンジ：100-1000） 詳細は公式サイトを参照してください。 試験ガイドに対象AWSサービスが載ってますが、古いためなのか実際は少し違っていたと思います。

AWS Certified Data Analytics - Specialty 認定

学習リソース

書籍

書籍で勉強するタイプなのですが、この資格の対策本は現在なかったので関係する書籍「AWSで始めるデータレイク」で基礎知識の勉強をしました。
前半はデータレイクの概要に設計論、AWSのデータ分析ソリューションの紹介があり、後半はデモシステム開発演習と各データ分析ソリューションの性能改善方法の解説があります。
当試験の範囲を網羅できて、最初の学習テキストとしてよかったです。

AWSではじめるデータレイク: クラウドによる統合型データリポジトリ構築入門

公式ドキュメント

「データ分析レンズ – AWS Well-Architected」を読んで、より深くAWSのデータ分析ソリューション活用のベストプラクティスを学びました。

分析レンズ - AWS Well-Architected フレームワーク - 分析レンズ

他にも、各AWSサービスの仕様を理解するため後述の問題に出てきた機能を中心に公式ドキュメントを読んでいます。

オンライン学習

・WEBサイト「WEB問題集で学習しよう(koiwaclub」の有償プランに入り、約200問を解いています。不正解の問題は解説を読み、メモを取り、理解を深めました。

AWS WEB問題集で学習しよう

・AWS無料模擬試験を２回解く。 昨年末から無料になった公式模擬試験を２回解いて、合格率を80%ぐらいまで到達しています。

試験本番

コロナ禍でしたが試験はテストセンターで受験しました。オンライン受験も選択肢にありましたが、要件を満たす試験環境を準備できないので止めています。
また運が悪かったのか、私が使ったマシンではマウスの反応がイマイチで数回クリックしないとチェックが付かない事象が発生して焦りましたが、10分ぐらい残して全ての問題を解くことができました。

所感

778点とギリギリでしたが初回で合格できて良かったです。
SAPと比較すると対象サービス数は少ないですがサービス一つ一つの仕様や機能を深く把握している必要があり、勉強範囲から漏れた仕様や機能に関する問題が出ると全く分からずカンで解くこともしばしばありました。
感覚ですが3割はカンで解いた気がします。なのでギリギリのスコアなのも納得です。個人的にはMSKやQuickSightはもう少し勉強が必要ですね。

参考サイト

・資格受験記録
AWS Certified Data Analytics – Specialty(DAS) を取得できたので振り返ってみた | DevelopersIO

AWS Certified Data Analytics - Specialty合格体験記 | フューチャー技術ブログ

AWSデータ分析資格 合格への道 | 日本能率協会グループ 株式会社 ジェーエムエーシステムズ コラムサイト

・AWS無料模擬試験の受験方法
ななななんと！AWS認定の模擬試験が無料になりました！！ | DevelopersIO