20211013のAWSに関する記事は13件です。

AWS SAMでLambdaに設定したS3イベントトリガがコンソールに表示されない問題の対応

AWS SAMでLambdaにS3イベントトリガを設定したところ 動作は想定どおり行われるが、AWSコンソールのイベントトリガには 何も表示されない事象が発生しました。 これは既知の問題のようで https://github.com/aws/serverless-application-model/issues/300 で議論されていました。 上記にも記載されていますが対応方法のサンプルです。 最初の定義。以下ではAWSコンソールにイベントトリガが表示されない。 MyFunction: Type: AWS::Serverless::Function Properties: CodeUri: MyFunction/ Runtime: python3.8 Handler: app.handler FunctionName: !Sub - "${prefix}MyFunction" - { prefix: !FindInMap ["EnvMap", !Ref Env, "Prefix"] } Events: MyFunctionEvent: Type: S3 Properties: Bucket: !Ref FileUploadBucket Events: s3:ObjectCreated:* Policies: - AmazonDynamoDBReadOnlyAccess - AWSLambdaVPCAccessExecutionRole - AmazonElasticFileSystemClientReadWriteAccess - S3CrudPolicy: BucketName: !Sub - "${prefix}fileupload-bucket" - { prefix: !FindInMap ["EnvMap", !Ref Env, "Prefix"] } # S3バケット定義 FileUploadBucket: Type: "AWS::S3::Bucket" Properties: BucketName: !Sub - "${prefix}fileupload-bucket" - { prefix: !FindInMap ["EnvMap", !Ref Env, "Prefix"] } AccessControl: Private PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true LifecycleConfiguration: Rules: - ExpirationInDays: 7 Id: !Sub - "${prefix}MyBucketLifecycleRule" - { prefix: !FindInMap ["EnvMap", !Ref Env, "Prefix"] } Status: "Enabled" Prefix: fileupload/ 対応として以下の定義を追加します。 SAMで定義した場合に内部的に定義されるようなものを明示的に 定義してあげる形になります。 定義の中で対象関数のロール名を指定する必要があるのですが SAMで明示的にロール名を指定しなかった場合は Lambdaの論理名 + Role で作成されるので !GetAtt MyFunctionRole.Arn のように参照すればOKです。 # 対象のS3バケットのポリシー定義 FileUploadBucketPolicy: Type: 'AWS::S3::BucketPolicy' Properties: Bucket: !Ref FileUploadBucket PolicyDocument: Statement: - Action: - 's3:*' Effect: 'Allow' Resource: !Sub 'arn:aws:s3:::${FileUploadBucket}/*' Principal: AWS: !GetAtt MyFunctionRole.Arn # 対象のLambda関数のPermissionを明示的に追加 MyFunctionInvokePermission: Type: 'AWS::Lambda::Permission' Properties: FunctionName: !GetAtt MyFunction.Arn Action: 'lambda:InvokeFunction' Principal: 's3.amazonaws.com' SourceAccount: !Ref 'AWS::AccountId' SourceArn: !GetAtt FileUploadBucket.Arn 以上
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS] 作成済みEC2インスタンスのセキュリティグループをAWS SDK for Python(Boto3)で変更する

本記事は「作成済みEC2インスタンスに割り当てているセキュリティグループ」をAWS SDK for Python(Boto3)で変更する方法のメモです。 ここの設定を変更したい: 変更するメソッド メソッドは EC2 : modify_instance_attribute() を使用します: ec2_client = boto3.client('ec2', 'region') ec2_client.modify_instance_attribute( InstanceId = 'string', Groups = [ 'string', ] ) 設定例: ec2_client = boto3.client('ec2', 'ap-northeast-1') ec2_client.modify_instance_attribute( InstanceId = 'i-0da123456', Groups = [ 'sg-35b28551', 'sg-35b28552' ] ) 関連情報の収集 変更する場合、変更前にインスタンスに設定されているグループIDのリストが必要になることも多いかと思います。その場合は EC2 : describe_instance_attribute() メソッドで取得します。 ec2_client = boto3.client('ec2', 'region') response = ec2_client.describe_instance_attribute( Attribute = 'groupSet', InstanceId = 'string' ) 実行例: ec2_client = boto3.client('ec2', 'ap-northeast-1') response = ec2_client.describe_instance_attribute( Attribute = 'groupSet', InstanceId = 'i-0da123456' ) for group in response['Groups']: print(group['GroupId']) sg-35b28550 sg-35b28551 このグループIDのリストを追加変更して modify_instance_attribute() のグループリストに設定する流れとなります。 参考資料 EC2 : modify_instance_attribute() 作成済みのEC2インスタンスにセキュリティグループを追加する [AWS] 作成済みEC2インスタンスのセキュリティグループをAWS Tools for PowerShellで変更する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS] 作成済みEC2インスタンスのセキュリティグループをAWS Tools for PowerShellで変更する

