今回はAWSのEC2インスタンスを用いてApacheのBasic認証を導入していきたいと思います。 経緯としてはLPIC202の学習で座学の学習だけではApacheの設定関連のテスト範囲が記憶に定着しないため、実際に手を動かして覚えることを目的としております。 前提条件 Windows10を使用 PCはDELLを使用 東京リージョンを使用 Linux serverはAWSのEC2インスタンスを使用 Apacheがインストールされていること。 Basic認証の設定手順 １. htpasswdコマンドでユーザとパスワードを作成する $ htpasswd -c /etc/httpd/htpasswd testuser ２. ユーザとパスワードが作成されたことを確認する $ cat /etc/httpd/htpasswd ３. htpasswdファイルの所有者・グループ・権限を変更する $ chown apache:apache /etc/httpd/htpasswd $ chmod 600 /etc/httpd/htpasswd ４. 項番３で変更した内容が反映されていることを確認する $ ls -l /etc/httpd/htpasswd ５. httpd.confを編集してDirectoryタブに以下の内容を追記 $ vim /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf <Directory "/var/www/html"> AuthType Basic AuthName "auth" AuthUserFile /etc/httpd/htpasswd Require valid-user </Directory> ６. Apacheの起動状態を確認する $ systemctl status httpd.service ７.Apacheが起動していない場合は起動する（起動している場合は不要） $ systemctl start httpd.service $ systemctl status httpd.service ８. 設定ファイルを反映させる $ systemctl reload httpd.service Basic認証の動作確認 １. 任意のブラウザからhttp://{パブリック IPv4 アドレス}にアクセスして認証情報を入力するポップアップが表示されていることを確認 ２. htpasswdで作成した認証情報を入力してウェブページが表示されることを確認する あとがき 今回はBasic認証の設定手順について説明しました。 実際に手を動かすことでLPIC202に必要な知識が定着しやすいと感じました。 今後は積極的にLinuxを触っていき知識を積み上げていきたいと思います。

はじめに S3 Bucket で何らかのイベントが発生したときに、特定の処理を行いたいことがあります。例えば、大きい画像をアップロードしたあとに、自動的に小さいサムネイル画像を生成するといったことが考えられます。 このときに、S3 側でイベント通知を設定することで、SNS・SQS・Lambda・EventBridge と連携して、サムネイル画像生成といった様々な処理を行うことが出来ます。 今回の記事では、イベント通知を Lambda Function で受け取る手順を確認していきます。また、受け取ったイベントの中身も確認していきましょう。 Lambda Function を作成 イベント通知から受け取ったイベント内容を CloudWatch Logs に出力する Lambda Function を作成します。今回は、次のような Python の Lambda Function を作成しました。 import json from logging import getLogger, INFO logger = getLogger(__name__) logger.setLevel(INFO) def lambda_handler(event, context): print("============ logger.info の出力 ============") logger.info(json.dumps(event)) return { "statusCode": 200, "body": json.dumps({ "message": "hello world", }), } マネージメントコンソールでは、こんな感じに作成しました。 S3 Bucket でイベント通知を設定する イベント通知を設定したい S3 Bucket の Properties を開きます。 Create event notification を押します Event の名前を指定します。すべての Object を対象にしたいため、Prefix と Suffix は空白のままとします。 Event type では、作成オペレーションを対象にしたいため、All object create events を選択します。 イベント通知で連携したい Lambda Function を指定して、Save changes を押します。 設定されました ファイルを S3 Bucket にアップロード ここまでで設定が完了です。簡単ですね。実際に動作を確認するためオブジェクトをアップロードしていきましょう。Upload を押します。 適当なテキストファイルをアップロードします。 アップロードされました。 イベント通知の内容を確認するために、CloudWatch Logs を開きます。Lambda Function が受け取ったイベント通知内容が出力されています。 Logs の内容です。(一部マスクしています) eventName : このイベント自体の種類 : ObjectCreated:Put s3.bucket.name : S3 Bucket の名前 : s3-presigned-test01 s3.object.key : アップロードした Object の名前 : test-event-notification-from-console.txt [INFO] 2022-02-23T13:13:22.083Z ad5795d8-a492-4809-b8ab-d4837de63f44 { "Records": [ { "eventVersion": "2.1", "eventSource": "aws:s3", "awsRegion": "ap-northeast-1", "eventTime": "2022-02-23T13:13:20.928Z", "eventName": "ObjectCreated:Put", "userIdentity": { "principalId": "AWS:xxxxxx:your iam user name" }, "requestParameters": { "sourceIPAddress": "your ip address" }, "responseElements": { "x-amz-request-id": "PSHDB7WAZT59P5K5", "x-amz-id-2": "qVe+UDQA0JKcXCvXEk6k5j9zOOAS3q6ffxzYIYyIljQA6KI+NET9czpVYiiJnLNVXGwURnk6UbZ81N/yY34wY+KfyVZ5VCFc" }, "s3": { "s3SchemaVersion": "1.0", "configurationId": "event-to-lambda", "bucket": { "name": "s3-presigned-test01", "ownerIdentity": { "principalId": "A3A42BDEZS91PL" }, "arn": "arn:aws:s3:::s3-presigned-test01" }, "object": { "key": "test-event-notification-from-console.txt", "size": 39, "eTag": "a71911a8b3b67fd336db01eabecf7935", "sequencer": "00621632F0E0615D2C" } } } ] } 付録 フォルダー配下にオブジェクトを作成したときのイベント "key": "folder01/test-event-notification-from-console.txt",　と Folder も含めてイベントに記録されている。 [INFO] 2022-02-23T13:16:27.775Z 40bfe1aa-29d8-4039-b47e-98e78ebe6d63 { "Records": [ { "eventVersion": "2.1", "eventSource": "aws:s3", "awsRegion": "ap-northeast-1", "eventTime": "2022-02-23T13:16:26.863Z", "eventName": "ObjectCreated:Put", "userIdentity": { "principalId": "AWS:xxxxxx:your iam user name" }, "requestParameters": { "sourceIPAddress": "your ip address" }, "responseElements": { "x-amz-request-id": "SQSRN1B6C5HDMJP8", "x-amz-id-2": "d8LH2y3HOivUZgHZBesPdsW2sQnac49CLjSzn1RyyYeaXz7SSrld4/RPCwAS857/1loOt7r/kB1jvqqnnRIGfNLZ5Fx/elOY" }, "s3": { "s3SchemaVersion": "1.0", "configurationId": "event-to-lambda", "bucket": { "name": "s3-presigned-test01", "ownerIdentity": { "principalId": "A3A42BDEZS91PL" }, "arn": "arn:aws:s3:::s3-presigned-test01" }, "object": { "key": "folder01/test-event-notification-from-console.txt", "size": 39, "eTag": "a71911a8b3b67fd336db01eabecf7935", "sequencer": "00621633AAD00B2072" } } } ] } 署名付き URL でアップロードしたときのイベント オブジェクトの通常のアップロードも、署名付き URL を使ったアップロードも、イベントでは区別できない。同じイベントの "eventName": "ObjectCreated:Put", となっている。 [INFO] 2022-02-23T13:25:07.925Z 69018da5-7284-42fe-9d60-7495c68242e0 { "Records": [ { "eventVersion": "2.1", "eventSource": "aws:s3", "awsRegion": "ap-northeast-1", "eventTime": "2022-02-23T13:25:06.954Z", "eventName": "ObjectCreated:Put", "userIdentity": { "principalId": "AWS:xxxxxx" }, "requestParameters": { "sourceIPAddress": "10.0.0.163" }, "responseElements": { "x-amz-request-id": "PD5BG90V0D18B365", "x-amz-id-2": "CXzFTYn0AYA3Irxf5rj6ena66EQZl0BCscKof8rGQXnr1jUkIaxXk+RUcMkpFMMs9CjoLDKRcvuHOMlpk9WyregLg4QhMYyG" }, "s3": { "s3SchemaVersion": "1.0", "configurationId": "event-to-lambda", "bucket": { "name": "s3-presigned-test01", "ownerIdentity": { "principalId": "A3A42BDEZS91PL" }, "arn": "arn:aws:s3:::s3-presigned-test01" }, "object": { "key": "this-is-filename.txt", "size": 42, "eTag": "bc1c394a26bb03e0d360ff78daafd221", "sequencer": "00621635B2E75499C7" } } } ] }

問題 Reactのページ遷移で404になる。 対応方法 S3単体でできます。 amazon s3から → {バケット名} 　→「プロパティ」 　　→「静的ウェブサイトホスティング」(ページの下の方) 　　　→「編集」 　　　　→「静的ウェブサイトホスティング」に"index.html"を記載 その他 apacheなどでも同じ問題が発生しますが、以下で表示されるようになります。 sudo vi /etc/httpd/conf.d/httpd.conf #ErrorDocument 404 /missing.html ErrorDocument 404 /index.html apache再起動する 以上

できたこと EC2にS3権限のあるIAMロールを付与すると、aws configureを設定しなくても、EC2からAWS CLIでS3にアクセスできるようになりました。 AWS CLIではEC2インスタンスでaws configureが行われていない場合に、EC2のIAMロールを利用してくれるそうです。 参考url AWS CLIでのEC2のIAMロールの利用 勘違いしていたこと EC2からS3にアクセスする際に、S3権限をもったIAMユーザーの認証と、EC2へのS3権限のIAMロールの両方が必要だと思っていた。 EC2へのS3権限のロールがあれば、AWS CLI・AWS SDK等からS3にアクセスできる。

この記事について AWS認定のSAP（ソリューションアーキテクト-プロフェッショナル）に合格したので、そこに至るまでの対策等を紹介していきます。 前提 AWS認定で、既に所持している資格 CLF SAA SOA DAV SOAとSAAは取得後、2年経過してるので、記憶が薄いです。 実務では、CFを使った環境構築、サーバーレスのWebアプリの環境構築を主としています。 受験までの流れ 2021/09: CLF, DAV取得。流れでSAPも勉強開始 2021/11 ~ 2021/12: 問題集を解いていると眠くなる病にかかり、勉強やめる 2022/01: SAPの試験予約 & 勉強再開 2022/02: 受験 実質的な勉強してた期間は1.5ヶ月ほどです。 試験対策 1. SAP試験対策本 唯一の対策本で、問題も良いと感じました。 特に模擬問題は本番と同じく７５問あるので、どれくらい時間がかかるのかといった所の把握にも繋がりました。 模擬問題より前の章は2021/10中に一周しました。その後、サボってたので若干頭から抜けてました… 模擬問題は2回行いました。周回で２時間はかかるので集中できる環境をきちんと作った方が良いです。 1周目: 受験2週間前くらいに環境を整えて実施。正答率が6割程度。 2周目: 受験4日前に実施。正答率が8割程度。 ２． AWS問題集 ちょっとお値段は張りますが、回答の説明についても丁寧に記述されており、かなり有用でした。 AWS WEB問題集で学習しよう 金銭的に厳しいといったことがあれば、Udemy等にある英語版の問題集を翻訳するのも良いと思います。 こちらは、１日５本ペースで解いてました。 3. 認定公式ページのサンプル問題 下のほうにある「試験の復習」にサンプル問題があります。試験ガイド等もあるのでぜひ読んでおきましょう。 AWS Certified Solutions Architect - Professional 4. 模擬試験 昔は有料でしたが、今は無料で受けられるので敷居が下がりました。 １回受けてみて、8割程度の正当でした。 スキルビルダー 5. Blackbelt 問題集等を解いていて、わからないなというサービスを中心に読んでいくことで理解が深められます。 AWS サービス別資料 私の場合はネットワーク周りのサービスへの理解が不足していたので、そのあたりを重点的に読み漁りました。 試験当日 模擬問題で2時間程度かかったので、本番は丸々時間を使い切るだろうと予測をしています。 直近の模擬試験が8割だったので、受かる自信はあまりなかったです。 試験を迎える直前 しっかりと睡眠・食事を取っておく 体が資本の試験なので… 飲み物は試験数時間前から控える 試験が始まると、トイレにいけないので集中力を維持するためにも重要 栄養ドリンクを直前に飲んでおく 試験のときはいつも飲んでますが、今回はお高いのにしました 試験中 用意されている耳栓を使う できるだけ集中したい 見直しフラグはどんどんつける わからない所・ちょっと不安なところは後で見直せるように 1時間に1回程度は、足を動かしたり伸びをしたりする 長丁場なので集中力が落ちてくる 体も痛くなる 問題１周に２時間半ほど使ったので、見直しに使える時間は３０分ほど。 見直しのペース配分を間違えて、終盤の問題は時間が足りずに見直しできませんでした… わからない問題が５問程度、ふんわりとした問題が１０問程度という感覚だったのですが、どうにか受かっててよかったです。 さいごに 勉強期間について 長文が並んでいるせいか勉強中は眠気との戦いで、ペースよく勉強できているのかわからず焦りました。 blackbeltを読んでサービスの仕様を理解するのは大事だと思いました。 試験について 試験中は座ったまま3時間というのは、体的にしんどかったです… 環境の違いか、栄養ドリンクのおかげかわからないですが、集中は出来たかなと思います。 集中しないと時間内に解ききれないなんて事もありそうなので、テストセンターで受るほうが良いと思います。 それでも、ペース配分はしっかり考えておくほうが焦らなくて良いかなと思いました。 AWS認定の中ではしんどいと思われる試験に受かったので、かなりスッキリです。

