0.はじめに お名前.comで取得したドメインをRoute53に登録します。 こちらも前回同様そんなに難しくないので、登録までは時間かかりませんが、 反映までに最大で72時間かかる場合があります。 1.前回のタスク 【AWS環境構築メモ①】お名前.comで独自ドメイン取得する 2.前提条件 AWSアカウント作成済み お名前.comでドメイン取得済み 3.登録手順(サマリー) 順番 手順 1 Route53のホストゾーン作成 2 NSレコードを確認 3 NSレコードの情報をお名前.comに登録する 4 反映の確認 4.登録手順 1.Route53のホストゾーン作成 AWSコンソール にログインする サービスよりRoute 53を選択して、ダッシュボードのホストゾーンをクリックする ホストゾーンの作成をクリックする 管理したいドメイン名を指定する。 ドメイン名 : お名前.comで取得したドメイン名を入力 説明 : 任意(入力なしでもOK) Type : パブリックホストゾーンを指定 ホストゾーンの作成をクリックする ホストゾーンが作成されます 2.NSレコードを確認 ホストゾーンにて、登録したドメイン名をクリックする レコードにて、表示されたNSレコードを確認 (NSレコード4点とSOAレコード1点が表示される) NSレコード４点をメモする。 3.NSレコードの情報をお名前.comに登録する お名前.comにログインする TOPをクリックして、対象ドメインのネームサーバー[初期設定]をクリックする 画像では[その他]となってますが、初期設定時は[初期設定]と表示されます。 対象ドメインの確認をする(間違いないか) 2.ネームサーバーの選択で[その他のサービス]を選択 ネームサーバーの入力フォームに、先程メモしたRoute53のNSレコード４点を入力する ([.]は省いてもかまいません) 確認ボタンをクリックする 設定の確認画面が表示されるので、対象ドメイン名とネームサーバー情報を確認して、OKをクリックする。 「完了しました」とメッセージが表示されたら設定操作は完了 4.反映の確認 ネームサーバーがRoute53に切り替わっているかどうか確認する nslookupコマンドで確認できる 設定した4つの値が表示されれば成功 反映には最大で72時間かかる場合があるので、時間が経ってから確認してみましょう。 nslookup -type=NS [対象ドメイン] Server: 192.168.0.1 Address: 192.168.0.1#53 Non-authoritative answer: [対象ドメイン].com nameserver = [ネームサーバー1] [対象ドメイン].com nameserver = [ネームサーバー2] [対象ドメイン].com nameserver = [ネームサーバー3] [対象ドメイン].com nameserver = [ネームサーバー4] Authoritative answers can be found from: 5.最後に これでRoute53に独自ドメインを登録できました。 次回はVPCの設定をしていきます。 次回 :【AWS環境構築メモ③】VPCの作成 6.参考

