AWS CDKでLambda関数URLを使う

はじめに

先日Lambda関数URL(Function URLs)という機能を試してみました。

これを使うとAPI Gatewayを使わずに、Lambdaの設定からURLの発行ができます。

詳しくは公式ドキュメントを確認してください。

Lambda 関数 URL - AWS Lambda

今回は、最初にマネジメントコンソールで機能を試した後、同様の環境を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の記事を参考にさせて頂きました。

aws.amazon.com

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,
  }
});

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.amazon.com

AWS CDK入門ガイドやってみた

SIEM on Amazon OpenSearch ServiceとかでCDKに触ることはあったのですが、 雰囲気で使っていたので入門ガイドやってみることにします。

aws.amazon.com

環境

  • macOS Monterey Ver 12.3.1

環境構築

AWS CLIのインストール

AWS CLIを環境に合わせてインストールしておきます。 自分の場合はbrew installで入れました。

$ brew install awscli

docs.aws.amazon.com

$ 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]:

docs.aws.amazon.com

Node.jsのインストール

AWS CDKの動作にはNode.jsが必要です。

複数バージョンを管理するためにnodebrewを入れておくと良いかと思います。 良かったら前回のブログ記事も参考にしてみてください。

shinsys24.hatenablog.com

$ node --version
v16.15.0

$ npm --version
8.5.5

AWS CDK CLIのインストール

npmAWS 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

catalog.us-east-1.prod.workshops.aws

nodebrewでNode.jsの複数バージョンを管理する

Node.jsの複数バージョンを切り替えられるnodebrewをインストールしてみました。 既に公式のインストーラからNode.jsを導入済みだったこともあり、アンインストール手順から記載しています。

環境

  • macOS Monteray Ver 12.3.1
  • Homebrew Ver 3.4.10

Node.jsのアンインストール

Qiitaの記事を参考にさせて頂き、既存のNode.jsを削除しました。

qiita.com

  • nodeの場所を確認
$ which node
/usr/local/bin/node
  • nodeの削除
$ rm -rf /usr/local/bin/node
  • npmの削除
$ rm -rf .npm

nodebrewのインストール

公式ではcurlwgetを使ってパッケージを取得していますが

今回はhomebrewを使いました。

github.com

$ 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.amazon.com

ハンズオンについて

今回試したハンズオンは「AWS Amplify を用いた Web サイトの構築方法を学ぼう」になります。

ハンズオン資料 | AWS クラウドサービス活用資料集

下記URLにある、Amplify Docsのチュートリアル(React版)の一部を実施する形式で進みます。 コードは用意されているので、Reactの学習経験がなくても大丈夫です。

https://docs.amplify.aws/start/q/integration/react/

動画収録時とチュートリアルの表現が一部で変わっている部分もありますが、特に問題なく進められました。

セッション一覧

  1. 今回のハンズオンで作る構成とAmplifyの紹介
  2. AWS Amplify のハンズオン(環境構築、Cloud9 編)
  3. AWS Amplify のハンズオン(環境構築、CLI 編)
  4. AWS Amplify のハンズオン(FE/API/DB 編)
  5. AWS Amplify のハンズオン(Auth 編)
  6. AWS Amplify のハンズオン(Hosting 編)
  7. 本シリーズのまとめ、リソースの削除

完了までの所要時間は大体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を指定する
  2. VPCピアリングによる接続を承認する
  3. 各ルートテーブルにVPCピアリングへの経路を追加する

1. VPCピアリングを作成する

VPCが準備できたので、VPCピアリングを作成します。

案内に従って接続したい2つのVPCを選択すればOKです。

VPCの左側メニューからピアリング接続を開きます。

ピアリング接続するVPCmain-vpcを選択します。

main-vpcを選択

次に、もう一方のVPCpeering-vpcを選択します。

今回は同一アカウント・同一リージョンのVPC間を接続しますが、 別アカウント・別リージョンのVPCにも接続できます。

peering-vpcを選択

ピアリング接続を作成をクリックします。

2. VPCピアリングの接続を承認

VPCピアリングを作成後、接続先VPCのアカウントでピアリング接続の承認が必要になります。

今回は同一アカウント内のVPCをピアリングするため、アカウントを切り替えずに承認できます。

VPCピアリングを選択し、アクションからリクエストを承諾をクリックします。

3. VPCピアリングへの経路追加

次に、VPCピアリングへの経路を追加します。

VPCのパブリックサブネットに関連付いたルートテーブルを編集し、 送信先として接続先VPCIPアドレス空間を追加します。

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つのVPCVPCピアリングで接続してみました。 設定としては接続したいVPCを指定するだけで済むので非常にシンプルかと思います。

推移的な接続はできないので、 3つ以上のVPCで設定する場合はそれぞれでVPCピアリングが必要な点は注意です。*1

*1:複数で繋ぐ場合はAWS Transit Gatewayを使うと良さそう

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をデプロイ済み

github.com

アラートの作成

OpenSearch Dashboardsにログインし、左側メニューのAlertingから設定していきます。

下記の項目を設定します。

  • Destinations
  • Monitors
  • Triggers
  • Actions

Destinationsがアラートの送信先の設定です。

Monitorsで監視するメトリクスを設定し、Triggersでアラートを発火させる条件を設定します。 最後にActionsでアラートのメッセージを設定します。

何が(Monitors)、どうなったら(Triggers)、どう通知する(Actions)のイメージで理解しました。

Destinationの作成

最初にアラートの送信先を設定します。

Destinationsタブから新しいDestinationを追加します。

Add 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

Destinationの作成

Monitorsの作成

次にアラート対象のメトリクスや頻度を設定します。 今回はルートアカウントでの作業があったときに通知を送ることにしました。

Monitorsタブから新しいMonitorを作成します。

Create monitors

項目名
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

Triggersの設定

Actionsの設定

最後にアラートが発火した時の通知内容を設定します。

Message subjectMessageがメールの件名と本文になります。本文はデフォルト設定のままにしました。

項目名
Action name root action notification
Destination Alert Topic - (Amazon SNS)
Message subject Root Action

Actionの設定

動作確認

ルートアカウントでいくつか作業したあと、 aes-siem-alertサブスクリプションに登録されたメールアドレスに通知が届けば完了です。

まとめ

SIEM on Amazon OpenSearch Serviceでアラートを作成してみました。

複数アカウントのログをSIEM環境に集約している場合は、通知設定もSIEM上に集約できることになり便利かと思いました。

参考

github.com