はじめに Lightsailを使ってWordPressを立ち上げ、静的IP、DNSの設定をしました。 ……が、SSL化をしていなかった。。。 ということで、今回の記事ではLightsailを使って立ち上げたWordPressをSSL化していきます。 Bitnami HTTPS Configuration Tool このツールでできることは以下になります。 Let’s Encrypt での証明書の取得 HttpからHttpsへのリダイレクト non-wwwからwwwドメインへのリダイレクト cron での自動更新の設定 とっても便利そうですね…！今回はこのツールを使っていきます。 Lightsail の WordPress をSSL化 インスタンスに入ります。 以下コマンドを実行します。 アップデートするか聞かれる場合があります。 聞かれた場合は、 "Y" を入力、実行し、再度以下のコマンドを実行します。 sudo /opt/bitnami/bncert-tool あとは確認項目に従って、内容を入力実行 or Y/nを入力実行していくだけです。 確認項目は以下です。 Domain listにドメインを入力 www.付きのドメインが含まれていないので対象に含めるかどうか HTTPからHTTPSへのリダイレクトを有効にするかどうか wwwなしのドメインからwwwありのドメインにリダイレクトするかどうか wwwありのドメインからwwwなしのドメインにリダイレクトするかどうか 設定内容が正しいかどうか 証明書に関連付けるメールアドレスを入力 契約内容に問題ないがないか Enter押して完了 これでリンクにアクセスすると、さっきまではSSL化されていなかったページがSSL化されました? おわりに これでようやく記事執筆に取り掛かれそうです。

はじめに 前回の記事では、署名付きURL で S3 にファイルをアップロードする方法を確認しました。今回の記事では、ダウンロードする方法を確認しましょう。 AWS マネージメントコンソール 前回アップロードしたファイルを選択して、Share with a presigned URL を選択します。 有効期限を指定して、Create presigned URL を押します。 マネージメントコンソールの画面上部に、通知が表示されます。Copy presigned URL を押します。 こんな感じの 署名付き URL が生成されました。(この URL は既に有効期限切れでアクセスできません) https://s3-presigned-test01.s3.ap-northeast-1.amazonaws.com/this-is-filename.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=xxxxxx%2F20220223%2Fap-northeast-1%2Fs3%2Faws4_request&X-Amz-Date=20220223T105747Z&X-Amz-Expires=1&X-Amz-SignedHeaders=host&X-Amz-Signature=0813f0e5753f557a121acc3184533545cdc12fce2f7007865d8c9dbe1bfbc6a5 ブラウザからアクセスしてみると、通常通りダウンロードできました ファイルも見ています AWS CLI AWS CLI で aws s3 presign コマンドで、ダウンロード用署名付き URL を生成できます。 aws s3 presign s3://s3-presigned-test01/this-is-filename.txt --expires-in 60 実行例 (既に有効期限切れでアクセスできません) https://s3-presigned-test01.s3.ap-northeast-1.amazonaws.com/this-is-filename.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=xxxxxx%2F20220223%2Fap-northeast-1%2Fs3%2Faws4_request&X-Amz-Date=20220223T105747Z&X-Amz-Expires=1&X-Amz-SignedHeaders=host&X-Amz-Signature=0813f0e5753f557a121acc3184533545cdc12fce2f7007865d8c9dbe1bfbc6a5 こちらも同様に、ブラウザからアクセスしてみると、通常通りダウンロードできました ファイルも見ています 有効期限切れの場合 このようにエラーになります

はじめに Lightsail を使ってWordPressを立ち上げる方法についてはこちらの記事でまとめています。 今回は、上の記事で立ち上げたインスタンスに静的IPとDNSの設定をしていきます。 インスタンスに静的IPを設定 Lightsailのコンソールから "Manage" を選択します。 ネットワークタブを開き、赤枠の "Create Static IP" を選択します。 静的IPをアタッチするインスタンスを選択し、静的IPのリソース名を設定します。 Createを押下すると、設定された静的IPと、そのIPが設定されたインスタンスが表示されます。 これで、インスタンスに静的IPを設定することができました！ インスタンスを再起動しても、IPが変わることはありません。 DNSを設定 ドメインの取得 今回は お名前.com でドメイン取得を行います。 取得したいドメインを入力し、検索します。 取得するドメインにチェックを入れます。 今回はLightsailを使って構築するので、 "サーバーは利用しない" を選択します。 内容に問題がなければ、右上の "料金選択へ進む" を押下します。 取得しようとしたドメインがすでに存在していました。。。1時間ほど悩みました 登録情報を入力し、ドメインを購入します。 （何度もレンタルサーバーを勧められますが、今回はLightsailを使って構築するので、利用しない、を選びます） ドメインが発行されると、ドメインの詳細情報が見れるようになります。 DNSの設定 Lightsailのコンソールに戻り、 "Networking" タブを開きます。 "Create DNS Zone" を選択します。 お名前.comで取得したドメインを入力したら、 "Create DNS Zone" を押下します。 DNS recordsにある "Add record" を押下します。 "A record" を選択し、ドメインの前に "@" を入力します。 "Resolves to" の下には、先ほど作成した静的IPのリソース名を選択します。 そうしたら、右上の緑のチェックをクリックします。 その下に "Name servers" としてネームサーバーが表示されます。 （私の場合は4つ表示されました） これをこの後使うので、メモしておきましょう。 今度はお名前.comに戻ります。 ドメイン詳細のネームサーバー設定を開きます。 ドメインを選択し、ネームサーバーの選択でその他のサービスを押下します。 そこで、先ほどメモしたネームサーバーを入力します。 これでDNSの設定は終わりです。 設定したドメインからWordPressのブログページが表示されることが確認できるかと思います? おわりに これでLightsailからWordPressの立ち上げ〜静的IPの設定〜DNSの設定までが終わりました。 あとはWordPressからの管理画面から記事を投稿するだけですね！ ……と思ったのですが、SSL化されてなかったです。 次の記事では、SSL化していこうと思います。

はじめに 先日、EC2にEFSをマウントしようとした際にマウントが失敗し、少しハマったことがあったので、記録です。 事象 以下に発生した事象を示します。 ハマる前までに行った内容 まず前提として、EFSをアタッチするEC2インスタンスを作成。 設定項目 設定値 リージョン 東京 VPC 10.0.0.0/21（名前：MyVPC1） AZ ap-northeast-1a サブネット 10.0.0.0/24（名前：PublicSubnet1） インスタンスタイプ t2.micro セキュリティグループ 全てのSSH接続を許可（名前：EC2-SG） 　　　　　 その後、EFSのコンソールから、[ファイルシステム]>[ファイルシステムの作成]をクリック。 そしてEC2インスタンスと同じVPCを指定してEFSを作成。 EFSが作成されたことを確認した後、EC2にログインしてEFSクライアントのインストールを実施。 $sudo yum install -y amazon-efs-utils 次にEFSをマウントするディレクトリを用意。 $mkdir efs-test ここまでがマウント前までに行った内容になります。 ハマった内容 作成したEFSのファイルシステムIDを指定して、mountコマンドを実行。 しかし待てども待てどもマウントされず・・・。 $sudo mount -t efs -o tls fs-07d78a63cf0e92891:/ efs/efs-test 暫くすると結局エラーが返ってきてしまいました。どうやらファイルシステムIDが取得できていない様子。 b'mount.nfs4: mount system call failed' 原因 原因はEFSのマウントターゲットにアタッチされているセキュリティグループにありました。 EFSのマウントターゲットとは、下記図の赤枠の部分のことです。 EFSのコンソールから、[ファイルシステム]>[作成したファイルシステム名]>[ネットワーク]>[管理]をクリックして確認してみると、マウントターゲットにVPCのデフォルトセキュリティグループがアタッチされています。 そしてデフォルトセキュリティグループのインバウンドルールを確認してみると、ソースに自身のセキュリティグループが指定されています。 つまり、同じデフォルトセキュリティグループをアタッチしたEC2からはインバウンド通信を行うことが出来ますが、今回EC2にはEC2-SGという別のセキュリティグループを設定しているため、マウントターゲットと通信が行えず、マウントに失敗するわけです。 対処法 デフォルトセキュリティグループの代わりに、マウントターゲットにアタッチするEFS用のセキュリティグループを新規で作成します。 EC2のコンソールから、[セキュリティグループ]>[セキュリティグループを作成]をクリックし、セキュリティグループ名、説明、VPCを入力します。 タイプにNFS、ソースにEC2のセキュリティグループを指定したインバウンドルールを追加し、画面下の[セキュリティグループを作成]をクリックします。 これにより、EFS用のセキュリティグループの作成は完了です。 次にEFSのコンソールから、[ファイルシステム]>[作成したファイルシステム名]>[ネットワーク]>[管理]をクリックし、現在設定されているマウントターゲットを削除します。 そしてマウントターゲットを新たに追加し、先ほど作成したEFS用のセキュリティグループを指定して保存をクリックします。 これでマウントターゲットの設定は完了です。 もう一度EC2にログインし、マウントを実行してみます。 $sudo mount -t efs -o tls fs-07d78a63cf0e92891:/ efs/efs-test 今度はエラーもなく、成功した様子。 dfコマンドで確認してみると、ちゃんとマウントされていました！ $df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 475M 0 475M 0% /dev tmpfs 483M 0 483M 0% /dev/shm tmpfs 483M 460K 483M 1% /run tmpfs 483M 0 483M 0% /sys/fs/cgroup /dev/xvda1 8.0G 1.6G 6.4G 20% / tmpfs 97M 0 97M 0% /run/user/1000 127.0.0.1:/ 8.0E 0 8.0E 0% /home/ec2-user/efs-test 最後に EFSのマウントって簡単にできると思ってましたが、マウントターゲットとか、デフォルトセキュリティグループとか、ちゃんと理解していないとダメですね。 あらためて実際に手を動かすのって大事だなあと感じました。 この記事が誰かの助けとなれば幸いです。

はじめに AWS Certified SysOps Administrator - Associateの試験ラボを乗り切るために、勉強していることをなんとなくメモっていきます。 基本的にハンズオンの内容は説明せずに出てきた単語を少し深掘りしていきます。 行うこと https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-hands-on/ Network編#1 AWS上にセキュアなプライベートネットワーク空間を作成する 本人情報 IT現場雑用員（SEで採用されながら一生Excel触ってる人） 半年前にAWS SAA取得済み AWS上にプライベートネットワーク空間を作成する。 VPCとは クラウド上にネットワークを構築し、既存のネットワークの延長として利用することができます。 セキュアなネットワーク環境として提供され、用途に応じてVPN、Direct Connectを用いてオンプレミスのデータセンターと接続したり、internet gatewayを用いてインターネットに接続できたりもします。 また、1つのVPC内でサブネットを分割し直接インターネットに接続されている環境とそうでは無い環境を分離することによって（パブリック、プライベート）よりセキュアな環境を保つことができます。 この辺りはSAAの勉強をしているときに再三出てきたかなぁと思います。 （動画内の画像はめっちゃわかりやすいです） AWS上にプライベートネットワーク空間を作成する-2 VPC内のサブネット VPC内で設定したネットワークアドレスの中で、さらに細かい範囲でネットワークアドレスを指定することによってネットワーク空間を分割することができます。VPCで指定できるサブネットの範囲は16〜24であり、AZを跨いで指定することはできません。 IPアドレスのサブネットマスクで指定された値まではネットワーク部になるので、10.0.0.0/16であれば10.0.1.0/24、10.0.2.0/24といった形で分割していけるということですね。詳しくはこちらをご覧ください。 https://www.cman.jp/network/term/subnet/ internet gateway インターネットと接続するための出入り口になる場所です。internet gatewayはVPCにアタッチされ、デフォルトゲートウェイ（0.0.0.0)の宛先がinternet gatewayとなったルートテーブルが関連付けられているサブネットはパブリックサブネット、そうでないものはプライベートサブネットになります。 ルートテーブルはサブネットごとに設定するため、1つのVPC内でインターネットに接続されているサブネット、されていないサブネットを分離することができます。 AWS上にプライベートネットワーク空間を作成する-2 ルートテーブル VPCと同時に自動的に作成されたルートテーブルは、明示的に関連付けを行なっていないサブネットに対して自動で紐付きます。メインという項目を変更することによって自動的に紐づくルートテーブルを変更することができます。 VPC内でパブリックサブネットを作成する場合は、デフォルトゲートウェイを含んだルートテーブルを新たに作成しサブネットに紐づける必要があります。 1つのルートテーブルを複数のサブネットに関連づけることはできますが、逆はできません。 プライベートサブネットからインターネットへのアクセス方法 NAT NATとはIPアドレスを変換するための仕組みです。ローカルネットワークからインターネットにパケットを送信する場合は送信元IPアドレスを変換し、パケットが返ってくる際にNATゲートウェイにたどり着けるようにします。インターネットから来たパケットに関しては宛先アドレスをローカルIPアドレスに変換し、ローカルネットワーク内のホストに届けます。 NATゲートウェイ、NATインスタンス AWS上でNATを実現する際にはNATゲートウェイ、もしくはNATインスタンスを利用する必要があります。 NATインスタンスはEC２上で動作するため、監視、保守などを自分で行う必要がある反面インスタンスタイプやサイズなどパラメータを細かく設定することができます。NATゲートウェイはマネージドサービスとなっているため高可用性、冗長性が保証されています。 https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-comparison.html AWS Systems Manager AWS System ManagerとはAWSおよびオンプレミスのサーバ群を管理するためのツール群です。 リソースのグループ化、デプロイやメンテナンスの自動化、コンプライアンス違反や運用状況の調査などを行います。 https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/what-is-systems-manager.html VPC外サービスへの接続方法 VPCエンドポイント VPCエンドポイントを利用すると、VPC外に存在するS3やDynamoDB、AWS System Managerに対して接続を行う際にインターネットゲートウェイを利用する必要がなくなります。これによってサブネットはセキュアな状態を維持することができます。 VPCエンドポイントにはGatewayとinterfaceで２種類存在し、なんのサービスに接続するかでどちらを選ぶかを決定します。接続先のサービスによっては複数作成する必要があります。 https://docs.aws.amazon.com/ja_jp/ja_jp/vpc/latest/userguide/endpoint-services-overview.html interface型 AWS Systems Managerなどの（S3、DynamoDB以外）サービスに接続するために使われます。接続先のサービスによっては複数作成する必要があります。 サブネット内に作成し、そこから他のサービスとやり取りを行います。 Gateway型 S3、DynamoDBと接続するために使用されます。interface型と違ってサブネットの外、かつVPCの中に作成されるため経路をルートテーブルにエントリする必要があります。インターネットゲートウェイと同じような位置にサービスが存在することを意識すればわかりやすいかと思います。

