計算概要 実行時間とリクエスト 無料枠 無料枠超過分

これは CDK Advent Calendar 2021 の 2日目の記事です。 こんにちは！るね*(@lune_sta)です。 本日(2021年12月2日)、CDKv2がStableになりました！めでたいですね！！ v1からv2への変更点、移行方法については公式ドキュメントやAWS Blogの AWS Cloud Development Kit v2 開発者プレビューのお知らせでも紹介していますので、合わせてご覧ください。 この記事のコードはGitHubにあります。CDKv2ベースです。 CDKのテストにまつわる話 CDKではアプリケーションのコードをテストするのと同じように、インフラのコードに対してテストを書けます。以前までは@aws-cdk/assertというモジュールを使ったテストが一般的でしたが、このモジュールはTypeScript/JavaScript専用なのがネックでした。 そのため、すべての言語に対応した @aws-cdk/assertions というモジュールが新しく開発され、こちらはCDKv1では2020年11月リリースの v1.132.0 からStableとして利用できるようになっています。もちろんCDKv2でも使用できます。 最近のバージョンではcdk initで作成されるテストの雛形も @aws-cdk/assert ではなく @aws-cdk/assertions に変わっており、今後はこちらが主流になっていくと思われます。 @aws-cdk/assertions の使い方については、AWS Blogのあらゆる言語でのCDKアプリケーションのテストで紹介していますが、この記事では実際にシンプルなコードに対してテストを書いてみて感触を確かめてみます。 テスト対象のプログラム 今回は、下記のようなシンプルなコードに対してテストする例を考えてみます。 const db = new dynamodb.Table(this, 'Table', { partitionKey: { name: 'itemId', type: dynamodb.AttributeType.STRING, }, tableName: 'items', removalPolicy: RemovalPolicy.DESTROY, }) const backend = new lambda.NodejsFunction(this, 'Function', { entry: './lambda/index.ts', }) db.grantReadWriteData(backend) new apigateway.LambdaRestApi(this, 'Api', { handler: backend }) テストの始め方 @aws-cdk/assertions を使うには、まずテスト対象のStackのインスタンスを生成し、Template.fromStack() を使用してCloudformationテンプレートを生成する所から始まります。 Template.fromString()やTemplate.fromJSON()なども用意されているので文字列やObjectからテンプレートを生成することもできます。 import { Template } from 'aws-cdk-lib/assertions' import { App } from 'aws-cdk-lib' import { CdkAssertionsSamplesStack } from '../lib/cdk-assertions-samples-stack' test('Test name', () => { const app = new App(); const stack = new CdkTestSamplesStack(app, 'CdkTestSamplesStack', {}) const template = Template.fromStack(stack) Full Template Match 一番シンプルなアサーションとして紹介されているのが、完成形のテンプレートと比較するFull Template Matchです。 const expected = { 'Resources': { 'TableCD117FA1': { 'Type': 'AWS::DynamoDB::Table', 'Properties': { 'KeySchema': [ { 'AttributeName': 'itemId', 'KeyType': 'HASH' } ], (中略) } template.templateMatches(expected) templateMatches() に限らず、@aws-cdk/assertions のマッチ系のメソッドではデフォルトで完全一致ではなく、"オブジェクトライク"な比較が行われます。そのため実際のテンプレートは期待する値の上位集合(superset)であることが許容されます。イメージとしては下記のような感じです。完全一致を行いたい場合は後述するマッチャーを使います。 // テスト対象のテンプレート // { // "Resources": { // "A": { // "Type": "Foo::Bar", // "Properties": {...} // }, // "B": { // "Type": "BAZ::QUX", // "Properties": {...} // } // } // } // これはエラーにならない const expected = { 'Resources': { 'A': { 'Type': 'Foo::Bar', 'Properties': {...} } } template.templateMatches(expected) // これはエラーになる const expected = { 'Resources': { 'C': { 'Type': 'QUUX::CORGE', 'Properties': {...} } } template.templateMatches(expected) 実際にFull Template Matchをする際は、手作業で期待するテンプレートを管理するよりスナップショットテストとして使うことが多いと思います。スナップショットテストは簡単で、TypeScriptでJestを使用する場合は下記のように書くだけでスナップショットの保存と比較が行われます。 // スナップショットとの比較を行う expect(template.toJSON()).toMatchSnapshot() テスト対象のテンプレートに意図して変更を加えた場合は、以下のコマンドでスナップショットを更新できます。詳しくはSnapshot Testingをご覧ください。 $ jest --updateSnapshot CDKから生成されるCFnテンプレートは、CDKフレームワークとCDKアプリケーションの2つのコードの影響を受けます。スナップショットテストを使うことで、CDKのバージョンが変化してもデプロイされるリソースに影響が無いことを確認できます。また、CDKアプリケーションのリファクタをする際にも有用です。 Counting Resources resourceCountIs()を使うと対象の種類のリソースの数を確認できます。 // Functionが1つ作られていることを確認する template.resourceCountIs('AWS::Lambda::Function', 1) Resource Matching & Retrieval テンプレート全体ではなく、特定のリソースの Properties を確認したい場合は hasResourceProperties() を使います。 Properties だけでなくリソース全体(UpdateReplacePolicyやDependsOnなど)を確認する場合は hasResource() を使います。 // Propertiesが正しいことを確認する template.hasResourceProperties('AWS::Lambda::Function', { 'Handler': 'index.handler' }); // Properties以外を確認したい場合はhasResource()を使う template.hasResource('AWS::DynamoDB::Table', { 'UpdateReplacePolicy': 'Delete' }) 似たようなものに findResources() メソッドがあり、アサーションではなくマッチするリソースのセットを取得できます。 // 生成されるIAM Roleをすべて表示する console.log(template.findResources('AWS::IAM::Role')) Output and Mapping sections OutputやMappingに対しても似たようなメソッドどして hasOutput()、findOutput()、hasMapping()、findMappings() が利用できます。その場合、引数としてlogicalIdを指定しますが、*を指定して全てを対象にすることもできます。 (logicallIdはランダムに生成されるため、一部を * にして ApiEndpoint* のような書き方ができると便利そうですが、できませんでした。) const expected = { Value: '...' } template.hasOutput('*', expected) Special Matchers hasXxx()、findXxx()、templateMatches() で使用する期待する値は、今までの例のようなリテラル値以外にもマッチャーを使用できます。 Object Matchers Match.objectLike() を使うとテスト対象のオブジェクトがパターンの上位集合(superset)であることを確認できます。これは マッチャーを使わない場合と同じ挙動です。 Match.objectEquals() を使うと完全一致のアサートをすることができます。 // Match.objectLike() は部分一致 template.hasResourceProperties('AWS::DynamoDB::Table', { 'ProvisionedThroughput': Match.objectLike({ 'ReadCapacityUnits': 5 }) }) // Match.objectEquals() は完全一致 template.hasResourceProperties('AWS::DynamoDB::Table', { 'ProvisionedThroughput': Match.objectEquals({ 'ReadCapacityUnits': 5, 'WriteCapacityUnits': 5 }) }) Presence and Absence Match.absent() を使うと該当する値が存在しないことを確認できます。逆に値が存在することだけを確認したい場合は Match.anyValue() を使います。 // 存在しないことを確認する template.hasResourceProperties('AWS::DynamoDB::Table', { 'DummyKey': Match.absent() }) // 存在することを確認する template.hasResourceProperties('AWS::DynamoDB::Table', { 'TableName': Match.anyValue() }) Array Matchers 配列に対しては Match.arrayWith() や Match.arrayEquals() が使用できます。 今回のテンプレートでは良い例が思いつきませんでしたが、公式ドキュメントには以下のような例が紹介されていました。 // Given a template - // { // "Resources": { // "MyBar": { // "Type": "Foo::Bar", // "Properties": { // "Fred": ["Flob", "Cat"] // } // } // } // } // The following will NOT throw an assertion error const expected = { Fred: Match.arrayWith(['Flob']), }; template.hasResourceProperties('Foo::Bar', expected); // The following will throw an assertion error const unexpected = Match.objectLike({ Fred: Match.arrayWith(['Wobble']), }); template.hasResourceProperties('Foo::Bar', unexpected); Not Matcher Match.not()を使うとマッチ結果を反転させることができます。 以下も公式ドキュメントの例になります。 // Given a template - // { // "Resources": { // "MyBar": { // "Type": "Foo::Bar", // "Properties": { // "Fred": ["Flob", "Cat"] // } // } // } // } // The following will NOT throw an assertion error const expected = { Fred: Match.not(['Flob']), }; template.hasResourceProperties('Foo::Bar', expected); // The following will throw an assertion error const unexpected = Match.objectLike({ Fred: Match.not(['Flob', 'Cat']), }); template.hasResourceProperties('Foo::Bar', unexpected); Serialized JSON 公式ドキュメント Capturing Values Capture() を使用するとマッチした値をキャプチャーできます。 // 値をキャプチャーするにはCapture()を使う const capture = new Capture() template.hasResourceProperties('AWS::Lambda::Function', { Runtime: capture }) console.log(capture.asString()) // nodejs14.x テストを書いてみた感想 @aws-cdk/assertions を使ったテストは、生成されるCFnテンプレートへのアサーションになるため、CFnを意識しないとうまくテストが書けない所が好みが分かれそうです。たとえばAspectsを使うと通常のTypeScriptのコードでStackの内容を確認することもできるので、用途によって使い分けるのがよいと思いました。Aspectsの使い方はクラスメソッドさんの記事が分かりやすいです。 マッチャーはかゆい所に手が届かない部分もあって、たとえばhasResource()等のメソッドは単一のリソースに対してのみアサートするため、同じ種類のリソースが複数あった時 (すべてのS3のバージョニングがonになっているか？など)の簡単な書き方が分かりませんでした。@aws-cdk/assertions はできたばかりのモジュールのため今後の更新にも期待です。 スナップショットテストは手間がほぼかからず、CDKのバージョンアップやリファクタによる意図しないデグレを防ぐことができるため有用だと思います。まずはスナップショットテストから始めるのがよいかなと思いました。

この記事では、laravelで開発したポートフォリオのAWS EC2へのデプロイについて紹介していきます！ 記事が長くなりそうなので、細かい説明とは省いてなるべく実行手順のみ記載していくようにします！ ポートフォリオ使用技術 フロントエンド：HTML5、CSS、bootstrap4.5.0、Tailwindcss2.2.15 バックエンド：PHP7.4.15、Laravel8.34.0、Jetstream1.0、Livewire インフラ：Docker20.10.2、nginx1.18、MySQL8.0.23/phpMyAdmin、Apache2.4.38、AWS S3 デプロイ環境 デプロイ先：AWS EC2 サーバー：nginx（Apacheの場合も記載しました。) 1.AWS EC2 インスタンス作成 1.AWSからログインしてEC2画面にアクセス。 2.画面右上のリージョンを「東京」に。 3.「インスタンスを起動」をクリック。 4.「AWS Linux2」を選択。 5.無料枠の「t2.micro」を選択。→次のステップでステップ5まで移動。 ※ステップ3、4はデフォルトのまま。 6.「タグを追加」→「キー」と「値」を入力。 7.「ルールの追加」→「HTTP」と「HTTPS」を追加→「確認と作成」 8.「起動」 9.「新しいキーペアの作成」→「キーペア名」入力→「キーペアのダウンロード」でローカルに保存→「インスタンスを作成」 10.作成されたインスタンスにチェック→接続 11.10の接続情報を元にターミナルからリモート接続を実施。 $ cd #ターミナルをスタート地点へ $ mkdir ~/.ssh　　　#.sshディレクトリを作成 $ mv Downloads/sample-key.pem .ssh/ #mvコマンドで、「キー.pem」を.sshディレクトリに移動 $ cd .ssh/ #.sshにディレクトリ移動 .ssh $ ls #pemファイルが存在するか確認。「sample-key.pem」が存在すればOK .ssh $ chmod 400 sample-key.pem #キーファイル（○○○.pem）のパーミッションを変更 .ssh $ ssh -i "sample-key.pem" ec2-user@ec2-52-68-186-250.ap-northeast-1.compute.amazonaws.com #ログイン（AWS 接続画面記載のコードをコピペ） Last login: Thu Dec 2 06:14:35 2021 from p3014131-ipoe.ipoe.ocn.ne.jp __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ nginxをセットアップ 今回はnginxをセットアップしますが、Apache2を使用したい方はApache2のインストールを参考にしてください。 Apache2の場合 [ec2-user@ip-172-31-45-44 ~]$ sudo yum update #パッケージアップデート 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 No packages marked for update #「No packages marked for update」は、アップデートするパッケージがないということなのでこのままでOK。 $ sudo yum install apache2 ※初めに選択したAMIがAWS Linux2の場合、aptコマンドが使用できない為、apt→yumに変更してコマンド実行。 nginxの場合 #EC2インスタンスは、nginxのyum intstallが有効になっていない為、有効化。 [ec2-user@ip-172-31-45-44 ~]$ sudo amazon-linux-extras enable nginx1 [ec2-user@ip-172-31-45-44 ~]$ sudo yum -y install nginx #インストール [ec2-user@ip-172-31-45-44 ~]$ nginx -v #バージョン確認 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl enable nginx #nginx自動起動化 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl start nginx.service #起動 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl status nginx.service #起動確認 続く AWSインスタンス一覧画面→作成したインスタンスにチェック→画面下のインスタンス情報内のパブリックIPv4アドレスからアクセス→サーバーの初期画面が表示されればインスタンスの作成とサーバーのセットアップが完了です！ とりあえずここまでお疲れ様でした！ まだ初めの段階ですが、エラーに引っかかってしまうとこれだけの作業でも時間が過ぎてしまいますよね。。 記事が長くなってしまう為、続きはパート2で紹介していきます！ 参考記事

この記事では、laravelで開発したポートフォリオのAWS EC2へのデプロイについて紹介していきます！ 記事が長くなりそうなので、細かい説明とは省いてなるべく実行手順のみ記載していくようにします！ ポートフォリオ使用技術 フロントエンド：HTML5、CSS、bootstrap4.5.0、Tailwindcss2.2.15 バックエンド：PHP7.4.15、Laravel8.34.0、Jetstream1.0、Livewire インフラ：Docker20.10.2、nginx1.18、MySQL8.0.23/phpMyAdmin、Apache2.4.38、AWS S3 デプロイ環境 デプロイ先：AWS EC2 サーバー：nginx（Apacheの場合も記載しました。) 1.AWS EC2 インスタンス作成 1.AWSからログインしてEC2画面にアクセス。 2.画面右上のリージョンを「東京」に。 3.「インスタンスを起動」をクリック。 4.「AWS Linux2」を選択。 5.無料枠の「t2.micro」を選択。→次のステップでステップ5まで移動。 ※ステップ3、4はデフォルトのまま。 6.「タグを追加」→「キー」と「値」を入力。 7.「ルールの追加」→「HTTP」と「HTTPS」を追加→「確認と作成」 8.「起動」 9.「新しいキーペアの作成」→「キーペア名」入力→「キーペアのダウンロード」でローカルに保存→「インスタンスを作成」 10.作成されたインスタンスにチェック→接続 11.10の接続情報を元にターミナルからリモート接続を実施。 $ cd #ターミナルをスタート地点へ $ mkdir ~/.ssh　　　#.sshディレクトリを作成 $ mv Downloads/sample-key.pem .ssh/ #mvコマンドで、「キー.pem」を.sshディレクトリに移動 $ cd .ssh/ #.sshにディレクトリ移動 .ssh $ ls #pemファイルが存在するか確認。「sample-key.pem」が存在すればOK .ssh $ chmod 400 sample-key.pem #キーファイル（○○○.pem）のパーミッションを変更 .ssh $ ssh -i "sample-key.pem" ec2-user@ec2-52-68-186-250.ap-northeast-1.compute.amazonaws.com #ログイン（AWS 接続画面記載のコードをコピペ） Last login: Thu Dec 2 06:14:35 2021 from p3014131-ipoe.ipoe.ocn.ne.jp __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ nginxをセットアップ 今回はnginxをセットアップしますが、Apache2を使用したい方はApache2のインストールを参考にしてください。 Apache2の場合 [ec2-user@ip-172-31-45-44 ~]$ sudo yum update #パッケージアップデート 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 No packages marked for update #「No packages marked for update」は、アップデートするパッケージがないということなのでこのままでOK。 $ sudo yum install apache2 ※初めに選択したAMIがAWS Linux2の場合、aptコマンドが使用できない為、apt→yumに変更してコマンド実行。 nginxの場合 #EC2インスタンスは、nginxのyum intstallが有効になっていない為、有効化。 [ec2-user@ip-172-31-45-44 ~]$ sudo amazon-linux-extras enable nginx1 [ec2-user@ip-172-31-45-44 ~]$ sudo yum -y install nginx #インストール [ec2-user@ip-172-31-45-44 ~]$ nginx -v #バージョン確認 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl enable nginx #nginx自動起動化 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl start nginx.service #起動 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl status nginx.service #起動確認 続く AWSインスタンス一覧画面→作成したインスタンスにチェック→画面下のインスタンス情報内のパブリックIPv4アドレスからアクセス→サーバーの初期画面が表示されればインスタンスの作成とサーバーのセットアップが完了です！ とりあえずここまでお疲れ様でした！ まだ初めの段階ですが、エラーに引っかかってしまうとこれだけの作業でも時間が過ぎてしまいますよね。。 記事が長くなってしまう為、続きはパート2で紹介していきます！ 参考記事

はじめに ※この記事は現在書き途中になります。 学習の進捗に合わせて更新されていくかと思います。 この記事ではAWS初心者の私が「実践AWSデータサイエンス」の本を読んでつまずいたところをメモしていく記事となります。 こちらの書籍内容は求めていたものですが、省略が多く(実践なので)、AWSの基本的な使い方については書かれていないように思えます。そこで試行錯誤しながらゆっくりメモしていければと思います。 3章 SageMaker Autopilot データセットの取得について SageMaker Studioを起動して、以下のファイルを開く https://github.com/data-science-on-aws/oreilly_book/blob/master/03_automl/01_Prepare_Dataset_Autopilot.ipynb そのあとすべて実行することで作成できる PythonSDKでSageMakerAutopilotをしたときにS3にアクセスできない role/service-role/awsdeepracersagemakeraccessrole has "s3:putobject" permissions on the bucket. というエラーが発生。S3とSagemakerのフルアクセスをIAMに設定しているのにダメだった。 【機械学習初級】Amazon SageMaker導入の手順~S3にデータをアップロード編~ こちらの記事を発見して以下の内容を実施したところエラーが解決した(ただしSでなくsでないとエラーになる) S3バケットを作成するうえで、注意する点が1点あります。 それは、バケット名に「Sagemaker」を含めることです。 こうすることでノートブックインスタンスを作成する際に設定をしたデフォルトで設定されているIAMポリシーでSagemakerがS3バケットにアクセスする権限を付与することができます。 Athenaでmismatched input 'FUNCTION'. Expecting: 'EXTERNAL' Athenaのテーブル名に-を使っていたことが原因だった aws-handson → aws_hands に変更して対応した Athenaで結果が空白や文字列が数値になって返ってくる これは入力のS3とクエリの履歴保存先であるS3が同じになっているのが原因 入力のS3はファイルのみしか置いてはいけない エディタの設定から出力先のS3を設定して解決 おわりに 1ページ進めるのに数時間かかるこの本ですが500p以上の大ボリューム。果たして一通りやることができるのか不安で仕方ないです。 わからないことも多いですが、なんとか進めていければと思います。 本当にわからないところは問い合わせるのもアリかな 参考 【機械学習初級】Amazon SageMaker導入の手順~S3にデータをアップロード編~ Athena に mismatched input 'external'. expecting: 'or', 'schema', 'table', 'view' と言われた

こいつをかいつまんでメモ https://d1.awsstatic.com/webinars/jp/pdf/services/20200826_AWS-BlackBelt_AWS-CloudFormation.pdf テンプレート記述 要素 versionバージョン desctiption説明 metadata追加で記述するもの（それぞれの記述に入れれる） parameter スタック作成時にユーザーが記述する情報 パラメータグループで複数の設定値をグループ化できる resources 自動で作成されるリソースの設定を記述（必須） output スタック作成後に出力されるデータ transform マクロを利用したやつ 他のテンプレート引っ張ったりでいる mappings 特定の設定を入れるとそれに対応した設定をしてくれる 例えば、リージョン指定したらそれに応じたリソース作成してくれるみたいな condition 一定条件を満たすとリソース作成するみたいなことができる 組み込み関数 ref Fn:: とかある だいたい!かFn::であらわされう 疑似パラメータ 組み込み関数っぽいやつがAWS側で事前に用意されている AWS::regionとかいれたらregionいれるとか 補足 論理ID テンプレートで一意 物理ID 実際のリソース名 デプロイ ①codepipeline 自動。手動で変更される心配がない ②変更セットで変更（直接更新も可能） ③スタックセットで他のリージョンにも一気に展開できる またスタック分割で ライフサイクルや依存関係でレイヤーを分けてテンプレートを作成すると変更セットを作成するときに便利 ドリフトで何を変更したかを見ることができる 運用 リソースの削除保護 IAMのテンプレートをスタックへインポートする テンプレートに削除保護に関する属性をいれておくことでリソースを保護できる

これは ユニークビジョン株式会社 Advent Calendar 2021 の記事です。 はじめに 以前書いた以下の記事に追記と称して自分の twitter だけ張り付けた事象をちゃんと記事にしてみた。 s3からフォルダのようなkeyが帰ってくる。 cloudfront のオリジンにしているときに s3に空ファイルがあると妙な現象が起こる。 空ファイルなんて作るやつが馬鹿なのよ。という方も前記事を見ていただけるとなぜ空ファイルが生えるかわかります。 現象 悪さといっても具体的に何なのか。 まず最初に現象を見るのが早いでしょう。 s3 をアクセス先とした cloudfront を作成してブラウザでアクセスします。 遷移先にブラウザが解釈可能なオブジェクトが存在すればブラウザはその内容を表示してくれるはずです。 ちょっとこの後のタネが割れるのですが以下のようなパスにアクセスします。 (URLはイメージです。distribution ID は伏せているのでアクセスしても何もありません。) https://XXXXXXXXXXX.cloudfront.net/test2/ するとこうなります。 なんかダウンロードしました。 空ファイルのようです。 実験 s3 の用意 以下の通り s3 を用意します test-bucket ├── test1 │ └── index.html └── test2 └── index.html ディレクトリを2つ作成し、それぞれに index.html を配置しました。 AWS s3 コンソール上での見かけは同じですが、作成手順が異なります。 test1 の方は index.html の入った test1 というフォルダをアップロードしました。 一方 test2 はコンソールから test2 というフォルダを作成し、index.html だけをその中にアップロードしました。 cloudfront の作成 先の test-bucket をオリジンに設定した cloudfront を作成します。 オリジンアクセスアイデンティティとかなんとか s3 オブジェクトにアクセスできるようにする設定は適宜行いましょう。 それだけ。 index.html にアクセス それぞれの index.html にアクセスしてみます。 https://XXXXXXXXXXX.cloudfront.net/test1/index.html https://XXXXXXXXXXX.cloudfront.net/test2/index.html それぞれアクセスできました。 index.html を削る それぞれ以下の URL にアクセスしてみます。 https://XXXXXXXXXXX.cloudfront.net/test1/ https://XXXXXXXXXXX.cloudfront.net/test2/ 結果は以下の通り、挙動が異なりました。 何が起こっているのか s3 について簡単におさらい 詳細は概要の前記事で 空ファイル フォルダの作成を使うと空のオブジェクトが生成されます つまり先ほど挙げたこのAWSコンソールでの見かけのディレクトリ構造は誤りであり、 誤 test-bucket ├── test1 │ └── index.html └── test2 └── index.html 以下が本来の姿と考えられます。 正 test-bucket ├── test1 │ └── index.html └── test2 ├── (空ファイル) └── index.html フォルダはない s3 は単純な Key-Value ストアであり、本来フォルダというものはありません。 つまり上記のディレクトリ構造すら正確には誤りであり、s3 の真に正しい姿は以下の通りになります。 <test-bucket> test1/index.html test2/ test2/index.html 実際、list_objects などで確認するとそのような返答が来ます。 cloudfront が実際にアクセスしているオブジェクト つまり、https://XXXXXXXXXXX.cloudfront.net/test1/index.htmlにアクセスしたときには、 https://XXXXXXXXXXX.cloudfront.net/test1/ にある index.html ではなく、 https://XXXXXXXXXXX.cloudfront.net/ = <test-bucket> にある test1/index.html を呼び出していると考えるべきでしょう。 よって、https://XXXXXXXXXXX.cloudfront.net/test2/ にアクセスしたときのみ存在する <test-bucket> の test2/ という空ファイルをブラウザは解釈できずダウンロードしてしまうということになっているのでしょう。 ちなみに、そのような理由で空ファイルが降ってくるので 今回の場合末尾にスラッシュのない以下のような URL https://XXXXXXXXXXX.cloudfront.net/test1 https://XXXXXXXXXXX.cloudfront.net/test2 はシンプルに access denied になります。 どんな時に問題になるのか 単純に s3 の訳の分からんエラー画面が出るのも驚きですが、突如謎の空ファイルが落とされたら当然ユーザーはもっとびっくりするでしょう。 さらにあなたが cloudfront のエラーページの設定で s3 からくる 403 エラーに適切に対処している場合は大きな問題になります。 空ファイルとはいえファイルはファイル。 オブジェクトが存在するので s3 は 200 で返答してきますのでエラーページの設定に引っかかりません。 せっかくエラーに対処していたのにエラーも起こさずユーザーに謎のファイルを送り付ける姿はかなり不快感を煽るでしょう。 コンテンツとして公開する s3 にはコンソールからフォルダを作らないことをお勧めします。

はじめに 今まで、 Kinesis Data Streams + AWS Lambda Amazon SQS+ AWS Lambdaのバックエンド、 Amazon SNS + Amazon SQS + AWS Lambda といったアーキテクチャをお客様のアプリケーションの中に組み込んできた中で、よくやっていたのが、Lambda Functions内で処理すべきデータか判断する、あるいは、判断を後に任せてとりあえず全部処理したり、不要なデータをスキップしたりしていました。これは、従量課金制のLambdaに対して、本来、処理対象ではないはずの不要なデータを投入し処理し、AWSサービス利用料、処理時間等に多少なりとも影響があったと思います。 　当記事では、その課題の改善につながる、2021/11にリリースされたKinesis Data Streams, Amazon DynamoDB Streams, Amazon SQSをイベントソースとするLambda のEvent Filtering機能について、実際にSAMで環境を構築しデータを投入して実験し、その結果を整理したいと思います。 　ここでの実験結果は私個人が興味で行っているものであり、所属する団体・組織を代表するものではありませんのであらかじめご了承ください。 サマリ EventBridgeのルール定義と同じ方法で条件を記載可能 AWS CLI/SAMで定義可能 イベントソースごとに不一致時の挙動がことなるため注意 Event Filtering機能とAWS サービス Kinesis Data Streams, Amazon DynamoDB Streams, Amazon SQSをイベントソースとするLambda のEvent Filtering機能が出てきたときに、今まで、Event Filteringは他にどんな方法があったのかな？と考えてみました。冒頭で例に挙げた、SNS-SQSの場合は、SNSに対してSQSのSubscriptionを作成する際に、メッセージの属性と値の組み合わせを定義したFilter policiesを適用することで、メッセージのフィルタリングができ、キューに配信されないように制御できました。 　それ以外のサービスとしては、Amazon EventBridgeも該当しますね。Amazon EventBridgeのイベントパターンもイベントをフィルタリングし、必要なイベントをターゲットに転送し、処理を行うことを支援します。 　私は、この二つの機能が頭に浮かびあがりましたが、今回のAWS LambdaのEvent Filtering機能は、Event Bridgeのイベントパターンの定義形式と同じ形式するものであり、EventBridgeをご利用されている方（あるいは、その前身のCloudWatch Events)には、非常になじみやすいものかなと思います。 機能の特徴と利用時の注意点 さて、当機能の特徴を簡単に整理するとともに、私が個人的に注意すべきだなと思った点を整理します。 特徴 対象となるサービス 対象は、Event Source Mappingで定義されるサービスの中で、 Kinesis Data Streams Amazon DynamoDB Streams Amazon SQS が対象です。したがって、同期で呼ばれる場合や、非同期で呼ばれた場合、また、上記以外のAmazon Managed Streaming for Apache Kafkaは対象外です。 フィルタの定義と処理 上限 1つのイベントソースに対して最大5個まで、１つのフィルターには最大2048 文字まで定義できます。(2048文字については執筆時点では、こちらに記載がありました。) 前述した通り、Amazon EventBridgeのEvent Patternと同じ文法で定義できます。 イベントとフィルタ定義 各イベントソースからLambdaに届くイベントは例えば、各イベントソースとなるAWSサービスが付与するメタデータの部分と、イベントソースのアプリケーションプログラムがセットするデータで構成されます。フィルタ定義はこの両方に対して、フィルタルールを指定可能です。例えば、「Null」「空文字」「存在する・存在しない」から「一致する・前方一致」「数値データに対するXXX以上、XXX以下」や「AND/OR/NOT」も指定可能です。定義は、AWS CLIやSAMでも可能です。JSONでの定義は私は苦手なので、この後の検証では、SAMで検証します。 動き イベントがAWS Lambdaに届くと、まず定義されたFilterに一致するか判断され、その後、「バッチ（Lambda 関数に渡すイベントまとまり）」を作りバッチ単位にLambda関数が起動されます。 図はこちらから引用 複数のフィルタを定義した場合、どれか1つのフィルタに対象レコードまたはメッセージが一致すれば、関数が起動されます。 これにより、不要なイベントが排除されて、Lambda関数は起動されず、Lambda関数のAWSサービス利用料の削減につながります。 一方、私が気になるのは、Kinesis Data Streamsの読み取りキャパシティです。このEvent Filterを利用することで、１つのStreamに対して特定のイベント用のLambdaを複数付け、それぞれが自分が処理したいデータだけをFilterで定義すると楽ちんだな～と考えたためです。これは、どういう動きになるのか、後で検証してみたいと思います。 　なお、フィルターと不一致な場合の動きについては、後述の注意点で記載しますがイベントソースごとに異なるようです。 注意点 SQS利用時のメッセージフォーマットとフィルタ SQS のメッセージのフォーマットは利用者が任意に決められます。例えば、BodyはPlain TextかもしれませんしJSONで構造化されているかもしれません。 PlainText This is Test Message. Timestamp is 2021-12-01T09:00:00 Json { "message" : "This is Test Message" "timestamp" : "2021-12-01T09:00:00" } 上記のようにメッセージのフォーマットは任意ですが、その形式により挙動が変わります。なお、後述のKinesis Data Streams/DynamoDB Streamsの場合は、JSONデータであることが前提となっており、SQSと異なります。 SQSの挙動の詳細はこちらに定義されていますが、一部簡単に表現するとこのような形です。 Message Format データ(body)に対するフィルタ定義 挙動 Plain Text Plain Text 条件に基づいて評価 Plain Text JSON Drop JSON Plain Text Drop Kinesis Data Streams/DynamoDB Streams利用時のメッセージフォーマットとフィルタ SQSの場合は前述した通り、JSONもPlain Textも対応しましたが、それとは異なり、Kinesis Data Streams/DynamoDB Streamsのデータプロパティは(Kinesis の場合はdata,DynamoDB Streamsの場合はdynamodb) JSONとなります。 詳細はこちらに記載がありますが、一部抜粋すると以下のような形ですね。 Message Format データ(body)に対するフィルタ定義 挙動 Valid JSON Valid JSON 条件に基づいて評価 Valid JSON Non JSON Filter定義時に例外が発生 Non-JSON Valid JSON Drop Non-JSON Non JSON Filter定義時に例外が発生 フィルターと不一致だったイベントに対する挙動 SQSの場合も、Kinesis Data Streamsの場合もDropという表現が登場しました。また、そもそも、適切に評価されて、不一致と判定されたデータがどう言う動きになるのかが重要です。 観点 Kinesis/DDB SQS 不一致の場合 対象レコードは処理されたとみなされスキップして次に進む メッセージがキューから削除される Dropの挙動 先に進む メッセージが削除される イベントソースごとに異なるイベントデータ 前述した通り、例えば、Kinesis Data Streamsの場合は、ユーザーがPut Recordしたデータは、"data"属性内にセットされますが、Amazon SQSでSendMessageしたデータは、"Body"内に格納されます。イベントソースにってフィルタを書く際には当然メタデータも変わってきますので注意してください。 バッチウィンドウとバッチサイズ バッチに入るデータは、Filterで一致したデータのみとなります。仮にバッチウィンドウを今までは30秒、バッチサイズを100件としていた場合、Filter定義を追加したことで、バッチサイズがバッチウィンドウ内に満たされず、実質、時間でトリガーするようなケースが発生するかもしれません。早急に処理したい場合は、それでよいですが、ある程度まとめて処理したい場合、バッチウィンドウを今までより伸ばすことで影響を小さくする可能性があります。 文字列 vs 文字列による比較 Lambdaは、フィルタを処理する際、「文字列」で比較するため、300と300.0の用に数値的に同じ値となるものでも、異なる値として判断します。 試してみたいこと 今回は、Kinesis Data StreamsとSQSをイベントソースにして以下を試したいと考えます。 1.基本動作確認として、Dropはどんな動きになるか目視したい（願望） 対象：SQS/Kinesis 内容：不一致なデータはどう処理されるのか確認する。 2.Kinesis Data Streamsで消費されるキャパシティユニット 対象：Kinesis 内容：Batchに入らない場合でもキャパシティユニットが消費されるか。10000件入れたけど、1件も一致しない場合もキャパシティユニットは消費されるか 3.条件に一致するけどエラーが繰り返された場合の動き対象：Kinesis 内容：バッチ内でエラーが繰り返されたら、バッチはどうなるのか。Destinationsに不一致メッセージは移動するのか - 環境構築 はい、それでは、ここからは色々試していくためにまずは環境準備ということで、今回は、まっさらなCloud9を用意しました。そこに、AWS CLIの最新版の導入手順と、AWS SAMの最新版の導入手順を見ながら、環境を用意します。また、初期サイズではディスクが足りなくなる可能性があることから、念のため、EBSを30GBに拡張することもこちらの手順で実施します。 $ sam --version;aws --version SAM CLI, version 1.36.0 aws-cli/2.4.3 Python/3.8.8 Linux/4.14.252-195.483.amzn2.x86_64 exe/x86_64.amzn.2 prompt/off さて、まっさらな状態からまずは、Ptyhon3.9 そして、従来からあるX86_64を選択しました。のちほどArm, つまり、Graviton2 も試しますが、今回はあまり関係ありません。 SAMのinitの実行 $ sam init --name sam-lambda-eventfiltering --runtime python3.9 --architecture x86_64 Which template source would you like to use? 1 - AWS Quick Start Templates 2 - Custom Template Location Choice: 1 What package type would you like to use? 1 - Zip (artifact is a zip uploaded to S3) 2 - Image (artifact is an image uploaded to an ECR image repository) Package type: 1 Cloning from https://github.com/aws/aws-sam-cli-app-templates AWS quick start application templates: 1 - Hello World Example 2 - EventBridge Hello World 3 - EventBridge App from scratch (100+ Event Schemas) 4 - Step Functions Sample App (Stock Trader) 5 - Elastic File System Sample App Template selection: 1 ----------------------- Generating application: ----------------------- Name: sam-lambda-eventfiltering Runtime: python3.9 Architectures: x86_64 Dependency Manager: pip Application Template: hello-world Output Directory: . Next application steps can be found in the README file at ./sam-lambda-eventfiltering/README.md Commands you can use next ========================= [*] Create pipeline: cd sam-lambda-eventfiltering && sam pipeline init --bootstrap [*] Test Function in the Cloud: sam sync --stack-name {stack-name} --watch treeをyumで導入して実行すると現在こんな感じでディレクトリが構成されています。 フォルダ構造 $ tree . ├── events │   └── event.json ├── hello_world │   ├── app.py │   ├── __init__.py │   └── requirements.txt ├── __init__.py ├── README.md ├── template.yaml └── tests ├── __init__.py ├── integration │   ├── __init__.py │   └── test_api_gateway.py ├── requirements.txt └── unit ├── __init__.py └── test_handler.py 5 directories, 13 files こんな状態ではありますが、さっき実行したsam initの最後の部分にCommands you can use next が表示されてます。ここで紹介されているコマンドは、sam pipeline と言いましてCICD Pipelineを簡単に準備してくれる今年出た機能です。こちらは、コンテナ Lambda の CI/CD パイプラインを SAM Pipeline で作ろう !を参照してみてください。 さて、ローカルにアプリケーションを構築できる状態になったので、まずは、SQS/Kinesis Data StreamsとLambda関数を作りたいと思います。今回はこのテンプレートで構成しました。 SAMテンプレート template.yml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > sam-lambda-eventfiltering Globals: Function: Timeout: 20 Resources: #### Message Producer Kinesis KinesisClientFunction: Type: AWS::Serverless::Function Properties: CodeUri: KinesisClient/ Handler: app.lambda_handler Runtime: python3.9 Architectures: - x86_64 Environment: Variables: STREAM_NAME: !Ref Stream Policies: - Version: '2012-10-17' Statement: - Effect: Allow Action: kinesis:PutRecord Resource: - !GetAtt Stream.Arn #### Message Producer SQS SQSClientFunction: Type: AWS::Serverless::Function Properties: CodeUri: SQSClient/ Handler: app.lambda_handler Runtime: python3.9 Architectures: - x86_64 Environment: Variables: QUEUE_URL: !Ref Queue Policies: - Version: '2012-10-17' Statement: - Effect: Allow Action: sqs:SendMessage Resource: - !GetAtt Queue.Arn #### Consumer Function SQS - SQSFunction: Type: AWS::Serverless::Function Properties: CodeUri: hello_world/ Handler: app.lambda_handler Runtime: python3.9 Architectures: - x86_64 Events: SQSEvent: Type: SQS Properties: Queue: !GetAtt Queue.Arn BatchSize: 10 MaximumBatchingWindowInSeconds: 10 Enabled: True FilterCriteria: Filters: - Pattern: '{"body": {"PRIORITY": [ { "numeric": [ "=", 101 ] } ]}}' #### Event Source SQS Queue: Type: AWS::SQS::Queue Properties: RedrivePolicy: deadLetterTargetArn: !GetAtt DeadLetterQueue.Arn maxReceiveCount: 3 DeadLetterQueue: Type: AWS::SQS::Queue #### Consumer Function Kinesis KinesisDataStreamsFunction: Type: AWS::Serverless::Function Properties: CodeUri: KinesisFunction/ Handler: app.lambda_handler Runtime: python3.9 Architectures: - x86_64 Events: KinesisEvent: Type: Kinesis Properties: Stream: !GetAtt Stream.Arn StartingPosition: TRIM_HORIZON BatchSize: 100 MaximumBatchingWindowInSeconds: 100 MaximumRetryAttempts: 2 DestinationConfig: OnFailure: Destination: !GetAtt KinesisDestinationQueue.Arn Enabled: True FilterCriteria: Filters: - Pattern: '{"data": {"PRIORITY": [ { "numeric": [ ">", 100 ] } ]}}' Policies: - Version: '2012-10-17' Statement: - Effect: Allow Action: sqs:SendMessage Resource: - !GetAtt KinesisDestinationQueue.Arn - KinesisDestinationQueue: Type: AWS::SQS::Queue #### Event Source Kinesis Stream: Type: AWS::Kinesis::Stream Properties: Name: LambdaEventFileringStream RetentionPeriodHours: 24 ShardCount: 1 さて、上記のテンプレートで注目すべきは、Consumerとして実装したKinesis/SQS用の関数のEvents句です。それぞれ、SQS/Kinesisを指定していますが、以下のような条件式が定義されています。t同じメッセージをKinesisとSQSに投入していますが、データプロパティを示す属性が異なります。（dataとbody） KinesisFilter FilterCriteria: Filters: - Pattern: '{"data": {"PRIORITY": [ { "numeric": [ "<", 100 ] } ]}}' SQSFilter FilterCriteria: Filters: - Pattern: '{"body": {"PRIORITY": [ { "numeric": [ "<", 100 ] } ]}}' ちなみに、メッセージのProducerの関数でPutするメッセージは以下のような形です。つまり、上記条件式は、PRIORITYが100未満だったらバッチに加わることになります。各値はrandomで生成しています。 message.json { "EVENT_TIME": "2021-12-01T12:24:55.045103", "ID": "ID-923760", "PRICE": 87907, "PRIORITY": 99 } 実験結果 1.基本動作確認として、Dropはどんな動きになるか目視したい（願望） 対象：SQS/Kinesis 内容：不一致なデータはどう処理されるのか確認する。 予想：スキップ？ 期待：条件に一致するものは処理、しないものは放置。 方法：SQSの標準キュー/Kinesis Data Streamsのストリームに前述の形式のメッセージで、PRIORITYを1~10になるデータを数百件件投入。 適用するフィルタ条件式はこちら。 KinesisFilter FilterCriteria: Filters: - Pattern: '{"data": {"PRIORITY": [ { "numeric": [ "=", 1 ] } ]}}' 結果：SQSとKinesisで動きが違う。 項目 SQS Kinesis データの扱い PRIPRITY=1のデータのみ処理された PRIPRITY=1のデータのみ処理された 不一致データの扱い キューからメッセージを削除された 該当のレコードをスキップして次に進んだ。もちろん、再利用、別プロセスによる処理も可能 推測 DeleteMessageがされた 全レコードGetRecordsでレコードが読み取られて進んだ 考察 不一致データを一切処理しなくてよいなら、利用してもよい 必要なデータだけを処理できて便利。 SQSの場合、メッセージが削除されてしまうので本当に不要なメッセージなのであれば、この機能が有効活用できますね。ただ、不要なメッセージは事前に送らないのがベストだなとは思います。また、SNS-SQS連携しているのであれば、冒頭に書いたSNSのSubscriptionのFilterを定義することで、そもそもSQSに入らないためそこで処理したいですね。 ということで、私が次に気になるのは、Kinesis!!! Kinesis のバックエンドでレコードの内容に応じて、異なる複数の処理に分岐するような場合、今回のFilterが使えるんじゃないか？という点ですが、その際に気になるのが、キャパシティユニット。きっと、消費されるんだろうな～ということで動きを次の検証で確認したいと思います。（正式に消費されるかされないかは、AWSサポート等にご確認いただければ・・） 2.Kinesis Data Streamsで消費されるキャパシティユニット 対象：Kinesis 内容：Batchに入らない場合でもキャパシティユニットが消費されるか。数万件入れたけど、1件もフィルタ条件に一致しない場合もキャパシティユニットは消費される? 予想：消費される。 期待：消費されないなら、めちゃスゴイ。 方法：Kinesis Data Streamsのストリームに前述の形式のメッセージを数万件投入。 投入後にEventSource Mappingを一斉に有効化し、CloudWatch Metricsでメトリクスの推移を確認する。なお、ConsumerのLambda関数を（界王拳）10倍にして読取スロットリングが起きるかメトリクスで確認する。 EventSource Mappingの有効化は以下の Enabled: TrueをFalseなら無効、Trueなら有効で切り替えが可能。 template.yml KinesisDataStreamsFunction: Type: AWS::Serverless::Function Properties: #(省略) Events: KinesisEvent: Type: Kinesis Properties: #(省略) Enabled: True FilterCriteria: Filters: - Pattern: '{"data": {"PRIORITY": [ { "numeric": [ "<", 0 ] } ]}}' 結果：Kinesisの読み取りでスロットリング起きたよ（想定通り。Lambdaがフィルタで判定するために読み取るからね）。Lambdaは1件も起動されてないよ（想定通り：条件に一致するメッセージは1件もないため）。画面の右下がLambdaのメトリクス。1件も起動されてないので何も出てこない。画像上部には、5分間で読み取ったデータ量も表示されており、ばっちり読み込まれてますね。ちなみに、読み込まれてることが確認できればスロットリングを起こす必要はないのですが、あえて起こしてみました。趣味です。 3.条件に一致するけどエラーが繰り返された場合の動き 対象：Kinesis 内容：バッチ内でエラーが繰り返されたら、バッチはどうなるのか。Destinationsに不一致メッセージは移動するのか 予想：移動しない。移動するのは、フィルタ条件に一致して繰り返し処理されたメッセージのみ 方法：Kinesis Data Streamsのストリームに前述の形式のメッセージを投入。ConsumerのLambdaで常にErrorになるように対応。Filterにマッチしたレコード以外のレコードがDLQに移動しているか確認 結果：　フィルタ条件にマッチしたデータでLambdaがエラーと応答したデータのみ。 今回は、Filterの条件と一致するメッセージを1件、不一致のメッセージを10件投入して動作確認しました。 まず、ログデータ。メッセージの投入。12/02 17:17:41秒前後に投入しています。 Concumer側のLambdaが動きました。。 STARTを3回しています。が3回とも[ERROR]で終わってます。存在しないデータにアクセスしているためですね。 ここで、なぜ3回なのかというと、以下の設定をEventの定義にしていたため、初回動いた後、2回リトライをしたわけです。そして、2回リトライした後は、Dead Letter Queue に移動しています。 MaximumRetryAttempts: 2 ちゃんとキューには、1件だけメッセージがあります。 {"requestContext":{ "requestId":"382ff016-8403-4d4d-be02-aa76ef52b620", "functionArn":"arn:aws:lambda:ap-northeast-1:123456789012:function:sam-lambda-eventfiltering-KinesisDataStreamsFuncti-1Q3pbmbZ7OWW", "condition":"RetryAttemptsExhausted", "approximateInvokeCount":3 }, "responseContext":{ "statusCode":200, "executedVersion":"$LATEST", "functionError":"Unhandled" }, "version":"1.0", "timestamp":"2021-12-02T08:19:22.397Z", "KinesisBatchInfo":{ "shardId":"shardId-000000000000", "startSequenceNumber":"49624442129468525601182640052593233276102295172440653826", "endSequenceNumber":"49624442129468525601182640052593233276102295172440653826", "approximateArrivalOfFirstRecord":"2021-12-02T08:17:42.226Z", "approximateArrivalOfLastRecord":"2021-12-02T08:17:42.226Z", "batchSize":1, "streamArn":"arn:aws:kinesis:ap-northeast-1:123456789012:stream/LambdaEventFileringStream"}} 上記のデータより、最初に到着したおよその時刻は、approximateArrivalOfFirstRecord":"2021-12-02T08:17:42.226Z"、つまり、Producerでメッセージを送信した時間であり、"timestamp":"2021-12-02T08:19:22.397Z"から初回のエラー発生後2回目を終えたこの時間に、DLQに自動で移動したと判断でき、特に違和感はないです。 さて、既にお気づきかもしれませんが、ProducerがキューにメッセージをPutしてから、Consumerが処理を開始するまでに、100秒の差があります。これは何か？それは、Eventに定義した2つの属性が関わっています。 template.yml BatchSize: 100 MaximumBatchingWindowInSeconds: 100 これは、以下の二つのOr条件として定義しているものです - バッチのサイズが100になったら起動してね - 100秒待ってもバッチがいっぱいにならなかったら起動してね。 今回は処理対象のメッセージが1件だったので、BatchSizeを満たすことができず、MaximumBatchingWindowInSecondsである100秒間、待っていました。 ということで、処理対象のメッセージが10件、BatchSizeも10だったら起動時間がどうなるのか最後に試したいと思います。 template.yml BatchSize: 10 MaximumBatchingWindowInSeconds: 10 MaximumRetryAttempts: 2 Producerが一致するデータを10件投入。（1件不一致） 1秒後には、Consumerが起動 終わりに Filtering機能、簡単に定義ができ、自身が処理すべきメッセージだけを処理することが可能です。とはいえ、EventSource側には、読み取りキャパシティユニットの消費やAPIコールが発生するわけですから、不要なメッセージを入れないに越したことはありませんが、Consumer側でフィルタリングが必要な場合には簡単に実装ができてとても良いなと思いました。

ルートユーザーとIAMユーザー AWSアカウントのルートユーザーとは AWSアカウントを作成した時に用意したEメールアドレスとパスワードを使用してサインインできるアカウントのこと。 ルートユーザーは、請求情報など支払いに関連したものも含めた、AWSの全てのサービスとリソースに対して無制限にアクセス可能で、解約などの契約変更も実行可能。 AWSでは、このルートユーザーを日常の業務で使用するべきではないとしており、管理者として作業する場合も、必要な権限を付与したIAMユーザーを使用することを強く推奨している。 ルートユーザーの安全を確保するためにやっておくべきこと セキュリティ面 パスワードを変更する MFA(多要素認証)を有効にする ルートユーザーのアクセスキーは作成しない もし発行されていた場合は削除を検討/実施 ルートユーザーの代替となる管理者用のIAMユーザーを作成する IAMユーザーに対してMFA(多要素認証)を有効にする コスト管理面 IAMユーザー/ロールでの請求情報アクセスを有効化 AWS Cost Explorerの有効化 請求アラートの設定 日本円建てによる支払い設定 操作履歴を残すよう設定（CloudTrail) CloudTrailは操作ログをCloudTrail(S3)に記録する設定にすると課金対象になってしまうとのことで今回は見送ることにした。以下サイト参照のこと。　もう少し理解できたら設定してみたい。 ※ 設定方法等、詳細については各項目の参考サイトを参照すること。 管理者権限のあるIAMユーザーの作成方法 やってみようシリーズ：IAMアカウントを作ってみよう-IAMポリシー解説編- 最初の IAM ユーザーを作成します。この IAM ユーザーを管理者グループに追加し、アカウントですべてのサービスおよび各サービスのリソースにアクセスできるようにします。次回 AWS アカウントにアクセスするときは、この IAM ユーザーの認証情報を使用してサインインします。 IAMポリシーとは IAMポリシーとは、「どのAWSサービスの」、「どのリソースに対して」、「どんな操作を」、「許可するか(許可しないか)」、を権限とし、利用者（IAMユーザーなど）に対して設定することが出来る定義 IAMポリシーの種類 IAMユーザーに対してアタッチをする「ユーザーベースのポリシー」 AWSリソースに対してアタッチをする「リソースベースのポリシー」 IAMロールに対してアタッチをする「IAMロールの信頼ポリシー」 今回は、IAMアカウント作成し、権限を適用することが目的の為、「ユーザーベースのポリシー」についてのみ説明する。 本来は、IAMポリシーを用意する必要があるが、管理者権限を付与したい時は、IAMポリシーは自分で作る必要がない。 なぜなら、よくあるパターンのIAMポリシーは、事前にアマゾンウェブサービス上に用意されている為。 ただ、用意されている物だけでも717件が登録されている（2021/11現在）。 どんな種類のIAMポリシーが存在するかを知ることが大変ですね。全てを覚えることは天才であっても難しいと思いますので、どのような権限が必要かを検討いただき、AWSのテクニカルサポートに問い合わせるなどして、必要なポリシーを特定していきましょう。 上記サイトは、AWS　のドキュメント「IAM のベストプラクティス」をできるだけ具体的に解説したサイト。 管理者として、ルートユーザーの次に最大の権限が設定してある「AdministratorAccess」ポリシーを付与します。 今回は、管理者としてのIAMユーザーを作成するため、[AdministratorAccess] のポリシーを選択する。 この際、各ユーザーにきちんとポリシーが割り当てられていることを確認しやすくするため、ユーザーにポリシーを付与するのではなく、グループにポリシーを付与する。 AWS公式では、多くの場合、ロールで最低限の権限付与をすることを推奨しています。参考までに。 多くの場合、期限のない長期のアクセスキー (IAM ユーザーのアクセスキーなど) は必要ありません。その代わり、IAM ロールを作成し、一時的なセキュリティ認証情報を生成できます。 IAMアクセスキーが必要なのは、AWSの外部からAWSアカウント内のサービスに対してアクセスを行う必要があるときのみです。 AWSの内部からAWSの各サービスを利用する場合は原則としてIAMロールを使用してください。 また、使う必要がないのにアクセスキーを発行することがないようにしましょう。 ・　IAMロール(Role)　＝　「AWSのリソースに付与するもの」で、IAMポリシーをグルーピングしたもの ・　IAMポリシー(policy)　＝　「AWSリソースにアクセスするための権限設定」 IAMユーザーに対してMFA(多要素認証)を有効にする 作成したIAMユーザーに対してもMFAの設定を行い、セキュアにしておきましょう。 IAMユーザー/ロールでの請求情報アクセスを有効化 AWSアカウント発行時のデフォルト設定では、請求情報の参照はルートユーザーでのみ可能な状態となっています。ルートユーザーを普段使いしないで済むようにする為にも、別途作成の管理用IAMユーザーにて請求情報参照を可能にする「IAMユーザー/ロールによる請求情報へのアクセス」設定の有効化(IAMアクセスのアクティブ化) を実施すると良いでしょう。 実施後、IAMユーザー/ロールに必要なIAMポリシーを付与する事で請求情報へのアクセスが可能となります。 IAM アクセスをアクティベートするだけでは、これらの請求情報と予算管理コンソールページに必要な許可は IAM ユーザーとロールに付与されません。IAM アクセスのアクティベートに加えて、必要な IAM ポリシーをこれらのユーザーまたはロールにアタッチする必要があります。詳細については、「請求情報とコスト管理での ID ベースのポリシー (IAM ポリシー) の使用」を参照してください。 IAM アクセスをアクティベートする 下記サイトは請求情報とコスト管理コンソールへの IAM ユーザーおよびロールのアクセスをアクティベートする方法を画像付きで具体的に説明している。 IAM ポリシーをユーザーまたはロールにアタッチする 今回は個人開発のため、全ての予算関係にアクセスできるポリシーを作成し、IAMユーザーに付与した。 下記サイトはIAM ポリシーをユーザーにアタッチする方法を画像付きで具体的に説明している。 AWS Cost Explorerの有効化 AWS Cost Explorerは、AWSの利用状況を可視化し分析できるサービス。 サービスごとのコスト、月毎のコスト推移を確認できます。また、コストと使用量のデータを分析して傾向・異常などを特定できるため、運用分析をする際に便利な機能です。ぜひ、設定しておくことをオススメします。 設定方法は下記サイト参照。 請求アラートの設定 予算管理のアラートにはいくつか種類がある。 AWS Budgetsのアラート機能 予算に対してアラートを設定できる。 AWS Budgetsで予算の設定をすると、閾値を超えた際にSNS通知（又は直接Mail）が可能です。 閾値は複数設定もできます。 予測コストに対して設定ができるのも利点です。（現在値に対して設定する事も可能） アラート以外に「予算アクション」も設定できて、インスタンスを停止したりIAMポリシーを書き換えて操作を禁止したりもできます。 AWS Budgets Actions とは（Serverworks blog） アラート機能自体は、登録された予算2つまでは毎月無料。アクションは有料。 AWS Budgets の注意事項 注意点として以下3点を紹介します。 IAMユーザの制限事項 AWS初期設定では、IAMユーザで請求情報を参照できず、ルートユーザで権限の変更が必要となります。 コスト予測の利用開始条件 予測コストの算出には、最低5週間の利用データが必要となります。 利用データが不足している状態、アラームは実行されませんので注意が必要です。 予算の更新周期 　 + AWS請求データの更新周期(1日1回以上)と連動しており、ユーザ側で指定は出来ません。 CloudWatchを使用した請求アラート AWS Budgetsができる前からある機能。 リソース毎に請求アラートを設定するなどの細かい設定には対応できない。 AWS コスト異常検出（AWS Cost Anomaly Detection） 前述の２つと役割が違い、普段のコスト変化が自動的に学習されて異なる変化があった際に通知がされます。 例えば検証でインスタンスを作成して消し忘れたなど。 ほか意図せず急にコストが増えた時の保険として設定しておくと良いと思います。 FAQに無料と記載されている。 今後、細かい設定をするかもしれないので、今回はAWS Budgetsのアラートを設定する。 AWS Cost Anomaly Detectionも無料のため、設定することにした。 AWS Budgetsのアラート機能 設定 AWS Budgetsのアラート機能設定方法は以下の動画を参考に。 https://youtu.be/SuWtEKDr_Po 日本円建てによる支払い設定 AWSの支払い方法は、クレジットカード払い、請求書払い、請求代行払いがあります。 クレジットカード払いの場合、利用者自身でデフォルト設定の米ドル請求から円建て払いに変更する必要があります。日本円を選択することで、外貨取扱手数料に相当する費用を削減することが可能です。コスト削減のためにも、設定変更をオススメします。 設定方法は下記サイト参照 その他参考サイト

はじめに どーも、のぶこふです。 この記事はGFAMアドベントカレンダー2021の3日目の記事です。 前回、アカウントを作成したので、お次はVPC（仮想ネットワーク）ですね。 このVPC内で、ほとんどの様々なリソースを起動していきます。 今回のサービス一覧 Service名とか 概要 VPC ネットワーク空間 Subnet VPCを論理的に分割 リージョン データセンタの場所（国とかの単位） AZ リージョンを物理的に分割 Internet Gateway インターネットからアクセスできるようにするよ NAT Gateway PrivateSubnetからインターネットアクセスしたい Route Table ネットワーク経路が記載されたテーブル Security Group インスタンス単位でのファイアウォール 関係性 名前とか文章だけだと分かりづらいので、図にしてまとめると、こんな感じです。 VPC1 VPC：Virtual Private Cloud AWS上にプライベートネットワーク空間を構築 任意のIPアドレスレンジが利用可能 論理的にネットワーク分離が可能 必要に応じて、ネットワーク同士の接続が可能 ネットワーク環境のコントロールが可能 ルートテーブル、各種ゲートウェイ、各種コンポーネント 複数のコネクション方法が選択可能 インターネット経由 VPN・専用線（Direct Connect） 作成時に、デフォルトでルートテーブルが作成される VPC Endpoint？ グローバルIPを持つAWSサービスに対して、VPC内部から直接アクセスするための出口 その仕組みから、Gateway型とPrivateLink、Gateway LoadBalancerに分類されます Gateway型 PrivateLink (Interface型) 対応サービス S3、DynamoDB 50種以上 アクセス制御 エンドポイントポリシー セキュリティグループ 利用料金 無料 有料（1プライベートIP毎） 冗長性 ユーザ側で意識不要 マルチAZ設計する VPC Flow Logs？ ネットワークトラフィックをキャプチャして、CloudWatch LogsやS3へPushする機能 ネットワークインタフェースを送信元・先とするトラフィックが対象 RDS、Redshift、ElasciCache、WorkSpaceのネットワークインタフェーストラフィックも取得可能 CIDR VPCやSubnetで出てくるのが、CIDRです。 CIDRについては、Wikipedia大先生2におまかせしますが、自身でVPCやSubnetを作成する際は、ざっくりと概念は理解しておいた方が良いと思います。 Subnet VPC内に構成するネットワークセグメント 1つのVPCに対して、1つ以上のサブネットで構成される Public Subnet、Private Subnet？ デフォルトゲートウェイへのルーティングによって変わる Public Private インターネットゲートウェイをアタッチして・・・ いる いない インターネットからのアクセス 可能 不可能 通信先（デフォゲ） インターネットゲートウェイ だいたいNAT Gateway よくある構成 APサーバ DBサーバ リージョン3 データセンターが集積されている世界中の物理的ロケーション 論理データセンターの各グループを、AZという（後述） AZ AZ：Availability Zone 1リージョン内にAZが複数存在 AZはお互いに地理的・電源的・ネットワーク的に分離 2つのAZを利用した冗長構成を容易に構築 リージョン内のAZ間は、高速専用線で接続 リージョン間も可能な限り高速専用線で接続 Internet Gateway4 VPCとインターネットとの間の通信を可能にするVPCコンポーネント インターネットでルーティング可能なトラフィックの送信先をVPCのルートテーブルに追加する Public IPv4アドレスが割り振られているインスタンスに対して、NAT（ネットワークアドレス変換）を行う IPv4トラフィックとIPv6トラフィックをサポート 利用料金無し NAT Gateway マネージドNATサービス プライベートサブネットのリソースが、インターネット・AWSクラウドへの通信をするために必要 EIPを割り当て、高パフォーマンス、高可用性 AZ毎に設置するのがベストプラクティス Route Table5 VPCに暗黙的に存在するルータの経路設定 EC2インスタンスから見るとデフォゲ Security Group6 インスタンス単位の仮想ファイアウォール インバウンド・アウトバウンドトラフィックをコントロール 許可ルールが指定可能 インバウンドとアウトバウンドのルールを個別に設定可能 デフォルトのインバウンドは「設定無し＝全て拒否」 デフォルトのアウトバウンドは「全て許可」 ステートフル ネットワークインタフェースに関連付けられる セキュリティグループの作成時に指定したVPCでのみ使用可能 AWSのサービス サービスによって配置される場所が異なります。7 サービスによっては、通常ではグローバルサービスだけど、リージョンだと・・というのもあります8 サービス 概要 例 グローバルサービス リージョンをまたがって世界で共通なサービス Route 53、Chime、WorkSpaces・・・ リージョンサービス リージョンごとに作成、管理するサービス VPC関連、DynamoDB、Code兄弟・・・9 AZサービス AZごとに作成、管理するサービス EC2、RDS・・・ おわりに 今回は、VPC周りを少し整理してみました。 今回上げたサービスのほとんどが「初めて触る人用」として、AWS側でデフォルトが用意されています。 なので、EC2を開始する時などにも「使ったことが無い」という方は多いかと思います。 これらのデフォルトで用意されているものは、あくまでも初めて触る人にむけてのもの。 VPCなどは自分で設計や構築していくのが、AWSの基本だと思います。 操作や概念に慣れてきたら、デフォルトのものは使わずに、自分で設定してみましょう。 今回はここまでです。 ありがとうございました。 BlackBeltさまさまです ↩ Wikipedia大先生 ↩ リージョンとAZは、公式から ↩ 公式ドキュメント ↩ BlackBelt ↩ 公式ドキュメント ↩ 『元オンプレエンジニアのAWS (Amazon Web Service) 自己学習メモ』さんより ↩ 例えば、Route53 ↩ リージョン毎のサービス ↩

■ActiveDirectoryの構築 新規サーバ構築に伴ってADを構築することになったのですが、思った以上にわからないことが多かったのでメモとして残します。 ◇現状 ・資産管理ソフト(SKYSEAやLanScopeCat等)でクライアントPC(約350台)を管理 ・従業員はオンラインストレージにデータを入れており、ファイルサーバは無し ・下記の課題は感じつつも、AD導入の大変さを考えると導入の優先度低い ◇AD導入で解決したかった課題 ・クライアントPCのOSパスワードが変更できない ・データ容量が増えてきたので、サブストレージとしてファイルサーバ構築を検討 　　※オンラインストレージを増量したいが、コストの問題でファイルサーバが現実的 ・Saasが増えてきたのでシングルサインオンしたい ◇悩んだ点 ・ActiveDirectoryが基本過ぎるのか、初心者向け情報が意外と少ない ・AWS MicrosoftAD構築情報は多く見つけられたが、基本的なADの運用方法を見つけるのに苦労 ・AWS MicrosoftADで必要となるDHCPオプションセットがVPC単位でしか適用できない 　　※ひとつのVPCで運用していたので、既存環境への影響調査に時間がかかった ・AWS MicrosoftADは直接操作できず、「管理ツールを入れたサーバが必要」がわかるまで時間がかかった ◇結論 最終的に下記の2記事だけで構築できることが理解できた。 ■ActiveDirectoryのポリシー設定 ◇ユーザーアカウントの作成 ◇ユーザーアカウントにログイン権限を付与(RDP接続できるように)する ◇パスワードポリシー設定 (下記ページの[Fine-Grained Password Policiesの使い方]を参照) ◇グループポリシー作成 ◇グループポリシーが適用されない場合の対応方法 ログオンスクリプトが上手く動作しない場合、クライアント側で「gpresult /z」を実行します。 これで適用されたGPOの情報や、実行結果を確認することが出来ます。 gpresult /z 強制的にポリシーを適用する場合は「gpupdate /force」を実行します。 gpupdate /force ■コマンドライン ◇コマンドラインからユーザーを追加したい サンプルコマンド dsadd user "CN= ,OU= ,OU= ,DC= DC= ,DC= " -samid hogehoge -upn hogehoge@fugafuga.co.jp -pwd Password -display hogehoge "CN= ,OU= ,OU= ,DC= DC= ,DC= "の部分に何を入れれば良いのかわからずかなり悩んだ。結果としてADに参加しているPCにて、下記のコマンドを実行すると、 gpresult /R 下記の通り、"CN= ,OU= ,OU= ,DC= DC= ,DC= "の部分に入力するべき内容が表示できることが判明した。 上記の通り、サンプルコマンドに"CN= ,OU= ,OU= ,DC= DC= ,DC= "の部分を貼り付ければコマンド実行可能。 ◇コマンドラインから権限を付与(グループに所属)したい 例えば、user1にadministrators権限を付与したい場合は、そのサーバにログインして下記コマンドで実行する。 net localgroup administrators user1 /add

この記事は ハンズラボ AdventCalendar2021　3日目の記事です。 はじめに 今回は、こちらの記事のCDK化(Python)を行っていきます。 構成やcfnテンプレートなど詳細はこちらをご参照ください。 前提条件 GitHub Actions OpenID Connect (OIDC) で多段 AssumeRole するを読み構成を理解していること CDKがインストールされ実行環境が準備されていること 実装 ではさっそくやっていきます。 初期設定 ディレクトリを作成し、cdk initを実行してプロジェクトを立ち上げます。 $ mkdir github_oicd $ cd github_oicd $ cdk init app --language python これで準備完了ですので、早速コーディングしていきます。 Provider作成 まずはProviderを作成していきます。 ここはドキュメント通りに値をセットするだけですので、簡単に実装できました。 ドキュメントはこちら github_oicd_stack.py github_oidc_provider = iam.OpenIdConnectProvider(self, client_ids=["sts.amazonaws.com"], thumbprints=["a031c46782e6e6c662c2c87c76da9aa62ccabd8e"], id="GithubOicdProvider", url="https://token.actions.githubusercontent.com", ) bastion_role（踏み台ロール)作成 ここから少し難易度が上がった印象です。 Principalに先ほど作成したProviderを設定する箇所でかなり苦戦しましたが、最後はドキュメントが助けてくれました。 （最初からドキュメントちゃんと読めという話ですが、、） 助けてくれたドキュメント達 ( Role, FederatedPrincipal, PolicyDocument, PolicyStatement ) github_oicd_stack.py GitHubOrgName = "example" GitHubRepoName = "example" conditions = { "StringEquals" : { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike" : { "token.actions.githubusercontent.com:sub" : f"repo:{GitHubOrgName}/{GitHubRepoName}:*" } } bastion_role = iam.Role(self, assumed_by=iam.FederatedPrincipal( github_oidc_provider.open_id_connect_provider_arn, conditions=conditions, assume_role_action="sts:AssumeRoleWithWebIdentity" ), path="/", inline_policies={ "AssumeRolePolicy": iam.PolicyDocument( statements=[ iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=["sts:GetCallerIdentity"], resources=['*'] ), iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "sts:AssumeRole", "sts:TagSession" ], resources=["*"] ) ] ) }, id="BastionRole", role_name="BastionRole", ) deploy_role(デプロイ用ロール)作成 最後のロール作成です。 ここが一番難しかったです。 一度に複数のStatementを設定したかったのですが、想定している設定がなかなかできなかったので、最初に1つ設定して後付けしています。 新たに助けてくれたドキュメント達 ( ArnPrincipal, PrincipalWithConditions ) github_oicd_stack.py ExternalId = "example1234" aws_principal = iam.ArnPrincipal( arn=bastion_role.role_arn, ) # add condition aws_principal_with_condition = iam.PrincipalWithConditions(aws_principal, { "StringEquals": { "sts:ExternalId": ExternalId } }) github_actions_deploy_role = iam.Role(self, assumed_by=aws_principal_with_condition, id="GitHubActionsDeployRole", path="/", role_name="GitHubActionsDeployRole", ) # add policy github_actions_deploy_role.assume_role_policy.add_statements(iam.PolicyStatement( actions=["sts:TagSession"], principals=[ aws_principal.grant_principal, ], )) この様に書くと以下の様なポリシーになります。 完璧です。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{AccoutID}:role/BastionRole" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "example1234" } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{AccoutID}:role/BastionRole" }, "Action": "sts:TagSession" } ] } 完成系 github_oicd_stack.py from aws_cdk import ( aws_iam as iam, core, ) class AwsCdkOicdStack(core.Stack): def __init__(self, scope: core.Construct, construct_id: str, **kwargs) -> None: super().__init__(scope, construct_id, **kwargs) ExternalId = "example1234" GitHubOrgName = "example" GitHubRepoName = "example" github_oidc_provider = iam.OpenIdConnectProvider(self, client_ids=["sts.amazonaws.com"], thumbprints=["a031c46782e6e6c662c2c87c76da9aa62ccabd8e"], id="GithubOicdProvider", url="https://token.actions.githubusercontent.com", ) conditions = { "StringEquals" : { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike" : { "token.actions.githubusercontent.com:sub" : f"repo:{GitHubOrgName}/{GitHubRepoName}:*" } } bastion_role = iam.Role(self, assumed_by=iam.FederatedPrincipal( github_oidc_provider.open_id_connect_provider_arn, conditions=conditions, assume_role_action="sts:AssumeRoleWithWebIdentity" ), path="/", inline_policies={ "AssumeRolePolicy": iam.PolicyDocument( statements=[ iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=["sts:GetCallerIdentity"], resources=['*'] ), iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "sts:AssumeRole", "sts:TagSession" ], resources=["*"] ) ] ) }, id="BastionRole", role_name="BastionRole", ) aws_principal = iam.ArnPrincipal( arn=bastion_role.role_arn, ) # add condition aws_principal_with_condition = iam.PrincipalWithConditions(aws_principal, { "StringEquals": { "sts:ExternalId": ExternalId } }) github_actions_deploy_role = iam.Role(self, assumed_by=aws_principal_with_condition, id="GitHubActionsDeployRole", path="/", role_name="GitHubActionsDeployRole", ) # add policy github_actions_deploy_role.assume_role_policy.add_statements(iam.PolicyStatement( actions=["sts:TagSession"], principals=[ aws_principal.grant_principal, ], )) デプロイ　& 動作確認 では、実際にデプロイして動作確認してみます。 Github Actions Workflowはこちらを参照してください。 $ cdk deploy 無事、それぞれのroleでAWSアカウント情報を取得することができました。 所感 個人的にはcfnよりもコーディングが楽しかったです。 今回初めてCDKを使って構築してみましたが、普段使用している言語だったためか、かなりスムーズに構築できたと思います。 cfnを初めて触った時はひどいもんでした。 みなさんも気分転換に一度CDKで構築してみてください。楽しいはずです！ 以上！

Ateam Lifestyle Inc. Advent Calendar 2021の3日目は株式会社エイチームライフスタイル @engabesi が担当します。 動機 AmazonWebServices。通称AWS。 この業界では使ったことはなくても聞いたことがない人はいないであろう存在。 なんとサービス数は執筆時点で200以上(↓を手で数えたので間違えていたらごめんなさい) https://docs.aws.amazon.com/ そんなAWSですが、頭文字から作られた英数字3文字程度の略称だったり名前が直感的ではないものが多く(個人の感想)、恥ずかしながら名前を聞いた時に「それ何のサービスだっけ…」となることがままあります。 これを期によく耳にするサービスの省略しない形の名前と一言レベルの概要を書き出して頭の中で紐付けます。 本題 グループは先述のdocument準拠で書きます。 Compute Amazon EC2 Amazon Elastic Compute Cloud Infrastructure as a Service(IaaS) 任意のスペックで仮想マシンを作成し稼働させられる AWS Batch 名前の通りバッチ処理を行うサーバーレス 処理に時間がかかる場合等にLambdaではなくこちらを使用する 処理をジョブ単位でキューに登録、ECSで実行 AWS Lambda Function as a Service(FaaS) 名前はラムダ式から来ている? Containers ECS Amazon Elastic Container Service EC2のクラスターでDockerコンテナの起動、停止、管理ができる サーバーやクラスターの管理不要でコンテナを実行できるFargate起動タイプがある EKS Amazon Elastic Kubernetes Service 名前の通りAWS上でKubernetesを使えるマネージド型サービス Storage Amazon S3 Amazon Simple Storage Service オブジェクトストレージサービス ストレージ管理からアクセス管理、データの処理など色々できる Simpleとは Database Amazon Aurora Amazon RDS(Relational Database Service)のうちのエンジンの一つ フルマネージドのリレーショナルデータベースエンジン MySQL、PostgreSQLと互換性がある 上記の互換性があるものからちょっと変更してAuroraに置き換えるだけでスループットが3~5倍になるよ(意訳) Amazon DynamoDB フルマネージドのNoSQLデータベースサービス 高速で予測可能なパフォーマンスとシームレスな拡張性が特長 Dynamoはそのまま訳すと「発電機」 Amazon ElastiCache フルマネージドの分散インメモリデータストアサービス RedisとMemcachedをサポートしている Amazon Redshift フルマネージドのデータウェアハウスサービス 名前の由来は以下のインタビュー記事にあった https://cloud.watch.impress.co.jp/docs/special/578047.html 　最後になぜ”Redshift”というネーミングにしたのかをグラバニ氏に聞いてみた。Redshiftの日本語訳は”赤方偏移”、光のドップラー効果を意味している。 　有名な「ハッブルの法則」にあるように、高速で離れていく光源から発せられる光のスペクトルは赤くシフトしていく（逆は青くずれる）。 　「現在は、ビッグオブジェクトがオンプレミスからクラウドへとすごい速さで離れていきつつある。たくさんの分析されるべきデータがインサイドからアウトサイドへと放たれていく。その動きはまさにわれわれが描く軌道そのもの。フィジカルな環境からのターニングポイントという意味を込めてRedshiftと名付けた」――。 Security, Identity, & Compliance Amazon Cognito ユーザー認証 cognitoは造語 incognito(匿名の)からinを除いて匿名の反対としたと言われている(公式ソースは見つからず) AWS WAF Web Application Firewall HTTP(S)リクエストをモニタリング、検出、防御できる 条件を設定してコンテンツへのアクセスも制御できる Cryptography & PKI AWS KMS AWS Key Management Service 暗号化キーの作成と制御を行うマネージドサービス 下記URLにあるサービスと統合されており簡単に暗号化キーを用いた暗号化ができる https://aws.amazon.com/jp/kms/features/#AWS_Service_Integration Management & Governance Amazon CloudWatch モニタリング系サービス メトリクスを収集解析、ログ収集から解析まで行えたりAWSLambda関数へイベントを飛ばしたり色々できる AWS Organizations 複数のAWSアカウントを一元管理している組織に統合できる IAMや費用をまとめたりできる Networking & Content Delivery API Gateway あらゆる規模の REST、HTTP、および WebSocket API を作成、公開、維持、モニタリング、およびセキュア化するための AWS のサービス Amazon CloudFront htmlなどの静的/動的なウェブコンテンツを配信するCDN Elastic Load Balancing EC2等の複数のターゲット間でアプリケーションのトラフィックを自動的に分散する ターゲットの状態をモニタリングして正常なターゲットにのみトラフィックをルーティングする ALB(Application Load Balancer)、NLB(Network Load Balancer)、CLB(Classic Load Balancer)の3つのタイプのロードバランサーをサポート Amazon Route 53 DNSサービス 53はDNSがTCP/UDPのポート53を使うから Front-End Web & Mobile AWS Amplify クラウドサービスを利用したモバイル開発向けライブラリ群 その内のAWS Amplify Consoleがウェブアプリの継続的デプロイ及びホスティングするサービス AWS AppSync リアルタイムデータ同期が行えるフルマネージドなGraphQLサービス Amazon SNS Amazon Simple Notification Service アプリケーション、エンドユーザー、およびデバイスがクラウドから通知を即座に送受信できるようにするウェブサービス Social Networking Systemではない Analytics Amazon Athena S3内のデータをSQLで分析できるサービス サーバーレス Athenaはギリシャ神話の神で知恵・芸術・学芸・戦争などを司る Amazon Kinesis 動画やデータストリームをリアルタイムで収集、処理、分析できるサービス Kinesisは直訳で「生物の動き」 Application Integration Amazon SQS Amazon Simple Queue Service 完全マネージド型のメッセージキューイングサービス サービス間の分離やスケーリングを容易にする Business Applications Amazon SES Amazon Simple Email Service ユーザー自身の E メールアドレスとドメインを使用して E メールを送受信するための、簡単で費用効率の高い方法を提供する E メールプラットフォームです。 〆 私がよく耳にするサービスをザッと書いてみました。 間違いなどあればコメントや編集リクエストを頂けますと泣いて喜びます。 書くにあたってドキュメントの概要部分を見たのですが、 長くなるので端折りましたがそのサービスの思想や目的も垣間見え、 俺は雰囲気でAWSの話をしている。から少しは脱せたかと思います。 今後は急いで記載した為深い部分まで見ることができなかったのでそこを見ていきます。 また、ここに記載したものはほんの一部でAWSにはサービスがまだ大量にあるので、 その辺りのサービスについてもドキュメントを読んでいきます。 明日は @b_b さんのマネジメントに関する記事です。お楽しみに

みなさん、re:Invent 楽しんでますか？夜中のキーノートを見ているために今週はかなり寝不足です。 BugBustとは 2021/6/21に公開されたプログラム。 100 万個のバグを修正し、技術的負債を 1 億ドル以上削減するという世界初のグローバルチャレンジ。 https://aws.amazon.com/jp/blogs/news/new-aws-bugbust-its-game-over-for-bugs/ バグを修正するとポイントをゲット。ポイント上位者はグローバルリーダーボードに追加。 コードや修正したバグの詳細は公表されない。 AWS BugBust re:Invent Challengeの開催期間は、PST 11/29 10:00～12/2 14:00(JST 11/30 03:00～12/03 7:00) 用意するもの AWS BugBustのアカウント GitHubのアカウント やってみた! ここからアクセス * https://bugbust.aws/ 初回は Create an accountでアカウント作成。 GitHubと連携させる。 GitHubアカウントがないひとは作成を。BugBustとGitHubのアカウントは同じに。 GitHubに招待される。 BugBustのダッシュボードへ。 イベントで「re:Invent」を選択、カテゴリと言語(PythonかJavaから選択可能)を見て「View event bugs」を選択。 バグの一覧が表示される。課題と解決方法が記載。ものによってはヒントもある。(簡単なのは1ポイント、難しいのは3ポイント) クレーム(選択)したバグ。5時間以内に解決せよとのこと。 パスを選択する。 該当のコードが表示される。 鉛筆ボタンを押して編集モードに。コードを修正して、プルリクすると、、、 コードの検証中。ここで CodeGuruが動作している模様。しばし待つ。 成功すると、ポイント加算。修正したコードがアカンかったらポイント獲得ならず。 自分の成果 ご褒美はこんな感じ。ハエたたき、サニタイザー、ジョッキ、パーカー、Echo Dot。 勇者たち。みなさんすげー。 ちなみに私のポイント。。。 からの 補足 うまくレビューが動かない人は、、、 ガイド方法を眺めて対処してみてください。それでもダメなら、アカウントを作り直すとうまくいくケースがあります。 まとめ うらで Amazon CodeGuru Reviewerが動いてコードを検証。 ひさしぶりに Java コードさわったので文法忘れてた。。。 プライベートイベントとか作成すると面白いかも。 アワードが送られてくるかどうかは、乞うご期待。 今から急いでやるとまだハエたたきがゲットできるよ(re:Invent Challengeは JST 12/3 7:00まで)

aws s3 ls | awk -F " " '{print "aws s3 rb s3://"$3" --force"}'

この記事は株式会社ナレッジコミュニケーションが運営する クラウドAI by ナレコム Advent Calendar 2021 の10日目にあたる記事になります。 はじめに AWS re:Invent 2021 にて、Contact Lens for Amazon Connect で通話を要約する機能が実装されたとの発表がありました！ 今回は早速新機能を検証していきたいと思います！ Amazon Connect とは？ Amazon Connect とはAmazon Web Services 社の提供する簡単にコールセンターを開設できるサービスです。 リモートでも社内電話を利用できたり、自動音声案内が実装できたりと大変便利なサービスとなっています。 以前書いた参考記事 - Amazon Connectの使い方[丁寧に解説してみた] Contact Lens for Amazon Connect とは？ Contact Lens for Amazon Connectとは、Amazon Connectで通話した内容をリアルタイムで文字起こしし、分析ができるサービスです。 2021年09月には日本語にも対応を開始いたしました。 公式アナウンス情報 - Contact Lens for Amazon Connect が日本語をサポートしました 新機能【通話要約】について この度、コールサマライズと呼ばれる新しい機械学習（ML）機能が追加されました。 コールサマライズを利用することで、お客様との会話で重要な部分を識別し、会話内容を自動で要約することができます。 これまでお客様とお電話する際に、手書きのメモで要点をまとめたりすることもあったかと思います。 今回の新機能によって、そのような時間を節約することが期待できます。 公式アナウンス情報 - AmazonConnectのコンタクトレンズが新しい機械学習を利用した通話の要約を発表 さっそく設定してみた 1. Contact Lens の有効化 コンソールからAmazon Connect にアクセスし、インスタンスエイリアスからContact Lens を有効化したいインスタンスをクリックしてください。 左メニューにあるAnalytics tools をクリックしてください。 Contact Lens を有効にするにチェックを入れてください。 2. セキュリティプロファイルの設定 Amazon Connect のダッシュボードにアクセスし、セキュリティプロファイルにアクセスしてください。 設定を変更したいセキュリティプロファイルをクリックしてください。 メトリクスおよび品質にある上記赤枠内の項目にチェックを入れてください。 3. 問い合わせフローの設定 左メニューの問い合わせフローにアクセスしてください。 コンタクトフローの作成をクリックしてください。 問い合わせフローの構成の中に、記録と分析の動作を設定を加えてください。 上記赤枠内にチェックを入れてください。 動作確認してみた… 実際に電話をかけて動作確認しようとしたところ以下のエラーメッセージが表示されました。 "We are unable to complete the call as dialed. Try again, or contact your administrator." 調査してみたところ以下が原因だったようです。 ・日本の規制変更に伴い、日本の番号取得は AWS サポートから申請および書類の提出が必須となった（個人用の番号は申請しても取得できない） Amazon Connect の電話番号をアジアパシフィック (東京) リージョンで取得する ・仕方がないので海外の番号を取得しましたが、日本の電話番号に発信するにはクウォータ緩和の申請が必要のこと 電話できる国 動作検証は泣く泣く諦めることになりました… 料金 Contact Lens for Amazon Connect の料金は以下の通りです。 ※2021/12/02時点の情報となります 月間ボリューム 1 分あたりの料金 最初の 500 万分 0.015 USD 500 万分以上 0.0125 USD ■月間総計700 万分ご利用された場合 [500 万分 * 0.015 USD] + [(700 万-500 万) 分 * 0.0125 USD] = [75,000 USD] + [25,000 USD] = 100,000 USD おわりに 今回のContact Lens for Amazon Connect のアップデートは非常に魅力的でしたね！ ぜひ検証してみたかっただけにとても残念でした…

AWS Containers Advent Calendar 2021　一日目のエントリーです！ AWS Cloud Development Kit　(CDK) は、AWS のインフラを TypeScript や Java などのプログラミング言語で記述できる IaC ツールです。 そして、 CDK では、 Amazon Elastic Container Service (Amazon ECS) のクラスターやタスク、サービスを簡単に定義できるようになっています。例えば、 ApplicalLoadBalancedFargateService　のようなクラスを使うだけで、 ApplicationLoadBalancer がフロントに立つ Fargate のサービスを作成できます。 一方で、「CloudWatchAgent を追加したい」「XXX なエージェントを追加したい」「XXX 用の権限を追加したい」となると、 例えば ApplicalLoadBalancedFargateService のクラス構造を掘り返し、必要なプロパティを持ってきてそこにいろいろ手を加えるなど、一手間必要になり、クラスの再利用なども容易でない、という課題があります。 そこで、 ECS Service Extensions の出番です。 この CDK のモジュールでは、基本的な ECS のサービスを作成し、そこに様々な拡張を付け足していく、というアスペクト指向的なアプローチでアプリケーションを定義することができるようになっていて、より、再利用性が高い記述が可能です。 例えば、 CloudWatch Agent を付けた ECS のサービスを定義する場合、以下のようになります。 import * as cdk from "@aws-cdk/core"; import * as ec2 from "@aws-cdk/aws-ec2"; import * as ecs from "@aws-cdk/aws-ecs"; import * as ecsServiceExtensions from "@aws-cdk-containers/ecs-service-extensions"; import * as ecr from "@aws-cdk/aws-ecr"; export class ServiceStack extends cdk.Stack { constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); // 既存のクラスターのインポート const vpc = ec2.Vpc.fromLookup(this, "ClusterVpc", { vpcId: "vpc-xxxxxxxxxxx" }); const cluster = ecs.Cluster.fromClusterAttributes(this, "Cluster", { vpc, clusterName: "sample-ecs-cluster", securityGroups: [] }); // サービス作成先のクラスター環境定義 const environment = ecsServiceExtensions.Environment.fromEnvironmentAttributes(this, "Environment", { capacityType: ecsServiceExtensions.EnvironmentCapacityType.FARGATE, cluster, }); // 基本の Fargate サービスを構築 const repository = ecr.Repository.fromRepositoryName(this, 'ApplicationRepository', "literalice/sample"); const image = ecs.ContainerImage.fromEcrRepository(repository, "latest"); const description = new ecsServiceExtensions.ServiceDescription(); description.add(new ecsServiceExtensions.Container({ image, cpu: 512, memoryMiB: 1024, trafficPort: 8080, })); // Load Balancer を立てる description.add(new ecsServiceExtensions.HttpLoadBalancerExtension()); // CloudWatch Agent を付ける description.add(new ecsServiceExtensions.CloudwatchAgentExtension()); new ecsServiceExtensions.Service(this, "Service", { environment, serviceDescription: description, }); } } 上記では、Extension として組み込みの HttpLoadBalancerExtension と CloudwatchAgentExtension を利用しており、これにより、 ロードバランサーを利用し、 CloudWatch Agent をアタッチした Fargate Service になっているわけですね。このあたりの詳細については以下の記事に詳しいので、ぜひご参照ください。 さて、この Extension ですが、自作が容易にできます。例えば、共通ライブラリとして Extension を作っておけば、いろいろなサービスで使い回すことが可能です。 ApplicalLoadBalancedFargateService のような高レベルのクラスを様々なパラメーターでインスタンス化させる、のような手法もあるかと思いますが、より整理された方法で再利用性を高めることができますね。 というわけで、この記事では、Extension を自作してみようと思います。上の例では組み込みの CloudwatchAgentExtension を利用していますが、これを改良したものを作ってみます。具体的には、 CloudWatch Agent のコンテナイメージを ECR Public から持ってくる CloudWatch Agent が出力するメトリクスの名前空間をアプリ独自のものにできるようにする デフォルトでは、 CWAgent に全て出力されますので、これを変更したい、ということですね やることとしては、組み込みの CloudwatchAgentExtension をコピーしてきて、上記の修正を入れるだけです！ 組み込みの CloudwatchAgentExtension のコードは以下にあります。 これを、以下のように修正してみました。 import * as ecs from "@aws-cdk/aws-ecs"; import * as ecr from "@aws-cdk/aws-ecr"; import * as iam from "@aws-cdk/aws-iam"; import { Service } from "@aws-cdk-containers/ecs-service-extensions"; import { ServiceExtension } from "@aws-cdk-containers/ecs-service-extensions"; import { Construct } from "@aws-cdk/core"; const CLOUDWATCH_AGENT_IMAGE = "public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest"; /** * This extension adds a CloudWatch agent to the task definition and * configures the task to be able to publish metrics to CloudWatch. */ export class CloudwatchAgentExtension extends ServiceExtension { private CW_CONFIG_CONTENT: {}; constructor(metricsNamespace: string) { super("cloudwatchAgent"); // 環境変数でコンテナに渡される、 CloudWatch Agent の設定 this.CW_CONFIG_CONTENT = { logs: { metrics_collected: { emf: {}, }, }, metrics: { namespace: metricsNamespace, metrics_collected: { statsd: {}, }, }, }; } public prehook(service: Service, scope: Construct) { this.parentService = service; this.scope = scope; } public useTaskDefinition(taskDefinition: ecs.TaskDefinition) { // Add the CloudWatch Agent to this task this.container = taskDefinition.addContainer("cloudwatch-agent", { image: ecs.ContainerImage.fromRegistry(CLOUDWATCH_AGENT_IMAGE), environment: { CW_CONFIG_CONTENT: JSON.stringify(this.CW_CONFIG_CONTENT), }, logging: new ecs.AwsLogDriver({ streamPrefix: "cloudwatch-agent" }), user: '0:1338', // Ensure that CloudWatch agent outbound traffic doesn't go through proxy memoryReservationMiB: 50, }); // ECR Public 用のトークンを取得する if (taskDefinition.executionRole) { ecr.PublicGalleryAuthorizationToken.grantRead(taskDefinition.executionRole); } // Add permissions that allow the cloudwatch agent to publish metrics new iam.Policy(this.scope, `${this.parentService.id}-publish-metrics`, { roles: [taskDefinition.taskRole], statements: [ new iam.PolicyStatement({ resources: ["*"], actions: ["cloudwatch:PutMetricData"], }), ], }); } // ... } } これを、以下のように利用するだけで、 好みの設定で CloudWatch Agent を Fargate タスクに組み込むことができます。 // ... import { CloudwatchAgentExtension } from "./cloudwatch-agent-extension"; // ... description.add(new CloudwatchAgentExtension("sample-app-metrics")); // ... この記事では、ECS Service Extensions を使って、再利用性の高い記述で ECS サービスを構築する方法を CloudWatch Agent のサイドカーを組み込むコードを例に紹介しました！ ぜひ、皆様のサービスでもご活用いただければと思います。

概要 先日の「自社クラウドサービスをAnsibleで作った話 recap」で紹介した通りに自社クラウドサービスのライフサイクル管理はほぼすべてAnsibleが担っています。 当社サービスはシングルテナント構成で、顧客数が増えるのに比例して顧客環境(以下テナントとする)も増えます。 事業がスケールしていくのにつれ、それらのテナントを手作業で管理、メンテしていけるはずがないことから、リリース当初からAnsibleによる自動化で構築していました。現在も機能追加や基盤改善を行う際も原則Ansibleで実装しています。 しかし、テストはついこの間まで手動のままでした。 テストは定期的に基盤更新(設定変更、構成変更、機能追加)やパッチ適用(各種バージョンアップ)を実施しているので、新規もしくはバージョンアップしたテナントが正常に動作しているのかをテストシナリオに沿ってシステムテストを実施しています。 シナリオはサービスメニュー（新規契約、解約、オプション）に沿って構成されており、それらのシナリオを順（直列）にテストしていました。サービスメニューが増えるのにつれ、シナリオが増え、結果的にテストコストも増える未来しかないので、自動テストを導入しました。 Ansibleのシステムテストの話を聞かないので、手動テストからテスト自動化するのあたっての工夫や考え方などを以下にまとめます。皆さんの役に立てれば幸いです。 すべてを書き出したわけではないので、気になることや質問などがありましたらドシドシくださいませ。 テストケース サービスメニューに沿ったシナリオベースのテストケースになります。 ざっくりですが、以下のように新規契約、変更、解約の一連のライフサイクルがテストケースになっております。 また、EC2のタグ付けや監視の動作確認、バージョンアップ時の動作確認などの非機能要件も確認内容に含めています。 No ケース名 確認内容 1 新規申込が確定したら、テナントAが作成され、正常に利用できる ・テナントが正常に作成されること・サンプルデータが投入されていること・初期PWでログインできること・EC2のタグに〇〇が付与されていること・Zabbix ホストにテナントAが登録されていること 2 テナントAの契約を更新したら、変更値がテナントAに反映される ・ユーザ数が〇〇であること・〇〇オプションが利用できること 3 テナントAが解約されたら、対象の環境が利用できなくなり、データが削除される ・テナントにアクセスできないこと・データが削除されていること・Zabbixホストが削除されていること 4 バージョンxxのテナントAをバージョンyyに更新し、各種機能が正常に利用できる ・正常にサービスを利用できる。・異常なアラートが発報されていない・新規追加された機能が利用できる 5 テナントAの〇〇サービスを停止すると、▲▲アラートがZabbixから発報される ・Slack XXXチャンネルに●●のアラートメッセージが受信されていること・Zabbixの障害一覧に該当の障害があること 6 テナントAの〇〇サービスを開始すると、▲▲アラートが解決される ・Slack XXXチャンネルに●●のアラートが解決したメッセージが受信されていること・Zabbixの当該の障害が解決されていること 上記テストケースNo.1で作成されたテナントAに対して順にテストしていました。 そうすると以下の問題を抱えていました。 途中で問題が発生した際に、すべてのテストを最初からやり直すことになる ケース数に応じてテスト時間も長くなる 複数人で同時実行しづらい 自動テスト化するのにあたり、以下のようにテスト種別ごとに並列実行できるようにケース間の依存関係を無くし、これらの問題を解決しました。 No テスト種別 ケース名 確認内容(前述同様のため略) 1 新規 新規テナントAが作成され、正常に利用できる 略 2 更新 新規テナントBが作成され、正常に利用できる 略 2-1 - テナントBの契約が更新されたら、変更値がテナントBに反映される 略 3 解約 新規テナントCが作成され、正常に利用できる 略 3-1 - テナントCが解約されたら、対象の環境が利用できなくなり、データが削除される 略 4 バージョンアップ バージョンxxのテナントDを作成し、正常に利用できる 略 4-1 - テナントDをバージョンyyに更新し、各種機能が正常に利用できる 略 実装 すべてのテストケースが並列実行できるようAWS Codebuild（AWS Codebuildの詳細は割愛します）を採用しました。 簡単なアーキテクチャは以下のようになっています。 テスト種別ごとに1つのCodebuilldプロジェクトになるようにしました。 Codebuilldではbuildspec.ymlで定義されたコマンド(下図のbuildspec.ymlを参照)を順に処理していきます。 buildspec.ymlの解説 上図のbuildspec.ymlの実行順に合わせて以下で解説します。 Codebuildの実行環境はローカルで開発する際のAnsibleの実行環境（AnsibleのDockerコンテナ）と同様のものを使用しているので、環境差異による問題を減らしています。 Codebuild実行時にソースは$CODEBUILD_SRC_DIRにクローンされます。なのでローカル開発と同じディレクトリ構成になるようにシンボリックリンクを設け、実行環境の差異を無くしています。（手順1） テスト開始前にテスト対象のテナントに関連するすべてのリソース（Zabbixホスト、ログフォルダ、EC2、ルーティング）を初期化することで、ゴミデータによるテスト品質の低下を抑えるようにしています。（手順2） 各テストシナリオごとに必要な変数（テナントの初期設定値）をjsonファイルに変換し、各種処理実行時に外部変数として渡すようにしています。変数を変えるだけで振舞を変えられるように標準化を図っています。（手順3） 本番環境はAWX経由ですべての処理を実行しているので、最終的なテストはAWX経由で実行します。開発時はスピード重視のため、直接playbookを実行できるようにフラグ（EXECUTE_ON_AWX）で処理分岐できるようにしています。（手順4） 作成されたテスト用テナントが前提条件に合致した環境なのかを検証することで、テスト品質を担保しています。（手順5） 実際に業務で使用されているplaybookを実行します。環境変数に応じてAWX経由で実行します。実行環境は本番環境と同等になるためテスト品質を担保しています。（手順6） テストケースに沿って動作、設定確認します。（手順7） APIで設定値を確認できないものは、GhostInspectorによるUIテストでカバーしています。 一部デスクトップ用クライアントアプリケーションは別途Windows Power Automate Desktopでテスト実装中です。完全自動化できていない。 注意点 すべてのテストを同時実行するのであれば、APIの同時実行制限があるクラウドサービスにおいて同時実行数の調整やエラー発生時のリトライの調整が必要 AWSでさえもAPIの同時実行制限がありますので、要注意！ テスト環境内に貧弱なシステムがあることで単一障害点になり、テストが詰まる可能性があるので、API同時実行時と同様な対応が必要 例えば、性能が低い監視基盤があると多数のテストテナントの監視を捌けずに落ちたり、監視が遅延したりなどが発生する 工夫 AWSを使用している弊社環境特有ですが、テナントをスポットインスタンスではなくオンデマンドインスタンスでテストしています。 スポットインスタンスだとAWSの都合によりテスト中にインスタンスの強制停止に遭遇し、思わぬエラーに見舞われる可能性を避けるため。 複数環境を想定したテストを実装すること。 例えば、テナントの削除ケースで予め2つ以上のテナントが存在し、そのうちの1つのテナントを削除し、もう一つのテナントが削除されないことも確認しているのでテストデータによるテスト不足を防ぐことができます。 テストケースの項番をテストコード内にも記載することで、検索性を高めている テストからテストケースを作成できるのが一番理想 - name: "2-1 更新確認" ansible.builtin.assert: that: - a == b assertモジュールにfail_msg:を指定することでエラー発生時に原因となった値を表示するようにする エラー発生時に比較対象がどのような値なのかが表示されないので、明示的に定義する必要があります。 stringフィルター忘れずに！ - name: "2-1 更新確認" ansible.builtin.assert: that: - a == b fail_msg: "a: {{ a | string }} , b: {{ b | string }}" localhost以外のホストをテスト対象にしている場合は、any_errors_fatal: Trueを設けることでサイレントエラーを無くす テストの実装方法次第ではあるが、max_fail_percentageの影響によっては、1部のホストでエラーが発生してもテストが完走してしまうリスクを無くす。 （一定ではない）時間経過によって確認しなければならないテストの場合は、待ち時間をpauseで固定するのではなく、ポーリングで状態確認(APIで状況を確認)することで、時間経過のブレによって実行時間の短縮や想定以上の時間を要したことによるエラーを防ぐことができます。 Linuxのaliasを活用して、playbook実行時のコマンドを短縮化することで、実装者の負担を減らしています。 すべての処理をAnsibleではなく、一部ShellScriptからAnsibleを実行していることもあります。適材適所。 効果 自動テスト化したことで得られた効果は以下の通りになります。 以前のテスト時間は準備を含めて1週間/1人。今は準備込みで3日/1人 心理的安全性を確保できたので、コード修正しても安心できる ちょっとした修正でも容易にテストできるので、品質の向上が得られた

はじめに こんにちは withでエンジニアをしているhayatonです。（最近入社したのでピチピチの若手です。） withでは サーバ周りのお仕事をさせてもらっています。 今回、アドベントカレンダーで記事を書かせていただくこととなり、何を書こうかと悩んでいたところに、 Minecraftの大型アップデートがきた。ということもあり、その内容を記事にさせていただきました。 このドキュメントはマイクラサーバの構築手順ではありません。バージョンアップ作業にフォーカスをおいたものです。 私は、マイクラ（Minecraft JavaEdition 1.11ぐらいから）にハマっています。（公共事業大好き勢） 一人だけでは飽き足らず、自前でサーバを構築し友人同士と同じ世界で楽しんでおります。（鯖管兼任） そのサーバのアップデートについて 自分の作業備忘録 気づいたポイント(3つ) の2点についてこの記事に記載します。 割と定期的にあるバージョンアップ作業なのですが、忘れがちなので、次のバージョンアップ向け自分用メモだったりしますが、 もしこの記事を読んで、何かしらで詰まっている方の解決への気づきなどが提供できたら嬉しいなと思い、書いてます。 私のサーバ環境情報 AWS Lightsail Memory/CPU/Disk: 4GM RAM / 2 vCPU / 80GB SSD OS: Debian Mod: none(vanilla) Backup: Daily(to GoogleCloud CloudStorage) java path: /usr/local/java minecraft path: /home/minecraft 作業ユーザー: minecraft 作業備忘録(バージョンアップ作業) 1. 稼働させるJavaのバージョンの変更 以前のminecraft 1.17.1 は、稼働条件のJavaバージョンは16でした。 今回のminecraft 1.18は、Javaバージョンが17になっています。(今回一緒にバージョンアップしています。) ちなみに、この環境はopenjdkで稼働させていますが、JavaSEでもちゃんと動くと思います。 [0] 作業ユーザーになる $ su minecraft [1] java17のダウンロード $ wget "https://download.java.net/java/GA/jdk17.0.1/2a2082e5a09d4267845be086888add4f/1 2/GPL/openjdk-17.0.1_linux-x64_bin.tar.gz" [2] 展開し、Javaをインストール 私の環境では、/usr/local/java で使いたいJavaをシンボリックリンク張っている。 ※ alternatives使うのがベストだろうけど許してください。 lrwxrwxrwx 1 root root 10 Dec 1 02:07 java -> jdk-16.0.1 drwxr-xr-x 8 minecraft minecraft 4096 Jun 25 22:57 jdk-16.0.1 なので、 $ tar zxvf openjdk-17.0.1_linux-x64_bin.tar.gz $ sudo mv jdk-17.0.1 /usr/local/. $ cd /usr/local $ sudo rm java $ sudo ln -s /usr/local/jdk-17.0.1 java $ ls -la /usr/local ... lrwxrwxrwx 1 root root 10 Dec 1 02:07 java -> jdk-17.0.1 drwxr-xr-x 8 minecraft minecraft 4096 Jun 25 22:57 jdk-16.0.1 drwxr-xr-x 8 minecraft minecraft 4096 Dec 1 02:07 jdk-17.0.1 ... として、インストール完了後、確認。 $ /usr/local/java/bin/java --version openjdk 17.0.1 2021-10-19 OpenJDK Runtime Environment (build 17.0.1+12-39) OpenJDK 64-Bit Server VM (build 17.0.1+12-39, mixed mode, sharing) となればOK。 2. minecraftサーバ用jarファイルのダウンロード及び設置(インストール) [1] minecraftサーバ用jarファイルをダウンロード $ wget "https://launcher.mojang.com/v1/objects/3cf24a8694aca6267883b17d934efacc5e44440d/server.jar" $ mv server.jar minecraft_server.1.18.jar [2] jarファイルをセット 私の環境では/home/minecraft に設置してある。 現在は以下のように、バージョンアップごとにシンボリックリンクを張り直しをしている -rw-r--r-- 1 minecraft minecraft 43626592 Jul 6 21:05 minecraft_server.1.17.1.jar -rw-r--r-- 1 minecraft minecraft 43621201 Jun 8 20:03 minecraft_server.1.17.jar lrwxrwxrwx 1 minecraft minecraft 25 Dec 1 01:54 minecraft_server.jar -> minecraft_s erver.1.17.1.jar なので $ mv minecraft_server.1.18.jar /home/minecraft/. $ cd /home/minecraft $ rm minecraft_server.jar $ ln -s minecraft_server.1.18.jar minecraft_server.jar $ ls -la ... -rw-r--r-- 1 minecraft minecraft 43626592 Jul 6 21:05 minecraft_server.1.17.1.jar -rw-r--r-- 1 minecraft minecraft 43621201 Jun 8 20:03 minecraft_server.1.17.jar -rw-r--r-- 1 minecraft minecraft 46323386 Nov 30 18:20 minecraft_server.1.18.jar lrwxrwxrwx 1 minecraft minecraft 25 Dec 1 01:54 minecraft_server.jar -> minecraft_s erver.1.18.jar ... とする。 3. 起動前にワールドデータをバックアップとっておく バックアップとっておく 壊れたことはないが、癖でやっています。（癖をつけておくの大事） バックアップ取る際、どのバージョンだったかを一緒につけると便利かも $ cd /home/minecraft $ cp -rp world world_1.17.1 4. 起動 起動 私の環境では、systemctl組み込み済み $ sudo systemctl status minecraft $ sudo systemctl start minecraft $ tail -F logs/latest.log [02:08:39] [Worker-Main-2/INFO]: Loaded 7 recipes [02:08:40] [Worker-Main-2/INFO]: Loaded 1141 advancements [02:08:43] [Server thread/INFO]: Starting minecraft server version 1.18 [02:08:43] [Server thread/INFO]: Loading properties [02:08:43] [Server thread/INFO]: Default game type: SURVIVAL [02:08:43] [Server thread/INFO]: Generating keypair [02:08:44] [Server thread/INFO]: Starting Minecraft server on *:25565 [02:08:44] [Server thread/INFO]: Using epoll channel type [02:08:44] [Server thread/INFO]: Preparing level "world" [02:08:44] [Server thread/INFO]: Preparing start region for dimension minecraft:overworld とか出てきたらOK。 しっかりと、1.18で稼働したよというログも出てますね。 気づいたポイント [1] バージョンアップ後の初期起動に時間がかかる。 今回のアップデート直後のサーバ起動にかなり時間がかかった印象。（クラッシュしたかと一瞬思った。） 時間がかかっていても、強制終了しないでね。 [02:10:32] [Server thread/INFO]: Done (108.070s)! For help, type "help" 約2分弱ですね。 [2] リリース直後はサーバサイドのJarファイルが1つ前になっていることがある。 (地味にハマった) https://www.minecraft.net/ja-jp/download/server このページが1.18対応したという表記になった直後にjarファイルをダウンロードしたが、 jarファイルを入れ替えして、さぁ起動だ！といったタイミングでずっとログに1.17.1がスタートしたよと出ていた。 [01:49:31] [Server thread/INFO]: Starting minecraft server version 1.17.1 いやいや、新しいの持ってきたんだけどなぁとドハマリしていたが、 以前のjarファイルとハッシュ値を比較した際に、同じ値となっており、古いものをダウンロードしていたことが発覚。 再度上記のサイトにアクセスし、新しいものに変わっていることを確認し、入れ替え作業を行った。 リリース直後はWeb表記は変わっているが、ダウンロードしてきたjarファイルは古いこともある。 以前のjarファイルとダウンロードしてきたjarファイルのmd5値をチェックして、変わっているかどうかを確認するとスマートかもしれない。 [3] 遠くに離れなくても、新要素が反映されている。 （これが今回一番すごいことだと思う。） これは、技術的な話じゃなく、ゲーム上の話なのですが、、、 いままでは、ワールド情報をバージョンアップ前のものから引き継ぐと遠い場所まで移動しないとアップデート内容が確認できないのが普通でした。 （いままでに読んでいないチャンクまで行かないと新要素が発生しなかった。） が、今回のアップデートはいままでに読まれていたチャンクでも、地下に行くことで新要素の確認が出来ました。これが一番の驚きでした。 マイクラ開発スタッフの方々ありがとう・・・・そしてお疲れさまです。。。。。（脱帽） 最後に この記事を最後まで読んでいただいてありがとうございます。 一応バージョンアップしてから今のところは問題が起きていませんが、なにか起きているようであればまた記事書こうと思います。 この記事は、自分の作業の備忘録が主目的ではありますが、 もしなにか躓いている方が、この記事を読んで、お役に立てる何かが見つかったら嬉しいです。 師走で忙しくなってくる時期に、マイクラのこんな大型アップデートをかけてくるなんて、 マイクラ開発スタッフの方々も鬼(warden)ですね！！笑

はじめに 開発環境のEC2やRDS、夜間も立ち上げっぱなしにしていませんか。 特に個人でサービス開発している方にとっては直接おサイフに響くので、１万円/月でも固定費が下がったら嬉しいはず。 今回は、今すぐ簡単にできるちょっとしたAWSコスト削減についてまとめてみようと思います。 本記事の主な対象者 主にスタートアップや個人のサービス開発において、少しでもAWSからの請求費用を削減したいと思っている方 AWSコスト関連のノウハウが少なく、どこから手をつけて良いかがよくわからない方 筆者について 2020 APN AWS Top Engineer 2021 APN AWS Top Engineer / APN ALL AWS Certifications Engineer レシピその１：Savings Plans AWS Cost Explorer から、必要なパラメータを選択してポチるだけ とはいえ、Cost Explorer は業務においては開発者として、EC2やRDSを利用しているだけだと中々馴染みのない部分かと思います。以下の手順で進めて下さい。 AWS コンソールから、AWS Cost Explorer を開く 左メニューから、「Savings Plans」> 「推奨事項」を選択する この画面では、ざっくり上半分（↑）がコストシミュレーションのパラメタ。下半分（↓）が、コストシミュレーションの結果となります。 おすすめは「Compute Savings Plans」で、リージョンを意識することなく、EC2 / Fagate / Lambda をまるっと割引してくれるというもの。 上記はざっくり「１年：前払いなし」の、オプションで、20%削減できるシミュレーションとなります（３年：全額前払いだと、驚きの47%削減ですが、ここは初回の場合はスモールスタートで良い気がします） さらに詳しく検討してみたい方は、公式ドキュメントなど確認の上、クッキングされると良いかと思います。 レシピその2：Instance Scheduler 1. 提供済みの CloudFormation テンプレート のスタックをデプロイし 2. 作成された DynamoDB の 起動スケジュールの管理項目をメンテし 3. 自動起動/停止の対象としたい、EC2/RDS にタグをつけるだけ 何が実現できるのかというと、これまで自前構築で Lambda + EventBridge で自動起動/停止行っていたようなものが、用意されたDynamoDBの項目メンテと対象のタグ付けだけで、夜間などの時間を指定して自動停止 / 翌朝起動とかが設定次第で簡単にできてしまうというもの。 開発環境など、24/365の稼働が必要でない非クリティカルな環境においては、平日夜間と土日を止める設定をするだけで、コストは半分くらいまで抑えることができるのではないでしょうか。 なお、Instance Scheduler の具体的なレシピについては、下記の builders.flashの 記事がハンズオン形式でとてもわかりやすいと思いましたので、興味がある方に向けてはこちらをご紹介したいと思います。 サーバーを指定した期間で停止する「AWS Instance Scheduler」を試してみる Instance Scheduler 実装ガイド おわりに 今すぐ 簡単 にできる レシピ２選のご紹介でした。 この年末年始、お使いのAWS環境の固定費に対するの割引サービスの検討や リソースのお掃除など、コストの見直しなど検討されてみるのはいかがでしょうか。 少しでも、皆様のおサイフのお役にたてれれば幸いです。

背景 RDSに接続できるようにするために EDITOR='vi' bundle exec rails credentials:edit をしてcredenialsファイルを開こうとしたところ Couldn't decrypt config/credentials.yml.enc. Perhaps you そしてpassed the wrong key? という風に言われました。ちなみにmaster.keyはちゃんと中身入ってます。 結論 解決方法としてはcredentialsファイルを作り直します。 ただ、作り直すといっても、そんな難しい作業ではないです。 まず既存のローカルのcredentialsファイルの名前を適当なファイル名に変更します。 そしてそのローカルのcredentialsファイルにRDSのusernameやpassword等を記述します。 ちゃんと記述ができたことが確認できたら、githubにpushします。 pushができたらSSHでEC2サーバ内に入り、アプリディレクトリで git pull を実行します。そしてEC2内で EDITOR='vi' bundle exec rails credentials:edit を実行するとcredenttialsの中身がちゃんと確認できるかと思います。

この記事は、「AWS Advent Calendar 2021」の2日目の記事です。 Amazon RedshiftとDBeaverで空間検索をしてみました 今回は、AWSが提供するクラウドデータウェアハウスのAmazon RedshiftにDBeaverで接続し、位置情報データのインポートや空間関数を実行してみました! 位置情報データの事前準備 事前準備としてQGISを利用し、ランダムポイント(青色の100万件)と空間検索用ポリゴン(黄色の3件)を、Amazon Redshiftで標準対応しているshapefile形式で準備しました。 QGIS #065 - 指定範囲にランダムポイント作成 また、Amazon Redshiftにインポートするためにデータ一式をS3にアップロードしておきます。 Amazon Redshiftのクラスター作成 はじめに、Amazon Redshiftのクラスターを作成します。 AWSコンソールでAmazon Redshiftを選択 → クラスター → クラスターを作成をクリック。 クラスター名・無料トライアル・ユーザー名・パスワードを設定 → クラスターを作成をクリック。 しばらくするとクラスターが作成されます。 これでAmazon Redshiftのクラスター作成は完了になります ロールとパブリックアクセスの設定 次に、Amazon RedshiftからS3へアクセスするためのロール設定と、DBeaverからAmazon Redshiftへ接続するためのパブリックアクセス設定をします。 S3へアクセスするためのロールを作成します。 Amazon Redshiftのクラスター詳細画面で作成したロールを割り当てます。 Amazon Redshiftのクラスター詳細画面のアクション → パブリックアクセス可能な設定を変更をクリック。 パブリックアクセス可能を「有効化」 → 変更を保存をクリック。 有効化されているかを確認します。 Amazon Redshiftのクラスター詳細画面のセキュリティグループ → インバウンドルールを追加しタイプをRedshiftに設定 → ルールを保存をクリック。 インバウンドルールが設定されているかを確認します。 これでロールとパブリックアクセスの設定は完了になります DBeaverで位置情報データをインポート 次に、DBeaverを利用しAmazon Redshiftに接続し位置情報データをインポートします。 DBeaverでAmazon Redshiftに接続します。ホスト名(クラスターエンドポイント)・ポート・データベース名・ユーザー名・パスワード・ロール名を設定します。 ランダムポイント(100万件)をインポートしてみます。事前にテーブルを作成し、インポートしたいshapefileの格納先とロールを指定し実行します。 CREATE TABLE points ( wkb_geometry GEOMETRY, id BIGINT ); COPY points FROM 's3://redshift-geo-data/points.shp' FORMAT SHAPEFILE CREDENTIALS 'aws_iam_role=arn:aws:iam::xxxxxxx:role/redshift-geo-role-2112'; インポートされると、マップ上で可視化しながらデータの確認ができます。 空間検索用ポリゴン(3件)をインポートしてみます。事前にテーブルを作成し、インポートしたいshapefileの格納先とロールを指定し実行します。 CREATE TABLE polygon ( wkb_geometry GEOMETRY, id BIGINT ); COPY polygon FROM 's3://redshift-geo-data/polygon.shp' FORMAT SHAPEFILE CREDENTIALS 'aws_iam_role=arn:aws:iam::xxxxxxx:role/redshift-geo-role-2112'; インポートされると、マップ上で可視化しながらデータの確認ができます。 これでDBeaverでの位置情報データのインポートは完了になります 空間関数を実行 最後に、Amazon Redshiftで空間関数を実行できるかを試してみます。今回は代表的な例として、「ST_AsGeoJSON」を利用しデータをGeoJSON形式に変換するのと、「ST_Within」を利用し100万件のポイントからポリゴン内にあるポイントを抽出する空間関数を実行してみます。 まずは、「ST_AsGeoJSON」を利用しデータをGeoJSON形式に変換してみます。 SELECT ST_AsGeoJSON(wkb_geometry) FROM public.polygon; GeoJSON形式のデータで出力されました！ 次に、「ST_Within」を利用しポリゴン内にあるポイントを抽出してみます。 SELECT public.points.id, public.points.wkb_geometry FROM public.points, public.polygon WHERE ST_Within(public.points.wkb_geometry, public.polygon.wkb_geometry); ポリゴン内のみのデータで出力されました！ 次に、「ST_Within」を利用しポリゴン内にあるポイントのカウントを抽出してみます。 SELECT COUNT(*) FROM public.points, public.polygon WHERE ST_Within(public.points.wkb_geometry, public.polygon.wkb_geometry); ポリゴン内のみのカウント「5167件」が出力されました！ 最後に、QGISを利用した場合と空間検索結果が一致するかも確認してみたいと思います。 QGIS #076 - 空間検索でデータ選択 同じ「5167件」になりました！ Amazon RedshiftとDBeaverで空間検索ができました Amazon RedshiftとDBeaverを利用することで、Amazon Redshiftで位置情報データのインポートや空間検索をできることが確認できました。今後位置情報データの分析等にもうまく利用できそうです。 当初はサービス内で利用できる、「Query Editor V2」で手軽に試そうとしましたが、現状で位置情報データのインポートや空間関数に対応していないようでした。今後対応されるともっと手軽に利用できたり、今週プレビュー版が発表されたAmazon Redshift Serverlessでも手軽に利用できるようになるかもしれません やってみたシリーズ tags - Try

IT資格取得をテーマに学びをシェアしよう！【PR】Udemy Advent Calendar 2021 の4日目の記事です。 目次 1. はじめに 2. AWSクラウドプラクティショナー対策 3. AWSソリューションアーキテクトアソシエイト対策 4. 使用した教材まとめ 5. さいごに 1. はじめに はじめまして！2021年にITエンジニアに異業種を転職した@kjstudy_englifeと申します。 私は実務未経験の状態から、約3ヶ月でAWSクラウドプラクティショナー(CLF)とAWSソリューションアーキテクトアソシエイト(SAA)を取得することが出来たので、取得するまでに使用した教材や効率の良い勉強の流れについてまとめてみました。 実務未経験だと中々勉強が難しいと感じるかもしれませんが、以下で紹介するUdemyを活用することで非常に効率良く学習を進めることが出来ます。AWS CLFの取得を考えている方はこの記事を最初から順番に、「既にCLFは取得しているからSAAの勉強法だけ知りたい！」という方は、途中のソリューションアーキテクトアソシエイト対策から読んで頂ければと思います。 2. クラウドプラクティショナー対策 本記事では私が実際に使用した教材と学習の流れを紹介しています。 ITに関する知識が全く無く「AWSって何？そもそもクラウドって？」という状態からスタートしたので、かなり初歩からのスタートとなっています。現在のご自分のレベルと比較し、必要だと思った教材のみピックアップして頂ければと思います。 2.1 使用した教材 【参考書１】図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書 この参考書はとにかく分かりやすいです。 私はそもそもAWSで何が出来るのかすら全く分かっていなかったド素人のため、最も図解が多いこちらの書籍を購入しました。現時点で発売されている書籍の中では、これが最も分かりやすいと思います。 ただし、この書籍は導入には最適ですが、本当に基礎の部分しか記載されていません。そのため、CLFに合格するにはもう1歩踏み込んだ内容が記載されている書籍があった方が良いと思います。 【参考書２】AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー こちらの参考書はAWS CLF対策をメインとしたものであり、CLFで出題されやすいAWSのサービスの要点がまとめられています。実務未経験だとなかなか使用イメージが湧きにくいこともありますが、CLFレベルでは深い内容が問われることは少ないため、とにかくこの書籍に書いてあるサービスを少しずつ覚えていきましょう。 【問題集１】この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（7回分455問） 問題集はコレ1つで問題ないです。価格も非常に良心的で、公式の模擬試験の価格と比較すると「こんなに安くていいの？」と心配になるレベルです。この教材に基本レベルの模試が2回分、応用レベルの模試が3回分、難易度高(SAA)レベルの模試が2回分入っており、これだけあればCLF対策としては十分です。 CLF対策としては、私は上で紹介した書籍2冊とUdemyの問題集を使用しました。 それでは、これらの教材を用いた学習の流れを紹介したいと思います。 2.2 学習の流れ 2.2.1 AWSの概要を知る これまで全くITの勉強をしてこなかった人は、AWSの概要について知ることが先決です。 【参考書１】を何度も読んでAWSへの理解を少しずつ深めましょう。既にAWSについてある程度の知識がある方は、ここのフェーズはスキップして問題ありません。 「オンプレミスと比較したAWSのメリットは？」 「IAM・S3・EC2・RDSって何をするためのサービス？」 こうした問いに簡潔に答えられるようであれば、次のステップに進んでよいと思います。 2.2.2 参考書でインプット AWSに関する最低限の知識を付けた後は、【参考書2】を読んでインプットを行いましょう。 例えば、データベースとは一口に言ってもRDSやDynamoDB、Redshiftなど様々なサービスがあります。どういった場面でどういったサービスが使われるのか、各サービスのユースケースも意識しながらインプットを行いましょう。 この時点では、完璧にインプットする必要はありません。 模試を解いた後の復習でも参考書を読むことになるので、ここでは1~2周読んだ段階で次のステップに進みましょう。 2.2.3 Udemyの模試で最終仕上げ 一通り書籍でのインプットが終了した後は、上記で紹介したUdemyの模試を用いて学習しましょう。この模試は全体的にレベルが高いので、初めは中々60%を超えるのも難しいです。間違えた部分は解説や書籍を見ながら、少しずつ知識を増やしていきましょう。 この模試を3~5周ほど繰り返し、応用レベルで80%以上取得できるようになれば、合格はかなり近いと思います。 2.3 AWS CLFまとめ 以上が私が実務未経験の状態から、AWS CLFを取得するまでに行った学習法になります。 AWS認定資格の中で最も易しいレベルの資格ではありますが、やはり取得するまでにはある程度の時間はかかります。紹介した書籍やUdemyの教材は本当にコストパフォーマンスが良くおすすめなので、ぜひ参考にしてみてください。 3. ソリューションアーキテクトアソシエイト対策 上記の方法でAWS CLFを取得した後に、AWS SAAを取得するために私が実際に使用した教材と学習の流れを紹介しています。CLFは取得済みなので最低限の知識はありますが、依然として実務は未経験という状態でした。 3.1 使用した教材 【参考書３】AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト AWS SAAを取得するために必要な知識の概要を掴むために使用しました。 次に紹介するハンズオンや模擬試験を解いた際の復習にも使用できるため、1冊持っておいて損はないかなと思います。 【ハンズオン１】これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） 実務未経験の人にとっては、書籍だけでは一体何が起こっているのか、各リソースの構築時にどういった設定が必要なのか、といった具体的なイメージが中々湧かないこともあると思います。 しかし、このハンズオン教材を使用することで、実務でAWSを触ったことが無くても実際に手を動かしてAWSリソースを構築する経験を積むことが出来るので、AWSに対する理解がかなり深まります。実務経験が浅い方はこの教材でハンズオンに取り組むことを強くおすすめします。 SAAと同じアソシエイトレベルのAWS認定資格である「AWSシステムオペレーションアドミニストレーター アソシエイト(SOA)」では、選択問題に加えて"試験ラボ"と呼ばれる実技問題が出題されます(2021年12月現在)。 この試験ラボ問題は書籍のみの学習では攻略が難しく、ハンズオンでの学習経験がカギになるため、SAAの次にSOAに挑戦しようと考えている場合にもこのハンズオン教材は役立ちます。 講義内でもしっかり説明がありますが、作成したAWSリソースは削除し忘れないようにしましょう。長時間無駄にサービスを起動し続けてしまうと、シャレにならない金額がかかったりします。 そして、このUdemyの教材で1番評価したい点がAWSの変化にも対応している点。 書籍でもAWSのコンソール画面の写真は確かに記載されており、ある程度操作のイメージをすることは出来ます。しかし、AWSは頻繁にUIやサービス名が変化するため、書籍出版時の情報がアテにならないことがしばしば起こってしまいます。 その点、Udemyのこのハンズオン教材であれば、AWSに変更が入ったとしても教材が適宜更新されるので、AWSが変化しても同じ教材で学び続けることが出来ます。さすがに動画が更新されるまでに時間が多少かかるので、常に最新のAWSの状態で学べる訳ではありませんが、書籍よりも新しい状態で学べることは非常に大きなメリットです。 「動画の最終更新日」に注目してみると、どの程度の頻度で動画が更新されているかを判断することが出来ます。 この日付が新しい教材ほど、定期的に動画が見直されている可能性が高いです。 【問題集２】【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） SAA用の模擬試験もこの教材1つで問題ないです。 こちらは基本レベルの模試が1回分、高難度レベルの模試が5回分入っています。高難度の模試は難易度がかなり高いので、1周目で60%以上の正解率に到達するのはかなり難しいです。しかし、この模試を解いてしっかりと復習することで、SAAに合格できるだけの力が付くと思います。 3.2 学習の流れ 3.2.1 参考書でインプット SAAを受けるレベルでは、ある程度AWSの基礎は抑えている方が多いと思います。 しかし、SAAはCLFに比べて出題されるAWSサービスも増えてくる上に、ベストプラクティスに則った構成等に対する理解も問われてくるため、まずは書籍を用いてインプットを行いましょう。ここでも軽く1~2周読んだ段階で、次のステップに進むと良いと思います。 3.2.2 Udemyのハンズオン教材で学習 上で紹介した【ハンズオン１】の教材を用いて、実際に手を動かしてAWSリソースの構築や各種設定を行いましょう。書籍を読んだ段階で今一つ理解できなかったリソースは、やはりハンズオンで学ぶのが最も理解が進みます。 このUdemyのハンズオン教材はEC2やRDSといった代表的なリソースの構築のみならず、SAAの対策として非常に重要なAWS Well Architectedフレームワーク(設計のベストプラクティス)に則った構築や、API GatewayやLambda、SQSやSNSを用いたサーバレスの構築も経験することが出来ます。 実務未経験であったとしても、このハンズオン教材があれば実務経験者と対等に戦えるのではないかと思います。 教材が充実し過ぎているが故に、全てのハンズオンを行うとかなりの時間がかかります(30時間以上)。触れておきたいサービスや理解が浅いサービスを中心に、適宜選択しながら学ぶことをお勧めします。 （Udemyは動画の再生速度を自由に調整できるため、私はよく1.5倍速で視聴していました。） 3.2.3 Udemyの模試で最終仕上げ 上で紹介した【問題集２】のUdemyの模試を用いて最後の仕上げを行いましょう。 こちらの模試も難易度が少し高めに作られているので、いきなり60%を超えるのは中々難しいかもしれません。 問題を一通り解き終わった後は復習をよく読み、2周目以降解いたときに正解できるようにしておきましょう。復習を読んでもどうしても理解しずらい点は、書籍やハンズオン教材をうまく活用しながら少しずつ知識を増やしていきましょう。 Udemy模試を何度か繰り返し、応用レベルで8~9割取れる状態になれば、実際にSAAの試験を受けても合格する可能性が高いと思います。 3.3 AWS SAAまとめ AWS CLFと比較すると覚えるべき内容がかなり多いため、少し苦戦するかもしれませんが、書籍やハンズオン教材、模擬試験を駆使すれば未経験でも2~3か月学習すれば合格可能だと思います。 効率良く学習を進めてSAAを取得した後は違う技術を学ぶも良し、さらに次のレベルのAWS認定資格に挑戦するも良しです。Udemyのような便利な教材を上手に活用していきましょう！ 4. 使用した教材まとめ 上で紹介した教材を、評価やコメントを添えて改めて以下の表にまとめてみました。 対策 教材名 おすすめ度 ひとこと CLF 図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書 ★★★★☆ 知識ゼロでも非常に読みやすい CLF AWS認定資格試験テキスト AWS認定クラウドプラクティショナー ★★★☆☆ CLFのインプット用に便利 CLF この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集 ★★★★★ コスパが抜群 SAA AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト ★★★☆☆ SAAのインプット用に便利 SAA これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座 ★★★★★ 実務未経験者はマストバイSOA対策にも役立つ SAA 【SAA-C02版】AWS 認定ソリューションアーキテクト - アソシエイト模擬試験問題集 ★★★★★ コスパが抜群 実務未経験で実際にAWSに触れた経験がなくても、これらの書籍・Udemyの教材でSAAは十分に取得可能です。より難易度の高い試験を受ける場合は、AWS WEB問題集で学習しようもおすすめですが、こちらは3カ月で税抜4,480円～と少し値が張ります(2021/12現在) Udemyの教材はこれより安価かつ買い切りの料金体系なので、コストパフォーマンスの面でもUdemyの教材で学習する方がおすすめです！ 以下は私のマイラーニング(購入した教材)の写真です。模試はCLF用&SAA用全ての問題を解き、ハンズオン教材では自分が重要だと思った部分のみ学びました。実際に私が使用して「良い」と感じた教材なので、自信を持っておすすめ出来ます。 5. さいごに 以上が実務未経験の状態からAWS CLF & SAAを取得するための勉強法です。 私自身、実務が全くの未経験からの学習でAWSの資格取得にかなり苦戦しましたが、Udemyの教材を活用したことで効果的に学習を進めることが出来ました。もし「学習の進め方が分からない」という方は、ぜひ上記の流れを参考にして頂ければと思います。 この記事がこれからCLF・SAAを取得しようとされている方のお役に立てば幸いです！

PacketFence is a fully supported, trusted, Free and Open Source network access control (NAC) system. Here comes the installation notes that I have done on my RHEL EC2 instance. Environment I have tested the installation on my RHEL - here comes the detail. $ cat /etc/os-release NAME="Red Hat Enterprise Linux" VERSION="8.5 (Ootpa)" ID="rhel" ID_LIKE="fedora" VERSION_ID="8.5" PLATFORM_ID="platform:el8" PRETTY_NAME="Red Hat Enterprise Linux 8.5 (Ootpa)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:redhat:enterprise_linux:8::baseos" HOME_URL="https://www.redhat.com/" DOCUMENTATION_URL="https://access.redhat.com/documentation/red_hat_enterprise_linux/8/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8" REDHAT_BUGZILLA_PRODUCT_VERSION=8.5 REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux" REDHAT_SUPPORT_PRODUCT_VERSION="8.5" As PacketFence consumes a huge system resources, you need to deploy large instance so as to succeed an installation. I have deployed t3.xlarge instance. Here comes my instance's resources detail. $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz stepping : 7 microcode : 0x5003103 cpu MHz : 2500.000 cache size : 36608 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves ida arat pku ospke bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 5000.00 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz stepping : 7 microcode : 0x5003103 cpu MHz : 2500.000 cache size : 36608 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves ida arat pku ospke bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 5000.00 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz stepping : 7 microcode : 0x5003103 cpu MHz : 2500.000 cache size : 36608 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves ida arat pku ospke bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 5000.00 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz stepping : 7 microcode : 0x5003103 cpu MHz : 2500.000 cache size : 36608 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves ida arat pku ospke bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 5000.00 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: $ cat /proc/meminfo MemTotal: 16021788 kB MemFree: 6279768 kB MemAvailable: 10224076 kB Buffers: 2716 kB Cached: 4090160 kB SwapCached: 0 kB Active: 742532 kB Inactive: 8359032 kB Active(anon): 676 kB Inactive(anon): 5014020 kB Active(file): 741856 kB Inactive(file): 3345012 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 440 kB Writeback: 0 kB AnonPages: 4957232 kB Mapped: 283048 kB Shmem: 6040 kB KReclaimable: 194280 kB Slab: 374412 kB SReclaimable: 194280 kB SUnreclaim: 180132 kB KernelStack: 6880 kB PageTables: 72576 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 8010892 kB Committed_AS: 18876888 kB VmallocTotal: 34359738367 kB VmallocUsed: 0 kB VmallocChunk: 0 kB Percpu: 2928 kB HardwareCorrupted: 0 kB AnonHugePages: 837632 kB ShmemHugePages: 0 kB ShmemPmdMapped: 0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 313256 kB DirectMap2M: 11028480 kB DirectMap1G: 5242880 kB Steps Update package. $ sudo yum -y update Install firewalls. $ sudo yum -y install firewalld Install kernel development package. $ sudo yum -y install kernel-devel-$(uname -r) Define a repository. $ sudo yum -y localinstall http://packetfence.org/downloads/PacketFence/RHEL8/packetfence-release-11.1.el8.noarch.rpm Install! $ sudo yum -y install --enablerepo=packetfence packetfence Verify the installation If you see port 1443 processes, the installation went well! $ sudo lsof -i:1443 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME haproxy 118986 haproxy 12u IPv4 349246 0t0 TCP ip-172-31-31-43.us-east-2.compute.internal:ies-lm (LISTEN)

Japan APN Ambassador Advent Calendar 2021が、APN Ambassadorの皆様が著者になり始まりました！　2日目の本日は、2020年のAPN Ambassadorってなんだ？に引き続きまして、APN Ambassadorの説明と、今回はAPN Ambassadorのすごいところを、5つあげてみたいと思います。 自己紹介 Amazon Web Services Japanで パートナーアライアンス統括本部　テクニカルイネーブルメント部　にて PSA（Partner Solutions Architect） のマネージャーをしている相澤と申します。元々外資系コンピューターメーカのプリセールスエンジニアをしており、データベースやDWHを担当しておりました。AWSに入社後にオンプレミス脳だった自分自身がクラウド脳になった、その感動体験を世の中に広めたいという思いがありテクニカルイネーブルメント部という部署を2017年に立ち上げまして、現在に至っております。我々のチームではAWSのパートナー様、その中でも主にシステムイングレーターのエンジニアのサポートをさせて頂いております。 投稿内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。 APN Ambassadorとは？ APNとはAWS Partner Networkの略称です。APN Ambassador Program とは世界中のAWS Partnerから卓越した技術力を持ち、社外への情報発信（セミナーでの発信、Blogや書籍での発信）をしているメンバーが、日本のみならず世界中のAWS Partnerの中から選出されるProgramです。そのProgramにより選出されたエンジニアの皆様がAPN Ambassadorとなります。APN Ambassadorの皆様はAWSの技術に明るいだけでなく、豊富なバックグラウンドをお持ちの方々ばかりで私も一緒に仕事をさせていただく中で多くの刺激をもらっています。 2019年から選出をさせて頂いており、2019年、2020年、2021年と発表をさせていただきました。2021年2月現在、国内では31名のエンジニアの方が、APN Ambassadorとして活躍されおり、今年もその方々にAdvent Calendarを実施いただくこととなり、大変嬉しく、感激しております。 APN Ambassadorの5つのすごいこと 1 技術力がすごい 選出されているAmbassadorの方々は、AWSパートナー様の中でも、技術力に優れ、且つ社外へのアウトプットや社内でのエンジニア育成などに尽力されている方々となります。JAWS-UGでの活躍や、様々な書籍やBlogでの執筆活動など、また実案件での対応など全方位で活躍されている方々です。認定資格数も日本のAmbassadorの皆様の取得数は世界No1となっております。 2 モチベーションがすごい Ambassadorの皆様とは、実際のビジネスの場面でも会議で同席させてもらうことが多くあります。皆様、卓越した技術力を持ちながらも、各パートナー様の中で技術リーダーとして多くの判断を、素早く的確にされております。技術を通してビジネス貢献をしようとする、皆様の高いモチベーション、熱い気持ちはいつも刺激になります。 3 アウトプットがすごい 認定資格や技術力向上の為のインプットがすごいといつも感心しておりますが、それ以上にアウトプットの頻度、質の高さが皆様素晴らしいです。本の執筆や、Blogでの情報発信、　JAWS-UGや、各種セミナーなどでの皆様の技術力や経験に基づいたアウトプットの質の高さにはいつも感激しております。 4 コミュニケーション能力がすごい Ambassador（大使）である皆様は、とにかく伝えること、まとめる事、説得することがすごいと思います。またAmbssador Meetupなどでお話しさせて頂くときも圧倒的に面白い、技術の話じゃなくても、いろんな話が面白くコミュニケーション能力高いなー、すごいなーと毎回感心しております。 5 AWSロゴ付きパーカー所有数がすごい 毎年パーカーを副賞でお渡ししていたので、「多すぎです、そろそろパーカーじゃないのが欲しいです・・・」と複数の方から言われました。反省しています。もう少しレパートリーを増やしていきます。次回こそはパーカーじゃない副賞を準備します。 オススメのAWS勉強法 昨年も書いたいのですが、今年も多くのパートナー様からよく聞かれていますので、再度書かせてもらいます。なんと言っても手を動かす、やってみるというのが一番の勉強方法だと思います。AWSパートナーに向けて、我々のチームでもアイデアソン＋ハッカソンのような、手を動かすトレーニングを2019年から実施しております。ANGEL DojoとネーミングしたEnablement活動は2021年度も実施しており、参加パートナーの皆様からも、「実践型のトレーニングで手を動かす大切さを改めて感じました。」「参加したメンバーの急速な成長を実感できました。」 とのありがたい言葉をもらっております。ANGEL Dojoに関しては、21年度の参加者の感想がこちらから読めます。胸熱なBlogになっていますので是非ご覧ください。クラウドであれば直ぐに環境を準備できて試すことができます、まずは触ってみる、手を動かしてみるということにチャレンジしてみてください。 ほとばしる情熱！参加者全員が成長を実感した「ANGEL Dojo」での学びとは？ AWS主催のANGEL DojoにてANGEL賞1位とベストアーキテクチャ賞1位をW受賞しました 成果報告 ANGEL Dojo に参加して学んだこと ANGEL賞とベストアーキテクチャ賞をW受賞！AWS Japan主催の『ANGEL Dojo』に参加した感想 開発未経験者がANGEL Dojoに参加して得たものとは！ANGEL Dojoを振り返る 今後の抱負＆APN Ambassadorの皆様へ 2021年は、APN Ambassadorの皆さと直接お会いすることができず、私のチームの目標であった、「AWSパートナーと日本を元気に！」 をやり切れていないと思っています。2022年度はAPN Ambassadorの皆様と切磋琢磨しながら、楽しみつつ、日本を元気にする活動を行い、Make Historyをしていければと思っています。APN Ambssadorのすごい能力を集結して、面白い、ワクワクするようなことをやっていきましょう！ 2021年のAdvent Calendar毎日楽しみにしています！！

AWS Certified Cloud Practitioner 試験に合格しましたので、私が実践した試験勉強について記録したいと思います。 AWS Certified Solutions Architect – Associate 試験にも合格済みですが、それはまたの機会にします。 AWS 認定試験は 11 種あり、 AWS Certified Cloud Practitioner 試験は 基礎レベル に位置づけられます。 11 種の中で、 最初に合格を目指す試験 になると思われます。 AWS 認定試験に興味があり、合格のために どのような準備が必要なのか 参考になれば幸いです。 ただし、実際に出題された問題について口外することは AWS の規約に禁じられていますので、お答えいたしかねます。 AWS 利用経験 : 1 つの EC2 インスタンスを作成 & 利用した程度 Cloud Practitioner 勉強期間 : 16 日間 x 1 時間 利用した教材 一夜漬け AWS認定クラウドプラクティショナー 直前対策テキスト Kindle 版: ￥1,960 (税込) or 単行本: ￥2,420 (税込) AWS認定　クラウドプラクティショナー　模擬問題集 Kindle 版: ￥750 (税込) Cloud Practitioner 受験料 : ￥12,100 (税込) AWS の製品・サービスを把握 (1 日 〜 6 日目 の 6 日間) AWS が公開している AWS Certified Cloud Practitioner (CLF-C01) 試験問題サンプルを見ると、 AWS 固有のサービス名が多数見受けられます。勉強開始時点では、 Amazon EC2 や Amazon S3 の有名どころしか知らない状態でした。 まずは、『一夜漬け AWS認定クラウドプラクティショナー 直前対策テキスト』の 2 〜 9 章に目を通し、 どのような AWS の製品・サービスがあるのか、ざっくりと把握 しました。 受験予約 と 試験当日に向けての準備 (7 日目) 私は「ピアソン VUE」のテストセンターで受験しました。 AWS 認定試験は ほぼ毎日 受験することができますが、 試験開始の 24 時間以上前に受験予約 を済ませる必要があります。 高いモチベーションを保つため & 希望の日時で受験するため 、受験日の 7 日以上前に受験予約を済ませることをオススメします。 試験時間の 15 分以上前にはテストセンターの受付に到着 する必要があります。 テストセンターの受付では、 2 種の本人確認書類を提示 する必要があります。1 「運転免許証」と「健康保険証」の両方あれば問題ありません。 もし足りなければ、下記ページから代わりになる書類を探します。 ※ 受験票はありません。当日の持ち物は、上記の本人確認書類のみで受験できます。 模擬問題集でミニテスト (7 日 〜 16 日目 の 10 日間) 共に Cloud Practitioner 合格を目指す同僚 3 名を集めて勉強会を開き、『AWS認定　クラウドプラクティショナー　模擬問題集』の正答率を競い合いました。 試験時間 と 日々のミニテスト Cloud Practitioner 試験では、 90 分間で 65 問を解く 必要があります。日々の勉強会では、 18 分間で 13 問のミニテスト (1/5 スケール) を行いました。実践すると、 試験時間には余裕がある ことがわかります。試験当日は、半分の 45 分程で解き終えることができました。 試験時間 出題数 実際の試験 90 分 65 問 日々のミニテスト 18 分 13 問 ※ テストセンター等で 100 分と表記される場合、操作説明 5 分 & アンケート 5 分を含めての時間です 問題形式 択一選択問題 と 複数選択問題 の 2 つの問題形式を組み合わせて出題されます。2 択一選択問題 : 正しい選択肢が 1 つ、誤った選択肢 (不正解) が 3 つ提示される 複数選択問題 : 5 つ以上の選択肢のうち、正解が 2 つ以上ある 机上でのミニテストでは、複数選択問題に対して 2 つ目・ 3 つ目の選択を忘れるミスが起きました。 実際に「ピアソン VUE」のテストセンターで受験した際には、コンピュータ上で、各問題に対して選択の数が一致しないことに気が付ける仕組みでした。安心です。 試験当日 と 合否発表 (16 日目 と その後) 試験 65 問 & アンケートに回答後、 合否が表示 されます。 正式な合格連絡は試験 2 日後に AWS からメールで通知されました。書面での通知はありません。 AWS からの合格通知後、 AWS 認定デジタルバッジで合格を実証します。 その他の特典にもアクセスが可能になります。 特典の 1 つに 受験料の 50 % の割引 があります。 例えば、アソシエイト試験 (中級レベル) 下記 3 種のいずれかに挑戦するならば、 通常受験料￥16,500 (税込) の半額￥8,250 (税込) で受験できます。 基礎レベル (Foundational) / 通常受験料 : ￥12,100 (税込) 基礎コース : 1 種 AWS Certified Cloud Practitioner 試験 (CLF-C01) 中級レベル (Intermediate) / 通常受験料 : ￥16,500 (税込) アソシエイト : 3 種 AWS Certified Developer - Associate AWS Certified Solutions Architect – Associate AWS Certified SysOps Administrator - Associate 上級レベル (Advanced) / 通常受験料 : ￥33,000 (税込) プロフェッショナル : 2 種 AWS Certified DevOps Engineer - Professional AWS Certified Solutions Architect - Professional 専門知識 : 5 種 AWS Certified Advanced Networking - Specialty AWS Certified Data Analytics - Specialty AWS Certified Database - Specialty AWS Certified Machine Learning - Specialty AWS Certified Security - Specialty https://www.pearsonvue.co.jp/Test-takers/Tutorial/Identification-2.aspx ↩ https://d1.awsstatic.com/ja_JP/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf ↩

Amazon S3 Events via Amazon EventBridge Jeff先生のブログがおすすめ。もうこれ読んだらこの記事読まなくていいぐらい。 何がうれしいの？ 今までは - S3のイベント通知機能でイベントは取れたが、Lambda、SNS、SQSにしか送れなかった - CloudTrailでオブジェクトレベルの認証を有効化（別途課金）しないとEventBridgeでS3オブジェクトのイベントを取れなかった やってみた S3バケットのイベント通知でEventBridgeの設定をオンにします EventBridgeでイベントタイプ「Amazon S3 Event Nortification」が選択可能に！ S3の特定のイベントを選べるよ ターゲットはAPIにしてみました 今回は、自社のクラウドサービス Qanat Universe（Node-RED）に API リクエストしてみます 適当なファイルをPUSH aws s3 cp test.txt s3://niida-test/test.txt EventBridge経由で通知を取得できました！ まとめ EventBridgeでS3の通知を受けられるようになったことで、Lambdaを挟むことなく様々なサービス連携することが可能になりました！ - 画像がアップロードされたら、機械学習する - ログがアップロードされたら、解析系のバッチを回す 上記のような処理が直接ECSタスクやStepFunctionsに投げられるようになったのはかなり嬉しいです！ EventBridgeのルールをうまく書くことでバッチ系の処理をシンプルにできそうかなと思います！

こんにちは。職業「戸倉彩」です。 今年から、IBMが提供するパブリッククラウド 「IBM Cloud」 から 「IBM Cloud Paks」 に軸足を置いた活動を開始しました。今回はエンジニアの視点でIBM Cloud Pakとの出会いが、新たな技術との出会いにも繋がっている体験について共有したいと思います。 IBM Cloud Paks とは？ 一番最初に「IBM Cloud Paks(読み方: クラウドパックス)」と聞いた時、すぐに連想したのは「IBM Cloud」、すなわちパブリッククラウドにまつわるパッケージでした。しかし、すぐに予想が外れたことに気づくことになりました。 日本IBMのIBM Cloud Paks公式サイトによると 「ハイブリッドクラウド向けAIを搭載したソフトウェア」 という文字がトップに配置されています。つまり、書かれている通りソフトウェアなのです。 これまで長年、パブリッククラウドを専門に扱ってきた自分にとって、ソフトウェアの世界にシフトすることは、大きな変化であり新たな挑戦だと感じました。 コンテナ革命の流れ 近年、エンタープライズではデジタルトランスフォーメーション(DX)やビジネスプロセスの自動化に目が向けられています。この改革を推進する主要な技術として コンテナ が挙げられます。コンテナの登場により、ソフトウェアを分離し、独立して実行できるようにすることで、アプリケーションの統合と最新化を容易にすることができるようになったことは大きなアドバンテージと言えます。さらに、Kubernetesは、コンテナのオーケストレーションと管理のための強力なソリューションを提供している点などが評価され、さまざまな組織で使われて始めています。 ※ IBMは、IBM Cloud上でマネージドのKubernetesとして「IBM Cloud Kubernetes Service」 (略称、IKS)を提供しています。 2019年、IBMはRed Hat Corporationの買収し、Red Hat OpenShiftをベースにKubernetesの提供を標準化しました。 その頃から、私は 「Red Hat OpenShift on IBM Cloud」 について技術啓蒙する機会が増えていきました。 IBM Cloud Paksには未来が詰まっている コンテナ化されたアプリケーションを最初から構築するには、リソース、技術者、および管理ツールに多額の投資が必要です。また、クラウドネイティブのスキルや経験を持ち合わせている技術者が不足している状況でも、プロジェクトのタイムラインが短いケースも少なくありません。そのため、エンタープライズ向けにあらかじめ統合されているソフトウェアが求められています。 そこで、IBM Cloud Paks の出番です。 「IBM Cloud」という文字が入っていますが、これはハイブリッドクラウド向けに設計されたソフトウェアであることを意味しています。Red Hat OpenShift基盤上で、機能、セキュリティ、および復元力を損なうことなく、ビジネスプロセスを自動化、予測、最適化し、ビジネスモデルをより速いペースで最新化することを実現します。 繰り返しになりますが、ソフトウェアなのでオンプレ環境はもちろんのこと、Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)、IBM Cloudなどのパブリッククラウド環境に導入して利用することができます。私にとって、パブリッククラウドベンダーに依存せずにエンジニア活動の場を広げられることに、喜びを覚えました。また、コンテナ型で提供するミドルウェアだからこそ、新たなユースケースを創出できるチャンスに満ち溢れていることを感じました。 IBM Cloud Paksは、ソリューションに基づいてパッケージ化されており、エンタープライズで 最も差し迫ったさまざまな課題を解決することを支援 できるような多機能が提供されています。それは、社会に大きなインパクトをもたらす可能性を秘めているテクノロジーの集大成であり、技術者の意識と志を高く保つためのものと自分の中で位置付けました。ここでは、IBM Cloud Paksのシリーズをざっくりとご紹介します。詳しい情報につきましては公式サイトも合わせてご覧ください。 IBM Cloud Pak for Data：データの収集、編成、分析 データを自動的に検出し精選することでデータへのアクセスを簡素化すると同時に、使用を保護するためのポリシーを適用します。 技術分野: AI, Database, など IBM Cloud Pak for Business Automation：業務変革の推進 業務プロセスの見える化から、反復作業や処理プロセスの自動化を実現し、ビジネスパフォーマンスを向上させます。 IBM Cloud Pak for Watson AIOps： インテリジェントなIT運用の構築 AIをIT運用ツールチェーンのコアに配置し、実際の運用管理シナリオを解決しながら運用管理の決定を自動化して、実用的な洞察を提供します。 技術分野: AIなど IBM Cloud Pak for Integration： システム連携の自動化 アプリケーションとデータフローを自動化して、クライアントエクスペリエンスを向上させます。 技術分野: APIなど IBM Cloud Pak for Security：ゼロトラスト・アーキテクチャーの展開を簡素化 脅威に対するより深い洞察を生成し、スケーラビリティーと自動化された応答のためのアクションを調整します。 技術分野: Security IBM Cloud Pak for Network Automation：ゼロタッチのネットワーク運用を実現 IBM Cloud Paks for Automationの一部として、クラウドとAIを活用したオートメーションによりネットワークを変革します。 技術分野: Networkなど 最後に 実際にIBM Cloud Paksを活用する際には、何をするかによって必要となる技術やスキルは異なります。 私は、IBM Cloud Paksと出会ったことをきっかけに、クラウドエンジニアになる前に専門にしていたセキュリティ分野の最新技術もキャッチアップしつつ、DevSecOpsやこれまであまり触れたことのないパブリッククラウドの技術も触る機会が増えてきました。まるで新しい扉を開けていくような感覚を味わっているところです。 本記事は、IBM Cloud Paks Advent Calendar 2021のDay1の記事として公開しました。この後、こちらのアドベントカレンダーに参加されている方々によって、それぞれのIBM Cloud Paksにフォーカスした技術解説や利用方法が投稿されると思いますので、一緒に楽しみましょう。皆さんにとっても「IBM Cloud Paks」との出会いが新たな技術や気づきなどに繋がることを願ってます。 参考リンク IBM Cloud Paks - 日本IBM IBMソリューションブログ What are IBM Cloud Paks? - IBM Blog