本記事は「作成済みEC2インスタンスに割り当てているセキュリティグループ」をAWS Tools for PowerShellで変更したい場合のコマンドメモです。 ここの設定を変更したい: 変更するコマンド コマンドは Edit-EC2InstanceAttribute Cmdlet を使用します: Edit-EC2InstanceAttribute -InstanceId <String> -Group <String[]> 実行例:PowerShellに不慣れだと間違えやすいですが、リストは @() 形式での指定になります。 Edit-EC2InstanceAttribute -InstanceId 'i-0da123456' -Group @( 'sg-35b28551', 'sg-35b28552' ) 関連情報の収集 変更する場合、変更前にインスタンスに設定されているグループIDのリストが必要になることも多いかと思います。その場合は Get-EC2InstanceAttribute コマンドで取得します。 Get-EC2InstanceAttribute -InstanceId <String> -Attribute 'groupset' 実行例: $current_sgs = Get-EC2InstanceAttribute -InstanceId 'i-0da123456' -Attribute 'groupset' foreach($group in $current_sgs.Groups) { $group.GroupId } sg-35b28550 sg-35b28551 このグループIDのリストを追加変更して Edit-EC2InstanceAttribute の引数に設定する流れとなります。 参考資料 Edit-EC2InstanceAttribute Cmdlet Get-EC2InstanceAttribute Cmdlet 作成済みのEC2インスタンスにセキュリティグループを追加する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Windowsでgit-secretsを利用する