はじめに Amazon Simple Storage Service (Amazon S3) は、高いスケーラビリティ・可用性・パフォーマンスなどを提供するオブジェクトストレージサービスです。Web サービスで画像データをアップロードしたいときに、S3 の署名付きURL を活用することが出来ます。 画像データをアップロードする際に、アプリケーションサーバーなどのバックエンドサーバーを経由する方法がありますが、CPU やネットワーク、メモリなどのリソース消費が気になります。アップロードの頻度が多く容量が大きいファイルだと、パフォーマンスへの影響が無視できません。そこで、ブラウザから直接 S3 にアップロードする方法を採用できます。 一方、セキュリティの観点で、S3 Bucket は Private にしておきたいです。Private のまま一時的にアップロードのための URL を生成する機能が、S3 署名付きURL です。 今回の記事では、ファイルをアップロードするための、S3 署名付きURL を確かめる記事になります。 S3 Bucket を作成 まず、署名付きURL を使ってアップロードするための S3 Bucket を作成します。Create Bucket を押します 適当に Bucket 名を付けます それ以外はデフォルトのまま作成をします。S3 Bucket は Private Bucket で作成しています。 Create を押します S3 Bucket が作成されました Pythonで署名付きURLを生成 次に、ファイルをアップロードするための、署名つきURLを生成します。AWS SDK を使って生成していきます。(AWS CLI では、アップロード用の署名付きURLは生成できません) Python プログラムを作成するための、作業用ディレクトリを作ります。 mkdir ~/python/s3-create-presign-upload Python ファイルを作成します touch ~/python/s3-create-presign-upload/s3-create-presign-upload.py 動作確認用ソースコードです。エラーハンドリングはしていないので、本番環境では気を付けましょう。 Params に、アップロード先のバケット名と、オブジェクト名を入れて、署名付きURL を生成している Bucket を作成した直後だと、次の URL にあるとおりエラーになる可能性がある。そのため、署名付きURL の s3.amazonaws.com を s3.ap-northeast-1.amazonaws.com に置換している https://aws.amazon.com/jp/premiumsupport/knowledge-center/s3-http-307-response/ import boto3 s3_client = boto3.client('s3', region_name='ap-northeast-1') url = s3_client.generate_presigned_url( ClientMethod='put_object', Params={'Bucket': 's3-presigned-test01', 'Key': 'this-is-filename.txt'}, ExpiresIn=3600) url = url.replace('s3.amazonaws.com', 's3.ap-northeast-1.amazonaws.com') print(url) Python プログラムの実行例です。S3 の URL に、Accesskey や署名や、有効期限がパラメータとして付与されています。 > python s3-create-presign-upload.py https://s3-presigned-test01.s3.ap-northeast-1.amazonaws.com/this-is-filename.txt?AWSAccessKeyId=xxxxxxxxxxxxx&Signature=yyyyyyyyyyy&Expires=1645609221 curl でテキストファイルをアップロード それでは、curl コマンドで実際にアップロードをしていきましょう。 適当なテキストファイルを生成します echo "Hi! I am Test File with S3 Presigned URL!" > test.txt curl でアップロードします url=$(python s3-create-presign-upload.py) curl -X PUT \ --upload-file test.txt \ $url S3 Bucket にアップロードされています。Download をして、中身を確認してみましょう 正常にアップロードされています！ 検証を通じてわかったこと 生成方法の違いについて S3 事前署名付き URL は、オブジェクトのダウンロード用とアップロード用の2種類がある ダウンロード用は、マネージメントコンソール・AWS CLI・AWS SDK から生成が可能 一方、アップロード用は、AWS SDK のみ生成が可能 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/PresignedUrlUploadObject.html アップロード用署名付き URL は、アップロード先のオブジェクト名を指定可能 アップロード元のファイル名は、アップロード先のオブジェクト名にならない オブジェクト名は、署名付きURLを生成する側でコントロール出来るため、便利に活用できる 参考URL

はじめに EBSボリュームは新規作成または空である場合初回からパフォーマンスが最大化されているがスナップショットから復元したボリュームはS3からデータがプルダウン されてボリュームに対する書き込み処理が発生するため、初回アクセス時にはフルパフォーマンスで利用できないという問題がある。 ではどうすればいいのかというと、以下の2パターンの解決方法が存在する。 Amazon EBS ボリュームの初期化 Amazon EBS 高速スナップショット復元 (FSR) Amazon EBS ボリュームの初期化 ボリュームの初期化とはスナップショットから復元したボリュームの全てブロックに対して読み取りを行う事である。 ddまたはfioコマンドを利用してブロックの読み取り処理を行う。 やり方は以下のリンクを参照。 Linux Windows Amazon EBS 高速スナップショット復元 (FSR) FSRを利用するとスナップショットから復元したボリュームは完全に初期化された状態で提供される。 FSRを利用するには各スナップショットに対してFSRを明示的に有効化する必要がある。 FSRの有効化はAWSマネジメントコンソール、CLI、APIから可能。 Linux Windows 料金 最低1時間単位で課金される https://aws.amazon.com/jp/ebs/pricing/ 所感 利用料がそれなりにかかるのでコスト削減の為にも、使い道をよく検討する必要がある。 キャッシュやDBなどのデータ領域で復元直後から高いI/Oパフォーマンスが即座に求められる場合は利用する価値がそれなりにあると思う。 また、スナップショットを世代管理しているワークロードなどでは、例えば直近1世代分は有効化し、他の世代に関しては無効化しておくなどの工夫も必要。

はじめに 前回の記事では、ECR に Push したコンテナイメージを App Runner にデプロイする方法を紹介しました。 デフォルトでは、App Runner は次の ドメイン名が自動的に割り当てられています。 https://xxxxxxxxx.ap-northeast-1.awsapprunner.com/ 自分たちのサービスを稼働させたい場合は、これを任意のドメイン名で提供したいはずです。今回は、カスタムドメインを使って、任意のドメイン名に変更する方法を確かめていきます。 Custom Domain の設定 前回の記事で作成した App Runner Service を使っていきます。Service の詳細画面を開き、Custom Domain の設定ページで Lind Domain を押します。 任意のドメイン名を指定します。今回は、Route 53 で管理している以下のドメインを、アクセス用として指定します。 apprunner.sugiaws.tokyo 次の画面が開き、ドメイン証明のための DNS レコードが表示されます。これを Route 53 などのドメイン管理サービスで入力をすることで、このドメインを所有していることを証明できます。 記事の環境では、Route 53 で管理しており、以下のように指定された 3 つの CNAME レコードを追加しました。 一定時間後、App Runner の Custom Domain の Status が Active に変わります。 アクセス確認 ここまで設定できれば、カスタムドメインが利用できるようになっています。実際に、Custom Domain で指定した名前でアクセスをしてみましょう。 正常に App Runner のアプリケーションにアクセスすることが出来ました。

本日AWS SAA(C02)を受験して結果画面に合格と表示されたので、 記憶が新しいうちに合格体験記を残します。 合格体験記はありふれているかもしれませんが、これからの受験者へ少しでもご参考になれば幸いです。 ※ 点数等は別途追記予定。 前提知識 モバイルエンジニア4年目。普段はAWSを(ほぼ)触りません。 2021年9月にAWS CLF合格 2021年9月以降はAWSの勉強せず。 勉強時間 約6-70時間くらい 2022年2月1日：勉強開始 2022年2月23日：合格 平日業務後約1時間、休日10時間程で詰め込みました。 勉強のロードマップ 1. 黒本を読む CLFを合格していたものの、期間が空いて知識の抜けが多かったので総ざらいとして本書から確認。 2周ほどざっと読んで終了。 2. ひたすら問題を解く 2-1 Udemyの以下講座を1~6までとりあえず１周解いて、解説見て理解。 2-2 CloudTechの無料AWSSAA対策問題２００問を解いて、解説見て理解。 2-3 公式模試を解いてみる。 2-4 UdemyとCloudTechの繰り返し Udemyは1~6をだいたい9割くらい、CloudTechは200問をほぼノーミスで解けるくらいまで。 不明点などは都度調べていましたが、メインとして使用していた教材は上記２点だけでした。 受験後の感想 本番試験難しい！ と、試験開始時思いましたが、いざ解いてみると問題文が若干長かったり言い回しが今までと少し異なるだけで、この問題はどの辺がポイントなんだろう？ということを意識すれば大きく焦ることもありませんでした。 焦らず問題の本質と向き合いましょう。 役に立ったサイトまとめ サイト名、文献等 おすすめ度 概要 黒本(アソシエイト教科書) ★★★ 各サービスの概要を理解できます。これだけで試験突破は厳しいのでピンポイントに調べたい時に使用 【2022年版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） ★★★★ 　問題のボリュームが多く、定番かと思います。一度解くと65問解き終えるまで終われないのでまとまった勉強時間を取る必要があるのが少し欠点 CloudTech ★★★★ 　200問までですが、1問ごとに答えを見れるので不明点を潰しながら勉強できます。課金すれば+200問できるので、絶対に落ちたくない！不安！という方は課金もあり。 無料模擬試験 ★★★ 　解説も丁寧で良いですが20問という少なさが少し欠点。無料ですし受ける価値はあります。 AWSWeb問題集 ★★★ 　一部の問題がAWSの本番と形式が異なるので優先度を下げて非会員の無料問題だけ解きました。もっと問題を解いておきたいという方には良いかもしれません。 tips 個人的にスプレッドシートに不明点を纏めると、 前日や当日何しよう？ってなった時に不明点をざっと見直せるので良かったです。 $\tiny{(走り書きのメモなので中身は気にしないように)}$ まとめ&反省点 反省点 もっと早くテスト予約すればよかった 受験の4日前くらいに試験予約しようとしましたが、希望日がほぼ埋まってました。受けるなら早めに予約を！ 受験場所は把握しておこう(テストセンターの場合) 当日迷子になりました。 まとめ 先に試験日を決めてから勉強に取り組んでもよかったかもしれません。 この体験記がAWSSAAを勉強されている方の一助になれば幸いです。 合格に向けて頑張りましょう！