0. はじめに 前回の記事では，ParallelClusterの立ち上げとログインまでを扱いました．そちらをご覧になっていない方は，下記「シリーズの流れ」にリンクを記載していますので，参考にしてください．今回は，ParallelCluster上でのFrontISTR実行について，ジョブスケジューラであるSlurmの使い方・ジョブスクリプトの書き方を中心に見ていきます． 1. シリーズの流れ ParallelCluster バージョン3用のカスタムAMIの作成 ParallelCluster バージョン3用の設定ファイルの作成〜起動 Slurmを利用したFrontISTR並列実行 (この記事) 2. ログイン〜領域分割 前回の記事に沿って，クラスタの作成とログインを行います． 設定ファイル「v3.1.2-FrontISTR.yaml」を利用して，「FrontISTR-cluster」という名称のクラスタを作成するコマンドは次の通りです． pcluster create-cluster -n FrontISTR-cluster -c v3.1.2-FrontISTR.yaml 作成が完了したのを確認したら，ヘッドノードにログインします(ここではpcluster sshコマンドを利用します)． pcluster ssh -n FrontISTR-cluster -i PRIVATE_KEY 子ノード(計算資源)との共有ディレクトリとして「/shared」を指定したので，そちらに移動し，例題となるモデル(サポートリポジトリ)をGitLabから持ってきます(書籍p. 235と同じ内容です)． cd /shared git clone https://gitlab.com/FrontISTR-Commons/nonlinearparallelfem.git cd nonlinearparallelfem/SampleModels/OpenTool 並列計算をするに当たり，モデルの領域分割を行います．今回は比較的小さいものですので，ジョブを投げる(=子ノードを立ち上げる)ことなく，その場で実行します． hecmw_part1 ここでは，領域分割したメッシュを別のディレクトリに格納するよう設定しています1ので，「MESH」というディレクトリが作成されます． $ ls frontistr.job hecmw_part_ctrl.dat MESH mesh.inp hecmw_ctrl.dat hecmw_part.log mesh.cnt ucd.inp $ ls MESH mesh.dist.0 mesh.dist.2 mesh.dist.30 mesh.dist.41 mesh.dist.52 mesh.dist.63 mesh.dist.1 mesh.dist.20 mesh.dist.31 mesh.dist.42 mesh.dist.53 mesh.dist.64 mesh.dist.10 mesh.dist.21 mesh.dist.32 mesh.dist.43 mesh.dist.54 mesh.dist.65 mesh.dist.11 mesh.dist.22 mesh.dist.33 mesh.dist.44 mesh.dist.55 mesh.dist.66 mesh.dist.12 mesh.dist.23 mesh.dist.34 mesh.dist.45 mesh.dist.56 mesh.dist.67 mesh.dist.13 mesh.dist.24 mesh.dist.35 mesh.dist.46 mesh.dist.57 mesh.dist.68 mesh.dist.14 mesh.dist.25 mesh.dist.36 mesh.dist.47 mesh.dist.58 mesh.dist.69 mesh.dist.15 mesh.dist.26 mesh.dist.37 mesh.dist.48 mesh.dist.59 mesh.dist.7 mesh.dist.16 mesh.dist.27 mesh.dist.38 mesh.dist.49 mesh.dist.6 mesh.dist.70 mesh.dist.17 mesh.dist.28 mesh.dist.39 mesh.dist.5 mesh.dist.60 mesh.dist.71 mesh.dist.18 mesh.dist.29 mesh.dist.4 mesh.dist.50 mesh.dist.61 mesh.dist.8 mesh.dist.19 mesh.dist.3 mesh.dist.40 mesh.dist.51 mesh.dist.62 mesh.dist.9 3. Slurmコマンド 領域分割が完了したら，いよいよソルバの実行になります．ここではまず，ジョブスケジューラであるSlurmの主要コマンドについて，実行例と共に見ていきます．Slurm公式ドキュメントの他，以下のサイトが参考になります． FOCUS モナシュ大 スタンフォード大 ペンシルベニア大 3.1. ジョブの投入 ジョブの投入はsbatchコマンドです．ジョブスクリプトを指定します．ジョブIDが返ってきます． $ sbatch v3.1.2-frontistr.job Submitted batch job 3 3.2. ジョブの削除 ジョブの削除はscancelコマンドです．ジョブIDを指定します．リターンはありません． $ scancel 3 3.3. ジョブ情報の表示 ジョブの情報はsqueueコマンドで表示します．SGEと異なり，経過時間2も表示されます． $ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 3 queue OpenTool ec2-user CF 0:03 2 queue-dy-compute-resource-[1-2] $ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 3 queue OpenTool ec2-user R 0:06 2 queue-dy-compute-resource-[1-2] ST欄に表示される状態については，上に載せたFOCUSのページに詳しく書かれています．ノード確保中のCF，実行中のRの他には，確保に失敗した際のPDや削除後のCGを比較的目にすると思われます．一番右のNODELISTについては次の3.4.を参照してください． 3.4. ノード情報の表示 利用しているノードの情報はsinfoコマンドで表示します．オプション-Nを付けると，各ノードが個別の行で，-sを付けると，全ノードをまとめた形で状態ごとのノード数が表示されます． $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST queue* up infinite 2 alloc~ queue-dy-compute-resource-[1-2] queue* up infinite 8 idle~ queue-dy-compute-resource-[3-10] $ sinfo -N NODELIST NODES PARTITION STATE queue-dy-compute-resource-1 1 queue* alloc~ queue-dy-compute-resource-2 1 queue* alloc~ queue-dy-compute-resource-3 1 queue* idle~ queue-dy-compute-resource-4 1 queue* idle~ queue-dy-compute-resource-5 1 queue* idle~ queue-dy-compute-resource-6 1 queue* idle~ queue-dy-compute-resource-7 1 queue* idle~ queue-dy-compute-resource-8 1 queue* idle~ queue-dy-compute-resource-9 1 queue* idle~ queue-dy-compute-resource-10 1 queue* idle~ $ sinfo -s PARTITION AVAIL TIMELIMIT NODES(A/I/O/T) NODELIST queue* up infinite 2/8/0/10 queue-dy-compute-resource-[1-10] 上の例の場合は，1・2番の2ノードを利用しているということになります．全体が10ノードなのは，ParallelCluster バージョン3での最大ノード数のデフォルト値が10であるためです．なお．ここで表示されるallocはあくまでも「10の内使用する2を設定しました」のような意味合いであり，実機を確保できているとは限りません．実機の確保に失敗した場合は，allocが再びidleとなり，別の番号のノードで確保を試みます． 4. Slurm用ジョブスクリプトの書き方 サポートリポジトリでは，SGE用のジョブスクリプト frontistr.job が提供されています．こちらをSlurm用に書き換えていきます． SGEとSlurmとの対応については，先にも挙げたモナシュ大，スタンフォード大，ペンシルベニア大のページが参考になります．特にモナシュ大のページでは，様々な並列計算の場合について紹介されています．また，FOCUSのページ(他節)も，比較はありませんが良い日本語資料となっています(以下，断りなくこれらを参照します)． 4.1. SGE用のものを書き換える こちらが，サポートリポジトリに掲載されている元のジョブスクリプトです．上から順に書き換えていきましょう． frontistr.job #!/bin/sh #$ -cwd #$ -N OpenTool #$ -pe mpi 72 #$ -j y source ~/.bashrc export OMP_NUM_THREADS=1 mpirun -np 72 fistr1 > out.log L. 2 #$ -cwd 現在のワーキングディレクトリへの移動を示します．Slurmではデフォルトの挙動ですので，対応するコマンドは存在しません． L. 3 #$ -N OpenTool ジョブの名称設定です．Slurmでは#SBATCH -J JOB_NAMEと書きます． L. 4 #$ -pe mpi 72 MPI並列数の設定です．Slurmでは#SBATCH --ntasks <num_procs>もしくは#SBATCH -n <num_procs>と書きます． L. 5 #$ -j y 標準出力と標準エラー出力を1つのファイルにまとめる設定です．Slurmでは標準出力のみを指定することで同様の結果を得ます． L. 11 mpirun -np 72 fistr1 > out.log FrontISTRの並列実行を示します．並列数は決め打ちでも良いですが，Slurmでは環境変数$SLURM_NTASKSを利用して取得することができます． これらを踏まえて書き直すと，以下のジョブスクリプトが完成します．名称は元のファイルにならい「v3.1.2-frontistr.job」としています． v3.1.2-frontistr.job #!/bin/sh #SBATCH -J OpenTool #SBATCH -n 72 source ~/.bashrc export OMP_NUM_THREADS=1 mpirun -np $SLURM_NTASKS fistr1 > out.log 前項で扱ったコマンドを用い，実行させます． sbatch v3.1.2-frontistr.job すると，計算開始後すぐに終了してしまいました．明らかに失敗しているのでout.logを確認すると，下に示す内容が36行(1ノード分)続いていました． out.log MPI startup(): PMI server not found. Please set I_MPI_PMI_LIBRARY variable if it is not a singleton case. MPI startup(): PMI server not found. Please set I_MPI_PMI_LIBRARY variable if it is not a singleton case. ... どうやら"PMI"というものでエラーになってしまったようです． 4.2. 並列実行部分を修正する どうもSlurmでのmpirunコマンドの利用に問題がありそうなので，Intel MPIの利用について，Slurmのドキュメントを参照します．すると，mpirunコマンド自体は利用できるようですが，別にプロセスマネージャの利用・指定が必要なことが分かります．また，推奨されているのはsrunコマンドを利用した方法ですので，こちらに切り替えます． srunコマンドを利用するにはまず export I_MPI_PMI_LIBRARY=/path/to/slurm/pmi/library/libpmi.so としてPMI (Process Management Interface)のライブラリを指定する必要があります．このlibpmi.soという共有オブジェクトですが，「slurm libpmi.so」と検索すると，場所に関するGitHubのIssue3が出てきました．これを基に/opt/slurm/lib内を探したところ，確かに存在しましたので，値として設定します． srunコマンドの例は srun -n <num_procs> a.out と示されています． これらを踏まえてv3.1.2-frontsitr.jobを書き直します．下3行が更新箇所です． v3.1.2-frontistr.job #!/bin/sh #SBATCH -J OpenTool #SBATCH -n 72 source ~/.bashrc export OMP_NUM_THREADS=1 export I_MPI_PMI_LIBRARY=/opt/slurm/lib/libpmi.so srun -n $SLURM_NTASKS fistr1 > out.log 再びジョブスクリプトを投入します． sbatch v3.1.2-frontistr.job 投入後にsqueue，sinfoコマンドを利用すると，前項のような出力を得られます．その他にも，ノードの情報を表示するコマンドとしてscontrol，ジョブの情報を表示するコマンドとしてsstatなどがあります． $ scontrol show nodes NodeName=queue-dy-compute-resource-1 Arch=x86_64 CoresPerSocket=1 CPUAlloc=36 CPUTot=36 CPULoad=1.04 AvailableFeatures=dynamic,c5n.18xlarge,compute-resource,efa ActiveFeatures=dynamic,c5n.18xlarge,compute-resource,efa Gres=(null) NodeAddr=10.0.1.76 NodeHostName=queue-dy-compute-resource-1 Version=21.08.6 OS=Linux 4.14.268-205.500.amzn2.x86_64 #1 SMP Wed Mar 2 18:38:38 UTC 2022 RealMemory=1 AllocMem=0 FreeMem=179437 Sockets=36 Boards=1 State=ALLOCATED+CLOUD ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A Partitions=queue ... NodeName=queue-dy-compute-resource-2 Arch=x86_64 CoresPerSocket=1 CPUAlloc=36 CPUTot=36 CPULoad=1.00 AvailableFeatures=dynamic,c5n.18xlarge,compute-resource,efa ... $ sstat 3 JobID MaxVMSize MaxVMSizeNode MaxVMSizeTask AveVMSize MaxRSS MaxRSSNode MaxRSSTask AveRSS MaxPages MaxPagesNode MaxPagesTask AvePages MinCPU MinCPUNode MinCPUTask AveCPU NTasks AveCPUFreq ReqCPUFreqMin ReqCPUFreqMax ReqCPUFreqGov ConsumedEnergy MaxDiskRead MaxDiskReadNode MaxDiskReadTask AveDiskRead MaxDiskWrite MaxDiskWriteNode MaxDiskWriteTask AveDiskWrite TRESUsageInAve TRESUsageInMax TRESUsageInMaxNode TRESUsageInMaxTask TRESUsageInMin TRESUsageInMinNode TRESUsageInMinTask TRESUsageInTot TRESUsageOutAve TRESUsageOutMax TRESUsageOutMaxNode TRESUsageOutMaxTask TRESUsageOutMin TRESUsageOutMinNode TRESUsageOutMinTask TRESUsageOutTot ------------ ---------- -------------- -------------- ---------- ---------- ---------- ---------- ---------- -------- ------------ -------------- ---------- ---------- ---------- ---------- ---------- -------- ---------- ------------- ------------- ------------- -------------- ------------ --------------- --------------- ------------ ------------ ---------------- ---------------- ------------ -------------- -------------- ------------------ ------------------ -------------- ------------------ ------------------ -------------- --------------- --------------- ------------------- ------------------- --------------- ------------------- ------------------- --------------- 3.0 213503982+ 0 0 Unknown Unknown Unknown 0 今度は何十分か経ってから終了しました．可視化ファイルも問題なく出力されています． $ ls vis_out mesh_vis_psf.0000.inp mesh_vis_psf.0002.inp mesh_vis_psf.0005.inp mesh_vis_psf.0009.inp mesh_vis_psf.0001.inp mesh_vis_psf.0003.inp mesh_vis_psf.0008.inp mesh_vis_psf.0010.inp out.logより，正常に実行・終了したことを確認します． out.log ################################################################## # FrontISTR # ################################################################## --- version: 5.3 git_hash: 5db1d80452b951905658da828285c2fd0537603c build: date: 2022-03-09T10:01:41+0000 MPI: "3.1, Intel MPI 2021.4.0" OpenMP: 201511 option: "-p --with-tools --with-metis --with-mumps --with-lapack --with-ml --with-parmetis --with-mkl " HECMW_METIS_VER: 5 execute: date: 2022-03-16T04:44:36+0000 processes: 72 threads: 1 cores: 72 MPI: "3.1, Intel(R) MPI Library 2021.4 for Linux* OS" host: 0: queue-dy-compute-resource-1 1: queue-dy-compute-resource-1 2: queue-dy-compute-resource-1 ... 70: queue-dy-compute-resource-2 71: queue-dy-compute-resource-2 --- fstr_setup: OK loading step= 1 sub_step= 1, current_time= 0.0000E+00, time_inc= 0.1800E+03 loading_factor= 0.0000000 1.0000000 ... iter: 5, residual: 9.5416E-01, disp.corr.: 6.2839E-04 ### FSTR_SOLVE_NLGEOM FINISHED! ==================================== TOTAL TIME (sec) : 4845.84 pre (sec) : 1.29 solve (sec) : 4844.55 ==================================== FrontISTR Completed !! 5. ちょっとした補足 メッシュのサイズが大きい場合には領域分割もジョブとして投入する必要があります．ヘッドノードではメモリ不足になります． 子ノードがいつまでも確保できないなど，Slurmでエラーが発生した場合は，/var/log/parallelcluster/slurm_resume.logを参照します．中を見てはじめて，アベイラビリティーゾーン内に資源がないため失敗したことが分かった，という経験があります． エラーについての参考↓ 前の記事: FrontISTRをAWS ParallelCluster バージョン3で利用する② この辺りの詳細はFrontISTRのマニュアルをご覧ください． ↩ それぞれの状態(ST)ごとに0からカウントされます．実行時間はジョブ投入からの経過時間ではありません． ↩ https://github.com/aws/aws-parallelcluster/issues/1008 ↩

