AWS CDKでLambda関数URLを使う
はじめに
先日Lambda関数URL(Function URLs)という機能を試してみました。
これを使うとAPI Gatewayを使わずに、Lambdaの設定からURLの発行ができます。
詳しくは公式ドキュメントを確認してください。
今回は、最初にマネジメントコンソールで機能を試した後、同様の環境をAWS CDKで実装します。
環境
関数URLの有効化(マネジメントコンソール)
早速、機能確認のためマネジメントコンソールから関数URLを有効化してみます。
Lambda関数の作成
まずはLambdaで関数を作成します。
関数名:
HelloFunctionURL
ランタイム:
Python 3.9
詳細設定
詳細設定を確認すると関数URLを有効化
があるので有効化します。
認証タイプ:
NONE
オリジン間リソース共有(CORS):
有効化
これらを入力した後、関数の作成
をクリックします。
"Hello from Lambda!"とレスポンスを返すシンプルな関数が作成されます。
import json def lambda_handler(event, context): # TODO implement return { 'statusCode': 200, 'body': json.dumps('Hello from Lambda!') }
動作確認
早速、設定
タブから関数URL
を開くと既に有効化されたURLが記載されています。
URLをクリックすると実行結果が表示されます。
関数URLの有効化にチェックするだけなのでお手軽で良い感じです。
関数URLの有効化(AWS CDK)
同様の実装をCDKでも試してみます。
実装はAWS公式のbuilders.flash
の記事を参考にさせて頂きました。
- プロジェクト用のディレクトリ作成
mkdir cdk-lambda-url-test
- CDKの初期化
cdk init app --language typescript
cdk.json
にリージョン情報を追記
〜〜省略〜〜 ], "context": { "region": "ap-northeast-1" } } }
bin/cdk-lambda-url-test.ts
にリージョン情報を追記
const app = new cdk.App(); const stack_region = app.node.tryGetContext("region"); new CdkLambdaUrlTestStack(app, 'CdkLambdaUrlTestStack', { env: { region: stack_region, } });
lambda
ディレクトリを作成し、hello.py
を作成する
CDKのプロジェクト直下にlambda
ディレクトリを作成します。
hello.py
の内容は冒頭のサンプルコードをそのまま流用します。
mkdir lambda && touch lambda/hello.py
lib/cdk-lambda-url-test-stack.ts
にリソースを定義
Lambdaのランタイム設定や関数URLの有効化などを定義します。
デプロイ後に関数URLを知る必要があるのでCfnOutput
で出力します。
import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as lambda from 'aws-cdk-lib/aws-lambda'; import { CfnOutput } from 'aws-cdk-lib'; export class CdkLambdaUrlTestStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); // Lambdaの設定 const hello = new lambda.Function(this, 'HelloHandler', { runtime: lambda.Runtime.PYTHON_3_9, code: lambda.Code.fromAsset('lambda'), handler: 'hello.handler' }); // 関数URLの設定 const fnUrl = hello.addFunctionUrl({ authType: lambda.FunctionUrlAuthType.NONE, cors: { allowedMethods: [lambda.HttpMethod.ALL], allowedOrigins: ["*"], }, }); // 関数URLの出力 new CfnOutput(this, 'FuntionUrl', { value: fnUrl.url }); } }
- cdk Toolkitのデプロイ
cdk bootstrap
- CDKのデプロイ
cdk deploy
動作確認
デプロイ完了時、コンソールに関数URLが出力されます。
実際にアクセスして"Hello from Lambda!"が表示されることを確認します。
参考
AWS CDK入門ガイドやってみた
SIEM on Amazon OpenSearch ServiceとかでCDKに触ることはあったのですが、 雰囲気で使っていたので入門ガイドやってみることにします。
環境
- macOS Monterey Ver 12.3.1
環境構築
AWS CLIのインストール
AWS CLIを環境に合わせてインストールしておきます。
自分の場合はbrew install
で入れました。
$ brew install awscli
$ aws --version $ aws-cli/2.7.0 Python/3.9.12 Darwin/21.4.0 source/x86_64 prompt/off
インストールできたら、アクセスキーID/シークレットアクセスキーを設定します。
$ aws configure AWS Access Key ID [None]:**************** AWS Secret Access Key [None]:**************** Default region name [ap-northeast-1]: Default output format [json]:
Node.jsのインストール
AWS CDKの動作にはNode.jsが必要です。
複数バージョンを管理するためにnodebrew
を入れておくと良いかと思います。
良かったら前回のブログ記事も参考にしてみてください。
$ node --version v16.15.0 $ npm --version 8.5.5
AWS CDK CLIのインストール
npm
でAWS CDK CLI
をインストールします。
sudo npm install -g aws-cdk
AWSアカウントのブートストラップ
CDKのデプロイに必要なリソースをAmazon S3
上に用意します。
いわゆるAWS CDKを使うためのおまじないで、 同一AWSアカウント同一リージョンであれば一度だけ実行すればOKです。
$ cdk bootstrap aws://123456789012/ap-northeast-1
CDKを試してみる
2つのアベイラビリティゾーンを持つVPCをCDKで作成します。
作業用のディレクトリを作っておきます。
$ mkdir cdk-demo $ cd cdk-demo
CDKでTypeScriptを使うように初期化します。
$ cdk init --language typescript
cdk-demo/bin.cdk-demo.ts
を編集し、デプロイ先となるAWSアカウントIDとリージョンを追記します。
#!/usr/bin/env node import 'source-map-support/register'; import * as cdk from '@aws-cdk/core'; import { CdkDemoStack } from '../lib/cdk-demo-stack'; const app = new cdk.App(); new CdkDemoStack(app, 'CdkDemoStack', { env: { account: '123456789012', region: 'ap-northeast-1' }, });
VPCやサブネットを作成するには専用のクラスが必要になります。
EC2モジュールをインストールします。
$ npm install -g @aws-cdk/aws-ec2
package.json
に追加したEC2モジュールの情報が自動で追記されます。
"dependencies": { "@aws-cdk/aws-ec2": "^1.155.0", "aws-cdk-lib": "2.23.0", "constructs": "^10.0.0", "source-map-support": "^0.5.21" }
cdk-demo/lib/cdk-demo-stack.ts
を編集します。
EC2モジュールからVpc
クラスとSubnetType
クラスをインポートし、
2つのAZを指定したVPCを用意します。
import * as cdk from '@aws-cdk/core'; import { Construct } from 'constructs'; import { Vpc, SubnetType } from '@aws-cdk/aws-ec2'; export class CdkDemoStack extends cdk.Stack { constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const vpc = new Vpc(this, 'MainVpc', { maxAzs: 2, subnetConfiguration: [ { cidrMask: 24, name: 'public-subnet', subnetType: SubnetType.PUBLIC }, ] }); } }
CDKのデプロイ
ここまでできたらAWSアカウントにデプロイします。
デプロイするとCloudFormationがのスタックが定義されリソースが作成されます。
$ cdk deploy
CdkDemoStack/MainVPC
という名前でVPCが作成されています。
パブリックサブネットが2つ作られていることが確認できました。
クリーンアップ
作成したリソースは次のコマンドで一括で削除できます。
$ cdk destroy
まとめ
AWS CDKの環境構築からVPCのリソース作成まで一通りやってみました。
CloudFormationよりも記述量が少なく、コード補完も効くので書きやすくて便利だなと思いました。
もう少し詳しく知るためにBlackBeltの資料を見たり、 AWS CDK intro Workshopも見つけたのでまたやってみたいと思います。
- AWS CDK Intro Workshop
nodebrewでNode.jsの複数バージョンを管理する
Node.jsの複数バージョンを切り替えられるnodebrewをインストールしてみました。 既に公式のインストーラからNode.jsを導入済みだったこともあり、アンインストール手順から記載しています。
環境
- macOS Monteray Ver 12.3.1
- Homebrew Ver 3.4.10
Node.jsのアンインストール
Qiitaの記事を参考にさせて頂き、既存のNode.jsを削除しました。
- nodeの場所を確認
$ which node /usr/local/bin/node
- nodeの削除
$ rm -rf /usr/local/bin/node
- npmの削除
$ rm -rf .npm
nodebrewのインストール
公式ではcurl
やwget
を使ってパッケージを取得していますが
今回はhomebrew
を使いました。
$ brew install nodebrew
インストール完了後
.bashrc
か.zshrc
にパスを通します。
$ nano .zshrc
ファイル末尾に下記を追記します。
export PATH=$HOME/.nodebrew/current/bin:$PATH
- 設定の反映
$ source ~/.zshrc
Node.jsのインストール
nodebrew
が入ったので早速Node.jsをインストールします。
まず、nodebrew ls-remote
でインストール可能なバージョンの一覧を確認できます。
$ nodebrew ls-remote v0.0.1 v0.0.2 v0.0.3 v0.0.4 v0.0.5 v0.0.6 v0.1.0 v0.1.1 v0.1.2 v0.1.3 v0.1.4 v0.1.5 v0.1.6 v0.1.7 v0.1.8 …
LTS版であるv16.15.0
をインストールしました。
$ nodebrew install v16.15.0
利用するバージョンを明示的に指定します。
$ nodebrew use v16.15.0
正しくインストールできたことを確認します。
$ node -v v16.15.0
使い方
- 他のバージョンをインストールして切り替える
$ nodebrew install v18.1.0 $ nodebrew use v18.1.0
- インストール済みバージョンの確認
current
が現在利用しているバージョンになります。
$ nodebrew list v16.15.0 v18.1.0 current: v18.1.0
- 特定のバージョンのアンインストール
$ nodebrew uninstall v18.1.0
AWS Amplifyのハンズオンをやってみた
前々からAWS Amplifyが気になっていたので、AWS Hands-on for BeginnersのAmplify編を試してみました。
AWS Amplifyとは
フロントエンドやモバイルアプリの開発に必要なAWSのバックエンドを簡単に構築するための仕組みです。
AWSに関する知識がなくてもバックエンドを構築できる点がメリットかと思います。
フロントエンドからバックエンドに接続するためのAmplify Library
も用意されています。
Amplifyで構築できる機能
ハンズオンについて
今回試したハンズオンは「AWS Amplify を用いた Web サイトの構築方法を学ぼう」になります。
下記URLにある、Amplify Docsのチュートリアル(React版)の一部を実施する形式で進みます。 コードは用意されているので、Reactの学習経験がなくても大丈夫です。
https://docs.amplify.aws/start/q/integration/react/
動画収録時とチュートリアルの表現が一部で変わっている部分もありますが、特に問題なく進められました。
セッション一覧
- 今回のハンズオンで作る構成とAmplifyの紹介
- AWS Amplify のハンズオン(環境構築、Cloud9 編)
- AWS Amplify のハンズオン(環境構築、CLI 編)
- AWS Amplify のハンズオン(FE/API/DB 編)
- AWS Amplify のハンズオン(Auth 編)
- AWS Amplify のハンズオン(Hosting 編)
- 本シリーズのまとめ、リソースの削除
完了までの所要時間は大体1時間半くらいでした。
学んだこと
Amplify CLIの設定
AWSアカウントとの紐付けにあたる設定をします。
amplify configure
対話的に進める中でIAMのアクセスキーを発行するので、その情報をAmplify CLIに設定します。
ここで用意したIAMユーザーはAdministrator Access
権限を持っているので
アクセスキーの取り扱いに注意が必要です。
AWSバックエンド環境の初期化
アプリケーションのプロジェクト直下で初期化コマンドを実施します。
amplify init
APIを追加
質問に対話的に答えていくとAPIに必要なリソースが準備されます。
amplify add api
バックエンドのリソース確認
Amplifyで追加した機能をはじめとするバックエンドのリソースの確認ができます。
amplify status
バックエンドのデプロイ
amplify status
で確認した各リソースがデプロイされます。
デプロイの仕組みとしてAWS CloudFormation
が使われてるようです。
amplify push
認証機能の追加
Amazon Cognitoを使ったログイン環境を構築します。
amplify add auth
ホスティング環境の構築
リソースをホスティングするための環境を準備します。
amplify add hosting
ホスティング先にビルド・デプロイ
amplify push
に加え、アプリケーションをビルドし、ホスティング先にデプロイします。
amplify publish
Amplify環境の削除
Amplifyで構築した環境を削除します。
amplify delete
まとめ
ハンズオンを通してAmplifyに入門してみました。
チュートリアルの範囲ではAWSを意識せずにアプリケーション用のバックエンドやデプロイができたので、 AWSに詳しくない開発者でも簡単にリリースできるサービスと感じました。
これを足がかりにAmplify SNS Workshopなど、他のコンテンツも試してみようと思います。
VPCピアリングを試してみた
AWS Hands-on for Beginnersのネットワーク編#2をやってみました。 その中でVPCピアリングの設定をしたので手順をメモしておきます。
環境
VPCピアリングで接続する2つのVPCを準備しておきます。 それぞれのVPCにはパブリックサブネットを一つ定義します。
VPC名 | IPv4 CIDR |
---|---|
main-vpc | 10.0.0.0/16 |
peering-vpc | 10.1.0.0/16 |
主な手順
VPCピアリングを作成する主な手順は下記の通りです。
1. VPCピアリングを作成する
案内に従って接続したい2つのVPCを選択すればOKです。
VPCの左側メニューからピアリング接続
を開きます。
ピアリング接続するVPCmain-vpc
を選択します。
次に、もう一方のVPCpeering-vpc
を選択します。
今回は同一アカウント・同一リージョンのVPC間を接続しますが、 別アカウント・別リージョンのVPCにも接続できます。
ピアリング接続を作成
をクリックします。
2. VPCピアリングの接続を承認
VPCピアリングを作成後、接続先VPCのアカウントでピアリング接続の承認が必要になります。
今回は同一アカウント内のVPCをピアリングするため、アカウントを切り替えずに承認できます。
VPCピアリングを選択し、アクション
からリクエストを承諾
をクリックします。
3. VPCピアリングへの経路追加
次に、VPCピアリングへの経路を追加します。
各VPCのパブリックサブネットに関連付いたルートテーブルを編集し、 送信先として接続先VPCのIPアドレス空間を追加します。
main-vpcのルートテーブル
まず、main-vpc
のパブリックサブネットに関連付けられたルートテーブルに
peering-vpc
への経路を追加します。
送信先 | ターゲット |
---|---|
10.1.0.0/16 | 作成したVPCピアリング |
peering-vpcのルートテーブル
もう一方も忘れずに設定します。
peering-vpc
のパブリックサブネットに関連付けられたルートテーブルに
main-vpc
への経路を追加します。
送信先 | ターゲット |
---|---|
10.0.0.0/16 | 作成したVPCピアリング |
動作確認
ハンズオンではpeering-vpc
側にEC2インスタンス(10.1.0.100
)を作成し、
main-vpc
側のCloud9からping
を実行して接続を確認しました。
まとめ
2つのVPCをVPCピアリングで接続してみました。 設定としては接続したいVPCを指定するだけで済むので非常にシンプルかと思います。
AWS SSOでMFA設定を必須にする
AWS IAM等のアカウント管理する立場だと、利用者にMFA設定を促すことも多いと思います。
ただ、MFA設定は各ユーザーに自主的に実施してもらう必要があり、下記の懸念があります。
- MFA設定の手順を案内する必要がある
- ユーザーが設定するのを忘れてしまう
AWS SSOの場合、MFA設定を必須にすることができるので試してみました。 公式ドキュメントだとこちらになります。 docs.aws.amazon.com
AWS SSOの設定
AWS SSOを開き、左側メニューの設定
を開きます。
次にネットワークとセキュリティ
タブを開き、設定
をクリックします。
選択肢の中からサインインごと(常時オン)
を選択します。
また、MFA設定されていない場合の動作も設定できます。
今回の設定だとユーザーがサインインした時にMFA設定をするよう促されます。 この場合、MFA設定が完了しない限りサインインできません。
動作確認
AWS SSOのダッシュボードにログインします。
MFA設定が未完了の場合、MFAデバイスの登録
画面が表示されます。
まとめ
AWS SSOでMFA設定を必須にしました。 コンソール上の設定だけで簡単に済ませられるのが良いですね。
OpenSearch Dashboardsでアラートを作成
SIEM on Amazon OpenSearch Serviceでアラートを作成してみました。
環境
- AWS Control Towerが有効
- AuditアカウントにSIEM on Amazon OpenSearch Serviceをデプロイ済み
アラートの作成
OpenSearch Dashboardsにログインし、左側メニューのAlerting
から設定していきます。
下記の項目を設定します。
- Destinations
- Monitors
- Triggers
- Actions
Destinations
がアラートの送信先の設定です。
Monitors
で監視するメトリクスを設定し、Triggers
でアラートを発火させる条件を設定します。
最後にActions
でアラートのメッセージを設定します。
何が(Monitors)、どうなったら(Triggers)、どう通知する(Actions)のイメージで理解しました。
Destinationの作成
最初にアラートの送信先を設定します。
Destinations
タブから新しいDestinationを追加します。
各値は下記で設定しました。 Amazon SNSとIAMロールはSIEM環境をデプロイした時に作成済みのものを指定します。
- SNSトピック:
aes-siem-alert
- IAMロール:
aes-siem-sns-role
項目名 | 値 |
---|---|
Name | Alert Topic |
Type | Amazon SNS |
SNS topic ARN | aes-siem-alert のARN |
IAM role ARN | aes-siem-sns-role のARN |
Monitorsの作成
次にアラート対象のメトリクスや頻度を設定します。 今回はルートアカウントでの作業があったときに通知を送ることにしました。
Monitors
タブから新しいMonitorを作成します。
項目名 | 値 |
---|---|
Monitor name | Root Action |
Frequency | By interval 1 Minutes |
Index | log-aws-cloudtrail-* |
Time field | @timestamp |
Metrics | COUNT OF user.name |
Time range for the last | 5 minute(s) |
Data filter | user.name is root |
Index名はlog-aws-cloudtrail-*
と手入力します。
末尾に-*
を忘れると正しく動作しませんでした。
Triggersの設定
次にアラートの発火条件を設定していきます
項目名 | 値 |
---|---|
Trigger name | root count trigger |
Severity level | 1(Highest) |
Trigger condition | IS ABOVE 0 |
Actionsの設定
最後にアラートが発火した時の通知内容を設定します。
Message subject
とMessage
がメールの件名と本文になります。本文はデフォルト設定のままにしました。
項目名 | 値 |
---|---|
Action name | root action notification |
Destination | Alert Topic - (Amazon SNS) |
Message subject | Root Action |
動作確認
ルートアカウントでいくつか作業したあと、
aes-siem-alert
のサブスクリプションに登録されたメールアドレスに通知が届けば完了です。
まとめ
SIEM on Amazon OpenSearch Serviceでアラートを作成してみました。
複数アカウントのログをSIEM環境に集約している場合は、通知設定もSIEM上に集約できることになり便利かと思いました。