経緯 先日業務でAWSを利用することになった際、料金の試算タスクを割り振られました。 自分なりに資料作成して提出したところ作り込みが甘いと私の資料は不採用に。先輩エンジニアの手を無駄に煩わせてしまいました。 この悔しい経験をバネにするべく、前もって主要サービスの料金早見表を作ろうと考え、記事にしてみました。 あくまで備忘録ですので情報が散乱していますが、どなたかの参考になれれば幸いです。 ドル/円のレートにより価格はおおよそ、また１ヶ月を３０日として計算しています。 ・VPC AWSが提供するネットワークサービス。手軽にネットワークを構築できる。リソースの配置やセキュリティを考慮した設計が魅力。 基本的には無料で利用できるが、追加で利用する機能によっては課金される。 ここではNATゲートウェイ（プライベートサブネットに配置したインスタンスからインターネットに通信する）を利用した場合。 1時間/円 1日/円 1ヶ月/円 6円 150円 　4500円 ・IAM 無料で利用できる。 ただし他のサービスを併用して、気付かずに料金が発生する場合もある。 https://dev.classmethod.jp/articles/jawsug_bgnr-36-shikujiri-iamrole-1000/ ・EC2 VPC内部に仮想のサーバーを構築するサービス。サーバの内部でウェブサイトをホストしたり、アプリケーションを動かしたり、DBを自社で保有したりといった際に使用する。 無料利用枠が用意されており、750h/月のt2.microインスタンスを1年間無料で使用することができる。 （購入オプションとしてオンデマンドインスタンスが最も価格が高く、リザーブドインスタンスを１〜３年単位で購入してコストダウンしたり、スポットインスタンスを利用する、EC2の起動時間を限定するといった方法もある。） インスタンスストレージはEBSが自動で立ち上がるが、EC2にはインスタンスストアというストレージがデフォルトで搭載されている。（こちらはインスタンスの削除と共にデータも消えるため、データの永続保存には推奨されない。） EC2で受け取ったデータをS3に保存したり、RDSに書き込むといった手法も存在している。 オンデマンドインスタンス価格 （ストレージにはEBSを利用する前提、インスタンスストアは一旦無視） ※t2.microが一月約1000円と暗記しておくと、後々便利。 インスタンスサイズ 　 料金 月額 t2.nano 0.8円 /1 時間 550円 t2.micro 1.5円 /1 時間 1100円 t2.small 3円 /1 時間 2160円 t2.medium 6円 /1 時間 4320円 t2.large 12円 /1 時間 8640円 t2.xlarge 24円 /1 時間 17280円 t2.2xlarge 48円 /1 時間 34560円 m4.large 13円 /1 時間 9360円 m4.xlarge 26円 /1 時間 18720円 m4.2xlarge 52円 /1 時間 37440円 m4.4xlarge 103円 /1 時間 74160円 m4.10xlarge 260円 /1 時間 187200円 m4.16xlarge 415円 /1 時間 298800円 --- --- --- c4.large 13円 /1 時間 9360円 c4.xlarge 25円 /1 時間 18000円 c4.2xlarge 50円 /1 時間 36000円 c4.4xlarge 100円 /1 時間 72000円 c4.8xlarge 210円 /1 時間 151200円 --- --- --- p2.xlarge 160円 /1 時間 115200円 p2.8xlarge 1200円 /1 時間 864000円 p2.16xlarge 2500円 /1 時間 1800000円 p3.2xlarge 530円 /1 時間 381600円 p3.8xlarge 2100円 /1 時間 1512000円 p3.16xlarge 4200円 /1 時間 3024000円 g2.2xlarge 890円 /1 時間 640800円 g2.8xlarge 3600円 /1 時間 2592000円 g3.4xlarge 160円 /1 時間 115200円 g3.8xlarge 320円 /1 時間 230400円 g3.16xlarge 630円 /1 時間 460800円 --- --- --- x1.16xlarge 1000円 /1 時間 720000円 x1.32xlarge 2000円 /1 時間 1440000円 x1e.xlarge 120円 /1 時間 86400円 x1e.2xlarge 240円 /1 時間 172800円 x1e.4xlarge 480円 /1 時間 345600円 x1e.8xlarge 1000円 /1 時間 720000円 x1e.16xlarge 2000円 /1 時間 144000円 x1e.32xlarge 4000円 /1 時間 288000円 r4.large 16円 /1 時間 11520円 r4.xlarge 32円 /1 時間 23040円 r4.2xlarge 64円 /1 時間 46080円 r4.4xlarge 128円 /1 時間 92160円 r4.8xlarge 256円 /1 時間 184320円 r4.16xlarge 512円 /1 時間 368640円 --- --- --- i3.large 18円 /1 時間 12960円 i3.xlarge 36円 /1 時間 25920円 i3.2xlarge 73円 /1 時間 52560円 i3.4xlarge 150円 /1 時間 108000円 i3.8xlarge 300円 /1 時間 216000円 i3.16xlarge 600円 /1 時間 432000円 d2.xlarge 850円 /1 時間 612000円 d2.2xlarge 170円 /1 時間 122400円 d2.4xlarge 340円 /1 時間 244800円 d2.8xlarge 680円 /1 時間 489600円 ・CloudWatch AWSが提供する監視サービス。CPUやメモリの使用率をモニタリングしたり、異常が検知された場合にアラートを発信することができる。基本的には無料で使用できるが、一部の機能や高度な性能を求める場合、料金が発生する。 ・SNS Simple notification servicer。アプリケーションの間でメッセージをやり取りしたり、アプリケーション側で発生したイベントに対して個人にメッセージを送るサービス。 ・SQS Simple queue service。SNSと類似するAWSのメッセージサービスだが通信の方式が違う。コンテナ間の連携に利用することもある。最初の100万件まで無料。 ・Step Functions ワークフローを構築できるサービス。アプリケーションのデプロイやAWSリソースの構築、テストといった作業を自動化できる。 ・Lambda サーバーを構築することなくコードを実行できるサービス。（もちろん本当は裏でサーバーが動いているが、サーバーの管理をAWSがやってくれる。）他サービスとの連携も可能で、S3から取得した画像データにモザイク処理を施す。EC2から取得した顧客データにマスキング処理をするといったことが可能。 ・System manager 旧SSM。AWSリソースとオンプレミスリソースを一元で管理できる。13の機能に関して無料で利用できる。 Explorer Explorer自体は無料。APIリクエストに関して課金。 OpsCenter OpsCenterAWSリソースに関連した運用上の問題の確認、調査、解決の一元管理ができる。料金は、その月に作成した OpsItem の数と、リクエストされたAPIコール(Get、Describe、Update、GetOpsSummary) の数に基づいて課金。 Incident Manager Incident Managerはサービス運用上顧客にトラブルが発生した際の対応を自動で提供する。100件までのSMS通知もしくは音声メッセージが無料。 AppConfig AWS場での機能の変更、検証、デプロイ、およびモニタリングできる。CloudWatchアラームと連携して設定のロールバックが可能。設定変更のエラーを軽減し、デプロイにかかる手間を軽減できる。 API コールを介した設定リクエスト 設定リクエストあたり 0.0000002 USD 受信した設定 受信した構成あたり 0.0008 USD Parameter Store スタンダードパラメータとアドバンスドパラメータで構成されている。スタンダードパラメータは無料。アドバンスドパラメータを作成すると、毎月、保存されたアドバンスドパラメータの数と、API インタラクションに応じて課金。 スタンダード 追加料金なし アドバンスド 1 か月ごとにアドバンスドパラメータ当たり約5円 Change Manager オペレーターとエンジニアがインフラストラクチャと構成における運用上の変更をリクエストできる。作成された各変更リクエストは、その変更テンプレートに基づいて事前定義された承認ワークフローを使用。 ３０日間の無料トライアル。トライアル期間中の平均使用率を見て料金を決定する。 料金 詳細 料金 変更リクエスト件数 変更リクエストごとに 0.296 USD API リクエスト (Get、Describe、Update、GetOpsSummary) リクエスト 1,000 件あたり 0.039 USD オートメーション AWS リソース全体における一般的な反復 IT オペレーションや管理タスクを安全に自動化できます。実際に使用した分に対してのみ料金が発生。 ステップカウント 100,000 ステップの無料利用枠。無料利用枠を超えると、基本ステップは 1 ステップあたり 0.002 USD が課金される。 プレイブックアタッチメント オートメーションプレイブックに添付ファイルをアップロードすると、添付ファイルのサイズ、保存期間に応じて課金されます。任意の複数アカウントまたはリージョンデータ転送に応じても課金されます。 料金 プレイブック 料金 ストレージ 1 か月あたり 0.046 USD/GB データ転送 (クロスアカウントまたはリージョン外) 転送されたデータ 1 GB あたり 0.900 USD データ転送 標準の AWS データ転送料金で課金。 Application Manager 追加料金なし。制限が適用される場合あり。 メンテナンスウィンドウ 追加料金なし。制限が適用される場合あり。 コンプライアンス 追加料金なし。制限が適用される場合あり。 インベントリ 追加料金なし。制限が適用される場合あり。 オンプレミスインスタンス管理 １０００まで無料。それ以上は従量課金。 料金 オンプレミスインスタンスティア 料金 スタンダード 追加料金なし アカウントごとにリージョンあたり最大 1,000 までの制限 アドバンスド アドバンスドオンプレミスインスタンスごとに時間あたり 0.00695 USD Session Manager Amazon EC2 インスタンスへのアクセスは、追加料金なしで。制限が適用される場合あり。 実行コマンド 追加料金なし。制限が適用される場合あり。 ステートマネージャー 追加料金なし。制限が適用される場合あり。 パッチマネージャー Amazon EC2 インスタンスまたはオンプレミスインスタンスでサポートされるオペレーティングシステムのパッチングや、Linux アプリケーションのパッチングは、追加料金なし。制限が適用される場合あり。 Amazon EC2 インスタンスでの Microsoft アプリケーションのパッチングは、追加料金なし。 Generate Report オプションを使用すると、オートメーションドキュメントが実行され、Systems Manager のオートメーション機能の料金に基づいて課金。 ディストリビューター Systems Manager に搭載されているディストリビューターは、ソフトウェアエージェントなどのソフトウェアパッケージを安全に配信し、インスタンスで維持する。たとえば、AWS のサービスエージェント、サードパーティー所有、または Systems Manager にインポートされた独自のエージェントがあります。AWS エージェントおよびサードパーティー所有エージェントのディストリビューションおよび更新チェックには、追加料金なし。 料金 サードパーティー所有パッケージ 無料 非 AWS パッケージ 料金 ストレージ 1 か月あたり 0.046 USD/GB Get または Describe API コール Get または Describe API コール 1,000 回あたり 0.025 USD データ転送 (リージョン外またはオンプレミスの転送のみ) ディストリビューターから転送されたデータ 1 GB あたり 0.900 USD 別料金 アプリケーションのワークフローで他の AWS サービスを使用している場合、またはデータを転送している場合は、別料金が請求される場合もある。たとえば、アプリケーションワークフローで AWS Lambda 関数を呼び出す場合は、その AWS Lambda 料金に基づき、AWS Lambda の利用料が課金。 ・Route53 Resolver オンプレミスからVPC内の名前解決を可能にするサービス｡一つのエンドポイントに対して13円/時間課金される。 １ヶ月では約18000円。 ・VPC endpoint AWS内のリソースをインターネットを経由せずに利用する際に使うサービス。 各 AZ の VPC エンドポイント 1 つあたりの料金 (円/時間) 1.5円/時間、１ヶ月約1100円。

はじめに lambda や API の実態と認証のロジックを切り離したい。 そしたらもっとシンプルにバックエンド開発ができる。 API はすべて API Gateway を通る構成なので、API Gateway をリバースプロキシのように扱い、そこでアクセス制御をしたい。 結論 IAM ロールに紐付けている　IAM ポリシーで各エンドポイントへのアクセス許可を制御したかっのですが、今回の方法では要件をクリアできませんでした。 今回の方法は Cognito オーソライザー に設定しているユーザープールへの認証が通れば、IDプールのロール設定に関係なくすべてのAPIが実行できてしまいます。 AWS に慣れている人からしたら当たり前の事かもしれないですね（ そもそもリクエスト時にIDプール指定してないですね…? ） IAM ポリシーで制御するためには 一時的な認証情報を使用してリクエストヘッダに署名をする必要があり、それを行うと要件を満たすことができました。 準備 1. オーソライザーの作成 API Gateway のメニューからオーソライザーを新規に作成します。 名前 （今回は cognito-auth にしました） タイプ 「Cognito」 ユーザープールを選択 トークンの格納フィールドを 「Authorization」 とする 2. アクセス制御の設定 アクセス制御を設定したいメソッドに対して先程作成した 「cognito-auth」 を指定します。 デプロイ後、トークンが付与されていないリクエストは受け付けません。 $ curl https://38npzjahsi.execute-api.ap-northeast-1.amazonaws.com/prod/cognito {"message":"Unauthorized"} 実装 import axios from "axios"; import CognitoIdp from "aws-sdk/clients/cognitoidentityserviceprovider"; const COGNITO_API_VERSION = "2016-04-18"; const REGION = "ap-northeast-1"; const COGNITO_USER_POOL_ID = "ユーザープールID"; const COGNITO_CLIENT_ID = "アプリクライアントID"; const USERNAME = "ユーザー名"; const PASSWORD = "パスワード"; const IAM_ACCESS_KEY_ID = "クレデンシャルのためのアクセスキー（マシンで設定済みのものを使用する場合は不要）"; const IAM_SECRET_ACCESS_KEY_ID = "クレデンシャルのためのシークレットキー（マシンで設定済みのものを使用する場合は不要）"; export const cognitoIdpClient = new CognitoIdp({ apiVersion: COGNITO_API_VERSION, region: REGION, credentials: { // adminInitiateAuth と adminRespondToAuthChallenge の実行権限を持っているクレデンシャルを使う accessKeyId: IAM_ACCESS_KEY_ID, secretAccessKey: IAM_SECRET_ACCESS_KEY_ID, }, }); // IDトークンを取得 async function getIdToken() { const getIdTokenCore = async () => { const params: CognitoIdp.AdminInitiateAuthRequest = { UserPoolId: COGNITO_USER_POOL_ID, ClientId: COGNITO_CLIENT_ID, AuthFlow: "ADMIN_USER_PASSWORD_AUTH", AuthParameters: { USERNAME: USERNAME, PASSWORD: PASSWORD, }, }; const response = await cognitoIdpClient.adminInitiateAuth(params).promise(); return response; }; let response = await getIdTokenCore(); // 初めてのログインの場合 if (response.ChallengeName === "NEW_PASSWORD_REQUIRED") { const params: CognitoIdp.AdminRespondToAuthChallengeRequest = { ChallengeName: "NEW_PASSWORD_REQUIRED", UserPoolId: COGNITO_USER_POOL_ID, ClientId: COGNITO_CLIENT_ID, ChallengeResponses: { USERNAME: USERNAME, NEW_PASSWORD: PASSWORD, }, Session: response.Session, }; // パスワードの再設定が面倒なので同じパスワードで状態を「CONFIRMED」に更新 await cognitoIdpClient.adminRespondToAuthChallenge(params).promise(); // 更新後 IDトークンを再取得 response = await getIdTokenCore(); } return response.AuthenticationResult?.IdToken!; } async function main() { const idToken = await getIdToken(); const resp = await axios.get( `https://xxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/cognito`, { headers: { Authorization: idToken, // ここ }, } ); console.dir(resp.data); } main(); まとめ ユーザープールだけで制御したいという場合は有効な手段だと思います ?