はじめに 他人が書いたCloudFormationのyamlコードの動作確認をしたところ、以下のエラーが出力しました。 1 validation error detected: Value '[AWS::EC2::VPC, AWS::EC2::RouteTable,AWS::EC2:Route, ...＜略＞]' at 'typeNameList' failed to satisfy constraint: Member must satisfy constraint: [Member must have length less than or equal to 204, Member must have length greater than or equal to 10, Member must satisfy regular expression pattern: [A-Za-z0-9]{2,64}::[A-Za-z0-9]{2,64}::[A-Za-z0-9]{2,64}(::MODULE){0,1}] これまた些細なことなのですが、10分以上解決に時間がかかりました。。。 原因 AWS::EC2:Routeになっていた。 正しくはAWS::EC2::Route。 コメント 最近こんなのばかり。。。 CloudFormationは便利だけれど、エラーメッセージが雑？で辛いときがあります。 Value '[AWS::EC2::VPC, AWS::EC2::RouteTable,AWS::EC2:Route, ...<略>]'のエラーメッセージ、Value '[AWS::EC2:Route]のように問題の箇所だけ抜き出して表示できないのかなあ。サービスを大量に定義しているコードだったため、問題の箇所が埋もれてしまってどれも正しいように見えてました。

0.はじめに AWSで本番環境構築するに当たり、お名前.comで独自ドメインを取得してみたことを書いてみました。 とても簡単なので、誰でも簡単に取得できます。多分。 あくまでもメモなので、詳しい説明等は参考にした記事などをご紹介する形で記載します。 1.ドメイン取得手順(サマリー) 順番 手順 1 取得したいドメイン名を決める 2 お申込み内容確認、メールアドレス、パスワード入力 3 会員情報登録 4 支払い方法選択 5 申し込み完了 6 メール確認 2.ドメイン取得手順 1.取得したいドメイン名を決める お名前.com にアクセス ページ中央の「取得希望の文字列を入力」部分に、取得したいドメイン名を入力 入力し終わったら検索ボタンを押す ドメイン入力の際は、.com .jpなどの選択は不要です。 ドメイン一覧から取得したいドメインにチェックをする(.comとか.jpとか色々あります) 選択した商品の欄で、取得したいドメインを確認して、お申込みへ進む 2.お申込み内容確認、メールアドレス、パスワード入力 お申し込み内容 Whois情報公開代行 1年登録でOK Whois情報公開代行メール配信オプション ドメインプロテクション チェックなしのままでOK メールアドレス、パスワードを入力して次へ(画面右上) Whois情報公開代行については以下の記事をご参考↓ Whois情報公開代行をやさしく説明！意味・費用・設定方法を徹底解説！ 3.会員情報登録 訳あって画像は無いです 必須項目はすべて入力してください 記入し終えたら「次へ」を押す 4.支払い方法選択 訳あって画像は無いです 支払い方法を以下の３つから選び、必要事項を入力 クレジットカード 銀行振込み コンビニ決済 申し込むを押します クレジットカード払いだと、ドメイン取得後すぐに取得したドメインが使えるみたいです。 5.申し込み完了 申し込むを押した後、「お名前.comのレンタルサーバー」 の申し込み画面がでてきますが、 私は必要無かったので申し込みませんでした。有料だし。 以上でドメイン取得の申し込みは完了です。 6.メール確認 上の画像のように、 ドメイン登録　料金ご請求/領収明細 ドメイン自動更新　設定完了 Whois情報公開代行　完了通知 ドメイン登録　完了通知 会員情報変更　完了通知 のメールが通知されていることを確認してください。 通知が来たら、内容を確認してください。 ドメイン取得完了 以上で独自ドメイン取得完了です。 そんなに難しい作業では無かったので、おそらく5~10分で終わると思います。 次回は、取得したドメインをRoute53に登録します。 次回 ： 【AWS環境構築メモ②】お名前.comで取得したドメインをRoute53に登録する 参考

そもそもなんでタグ付けする必要あるの 一番のメリットとしてはコストをグループ化できるというところにあると思います。 システムの規模が大きくなれば大きくなるほど、どのプロジェクトで何のコストが発生し、結果このような料金になっているかの説明がしにくくなっていきます。 規模が小さいうちにタグ付けのルールを決めて付与してあげることで、プロジェクト単位や使用ユーザ単位などでコストを確認できるのです！！ AWSタグエディター タグエディタを使用することにより特定のタグが付いているリソースを検索したり、逆にタグがついていないリソースにまとめてタグを付与できたりします。 GUIで使うので誰でもわかりやすく操作できるでしょう AWS CLIでタグ付与 タグエディタでタグを付与する際、タグ付けルールが細分化されてなければいいのですが、一つずつ違うタグをつけたい時などがあると思います。 その場合は下記コマンドを利用したほうが良いです。 実行結果としてFailedResourcesMapが返ってきますが、{}に何も入っていない場合は正常です。 例: aws resourcegroupstaggingapi tag-resources --resource-arn-list 【ARN】 --tags 【key】=【value】 aws resourcegroupstaggingapi tag-resources --resource-arn-list 【ARN】 --tags 【key】=【value】,【key】=【value】 実行結果： [cloudshell-user@ip-10-1-130-113 ~]$ aws resourcegroupstaggingapi tag-resources --resource-arn-list arn:aws:ec2:ap-northeast-1:9999999999:instance/i-999999999999999 --tags PJ=APP { "FailedResourcesMap": {} } [cloudshell-user@ip-10-1-130-113 ~]$