git-secrets は AWS Labsで提供されているツールの一つです。 ※AWS Labsはawsが提供しているツールなりスクリプトなりが置いてある場所 git-secretsを利用する事により、AWSアクセスキー、AWSシークレットキーをgitリポジトリにコミットできないようにコミット直前にチェックできるようになります。 他にもファイルを検索したり、独自のルールを設定したい色々と機能があります。 今回はそんなgit-secretsをWindows環境にインストールして利用してみます。 余談 git-secretsって昔はREADMEにWindows環境へのインストール方法が書いてなくてWindowsで使えないのかと思ってましたが。 Writing instructions for how to get git-secrets to work for Windows #87 上記でWindows環境への導入方法が追加されてから、今現在はインストール用のPowerShellスクリプトも用意されています。 Windows環境にgit-secretsをインストールしてみる Installing git-secrets - Windows インストール用のPowerShellスクリプト(install.ps1)が用意されているのでコチラを実行します。 前提条件としてgitがインストールされていて、PowerShellスクリプトが実行できるようになっている必要があります。 下記のコマンドをPowerShellで実行して下さい。 【PowerShell】git-secretsのインストール git clone https://github.com/awslabs/git-secrets # このスクリプト。install.ps1があるディレクトリをカレントディレクトリにして実行しないと動かないのでcdする。 cd git-secrets ./install.ps1 スクリプトが正常終了すればインストールは完了です。 ちなみにスクリプトが何をやっているかといえば、 %USERPROFILE%/.git-secretsにgit-secretsとgit-secrets.1をコピーして、%USERPROFILE%/.git-secretsを環境変数PATHに追加しています。 git-secretsを利用できるようにリポジトリにgit hookを設定する git-secretsをインストールしただけでは認証情報をコミット時の含まれているかのチェックはしれくれない状態です。 これはgit-secretsがgit hookの機能を利用してチェックをおこなっているためです。 チェックするためには、対象となるリポジトリにgit hookをインストールする必要があります。 ここではcheck-repというリポジトリを作成して、このリポジトリに対してgit hookをインストールしてAWSシークレットキーがコミットされたかチェックしてみます。 まずはリポジトリにgit hookをインストールして、git secrets --listでgit secretsの設定を確認してみます。 【PowerShell】リポジトリの初期化とgithookのインストール # gitリポジトリの初期化 git init check-rep cd ./check-rep # git hookのインストール git secrets --install # aws認証情報用のパターンをgitconfig(ローカル)に書き込み) git secrets --register-aws # リポジトリに設定されているsecretsのconfigを表示 git secrets --list git secrets --listを実行すると事前登録されているパターンで下記設定が表示されるかと思います。 git_secrets_--listの表示 secrets.providers git secrets --aws-provider secrets.patterns (A3T[A-Z0-9]|AKIA|AGPA|AIDA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16} secrets.patterns ("|')?(AWS|aws|Aws)?_?(SECRET|secret|Secret)?_?(ACCESS|access|Access)?_?(KEY|key|Key)("|')?\s*(:|=>|=)\s*("|')?[A-Za-z0-9/\+=]{40}("|')? secrets.patterns ("|')?(AWS|aws|Aws)?_?(ACCOUNT|account|Account)_?(ID|id|Id)?("|')?\s*(:|=>|=)\s*("|')?[0-9]{4}\-?[0-9]{4}\-?[0-9]{4}("|')? secrets.allowed AKIAIOSFODNN7EXAMPLE secrets.allowed wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY この情報がどこに登録されているかといえば、該当リポジトリのgit config --local --listを見ればみつかります。 眺めているとなんとなく想像はつきますが、アクセスキー、シークレットキーと判断するためのパターンが設定されています。 一点注意なのは、よくドキュメントでサンプルとして利用されいている アクセスキーAKIAIOSFODNN7EXAMPLE シークレットキーwJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY はsecrets.allowedとして許可設定に含まれているため。 git secretsの動作を確認する用途として、このサンプルアクセスキーを利用してしまうと。 許可設定されているので普通にコミットできてしまう点は認識しておく必要があります。 git hookを設定したリポジトリにシークレットキー(サンプル)をコミットしてみる 先程、AWSアクセスキーシークレットキーを判断するパターンを確認しました。 この条件に引っかかるようなシークレットキーをファイルに書き出してコミットしてみます。 ※今回は"aws_secret_access_key = GitSecretsCommitTestCaseSampleKeysSample" 【PowerShell】シークレットキーをコミットする # さきほど設定したリポジトリにサンプルファイルを作成 New-Item -Name ./secret -Value "aws_secret_access_key = GitSecretsCommitTestCaseSampleKeysSample" git add ./secret git commit -m test git commit を実行した段階で下記のエラーが表示されてgit commit が阻害されている事がわかります。 コミット時のエラーメッセージ [ERROR] Matched one or more prohibited patterns Possible mitigations: - Mark false positives as allowed using: git config --add secrets.allowed ... - Mark false positives as allowed by adding regular expressions to .gitallowed at repository's root directory - List your configured patterns: git config --get-all secrets.patterns - List your configured allowed patterns: git config --get-all secrets.allowed - List your configured allowed patterns in .gitallowed at repository's root directory - Use --no-verify if this is a one-time false positive これで該当リポジトリについては、git-secretsのAWSアクセスキーとシークレットキーのチェック機能が追加された事が確認できました。 テンプレートに登録してリポジトリの初期化時にgit hookのインストールを自動で実行するようにする リポジトリごとに毎回git hookをインストールしてもよいのですが、git cofingで用意されているinit.templateDirにテンプレート登録することで、git init、git clone時に自動的にgit-secrets用のgit hookをインストールする事ができます。 ※2021年10月現在の注意点 この手順で利用するコマンドについて。 コマンドプロンプト と Windows PowerShell で git secrets --install ~/.git-templates/git-secretsがうまく動かない事を確認しています。 ですのでここでのコマンドGit for WindowsをインストールしたときについてくるGit Bashを利用して実施して下さい。 【GitBash】リポジトリ初期化時に自動でインストールするようにテンプレート設定 # 下記はGitBashで実行して下さい # 前回はリポジトリごとにgit config(ローカル)を設定していましたが globalをつけて git config(グローバル)に設定を書き込み git secrets --register-aws --global # テンプレートファイルを生成 git secrets --install ~/.git-templates/git-secrets # git configのinit.templateDirに生成したテンプレート使うように設定 git config --global init.templateDir ~/.git-templates/git-secrets 上記のコマンドを実行することで、シークレットチェック用のパターンをgit config(グローバル)に設定し、どのリポジトリでも同様の設定を利用するようにしています。 またgit config(グローバル)のinit.templateDirにテンプレートを設定することによりリポジトリ初期化時に~/.git-templates/git-secretsをテンプレートとして利用するように登録しています。 ここまでの設定したあとにリポジトリ初期化を実行すると、自動でgit hookがインストールされている事を確認できます。 【PowerShell】 git init check-rep cd ./check-rep New-Item -Name ./secret -Value "aws_secret_access_key = GitSecretsCommitTestCaseSampleKeysSample" git add ./secret git commit -m test コミット時にチェックエラーが表示される事を確認できるかと思います。 git secrets --install ~/.git-templates/git-secretsがWindows環境ではばくってる 2021年10月現在。 git secrets --install ~/.git-templates/git-secretsコマンドを実行してgit-secrets用のテンプレートを生成しますが。 コマンドプロンプトとWindows PowerShellで実施すると期待を裏切り。 カレントディレクトリに ~/.git-templates/git-secrets というテンプレートを作成します。 ホームディレクトリにテンプレートを作成しないで~(チルダ)というフォルダの下にテンプレートファイルを作成してしまう…… これはなかなかに残念な感じ。 試した所、PowerShell 7、Git Bashだと問題なくホームディレクトリにテンプレートを作成してくれますが。 コマンドプロンプト、Windows PowerShell、Git CMDだとうまく動かないようです。 template install fails on Windows #123 git hookの設定を解除する 一度git-secretsで管理するように設定したリポジトリをgit-secretsの管理から外したい場合はgit hookの設定を削除する必要があります。 git secretsのコマンドからアンインストールできれば便利そうですが、現状ではマニュアルでファイルを削除して対応する方法しかないようです。 feature request: uninstall Add Remove command to remove patterns that were added #125 対象リポジトリからgit hookを削除する場合 対象リポジトリの下記3ファイルを削除すれば問題ないようです。 .git/hooks/commit-msg .git/hooks/pre-commit .git/hooks/prepare-commit-msg 気になるようだったらgit config(ローカル)に追加したsecrets.*な設定も削除して下さい。 テンプレート登録を解除する場合 git secrets --register-aws --globalでグローバルに紺地る設定して、init.templateDirにテンプレート登録を実施し、自動でgit hookをインストールしている場合は下記方法で解除できます。 git config(グローバル)に書き込んだsecrets.*な設定の削除 git config(グローバル)に書き込んだinit.templateDirな設定の削除 ~/.git-templatesの削除 git config --global --editを実行するとエディタが起動するので、直接gitconfigのパラメータを更新することができます。 こちらから登録したsecrets.*のパラメータとinit.templateDirを削除して下さい。 最後に、テンプレートファイル~/.git-templatesも削除すれば完了です。 もしくはgit configのグローバルな設定は~/.gitconfigファイルに書き込まれているためこのファイルからsecrets.*、init.templateDirな設定を削除して下さい。 あとgit config --global --unset,git config --global --unset-allコマンドにパラメータ名をそれぞれ渡す方法でも削除できます。 【削除対象】gitconfigの設定 [secrets] providers = git secrets --aws-provider patterns = (A3T[A-Z0-9]|AKIA|AGPA|AIDA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16} patterns = (\"|')?(AWS|aws|Aws)?_?(SECRET|secret|Secret)?_?(ACCESS|access|Access)?_?(KEY|key|Key)(\"|')?\\s*(:|=>|=)\\s*(\"|')?[A-Za-z0-9/\\+=]{40}(\"|')? patterns = (\"|')?(AWS|aws|Aws)?_?(ACCOUNT|account|Account)_?(ID|id|Id)?(\"|')?\\s*(:|=>|=)\\s*(\"|')?[0-9]{4}\\-?[0-9]{4}\\-?[0-9]{4}(\"|')? allowed = AKIAIOSFODNN7EXAMPLE allowed = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY [init] templateDir = C:/Users/Administrator/.git-templates/git-secrets git secrets --scan 今まではコミット時にチェックを実施していましたが。 git secrets --scan を利用することにより、ファイルに対してチェックを実施できます。 scna # リポジトリ中で実行すればリポジトリのファイル全スキャン git secrets --scan # ファイル名を指定すれば対象のみをスキャン git secrets --scan ./secret # `git secrets --scan -`とすれば下記のような事もできる Write-Output 'aws_secret_access_key = GitSecretsCommitTestCaseSampleKeysSample' | git secrets --scan - 総評 今回は紹介していませんが、git-secretsには自分でプロバイダを追加して、指定したルールでファイルをチェックする機能を提供しており。 設定さえすればAWSアクセスキー、シークレットキーに限らず、特定の機密情報のコミットを防ぐような事も実現できます。 一度設定したリポジトリを対象から外す際は、リポジトリのgit hook設定を元に戻したりと少し戸惑うかもしれませんが。 便利に利用できるツールになるかと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS:S3からのデータのダウンロードとアップロードについて