PynamoDBとFastAPIを用いて簡単なCRUD APIを作成したのでメモとして残しておく。 PynamoDB DynamoDB用Pythonインターフェイス DynamoDB APIを抽象化しており、比較的簡単にDynamoDB操作ができる。 事前準備 こちらの手順で動作確認用のDynamoDBコンテナを起動する。 テーブル名などはtest_userとして修正する。 依存ライブラリインストール pynamodb fastapi uvicorn コード app.py from pynamodb.models import Model from pynamodb.attributes import UnicodeAttribute,NumberAttribute from fastapi import FastAPI, HTTPException from fastapi.responses import JSONResponse from fastapi.responses import PlainTextResponse from starlette.exceptions import HTTPException as StarletteHTTPException from pydantic import BaseModel from typing import Optional import uuid import logging # PynamoDB用データモデル class UserModel(Model): # 接続先情報(クレデンシャルやテーブル情報)を定義 class Meta: host = "http://localhost:8000" aws_access_key_id = 'dummy' aws_secret_access_key = 'dummy' region = 'ap-northeast-1' table_name = "test_user" # テーブル属性定義 id = UnicodeAttribute(hash_key=True) email = UnicodeAttribute(null=True) # FastAPIリクエストボディ用データモデル class User(BaseModel): id: Optional[str] = None email: str app = FastAPI() # ユーザー登録API @app.post("/users") def regist_user(user: User): # ユーザーID生成 user_id = str(uuid.uuid4()).replace("-","") regist_user = UserModel(user_id) regist_user.email = user.email # ユーザー登録 regist_user.save() user.id = user_id return user # ユーザー取得API @app.get("/users/{user_id}") def get_user(user_id: str): try: # ユーザー取得 user = UserModel.get(user_id) logging.info(user) return user.attribute_values except UserModel.DoesNotExist: logging.error("User does not exist.") raise HTTPException(status_code=404, detail="user_not_found") # ユーザー更新API @app.put("/users/{user_id}") def update_user(user_id:str, user: User): try: # 更新対象ユーザー取得 target_user = UserModel.get(user_id) # ユーザー更新 target_user.update(actions=[ UserModel.email.set(user.email) ]) return target_user.attribute_values except UserModel.DoesNotExist: logging.error("User does not exist.") raise HTTPException(status_code=404, detail="user_not_found") # ユーザー削除API @app.delete("/users/{user_id}") def update_user(user_id:str): try: # 削除対象ユーザー取得 target_user = UserModel.get(user_id) # ユーザー削除 target_user.delete() return {} except UserModel.DoesNotExist: logging.error("User does not exist.") raise HTTPException(status_code=404, detail="user_not_found") 動作確認 API起動 uvicorn app:app --reload --port 5000 ユーザー登録API リクエスト POST /users HTTP/1.1 Host: 127.0.0.1:5000 Content-Type: application/json Content-Length: 37 { "email":"test0@example.com" } レスポンス { "id": "87527962cbd14293943d323548f403da", "email": "test0@example.com" } ユーザー取得API リクエスト GET /users/87527962cbd14293943d323548f403da HTTP/1.1 Host: 127.0.0.1:5000 レスポンス { "email": "test0@example.com", "id": "87527962cbd14293943d323548f403da" } ユーザー更新API リクエスト PUT /users/87527962cbd14293943d323548f403da HTTP/1.1 Host: 127.0.0.1:5000 Content-Type: application/json Content-Length: 44 { "email":"test0_update@example.com" } レスポンス { "email": "test0_update@example.com", "id": "87527962cbd14293943d323548f403da" } ユーザー削除API リクエスト DELETE /users/87527962cbd14293943d323548f403da HTTP/1.1 Host: 127.0.0.1:5000 レスポンス {} 参考情報 PynamoDB

いつも忘れるのでメモ aws-cliのインストール（バージョン2系） ▼公式を参考 macOS コマンドラインを使用してすべてのユーザーを対象にインストールおよび更新する https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-mac.html#cliv2-mac-install-cmd-all-users curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg" sudo installer -pkg AWSCLIV2.pkg -target / # aws-cliがインストールされた場所 which aws > /usr/local/bin/aws # インストールしたaws-cliを確認 aws --version > aws-cli/2.4.18 Python/3.8.8 Darwin/20.6.0 exe/x86_64 prompt/off # 不要なパッケージ削除 rm AWSCLIV2.pkg aws-cli バージョン1系も使いたい場合 ▼公式を参考 バンドルされたインストーラを使用した macOS での AWS CLI バージョン 1 のインストール、更新、アンインストール https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-macos.html#install-macosos-bundled which aws > /usr/local/bin/aws # version2を退避 mv /usr/local/bin/aws /usr/local/bin/aws2 # version1をインストール curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip" unzip awscli-bundle.zip sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws # 場合によってはこんな感じのエラーが出る > Unsupported Python version detected: Python 2.7 > To continue using this installer you must use Python 3.6 or later. > For more information see the following blog post: https://aws.amazon.com/blogs/developer/announcing-end-of-support-for-python-2-7-in-aws-sdk-for-python-and-aws-cli-v1/ # エラーが出た場合は使用するpythonのバージョンを指定する sudo /usr/bin/python3 awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws ## バージョン1がインストールされたか確認 aws --version > aws-cli/1.22.60 Python/3.8.9 Darwin/21.3.0 botocore/1.24.5 # 不要なパッケージ削除 rm -rf awscli-bundle.zip rm -rf awscli-bundle # アンインストールする場合はrm rm -rf /usr/local/bin/aws awsのconfig設定 # プロファイル作成 aws configure --profile dev-user > AWS Access Key ID [None]: XXXXXXXXXXXXXXXX > AWS Secret Access Key [None]: XXXXXXXXXXXXXXXX > Default region name [None]: ap-northeast-1 > Default output format [None]: json # プロファイル確認 cat ~/.aws/config cat ~/.aws/credentials # aws-cliを使う際はuserを設定 export AWS_PROFILE=dev-user

問題 問1. CodeBuildにおいてビルドプロジェクトは[A]を、buildspec.ymlファイルは[B]の設定を行う。以下からそれぞれに当てはまるものを選択せよ。 a. 実行環境の準備 b. 実行コマンド c. デプロイ先の指定 d. ソースコードの作成 問2. CodeDeployの中で登場する「リビジョン」とはCodebuildが出力した[A]である。答えよ。 問3. CodeDeployの使用に必要な作業は、デプロイ先の対象インスタンスへ[A]をインストールすることと、[B]ファイルを作成することである。答えよ。 問4. 通常CodeBuildの主力アーティファクトはCodeBuildのコンソールにて[A]を、buildspec.ymlにて[B]を定義する。答えよ。 問5. CodePipelineにより、CodeDeployの[A]を設定する必要がない。答えよ。 解答 問1. [A]実行環境の準備,[B]実行コマンド 問2. [A]出力アーティファクト(一旦S3などに保存される) 問3. [A]CodeDeployエージェント,[B]appspec.yml(対象インスタンスへのデプロイ方法が記述される) 問4. [A]出力パスやファイル形式,[B]アーティファクト名 問5, [A]リビジョン

はじめに AWSのコンピューティングサービスであるEC2インスタンスの大半は拡張ネットワーキングがサポートされている。拡張ネットワーキングとは簡単に言えば有効化するだけでインスタンスのネットワークパフォーマンスが向上する機能である。利用にあたり追加料金がかからないのもメリットの一つ。本記事では拡張ネットワーキングに関してまとめておく。 拡張ネットワーキングとは何か？ SR-IOVによってネットワークのパフォーマンスを向上させる技術 AWSドキュメントより 拡張ネットワーキングでは、シングルルート I/O 仮想化 (SR-IOV) を使用して、サポートされるインスタンスタイプにおける高性能ネットワーキング機能が提供されます。 SR-IOV は、従来の仮想化ネットワークインターフェイスと比較し、I/O パフォーマンスが高く、CPU 利用率が低いデバイス仮想化の手法です。 拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。 利用するための条件は？ 現行のインスタンスタイプであれば利用可能 Linux https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instance-types.html#current-gen-instances Windows https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/instance-types.html#current-gen-instances 拡張ネットワーキングのタイプ 拡張ネットワーキングはインスタンスタイプによって以下のいずれかのインターフェイスをサポートしている Elastic Network Adapter (ENA) 最大100Gbpsのネットワーク速度をサポート Intel 82599 Virtual Function (VF) インターフェイス 最大10Gbps のネットワーク速度をサポート インスタンスタイプ別にサポートされているインターフェイスに関しては以下URLにある表の拡張ネットワーキング列を参照 Linux https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instance-types.html#instance-type-summary-table Windows https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/instance-types.html#instance-type-summary-table 有効化のやり方 基本的にはサポート対象のディストリビューションのAMIでインスタンスを起動すると自動的に有効化されている。なのでインスタンスを起動した後に有効化されているか確認することが重要。 Linux: Elastic Network Adapter (ENA) https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/enhanced-networking-ena.html Linux: Intel 82599 Virtual Function (VF) インターフェイス https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/sriov-networking.html Windows: Elastic Network Adapter (ENA) https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/enhanced-networking-ena.html Windows: Intel 82599 Virtual Function (VF) インターフェイス https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/sriov-networking.html

