- 投稿日:2022-02-25T23:02:34+09:00
Amazon CloudFront の署名付きURL(カスタムポリシー)を使って、安全にコンテンツを配信してみた
はじめに 前回の記事では、CloudFront の署名付きURL(規定ポリシー)を使って、Private の S3 Bucket に格納している画像データを、安全性を高めたアクセス方法を確認しました。 今回の記事では、より柔軟なアクセスポリシーを定義できるカスタムポリシーを利用した方法を確認していきましょう。 2種類の署名付き URL 前回の記事でも記載しましたが、今回も改めて記載します。 署名付き URL は、セキュリティに関するポリシーの違いによって、「規定ポリシー」と「カスタムポリシー」の 2 種類あります。2 つのポリシーの違いを AWS Document に書かれている表から抜粋します。規定ポリシーは、デフォルトの設定になっており、手を加えない分比較的楽に生成できます。一方、カスタムポリシーは自分たちのワークロードに合わせたカスタマイズが可能で、柔軟にコントロールができます。カスタムポリシーの方は、複数のオブジェクトのために再利用出来たり、アクセス元の IP アドレスの制限が出来るため、便利に利用できそうですね。 今回の記事では、カスタムポリシーを使った署名付き URL を生成する方法を確認していきます。 秘密鍵・公開鍵の作成 署名付き URL を生成するために、秘密鍵・公開鍵の生成が必要です。手元の Linux マシンなどで作成していきましょう。 mkdir ~/temp/cloudfront-presign/ cd ~/temp/cloudfront-presign/ 秘密鍵を生成します openssl genrsa -out private_key.pem 2048 秘密鍵から、CloudFront に登録するための公開鍵を生成します openssl rsa -pubout -in private_key.pem -out public_key.pem こんな感じに生成できました > ls -lha total 12K drwxr-xr-x 2 ec2-user docker 51 Feb 25 20:18 . drwxrwxr-x 36 ec2-user docker 4.0K Feb 25 19:12 .. -rw-r--r-- 1 ec2-user docker 1.7K Feb 25 20:18 private_key.pem -rw-r--r-- 1 ec2-user docker 451 Feb 25 20:18 public_key.pem CloudFront に公開鍵をアップロード CloudFront のページに移動して、Create public key を押します 公開鍵の中身を確認して、登録をしていきます cat public_key.pem 登録されました。 CloudFront に Key Group を作成 Key Group を作成して、アップロードした公開鍵を登録します 名前や公開鍵の名前を選択します 作成されました S3 Bucket の作成 適当な名前で Private な S3 Bucket を作成して、うちの猫の写真をアップロードします。この写真を、署名付き URL のアクセス確認に使っていきます。 CloudFront の Distribution の作成 署名付き URL を利用するために、Create distributon を押します。 Distribution の Origin として、作成した S3 Bucket を指定 OAI を利用して、S3 Bucket のアクセスを CloudFront のみに制限 Restrict viewer access を有効にして、署名付き URL が無いとアクセスできないように設定します Create Distribution を押します Deploy プロセスが走りました 署名付きURL(カスタムポリシー)の生成 カスタムポリシーを利用した署名付き URL は、AWS CLI では生成できず、何らかのプログラムで生成する必要があります。AWS Document にサンプルコードが記載されているため、これを参考にするとよいでしょう。 今回の記事では、Python を使った署名付き URL の生成を行います。ソースコードはこんな感じです。 Python の実行環境上で秘密鍵 /home/ec2-user/temp/cloudfront-presign/private_key.pem が存在している 署名付き URL の対象となるパス https://d31z1elfcc2o1s.cloudfront.net/mycat.jpg を指定 署名付き URL の有効期限を expire_date で指定 アクセス元の IP アドレスを 54.250.23.0/32 と指定 (とある EC2 インスタンスのもの) import datetime from cryptography.hazmat.backends import default_backend from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives import serialization from cryptography.hazmat.primitives.asymmetric import padding from botocore.signers import CloudFrontSigner from dateutil import tz def rsa_signer(message): with open('/home/ec2-user/temp/cloudfront-presign/private_key.pem', 'rb') as key_file: private_key = serialization.load_pem_private_key( key_file.read(), password=None, backend=default_backend() ) return private_key.sign(message, padding.PKCS1v15(), hashes.SHA1()) key_id = 'K1DYHGI8XWLXZL' url = 'https://d31z1elfcc2o1s.cloudfront.net/mycat.jpg' expire_date = datetime.datetime( 2022, 2, 25, 22, 10, 0, 0, tz.gettz('Asia/Tokyo')) cloudfront_signer = CloudFrontSigner(key_id, rsa_signer) # Create a signed url that will be valid until the specific expiry date # provided using a canned policy. policy = cloudfront_signer.build_policy( url, expire_date, date_greater_than=None, ip_address='54.250.23.0/32') signed_url = cloudfront_signer.generate_presigned_url( url, date_less_than=None, policy=policy) print(signed_url) この Python コードを実行すると、署名付き URL を生成できます > python cloudfront-create-presign.py https://d31z1elfcc2o1s.cloudfront.net/mycat.jpg?Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9kMzF6MWVsZmNjMm8xcy5jbG91ZGZyb250Lm5ldC9teWNhdC5qcGciLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE2NDU4ODEwMDB9LCJJcEFkZHJlc3MiOnsiQVdTOlNvdXJjZUlwIjoiMC4wLjAuMC8wIn19fV19&Signature=RmBo1DqAyEMSQWvMgubzHs2zufS03rceMEIvv8JHkQaMyQDtuu3aLTDSyQ9eO4Oyp~lkB2QrC-KM8v21eo9i0IRWFsbY5IreNpOqo5sLc8RWL9LpKWo6~EM1ykD29SCp8fObkLBe9ed85lNLqml2kDztHCV7ebYvU7fBUGHLnsQ4n4NZjRpipDfZdMJbhjx0DWfpp5VmaKIGh0XwZxMeNbR8vMIUEKn1DHLcyLLywkzyFZaI146NvekpDgS-VqMmxBIRVOjxhXc3p8JvPoTdAEYW3Dxp7Cit~Xd1xNoO9cn6GiFQUDn9uWD1fETSzASilj8NbpIzpJXU6S1n0I57XQ__&Key-Pair-Id=K1DYHGI8XWLXZL アクセス確認 まず、通常通りに CloudFront 経由でアクセスを試みると、想定通りにエラーになります。 次に、署名付き URL で、許可された IP アドレスからアクセスすると、正常に家猫の画像が出ます。かわいい。 署名付き URL の 有効期限が切れたときの結果です。想定通りエラーになります。 IP アドレスを制限するための WAF 署名付きURLのカスタムポリシーでは、アクセス元の IP アドレスが指定可能ですが、1個までという制限があります。Web アプリケーションとして認証を加えたうえで、アクセス元のクライアント IP を取得し生成することで、URL が仮に漏れたとしてもアクセスを防ぐ構成も可能です。 上記とは別の方法で、WAF を利用した 複数の IP アドレス制限を加えることも可能です。WAF の構成もしてみましょう。Create IP set を押します。 アクセスを許可する IP アドレスを複数入力します。 IP set が作成されました。 WAF の Web ACL を作成します。 適当に名前を入れて、CloudFront に紐づけます。 Add my own rules and rule groups を選択します。 作成した IP set を選択して、Allow を選びます ルールに合致しないものは Block とすることで、指定された IP アドレス以外を防ぎます Next Next Create を押します WAF の Web ACL が作成されました アクセス確認 WAF でブロックしている IP アドレスから、署名付き URL にアクセスしてみると、想定通りアクセスができません。WAF としてのエラーとなっており、カスタムポリシーとは異なったエラーが表示されます。 検証を通じてわかったこと カスタムポリシーでは、アクセス元の IP アドレスを指定可能 ただし、カスタムポリシー上では 1 個のみ指定可能 IP アドレスを複数利用して制限したい場合は、WAF を利用した IP アドレス制限が検討可能 参考URL AWS Document : 署名付き URL の使用 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html Python のサンプルコード https://github.com/boto/boto3/blob/develop/boto3/examples/cloudfront.rst
- 投稿日:2022-02-25T22:31:35+09:00
AWS SAAに一回落ちたヤツが語る合格への道
筆者について WEB系は3年目くらいのエンジニア。バックエンド担当。 AWSは仕事上触るが、既に組み上がったものを設定を変更するくらいだった。 受験しようと思った理由 触っていたAWS環境に納得いかない設定や構成があった。 でも何も知らないヤツに改善はできない、だから勉強しようと考えた。 1回目の受験編 ■勉強期間 平日2時間、土日3時間くらいを3週間続けた。 ネットの合格体験記を見ると大体そんなところが多いように思ったからだ。 ■学習方法 まずは、いわゆるオレンジ本 をメルカリで買って試験概要とサービスの概要を知ることにした。 つぎは、ネット無料問題サイト 問題をもっと解かないと受からんだろと思い、無料で200問くらいできるサイトで満点になるまで何周も繰り返した。 正解が多くなるにつれて自信がついてきた。 最後に、Udemy 有名だと思うが、これ一本でOKのやつをハンズオン編は気になるところだけ視聴し、あとは模擬試験を満点になるまで繰り返した。 この時は「この模擬試験は難易度が高いな...こんなの出るのか?」と思っていた。 (これは2回目の試験時にも使っていたので買ってよかったと思う) いざ受験 この時はもう結構自信がついていて、ほぼ受かるだろうと思っていた。 なにせあれだけ問題を繰り返してサービス内容を頭に叩き込んだのだから。 結果 680点で落ちました。(合格ラインは720点以上) 問題が本やネットで見た試験内容よりもかなり難しかった... 本やネットの問題よりも深くサービスの設定方法を聞かれたり、最新のサービスについての問題も出て完全に見たことない単語がかなり出ました。 2回目の受験編 敗因と対策を考えた 敗因 ■サービスについて隅々まで知らなかったこと 「サービスを知ってる = 細かい設定から最新の情報まで知っている」という事なのだ。 例えば、EC2のスポットインスタンスは途中でターミネートされるサービスと思っていたが、スポットフリートを使えばキャパシティを維持できるといったまで知っている必要がある。 ■「ソリューションアーキテクトだったらどう考えるべきか」が抜けていた そもそも「課題に対してどうすれば解決できるか」をベースに考えなければいけないのだ。 試験問題と捉えるのではなく、Well-Architectedの考えを持って、どのようにすれば課題解決できるかで考えるべきだった。 対策 できるだけ難しい問題を解きまくる 本屋やUdemyで売ってる問題集をできるだけ解きまくって、あらゆる角度からサービスについての知識を深めまくった。 ■ おすすめ問題集 細かい問題や最新の問題も出てるし、解説も詳しい。 ・【2022年版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問) ・AWS認定ソリューションアーキテクト-アソシエイト問題集 メモする 自分の場合は、notionに各サービスのことを自分の言葉でまとめてました。 「このサービスは例えばこんな時に使うやつ」みたいな感じで、自分が考えた言葉や例えでノートにまとめてました。 合格して振り返ってみるとこれが結構当たりだったと思います。 結果 もう3週間勉強して、見事合格することができました。 2週間で再度受験できるのですが、考えを改めてゆっくり定着させてから受験しました。 まとめ 受かりましたが、試験中は合格できるか結構不安な感じでした。 どれだけ勉強していても、答えが全くわからない問題は少なくともありました。 やはり継続して勉強していくことが大事だと思います。 ただ実際詳しく勉強したことで、実務でもコスト削減したりできたので、当初の目的は達成できたと思います。 余談 ■ ネットの無料問題はオススメしない 模擬問題などをやっていて個人的に重要だなと思ったのは、問題の解説が信頼できるかだと思います。 ネットの無料のやつをやっていて、解説に納得行かないのがあったりして、「これ正解も合ってんのかな...?」と疑心暗鬼になる。 上記のおすすめは、問題出してる人が元AWSの人だったり、それと同等に詳しい人だったりするので、解説も信用しやすかった。 ※ネット無料問題のやつが悪いわけではない。勉強し始めはいいかもしれないが、これに時間を割くのは勿体ない気がする。
- 投稿日:2022-02-25T22:27:53+09:00
AWSのS3で画像が保存できない
簡易的なフリマアプリを作成中。 AWSのS3に画像を保存するための実装を実施。 必要なファイルや記述なども終え、まずローカル環境で画像がS3に保存できるかの挙動確認を行う。 が、エラー発生。 エラー文は以下の通り。 NoMethodError (undefined method `upload' for nil:NilClass): 「スペルミスでもしたかな?」 まずは今回新たに追記したconfig/environments/developmentとconfig/storage.ymlのファイルを見直す。 しかし特に間違っている様子はない。 次にエラー内容をgoogleにて検索。 すると、同じ境遇の方々がたくさんいらっしゃいました笑 それぞれの記事を見ていると「:が抜けている」や「""を忘れている」などの内容が多かったので、再度その辺りを確認するため、各コードを見直し。 が、やはり間違いが見当たらない・・・ S3に入る直前に挙動確認を行った際は、問題なく画像が保存されていたので、コードの書き間違いは考えにくい。 間違いがあるのはconfigの箇所であることはほぼ確定している。 でもどこが間違っているのかが全くわからない・・・ するととある記事を発見。そこには「余計なスペースが入っていた」と書かれている。 「スペース?そういえばそこは意識してなかったかも」 再度コードとにらめっこ開始。 すると・・・ 発見!!! config/storage.yml local: service: Disk root: <%= Rails.root.join("storage") %> amazon: service: S3 region: ap-northeast-1 bucket: バケット名 access_key_id: <%= ENV['AWS_ACCESS_KEY_ID'] %> secret_access_key: <%= ENV['AWS_SECRET_ACCESS_KEY'] %> amazon:の前に半角スペースが! 調べてみると、半角スペースがあるせいで、上記のlocal:の続きと見なされてしまうのだとか。 早速この余計なスペースを削除して、再度挙動確認! が、まだ保存できない・・・ さらに1時間考えた末、出した結論は PC再起動 すると無事にエラー解決できました笑
- 投稿日:2022-02-25T20:58:54+09:00
Amazon CloudFront の署名付きURL(既定ポリシー)を使って、安全にコンテンツを配信してみた
はじめに Web アプリケーションやモバイルアプリなどを提供する際に、画像などの素材を Amazon Simple Storage Service (Amazon S3) に格納したものを配信できます。セキュリティやパフォーマンスを考慮して、以下の 2 点を実現していきたいユースケースがあります。 S3 に格納したファイルは、一部のユーザーに限定して配信したい たくさんのユーザーがいるため、CloudFront を使った配信をしたい 上記を満たすために、CloudFront の署名付き URL や 署名付き Cookie が活用できます。S3 を Private Bucket にしたうえで、CloudFront の署名付き URL や 署名付き Cookie を生成することで、CloudFront のスケーラビリティを活かしながら、一部のユーザーに限定したアクセスが提供できます。Web アプリケーション側で、何らかの認証機能を利用しながら、ログイン済みユーザーに限定して署名付き URL ・署名付き Cookie を発行する仕組みを作り上げることで、実現頂けます。 次の構成図に、概要図を載せています。 ユーザーは、Web アプリケーションに備わっている認証機能でログインを行う Web アプリケーションはリクエストに応じて、画像データなどに紐づく CloudFront 署名付き URL を生成 Web アプリケーションは、ユーザー側に署名付き URL をレスポンス ユーザは、署名付き URL にアクセスすることで、Private な S3 Bucket に格納されている画像データなどを取得 概要図では、Web アプリケーション側に秘密鍵を持たせて署名付き URL を生成していますが、API Gateway + Lambda を活用したサーバーレス構成の選択肢が有ります。サーバーレス構成は運用負担の軽減といったメリットがあります。 2種類の署名付き URL 署名付き URL は、セキュリティに関するポリシーの違いによって、「規定ポリシー」と「カスタムポリシー」の 2 種類あります。2 つのポリシーの違いを AWS Document に書かれている表から抜粋します。規定ポリシーは、デフォルトの設定になっており、手を加えない分比較的楽に生成できます。一方、カスタムポリシーは自分たちのワークロードに合わせたカスタマイズが可能で、柔軟にコントロールができます。カスタムポリシーの方は、複数のオブジェクトのために再利用出来たり、アクセス元の IP アドレスの制限が出来るため、便利に利用できそうですね。 今回の記事では、規定ポリシーを使った署名付き URL を生成する方法を確認していきます。 秘密鍵・公開鍵の作成 署名付き URL を生成するために、秘密鍵・公開鍵の生成が必要です。手元の Linux マシンなどで作成していきましょう。 mkdir ~/temp/cloudfront-presign/ cd ~/temp/cloudfront-presign/ 秘密鍵を生成します openssl genrsa -out private_key.pem 2048 秘密鍵から、CloudFront に登録するための公開鍵を生成します openssl rsa -pubout -in private_key.pem -out public_key.pem こんな感じに生成できました > ls -lha total 12K drwxr-xr-x 2 ec2-user docker 51 Feb 25 20:18 . drwxrwxr-x 36 ec2-user docker 4.0K Feb 25 19:12 .. -rw-r--r-- 1 ec2-user docker 1.7K Feb 25 20:18 private_key.pem -rw-r--r-- 1 ec2-user docker 451 Feb 25 20:18 public_key.pem CloudFront に公開鍵をアップロード CloudFront のページに移動して、Create public key を押します 公開鍵の中身を確認して、登録をしていきます cat public_key.pem 登録されました。 CloudFront に Key Group を作成 Key Group を作成して、アップロードした公開鍵を登録します 名前や公開鍵の名前を選択します 作成されました S3 Bucket の作成 適当な名前で Private な S3 Bucket を作成して、うちの猫の写真をアップロードします。この写真を、署名付き URL のアクセス確認に使っていきます。 CloudFront の Distribution の作成 署名付き URL を利用するために、Create distributon を押します。 Distribution の Origin として、作成した S3 Bucket を指定 OAI を利用して、S3 Bucket のアクセスを CloudFront のみに制限 Restrict viewer access を有効にして、署名付き URL が無いとアクセスできないように設定します Create Distribution を押します Deploy プロセスが走りました 署名付きURLの生成 今回は、AWS CLI を使って CloudFront の署名付き URL を生成していきましょう。実際の環境では、SDK を使ったプログラムから署名付き URL を生成すると思います。次の Document にサンプルコードがあるので参考にできます。 aws cloudfront sign \ --url https://d31z1elfcc2o1s.cloudfront.net/mycat.jpg \ --key-pair-id K1DYHGI8XWLXZL \ --private-key file:///home/ec2-user/temp/cloudfront-presign/private_key.pem \ --date-less-than 2022-02-25T20:50:00+09:00 実行例 > aws cloudfront sign \ --url https://d31z1elfcc2o1s.cloudfront.net/mycat.jpg \ --key-pair-id K1DYHGI8XWLXZL \ --private-key file:///home/ec2-user/temp/cloudfront-presign/private_key.pem \ --date-less-than 2022-02-25T20:50:00+09:00 https://d31z1elfcc2o1s.cloudfront.net/mycat.jpg?Expires=1645789800&Signature=lteo65gt~7K2UFPyG9KEOhIEkTYid2Zn9IKG6Ync605wwnygvo~dUWjwX~N~8BmGiAPnMavtADL-mf-24aGRQa~xRSgLm6tPvoyqeX6rSptXvkrPMqtQ9HOiaHPMY8PuzMkj3CQLb-0O53CwD5HJNUeQbAers6IFvxeJoEgtWTn1YE8J1umezTxHlsHuRl7Eq0soT8iktFXaRKE0AQFjYvT5UvmkgShA2j7eqtcIW~mmKHT2LQ5XSSxztiZj5OWzFXLyET9va0Amj2t7~EOxA21n~7AWamrmU9xNCKO5bnuz31dV4L5fKSVQdxl5jFddXk6~qyxDP2r26JgXtYFMJA__&Key-Pair-Id=K1DYHGI8XWLXZL⏎ アクセス確認 通常のアクセス まず、通常通り、署名付き URL なしで CloudFront にアクセスしてみます。想定通り、エラーになりました。 署名付き URL でアクセス AWS CLI で生成した URL にアクセスしてみます。S3 Bucket にアップロードした、家猫の写真が見えました。かわいい。 有効期限切れ 署名付き URL の有効期限が切れた後にアクセスしてみた結果です。これも想定通りエラーになりました。 検証を通じてわかったこと 秘密鍵・公開鍵を生成して、CloudFront に公開鍵をアップロードする必要がある 署名付き URL を生成できるのは、秘密鍵を持っているコンピュートリソース (EC2, Lamda, ECS, App Runner など) 参考URL AWS Document : 署名付き URL の使用 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html Python のサンプルコード https://github.com/boto/boto3/blob/develop/boto3/examples/cloudfront.rst 【AWS】CloudFrontで署名付きURLの設定方法(プライベートコンテンツの配信) https://zenn.dev/may_solty/articles/807dbad3a30de8
- 投稿日:2022-02-25T20:38:36+09:00
受験談 AWS Certified Machine Learning - Specialty 認定
AWS Certified Machine Learning - Specialtyを受験しました。 受験される方の参考になりましたら。 前提 2021年 8月:SAA (受験談) 9月:SAP 11月:SOA (受験談) 12月:SCS (受験談) 2022年 1月:DVA(受験談) 2月:MLS(←今回ココ) SAA受験談に私のAWSの事前知識・経験が書いてありますが、業務等での経験はほぼゼロです。 また、機械学習という意味では、G検定を2020年に取得していますが、業務での機械学習などの経験はほぼゼロです。いずれも趣味レベルであれこれ触ってるくらいです。 これまでの認定試験と違い感じたこと 上記の通り6つ目の認定試験でしたが、これまでの認定試験と明らかに違うなと感じた点が以下です。 AWSに特化した設問が少ない 感覚的に6割?7割?くらいは、AI/機械学習の知識があれば正解できる気がしました。 Udemyやkoiwa clubとの類似問題 65問中15問、20問くらい?は、見たことあるような問題でした。 1問あたりの問題にかかる時間が少ない 勉強中もそうでしたが、1問あたりにかかる時間が比較的少なくて済んだ印象です。問題文が短めのも多かったり、長くても他の認定試験と違い把握するまでにかかる時間が短くて済む印象です。 なので、少ない時間で多くの問題を繰り返し勉強できた気がします。 活用したもの 公式サンプル問題 10問ではありますが、雰囲気や難易度をつかむには十分かなと思います。 AWS BenchPrep認定試験練習 無料で模擬問題が20問受けられるので活用しないと損です。 koiwaclub 全20節。1節7問なので合計140問。 ひたすら繰り返しました。 Udemy 本番想定の65問が2セットあります。こちらもひたすら繰り返しました。 ただ、他の認定資格の講座と違い、正解の選択肢に関しては解説があるのですが、不正解の選択肢がなぜ不正解なのか?という解説がほとんどないので、迷った時になんでこっちはダメなんだろう?というのを調べるのに苦戦しました。 Googleスプレッドシート チートシートです。SAA受験の時から作っているのでだいぶボリューム満載になってきています笑 実際の試験 上記にも書いてますが、既視問題が多かった印象とAWSに特化した問題が少なかったです。 個人的にはUdemyとkoiwa clubの問題を繰り返していれば合格ラインに達する気がしました。 一応AWSの他の認定試験とG検定の知識が余韻程度に残っている前提ではありますが、問題のパターン的には上記で十分網羅されていた感じです。 勉強しててちょっと苦戦したのは、Udemyとkoiwa clubで同じ問題でも回答が異なるものがいくつかあったことです。自分なりに調べて納得・理解したつもりなので、それはそれで勉強にはなりましたが結局最後までどっちが正解なの?というのもありました・・。 あと、特に以下3つは頻出サービスになるので、実際に一度はコンソールでポチポチしてイメージを沸かせてみました。理解せずとも操作すると「この単語ってどのサービスの話だったっけ?」というのが思い出しやすくなると思います。 Sage Maker Kinesis Glue まとめ SAA+G検定直後のタイミングの人は、受けちゃってみるのもオススメな気がします。
- 投稿日:2022-02-25T20:26:53+09:00
Cost Explorer API で特定のコストカテゴリの料金を取得する
モチベーション AWS Cost Explorer は 日次や月次レベルで AWS のコストと使用量の可視化、把握、管理を行うことができるサービスです。コンソールから利用できますが、API が用意されているため、プログラムから定期的に目的のコストを状況を抽出して通知するなどといった自動化が可能です。 CloudWatch の Billing メトリクスでも各アカウントの概算費用は取得できますが、アカウント ID の情報しか持っていません。そのためシステム単位等の特定のアカウント郡のコストだけを抽出することは CloudWatch メトリクスの機能だけでは実現できません。 AWS Billing and Cost Management にはコストカテゴリという機能があり、特定のルールでコストのグループを作成できます。Cost Explorer ではコストカテゴリでフィルターした料金を抽出できるため、CloudWatch メトリクスより簡単かつ、柔軟にコストの分析が可能です。 コストカテゴリの作成 AWS Billing Management コンソールからコストカテゴリを作成できます。例えば以下のコストカテゴリおよびルールはアカウント名が SampleSystem- で始まるアカウントをグループ化しています。現状、AWS Organizations の OU 単位等でのグループ化はサポートされていないため、ここではアカウント名をベースにカテゴリを作成します。 コストカテゴリを作成すると、指定したルールによって分類されたコストを確認することができます。以下の例では全体 AWS コストのうち、51% がコストカテゴリでグループ化したアカウントのコストであることがわかります。(金額等はマスキングしています。) コストカテゴリ作成後、Cost Explorer でフィルター条件として指定できるようになります。 Cost Explorer API 経由で取得する 例えば AWS Lambda から boto3 を使用して月の合計料金を取得する場合、最低限の処理は以下のようになります。 lambda_function.py import boto3 def lambda_handler(event, context): ce = boto3.client('ce') response = ce.get_cost_and_usage( TimePeriod={ 'Start': '2022-02-01', 'End' : '2022-02-28', }, Granularity='MONTHLY', Metrics= [ 'NetUnblendedCost' ], Filter={ 'CostCategories': { 'Key': 'Sample System Accounts', 'Values': [ 'Sample System Accounts', ] } } ) print(response['ResultsByTime'][0]['Total']) 結果例 {'NetUnblendedCost': {'Amount': '42969.6600696831', 'Unit': 'USD'}} GroupBy を使用するとコストをグループ化して取得することが可能です。Cost Explorer コンソールではグループ化条件は 1 つまでしか適用できませんが、Cost Explorer API では最大 2 つのグループ化条件を指定することができます。以下の例ではコストカテゴリでアカウントを Filter し、GroupBy で Linked Account ごとにサービス別のコストを取得しています。 lambda_function.py import boto3 def lambda_handler(event, context): ce = boto3.client('ce') response = ce.get_cost_and_usage( TimePeriod={ 'Start': '2022-02-01', 'End' : '2022-02-28', }, Granularity='MONTHLY', Metrics= [ 'NetUnblendedCost' ], Filter={ 'CostCategories': { 'Key': 'Sample System Accounts', 'Values': [ 'Sample System Accounts', ] } }, GroupBy=[ { 'Type': 'DIMENSION', 'Key': 'LINKED_ACCOUNT' }, { 'Type': 'DIMENSION', 'Key': 'SERVICE' } ] ) print(response['ResultsByTime'][0]['Groups']) 結果例 (見やすくするため改行をいれています) [ {'Keys': ['123456789012', 'AWS Key Management Service'], 'Metrics': {'NetUnblendedCost': {'Amount': '0.1175595208', 'Unit': 'USD'}}}, {'Keys': ['123456789012', 'AWS Secrets Manager'], 'Metrics': {'NetUnblendedCost': {'Amount': '0.095238096', 'Unit': 'USD'}}}, {'Keys': ['123456789012', 'AWS Security Hub'], 'Metrics': {'NetUnblendedCost': {'Amount': '1.904', 'Unit': 'USD'}}}, {'Keys': ['123456789012', 'EC2 - Other'], 'Metrics': {'NetUnblendedCost': {'Amount': '0.4245898221', 'Unit': 'USD'}}}, {'Keys': ['123456789012', 'Amazon Elastic Compute Cloud - Compute'], 'Metrics': {'NetUnblendedCost': {'Amount': '0.0002534851', 'Unit': 'USD'}}}, {'Keys': ['111111111111', 'Amazon Elastic Container Service for Kubernetes'], 'Metrics': {'NetUnblendedCost': {'Amount': '25.302975656', 'Unit': 'USD'}}}, {'Keys': ['111111111111', 'Amazon Elastic Load Balancing'], 'Metrics': {'NetUnblendedCost': {'Amount': '3.888', 'Unit': 'USD'}}}, {'Keys': ['111111111111', 'Amazon Kinesis'], 'Metrics': {'NetUnblendedCost': {'Amount': '1.56', 'Unit': 'USD'}}}, {'Keys': ['111111111111', 'Amazon Simple Storage Service'], 'Metrics': {'NetUnblendedCost': {'Amount': '0.0000000128', 'Unit': 'USD'}}}, {'Keys': ['222222222222', 'Amazon Virtual Private Cloud'], 'Metrics': {'NetUnblendedCost': {'Amount': '5.6000999356', 'Unit': 'USD'}}}, ] あとはこれらの結果を加工して Slack 通知するなど、煮るなり焼くなり好きにできますね。 注意点 Cost Explorer API は 1 リクエストあたり、$0.01 の料金が発生します。呼び出し回数が増えると料金も高額になってきますのでご注意ください。 Cost Explorer API を使用してアプリケーションを作成する場合は、キャッシュレイヤーを含むように設計することが推奨されています。 Best practices for optimizing your Cost Explorer API costs If you're creating an application using the Cost Explorer API, we recommend architecting the application so that it has a caching layer. 以上です。 参考になれば幸いです。
- 投稿日:2022-02-25T18:51:42+09:00
aws Lightsail Redmine インスタンスによるチケットシステムの構築
最終形 Lightsail Redmine インスタンスを生成する インスタンスロケーション: 東京、ゾーンA (ap-northeast-1a) プラットフォーム: Linux 設計図: Redmine 4.2.3-38 インスタンスプラン: 3.5 USD これで http 接続により Redmine が利用可能になります。インスタンスの起動待ち時間を除くと、1、2分の作業で構築完了です。 静的 IP をアタッチする ネットワーキング > 静的 IP の作成 DNS (Route53) にて サブドメイン で 静的IP をポイントする Let's Encrypt SSL 証明書をインストールする こちらの一次情報に従ってインストールします。 一次情報上の「方法1」の「アプローチA」に従って設定を行いましたが、その前にサービスを停止しておきました。 $ sudo /opt/bitnami/ctlscript.sh stop Stoping services.. $ 「6. SSL 証明書と証明書キーファイルを、Web サーバーが現在読み取っている場所にリンクします。」が完了すると、https 通信が可能になります。 動作確認 サービス起動 $ sudo /opt/bitnami/ctlscript.sh start Starting services.. $ ブラウザから https でアクセスする 証明書の自動更新を設定する 一次情報の「7. 証明書の自動更新を設定します。」に従って設定しましたので、日次で証明書の自動更新を行なってくれるはずです。実行結果は明日確認してみます。 構築時点 $ pwd /opt/bitnami/apache2/conf/bitnami/certs $ ls -ltr total 8 -rw-rw-r-- 1 bitnami root 1679 Jan 8 08:42 server.key.old -rw-rw-r-- 1 bitnami root 981 Jan 8 08:42 server.crt.old lrwxrwxrwx 1 root root 52 Feb 25 08:17 server.key -> /opt/bitnami/letsencrypt/certificates/demoru.net.key lrwxrwxrwx 1 root root 52 Feb 25 08:18 server.crt -> /opt/bitnami/letsencrypt/certificates/demoru.net.crt $ 24 時間経過後 Todo http 通信を許可しない Lightsail インスタンスの [ネットワーキング] タブにある IPv4ファイアウォール と IPv6ファイアウォール で 80番ポートをふさぎました。 メール通知 メール通知があると便利です。私の場合はメール通知のおかげで自分が関与しているチケットの動きがわかるので、「滞留しているチケットを探す」という作業を行う頻度を下げることができました。 aws SES を用いてメール通知が送信できる仕組みを採用しました。 SES SMTP 認証情報を取得する こちらの一次情報に従い、SMTP ユーザ名 と SMTP パスワード を取得します。 Redmine の config に SES SMTP 認証情報を設定する こちらの一次情報に従い設定しました。 テストメールを送信する Redmine の 管理 > 設定 > [メール通知]タブ画面の右下に [テストメールを送信] リンクをクリックすると、自分宛にテストメールが送信されます。 私の環境では 554 エラーが発生していましたが、こちらの一次情報 に従い対応しました。 成果物 https://rm.demoru.net 組織 unremoted.com
- 投稿日:2022-02-25T17:49:25+09:00
AWS Compute Optimizerを利用したコスト・パフォーマンス最適化
はじめに まず、AWS Compute Optimizerというサービスをご存知でしょうか? AWS Compute Optimizerは簡単に言うとAWSコンピューティングサービスのメトリクスから パフォーマンス及びコストを最適化の提案をしてくれるサービスです。 AWS Compute Optimizer は、 AWS リソースの設定と使用率のメトリクスを分析するサービスです。 リソースが最適かどうかを報告します。また、コストを削減し、ワークロードのパフォーマンスを向上させるための最適化に関する推奨事項を生成します。 対象リソース AWS Compute Optimizerでは以下のリソースをサポートしています。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス Amazon EC2 Auto Scaling グループ Amazon Elastic Block Store (Amazon EBS) ボリューム AWS Lambda 関数 使い方 AWS Compute Optimizerコンソールからオプトインを実行する、またはAWS CLIで有効化する事で利用が開始されます。 オプトインを開始すると自動的に過去14日分のコンピューティングリソースのメトリクスが取得され、対象リソースのレコメンデーションを表示してくれます。 AWS Compute Optimizerコンソールでは以下の様に各リソースのレコメンデーションを割合で表示してくれます。 例えばLambdaでは現在設定されているメモリではパフォーマンスが低いので メモリを増加するようにレコメンデーションされています。 表示されているレコメンデーションはCSV形式でエクスポートもできますので、他人と共有するのも楽です。 料金 AWS Compute Optimizerではレコメンデーションを計算する為の拡張メトリクスが使われており その拡張メトリクスに対して1時間単位で料金がかかる仕組みなってます。 1 リソース1 時間あたり 0.0003360215 USD 1 リソースあたり月額 0.25 USD 各リソースにつき 1 時間あたり 0.0003360215 USD で、リソースが実行されている 1 か月あたりの時間数に基づいて請求されます。 この機能のコストは、1 か月間 31 日フルで稼働するリソースに対して、1 リソースあたり月額 0.25 USD となります。 まとめ コンピューティングリソースのサイジングの見直しはCPUやメモリのDiskの利用状況、トラフィックパターン等複数の要素とニラメッコしながら実施する 比較的大変な作業ですがこのサービスを利用する事によって簡単に安価に推奨事項を取得する事ができるので便利だと思います。 いいなと思った方は有効化(オプトイン)してみてはいかがでしょうか。
- 投稿日:2022-02-25T17:48:38+09:00
EC2を使用して、別アカウントのS3バケットからオブジェクトを移行する方法
はじめに S3間で40TB以上のデータ移行が必要になり、普通にやると約2日かかる。 そこで、tmuxを使用しセッションが切れても実行し続ける環境をEC2インスタンス上で構築しました。 その時の学習をアウトプットできればと思います。 手順 前提 EC2インスタンスにSSM接続ができるように設定する EC2を起動するサブネットへS3用のエンドポイントを作成 手順 1. 【targetアカウント】EC2用のIAMロールを作成 2. 【sourceアカウント】バケットポリシーを作成 3. 【targetアカウント】EC2インスタンスにtmuxをインストール 4. 【targetアカウント】tmuxで新規シェルを作成し、移行コマンドの実行 今回の構成図 手順1 【targetアカウント】EC2用のIAMロールを作成 1.1 下記カスタマ管理ポリシーを作成 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetObject" ], "Resource": [ "arn:aws:s3:::<sourceのS3バケット名>", "arn:aws:s3:::<sourceのS3バケット名>/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:PutObject", "s3:PutObjectAcl", "s3:GetObject" ], "Resource": [ "arn:aws:s3:::<targetのS3バケット名>", "arn:aws:s3:::<targetのS3バケット名>/*" ] } ] } 1.2 カスタマー管理ポリシーを、EC2へアタッチするIAMロールへ追加 手順2 【sourceアカウント】バケットポリシーを作成 下記バケットポリシーをsorceアカウントの対象S3バケットのバケットポリシーに記入します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AddCannedAcl", "Effect": "Allow", "Principal": { "AWS": "<EC2へアタッチしたIAMロールのARN>" }, "Action": [ "s3:ListBucket", "s3:GetObject", "s3:GetObjectTagging" ], "Resource": [ "arn:aws:s3:::<targetのS3バケット名>", "arn:aws:s3:::<targetのS3バケット名>/*" ] } ] } ここまでで、EC2へSSM接続しsorceアカウントの対象のS3バケットのオブジェクト名など取得できることを確認する。 # 下記コマンドで、オブジェクト名が表示されたら成功 $ aws s3 ls s3://<sourceのS3バケット名> オブジェクト名が取得できなければ、 ・バケットポリシーの内容 ・S3用のエンドポンとがあるか など確認する。 手順3 【targetアカウント】EC2インスタンスにtmuxをインストール tmuxとは 端末多重化ソフトウェア(ターミナル画面を複数開くことで、同時作業が可能になる) tmuxを使用する背景: セッションマネージャーにはセッション維持の制限時間があるが、tmuxで作成したターミナルは明示的にセッションを終了しなければ維持され続ける。 冒頭でも書いたように、今回は40TB以上のデータを移行するので最低でも2日間はセッションを維持しておく必要がある。 # 下記コマンドでインストール $ sudo yum install -y tmux 手順4 【targetアカウント】tmuxで新規シェルを作成し、移行コマンドの実行 4.1 新規セッションの起動 # 下記コマンドで新規セッションの開始 $ tmux new -s <セッション名> 4.2 起動したセッションで、コマンドを実行 # 下記コマンドでデータ移行 aws s3 sync s3://<sourceバケット名> s3://<targetバケット名>/ --acl bucket-owner-full-control 無事データが移行できていることを確認! 4.3 【番外】tmuxのセッションから抜ける方法 ctrl + bを押した後に dを入力 参考 Amazon S3 の VPC エンドポイントのタイプ とほほのtmux入門
- 投稿日:2022-02-25T15:52:36+09:00
AWSのEC2の環境構築で参考にしたサイト(rails,docker,nginx)
以下のインフラ環境を構築するまでに参考にしたサイトをご紹介します。 1,AWSの全体的な知識を付けるために参考にしたもの <動画教材> WEBエンジニアの山浦さんのUdemyの動画教材です。 解説が初心者に優しく、わかりやすいのでおすすめです。 <書籍> 解説がわかりやすいです。 イラスト使って説明してくれるので、なにをやっているのかイメージしやすく、すぐに読み終えることができました。 補足: ご紹介した2点は内容が共通している部分が多いです。 山浦さんの動画教材の方が、内容が濃いので、そちら1点だけでも良いかもしれません。 2,VPC作成からEC2にデプロイするまで 有料の教材です。 買っても良いと思いますが、chapter3まで無料なのでそこまでやって、その後は次にご紹介する記事を参考にすると良いと思います。 この記事にはかなり助けられました。 これを進めれば、RDSの作成やdocker環境でwebサーバーがnginxのrailsアプリをEC2にデプロイまでできます。 3,ALBを使用してHTTPからHTTPSでサイトにアクセスできるようにする サイトのHTTPS化には次のサイトを参考にしました。 chapter6でHTTPS化、 chapter7でHTTPでアクセスしてもHTTPSになるように設定できるようになります。 ちなみにサイトのドメインの取得方法は、最初にご紹介した山浦さんの動画で、「お名前.com」でドメインを購入し、Route53と連携する所まで紹介されています。 4,SESを使ったメール送信 AWSのSESを使用してメール送信は以下のサイトを参考にしました。 SES導入はエラーがでまくり、かなり苦戦したので、一応自分のエラーが出なかったproduction.rbを貼っておきます。 config/enviroments/production.rb creds = Aws::Credentials.new( ENV['AWS_ACCESS_KEY_ID'], ENV['AWS_SECRET_ACESS_KEY'] ) Aws::Rails.add_action_mailer_delivery_method( :aws_sdk, credentials: creds, region: ENV['AWS_REGION'] ) config.action_mailer.default_url_options = { host: 'あなたが取得したドメイン名' } config.action_mailer.delivery_method = :aws_sdk config.action_mailer.perform_deliveries = true config.action_mailer.perform_caching = false config.action_mailer.raise_delivery_errors = true ポイントは、 config.action_mailer.delivery_method = :aws_sdk の部分です。 rails aws sesで検索すると、ここが「:ses」になっている記事が多いですが、「:aws_sdk」にしないとエラーが出たので、よかったら参考にしてください。 4,S3に画像をアップロードする S3はRailsチュートリアルを参考に実装しました。 最後に 山浦さんのUdemyの講座が全体を網羅しているので、山浦さんの教材を軸にご紹介した記事などを参考に進めれば、環境構築はできると思います。
- 投稿日:2022-02-25T15:39:37+09:00
AWS セキュリティグループとネットワークACLの主な違い
セキュリティグループ EC2インスタンスなどに適用するファイアウォール機能。 許可するルールのみ定義する。 デフォルトの設定値の場合、アウトバウンド通信はすべて許可、インバウンド通信はすべて拒否する。 EC2インスタンスに複数のセキュリティグループの適用が可能で、設定の追加・変更は即座に反映される。 ステートフルな制御が可能。(ルールで許可された通信の戻り通信も自動的に許可される) ネットワークACL サブネット単位で設定するファイアウォール機能。 各ルールに番号を割り当て、番号順に許可または拒否のルールを適用する。 VPC作成時に、デフォルトのネットワークACLがひとつ準備されており、初期設定ではすべてのトラフィックを許可。 VPC内に作成したサブネットごとにひとつのネットワークACLを設定可能。 新規に作成することもでき、その場合はすべてのトラフィックを拒否。 インバウンド、アウトバウンドそれぞれに対して、許可または拒否を明示した通信制御が可能。 ステートレス(インバウンドとアウトバウンドに対する通信制御が必要) 参照 AWS認定ソリューションアーキテクトアソシエイト教科書
- 投稿日:2022-02-25T12:52:51+09:00
CloudEndureメモ
前準備 まずcoudendureのアカウントを作成 https://console.cloudendure.com/#/register/register vagrantとかで適当にサーバたてる 今回はcentos7で使用できるサーバの条件などは下記参照 https://docs.cloudendure.com/Content/Getting_Started_with_CloudEndure/Supported_Operating_Systems/Supported_Operating_Systems.htm aws側でcloudendure用の IAMユーザ、ポリシー、VPC、サブネット、ルートテーブル、IGW作成設定 ポリシー には画像のリンクのJSONを張り付け ポリシーが作成できたら新規で作成したIAMユーザに既存のポリシーを直接アタッチ アクセスキーなど払い出されるので CloudEndureのAWS CREDENTIALSに登録 レプリケーション設定 ソースにはOther Infrastructure ターゲットは今回はオレゴン レプリケーションサーバの設定は要件に合わせて設定 今回はインスタンスタイプがt2.micro VPCは前準備で作成したもの 他はデフォルト cloudendureのAgentをインストール 適当に作ったサーバにログインして wgetとpythonのコマンドを打つ インストールが終わったらCloudEndureのMachinesタブにサーバが出てくる AWS上にもレプリケーションサーバが立ち上がる 同期が終了したらBLUEPRINTの設定を行う EC2の設定のようなものをcloudendure上で行う ストレージタイプがデフォルトだとPIOPSなので注意 設定を保存後ランチターゲットマシーンからテストモードでサーバ起動 しばらくするとAWS上にコンバータサーバが立ち上がる EC2インスタンスも自動で立ち上がる コンバータサーバはEC2インスタンスが作成されると自動で削除される teratermとかでSSHログインして確認 セキュリティグループを設定していない場合インバウンドルールからポート22、マイIPで設定しておく カットオーバー テストが問題なければカットオーバーモードで起動 テストで作成されたEC2とコンバータサーバは自動削除される cloudendure上でオプションから移行元サーバをリムーブすると レプリケーションサーバも自動で削除される
- 投稿日:2022-02-25T12:40:49+09:00
WSL + Ubuntu 20.04に AWS CLI を入れる
当たり前だが入ってない $ aws --version Command 'aws' not found, but can be installed with: sudo apt install awscli 以下が入ってるか確認します /usr/lib/x86_64-linux-gnu/libc.so.6 curl unzip groff less $ /usr/lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Ubuntu GLIBC 2.31-0ubuntu9.2) stable release version 2.31. Copyright (C) 2020 Free Software Foundation, Inc. ...以下略 $ curl --version curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3 ...以下略 $ unzip --version Command 'unzip' not found, but can be installed with: sudo apt install unzip $ groff --version GNU groff version 1.22.4 Copyright (C) 2018 Free Software Foundation, Inc. ...以下略 $ less --version less 551 (GNU regular expressions) Copyright (C) 1984-2019 Mark Nudelman ...以下略 unzip 入ってないので入れる $ sudo apt install unzip Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: zip The following NEW packages will be installed: ...などなど以下略 AWS CLIをダウンロード $ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "/tmp/awscliv2.zip" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 43.6M 100 43.6M 0 0 6403k 0 0:00:06 0:00:06 --:--:-- 5051k AWS CLIをインストール $ unzip /tmp/awscliv2.zip -d /tmp/ && sudo /tmp/aws/install -i /usr/local/aws-cli -b /usr/local/bin Archive: /tmp/awscliv2.zip creating: /tmp/aws/ creating: /tmp/aws/dist/ inflating: /tmp/aws/install ...以下略 確認 aws --version aws-cli/2.4.21 Python/3.8.8 Linux/4.19.128-microsoft-standard exe/x86_64.ubuntu.20 prompt/off 上手に入りました
- 投稿日:2022-02-25T11:38:45+09:00
エンジニア目線で始める Amazon SageMaker Training ③機械学習を使わないはじめての Bring Your Own Container
過去記事一覧 Amazon SageMaker Training で Bring Your Own Container する 今まで、 AWS が用意していたコンテナイメージを利用して Training Job を起動していました。 具体的には TensorFlow, PyTorch, MXNet, Scikit-Learn のコンテナを利用する例を紹介しました。 では、独自コンテナを使う場合はどうなんでしょうか?というのを試してみます。 例にもれず、こちらの GitHub リポジトリに使用しているコードをアップロードしておりますので、併せてご参照ください。 Hello My Container 早速 Hello World 相当のことをしてみましょう。 このようなコードと Dockerfile を用意してみました。 ./container/3-1/Dockerfile FROM python:3.9.10-slim-buster COPY ./hello_my_container_image.py / ENTRYPOINT ["python","/hello_my_container_image.py"] ./container/3-1/hello_my_container_image.py print('Hello my container .') exit() python の 3.9 slim-buster のコンテナイメージで、 Hello my container image. と出力するだけの簡単なコードをコンテナの中に入れて、ENTRYPOINT で実行しなさい、と指定しているだけです。 さて、このコンテナを使って SageMaker Training を実行してみたいのですが、SageMaker Training で自分のコンテナイメージを使うには、 まず Amazon Elastic Container Registry (ECR) にプッシュする必要があります。ビルドしてプッシュしましょう。 ビルド ./3_byoc.ipynb IMAGE_NAME='sagemaker-slim-buster' TAG = ':python39' %cd container/3-1 !docker build -t {IMAGE_NAME}{TAG} . %cd ../../ プッシュ ./3_byoc.ipynb # boto3の機能を使ってリポジトリ名に必要な情報を取得する import boto3 MY_ACCOUNT_ID = boto3.client('sts').get_caller_identity().get('Account') REGION = boto3.session.Session().region_name # ECR へ Docker Image の push MY_ECR_ENDPOINT = f'{MY_ACCOUNT_ID}.dkr.ecr.{REGION}.amazonaws.com/' MY_REPOSITORY_URI = f'{MY_ECR_ENDPOINT}{IMAGE_NAME}' MY_IMAGE_URI = f'{MY_REPOSITORY_URI}{TAG}' !$(aws ecr get-login --region {REGION} --registry-ids {MY_ACCOUNT_ID} --no-include-email) # リポジトリの作成 !aws ecr delete-repository --repository-name {IMAGE_NAME} --force # 同名のリポジトリがあった場合削除 !aws ecr create-repository --repository-name {IMAGE_NAME} !docker tag {IMAGE_NAME}{TAG} {MY_IMAGE_URI} !docker push {MY_IMAGE_URI} print(f'コンテナイメージは {MY_IMAGE_URI} へ登録されています。') これらを実行することによって ECR へコンテナイメージをプッシュできました。 最後に実行してみます。 ./3_byoc.ipynb from sagemaker.estimator import Estimator estimator = Estimator( image_uri = MY_IMAGE_URI, role=sagemaker.get_execution_role(), instance_count=1, instance_type='ml.m5.xlarge', ) estimator.fit() 出力結果 (略)hello my container . (略) 無事 Hello my container image. という出力を得ることが出来ました。 こんな感じで、エンジニア目線で始める Amazon SageMaker Training ①機械学習を使わないはじめての Training Job の表現に戻りますが、 「Amazon SageMaker Training とは、①用意したコードを ②用意したデータと ③用意した環境で実行してくれ 、 ④結果を自動で保存してくれ る、バッチ処理サービスです。」 が体感できました。 環境を準備し、コンテナ内に処理したい内容をコードに記載して入れてしまえば実行ができることがわかりました。 独自コンテナで SageMaker の機能を使うためには Hello my container の例では自前で作ったコンテナイメージを SageMaker Training ジョブで動かせましたが、SageMaker Training では、コンテナの外(S3)からコードとデータを与え、成果物を S3 に出力する、という機能を使いたいですが、このままではその機能を利用できません。 やり方は公式 Doc に記載があります。 Adapting Your Own Training Container 詳細は Doc を読んでいただきたいのですが、肝は Dockerfile の以下の部分です。 RUN pip3 install sagemaker-training sagemaker-training をインストールすることで、記事①で紹介した機能を利用できるようになります。 さて、実際にやってみましょう。 ./container/3-2/Dockerfile FROM python:3.9.10-slim-buster RUN apt update -y && \ apt install gcc -y && \ pip3 install sagemaker-training apt で gcc をインストールしてますが、sagemaker-training のインストールに gcc が必要だったためインストールしておりますが、ご覧の通り先程利用した python:3.9.10-slim-buster に sagemaker-training をインストールしているだけです。 先程同様ビルドとプッシュをしておきます。 ./3_byoc.ipynb IMAGE_NAME='sagemaker-slim-buster' TAG = ':python39-sagemaker-training' %cd container/3-2 !docker build -t {IMAGE_NAME}{TAG} . %cd ../../ # boto3の機能を使ってリポジトリ名に必要な情報を取得する import boto3 MY_ACCOUNT_ID = boto3.client('sts').get_caller_identity().get('Account') REGION = boto3.session.Session().region_name # ECR へ Docker Image の push MY_ECR_ENDPOINT = f'{MY_ACCOUNT_ID}.dkr.ecr.{REGION}.amazonaws.com/' MY_REPOSITORY_URI = f'{MY_ECR_ENDPOINT}{IMAGE_NAME}' MY_IMAGE_URI = f'{MY_REPOSITORY_URI}{TAG}' !$(aws ecr get-login --region {REGION} --registry-ids {MY_ACCOUNT_ID} --no-include-email) !docker tag {IMAGE_NAME}{TAG} {MY_IMAGE_URI} !docker push {MY_IMAGE_URI} print(f'コンテナイメージは {MY_IMAGE_URI} へ登録されています。') さて、このコンテナイメージで、記事①の 1-5 で行ったコードとデータを持ち込んで成果物を S3 に保存を実行してみます。 実行 ./3_byoc.ipynb input_s3_uri = sagemaker.session.Session().upload_data(path='./data/1-5/', bucket=sagemaker.session.Session().default_bucket(), key_prefix='training/1-5') from sagemaker.tensorflow import TensorFlow estimator = TensorFlow( entry_point='./src/1-5/concat.py', image_uri=MY_IMAGE_URI, instance_count=1, instance_type='ml.m5.xlarge', role=sagemaker.get_execution_role() ) estimator.fit(input_s3_uri) 結果確認 ./3_byoc.ipynb import tarfile prefix = estimator.latest_training_job.describe()['ModelArtifacts']['S3ModelArtifacts'].replace(f's3://{sagemaker.session.Session().default_bucket()}/','') sagemaker.session.Session().download_data('./', sagemaker.session.Session().default_bucket(), key_prefix=prefix) with tarfile.open('./model.tar.gz', 'r') as f: f.extractall() !cat output.csv 出力結果 1,2 3,4 5,6 7,8 AWS の SageMaker Training のコンテナを拡張する場合 先程の例では slim-buster をベースイメージとして実行した例ですが、SageMaker Training のコンテナを拡張したいケースもあるかと思います。 その場合は、sagemaker-training 相当のものはすでに入っているのでインストール不要ですので、必要なモジュールを追加を Dockerfile に記載するだけで OK です。 詳細はこちらをご覧ください。(コードを紹介するまでもないので…)
- 投稿日:2022-02-25T09:44:30+09:00
【AWS】Webアプリケーションを作りたいと思った場合のシステム構成図
今回はAWSにてWebアプリケーションを構築したい場合、どういった構成がとれるのか、といった議題で執筆しようと思います。 VPCを構築 まずVPCを構築しましょう。VPCとは、「Virtual Private Cloud」の略でAWS上に仮想ネットワークを構築することが可能です。 AWS上にVPCを東京リージョンで構築したとすると下記図になるかと思います サブネットを構築 次にサブネットを構築しましょう。サブネットにはインターネットとのアクセスを可能とする「パブリックサブネット」とVPC内で通信を行いインターネットとのアクセスを許可しない「プライベートサブネット」と大きく二つに分かれます。 パブリックサブネットとプライベートサブネットの違いは「インターネットゲートウェイ(IGW)」がサブネットのルートテーブルに設定しているかどうかと覚えているとよいかと思います。 では上記の図にパブリックサブネットとプライベートサブネットを構築してみます。 ここでAvaliability Zone(アベイラビリティゾーン)というのが図に記載されていますが、アベイラビリティゾーンとはデータセンターと思ってください。データセンターを跨ぐことで、例えば災害などでデータセンターが停電などになった場合、サーバーが停止あるいは故障してしまう可能性があるのを防ぐことができます。図のような構成を「マルチAZ」構成と呼びます。 基本的にAWSでサーバー構築する場合はマルチAZ構成で構築することをおすすめします。 EC2の構築 ここまで??が飛んでいるかも知れませんが、ここからが本題みたいなところです。「Webサーバー」の登場です。 WebサーバーにはEC2やECSなどコンピューティングサービスを選択するとよいでしょう。また、サーバーレスアプリケーションとしてLambdaを選択するのもよいかと思います。 今回はEC2で開発するとします。 筆者はWindows系で開発することが多いので、EC2のWindows Serverを選択し、EC2構築後は日本語設定やIISを構築した後、.NETフレームワークのインストールなどを行い、C#でのアプリケーションを構築したりします。 ではEC2の構築した後のシステム構成を下記図に記載します。 パブリックサブネットにEC2を構築しました。 ALB(アプリケーションロードバランサー)の構築 ロードバランサーの機能を持つ「ELB」を用いてそれぞれのサブネットに構築しているEC2に振り分けを行います。 インターネットから例えば「 https://www.miya.com 」とURLをたたくと、今後投稿予定ではありますが、ACM(AWS Certificate Manager)にてhttpsを実現し、www.miya.comはRoute53にてドメイン解決を行い、www.miya.comをALBのURLをドメイン登録しておくとALBからそれぞれのサブネットに構築しているEC2へ振り分けをしてくれます。 冗長構成としての役割ともなりますし、例えばABテストなどにも活用することが可能です。同一セッションであれば同じサーバーへルーティングする「スティッキーセッション」を用いることでアクセスしているサーバー依存のアプリケーションにも対応しています。 ではALBの構成も図に記載します。 RDSの構築 最後にデータベースの構築をしましょう。例えばショッピングサイトなどのECサイトを構築した場合、注文履歴などをデータベースに登録する必要があります。Web上で買い物した場合にDBに書き込みを行うためにRDSを用います。 AWSにはRDSのほかにも、「DynamoDB」や「Redshift」、「ElasticCache」などがあります。リレーショナルデータベースが必要な場合やSQLを利用したい場合はRDSを選択しましょう。 RDSにはOracleやPostgreSQLなど幅広いリレーショナルデータベース管理システムが対応しています。その中でもAWSでは「Amazon Aurora」を推奨しています。Auroraを利用することで性能が格段に高まるので、できる限りAuroraを利用することをおすすめします。 最終的なシステム構成図 インターネット経由で接続をした場合、下記構成になるかと思います。 上記の構成には、まだネットワークACLやセキュリティーグループなどのファイヤーウォールの設定やルートテーブルの設定、ACMやRoute53の話ができていないため、説明としては不十分ですが今後投稿していけばと思います。
- 投稿日:2022-02-25T07:13:11+09:00
DynamoDBに作成済みのテーブルを複製したい!(手作業ではやりたくない)
仕事でDynamoDBの既存テーブルを複製する必要があり、一つずつ手作業で作成するのは大変だし、設定が漏れてしまう可能性もあるため、2コマンドで複製できるようにしてみました。 テーブル情報作成用シェルスクリプト 第一引数に指定したテーブルの情報をコピーしてXXXX_copyというテーブル名で出力するシェルスクリプトを作成します create-table-description.sh #!/bin/sh # テーブル名 TABLE_NAME=$1 TABLE_NAME_COPY=$1_copy # 指定テーブルの定義を取得 DESCRIPTION=`aws dynamodb describe-table --table-name $TABLE_NAME` # 必要な項目以外は削除 CONTENTS=`echo $DESCRIPTION | jq '.Table' | jq 'del(.ProvisionedThroughput.NumberOfDecreasesToday)' | jq 'del(.ProvisionedThroughput.LastIncreaseDateTime)' | jq 'del(.ProvisionedThroughput.LastDecreaseDateTime)' | jq 'del(.TableSizeBytes)' | jq 'del(.TableStatus)' | jq 'del(.ItemCount)' | jq 'del(.CreationDateTime)' | jq 'del(.TableArn)' | jq 'del(.TableId)' | jq 'del(.LatestStreamLabel)' | jq 'del(.LatestStreamArn)' | # テーブル名を変換して出力 jq --arg table "$TABLE_NAME_COPY" '.TableName = $table' ` # グローバルセカンダリインデックスがある場合 if test `echo $CONTENTS | jq 'has("GlobalSecondaryIndexes")'` = true; then echo has GlobalSecondaryIndexes CONTENTS=`echo $CONTENTS | jq 'del(.GlobalSecondaryIndexes[].IndexArn)' | jq 'del(.GlobalSecondaryIndexes[].ItemCount)' | jq 'del(.GlobalSecondaryIndexes[].IndexStatus)' | jq 'del(.GlobalSecondaryIndexes[].IndexSizeBytes)' | jq 'del(.GlobalSecondaryIndexes[].ProvisionedThroughput.NumberOfDecreasesToday)' | jq 'del(.GlobalSecondaryIndexes[].ProvisionedThroughput.LastIncreaseDateTime)' | jq 'del(.GlobalSecondaryIndexes[].ProvisionedThroughput.LastDecreaseDateTime)' ` fi # ローカルセカンダリインデックスがある場合 if test `echo $CONTENTS | jq 'has("LocalSecondaryIndexes")'` = true; then echo has LocalSecondaryIndexes CONTENTS=`echo $CONTENTS | jq 'del(.LocalSecondaryIndexes[].IndexArn)' | jq 'del(.LocalSecondaryIndexes[].IndexStatus)' | jq 'del(.LocalSecondaryIndexes[].ItemCount)' | jq 'del(.LocalSecondaryIndexes[].IndexSizeBytes)' | jq 'del(.LocalSecondaryIndexes[].ProvisionedThroughput.NumberOfDecreasesToday)' | jq 'del(.LocalSecondaryIndexes[].ProvisionedThroughput.LastIncreaseDateTime)' | jq 'del(.LocalSecondaryIndexes[].ProvisionedThroughput.LastDecreaseDateTime)' ` fi # jsonファイル出力 echo $CONTENTS > $TABLE_NAME_COPY.json DynamoDBにテーブルを作成 前提 aws-cliインストール済み aws configureでDynamoDBの読み書き可能なアカウントの認証情報を設定していること jqインストール済み https://stedolan.github.io/jq/manual/ 実行 # テーブル情報作成 ./create-table-description.sh Test # コピーテーブルを作成 aws dynamodb create-table --cli-input-json file://Test_copy.json 補足 データのコピーについてはDataPipelineでExport/Importする必要があるようです https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/DynamoDBPipeline.html 参考 https://www.hands-lab.com/tech/t188/ https://docs.aws.amazon.com/cli/latest/reference/dynamodb/create-table.html
- 投稿日:2022-02-25T00:54:16+09:00
Quicksite上のVPC接続情報を削除or作成する権限は何か
Quicksiteから他アカウントのデータソースを参照しようとしました。 VPCピアリングを行い、Quicksite上にVPC接続情報を登録したまでは良かったのですが あれ!?Quicksiteに作成したVPC接続情報が削除できない! しかもQuicksiteのFullAccess権限を付与しても削除できない! 結局AWSサポートに問い合わせしてようやく解決したので備忘録として残します 前提 QuicksiteとデータソースのAWSアカウントは違う QuicksiteのAWSアカウントをQとする 利用したいデータソースのAWSアカウントをAとする 結論 Quicksite上に作成したVPC接続情報を削除するには、下記の権限が必要 ec2:DeleteNetworkInterface quicksight:DeleteVPCConnection 上記の情報はQuicksiteのドキュメントに記載なし IAMポリシーのビジュアルエディタでは設定不可 ただしIAMポリシーのJSONを直接編集すれば設定できる やりたいこと Quicksiteから、他アカウントのデータソースを参照したい Quicksite上に設定したVPC接続情報を作成or削除したい やったこと アカウントQとアカウントAをVPCピアリングで接続(こちらを参照ください)) IAMポリシーのJSONを直接編集し、下記権限を付与(付与前に警告が表示されますが無視してください) { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ -- 削除用 -- "quicksight:DeleteVPCConnection", "ec2:DeleteNetworkInterface", -- 作成用 -- "quicksight:GetVPCConnection", "quicksight:CreateVPCConnection", "ec2:CreateNetworkInterface" ], "Resource": "*" } ] } 参考 QuickSightから別アカウントにあるプライベートRedshiftに接続する(VPCピアリング編)
- 投稿日:2022-02-25T00:39:28+09:00
Lambdaの実行環境について(コールドスタートとウォームスタート)
はじめに 昨年、awsブログにてOperating Lambdaシリーズの翻訳版が公開された。 Lambdaを使う開発者にとっては知っておくべきことが詰まったこのブログ、3本から構成されています。今回はその内容から一部抜粋してLambdaのコールドスタートとウォームスタートについて取り上げまとめてみましたという記事です。 コールドスタートとレイテンシー、そしてウォームスタート 下記の図は、Lambdaの関数実行のrequestを受け取ってから、ハンドラ関数実行までの流れを表しています。 Lambdaは、Lambda APIを介して関数実行された時次のような動作をします。 1: S3バケットから実行するコードのダウンロードを行ったり、コンテナパッケージを使用している場合はECRよりダウンロードします。 2: 指定されたメモリ、ランタイム及び各種設定に基づいた環境を作成します。 3: Lambdaのハンドラ関数外の初期化コードを実行します。 4: Lambdaのハンドラ関数の実行 Lambdaにおけるコールドスタートはこのコード準備と環境準備のステップです。 lambdaがコールドスタートするのは有名だと思いますし、課金対象もこのコールドスタートで起きる最初の環境準備は含まれません。 実は、lambdaは必ずしもコールドスタートで始まるわけではありません。 Lambdaの実行が完了した後、Lambdaは実行環境を不特定期間保持します。 その為、この時同じ関数にリクエストがあった場合、Lambdaは環境の再利用を行うのです。 これは、これはコールドスタートとは異なり、コールドスタートされていたステップ(コード準備と環境作成)が省略されるので、ウォームスタートとなります。 実行環境のライフサイクル Lambdaは、関数実行後、その環境をすぐ破棄することなく保持します。 ただ、この環境破棄までの期間を指定することはできません。 またLambdaのウォームスタートをパフォーマンスの最適化とし、ウォームスタート依存するのはよくありません。 => なぜならば、LambdaがAZに跨って実行を管理するサービスだからです。 その為、実行されたLambdaがその後ウォームスタートすると思いきや、コールドスタートになるという可能性も考えられます。 => さらに、Lambdaがスケールアップされる際に関数の追加が発生したとします。そうすると、その場合においても新たな実行環境の作成が行われるので、追加分の関数についてはコールドスタートになります。 => また、コードの更新や、関数の設定変更等を行い新しいバージョンのコードのみが使用されるようエイリアス設定されている場合は、実行している既存の環境は破棄されます。この場合もコールドスタートになります。 Lambdaを定常でウォームスタートされるために方法(EventBridgeを使い1分ごとに関数の呼び出しをpingで行う方法)もあるようだが、公式ブログ内ではこの方法だとコールドスタートを減らす保証がないことが記載されています。 パフォーマンスの最適化 Lambdaにおける機能にProvisioned Concurrencyがあります。これを使用すると、コールドスタートの削減につながります。 Provisioned Concurrencyの機能とは、事前に同時実行環境を準備しておく機能です。 準備される範囲としては、コードの準備、環境の作成、ハンドラ外の初期化コードの実行までを事前に構築実行しておきます。 これにより解決する課題は、2つで、初期リクエストに関して完全にコールドスタートとなりレイテンシーが大きくなる課題と、スパイクなリクエストが来た時にスケーリングが追いつかない課題です。 まあ、その分料金がProvisioned Concurrency料金 + リクエスト料金 + コンピューティング料金となるので、そこが注意点です。 引用元
- 投稿日:2022-02-25T00:19:06+09:00
AWS認定 ソリューションアーキテクト – プロフェッショナル (AWS Certified Solutions Architect - Professional) に合格した
1. 初めに 「AWS認定 ソリューションアーキテクト – プロフェッショナル」の資格が失効してしまった。プレゼンする時の自己紹介スライドなどで、有識者を装うためにロゴを載せたいので、改めて資格取得にチャレンジすることとした。特別なことはしていないが、何かの参考のため対策方法を記録しておきたい。 2. 勉強法 2.1 先人の体験記 まずは合格体験記で勉強の仕方の流れを確認するとともに、「自分も取るぞ」というモチベーションを高めた。 AWSソリューションアーキテクト プロフェッショナル (SAP-C01)に合格 最近の記事であり、勉強用のサイトやツール(模擬試験、書籍、Udemyなど)の評価も参考になった。 【最速】既婚子持ち社会人のクラウド初心者でも、1ヶ月半でAWS資格11冠制覇できる方法 「出題内容の細かいところまで追求して完全に理解しようとはせず、ある程度のところで割り切りが必要」との考えに共感できた。SAPは出題範囲が広いので、「実環境で設定含め動作検証してみよう」は諦めて、「問われている概念を理解できたらOK」に留めるようにした。 2.2 サンプル試験問題/模擬試験 次にサンプル試験問題/模擬試験を実施し、どれくらいハードルが高そうかを確認。「それなりに難しくはあるが、問題と解説を読んで、言ってることは理解できるレベルなので、頑張って勉強すればまあ大丈夫そうかも」であることを確認。 サンプル試験問題(リンクはこちら) 10問しかないが、解説もついているため、一通り内容確認し、問題のレベル感を確認した。 模擬試験 サイトへの登録方法などは、Developers.IOの記事「ななななんと!AWS認定の模擬試験が無料になりました!!」を参照。 問題にたどり着くまでの道のりが長い(Skill Builderのサイト経由でBenchprepのサイトへ)が、無料で解説付きの20問あり。 こちらも一通り実施。常に同じ問題が出題されるため、学習のためというよりは試験の内容・レベル感の確認目的。 2.3 参考書 現在(2022/2時点)で出版されている試験対策書を2冊とも利用した。 AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説 全て問題形式となっており内容に無駄もなく、回答の解説(なぜ不正解なのかなど)も詳細に記載されているため、非常に参考になった。 各章の練習問題及び最後の模擬試験について、全て正答するまで繰り返し実施。 AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル 比較的最近(2021/10)出版されたため、新しめのサービス(例:Snowシリーズとか)についても取り上げられていたり、図解が多かったりする反面、問題文の内容が少しフランク?で本番と違う感じだったり、誤植があったりと一長一短あり。 上の本とは問題の取り揃えも異なるため、こちらの本の模擬試験問題についても全て正答するまで繰り返し実施。 2.4 Udemy とにかく長文問題に慣れるのが大事と思い、以下の2つを実施した。 AWS Certified Solutions Architect Professional Practice Exam 受講者数・評価からこちらを選択。 25問×6セットで十分な量がある。解説についても「選択肢1)は不正解。なぜならばXXだから。」のように、不正解の選択肢全てに理由説明されているので、「そうだったのか」という理解につながりやすかった。 ほぼ全て正解になるまで繰り返し実施。 AWS 認定ソリューションアーキテクト プロフェッショナル模擬試験問題集(全5回分375問) 唯一の日本語問題集ということでこちらも実施。 75問x5セットということでかなりの量がある。他の問題集と比較して「やや問題が細かめの内容で、難しめかな?」という印象。一通り実施はしたが、全てを正解するまでやりこむのは断念してしまった。 3. 受験 結果: 合格(814点) ※750点以上合格 「全然分からない、、」というのは数問だった気がするが、あまり余裕のある合格点ではなかった。。 4. 所感 本来、実機での動作確認を行い、知識の定着を図るべきとも思うが、今回はあまり時間の余裕がなく問題集中心の学習となってしまった。また別の試験(Specialty系)の時は勉強時に実機での動作確認も行い、実戦的な能力の向上を図りたい。 試験対策を通じて、苦手な分野(SAMLとかの認証系、code兄弟とかのCI/CD系など)が再確認できたため、そのあたりをフォローできるようにしていきたい。
- 投稿日:2022-02-25T00:13:20+09:00
AWS Lambda Layersを使ったPythonライブラリーの追加
はじめに Lambda関数でサードパーティのライブラリーを使用したいときは、下記のいずれかの方法を使って、対象のライブラリーを追加する必要がある。 追加したいライブラリーを含んだパッケージデプロイ Lambda Layersを使って追加 今回は「Lambda Layersを使って追加」についてまとめていく。 Lambda Layersを使った追加方法 環境 Windows / Mac Dockerが使えること。 ここではDockerのインストール方法は省略するが、ローカルの場合はDocker Desktopを使うと簡単。 Linuxサーバー等にインストールする場合は下記記事記事を参照。 https://qiita.com/subretu/items/549bc720165004bca3c3 やってみて分かったこと Layerにアップロードするライブラリーは、AmazonLinux環境で作成しないと読み取ってくれないことが分かった。 WindowsやMacのローカル環境で、pipを使ってインストールしたライブラリーをLayerに追加しても正常に読み取ってくれなかった。 他のLinux環境では試していないので、もしかしたらそちらでも可能かもしれない(未検証) そこで、「docker-lambda」というLambda環境を構築できるDockerコンテナを利用してライブラリーを作成することでうまくいったので、次章ではその方法についてまとめていく。 docker-lambdaについては下記を参照。 https://github.com/lambci/docker-lambda https://hub.docker.com/r/lambci/lambda/ docker-lambdaを使ったライブラリーファイルの作成 requirements.txtに必要なライブラリーを記載する。 下記コマンドを実行。 初回だけイメージpullに時間がかかるが、2回目以降はしないので早くなる。 作成するフォルダ名は「python」にしないといけないみたい。 これについては諸説あるみたいだが、「python」とするとうまくいった。 Pythonのバージョンは例として3.8とした。 どのバージョンをサポートしているかは上記に記載したURLを参照。 docker run --rm -v "$(PWD):/var/task" lambci/lambda:build-python3.8 pip install -r ./requirements.txt -t python/lib/python3.8/site-packages/ カレントディレクトリに「python」フォルダができているのでzipファイルにする。 Layerを追加 Lambdaのページを開き、「レイヤー」で追加したいライブラリーを含んだレイヤーを作成する。 zipファイルが10Mを超える場合はS3経由のアップロードになるので注意すること。 レイヤーを作成後は、Lambda関数の「レイヤーを追加」で対象のレイヤーを追加する。 「ARNを指定」を選び、追加したレイヤーのARN貼り付ける。 正常にレイヤー追加されると、下記のように一覧に追加したレイヤーが表示される。 その後は通常通り、import XXXXXでライブラリーをimportして使用することができる。