なぜ書こうと思ったのか インターン先で、AWSを初めて使うようになり、S3からのデータのダウンロードとアップロードが苦戦したので、整理のために書こうと思いました。 目次 そもそもS3とは? S3への接続とその確認方法 S3からのダウンロードとアップロード そもそもS3とは? Amazon Simple Storage Service、通称S3はオブジェクトストレージサービスであり、様々なユースケースのデータを保存して保護することができる。さらには、データを整理してアクセス制御を細かく調整するために使いやすい機能を提供するサービスである。 S3のメリットについては、以下の記事を参考 - S3のメリット S3への接続とその確認方法 今回はSagemaker上で行っています。 ローカルで行う場合は、configureの設定を行ってから進める必要があります。 バケットへの接続 name部分には、抽出したいファイルがあるS3上のバケット名をいれます。 import boto3 #バケットへの接続 s3 = boto3.resource('s3') bucket = s3.Bucket('name') このときに、jupyter上で print(bucket) を実行してバケット名が表示されていれば、接続ができていると思われます。 ファイルのダウンロードとアップロード バケットからのダウンロード 対象のファイルをダウンロードしたい場合 bucket.download_file(file_path, file_name) file_pathには、s3上での抽出したいファイルのpath file_nameには、保存時のファイル名 一度にすべてのファイルをダウンロードしたい場合 !aws s3 cp s3://'s3上でのバケット名'(/file_path) 'ダウンロード先のフォルダ' --exclude "" --include "*" --recursive excludeオプション exclude オプションは、コマンドからオブジェクトのみを除外するようにルールを設定します。 includeオプション include オプションは、指定したオブジェクトのみをコマンドに含めるようにルールを設定します。 recursiveオプション recursiveオプションは、指定のディレクトリ内またはプレフィックス内のすべてのファイルやオブジェクトに対してコマンドが実行されます バケットへのアップロード  bucket.upload_file(file_name, file_path) file_nameには、アップロードするファイル名 file_pathには、バケット内のどのフォルダ内にアップロードするかのpathを指定する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSから突然$52.92(6031円)の請求が来たときの話