2022年1月30日にAWS認定ソリューションアーキテクトアソシエイトに合格した経験から、資格取得に向けて必要な出題分野の説明とキーワードを開設したいと思います。 試験概要 概要 詳細 問題数 65問 傾斜配点がある。試験問題開発のため、点数が付かない問題が含まれている場合がある。 出題形式 選択式 4択または5択以上で指定された個数の正解を選択。 制限時間 130分 途中退出不可。試験会場によっては、別途前後5分にアンケートなどがある。 合格点 720/1000 100点は必ずもらえる。採点方法は非公開。 試験の出題分野とキーワード まずは試験の出題分野についてです。ソリューションアーキテクトの試験ではシステムのアーキテクチャについて以下の4テーマで出題されます。 ※2022/1/30現在 参考 | AWS Certified Solutions Architect – Associate (SAA-C02) 試験ガイド 各分野の概要とキーワードを確認しましょう。 弾力性に優れたアーキテクチャの設計 まず理解したいのは弾力性です。簡単に説明すると、どんな状況でも想定通りに動くアーキテクチャです。突然のアクセス集中にも対処できるようにスケーリングできたり、サーバで障害が起きてもすぐに復旧できるようなアーキテクチャが弾力性に優れていると言えるでしょう。 それを踏まえて、この分野のキーワードは以下です。 キーワード スケーリング フォールトトレラントアーキテクチャ 高可用性 災害対策 デカップリング サーバーレステクノロジー 重要なキーワード紹介 スケーリング AWSにはスケーリングの設定ができるリソースがたくさんあります。 また、CloudWatchと連携して、CPUやメモリが設定した条件に当てはまった場合にスケーリングするなどの自動スケーリングもあります。 分野にある弾力性はスケーリングがカギであるため、試験でも頻出です。 練習問題でも問題としてよく出題され、試験でも出たのはRDSについてです。 RDSにも自動スケーリングがあります。しかし、自動スケーリングでスケーリングできるのは ストレージ(容量) のみです。CPU・メモリ・ネットワークキャパシティーでスケーリングはできませんので、引っかけ問題に気をつけましょう。 フォールトトレラントアーキテクチャ フォールトトレラントアーキテクチャ(Fault Tolerant Architecture)とは システムの Fault=障害 に対して Tolerant=耐性 のあるシステムの Architecture=構造 のことです。 試験では、障害に対する耐性を高めるために同じ機能を持つサーバを複数用意して、Elastic Load Balancingで負荷分散する例が良く出題されます。 また別の例では、アベイラビリティゾーンの障害に耐えられるように、ストレージをマルチAZ構成にする問題も多いです。ストレージではS3やRDSが頻出です。 高性能アーキテクチャの設計 大規模なシステムで直面するパフォーマンス問題を解決するアーキテクチャについてです。 1から構築する際に将来を見据えて拡張性の高いアーキテクチャについてや、既存のアーキテクチャで抱えているパフォーマンス問題に対して最適な解決策を求められます。 キーワード 伸縮自在/スケーラブル モニタリング ハイパフォーマンス エッジキャッシュ戦略 データ転送サービス 重要なキーワード紹介 エッジキャッシュ戦略 AWSにはリージョンという概念があり、それぞれのリージョンは完全に分離された状態でデータセンターが存在しています。また、リージョンは更にいくつかのアベイラビリティゾーンとして分割されたいます。同一リージョン内のアベイラビリティゾーンは相互に接続されています。 通常はリージョンを選択し、複数のアベイラビリティゾーンを使用して可用性・耐障害性を確保しながらシステムを構築します。 それに加えて、コンテンツの配信で高いパフォーマンスが求められるシステムのために、 CloudFront というサービスが用意されています。 CloudFront を使うと、リージョンとは別に用意されたエッジロケーションを使用して、低レイテンシーかつ高速な転送速度でコンテンツの配信が可能です。 CloudFront は、エッジロケーションにキャッシュを行う条件を設定することでパフォーマンスを向上させることができます。このキャッシュを行う条件が エッジキャッシュ戦略 です。 データ転送サービス 大規模なシステムをAWSに移行するというテーマの問題は頻出です。その中で問われる問題の1つにオンプレミスのデータをAWSに移行する最適な方法についてがあります。 AWSには様々な データ移行サービス が存在します。大きく分けると、3種類あります。 方法 内容 ハイブリッドクラウドストレージ オンプレミスとAWSのクラウドを繋いでデータを管理する オンラインデータ転送 オンラインでデータを転送する オフラインデータ転送 オフラインでデータを転送する それぞれの方法に数種類のサービスがあります。コスト・期間・セキュリティなどの要件から、適切なデータ移行サービスを選択できるようにしましょう。 セキュアなアプリケーションとアーキテクチャの設計 セキュリティはクラウドサービスを使用するうえで特に意識すべきことです。AWSでセキュリティを向上させるためのアーキテクチャの構築やセキュリティのために用意されたサービスの適切な活用方法を理解しているかが問われます。 後述するキーワードからわかる通りセキュリティ特有の用語がいろいろあるので、セキュリティについて疎い場合は言葉を理解することから始めるのがおすすめです。 キーワード トレーサビリティ トラフィック制御 ネットワークセグメンテーション (ネットワーク)ルーティングメカニズム (外部の脅威からの)アプリケーション保護 データセキュリティオプション 重要なキーワード紹介 トラフィック制御 AWS上のネットワークはVPCという仮想ネットワークを使用します。さらにVPCのIPアドレスの範囲を指定することでサブネットを作成することができます。 VPCやサブネットのトラフィックを適切に制御することで、不要な外部通信を遮断して必要な通信のみにすることができ、セキュリティを向上させることができます。 VPC内のリソース 単位でトラフィックを制御する場合は セキュリティグループ を使用します。セキュリティグループはインバウンドとアウトバウンドに対して 許可ルールのみ 指定できます。 セキュリティグループは ステートフル なので、インバウンド通信に対する応答やアウトバウンド通信に対するレスポンスは設定されたルールに関わらず通過します。 サブネット 単位でトラフィックを制御する場合は ネットワークACL を使用します。 ネットワークACLはインバウンドとアウトバウンドに対して 許可ルールと拒否ルール の両方を指定できます。 ネットワークACLは ステートレス なので、インバウンド通信に対する応答はアウトバウンドルールが適用され、アウトバウンド通信に対するレスポンスはインバウンドルールが適用されます。 トラフィック制御の方法として セキュリティグループ と ネットワークACL を理解して、それぞれの特徴と活用場面を判断できるようにしましょう。 データセキュリティオプション AWSにデータを保管するときやオンプレミスからAWSにデータを転送するときのセキュリティ対策は重要です。 そのようなデータ管理に対するセキュリティ要件を満たす方法がいくつかあります。 ここでは試験で頻出のS3を例に説明します。 データが管理されているS3バケット全体やその中のオブジェクトへの アクセスの制御 をすることでセキュリティを高めることが出来ます。その場合は アクセスポリシー を使用します。 アクセスポリシーには リソースベースのポリシー・ユーザーポリシー・ACLベースのポリシー など特徴の違う様々な種類があるので、要件に応じて適切なポリシー設定を選択できるようにしましょう。 また、S3のデータ(オブジェクト)の 暗号化 をすることでもセキュリティを高めることができます。 方法は大きく分けて2つあります。 1つは、 サーバー側で暗号化 を実施する方法で SSE(Server Side Encryption) といいます。 もう1つは、 クライアント側で暗号化 してからS3に保存する方法で CSE(Client Side Encryption) といいます。SSEは3種類、CSEは2種類あります。これらの違いを理解して、要件にあったオプションを選択できるようにしましょう。 参考 | S3データ格納時のサーバ側暗号化（SSE-S3、SSE-KMS、SSE-C）と、クライアント側暗号化（CSE-KMS、CSE-C） コストを最適化したアーキテクチャの設計 キーワード Amazon EC2 請求オプション ストレージ階層 データ転送コスト 重要なキーワード紹介 Amazon EC2 請求オプション AWSのEC2は、もっとも一般的に使われている仮想マシンの一つです。 CPUやストレージなどEC2には様々なオプションがありますが、コスト最適化の観点では購入オプションの選択が問われます。デフォルトでは オンデマンドインスタンス を購入して、利用時間に応じて秒単位での支払いを行います。 使用方法によってはオンデマンドインスタンスよりもコストを削減できる購入方法が用意されています。 例えば、数年間にわたって24時間使用することが前提の場合、リザーブドインスタンス を購入することで割引きが適用されます。 また、使用する頻度や時間がある程度予測できる場合、 Savings Plans で予め利用料を宣言することで割引が適用されます。これは、リザーブドインスタンスなどと併用できます。 要件に対して最もコストが最適化されるオプションが何かを求められますので、それぞれのオプションの特徴を覚えておきましょう。 紹介した以外にも、支払方法を含めた様々なオプションが用意されていますので、詳しくは以下を参考にしてください。 参考 | インスタンス購入オプション データ転送コスト AWS内のデータ転送コストを削減する方法として覚えておきたいのは、VPC内からS3へのデータ転送 です。 例えば、あるVPC内にEC2があるとします。そのEC2からS3にデータ転送する場合、S3はVPCのネットワーク内にないので、通常は外部通信となります。その場合は、一般的な外部通信の利用料金がかかります。 一方で、S3に対する VPCエンドポイント の一つである ゲートウェイエンドポイント を作成して ゲートウェイエンドポイント経由でデータ転送 を行えば、データ転送コストはかかりません。 この例はS3を DynamoDB に置き換えても成り立ちます。 試験としてのウェイトは軽いので上記の例を覚えておけば対策としては十分だと思いますが、AWSを理解する観点ではその他のアーキテクチャのデータ転送コストについて学ぶのも良いと思います。 さいごに SAAの勉強と試験から考えたキーワードから、分野ごとのポイントをまとめてみました。 資格取得までに何をしたかなどは合格体験記に書いていますので、そちらもご確認していただけると嬉しいです。