はじめに 　Lambdaでは、DynamoDB Streamsでデータの変更を検知して実行することができます。以前は、変更のたびに毎回Lambdaが実行され、Lambdaのコード内で追加、更新、削除を判断して処理を行う必要がありました。この方法では、毎回Lambdaが実行されるため、その分、費用がかかる状態でした。 　それが2021年11月のアップデートでLambda実行前に処理を実行するかどうかフィルタリングすることができるようになり、コードの簡略化や不要な実行がなくなり費用も低減できます。 　今回は、実際にフィルタリングを設定し、実行してみます。 事前準備 　トリガーとなるDynamoDBのテーブルを作成し、ストリームを有効化しておきます。その後、ストリームARNをコピーしておきます。 Lambda Functionを作成する 　今回は、pythonでログを出力するだけの処理で確認します。実際には、DynamoDBのテーブルにレコードが追加されたら、「管理者、ユーザに通知する」、「分析用のテーブルにレコードを追加する」等のユースケースで利用することがあるかと思います。 基本設定 Lambda Functionのソース index.py import json def lambda_handler(event, context): print("Received event: " + json.dumps(event)) for record in event['Records']: print(record['eventID']) print(record['eventName']) print("DynamoDB Record: " + json.dumps(record['dynamodb'])) return 'Successfully processed {} records.'.format(len(event['Records'])) #　アクセス権限 　Lambda Functionのアクセス権限には以下の通り、DynamoDB Streamsへのアクセス権限が必要なります。※ポリシー抜粋 ロールに付与されたポリシー { "Action": [ "dynamodb:GetRecords", "dynamodb:GetShardIterator", "dynamodb:DescribeStream", "dynamodb:ListStreams" ], "Effect": "Allow", "Resource": [ "arn:aws:dynamodb:[リージョン]:[アカウントID]:table/[テーブル名]/stream/[ストリームID]" ] } トリガー 　トリガーにDynamoDBを設定します。フィルタリング条件については後述します。 フィルタリング条件の設定 　トリガー設定にあるフィルタリング条件を追加し、Lambda Functionを実行したい条件を設定します。 「追加」の場合に実行する insert { "eventName": ["INSERT"] } 「更新」の場合に実行する update { "eventName": ["UPDATE"] } 「削除」の場合に実行する delete { "eventName": ["DELETE"] } 細かいフィルタールールについては、以下を参考すると良いです。 トリガーを確認する 　設定したトリガーを確認します。追加したフィルタリング条件が設定されていることがわかります。 ご注意 作成された以下のフィルタリング条件をそのままコピーして作成しようとするとエラーになります。 ↓エラー。恥ずかしながらハマってました。。 ↓正解はこっちです。 動きを確認する 　では、実際に動かしてみます。以下が既存のテーブルです。 レコードを追加します。 Lambda Functionのログが以下の通り、出力されています。 次にレコードの削除を行なってみます。 Lambda Functionのログが以下の通り、出力されていません。 メトリクスも見てみます。Invocationsのカウントが1です。 おまけ（CLoudFormationテンプレート） 　ここまで手動でやってきましたが、やはり手早く使いたい方もいるかと思いますので、CloudFormationテンプレートを載せておきます。レコードが追加された場合に実行されるサンプルになります。 lambda-filtering.yaml AWSTemplateFormatVersion: '2010-09-09' Description: 'Filtering event sources for AWS Lambda functions' # Parameters Parameters: DynamoDBStreamsArn: Type: String MinLength: 1 # Resources Resources: # Role ExecutionRole: Type: AWS::IAM::Role Properties: RoleName: !Sub '${AWS::StackName}-execution-role' AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: - sts:AssumeRole Effect: Allow Principal: Service: - lambda.amazonaws.com Path: / Policies: - PolicyName: lambda-execution-policy PolicyDocument: Version: 2012-10-17 Statement: - Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Effect: Allow Resource: - !Sub 'arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/${AWS::StackName}-*' - Action: - dynamodb:GetRecords - dynamodb:GetShardIterator - dynamodb:DescribeStream - dynamodb:ListStreams Effect: Allow Resource: - !Ref DynamoDBStreamsArn # Lambda LambdaFunction: Type: AWS::Lambda::Function Properties: Architectures: - arm64 Code: ZipFile: | import json def lambda_handler(event, context): print("Received event: " + json.dumps(event)) for record in event['Records']: print(record['eventID']) print(record['eventName']) print("DynamoDB Record: " + json.dumps(record['dynamodb'])) return 'Successfully processed {} records.'.format(len(event['Records'])) FunctionName: !Sub '${AWS::StackName}-function' Handler: index.lambda_handler MemorySize: 128 Role: !GetAtt ExecutionRole.Arn Runtime: python3.9 Timeout: 300 # Lambda - EventSourceMapping EventSourceMapping: Type: AWS::Lambda::EventSourceMapping Properties: BatchSize: 100 BisectBatchOnFunctionError: false Enabled: true EventSourceArn: !Ref DynamoDBStreamsArn FilterCriteria: Filters: - Pattern: "{\"eventName\": [\"INSERT\"]}" FunctionName: !Ref LambdaFunction MaximumBatchingWindowInSeconds: 0 MaximumRecordAgeInSeconds: -1 MaximumRetryAttempts: -1 ParallelizationFactor: 1 StartingPosition: LATEST TumblingWindowInSeconds: 0 まとめ 　フィルタリングの設定を行うことでフィルタリングするコードが不要となり、簡略化され、さらに費用が少なくなるのは良いですね。おまけ含めて、ぜひご活用いただければと思います。良いものは使いましょー

AWSで負荷テスト環境を簡単に構築出来るようなので試してみます。 構成 公式から。 フロントにAmplifyが用いられテストシナリオを作成するコンソール画面が提供されます。 実際に負荷をかける環境はECSによって管理されたコンテナから実行されます。コンテナイメージにはコンテナイメージにはTaurusというテストツールが使用されているようです。 コスト こちらも公式から。 負荷テストの実行時間に応じたFargateの従量課金分が多くを占め、維持コストはほぼかかりません。 仮にEC2にテスト環境を構築した場合、厳密にテスト時間だけ起動するという運用は困難ですし、コスト面でも優秀なのではないでしょうか。 使ってみる こちらのデプロイガイドを参照しながら進めていきます。 CloudFormationスタックの作成 デプロイガイドに下記の記載がありますので、マネジメントコンソールにログインした状態でソリューションの起動をクリックします。 CloudFormationの画面が開きます。 デフォルトだとリージョンがバージニア北部になっているので東京に変更しました。 スタックの詳細の指定です。 Console Administrator Name とConsole Administrator Emailの欄だけ入力しました。 負荷テストのコンソールへログインするユーザー名の指定と、ログインパスワードが通知されるメールアドレスを記載します。 スタックオプションの設定です。 特に変更せずに進みます。 確認画面に遷移します。 IAMリソース作成への同意にチェックをする必要がありますので、チェックをしてスタックを作成します。 スタックの作成が開始されます。5分程で完了しました。 テストコンソールからのテスト実行 スタック作成が完了すると、パラメータとして入力したメールアドレス宛に、ログインパスワード、ログインURLが記載されたメールが送られてきます。 記載されたURLにアクセスし、ログイン。 パスワード変更を求められるので変更します。 ログイン出来ました。 テストシナリオを作成していくのですが、その前にテスト対象の環境を用意します。 今回はとりあえずhttpリクエストを受けられれば良いので、apacheがインストールされているAMIからEC2インスタンスを起動しただけの雑な環境をテスト対象としました。 ちなみに、AWSで負荷テストや侵入テストを実施する場合、シナリオによってはAWSへ事前連絡が必要となる事があるのですが、ガイドによると「本ソリューションでネットワークトラフィックが1Gbps未満の場合は連絡不要」との事です。 詳細についてはこちらに書いてあるようなので、AWSで本格的な負荷テストを行う際は確認しておいた方が良いでしょう。 さて、テストシナリオの作成に戻ります。 テストコンソール上部の[CREATE TEST]をクリックします。 シナリオの設定を入力する画面となるので、要件に応じて記載して実行します。 実行するとこのような画面になりました。 画面下部欄の[Amazon CloudWatch Metrics Dashboard]をクリックすると、リアルタイムに状況をウォッチする事が出来るようです。 テスト対象はしょぼいインスタンスタイプで用意したのでまぁまぁエラーがでてますね。 実行が終わるとすぐに結果のサマリーが確認可能となりました。 単体で作成できるテストシナリオはシンプルなものに限られますが、シナリオ作成時[Test Type]にJmeterを選択する事ができ、既存のJmeterの定義を読ませる事ができるようです。 簡単に、従量課金でコスト最適化されたテスト実行環境が構築出来るのは、かなり良いのではないでしょうか。