はじめに 最近、pythonでAWSでのいくつかのAIサービスの学習をスタート AWSでAIサービスを使ってみる〜第11回Personalize編〜 ちょうどPersonalizeの試しの学習を終え、Qiitaへの記事投稿もひと段落した 約一週間後、、、、、、その通知は届き来ました。 ハイ!? $52.92? 一体これはどういうことなんだってばよ!? 気づいたときは 時すでに遅し 9月末からpersonalizeの請求が入っており、気づいたのが10月であったため10月分の請求も含まれていました。。。 Cost Explorer 何が起こっていたのか 実際の請求の内容はpersonalizeの学習の後、データセットを停止させずにそのままACTIVE状態のまま翌月まで起動させていたため(気づけよ)、無料枠の請求を超えて通常の請求が入ったようですね。 使用していなかったためpersonalizeのデータセットは削除しました。削除も順番があり、作成したキャンペーンやソリューションから削除する必要があるので注意です。 無料枠を超えたメールが来ていました。 終わりに AWSのAIサービスは将来的なWebサービスの中核として期待されていますが、ご利用には注意が必要ですね。 personalizeのみでなくForcastもいくらか請求額があるため、検証する事柄やデータは事前に調整して必要なデータのみ利用することをオススメします。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS,APIGateway,SAM]InvokeRoleのCALLER_CREDENTIALSについて

AWS SAMでtemplate.yamlを書いており、APIGatewayのリソースを作成しようとした際に迷ったので記事にしておきます。 AWS公式の記事は少し読みづらいです。 とても限定的な記事なのでほとんど読まれないと思いますが、同じような疑問を思っている人の助けになれば。 InvokeRoleでは何を設定するのか InvokeRokeに設定するのはずばり「APIGatewayの権限」になります。 IAMロールのARNを入れれば、APIGatewayの権限は指定したIAMロールと同等の権限をもつことになります。 公式ドキュメントによると、InvokeRoleに設定できるのは以下の値です。 CALLER_CREDENTIALS, NONE, IAMRoleArn 何も設定しない場合、CALLER_CREDENTIALSが適用されます。 さて、ここでCALLER_CREDENTIALSについてです。 一見すると意味が分かりません。 CALLER_CREDENTIALSとは CALLER_CREDENTIALSとは、APIGatewayを呼び出す際に渡した認証情報をそのまま使うということです。CALLERのCREDENTIALSですので、呼び出し側の認証情報です。 実際にマネジメントコンソールのヘルプにも、以下のように表示されています。 ここで、「APIGatewayによって受信された認証情報ってなんじゃい!」という話になってきます。 具体例を見ていきましょう。 APIGatewayを呼び出す際に、以下のようにIAMロールの認証情報を一緒に送ることが出来ます。 以下のソースではaws_requests_authというライブラリを利用していますので、詳しい実装を知りたい場合はこちらを参考にしてください。 credentials = get_credentials() # stsからIAMロールのcredentialsを取得 auth = AWSRequestsAuth( aws_access_key=credentials['AccessKeyId'], aws_secret_access_key=credentials['SecretAccessKey'], aws_host=aws_host, aws_region=REGION_NAME, aws_service='execute-api' ) headers = {'x-amz-security-token': credentials['SessionToken']} response = requests.post( url, json={"foo": "bar"}, auth=auth, headers=headers) この時、APIGatewayではIAMロールの認証情報が受信されています。 というわけで、このような形で「受信された認証情報」をつかうことになるわけです。 なので、ここで指定しているIAMロールの権限と同等の権限をAPIGatewayが行使することになります。APIGatewayの呼び先がLambdaである場合、IAMロールにはLambdaの実行権限を付けてあげないと実行できなくなるということです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AI知識不要】AWS DeepRacer の始め方【無料で機械学習エンジニアの仕事を疑似体験】