1. 前書き 1.1. CDKとは何か？ AWS Cloud Development Kit (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースを定義するためのオープンソースのソフトウェア開発フレームワークです。 https://aws.amazon.com/jp/cdk/ 使い慣れたプログラミング言語、ツール、ワークフローの使用 AWS CDK を使用すると、TypeScript、Python、Java、.NET、および Go (開発者プレビュー) を使用してアプリケーションインフラストラクチャをモデル化できます。CDK では、開発者は既存の IDE、テストツール、およびワークフローパターンを使用できます。自動入力ドキュメントやインラインドキュメントなどのツールを活用することで、AWS CDK では、サービスドキュメントとコードの切り替えにかかる時間を短縮できます。 https://aws.amazon.com/jp/cdk/features/ 1.2. この記事の目的 この記事の目的は、AWS CDKでECS/FargateとRDSの環境を作成する手順を個人的なメモとして記すことです。 1.3. 試したかったこと 実は今回はCDKを試したのは、二次的な要素でした。 　 コンテナ構築の効率化とセキュリティー向上をテーマに「CloudNative Buildpacks」と「コンテナイメージのスキャン」を試そうとしていました。 そのための検証環境が必要だったため、CDKで作るのが効率が良さそうと考えて、CDKも試してみたという背景があります。 今回は、以下リソースをCDKで作成することを意図しました。 VPC関連のリソース（VPC, Subnet, Gateway） RDS ECS/Fargate関連のリソース（Cluster, Service, TaskDefinition） ApplicationLoadBalancer また、関連して、以下のリソースも作成します。 IAM Poclicy SecretsManager SecurityGroup 1.4. 構成図（概略） 概略とはいえ、雑すぎる図になってしまいました。 1.5. 前提事項 以下のインストールについては済んでいるものとします。 CDK typescript CDK 2.12.0 typescript 3.9.7 VSCode 1.64.2 macOS Monterey 12.1 2. CDKでリソースを作ってみる 2.1. CDK利用の戦略 CDKには、大きく分けると、 L2 Library(AWS Construct Library) L1 Library(AWS CloudFormation Resource) の２つがあります。 L2は、高水準な仕様となっており、最低限のパラメーターで、いい感じに直接指定のないリソースも自動生成するようになっています。（その分細かい調整が難しいです）。 一方のL1は、生のCloudFormationを書くのとほぼ同等のパラメーター設定が必要で、細かい調整が可能ですが、記述が冗長になります。 状況にもよりますが、CDKのメリットを最大限享受するならば、なるべくL2を使うのが良いと思います。 今回は、L2を利用して必要な部分を都度オプションパラメーターで調整しています。 2.2. 実装を見てみる 以下が第一弾のソースコードです。基本的には最小限の定義にしており、関連するリソースは自動生成に委ねています。 　 ただし、このコードだとうまく生成されないリソースがあります。 test_cdk-stack.ts import { Duration, Stack, StackProps } from "aws-cdk-lib"; import * as ec2 from "aws-cdk-lib/aws-ec2"; import * as ecs from "aws-cdk-lib/aws-ecs"; import * as ecsPatterns from "aws-cdk-lib/aws-ecs-patterns"; import { Construct } from "constructs"; import { DatabaseCluster, DatabaseClusterEngine, } from "aws-cdk-lib/aws-rds"; export class TestCdkStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // VPC関連のリソース作成 const vpc: ec2.Vpc = new ec2.Vpc(this, "AbeTestVpc", { cidr: "10.x.0.0/16", subnetConfiguration: [ // Optional（省略すると、PUBLICとPRIVATE_WITH_NATのみ生成される） { cidrMask: 24, name: "ingress", subnetType: ec2.SubnetType.PUBLIC, }, { cidrMask: 24, name: "application", subnetType: ec2.SubnetType.PRIVATE_WITH_NAT, }, { cidrMask: 28, name: "rds", subnetType: ec2.SubnetType.PRIVATE_ISOLATED, }, ], }); // Security Group(自動生成に任せる) // RDS(最低限の設定としてある) const rdsCluster = new DatabaseCluster(this, "AbeTestRds", { engine: DatabaseClusterEngine.AURORA_MYSQL, instanceProps: { vpc, vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED, }, instanceType: ec2.InstanceType.of( ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.SMALL ), }, defaultDatabaseName: "abeTest", }); // ECS Cluster const cluster = new ecs.Cluster(this, "AbeTestCluster", { vpc: vpc, }); // ALB, FargateService, TaskDefinition const loadBalancedFargateService = new ecsPatterns.ApplicationLoadBalancedFargateService( this, "AbeTestService", { cluster: cluster, // Required memoryLimitMiB: 512, cpu: 256, desiredCount: 1, // Optional(省略値は3) listenerPort: 80, taskImageOptions: { image: ecs.ContainerImage.fromRegistry( "my_account/spring-boot-docker" ), containerPort: 8080, }, healthCheckGracePeriod: Duration.seconds(240), } ); // HealthCheckの設定 loadBalancedFargateService.targetGroup.configureHealthCheck({ path: "/custom-health-path", healthyThresholdCount: 2, // Optional interval: Duration.seconds(15), // Optional }); } } 3. この時点での課題 RDS(DB)のSecurityGroupにInboundルールが作成されていない ECSからSecretsManagerを参照するIAMポリシーが「タスク実行ロール」にアタッチされていない ECSからSecretsManagerを参照する「環境変数」の定義がタスク定義に作成されていない 3.1. RDS(DB)のSecurityGroupにInboundルールが作成されていない 3.2. ECSからSecretsManagerを参照するIAMポリシーが「タスク実行ロール」にアタッチされていない 実は、RDSを作成した段階で自動的に、SecretsManagerはできている。 しかし、CDKでそれをどこでどう使うか？を指定していないためにアタッチがされていない。 ちなみに、ECSからのLog出力のIAMポリシーはアタッチされている。 3.3. ECSからSecretsManagerを参照する「環境変数」の定義がタスク定義に作成されていない 4. 課題の解決 課題1.の解決 現状は、CDKがSecurityGroupを自動的に生成してくれています。 例えば、RDSのセキュリティーグループについては、API仕様をみると以下のように記載されています。 　 securityGroups? Type: ISecurityGroup[] (optional, default: a new security group is created.) Security group. DatabaseClusterのコンストラクターに渡す、InstancePropsのsecurityGroupsは、省略可能で、省略した際には、新しいsecurity groupが（自動的に）作られるという記載があります。 従って、自前で、SecurityGroupを生成して、それを渡してあげれば良さそうです。 変更箇所は、以下のようになります。 + // VPC定義の後で、RDS定義より前に追加 + // RDS SecurityGroup設定 + const ecsSG = new SecurityGroup(this, "AbeTestEcsSecurityGroup", { + vpc, + }); + + const rdsSG = new SecurityGroup(this, "AbeTestRdsSecurityGroup", { + vpc, + allowAllOutbound: true, + }); + // ↓ ここがポイント + rdsSG.connections.allowFrom(ecsSG, Port.tcp(3306), "Ingress 3306 from ECS"); + // RDS const rdsCluster = new DatabaseCluster(this, "AbeTestRds", { engine: DatabaseClusterEngine.AURORA_MYSQL, instanceProps: { vpc, vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED, }, + securityGroups: [rdsSG], instanceType: ec2.InstanceType.of( ec2.InstanceType.of( ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.SMALL ), }, defaultDatabaseName: "abeTest", }); // 〜 中略 〜 // ALB, FargateService, TaskDefinition const loadBalancedFargateService = new ecsPatterns.ApplicationLoadBalancedFargateService( this, "AbeTestService", { cluster: cluster, // Required memoryLimitMiB: 512, cpu: 256, desiredCount: 1, // Optional(Default === 3 !!!) listenerPort: 80, taskImageOptions: { image: ecs.ContainerImage.fromRegistry( "akiraabe/spring-boot-docker" ), containerPort: 8080, }, + securityGroups: [ecsSG], healthCheckGracePeriod: Duration.seconds(240), } ); 課題2.の解決 今回は、「aws-cdk-lib.aws_ecs_patterns module」を用いて、ALBとECSを作成しています。 一方で、RDSは個別に定義しているので、RDSとそこから生成されるSecretsManagerがいわば蚊帳の外の状態になっています。 従って、ECSのタスク実行ロールに、自前で生成したSecretsManager読み取りポリシーをアタッチすれば良さそうです。 コードの変更箇所は以下の通りです。 + // RDS定義の後に追加 + // SecretsManager(RDSにより自動設定) + const secretsmanager = rdsCluster.secret!; + + // 最後に追加 + // Add SecretsManager IAM policy to FargateTaskExecutionRole + const escExecutionRole = Role.fromRoleArn( + this, + "ecsExecutionRole", + loadBalancedFargateService.taskDefinition.executionRole!.roleArn, + {} + ); + escExecutionRole.attachInlinePolicy(new Policy(this, 'abeTestSMGetPolicy', { + statements: [new PolicyStatement({ + actions: ['secretsmanager:GetSecretValue'], + resources: [secretsmanager.secretArn], + })], + })); 課題3.の解決 課題2と原理は一緒です。SecretsManagerの値を、タスク定義に渡してあげればうまくいきます。 // ALB, FargateService, TaskDefinition const loadBalancedFargateService = new ecsPatterns.ApplicationLoadBalancedFargateService( this, "AbeTestService", { cluster: cluster, // Required memoryLimitMiB: 512, cpu: 256, desiredCount: 1, // Optional(Default === 3 !!!) listenerPort: 80, taskImageOptions: { image: ecs.ContainerImage.fromRegistry( "akiraabe/spring-boot-docker" ), containerPort: 8080, + // Secretの設定 + secrets: { + "dbname": ecs.Secret.fromSecretsManager(secretsmanager, 'dbname'), + "username": ecs.Secret.fromSecretsManager(secretsmanager, 'username'), + "host": ecs.Secret.fromSecretsManager(secretsmanager, 'host'), + "password": ecs.Secret.fromSecretsManager(secretsmanager, 'password'), + } }, securityGroups: [ecsSG], healthCheckGracePeriod: Duration.seconds(240), } ); これにより、課題が解決され、ALB〜RDSまで一気通貫でつながります。 5. まとめ 5.1. 所感 今回は、手っ取り早くコンテナ環境とDBを作るということにフォーカスしています。 　 実験用なので、1セットのStackとしてあり、用が済んだら全てcdk destroyで消してしまうという思想です。 もう少し実用的なインフラを構築するためには、さらに、以下の課題があると思います。 Stackを分割して、毎回RDSが消えないようにするなど、リソースのライフサイクルに合わせる CodePipelineを用いて、アプリケーションのリリースの自動化にも対応する Blue/Greenデプロイなどにも対応する 5.2. CDKの展望？ AmplifyやChaliceがCDKと連携する機能をリリースしているので、今後、AWSのサービス間での連携にCDKが使われていく可能性が高いと思います。 5.3. 参考にしたサイト 以下のサイトを参考にしています。（特に、API仕様は必読です。） APIドキュメント https://docs.aws.amazon.com/cdk/api/v2/ Construct Hub https://constructs.dev/ Example https://github.com/aws-samples/aws-cdk-examples ClassmethodさんのじっせんCDK（L1の記述例として有用です） https://dev.classmethod.jp/articles/cdk-practice-1-introduction/ stackoverflow (SecurityGroupの設定の際に参考になりました) https://stackoverflow.com/questions/66979012/how-to-add-a-security-group-to-an-existing-rds-with-cdk-without-cyclic-dependenc

自己紹介 一般の大学生です。今年で20になり、運転免許取得中のペーペーです。プログラミングはpythonから始めて、インターンでjavascriptを触ったくらいです。一年半くらいの経験です。 えーだぶる...えす?? pythonでlinebotを作ろうとしたときにAWSという単語を初めて見たときはこんな反応をしました。一体何なのかと。どうやらアマゾンウェブサービスの略称らしい、広く使われてるらしい、クラウド技術バンザイ。なるほどそういう感じなのか、ちょっと深い記事読んでみようかな！と思って手を伸ばしたら... lambda..? S2...? cloud9...? 困った。何もわからない。ここはもしかしてスパイの本部で、自分にはわからない暗号を使って会話してるのだろうか？ という錯乱っぷりを見せつつ、これは体系的に学ぶしかないなと腹をくくりました。が、｢僕なんてまだプログラミングなんにもわかってないでチュ...｣と避け続けてきたので今度こそやります。 学習の方針 なーーーーーんにもわからんのでとりあえず先人が用意してくれた学習リソースを最大限に活用していこうと思います。自分なりに考えている順序はこうです。 1.AWS educateに登録する 　学生だとお安くなってるらしいじゃないですか 2.AWSの資格を色々とってみる 　とりあえず取れと先人たちが言っていたので(投げやり) このくらいしか考えられないです。なんたってなーーーーーんにもわからんのでね！ じゃ！行ってくるわ！ 頑張って勉強します。ｶﾝｾﾞﾝﾆﾘｶｲｼﾀ状態になることを一旦の目標とします！

[前回] AWS公式資料で挑むSCS認定(3)-対象サービス攻略 はじめに 今回から、サービスを一つずつ理解していきますが、 その前に、それぞれの目的や依存関係を加味し、勉強順つけようと思います。 「xxxサービスを真っ先に」名人からお勧めの一言ほしい。。。 サービスの勉強順序を決める 一旦、カテゴリ三つに分けました(あくまで個人の理解と独断です)。 サービス名は、略称または先頭の「Amazon」「AWS」を省きました。 超重要 自分の中で一番力を入れたいトップ3 IAM アクセス制御 AWSセキュリティの土台で超超超重要 VPC 仮想ネットワーク サービスはVPC上で連携しながら動く、データ通信が盗聴されたら。。。 KMS 暗号化キーの作成・制御 機密情報の暗号化に使うキーが攻撃者の手に渡ったら。。。 重要 セキュリティ対策に欠かせない、と思われるもの Cloudwatch CloudTrail システムログやイベント収集 操作履歴を記録しておかないと、セキュリティ始まりませんので 両者の違いはなんだ?(自分の宿題) WAF Network Firewall ファイアウォール 入り口でサイバー攻撃を止めてくれる優れもの Shield DDoS攻撃対策 攻撃者が複数機器を乗っ取り一斉攻撃、過剰負荷でサービス停止の恐れ ACM 証明書発行・管理 SSL/TLS証明書を簡単にプロビジョニング、管理、デプロイ Single Sign-On Cognito 認証・認可 認証が攻撃者に突破されたら、CIA(機密性・完全性・可用性)破綻の恐れ 普通 Macie GuardDuty Inspector Detective 不正アクセスの検知・監視・分析 Audit Manager Security Hub Trusted Advisor セキュリティ診断・監査 Systems Manager Firewall Manager Config Organizations 管理・設定ツール CloudHSM ハードウェアセキュリティモジュール(HSM)のストレージサービス ハードウェアレベルで、暗号化キー保管や暗号化タスクを実行 Directory Service Microsoft Active Directory (AD) を AWS の他のサービスと併用したい場合 おわりに サービスの勉強をスムーズに進めるため、優先順位付けてみました。 各々のサービスが、AWSセキュリティ4点方針「防止、検出、対応、修復」 いずれかの実現を目的としていることも、再確認できました。 次回は、IAMの勉強に入ります。お楽しみに。

[前回] AWS公式資料で挑むSCS認定(3)-対象サービス攻略 はじめに 今回から、サービスを一つずつ理解していきますが、 その前に、それぞれの目的や依存関係を加味し、勉強順つけようと思います。 「xxxサービスを真っ先に」名人からお勧めの一言ほしい。。。 サービスの勉強順序を決める 一旦、カテゴリ三つに分けました(あくまで個人の理解と独断です)。 サービス名は、略称または先頭の「Amazon」「AWS」を省きました。 超重要 自分の中で一番力を入れたいトップ3 IAM アクセス制御 AWSセキュリティの土台で超超超重要 VPC 仮想ネットワーク サービスはVPC上で連携しながら動く、データ通信が盗聴されたら。。。 KMS 暗号化キーの作成・制御 機密情報の暗号化に使うキーが攻撃者の手に渡ったら。。。 重要 セキュリティ対策に欠かせない、と思われるもの Cloudwatch CloudTrail システムログやイベント収集 操作履歴を記録しておかないと、セキュリティ始まりませんので 両者の違いはなんだ?(自分の宿題) WAF Network Firewall ファイアウォール 入り口でサイバー攻撃を止めてくれる優れもの Shield DDoS攻撃対策 攻撃者が複数機器を乗っ取り一斉攻撃、過剰負荷でサービス停止の恐れ ACM 証明書発行・管理 SSL/TLS証明書を簡単にプロビジョニング、管理、デプロイ Single Sign-On Cognito 認証・認可 認証が攻撃者に突破されたら、CIA(機密性・完全性・可用性)破綻の恐れ 普通 Macie GuardDuty Inspector Detective 不正アクセスの検知・監視・分析 Audit Manager Security Hub Trusted Advisor セキュリティ診断・監査 Systems Manager Firewall Manager Config Organizations 管理・設定ツール CloudHSM 暗号用ストレージ ハードウェアセキュリティモジュール(HSM)で暗号化キー保管や暗号化タスク実行 Directory Service Microsoft Active Directory(AD) ADをAWSの他のサービスと併用したい場合 おわりに サービスの勉強をスムーズに進めるため、優先順位付けてみました。 各々のサービスが、AWSセキュリティ4点方針「防止、検出、対応、修復」 いずれかの実現を目的としていることも、再確認できました。 次回は、IAMの勉強に入ります。お楽しみに。

はじめに バックエンドのサービス間認証は以下の IAM と API Gateway を使用したアクセス制御で良いですが、フロントエンドから APサーバー（BFF） を挟まず、直接 API Gateway にリクエストを行うサーバレスの要件が上がってきました。いいや、降りてきました。 その場合、 cognito を使用して AWS リソースへのアクセス許可を取得するのが一般的なようで、そのとき行った設定をメモしておきます。 やりたいこと フロントエンドから直接… cognito（IDプール） から未認証ユーザーのロールを付与してもらい、ゲストユーザーとして未認証ユーザー用の API が実行できる。 cognito 認証後、認証済みユーザー用の API が実行できる。 Cognito 1. ユーザープールの作成 デフォルトの設定を使用します。 2. アプリクライアントの追加 「クライアントシークレットの生成」を解除し、SRP認証を有効にします。 USER_SRP_AUTH SRP 認証に関しては以下の記事で投稿してたりします。 3. IDプールの作成 未認証のユーザーに対してもアクセス制御（許可）を行いたいので 「認証されていない ID に対してアクセスを有効にする」 をチェック。 また、認証プロバイダーに先程作成したユーザープールを設定します。 API Gateway 1. API を作成 「REST API」 を選択。 2.リソースの作成 未認証ユーザーに公開する/public 認証済みユーザーに公開する/private を同じ設定で作成します。 フロントエンドから直接リクエストするので CORS を有効にしておきます。 3. HTTPメソッドの作成 どちらもモックデータをを返すように設定しておきます。 4. モックレスポンスの設定 /public と /private どちらかを判別できるレスポンスにしておきます。 5. 動作確認 一度デプロイして動作確認をしてみます。何も設定していないのでどちらにもリクエストが通ります。 6. アクセス制御の設定 未認証ユーザーに公開する/public 認証済みユーザーに公開する/private どちらも同じく 「AWS IAM」 を設定します。 7. 動作確認 デプロイし直します。 著名が付与されていないリクエストがブロックされることが確認できます。 IAM 1. IAM ロールの確認 ID プールを作成したときに一緒に作った 「認証されていないロール」 「認証されたロール」 に対して API Gateway のアクセス許可を設定していきます。 設定されている IAM ロールは ID プールの管理画面 「ID プールの編集」 から確認できます。 2. IAM ポリシーの設定 「認証されていないロール」 は /public に 「認証されたロール」 は /public /privateの両方に対して以下のように設定していきます。 ※ インラインポリシー、ビジュアルエディタ どちらも 「認証されたロール」 に対して設定を行ったときのキャプチャです。 ビジュアルエディタから登録する場合は以下のように フロントエンド フロントエンドを作成していきます。 $ npx create-react-app aws-hello --template typescript 著名の作成 がとても面倒ですが aws-amplifyのパッケージを使用することで、その工程を意識せずに認証を行うことができます。 $ npm i aws-amplify 力尽きました。 長々と書いていて力尽きました。笑 amplify と React.js を使用した SRP 認証の実装は以下を参照していただくと… ログイン前は IDプールから未認証の IAM ロールが付与され /public のみ実行でき、 ログイン後は認証済みの IAM ロールが付与されて /public と /private どちらの URL もフロントエンドから直接リクエストできるようになります。 アドレスバーなどから /public を実行しても未認証用の IAM ロールが付与されていないため、リクエストは通りません。 そして、ログインするためのユーザーは cognito の管理画面で作っておきましょう。 まとめ AWS の認証をうまく使って、機能開発から認証を切り離して開発効率上げたいですね ?

もうHTML/CSSは書きたくない 「もうHTML/CSSは書きたくない」とちょっとタイトルで釣りましたが、最後まで読んでくれると嬉しいです！ 結論から言うと、Amplify StudioとFigmaを連携させて、Reactのコンポーネントを作成すると言う記事です。 StudioとFigmaを連携させる機能は、2021年の12月に発表されました。 最小限のプログラミングでFigmaからフルスタックのReactアプリを実現 実際に、インターンシップで触れる機会があったので、触れた感想や結果を書きたいと思います。 先に感想を Amplify StudioとFigmaを連携させる方法は、僕以外の人も書いているので、僕の感想を先に書きます。 感想だけでいいと言う方は、ここで離脱しても大丈夫です！ 僕のプロフィール エンジニアインターンとして5ヶ月経ち、インターンではReactとAWSを使って開発中。 クラウドプラクティショナー取得済み。 実際にやってみた感想 ・ Figmaを完璧に使えこなせていないと厳しい Figmaの方で雑にデザインを作っていると、いざReactでUIコンポーネントとして利用したときに、ずれが起きたり、画面サイズが変わったときにデザインが崩れたりします。また、Amplify Studioでコンポーネントとして出力させるとこうなるんだ！ということもわかっておくと、進めやすいと思います。 ・ 全部のコンポーネントを置き換える必要は特にない 一応プレビューの段階のため、できないこともあるようです。また、すでにコンポーネントがあるなら、わざわざ置き換えるメリットはないと思います。そのため、新しい比較的小さいコンポーネントを作成する際に少し使ってみるとかはありかもです。 ・ Amplify Studioの操作が難しい これについては、慣れろよとしか言いようがないのですが、DynamoDBからデータを引っ張ってこれたり、型定義ができたりします。AWSの機能は大体そうですが、慣れないと複雑だなーと感じることがあります。 先にFigmaのリンクを取得する 以下Figmaの画面の右上にある、青いShareボタンを押すと、モーダルが出てきます。 そのモーダルの左下にあるCopy Linkを押して、Figmaのリンクを取得します。 以下の画像はサンプルのため、デザインを作成していません Amplify Studioにログインする ここから先は、GraphQL APIバックエンドとReactフロントエンドを持つ、サンプルReactアプリケーションをデプロイしていることを前提に、書き進めていきます。 Amplifyがわからない方は、Amplify SNS Workshopを参考にしてください。 まずはマネジメントコンソールにログインして、Amplifyコンソールにある作成したアプリケーションを開きます。 その後、左のメニューのアプリの設定から、Amplify Studio Settings(設定)を選択します。 すると、以下の画面が出てくるので、Enable Amplify Studioをオンにして、右側にあるInvite usersを押します。 そこで、自分のメールアドレスを打ち、届いたメールに書かれているUDとパスワードで、Amplify Studioにログインします。 Amplify StudioとFigmaを連携させる ログインして、以下のような画面が開ければ、右のメニューにあるUI Libraryを押します。 その後、画面が変わり、真ん中にGet startedがあるので、押します。 すると、上で取得したリンクを記入する欄があるので、そこにペーストして、Continueを押します。 これで連携が完了です。 ReactのUIコンポーネントとして使えるようにする。 Figmaと連携して、右上のFigmaのマークの隣にあるSync with Figmaのボタンを押すと、Figmaで作成したコンポーネントが出てきます。 そこで、以下の画像の前に、RejectもしくはAcceptボタンが出てくるので、必要なコンポーネントのみAcceptします。 そうすると、以下の画像のようになります。 そして、この画像の右少し上にあるConfigureボタンを押すと、画面が少し変わり、下の方に</> Get component codeボタンが出てきます。 それを押すと、ReactのUIコンポーネントとして使えるようにする方法が出てきます。 詳しくは進めるとわかるので、ここではざっとだけ説明すると、amplify pullして、jsxファイルが作成されるため、それを別のファイルからインポートして利用します。 まとめ ここでは、最短でFigmaからReactのコンポーネントを作成する方法を書きました。 Amplify Studioには、まだまださまざまな機能が存在するため、ぜひ試してみてください。 また、もし間違えていることや追加コメントがあれば、教えてください！

はじめに lambda や API の実態と認証のロジックを切り離したい。 そしたらもっとシンプルにバックエンド開発ができる。 API はすべて API Gateway を通る構成なので、API Gateway をリバースプロキシのように扱い、そこでアクセス制御をしたい。 API Gateway で IAM アクセス制御を設定すると... AWS サービスがリクエストを受信すると、リクエストで送信した署名を計算したときと同じステップが実行されます。続いて AWS は、計算された署名とそのリクエストで送信した署名を比較します。署名が一致すると、リクエストが処理されます。署名が一致しない場合、リクエストは拒否されます。 この「署名」を作る処理がとても面倒だったので、メモを残しておきます。 準備 1. API Gateway で認可の設定を 「AWS IAM」 に設定する 2. API Gateway へのアクセス権限をもつ IAM ユーザーを用意する プログラムからアクセスするので、ユーザーは 「プログラムによるアクセス」 にチェック ポリシーの設定 著名をつけずに実行しても {"message":"Missing Authentication Token"} のように、リクエストが拒否される。 実装 最初は こちら を参考に著名を作成しようと思ったが、typescript だといまいちだったので、別の方法を模索。 どうやら AWS SDK for JavaScript の v3 だと著名作成の処理が公開されているようなので、それを使用。 以下の記事をからほぼ流用させてもらった。 実際に扱うなら、記事のコードをそのまま使用したほうが良い。（というか実践的で完成度高いです。） なかなか難しかったので自分なりに砕いたのが下記のコード。 import { SignatureV4 } from "@aws-sdk/signature-v4"; import { Sha256 } from "@aws-crypto/sha256-js"; import { HttpRequest } from "@aws-sdk/protocol-http"; import axios from "axios"; const accessKeyId = "IAMのアクセスキーID"; // process.env.IAM_ACCESS_KEY_ID! const secretAccessKey = "IAMのシークレットアクセスキー"; // process.env.IAM_SECRET_ACCESS_KEY_ID! const hostname = "xxxxxxx.execute-api.ap-northeast-1.amazonaws.com"; // 著名を作るメソッド async function signRequest( headers: Record<string, string>, method: string, path: string, body?: unknown ) { const request = new HttpRequest({ body: body ? JSON.stringify(body) : undefined, headers, hostname: hostname, method: method.toUpperCase(), path, }); const signer = new SignatureV4({ credentials: { accessKeyId, secretAccessKey, }, service: "execute-api", region: "ap-northeast-1", sha256: Sha256, }); const signedRequest = await signer.sign(request); return signedRequest; } async function main() { const headers: Record<string, string> = { host: hostname, "Content-Type": "application/json", }; const path = "/hello"; const data = { name: "tubakuro", }; // 著名（ヘッダー）を作成して const req = await signRequest(headers, "POST", path, data); // 著名と同じ内容でリクエスト const resp = await axios.post(`https://${hostname}${path}`, data, { headers: req.headers, }); console.dir(resp.data); } main(); 以下のようなリクエストが作られて、リクエストが成功したらOK POST /hello HTTP/1.1 x-amz-date: 20220222T135041Z x-amz-content-sha256: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx authorization: AWS4-HMAC-SHA256 Credential=xxx, SignedHeaders=content-type;host;x-amz-content-sha256;x-amz-date, Signature=xxx Content-Length: xx Content-Type: application/json Host: xxxxxxx.execute-api.ap-northeast-1.amazonaws.com [body] GET の場合だとこう。 axios GET時の仕様がややこい。 async function main() { const headers: Record<string, string> = { host: hostname, }; const path = "/hello"; const req = await signRequest(headers, "GET", path); const resp = await axios.get(`https://${hostname}${path}`, { headers: req.headers, }); console.dir(resp.data); } まとめ 一度作ってしまえば楽ちんですね ? AWS SDK for JavaScript v3 のリファレンス置いておきます。

はじめに lambda や API の実態と認証のロジックを切り離したい。 そしたらもっとシンプルにバックエンド開発ができる。 API はすべて API Gateway を通る構成なので、API Gateway をリバースプロキシのように扱い、そこでアクセス制御をしたい。 API Gateway で IAM アクセス制御を設定すると... AWS サービスがリクエストを受信すると、リクエストで送信した署名を計算したときと同じステップが実行されます。続いて AWS は、計算された署名とそのリクエストで送信した署名を比較します。署名が一致すると、リクエストが処理されます。署名が一致しない場合、リクエストは拒否されます。 この「署名」を作る処理がとても面倒だったので、メモを残しておきます。 準備 1. API Gateway で認可の設定を 「AWS IAM」 に設定する 2. API Gateway へのアクセス権限をもつ IAM ユーザーを用意する プログラムからアクセスするので、ユーザーは 「プログラムによるアクセス」 にチェック ポリシーの設定 著名をつけずに実行しても {"message":"Missing Authentication Token"} のように、リクエストが拒否される。 実装 最初は こちら を参考に著名を作成しようと思ったが、typescript だといまいちだったので、別の方法を模索。 どうやら AWS SDK for JavaScript の v3 だと著名作成の処理が公開されているようなので、それを使用。 以下の記事をからほぼ流用させてもらった。 実際に扱うなら、記事のコードをそのまま使用したほうが良い。（というか実践的で完成度高いです。） なかなか難しかったので自分なりに砕いたのが下記のコード。 import { SignatureV4 } from "@aws-sdk/signature-v4"; import { Sha256 } from "@aws-crypto/sha256-js"; import { HttpRequest } from "@aws-sdk/protocol-http"; import axios from "axios"; const accessKeyId = "IAMのアクセスキーID"; // process.env.IAM_ACCESS_KEY_ID! const secretAccessKey = "IAMのシークレットアクセスキー"; // process.env.IAM_SECRET_ACCESS_KEY_ID! const hostname = "xxxxxxx.execute-api.ap-northeast-1.amazonaws.com"; // 著名を作るメソッド async function signRequest( headers: Record<string, string>, method: string, path: string, body?: unknown ) { const request = new HttpRequest({ body: body ? JSON.stringify(body) : undefined, headers, hostname: hostname, method: method.toUpperCase(), path, }); const signer = new SignatureV4({ credentials: { accessKeyId, secretAccessKey, }, service: "execute-api", region: "ap-northeast-1", sha256: Sha256, }); const signedRequest = await signer.sign(request); return signedRequest; } async function main() { const headers: Record<string, string> = { host: hostname, "Content-Type": "application/json", }; const path = "/hello"; const data = { name: "tubakuro", }; // 著名（ヘッダー）を作成して const req = await signRequest(headers, "POST", path, data); // 著名と同じ内容でリクエスト const resp = await axios.post(`https://${hostname}${path}`, data, { headers: req.headers, }); console.dir(resp.data); } main(); 以下のようなリクエストが作られて、リクエストが成功したらOK POST /hello HTTP/1.1 x-amz-date: 20220222T135041Z x-amz-content-sha256: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx authorization: AWS4-HMAC-SHA256 Credential=xxx, SignedHeaders=content-type;host;x-amz-content-sha256;x-amz-date, Signature=xxx Content-Length: xx Content-Type: application/json Host: xxxxxxx.execute-api.ap-northeast-1.amazonaws.com [body] GET の場合だとこう。 axios GET時の仕様がややこい。 async function main() { const headers: Record<string, string> = { host: hostname, }; const path = "/hello"; const req = await signRequest(headers, "GET", path); const resp = await axios.get(`https://${hostname}${path}`, { headers: req.headers, }); console.dir(resp.data); } まとめ 一度作ってしまえば楽ちんですね ? AWS SDK for JavaScript v3 のリファレンス置いておきます。