概要 IAMユーザを使用できるプリンシパルをIPやソースのVPCエンドポイントで絞りたいです。 ※プリンシパル：AWSのリソースに対してアクションやオペレーションを実行できる人、もしくはアプリケーションのこと 図にすると以下となります。 要件を満たすIAM ポリシーを作成する やりたいこと：プログラム経由(CLI、SDK等)のIAMを使うプリンシパルが以下の場合はアクセスを許可したい アカウントAのVPCエンドポイントを経由している 特定のパブリックIP AWSのサービス つまり1 or 2 or 3であればIAMが使えます。 ソースIPを絞りたい場合、こちらの公式ドキュメントを参考にIAMポリシーを作成しました。 また、経由するVPCエンドポイントを絞るのは「StringNotEquals」と「aws:SourceVpce」の組み合わせを使いました。 以下が完成したIAMポリシーです。 { "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:SourceVpce": [ "<アカウントAのVPCエンドポイント>" ] }, "NotIpAddress": { "aws:SourceIp": [ "<アカウントAのEC2のパブリックIP>" ] }, "Bool": { "aws:ViaAWSService": "false" } } } } これは以下の3つのAND条件となります。 アカウントAのVPCエンドポイントを経由していない 特定のパブリックIPではない AWSのサービスではない なぜこんなややこしい書き方をするかというと、 IAMポリシーのConditionに対する評価ロジックはAND条件となるためです。 つまり、この章の初めに記載したOR条件ではポリシーを記述することができず、中学生・高校生の時にやった集合でいうところの対偶(正反対)の条件に書き換える必要がありました。 文字だと分かりにくいため、図にすると以下となります。 検証 念のため、以下の条件で動作検証をしてみました。 Account Aのプライベートサブネット上に存在するEC2へuser Aのクレデンシャルを登録してAccount BのS3へアクセスできる(図のオレンジの経路) Account Aのパブリックサブネット上に存在するEC2へuser Aのクレデンシャルを登録してAccount BのS3へアクセスできる(図の水色の経路) ※水色の経路はローカルからCLIを実行しているのと同じです 以下コマンドでアカウントBのバケットへアクセスすることができました。 aws s3 ls s3://バケット名 また、逆にIAMポリシーのConditionに記述しているIPやVPCエンドポイントのIDを存在しないものに書き換えた場合、アクセスができなくなりました。 おわりに IAMポリシーのCondition句「StringNotEquals」や「NotIpAddress」といったNotのDenyは分かりづらいですが、整理して考えることができれば大変柔軟が効くポリシーを書くことができます。 機会があれば使ってみてください！

みなさんこんにちは。子育てしながらクラウド推進！日立のモフママです。 前回に引き続き，AWS Summit Online Japan 2021 での日立セッションについてご紹介していきます。 AWS は、米国その他の諸国における Amazon.com, Inc. またはその関連会社の商標です。 その他、本資料に記述してある会社名、製品名は、各社の登録商品または商標です。