AWS DeepRacer を始めたいと思っている人 AIに興味はあるが、勉強を始めるきっかけが無い AWS触ったことないが大丈夫か心配、DeepRacerがどれくらい料金かかるのか知りたい こういった悩みに答えます。 本記事の内容 本記事を読むと下記のことが分かります。 AWS DeepRacerをやると得られるもの AWS、AI知識0でも問題ない理由 AWSアカウント作成からDeepRacerリーグ出場するまでの手順 記事の信頼性 筆者はAWS経験5年程度です。AWS資格は5冠+AWS Certified Machine Learning - Specialty取得しました。 DeepRacer使用歴は一年程度です。 AWS DeepRacer の始め方 AWS DeepRacerの始め方の具体的な手順を説明する前に AWS DeepRacer をやることで得られることや AWS、AI知識0でも問題ない理由についてお伝えしておきたいと思います。 それでは見ていきましょう。 AWS DeepRacer をやると得られるもの 機械学習エンジニアの仕事を疑似体験できる AI案件の仕事の流れは データ準備→モデル生成→モデル理解→効果検証→モデル運用管理→モデル更新 の流れです。 参考:下記より画像引用 CUS-85:製造業における IoT×AI/ML 基盤の構築とその運用事例 AWS DeepRacerではデータ準備を行うことなく モデル生成からモデル更新までの一連の流れを楽しく体験できるつくりになっています。 一般的にはデータの準備はデータサイエンティストが行い、 機械学習エンジニアがモデル生成を行うという現場が多いらしいです。 AI導入ではデータ準備が一番大変と言われていますが、ここはAWS DeepRacer では意識しなくて良い部分になります。 AIについての勉強意欲 筆者はAWS DeepRacer を1年くらいやっていますが、AI案件を疑似体験していく中で、徐々に機械学習エンジニアを目指したいと思うようになりました。 そこでAI全般の知識を得たいと思うようになり、せっかくなら資格取得しようと思い、 AWS Certified Machine Learning - Specialty を取得できました。 今回は明確な目的があったので、今まで取得した資格よりも知識が定着したと思います。 AWS、AI知識0でも問題ない理由 AWSの目標 AWSの目標として 「AWS の目標は、すべてのデベロッパーやデータサイエンティストが ML を使えるようにすることです。」 と記載があります。 AWS DeepRacer はその目標を実現するために 初心者が楽しく学ぶツールとして開発されたサービスです。 このような思想なので、誰でも簡単に利用できるように配慮されています。 AWS知識0なので料金が心配 AWSを使ったことないので、どれだけ料金がかかるか心配になった方もいるかもしれません。 AWSは従量課金(使った分課金)ですが、知らないうちに使いっぱなしになっていて、予期しない料金の請求が来たという記事を見たことがあります。 AWS DeepRacer は上記のようなことが起こらないように時間が経つと自動停止したりなど、 AWS初心者でも問題が起こらないように配慮されたサービスになっています。 ※AWSアカウント作成時にセキュリティについては意識する必要がありますが、それは後述します。 AWSアカウント作成からDeepRacerリーグ出場するまでの手順を紹介 AWS DeepRacer を始める前に概要を理解 AWS DeepRacer やAIの概要を理解できる動画があるので、実作業に入る前に見ておくと良いです。 【STEP1】動画で見よう「AWS DeepRacer 概要」 30分程度 ※「ハンズオンを終えた後も環境をそのままにしておくとAWS利用料金が発生します。」と記載がありますが、 2021年現在はそのようなことが起こらないような設計に改善されていますので、気にする必要なしです。 AWSアカウント作成 AWS Hands-on for BeginnersというAWS初心者向けのハンズオンの中に AWSのアカウント作成について必要な知識を学びながら実際にアカウント作成できるハンズオンがあります。 IAMはAWSのセキュリティに関わる部分なのでしっかり理解しておきましょう。(動画は1時間くらいです) 今回だとAWSDeepRacerFullAccessとBillingのポリシーだけで大丈夫なはずですが、 ログ分析にSageMakerを使う場合など不足があれば都度足していきます。 IAMユーザで請求情報を見るにはIAMポリシーの設定とは別に 「IAMユーザー/ロールによる請求情報へのアクセス」 の設定が必要になります。 下記の記事が参考になります。 【AWS】IAMユーザに「マイ請求ダッシュボード(Billing & Cost Management)」閲覧権限を付与する https://soypocket.com/it/aws-iam-tutorial-billing/ ※Rootユーザを利用する場合は最低でもMFAは設定しておきましょう。 【AWS】ルートアカウントのMFA有効化方法 https://qiita.com/satton6987/items/31e0eecdc9fa33d9c609 AWS DeepRacer ハンズオンの実施 下記のハンズオンに従うとDeepRacer リーグ出場までが一通り経験できるようになっています。 AWS DeepRacer Workshop パラメータの意味理解は難しいと思いますので、まずはデフォルト値で1周してみましょう。 モデル生成→モデル理解→効果検証 までの機械学習の流れを簡単に体験することができます。 学習と評価の時間が10時間までは無料でできるので、デフォルトの学習時間(60分)だと9周までは無料で体験できます。(評価は1回5分程度) 10時間を超えると1時間あたり350円程度の料金がかかります。 念のため、料金はこまめにBillingで確認するようにしてください。参考手順を貼っておきます。 月額料金の表示 さいごに AI知識をどうやって高めるのが良いのかはいろいろなやり方があると思うのですが、 筆者自身はモチベーションの維持という意味で AWS DeepRacer みたいなゲーム感覚で楽しめるツールがあるのは大変助かりました。 本記事がAI知識を高めたいがやり方が分からない方の参考になれば幸いです。 そもそもAIを勉強するか迷っている方で、意思をより固めたい場合は、 AI業界について記載した下記の記事も参考になると思います。 インフラエンジニアのAI(ML)入門→MLOpsへ【AWS DeepRacerで学ぶ】 https://qiita.com/toma_shohei/items/43279b3a5c82e186211b
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

セキュリティグループとネットワークACLのメモ

はじめに SAA取得に向けた勉強をしてるけど、インプットだけではなかなか頭に入ってこないので各サービスの特徴などをメモがてら書いてます。 この行動が結果に繋がるといいな。 AWSのドキュメントをベースに セキュリティグループの特徴 EC2インスタンスなどの受信トラフィックと送信トラフィックを制御してくれる。(インスタンス単位の通信制御を適用することができる) デフォルトでは同じセキュリティグループ内の通信のみを許可している。 ステートフルなため、インバウンドの許可設定をしたらアウトバウンドの通信も許可される仕組みになってる。 設定は許可設定だけできる(拒否したい通信はセキュリティグループ内に入れない) すべてのルールが適用される ネットワークACLの特徴 サブネット単位での通信を制御を適用することができる。 デフォルトではすべての通信を許可する設定になっている。 ステートレスなため、インバウンドの設定だけではなくアウトバウンドの設定が必要。 設定は許可だけではなく拒否設定もできる。 制御ルールに付与される番号順にルールが適用される。 参考 VPC のセキュリティグループ ネットワーク ACL
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Amplifyで静的サイトを構築してみた

背景 今年の初めに法人を作ったので、楽天銀行で法人口座を開設しようと手続きを進めてみたら、自社Webサイトがあると提出書類が減るとのことだったので簡易にサイトを構築してみました。 楽天銀行 口座開設に必要な書類 最近PO/PM業務が多かったので久しぶりの技術です。 事前の用意 ドメイン(AWS Route53で取得も可) AWSアカウント githubアカウント 私はmuumuuドメインでドメインを取得、静的サイトはReactで作りました。 構築手順 ほぼここに書かれた内容そのままですが、手順を追って説明します。 静的サイトの構築 まずはローカル環境で静的サイト(Reactアプリ)を作ります。Reactって何?って方はこちらを参照ください。 npx create-react-app mysite cd mysite yarn start githubリポジトリの作成 githubで新しくリポジトリを作成します。 githubへ静的サイトをpush Reactアプリのディレクトリで以下のコマンドを打ちます。環境によって6行目の文字列は異なるのでgithubでリポジトリ作成時に表示されたコマンドをそのまま打ちましょう。 echo "# mysite" >> README.md git init git add README.md git commit -m "first commit" git branch -M main git remote add origin git@github.com:account/mysite.git git push -u origin main githubのデフォルトのブランチがmasterからmainに変わってました。 AWS Amplifyからgithubに接続 Amplifyから、githubで作成したリポジトリへ接続して、Reactアプリをデプロイしてあげます。 Amplifyにアクセスして、いくつかの質問に答えていくだけで設定が終わります。 ここまでくれば、Amplifyのサブドメイン上で、作成したReactアプリがインターネット公開されます。とても簡単ですね。 以前、herokuでもReactアプリをデプロイしたことがありますが、それと比べるととても簡単でした。 ドメイン設定 取得済みのドメインでサイトにアクセスできるようにします。 Route 53のここからホストゾーンの作成をします。 そうすると、ネームサーバー情報が表示されるので、これをドメイン取得サイト(私の場合はmuumuu)に設定します。 ネームサーバー設定の以下の部分にRoute 53で表示されたネームサーバーを入力します。 あとは、Amplifyのドメイン管理からドメインを割り当てます。 設定画面を取り忘れましたが、設定が終わると以下のような画面になります。 以上で作業は完了です。 補足 一部画像が表示されない事象が発生したので調べたら、拡張子をjpegとしているのがだめだったようで。 以下の”書き換えて、リダイレクト”(翻訳が、、、)の設定を書き換えたら表示されるようになりました。 もともとjpgしかなかったところjpegを追加してます。 所感 1-2年技術から離れてから戻ってくると、その進化の速さに驚きます。 静的サイトくらいであればサーバなんて立てる必要もないし、ApacheやらNginxの設定もいらないんですね。。。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

プロキシ経由でTableau DesktopからAWS Athenaに接続する方法

環境  Tableau Desktop 2020.4.7  Windows 10 Enterprise(バージョン1909) 手順 JDBCのインストール AmazonのWEBサイトからJDBC(AthenaJDBC42.jar)をダウンロードして C:\Program Files\Tableau\Drivers に保存 プロキシ設定 以下の内容をathena.propertiesという名前で C:\Users\(ユーザ名)\Documents\マイ Tableau リポジトリ\データ ソース に保存 athena.properties ProxyHost=(プロキシURL) ProxyPort=443 UseResultSetStreaming = 0 proxyportはネットワーク環境設定によります(444やその他のポート番号の場合があります) UseResultSetStreaming = 0 は無いほうがつながる場合もあるようです。 tableauから接続  tableau起動⇒接続の「サーバーへ」 ⇒その他⇒Amazon Athena⇒以下の設定 サーバー  athena.(リージョン).amazonaws.com  例)athena.us-east-1.amazonaws.com ポート  443 S3ステージングディレクトリ  Athena → 設定の「クエリの結果の場所」を入力  例)s3://e-stat/Athena/ AccessKey / SecretKey  アクセスキーとシークレットキーをそれぞれ入力 以下のように表示されれば接続成功です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Exponential Backoffアルゴリズム