0. はじめに 前回の記事では，カスタムAMIの作成とAWS ParallelCluster (コマンドラインツール)のインストールまでを行いました．これらの作業がまだの方は，下記「シリーズの流れ」より1回目をご覧ください． 今回は，AMIを利用して実際にParallelClusterを起動するところまでを扱います．具体的な内容は，設定ファイルの作成とコマンドの確認・実行になります． 1. シリーズの流れ ParallelCluster バージョン3用のカスタムAMIの作成 ParallelCluster バージョン3用の設定ファイルの作成〜起動 (この記事) Slurmを利用したFrontISTR並列実行 2. 設定ファイルの作成 2.1. バージョン2用との違い 書籍のサポートリポジトリではAWS ParallelCluster バージョン2用の設定ファイル v2.11.1-FrontISTR.config が提供されていますが，バージョン3用の設定ファイルは仕様が大きく異なるため，はじめから作成する必要があります．いくつか相違点をあげると ログインするノードの名称: 「Master」から「HeadNode」に ファイル形式: バージョン3用ではYAML形式に 内容のまとまり: バージョン2ではクラスタ・VPCなど機能ごと，バージョン3ではヘッドノード・子ノードと部分ごと バージョン2用冒頭のテンプレート名称宣言や各種チェックが削除 となります．詳しくは，公式ドキュメントをご覧ください． 以下では，「バージョン3でジョブスケジューラにSlurmを使用する場合」に，サポートリポジトリの設定ファイルと同様の内容を表現できるよう，記述する内容を上から順に説明していきます(一般的な書き方の説明ではないためご注意ください)．サポートリポジトリのファイルとの対応は，項目ごとに「(→サポL. 行数)」という形式で明示します．また，対応関係の全体像はこのセクションの最後に画像として示しています． (注) 公式ドキュメントでのリファレンス・作成例を断りなく参照します．また，各項目の必須・オプションは強調したい場合以外記載しませんので，リファレンスをご覧ください． 2.2. Regionセクション バージョン3用の設定ファイルではじめに記載される内容です． Region: ap-northeast-1 Region(オプション): 利用するリージョン．東京リージョン(ap-northeast-1)を指定します．(→サポL. 24) 2.3. Imageセクション Image: Os: alinux2 CustomAmi: ami-xxxxxxxxxxxxxxxxx Os(必須): 利用するOS．Amazon Linux (alinux2)を指定します．(→サポL. 27) CustomAmi(オプション): ベースとなるAMI．自身で作成したカスタムAMIを指定してください．(→サポL. 29) 2.4. HeadNodeセクション AWS ParallelCluster バージョン2では，最初にログインするEC2インスタンスを「Master」と呼んでいましたが，バージョン3では「HeadNode」という名称に変更になりました．GitHubのブランチ名と同様，inclusive languageを反映したものです．以下，3パートに分けて説明します． HeadNode: InstanceType: c5n.large InstanceType(必須): ヘッドノードで利用するインスタンスのタイプ．c5n.xlargeを指定します．(→サポL. 33) HeadNode: ... Networking: SubnetId: subnet-xxxxxxxxxxxxxxxxx ElasticIp: true SubnetId: 利用するサブネット．自身で作成したサブネットを指定してください．(→サポL. 54) VPCを指定する箇所はありません．サブネットに関連付けられたVPCが利用されます． ElasticIp: ヘッドノードにElastic IP (パブリックIP)を付与するか．必ずtrueを指定し有効化してください． (失敗談) 初めて行った際にはこの設定を無視したために，パブリックIPが付与されず，立ち上がったのにいつまでもログインできない状態に陥ってしまいました． HeadNode: ... Ssh: KeyName: FrontISTR-key LocalStorage: RootVolume: Size: 35 Ssh > KeyName: SSH接続で利用する鍵．自身で作成した鍵を指定してください．(→サポL. 28) LocalStorage > RootVolume > Size: ルートボリュームのサイズ．35 (GiB)とします．(→サポL. 35) 2.5. Schedulingセクション 長いため，こちらもいくつかに分割して説明します． Scheduling: Scheduler: slurm SlurmSettings: ScaledownIdletime: 15 Scheduler: 利用するジョブスケジューラ．ここではSlurmを指定します．(→サポL. 30) SlurmSetting > ScaledownIdletime: 何もしないと子ノードがシャットダウンする時間．サポートリポジトリのものより長く，15(分)とします．(→サポL. 50) 2.5.1. SlurmQueuesサブセクション 子ノードに関する具体的な設定など，Schedulingセクションの中核をなすのがこの部分です． Scheduling: ... SlurmQueues: - Name: queue ComputeSettings: LocalStorage: RootVolume: Size: 35 CapacityType: SPOT Name: このキューの名称．適当に指定します． ComputeSettings > LocalStorage > RootVolume > Size: 子ノードのルートボリュームのサイズ．35 (GiB)とします．(→サポL. 36) CapacityType: 子ノードの起動タイプ，オンデマンドかスポットか．SPOTを指定します．(→サポL. 31) ... SlurmQueues: ... Networking: SubnetIds: - subnet-xxxxxxxxxxxxxxxxx AssignPublicIp: true PlacementGroup: Enabled: true SubnetIds: 利用するサブネット．自身で作成したサブネットを指定してください．(→サポL. 54) バージョン2ではMasterのサブネットのみ指定した場合に子ノードにも同じものが引き継がれましたが，バージョン3では両方に記載する必要があります．このNetworking, SubnetIdsは共に必須の項目ですので，書き漏れのないようにしてください． ヘッドノードと同じくVPCを指定する箇所はありません． AssignPublicIp: 子ノードにパブリックIPを付与するか．必ずtrueを指定し有効化してください． (失敗談) ヘッドノードの方でElasticIp: trueとしたにもかかわらずこの設定を無視したために，ノードが立っても計算が走らない状態に陥ってしまいました． PlacementGroup > Enabled: クラスタでプレースメントグループを利用するか．trueを指定します．(→サポL. 43) バージョン2では，placement_groupで自動作成か既存のものの利用かを指定していました．バージョン3では，PlacementGroup > Idに既存のものを記載するかでこれを区別します．サポートリポジトリではDYNAMIC (自動作成)としていたため，ここではIdを記載していません． バージョン2では，placementでグループを利用する対象がクラスタ全体か子ノードのみか指定していました．バージョン3ではこれに対応するものがないようですので，無視しています．(→サポL. 42) ... SlurmQueues: ... ComputeResources: - Name: compute-resource InstanceType: c5n.18xlarge MinCount: 0 DisableSimultaneousMultithreading: true Efa: Enabled: true Name: この計算資源の名称．適当に指定します． InstanceType: 子ノードのインスタンスのタイプ．c5n.18xlargeを指定します．(→サポL. 34) MinCount: 子ノードの下限数．0とします．(→サポL. 32) バージョン2ではデフォルトの下限数が2であった1ために記載していますが，バージョン3ではデフォルトが0に変更されているため，省略しても構いません． DisableSimultaneousMultithreading: ハイパースレッディング無効化の設定．trueを指定します．(→サポL. 37) Efa > Enabled: EFA (Elastic Fabric Adapter)2有効化の設定．trueを指定します．(→サポL. 40) ... SlurmQueues: ... Iam: S3Access: - BucketName: xxxxxxxxxxxxxxxxx EnableWriteAccess: true S3Access: S3利用に関する設定．S3との接続を考えるため記述します． BucketName: 利用するS3バケット．自身で作成したバケットの名称を指定してください．(→サポL. 41) バージョン2とは異なり，ARN (Amazon Resource Names)ではなくバケットの名称自体を記載します． EnableWriteAccess: 書き込みを許可するか．trueを指定します．(→サポL. 41) 2.6. SharedStorageセクション SharedStorage: - MountDir: shared Name: ebs StorageType: Ebs MountDir: 共有するディレクトリ．shared (/sharedのこと)を指定します．(→サポL. 57) Name: 共有ストレージの名称．適当に指定します． StorageType: 共有ストレージのタイプ．EBS (Amazon Elastic Block Store)3を指定します．(→サポL. 47, 56) 2.7. 設定ファイルの全体像 作成したファイルの全体は以下のようになります．YAML形式で書かれていますので，ここでは「v3.1.2-FrontISTR.yaml」という名称で保存しました． v3.1.2-FrontISTR.yaml Region: ap-northeast-1 Image: Os: alinux2 CustomAmi: ami-xxxxxxxxxxxxxxxxx HeadNode: InstanceType: c5n.large Networking: SubnetId: subnet-xxxxxxxxxxxxxxxxx ElasticIp: true Ssh: KeyName: xxxxxxxxxxxxxxxxx LocalStorage: RootVolume: Size: 35 Scheduling: Scheduler: slurm SlurmSettings: ScaledownIdletime: 15 SlurmQueues: - Name: queue ComputeSettings: LocalStorage: RootVolume: Size: 35 CapacityType: SPOT Networking: SubnetIds: - subnet-xxxxxxxxxxxxxxxxx AssignPublicIp: true PlacementGroup: Enabled: true ComputeResources: - Name: compute-resource InstanceType: c5n.18xlarge MinCount: 0 DisableSimultaneousMultithreading: true Efa: Enabled: true Iam: S3Access: - BucketName: xxxxxxxxxxxxxxxxx EnableWriteAccess: true SharedStorage: - MountDir: shared Name: ebs StorageType: Ebs 非常に見にくくなっていますが，サポートリポジトリで提供されているバージョン2用の設定ファイルとの対応は画像のようになります． 3. ローカルPCで用いるコマンド ここでは，主に用いる3つのコマンドについて，最低限の内容を記述します．記事で触れていないオプションやその他のコマンドについては，公式ドキュメントをご覧ください． 3.1. クラスタの作成 バージョン3で作成に用いるコマンドはpcluster create-clusterになります．バージョン2のpcluster createとは異なりますので，注意が必要です．また，設定ファイルの指定が必須になっています． pcluster create-cluster --cluster-name CLUSTER_NAME --cluster-configuration CLUSTER_CONFIGURATION オプション--cluster-nameは-nに，--cluster-configurationは-cにそれぞれ省略可能なので，以下のように記述しても同じです． pcluster create-cluster -n CLUSTER_NAME -c CLUSTER_CONFIGURATION 3.2. クラスタの削除 バージョン3で削除に用いるコマンドはpcluster delete-clusterで，こちらもバージョン2のpcluster deleteから変更されています．また，削除の際に設定ファイルが指定できなくなっています． pcluster delete-cluster --cluster-name CLUSTER_NAME 作成時と同じく，オプション--cluster-nameは-nに省略可能です． pcluster delete-cluster -n CLUSTER_NAME 3.3. クラスタの一覧表示 バージョン3で一覧表示に用いるコマンドはpcluster list-clustersで，同じくバージョン2のpcluster listから変更されています． pcluster list-clusters list-clustersと複数形になっている点に注意が必要です． 4. ParallelClusterを実際に起動する ここまでで，設定ファイルの作成とコマンドの確認が完了しました．早速，ParallelClusterを起動していきます． 4.1. ヘッドノードの起動 作成した設定ファイルを指定し，起動します．名称は適当に「FrontISTR-cluster」としました． pcluster create-cluster -n FrontISTR-cluster -c v3.1.2-FrontISTR.yaml コマンドを実行すると，JSON形式で詳細が返ってきます． $ pcluster create-cluster -n FrontISTR-cluster -c v3.1.2-FrontISTR.yaml { "cluster": { "clusterName": "FrontISTR-cluster", "cloudformationStackStatus": "CREATE_IN_PROGRESS", "cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:xxxxxxxxxxxx:stack/FrontISTR-cluster/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "region": "ap-northeast-1", "version": "3.1.2", "clusterStatus": "CREATE_IN_PROGRESS" }, "validationMessages": [ { "level": "WARNING", "type": "CustomAmiTagValidator", "message": "The custom AMI may not have been created by pcluster. You can ignore this warning if the AMI is shared or copied from another pcluster AMI. If the AMI is indeed not created by pcluster, cluster creation will fail. If the cluster creation fails, please go to https://docs.aws.amazon.com/parallelcluster/latest/ug/troubleshooting.html#troubleshooting-stack-creation-failures for troubleshooting." }, { "level": "WARNING", "type": "AmiOsCompatibleValidator", "message": "Could not check node AMI ami-xxxxxxxxxxxxxxxxx OS and cluster OS alinux2 compatibility, please make sure they are compatible before cluster creation and update operations." } ] } pcluster list-clustersで一覧表示させると，同じくJSON形式で返ってきます． $ pcluster list-clusters { "clusters": [ { "clusterName": "FrontISTR-cluster", "cloudformationStackStatus": "CREATE_IN_PROGRESS", "cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:xxxxxxxxxxxx:stack/FrontISTR-cluster/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "region": "ap-northeast-1", "version": "3.1.2", "clusterStatus": "CREATE_IN_PROGRESS" } ] } 作成が完了するとステータスが"CREATE_COMPLETE"となります． $ pcluster list-clusters { "clusters": [ { "clusterName": "FrontISTR-cluster", "cloudformationStackStatus": "CREATE_COMPLETE", "cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:xxxxxxxxxxxx:stack/FrontISTR-cluster/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "region": "ap-northeast-1", "version": "3.1.2", "clusterStatus": "CREATE_COMPLETE" } ] } AWS マネジメントコンソールをチェックすると，「HeadNode」という名称のEC2インスタンスができていることが分かります． 4.2. ヘッドノードへのログイン バージョン3のpcluster create-clusterでは，作成完了時にパブリックIPなどがCLIに返ってくる仕様になっていません．よって，pcluster sshコマンドを利用してログインすると，AWS マネジメントコンソールにアクセスしてパブリックIPを調べる手間が省けます． pcluster ssh -n FrontISTR-cluster -i PRIVATE_KEY もちろん，コンソールよりIPを取得し，通常のsshコマンドでログインすることも可能です． ssh -i PRIVATE_KEY ec2-user@xxx.xxx.xxx.xxx ログイン後の実際にFrontISTRを実行する例については，ジョブスクリプトの書き方とともに次の記事で紹介します． 4.3. ヘッドノードの削除 ヘッドノードを保持しておくと無尽蔵に課金されてしまうため，利用後には削除が必要です．作成したParallelClusterの名称を指定し，削除を実行します．起動時と同様，JSON形式で詳細が返ってきます． $ pcluster delete-cluster -n FrontISTR-cluster { "cluster": { "clusterName": "FrontISTR-cluster", "cloudformationStackStatus": "DELETE_IN_PROGRESS", "cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:xxxxxxxxxxxx:stack/FrontISTR-cluster/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "region": "ap-northeast-1", "version": "3.1.2", "clusterStatus": "DELETE_IN_PROGRESS" } } 削除が完了すると，pcluster list-clustersで得られるリストは空になります． $ pcluster list-clusters { "clusters": [] } 前の記事: FrontISTRをAWS ParallelCluster バージョン3で利用する① 次の記事: FrontISTRをAWS ParallelCluster バージョン3で利用する③ https://github.com/aws/aws-parallelcluster/blob/v2.11.1/cli/src/pcluster/examples/config#L33 ↩ https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html ↩ https://aws.amazon.com/ebs/ ↩

[前回] AWS公式資料で挑むSCS認定(20)-こんな時どうする(分野2:ログと監視) はじめに 前回に続き「こんな時どうする」をまとめ中です。 今回は「分野3: インフラストラクチャのセキュリティ」となります。 「分野3: インフラストラクチャのセキュリティ」基本知識のおさらい エッジセキュリティに使用されるサービス Amazon Route 53 ドメインネームシステム(DNS)ウェブサービス AWS WAF アプリケーションファイアウォール 機能: SQLインジェクションやクロスサイトスクリプト攻撃をブロック Amazon CloudFront コンテンツ配信ネットワーク(CDN)サービス AWS Shield 分散サービス妨害(DDoS)のマネージド型防御サービス 機能: AWSで実行しているアプリケーションを保護 DDoS攻撃緩和に使用されるサービス Amazon Route 53 Amazon CloudWatch AWS WAF Amazon CloudFront AWS Shield Elastic Load Balancing(ELB) アプリケーションへのトラフィックを、1つまたは複数アベイラビリティーゾーン(AZ)内の複数ターゲットおよび仮想アプライアンスに自動的に分散 Amazon API Gateway(AGW) API(RESTful、WebSocket)の作成、公開、保守、モニタリング、保護を行うフルマネージド型サービス 機能: トラフィック管理、オリジン間リソース共有(CORS)のサポート、認可とアクセスコントロール、スロットリング、モニタリング、APIバージョン管理 Amazon EC2 Auto Scaling アプリケーションの可用性を維持するためのサービス 機能: 定義された条件に応じてEC2インスタンスを自動的に追加または削除 Amazonマシンイメージ(AMI)のセキュリティ 安全でないアプリケーションを無効に 平文による認証を行うサービスとプロトコルを無効に 露出度を最小限に 使用しないネットワークサービスを無効に 使用しないデフォルトのサービスを無効に ファイル共有 Print Spooler RPC AMI作成時の認証情報を削除 すべてのSSHキーペアを削除 AWSとサードパーティのすべての認証情報(アクセスキーなど)を削除 すべてのユーザアカウントのパスワードを削除 「分野3: インフラストラクチャのセキュリティ」の「こんな時どうする」 特定IPアドレスからのトラフィックをブロックしたい ネットワークACL(NACL)で拒否ルール設定 ※ セキュリティグループ(SG)は拒否ルール設定できない(許可のみ) 特定IPアドレスとの双方向通信を許可したい NACLの場合、インバウンド・アウトバウンド両方にルール設定が必要(ステートレス) SGの場合、インバウンドかアウトバウンド一つのみルール設定でOK(ステートフル) 他のSGに含まれるすべてのEC2インスタンスからのトラフィックを許可したい SGのインバウンドとアウトバウンドのルールを「ALL trafic 他のSG名」と設定 ルールはSG名のみで記載可、CIDRブロックを指定しなくてもOK VPCネットワークにおけるNACLとSGの許可・禁止についてのトラフィックログを監視したい VPCフローログで監視 セキュアでないプロトコルまたは暗号が使用されたSSL/TLS通信をELBでブロックしたい 問題プロトコル、暗号を含まないカスタムセキュリティポリシーを作成、ELBに適用 事前に定義されたELBのデフォルトセキュリティポリシーの使用を推奨 特定クエリ文字列(URIパラメータ)が含まれているCloudFrontへのウェブリクエストをブロック CloudFrontに関連付けられたAWS WAFを使用 特定クエリ文字列に一致するAWS WAF ACLを記述し、AWS WAFルールにアタッチ シグネチャに基づきELBへのウェブリクエストをブロック シグネチャとは、既知の不正な通信やプログラム、攻撃パターンを識別するためのルール集 ELBと関連付けられたAWS WAFを使用 シグネチャとマッチングしたリクエストをブロック SQLインジェクションやクロスサイトスクリプティング(XSS)をブロックしたい AWS WAFを使用 ※ AWS Shieldでは守れない OSI参照モデルのネットワーク層(3層)およびトランスポート層(4層)で行われるDDos攻撃をブロック AWS Shieldを使用 ※ AWS WAFはOSI参照モデルのアプリケーション層(7層)で行われるDDoSを防御 EC2インスタンス上の自動侵入テストと脆弱性分析実施中に、GuardDutyによるアラームを上げたくない GuardDutyの信頼されたIPアドレスリストにEC2のElastic IPアドレス(EIP)を追加 おわりに 「分野3: インフラストラクチャのセキュリティ」に対する「こんな時どうする」集でした。 次回は「分野4: ID(アイデンティティ)及びアクセス管理」です。 お楽しみに。

[前回] AWS公式資料で挑むSCS認定(20)-こんな時どうする はじめに 前回に続き「こんな時どうする」をまとめ中です。 今回は「分野3: インフラストラクチャのセキュリティ」となります。 「分野3: インフラストラクチャのセキュリティ」基本知識のおさらい エッジセキュリティに使用されるサービス Amazon Route 53 ドメインネームシステム(DNS)ウェブサービス AWS WAF アプリケーションファイアウォール 機能: SQLインジェクションやクロスサイトスクリプト攻撃をブロック Amazon CloudFront コンテンツ配信ネットワーク(CDN)サービス AWS Shield 分散サービス妨害(DDoS)のマネージド型防御サービス 機能: AWSで実行しているアプリケーションを保護 DDoS攻撃緩和に使用されるサービス Amazon Route 53 Amazon CloudWatch AWS WAF Amazon CloudFront AWS Shield Elastic Load Balancing(ELB) アプリケーションへのトラフィックを、1つまたは複数アベイラビリティーゾーン(AZ)内の複数ターゲットおよび仮想アプライアンスに自動的に分散 Amazon API Gateway(AGW) API(RESTful、WebSocket)の作成、公開、保守、モニタリング、保護を行うフルマネージド型サービス 機能: トラフィック管理、オリジン間リソース共有(CORS)のサポート、認可とアクセスコントロール、スロットリング、モニタリング、APIバージョン管理 Amazon EC2 Auto Scaling アプリケーションの可用性を維持するためのサービス 機能: 定義された条件に応じてEC2インスタンスを自動的に追加または削除 Amazonマシンイメージ(AMI)のセキュリティ 安全でないアプリケーションを無効に 平文による認証を行うサービスとプロトコルを無効に 露出度を最小限に 使用しないネットワークサービスを無効に 使用しないデフォルトのサービスを無効に ファイル共有 Print Spooler RPC AMI作成時の認証情報を削除 すべてのSSHキーペアを削除 AWSとサードパーティのすべての認証情報(アクセスキーなど)を削除 すべてのユーザアカウントのパスワードを削除 「分野3: インフラストラクチャのセキュリティ」の「こんな時どうする」 特定IPアドレスからのトラフィックをブロックしたい ネットワークACL(NACL)で拒否ルール設定 ※ セキュリティグループ(SG)は拒否ルール設定できない(許可のみ) 特定IPアドレスとの双方向通信を許可したい NACLの場合、インバウンド・アウトバウンド両方にルール設定が必要(ステートレス) SGの場合、インバウンドかアウトバウンド一つのみルール設定でOK(ステートフル) 他のSGに含まれるすべてのEC2インスタンスからのトラフィックを許可したい SGのインバウンドとアウトバウンドのルールを「ALL trafic 他のSG名」と設定 ルールはSG名のみで記載可、CIDRブロックを指定しなくてもOK VPCネットワークにおけるNACLとSGの許可・禁止についてのトラフィックログを監視したい VPCフローログで監視 セキュアでないプロトコルまたは暗号が使用されたSSL/TLS通信をELBでブロックしたい 問題プロトコル、暗号を含まないカスタムセキュリティポリシーを作成、ELBに適用 事前に定義されたELBのデフォルトセキュリティポリシーの使用を推奨 特定クエリ文字列(URIパラメータ)が含まれているCloudFrontへのウェブリクエストをブロック CloudFrontに関連付けられたAWS WAFを使用 特定クエリ文字列に一致するAWS WAF ACLを記述し、AWS WAFルールにアタッチ シグネチャに基づきELBへのウェブリクエストをブロック シグネチャとは、既知の不正な通信やプログラム、攻撃パターンを識別するためのルール集 ELBと関連付けられたAWS WAFを使用 シグネチャとマッチングしたリクエストをブロック SQLインジェクションやクロスサイトスクリプティング(XSS)をブロックしたい AWS WAFを使用 ※ AWS Shieldでは守れない OSI参照モデルのネットワーク層(3層)およびトランスポート層(4層)で行われるDDos攻撃をブロック AWS Shieldを使用 ※ AWS WAFはOSI参照モデルのアプリケーション層(7層)で行われるDDoSを防御 EC2インスタンス上の自動侵入テストと脆弱性分析実施中に、GuardDutyによるアラームを上げたくない GuardDutyの信頼されたIPアドレスリストにEC2のElastic IPアドレス(EIP)を追加 おわりに 「分野3: インフラストラクチャのセキュリティ」に対する「こんな時どうする」集でした。 次回は「分野4: ID(アイデンティティ)及びアクセス管理」です。 お楽しみに。

はじめに 当記事はAWSの主なサービスを備忘録として簡潔にまとめていこうと思います。 個人開発者目線での記事となっています。 初学者なので間違っていることや分かりにくい部分があると思いますが、ご指摘いただけたら幸いです。 AWSとは AWSとはAmazon Web Serviceの略でAmazonが提供するクラウドサービスです。 AWSではWebサイトの運営やビッグデータ分析、機械学習などをすることができます。 様々なニーズに合わせた多様なサービスがあるので必要なサービスを学習していくことが重要になってきます。 今回はWebサイト運営を目的とした記事となります。 VPC (Virtual Private Cloud) AWS上でネットワークを提供する仮想ネットワークサービス。 扱うサービスの作業範囲を決めるような認識。 アイコン 料金 VPC自体は無料で利用することができる。 サブネット VPCのを細かく区切り、IPアドレスを細分化したもの。 大きく分けて、インターネットに接続可能なサブネットをパブリックサブネット、不可能なサブネットをプライベートサブネットと呼ぶ。 アイコン 　 料金 無料 ルートテーブル サブネットやその他のシステムを通信させるための送信先の制御をするリスト。 アイコン - 料金 無料 インターネットゲートウェイ VPCにアタッチすことでインターネットに接続することができる。 アイコン 料金 無料 NATゲートウェイ AWS内で通信するときに用いるもの。 IPアドレスを秘匿するために、プライベートサブネットに配置したDBへ接続する際、パブリックアブネットから一度NATゲートウェイを経由してプライベートサブネットのDBへ転送するなどの用途で用いる。 アイコン 料金 0.062 USD/時間 Elastic IP アドレス AWS内でIPアドレスを固定することができる。 アイコン 料金 起動中のEC2インスタンスに割り当てた場合のみ無料割り当てていない場合は0.005 USD/時間 セキュリティグループ AWS内のネットワークのインバウンドルールとアウトバウンドルールの制御する仕組み。 アイコン 料金 無料 VPCエンドポイント AWS内で通信をするときにIPアドレスを用いずに通信することができるもの。 アイコン 料金 最初の1PB : 0.01 USD/時間 次の4PB : 0.006 USD/時間5PB以上 : 0.004 USD/時間 EC2 (Elastic Compute Cloud) AWS上に仮装マシンを構築するサービスで、作成したEC2の仮想サーバーはインスタンスという単位で扱われる。 Elasticは伸縮性が高いという意味で、ユーザーの要件によりコンピュータの性能や台数、メモリなどその名の通り、伸縮性が高く設定することができる。 アイコン 料金 契約するEC2タイプによって異なる。起動しているだけで料金が発生する可能性があるので注意が必要。 AMI (Amazon Machine Image) EC2を起動する上での設計図。 OSの情報や提供したいサービスをインストールしているものがテンプレートとしてまとまっている。 アイコン 料金 利用するAMIによって異なる。 キーペア インターネット上で情報をやり取りする際に第三者から情報を盗み見されないために通信データを暗号化する仕組み。 アイコン 料金 無料 ELB (Elastic Load Balancing) 特定のEC2インスタンスやその他のサービスにアクセスが偏らないように分配してくれるもの。 アイコン 料金 ロードバランサーの種類によって異なる。 Auto Scaling アクセスが集中した際やあらかじめ設定された時刻など、特定の条件を満たした際に自動的にEC2インスタンスを起動、または終了してくれもの。 アイコン 料金 無料 Lambda AWS上で動作するバッチのようなもの。 実行時間は15分までの制限がある。 アイコン 料金 100万リクエスト、40万秒まで:無料100万件以上:0.2 USD/100万件40万秒以上:0.0000166667 USD/GB-秒 Route53 AWSが提供するDNS（Domain Name System）。 IPアドレスとドメイン名を結びつける。 アイコン 料金 0.5 USD/月（２５ホストゾーンまで、ホストゾーンごと。） S3 (Simple Storage Service) クラウド型のオブジェクトストレージサービス。 静的サイトや、サーバーアクセスエラー画面なども配置する。 アイコン 料金 有料。（契約内容によって変動する。） RDS (Relational Data Base System) AWSによって提供されているフルマネージドデータベース。 AWSが独自に提供するDBのAuroraから、MySQL、ProtgerSQL、ORACLE等が利用できる。 アイコン 料金 契約の種類によって異なる。 Cloud Watch AWSで稼働中のシステムの状況を監視したり、ログを見たりすることができる。 システムの状況やログからアラームを設定したり、イベントを起動したりすることができる。 アイコン 料金 一部無料利用枠はあるが利用状況が大きくなると有料になる。 CloudFormation AWSリソースをソースコードとして管理し、起動することができる。 アイコン 料金 無料 ECR (Elastic Container Registry) AWS上で利用できるDocker hub。レジストリサービス。 アイコン 料金 ストレージ:0.1 USD/GBデータ転送:0.14 USD/GB ECS (Elastic Container Service) ECRのコンテナを起動させる場所。 アイコン 料金 無料。（起動するインスタンスタイプによっては課金が発生する。） IAM (Identity and Access Management) AWSにおけるユーザーや権限を管理する。 アイコン 料金 無料 SNS (Simple Notification Service) AWSからメールやプッシュ通知を行うメッセージングサービス。 アイコン 料金 無料利用枠あり。通信が多いと課金。 Billing AWSで利用している課金状況を見ることができる。 アイコン - 料金 無料 おわりに AWSの機能のよく使うであろう機能をまとめてみました。 ここに記した機能はAWSの中でもごく一部なので日々もっと勉強しないといけないですね。