DNS サーバー、スイッチ、ロードバランサーなど、ネットワークの多数のコンポーネントが、特定のリクエストの存続期間中どこでもエラーを生成する可能性があります。 ネットワーク環境でこれらのエラー応答を処理する通常の方法は、クライアントアプリケーションで再試行するロジックを実装する。 連続したコリジョン(衝突)を避けるため、乱数によってタイミングをずらす実装がされていますが、ここではコリジョンを避ける必要があるわけではないので、乱数の実装は不要です。 可用性を高め、運用コストを削減するアプローチとしてAWS SDKには、自動再試行ロジックが実装されている。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS 代表的なサービス一覧

リンク集 AWS 代表的なサービス一覧 AWS 個別サービス詳細1 代表的なサービス一覧 サーバー関連 サービス名 概要 Amazon EC2 仮想サーバー Amazon Elastic Container Service Dockerコンテナの実行および管理 Amazon Lightsail 仮想サーバーとネットワーク一式の起動と管理 AWS Batch バッチジョブの実行 Amazon VPC ネットワーク環境 Amazon APIGateway Web APIを構築するサービス Amazon CloudFront コンテンツキャッシュサービス(CDN) Amazon Route 53 DNSサービス Amazon Direct Connect AWSネットワークに専用線で接続 AWS Transit Gateway VPC同士などを接続 Elastic Load Balancing(ELB) 負荷分散装置 Amazon Simple Email Service(SES) メールサービス Amazon GameLift ゲームホスティングサービス AWS Amplify モバイルアプリとWebアプリの構築とデプロイ メディア サービス名 概要 Amazon Elastic Transcoder メディア変換サービス AWS Elemental MediaLive ライブビデオコンテンツの変換 AWS Elemental MediaPackage 動画の配信パッケージ ストレージ サービス名 概要 Amazon Simple Storage Service(S3) 汎用的なクラウドストレージ AWS Transfer for SFTP SFTPサービス Amazon Elastic Block Store(EBS) EC2で用いるストレージ Amazon FSx for Windows ファイルサーバー Windowsファイルシステムのサービス Amazon S3 Glacier S3の長期保存サービス AWS Backup バックアップサービス データベース サービス名 概要 Amazon Aurora Amazonによってカスタマイズされた高性能なRDS Amazon DynamoDB NoSQLデータベース Amazon DocumentDB MongoDB互換のドキュメントデータベース Amazon ElastiCache インメモリキャッシュシステム Amazon RDS リレーショナルデータベース セキュリティ サービス名 概要 AWS Identity and Access Management(IAM) ユーザー機能 Amazon Congnito アプリケーション認証機能を提供するサービス Amazon GuardDuty 脅威を検出 AWS Certificate Manager 証明書を生成 AWS Firewall Manager ファイアウォールの一元管理 AWS WAF Webのファイアウォール機能 データの集計・分析 サービス名 概要 Amazon Athena S3に保存したデータの集計サービス Amazon Redshift 大量データの集計サービス Amazon Kinesis リアルタイムのビデオやデータストリームを分析 Amazon Elasticsearch Service ログやモニタリング、セキュリティなど、データ分析サービス アプリケーション連携 サービス名 概要 AWS Step Functions 順次プログラムを実行する仕組み Amazon Simple Queue Service(SQS) アプリケーション同士を連携するキューイングサービス Amazon Simple Notification Service(SNS) アプリケーション同士で通知メッセージを送信するサービス 機械学習 サービス名 概要 Amazon SageMaker 機械学習モデルの構築、トレーニング、デプロイ Amazon Lex 音声やテキストに対応するチャットボットの構築 Amazon Polly テキストを話し声に変換 Amazon Textract ドキュメントからテキストやデータを抽出 Amazon Translate 言語翻訳 Amazon Transcribe 自動音声認識 IoT サービス名 概要 AWS IoT Core IoTデバイスをクラウドに接続するための基本サービス Amazon FreeRTOS マイコン向けリアルタイムOS AWS IoTボタン クラウドでプログラミングできるダッシュボタン AWS IoT Things Graph デバイスとWebサービスを相互接続するサービス クライアント向けサービス サービス名 概要 Amazon WorkSpaces 仮想デスクトップ環境 Amazon AppStream 2.0 デスクトップアプリケーションをWebブラウザにストリーミング Amazon WorkLink 社内のWebサイトへのモバイルアクセスを可能に 開発ツール サービス名 概要 AWS Cloud9 Webブラウザで操作できる統合開発ツール AWS CodeBuild プログラムのビルドやテストツール AWS CodeCommit プライベートなGitサービス AWS CodeDeploy 開発したプログラムを配備するツール AWS CodePipeline 開発したツールをビルドして配備するまでを自動化するツール AWS CodeStar ビルドから配備までを一式提供するツール AWS コマンドラインインターフェイス コマンドでAWS を操作するツール コスト管理 サービス名 概要 AWS Cost Explorer コストと使用状況を分析 AWS Budgets 予算を設定して超えそうになったときに通知
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む