もくじ ①IAMユーザの作成+ロールの作成 ②EclipseマーケットプレイスでAWS ToolKit For Eclipseをインストール ③プロジェクトを作成してjar実行 ④おわりに ①IAMユーザの作成+ロールの作成 ロールにAmazonDynamoDBFullAccessを付けておけばいいのかなと思います。（雑な権限付与ですみません。） CSVファイル「new_user_credentials .csv」を保存しておきます。 ②EclipseマーケットプレイスでAWS ToolKit For Eclipseをインストール こちらをインストールします。 「何をインストールするか？」を聞かれるので、必要に応じて選択してインストールするといいと思います。 ここでCredential情報を聴かれるので、CSVファイル内の「アクセスキーID」と「秘密アクセスキー」を入力します。 ③プロジェクトを作成してjar実行 新規AWS Javaプロジェクトより、DynamoDBSampleを選択します。 すると以下のプロジェクトが自動生成されます。 この中のAmazonDynamoDBSample.javaを実行してみましょう。 ④おわりに 特にリージョンの記述を変更していない場合、 オレゴンのDynamoDBに"my-favorite-movies-table"という名前のテーブルが作成されます。 Javaの記述と作成されたテーブルを見比べながら、SDKの学習していくのが良いかなと思います。

はじめに 2021年の7月からAWSの勉強を始め、 CLFとSAAをそれぞれ下記の通り取得してます。 •CLF ：2021年 8月 •SAA ：2021年 11月 AWS SysOps アドミニストレーター試験は2022年の1月に受験し、725点でギリギリ合格しました。 この記事はSOA試験の備忘録となります。 目次 取り組んだこと 問題 試験ラボ 取り組んだこと 以下の勉強をしました。 ①Wizlabs（AWS Certified SysOps Administrator Associate） 海外のUdemyのようなサイトです。 すべて英語で記載されてますので、Google翻訳を用いて勉強しました。 問題は比較的基礎的な内容が多いと思ってますが、 Google翻訳を適用させると、「Auto Scalling」が「自動スケーリング」と翻訳されたり、 CloudFormationのテンプレートが部分的に翻訳された形で表示されたりするため、 元の単語等を知らないまま勉強してしまうと中途半端に翻訳されたままの単語を覚えてしまうと思います。 ハンズオンの講座もあるようですが、練習問題だけ購入してやりました。 正直練習問題と同じような問題は本番の試験では出ませんでした。 各問題を2回ずつやりそれぞれ85％以上はスコアを取れるようにしました。 WizlabsではAWS Configのアグリゲーターについての問題が多かったのですが、 本番では全く出て来ませんでした。。。 ②AWS Blacｋbelt Online Seminar 正直SysOpsの勉強では一番参考になったかなと思います。 以下のサービスの動画を見ました。 •Cloud Watch •Trusted Advisor •AWS Systems Manager (①と②があります) •Cloud Formation •EventBridge •KMS Cloud WatchはSOAを受験するなら必修の内容だと思います。 EventBridgeはCloudWatchと比較して、覚えるのが良いと思いました。 その他として、見てはいませんがVPCとCloudTrail、Config辺りは本番試験でかなり出題されました。 ③その他参考にした記事 SysOpsは参考文献が少ないような気がします。。。 以下の記事を2、3回読みました。 エラーの内容などは本番でかなり出題されたため非常に参考になりました。 【AWS認定資格】SOA-C02にアップデートされたぞぉぉぉ！！（途中なのでちょくちょく更新） AWS Certified SysOps Administrator の試験勉強して「へぇ〜」って思ったものを列挙してる記事 問題 ほとんど記憶にありませんが、勉強〜本番試験を通して合格するためにこれは覚えておいた方がいいなと思ったことを備忘録として記載します（実務で参考になるかは不明）。 ・Cloud Watch ①Cloud Watchエージェントをインストールすることで何ができるようになるのか →メモリ使用率、ディスク使用率 ②メトリクスフィルター →「Error」の文字列をロググループ、ログストリームから検索できる ③Cloud Watch Alarm →評価のルール3つを覚えておく（期間、評価の期間、アラームを実行するデータポイント） ・AutoScalling ①スケーリングのPolicy →簡易スケーリング、ステップスケーリング、ターゲット追跡スケーリング ・Trusted Advisor ①TrustedAdvisorは問題文ではほとんど出て来ないが、選択肢としてかなり出てくるため、何ができるかをよく確認しておく（基本的には使用しているリソースに対するアドバイスを提供） ・Systems Manager ①Configと組み合わせて非準拠のリソースに対して修正を実行できる（非準拠のリソースを検出するのはConfig、修正を実行するのがSystems Manager） ②それぞれの機能について何ができるか覚えておく •実行日時の定義：Change Callender •ドキュメント定義：Document Builder、SSMドキュメント（定義済） •ドキュメント実行：Automation、RunCommand •定期実行：ステートマネージャー、メンテンナンスウインドウ ・CloudFormation •Dependon属性で処理を繋げることが可能（RDSインスタンスの作成が完了してからEC2インスタンスを作成するなど） •Mapping属性でリージョンを指定可能(AMIとリージョンを指定して展開) •Deletion Policyでスタックが削除される前にリソースの保持、バックアップ その他 •インスタンスタイプの変更にまつわるELB、AutoScalling辺りの挙動 •ハードウェアモジュールを利用した暗号化にはHSM •EC2のプレイスメントグループ •Route53のルーティング •CloudFront、Route53で選択するレコード（エイリアスレコード、CNAMEレコードなどの違い） •Aurolaのバックアップ •IAMロール、バケットポリシーなどの権限管理 試験ラボ 2問出ました。 •1問目 S3のバケット作成の問題でした。 データ保存用のバケットとログ保存用のバケットを一つずつ作成し、KMSを有効化、 データバケットは365日はすぐにアクセスできるようにし、１８０日でアクセス頻度が下がり、10年で完全に削除というライフサイクルルールを設定するように指示がありました。 問題文を読みながらなんとなくで解答することができました。 ・2問目 VPCの問題でした。 CIDRが指定されたパブリックサブネットとプライベートサブネットの作成、 HTTPSのセキュリティグループの作成とVPCのトラフィックのログをS3に保存するような指示がありました。 こちらも問題文を読みながらなんとなくで解答することができました。 終わりに 結果として725点でのギリギリの合格でした。 実務でAWSを触ったことはないのですが、復習が必要だなと思いました。 試験ラボは簡単なインフラストラクチャの構成や静的なWebサイトホスティングの構築程度はしたことがあったので、 解答する際にその辺の知識が参考になったと思います。 個人的には試験ラボの対策はそこまで時間を掛けなくても良いと思いました。 （ただ私の場合選択問題は20問程度間違えていた気がするので、試験ラボでかなり助けられたと思います。。） 以上

はじめに 2021年の7月からAWSの勉強を始め、 CLFとSAAをそれぞれ下記の通り取得してます。 •CLF ：2021年 8月 •SAA ：2021年 11月 AWS SysOps アドミニストレーター試験は2022年の1月に受験し、725点でギリギリ合格しました。 この記事はSOA試験の備忘録となります。 目次 取り組んだこと 問題 試験ラボ 取り組んだこと 以下の勉強をしました。 ①Wizlabs（AWS Certified SysOps Administrator Associate） 海外のUdemyのようなサイトです。 すべて英語で記載されてますので、Google翻訳を用いて勉強しました。 問題は比較的基礎的な内容が多いと思ってますが、 Google翻訳を適用させると、「Auto Scalling」が「自動スケーリング」と翻訳されたり、 CloudFormationのテンプレートが部分的に翻訳された形で表示されたりするため、 元の単語等を知らないまま勉強してしまうと中途半端に翻訳されたままの単語を覚えてしまうと思います。 ハンズオンの講座もあるようですが、練習問題だけ購入してやりました。 正直練習問題と同じような問題は本番の試験では出ませんでした。 各問題を2回ずつやりそれぞれ85％以上はスコアを取れるようにしました。 WizlabsではAWS Configのアグリゲーターについての問題が多かったのですが、 本番では全く出て来ませんでした。。。 ②AWS Blacｋbelt Online Seminar 正直SysOpsの勉強では一番参考になったかなと思います。 以下のサービスの動画を見ました。 •Cloud Watch •Trusted Advisor •AWS Systems Manager (①と②があります) •Cloud Formation •EventBridge •KMS Cloud WatchはSOAを受験するなら必修の内容だと思います。 EventBridgeはCloudWatchと比較して、覚えるのが良いと思いました。 その他として、見てはいませんがVPCとCloudTrail、Config辺りは本番試験でかなり出題されました。 ③その他参考にした記事 SysOpsは参考文献が少ないような気がします。。。 以下の記事を2、3回読みました。 エラーの内容などは本番でかなり出題されたため非常に参考になりました。 【AWS認定資格】SOA-C02にアップデートされたぞぉぉぉ！！（途中なのでちょくちょく更新） AWS Certified SysOps Administrator の試験勉強して「へぇ〜」って思ったものを列挙してる記事 問題 ほとんど記憶にありませんが、勉強〜本番試験を通して合格するためにこれは覚えておいた方がいいなと思ったことを備忘録として記載します（実務で参考になるかは不明）。 ・Cloud Watch ①Cloud Watchエージェントをインストールすることで何ができるようになるのか →メモリ使用率、ディスク使用率 ②メトリクスフィルター →「Error」の文字列をロググループ、ログストリームから検索できる ③Cloud Watch Alarm →評価のルール3つを覚えておく（期間、評価の期間、アラームを実行するデータポイント） ・AutoScalling ①スケーリングのPolicy →簡易スケーリング、ステップスケーリング、ターゲット追跡スケーリング ・Trusted Advisor ①TrustedAdvisorは問題文ではほとんど出て来ないが、選択肢としてかなり出てくるため、何ができるかをよく確認しておく（基本的には使用しているリソースに対するアドバイスを提供） ・Systems Manager ①Configと組み合わせて非準拠のリソースに対して修正を実行できる（非準拠のリソースを検出するのはConfig、修正を実行するのがSystems Manager） ②それぞれの機能について何ができるか覚えておく •実行日時の定義：Change Callender •ドキュメント定義：Document Builder、SSMドキュメント（定義済） •ドキュメント実行：Automation、RunCommand •定期実行：ステートマネージャー、メンテンナンスウインドウ ・CloudFormation •Dependon属性で処理を繋げることが可能（RDSインスタンスの作成が完了してからEC2インスタンスを作成するなど） •Mapping属性でリージョンを指定可能(AMIとリージョンを指定して展開) •Deletion Policyでスタックが削除される前にリソースの保持、バックアップ その他 •インスタンスタイプの変更にまつわるELB、AutoScalling辺りの挙動 •ハードウェアモジュールを利用した暗号化にはHSM •EC2のプレイスメントグループ •Route53のルーティング •CloudFront、Route53で選択するレコード（エイリアスレコード、CNAMEレコードなどの違い） •Aurolaのバックアップ •IAMロール、バケットポリシーなどの権限管理 試験ラボ 2問出ました。 •1問目 S3のバケット作成の問題でした。 データ保存用のバケットとログ保存用のバケットを一つずつ作成し、KMSを有効化、 データバケットは365日はすぐにアクセスできるようにし、日でアクセス頻度が下がり、10年で完全に削除というライフサイクルルールを設定するように指示がありました。 問題文を読みながらなんとなくで解答することができました。 ・2問目 VPCの問題でした。 CIDRが指定されたパブリックサブネットとプライベートサブネットの作成、 HTTPSのセキュリティグループの作成とVPCのトラフィックのログをS3に保存するような指示がありました。 こちらも問題文を読みながらなんとなくで解答することができました。 終わりに 結果として725点でのギリギリの合格でした。 実務でAWSを触ったことはないのですが、復習が必要だなと思いました。 試験ラボは簡単なインフラストラクチャの構成や静的なWebサイトホスティングの構築程度はしたことがあったので、 解答する際にその辺の知識が参考になったと思います。 個人的には試験ラボの対策はそこまで時間を掛けなくても良いと思いました。 （ただ私の場合選択問題は20問程度間違えていた気がするので、試験ラボでかなり助けられたと思います。。） 以上

はじめに 本記事では、プライベートサブネットに置いたRDSへのAWS Systems Manager Session Maneger（以降SSM）を使ったローカルからの接続方法について、備忘録も兼ねて書いていく。 これまでは、プライベートサブネットに置いてあるRDSへ接続するには、EC2を踏み台にしてSSHポートフォワーディングを行う必要があり、そのためにはEC2をパブリックサブネットに置き、SSH用のポートも開ける必要があった。 しかし、SSMを使えば、EC2をプライベートサブネットに置き、SSH用のポートを開けることもなく、EC2にローカルから接続できるようになり、セキュリティリスクも軽減させられるようになった。 実行環境について Windowsで実行。 作成手順 RDS作成 プライベートサブネットにRDSを作成。 作成方法については本記事では省略するが、気を付けるポイントを下記に書いておく。 RDSに付与するセキュリティーグループの設定。 インバウンドルールに、EC2に付与するセキュリティーグループから5432ポートへの接続の許可を入れておくこと。 EC2作成 今回はプライベートサブネット内にEC2を作成。 EC2の作成方法については本記事では省略するが、気を付けるポイントを下記に書いておく。 キーペアは、SSHポートフォワーディング時に必要になるのでダウンロードしておくこと。 EC2に付与するIAMロールに下記のポリシーを付与しておくこと。 AmazonSSMManagedInstanceCore VPCエンドポイントの作成 プライベートサブネット内のEC2でSSMを利用するには、AWS PrivateLinkを使う必要あり。 下記3つのVPCエンドポイントを作成。 com.amazonaws.ap-northeast-1.ssm com.amazonaws.ap-northeast-1.ssmmessages com.amazonaws.ap-northeast-1.ec2messages 作成方法については、下記を参照。 https://zenn.dev/mn87/articles/31bd31c3c75f04 SSMの設定 AWS CLIをインストール。 手順は下記を参照。 https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-windows.html https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-quickstart.html Session Manager Pluginをインストール 手順は下記を参照。 https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html C:\Users\xxxxx\.ssh\configに下記内容を追記。 xxxxxはユーザー名。 configファイルがない場合は作成する。 host i-* mi-* ProxyCommand C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p" ローカルより接続 まずはSSMでプライベートサブネットに置いたEC2に接続できることを確認。 ssh -i {ダウンロードした秘密鍵のパス} ec2-user@{EC2インスタンスID} 接続できたことを確認。 SSHポートフォワーディングでトンネル開通。 秘密鍵については、置き場所次第では権限エラーが出るので注意。 Windowsの場合は、ユーザー直下に置いていたら問題なさそう。 ｛｝は除去すること。 ssh -i {ダウンロードした秘密鍵のパス} ec2-user@{EC2インスタンスID} -L {ローカルのポート}:{RDSのエンドポイント}:{RDSのポート} 無事トンネルが開通したと思われるので、SQLエディタよりRDSに接続してみる。 今回はpsqleditより接続。 USER/PASSWORD/DB NAME：RDS作成時に設定したもの。 HOST：ローカルホストである「127.0.0.1」 PORT NO：sshコマンドで設定したローカル側のポート。 無事に接続ができたことを確認。

背景 会社の上司から Step Functions の学習をお勧めされたので、学習してみる。 参考記事 下記記事を見ながら取り組んでみる。 AWS SAM とは: AWS Serverless Application Model（以下、AWS SAM）は、サーバーレスアプリケーションのデプロイに特化した、CloudFormation（以下、CFn）の拡張機能です。 準備 AWS SAM CLI をインストールする。 (ついでに、これまで作っていなかった、管理者権限を持つユーザーを作成した。) (また、シークレットアクセスキーも新調する。) しばらく Homebrew を使っていなかったので、関連プログラムの更新が走り、少し時間がかかった。 やってみる 今回はLambda Functionを呼び出す、シンプルなステートマシンを構築する。 下記のようなディレクトリ・ファイルを構成する。 . ├── functions │ └── hello_world │ ├── app.py │ └── requirements.txt ├── statemachine │ └── sfn.asl.json └── template.yaml ステートマシンから呼び出しされる、 Lambda Function のコードは下記。 functions/hello_world/app.py def lambda_handler(event, context): print("Hello world") ステートマシンのワークフローは、ASL (Amazon States Language) で定義する。 Lambda Function の指定を変数定義にすることで、 AWS SAM テンプレート内で動的に指定できるようにする。 statemachine/sfn.asl.json { "StartAt": "hello world", "States": { "hello world": { "Type": "Task", "Resource": "${LambdaFunction}", "End": true } } } AWS SAM テンプレートは下記。 template.yaml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Parameters: StateMachineName: Description: Please type the Step Functions StateMachine Name. Type: String Default: 'sfn-sam-app-statemachine' LambdaFunctionName: Description: Please type the Lambda Function Name. Type: String Default: 'sfn-sam-app-function' Resources: LambdaFunction: Type: AWS::Serverless::Function Properties: FunctionName: !Sub ${LambdaFunctionName} CodeUri: functions/hello_world/ Handler: app.lambda_handler Runtime: python3.8 Timeout: 60 Role: !GetAtt LambdaFunctionRole.Arn LambdaFunctionRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole - arn:aws:iam::aws:policy/AWSStepFunctionsReadOnlyAccess StateMachine: Type: AWS::Serverless::StateMachine Properties: Name: !Sub ${StateMachineName} DefinitionUri: statemachine/sfn.asl.json DefinitionSubstitutions: LambdaFunction: !GetAtt LambdaFunction.Arn Role: !GetAtt StateMachineRole.Arn Logging: Level: ALL IncludeExecutionData: True Destinations: - CloudWatchLogsLogGroup: LogGroupArn: !GetAtt StateMachineLogGroup.Arn StateMachineLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName : !Join [ "", [ '/aws/states/', !Sub '${StateMachineName}', '-Logs' ] ] StateMachineRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: - states.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaRole - arn:aws:iam::aws:policy/CloudWatchLogsFullAccess sam deploy でデプロイする。 オプション --guided を指定することで、 CFn スタック名など、必要なパラメータを対話形式で指定することが可能。 bash $ sam deploy --guided Configuring SAM deploy ====================== Looking for config file [samconfig.toml] : Not found Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: AWS Region [ap-northeast-1]: Parameter StateMachineName [sfn-sam-app-statemachine]: Parameter LambdaFunctionName [sfn-sam-app-function]: Parameter Resources []: #Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [y/N]: y #SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]: #Preserves the state of previously provisioned resources when an operation fails Disable rollback [y/N]: Save arguments to configuration file [Y/n]: SAM configuration file [samconfig.toml]: SAM configuration environment [default]: プロンプトに従い必要な情報を入力していくと、変更されるリソースなどが表示される。 bash Waiting for changeset to be created.. CloudFormation stack changeset --------------------------------------------------------------------------------------------------------------------------------- Operation LogicalResourceId ResourceType Replacement --------------------------------------------------------------------------------------------------------------------------------- + Add LambdaFunctionRole AWS::IAM::Role N/A + Add LambdaFunction AWS::Lambda::Function N/A + Add StateMachineLogGroup AWS::Logs::LogGroup N/A + Add StateMachineRole AWS::IAM::Role N/A + Add StateMachine AWS::StepFunctions::StateMachi N/A ne --------------------------------------------------------------------------------------------------------------------------------- Changeset created successfully. arn:aws:cloudformation:ap-northeast-1:814937260541:changeSet/samcli-deploy1641627008/63193769-38f1-432f-a09c-358fbeab285f Previewing CloudFormation changeset before deployment ====================================================== Deploy this changeset? [y/N]: y 作成されたリソースなどが表示され、しばらくするとデプロイが完了する。 bash 2022-01-08 16:30:28 - Waiting for stack create/update to complete CloudFormation events from stack operations --------------------------------------------------------------------------------------------------------------------------------- ResourceStatus ResourceType LogicalResourceId ResourceStatusReason --------------------------------------------------------------------------------------------------------------------------------- CREATE_IN_PROGRESS AWS::IAM::Role StateMachineRole Resource creation Initiated CREATE_IN_PROGRESS AWS::Logs::LogGroup StateMachineLogGroup - CREATE_IN_PROGRESS AWS::IAM::Role StateMachineRole - CREATE_IN_PROGRESS AWS::IAM::Role LambdaFunctionRole - CREATE_IN_PROGRESS AWS::IAM::Role LambdaFunctionRole Resource creation Initiated CREATE_IN_PROGRESS AWS::Logs::LogGroup StateMachineLogGroup Resource creation Initiated CREATE_COMPLETE AWS::Logs::LogGroup StateMachineLogGroup - CREATE_COMPLETE AWS::IAM::Role StateMachineRole - CREATE_COMPLETE AWS::IAM::Role LambdaFunctionRole - CREATE_IN_PROGRESS AWS::Lambda::Function LambdaFunction - CREATE_IN_PROGRESS AWS::Lambda::Function LambdaFunction Resource creation Initiated CREATE_COMPLETE AWS::Lambda::Function LambdaFunction - CREATE_IN_PROGRESS AWS::StepFunctions::StateMachi StateMachine - ne CREATE_IN_PROGRESS AWS::StepFunctions::StateMachi StateMachine Resource creation Initiated ne CREATE_COMPLETE AWS::StepFunctions::StateMachi StateMachine - ne CREATE_COMPLETE AWS::CloudFormation::Stack sam-app - --------------------------------------------------------------------------------------------------------------------------------- Successfully created/updated stack - sam-app in ap-northeast-1 デプロイが完了しているので、マネジメントコンソールからもステートマシンの作成を確認することができる。 今回の構成でワークフローを変更する際は、 sfn.asl.json を更新する。 statemachine/sfn.asl.json { "StartAt": "hello world", "States": { "hello world": { "Type": "Task", "Resource": "${LambdaFunction}", "Next": "succeed", "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Next": "fail" } ] }, "succeed": { "Type": "Succeed" }, "fail": { "Type": "Fail", "Error": "ErrorCode 100", "Cause": "There is Error." } } } 再度、デプロイを行えば環境に反映される。 bash $ sam deploy ... CloudFormation stack changeset --------------------------------------------------------------------------------------------------------------------------------- Operation LogicalResourceId ResourceType Replacement --------------------------------------------------------------------------------------------------------------------------------- * Modify StateMachine AWS::StepFunctions::StateMachi False ne --------------------------------------------------------------------------------------------------------------------------------- ... CloudFormation events from stack operations --------------------------------------------------------------------------------------------------------------------------------- ResourceStatus ResourceType LogicalResourceId ResourceStatusReason --------------------------------------------------------------------------------------------------------------------------------- UPDATE_IN_PROGRESS AWS::StepFunctions::StateMachi StateMachine - ne UPDATE_COMPLETE AWS::StepFunctions::StateMachi StateMachine - ne UPDATE_COMPLETE_CLEANUP_IN_PRO AWS::CloudFormation::Stack sam-app - GRESS UPDATE_COMPLETE AWS::CloudFormation::Stack sam-app - --------------------------------------------------------------------------------------------------------------------------------- Successfully created/updated stack - sam-app in ap-northeast-1 変更が反映されたことが確認できる。 やってみて SAM を使うと、コード上で書けば簡単に Step Functions を定義・デプロイできて、かなり便利だなと感じた。 まだ文法や書き方がよく分かっていないので、SAM と Step Functions をもう少し勉強しようと思う。

re:Invent2021で発表されたサーバレス関連サービスのアップデートをまとめてみました。 1/8 20:00 から JAWS-UG横浜 #40 AWS re:Invent 2021 Recap Serverless でこのあたりをキャッチアップしますので是非ご参加ください！ AWS Amplify Studio Amplifyの強力なバックエンドとの統合・管理機能を持ち、最小限のコーディングでUI開発を加速 Figmaで作成されたデザインを人間が読めるReactのコンポーネントコードに自動的に変換 開発者が生成されたコンポーネントをアプリのバックエンドデータに視覚的に接続可能 Amazon Redshift Serverless クラスターのセットアップや管理は不要 データのクエリやロード中など、データウェアハウスの使用中は秒単位で課金 データウェアハウスがアイドル状態の場合は課金なし 開始時に適切なコンピューティングリソースを自動的にプロビジョニングします 同時ユーザー数が増え、新しいワークロードが増えるにつれ、データウェアハウスはシームレスかつ自動的に拡張し、変化に適応します オプションで、基本データウェアハウスのサイズを指定して、コストとアプリケーション固有の SLA をさらに細かく制御可能 Amazon EMR Serverless Apache Spark、Apache Hive、Presto などのオープンソース分析フレームワークを使用して構築されたアプリケーションを数回のクリックだけで実行 クラスターを構成、最適化、または保護する必要なし アプリケーションに必要なコンピューティングリソースとメモリリソースを自動的にプロビジョニングしてスケーリング 使用したリソースに対してのみ課金 Amazon MSK Serverless コンピューティングリソースとストレージリソースを自動的にプロビジョニングおよびスケーリング AWS PrivateLink とのプライベート接続 AWS Identity and Access Management (IAM) による安全なクライアントアクセス AWS Glue Schema Registry によるスキーマ進化制御 クラスターごとに 1 時間あたりの料金を支払い 作成するパーティションごとに 1 時間あたりの料金を支払い データスループットとストレージの GB ごとに支払い Amazon Kinesis Data Streams On-Demand ストリーミングデータ用のキャパシティーのプロビジョニングと管理が不要 データトラフィックの変化に応じてキャパシティーが自動的にスケーリング ストリームへの書き込み、読み取り、保存を行うデータの 1 ギガバイトあたりの料金は、スループットごとに課金 AWS Lambda support for Event Filtering for SQS, DynamoDB & Kinesis Lambda 関数へのトラフィックを減らし、コードを簡素化し、全体的なコストを削減 最大 5 つのフィルター条件を指定することが可能 Amazon SQS が標準キューのデッドレターキュー管理エクスペリエンスを強化 デッドレターキュー (DLQ) のソースキューへのリドライブをサポート Amazon EventBridgeでAmazon S3のイベント通知が利用可能に 高度なフィルタリング 複数の送信先 高速で信頼性の高い呼び出し

やりたいこと Railsでフランス語のWebアプリを個人開発してます。 developmentではS3で画像を保存していたのですが、本番デプロイするにあたり、Lightsailでアプリを運用することにしたのでLightsailのオブジェクトストレージを使うことにしました。 12ヶ月無料だって。やったー！ 元々のS3での実装がどうなってたのか、記憶から消えていたのでこの辺を読んで復習するところから始まりました。 関連する該当箇所は以下な感じです。 Gemfile gem 'image_processing', '~> 1.2' user.rb has_one_attached :image users_controller.rb def users_params params.require(:user).permit(:account_name, :image) end config/storage.yml amazon: service: S3 access_key_id: <%= Rails.application.credentials.dig(:aws, :access_key_id) %> secret_access_key: <%= Rails.application.credentials.dig(:aws, :secret_access_key) %> region: ap-northeast-1 bucket: MY_BUCKET_NAME どこかでS3クライアント作ったり、PutObjectとかしているのかと思ったらやってなくてgemがいい感じにしてくれているみたい...。今回大事なのはconfig/storage.ymlで、というかだけで、AdministratorAccessのあるIAMユーザーのアクセスキーを渡していました。 Lightsailのオブジェクトストレージも結局実態はS3ではあるのだろうけど、どうやってやるのだろう...。 実装！ 結論 いっろいろ遠回りしたけど、結論はバケットのアクセスキーみたいです。 ホーム => ストレージ => 該当のバケット選択 => アクセス権限 => アクセスキー ここでアクセスキーを作成して、アクセスキーIDとシークレットアクセスキーを取得し、今まで環境変数なり、credentialsなりで、IAMのaccess_key_idとsecret_access_keyをセットしていたところを置き換えます。 これだけです。 一応ドキュメントはこれになるぽいです。操作は簡単なので、これ見なくてもできますが。 https://lightsail.aws.amazon.com/ls/docs/ja_jp/articles/amazon-lightsail-creating-bucket-access-keys 以上で終了ですが、参考までに以下に空振りしたものも書いておきます。 空振り１：アカウントのAPIアクセスキー 当初こうやって怒られていました。 Aws::S3::Errors::SignatureDoesNotMatch at / The request signature we calculated does not match the signature you provided. Check your key and signing method. そういえば、Lightsailをいじり始めた当初からLightsailと他のAWSサービスって画面が違うし、IAMとかどうなるんだろう？と疑問に思っていたのですよね。Lightsailコンソールをいじってみると。 右上にアカウントというメニューがある。 自分がAWSで作ったIAMユーザーになってる。（ここではadminという名前のIAMユーザーを使っている） お、APIアクセスキー。 このドキュメントで、ここに答えがあるかもと思ひつるを。 https://lightsail.aws.amazon.com/ls/docs/en_us/articles/lightsail-how-to-set-up-access-keys-to-use-sdk-api-cli Choose the name of the user for which you want to create an access key. The user you choose should have full access or specific access to Lightsail actions. IAMユーザーはフルアクセスかLightsailのactionsに対するアクセス権限を持ってないとダメと書いてありますが、このLightsailに使われているIAMユーザーはAdministratorAccessでProvides full access to AWS services and resources.だから既に"full access"ある...うーん。 試しに新規でIAMユーザーを作って、明確にLightsailを許可するポリシーをアタッチしてそのアクセスキーをセットしてみる。 （既存のポリシーにLightsailはないのでポリシーの作成ボタンから作る。） （作ったIAMのapi_access_key, secret_access_keyをcredentialsにセットする。） これをやってRailsサーバーを再起動して動作確認してみると、下記の通り違うエラーになりました。 Aws::S3::Errors::AccessDenied Access Denied 今度はバケットに拒否されている模様。 空振り２：バケットのアクセス権限 デフォルトのすべてのオブジェクトはプライベートです => すべてのオブジェクトはパブリックで読み取り専用ですと変更してみる。 ダメ。 ちなみに一番最初のうまくいった例では、ここをすべてのオブジェクトはプライベートですに戻してもきちんと動作しました。 最後に なんか的外れなこと書いてたら教えてください〜?

はじめに FargateでwordPressの本番環境を構築後、開発環境を作成する上で、Cl/CD構成について試行錯誤したため、まとめます。 FargateでWordPressの構築方法 こちらの記事を順番どおり行うと、本番環境として構築できます。 本番と開発環境のCI/CDの構成の要件 アプリケーションの品質を担保する観点から、開発環境でビルド・デプロイテストを行い、問題ないことを確認して、本番環境にデプロイしたい →そのために、各環境にCodePipelineを構築する 　　 開発効率の点から本番と開発環境のソースコードは同じにしたい →そのためには、CodeBuildの環境変数や、ECSのタスク定義の環境変数で、環境ごとの差異を修正する Fargateの本番と開発環境のCI/CDの構成図 開発のCI/CD流れ 開発ブランチ(develop)の ソースコードを修正し、CodeCommitにプッシュすると、開発環境用のCodePipelineが起動します。 developのbuildspec.ymlファイルのコードを元に、CodeBuildでDockerイメージを作成します。 CodeDeploy(ECSタイプ)で、タスク定義の環境変数に開発用のRDSエンドポイントを指定し、タスクをデプロイする 本番のCI/CD流れ デプロイされた開発環境のアプリケーションを確認し、問題ないことを確認する CodeCommitのdevelopブランチからmainにマージすると、本番用のCodePipelineが起動します。 buildspec.ymlファイルが同じため、開発環境と同じイメージをECRに保存する。 CodeDeploy(ECSタイプ)で、タスク定義の環境変数に本番用のRDSエンドポイントを指定し、タスクをデプロイする 本番と開発環境の差異 CodeCommitの開発と本番環境は、同じリポジトリですが、開発と本番でブランチでわけています。（CodeCommitでなく、GitHubでも可） buildspec.ymlファイルも共通で、同じイメージをECRから取得します。 CodeBuild、CodeDeploy、RDSは、各環境ごとに作成します。 ECSのクラスターは、各環境ごとに作成します ALBとターゲットグループは、各環境ごとに作成します。本番と開発で同じALBを使用することはできませんでした。 作業の流れ 資産を本番と開発環境で同じにする 開発環境用のcodebuildとcodepipelineとcodeDeploy(ECS)を作成 資産を本番と開発環境で同じにする 本番環境は、先程記載した記事通りにすると作成できます。 開発環境のソースコードは、本番環境のソースコードと差異がないようにする必要があります。 私の場合、WordPressだと以下のファイルを修正しました。 dockercompose.yml 修正前 dockercompose.yml version: '3' services: wordpress: build: . # カレントディレクトリのDockerfileでイメージをビルド image: wordpress # イメージ名はwordpressとする ports: - '80:80' # port80でコンテナのport80にアクセスできるようにする environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_NAME: wordpress WORDPRESS_DB_USER: wp_user WORDPRESS_DB_PASSWORD: wp_pass volumes: - wordpress:/var/www/html/ 修正後 dockercompose.yml version: '3' services: wordpress: build: . # カレントディレクトリのDockerfileでイメージをビルド image: wordpress # イメージ名はwordpressとする ports: - '80:80' # port80でコンテナのport80にアクセスできるようにする ECSのタスク定義の環境変数に記載すれば、dockercompose.ymlに書く必要はないですね。 もちろんブランチにdevelopを作成することも忘れずに。 資産 FargateでWordPressを構築する際のソースコードは、こちらです。 . ├── Dockerfile ├── buildspec.yml ├── docker-compose.yml ├── html ├── php.ini │   ├── wp-config.php │   └── wp-content │   ├── plugins │   └── themes └── imagedefinitions.json 特に指定がなければ、コンテナ内の/var/www/html配下に設置されます。 詳細は、Dockerfile,docker-compose.ymlに記載 リポジトリとコンテナ内のディレクトリ構造 html /var/www/html php.ini /usr/local/etc/php/php.ini CodeBuildで必要なファイル buildspec.yml imagedefinitions.json Dockerで必要なファイル Dockerfile docker-compose.yml 開発環境用のcodebuildとcodepipelineとcodeDeploy(ECS)を作成 参考記事通りに作成します。 ECS作成時、注意点① Deploy時、本番環境と同じイメージを取得するため、タスク定義は、同じにします。 ECS作成時、注意点② ECSのクラスターは、各環境ごとに作成します。 ECS作成時、注意点③ ECSサービスは、新規でロードバランサーとターゲットグループを作成します。 本番と開発環境で同じロードバランサーは、使用できませんでした。 作成後、検証環境にpushすると、検証環境としてデプロイされます。 developブランチをmainにマージすると、本番環境としてデプロイされます！

今回はさくっとAWS EC2でFTPサーバお試し構築してみます。EC2は同一サブネットに２つデプロイして、１つをFTPサーバ、もう１つをクライアントとして設定し、FTPでファイル送受信を行う設定になります。 前提 利用するインスタンスはFTPサーバはAmazon Linux2で、クライアント側はWindows Serverとし、FTPソフトウェアはWinSCPとする コマンド操作はRoot権限のあるユーザで実施する 構築手順 ①EC2をサーバ、クライアント用でそれぞれデプロイ ②サーバ側にvsftpdをインストールして、FTPユーザを作成 ③vsftpdの設定ファイルをデフォルトから変更 ④クライアント側でWinSCPをインストールし、接続 実際にやってみた まず①についてはほ他に詳しい記事がたくさんあるので割愛します。EC2をデプロイしてRoot権限のユーザに昇格したものとして以下進めます。 次の②のvfstpdのインストールですが以下でインストールします。 #サーバ側にvsftpdをインストール yum -y install vsftpd    #vsftpdサービス起動および自動起動されるように設定 systemctl start vsftpd systemctl enable vsftpd   これでとりあえず、サーバ側で必要なパッケージは準備ＯＫです。 クライアント用のEC2も同じVPCにデプロイして、RDPできるところまで進めます 続いて③ですがvsftpdの設定コンフィグである/etc/vsftpd/vsftpd.confの中身をデフォルトから変更していきます。 ※別にデフォルトのままでもFTP接続することは可能です。 #/etc/vsftpd/vsftpd.confを修正 vi /etc/vsftpd/vsftpd.conf ~~~以下抜粋~~~~ 1 # Example config file /etc/vsftpd/vsftpd.conf 2 # 3 # The default compiled in settings are fairly paranoid. This sample file 4 # loosens things up a bit, to make the ftp daemon more usable. 5 # Please see vsftpd.conf.5 for all compiled in defaults. 6 # 7 # READ THIS: This example file is NOT an exhaustive list of vsftpd options. 8 # Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's 9 # capabilities. 10 # 11 # Allow anonymous FTP? (Beware - allowed by default if you comment this out). 12 anonymous_enable=YES　　→「No」に変更 13 # 14 # Uncomment this to allow local users to log in. 15 # When SELinux is enforcing check for SE bool ftp_home_dir 16 local_enable=YES 12行目:anonymous_enable=YESは不特定ユーザのアクセス許可はセキュリティ上、よろしくないので「No」にします。 16行目:local_enable=Yesはローカルユーザ（/etc/passwdに記述されたユーザー）のアクセス許可なので「YES」のままでOKです。 112 # When "listen" directive is enabled, vsftpd runs in standalone mode and 113 # listens on IPv4 sockets. This directive cannot be used in conjunction 114 # with the listen_ipv6 directive. 115 listen=NO 116 # 117 # This directive enables listening on IPv6 sockets. By default, listening 118 # on the IPv6 "any" address (::) will accept connections from both IPv6 119 # and IPv4 clients. It is not necessary to listen on *both* IPv4 and IPv6 120 # sockets. If you want that (perhaps because you want to listen on specific 121 # addresses) then you must run two copies of vsftpd with two configuration 122 # files. 123 # Make sure, that one of the listen options is commented !! 124 listen_ipv6=No 125 126 pam_service_name=vsftpd 127 userlist_enable=YES　→「YES」だと userlist_file に記載しているユーザは接続拒否されるので「No」に変更 128 tcp_wrappers=YES 115行目:listen=スタンドアロンでvsftpdを起動するかの設定で、デフォルトが[NO]なのでそのままでOKです。 124行目:listen_ipv6=IPv4ソケットの代わりにIPv6ソケットをリッスンする。 このオプションとlistenオプションは、同時に有効にすることができないがこれも「NO」でOKです。 127行目:userlist_enable=userlist_fileオプション（デフォルトは/etc/vsftpd.user_listファイル）で指定したファイルに含まれるユーザリストを元に、ログインの許可/拒否が決定されます。[YES]にすると/etc/vsftpd.user_listがブラックリストになり、ユーザを追記するとアクセス拒否されてしまうので、今回は[NO]に変更しておきます。 「userlist_enable=YES」のままでも、下に「userlist_deny=NO」を記述すれば同じ設定にできますので、そっちの方がわかりやすいかもしれませんね。 FTPにはアクティブモードとパッシブモードがありますが、デフォルトだと「パッシブモード」で設定されます。 明示的に記載する場合は「pasv_enable=YES」とします。 とりあえず最低限の変更は以上です。 次にFTPでアクセスするユーザをサーバ側で作成します。 #ftpで利用するユーザを作成 useradd ftp-user passwd ftp-user New-Passwd:任意のパスワード 続いて、etc/vsftpd.user_listに先ほど作成したユーザを追記してやります。 vi etc/vsftpd.user_list ~~以下を追記~~ ftp-user またリストに既に記載されているユーザでもFTPサーバにアクセスできてしまうので、不要であれば削除しておきましょう。 最後に設定反映のためにvsftpdをサービス再起動させましょう。 systemctl restart vsftpd これでサーバ側の設定は完了です。 では④のクライアント側の設定に移ります。とっいてもEC2のログインして、WinSCPをインストールするだけなので手順は簡略化します。 とりあえず窓の杜からインストールしておけばOKです。 クライアントのEC2でWinSCPを起動させると以下のような画面になるので、「ホスト名」にサーバのＩＰアドレスを、ユーザ名のところに「ftp-user」と設定したPWを入力します。 こんな感じで接続できています！ 参考にしたサイト 【AWS】閉域網のEC2にFTPサーバーを構築 【CentOS7】vsftpdでパッシブモードのFTPサーバーを設定する

はじめに CloudFormationで作成したスタック内のリソースを直接設定変更すると、テンプレートで定義された設定内容と実際のリソースの設定内容に差分(以下、「ドリフト」と記述)が生じます。 ドリフトが発生することにより、スタックの更新や削除の際に問題が生じる可能性があります。 今回は「ドリフト検出」の機能を使用して、発生したドリフトの内容の確認やドリフトの解消を実施してみたいと思います。 また、定期的なドリフト検出とSlackへの通知も併せて構成していきます。 構成図 定期的なドリフト検出とSlackへの通知のためにCloudFormation以外に以下のサービスを使用します。 ※ドリフト検出を実行するのみであれば不要です。 AWS Config Amazon EventBridge Amazon SNS AWS Chatbot CloudFormation スタック作成 スタック構成図 以下のような構成でCloudFormationスタックを作成します。 テンプレート テンプレートの内容は以下となります。 drift-detection-test.yml AWSTemplateFormatVersion: 2010-09-09 Description: CloudFormation drift detection test Parameters: VpcName: Type: String Description: VPC name Default: "testVPC" VpcCidrBlock: Type: String Description: VPC CIDR block Default: "10.0.0.0/16" IgwName: Type: String Description: Internet gateway name Default: "testIGW" SubnetName: Type: String Description: Subnet name Default: "testSubnet" SubnetCidrBlock: Type: String Description: Subnet CIDR block Default: "10.0.0.0/24" PublicRouteTableName: Type: String Description: Public route table name Default: "public-rt" SecurityGroupName: Type: String Description: Security group name Default: "testSG" SSHAccessIp: Type: String Description: Source IP address of SSH access Default: "0.0.0.0/0" InstanceName: Type: String Description: EC2 instance name Default: "testEC2" KeyName: Type: String Description: Key pair name Default: "cloudtech-keypair" ImageId: Type: String Description: Image ID of EC2 instance Default: "ami-0404778e217f54308" BucketName: Type: String Description: S3 bucket name Default: "drift-detection-test01" Resources: testVPC: Type: AWS::EC2::VPC Properties: CidrBlock: !Ref VpcCidrBlock EnableDnsSupport: true Tags: - Key: Name Value: !Ref VpcName testIGW: Type: AWS::EC2::InternetGateway Properties: Tags: - Key: Name Value: !Ref IgwName AttachGateway: Type: AWS::EC2::VPCGatewayAttachment Properties: VpcId: !Ref testVPC InternetGatewayId: !Ref testIGW testSubnet: Type: AWS::EC2::Subnet Properties: AvailabilityZone: !Sub ${AWS::Region}a VpcId: !Ref testVPC CidrBlock: !Ref SubnetCidrBlock Tags: - Key: Name Value: !Ref SubnetName publicRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref testVPC Tags: - Key: Name Value: !Ref PublicRouteTableName publicRoute: Type: AWS::EC2::Route Properties: RouteTableId: !Ref publicRouteTable DestinationCidrBlock: "0.0.0.0/0" GatewayId: !Ref testIGW publicRouteTableAssoc: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref testSubnet RouteTableId: !Ref publicRouteTable testSG: Type: AWS::EC2::SecurityGroup Properties: GroupName: !Ref SecurityGroupName GroupDescription: !Ref SecurityGroupName VpcId: !Ref testVPC SecurityGroupIngress: - IpProtocol: "tcp" FromPort: 22 ToPort: 22 CidrIp: !Ref SSHAccessIp Tags: - Key: Name Value: !Ref SecurityGroupName testEC2: Type: AWS::EC2::Instance Properties: KeyName: !Ref KeyName ImageId: !Ref ImageId InstanceType: "t2.micro" NetworkInterfaces: - AssociatePublicIpAddress: true DeviceIndex: "0" SubnetId: !Ref testSubnet GroupSet: - !Ref testSG Tags: - Key: Name Value: !Ref InstanceName s3Bucket: Type: AWS::S3::Bucket Properties: BucketName: !Ref BucketName AccessControl: Private PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true VersioningConfiguration: Status: "Suspended" Tags: - Key: Name Value: !Ref BucketName ドリフト検出 まずはリソースの設定変更を実施する前に現状ドリフトが発生していないことを確認します。 CloudFormationのスタック一覧画面で対象スタックを選択し、[スタックアクション]-[ドリフトの検出]をクリックします。 ドリフトの検出実行後、再度対象スタックを選択し、[スタックアクション]-[ドリフト結果を表示]をクリックします。 ドリフトステータスが「IN_SYNC」になっていればスタック内のリソースにドリフトが発生していない状態となります。 スタック内のリソース設定変更 作成したスタック内のEC2インスタンス, S3バケットに対して以下の変更を加えます。 EC2インスタンス インスタンスタイプを「t2.micro」から「t2.small」に変更 S3バケット バケットを削除 上記設定変更後、再度ドリフト検出を実施してみます。 ドリフトステータスが「DRIFTED」となり、スタック内のリソースにドリフトが発生している状態となります。 また、リソースのドリフトステータスでリソースごとのドリフト発生状況を確認すると、EC2インスタンスは「MODIFIED」、S3バケットは「DELETED」とステータスが変更されていることが確認できます。 リソースごとにどのようなドリフトが発生しているのか確認してみます。 EC2インスタンスを選択し、[ドリフトの詳細を表示]をクリックします。 違い内にドリフトが発生している項目の一覧、詳細内にスタックを作成・更新した際に使用したテンプレートの内容(予定)と現在の実際の設定(現在)が表示されます。 違い内のドリフト発生項目にチェックを入れると、詳細内でどのようなドリフトが発生しているかが色付けされ確認することができます。 今回の場合はインスタンスタイプが「t2.micro」から「t2.small」に変更されたことが確認できます。 ドリフト解消 ドリフトを解消するためには以下の3つの方法があります。 直接変更したリソースの設定を元に戻す 直接変更したリソースの設定をテンプレートに反映させ、スタックを更新する リソースをスタックから取り除き、インポートし直す 方法1：直接変更したリソースの設定を元に戻す 直接変更した設定を元の設定に戻します。 EC2インスタンスは停止後にインスタンスタイプを「t2.micro」に戻し、S3バケットは同じ設定で再作成します。 上記作業実施後にドリフト検出を実行してみると、ドリフトが解消されていることを確認できます。 S3バケットについてはCloudFormationで付与されたタグが付いていない状態ではありますが、ドラフトがない状態として認識されています。 方法2：直接変更したリソースの設定をテンプレートに反映させ、スタックを更新する 直接変更した設定内容をテンプレートに反映させます。 ただし、S3バケットに関しては削除されているだけで設定内容自体に変更はありません。 今回はEC2インスタンスの設定内容に変更があるため発生しない想定ですが、テンプレートの内容を変更しないままスタックを更新すると以下のエラーが発生します。 そのため、EC2インスタンスについてはインスタンスタイプの設定値を修正し、S3バケットの記述についてはいったんコメントアウトをします。 テンプレートの修正ができたら、スタックを更新します。 drift-detection-test.yml testEC2: Type: AWS::EC2::Instance Properties: KeyName: !Ref KeyName ImageId: !Ref ImageId InstanceType: "t2.small" NetworkInterfaces: - AssociatePublicIpAddress: true DeviceIndex: "0" SubnetId: !Ref testSubnet GroupSet: - !Ref testSG Tags: - Key: Name Value: !Ref InstanceName # s3Bucket:　 # Type: AWS::S3::Bucket # Properties: # BucketName: !Ref BucketName # AccessControl: Private # PublicAccessBlockConfiguration: # BlockPublicAcls: true # BlockPublicPolicy: true # IgnorePublicAcls: true # RestrictPublicBuckets: true # VersioningConfiguration: # Status: "Suspended" # Tags: # - Key: Name # Value: !Ref BucketName スタック更新時にEC2インスタンスが再起動されます。 インスタンスタイプはすでに「t2.small」となっていますが、本来インスタンスタイプの変更にはインスタンスの停止が必要となるため再起動が発生するものと思われます。 スタック更新が完了すると、EC2インスタンスについてのドリフトが解消されていることが確認できます。 S3バケットについてはテンプレートでコメントアウトされているので、そもそもスタックに存在しないリソースという扱いとなります。 S3バケットを再度スタック内に作成するためには、テンプレートでのコメントアウトを解除し、スタックを更新します。 drift-detection-test.yml s3Bucket: Type: AWS::S3::Bucket Properties: BucketName: !Ref BucketName AccessControl: Private PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true VersioningConfiguration: Status: "Suspended" Tags: - Key: Name Value: !Ref BucketName これでEC2インスタンス、S3バケットともにドリフトが解消された状態となります。 EC2インスタンスの設定は新しい設定となり、S3バケットは同名ではありますが別バケットとなります。 方法3：リソースをスタックから取り除き、インポートし直す スタックを更新する際にリソースの再作成が発生する場合には方法3を用いて、既に作成されているリソースを保持したままドリフトを解消することができます。 方法2でEC2インスタンスのドラフトを解消する際には再起動が発生してしまいましたが、方法3で対応することで再起動を発生させずドラフトを解消することができます。 S3バケットについては方法2を使用して再作成を行っていきます。 テンプレート内のEC2インスタンスの記述にDeletionPolicy属性を追加し、スタックを更新します。 DeletionPolicy属性を「Retain」とすることでスタック削除時にリソースが保持されるようになります。 S3バケットはコメントアウトします。 drift-detection-test.yml testEC2: Type: AWS::EC2::Instance DeletionPolicy: Retain Properties: KeyName: !Ref KeyName ImageId: !Ref ImageId InstanceType: "t2.micro" NetworkInterfaces: - AssociatePublicIpAddress: true DeviceIndex: "0" SubnetId: !Ref testSubnet GroupSet: - !Ref testSG Tags: - Key: Name Value: !Ref InstanceName # s3Bucket:　 # Type: AWS::S3::Bucket # Properties: # BucketName: !Ref BucketName # AccessControl: Private # PublicAccessBlockConfiguration: # BlockPublicAcls: true # BlockPublicPolicy: true # IgnorePublicAcls: true # RestrictPublicBuckets: true # VersioningConfiguration: # Status: "Suspended" # Tags: # - Key: Name # Value: !Ref BucketName これでEC2インスタンスについては削除時にリソースが保持される状態となりました。 次にテンプレート内のEC2インスタンスをコメントアウトし、S3バケットのコメントアウトを解除した状態でスタックを更新します。 drift-detection-test.yml # testEC2: # Type: AWS::EC2::Instance # DeletionPolicy: Retain # Properties: # KeyName: !Ref KeyName # ImageId: !Ref ImageId # InstanceType: "t2.micro" # NetworkInterfaces: # - AssociatePublicIpAddress: true # DeviceIndex: "0" # SubnetId: !Ref testSubnet # GroupSet: # - !Ref testSG # Tags: # - Key: Name # Value: !Ref InstanceName s3Bucket:　 Type: AWS::S3::Bucket Properties: BucketName: !Ref BucketName AccessControl: Private PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true VersioningConfiguration: Status: "Suspended" Tags: - Key: Name Value: !Ref BucketName コメントアウトしたEC2インスタンスはスタックには存在しない状態となりますが、更新前に作成されていたEC2インスタンスは保持されます。 S3バケットについては新規作成されます。 スタック詳細画面で[リソース]タブを選択し、「AWS::EC2::Instance」「AWS::S3::Bucket」でそれぞれ検索し、EC2インスタンスはスタックに存在しないこと、S3バケットは新規作成されていることを確認します。 スタックからEC2インスタンスが除外されたことを確認後、テンプレート内のコメントアウトを解除し、設定値を現在のEC2インスタンスの設定値に変更します。 drift-detection-test.yml testEC2: Type: AWS::EC2::Instance DeletionPolicy: Retain Properties: KeyName: !Ref KeyName ImageId: !Ref ImageId InstanceType: "t2.small" NetworkInterfaces: - AssociatePublicIpAddress: true DeviceIndex: "0" SubnetId: !Ref testSubnet GroupSet: - !Ref testSG Tags: - Key: Name Value: !Ref InstanceName 上記テンプレート修正が完了したら、リソースのインポートを実施します。 スタック一覧画面で対象スタックを選択し、[スタックアクション]-[スタックへのリソースのインポート]をクリックします。 [次へ]をクリックします。 テンプレートを指定し、[次へ]をクリックします。 識別子の値にインポートするリソースについての値を入力します。 EC2インスタンスの場合はインスタンスIDを入力します。 入力できたら、[次へ]をクリックします。 パラメータを確認し、[次へ]をクリックします。 設定の概要を確認し、[リソースをインポート]をクリックします。 リソースのインポートが完了したら、ドリフト検出を実行し、ドリフトステータスが「IN_SYNC」になっていることを確認します。 EC2インスタンスの設定は新しい設定となり、S3バケットは同名ではありますが別バケットとなります。 ドリフト検出の定期実行 AWS Configにてドリフトを定期的に検出し、ドリフトが発生してるかどうかを判断するためのルールを作成します。 まずはルール作成時に必要となるIAMロールを先に作成しておきます。 IAMロールの作成 CloudFormationスタックのドリフト検出を実行できる権限を持つIAMロールを作成します。 信頼関係やポリシーについては以下の記事を参考にして作成しました。 Configルールを作成する際にはIAMロールのロールARNを指定することになるので、ロールARNを控えておきます。 Configルールの作成 Config管理画面でルール一覧を開き、[ルールを追加]をクリックします。 AWS マネージド型ルールの検索窓に「cloudformation」と入力し検索をかけます。 [cloudformation-stack-drift-detection-check]を選択し、[次へ]をクリックします。 今回は頻度を「1時間」に設定します。 パラメータ内のキー[cloudformationRoleArn]の値として、事前に作成したIAMロールのARNを入力し、[次へ]をクリックします。 確認画面で設定を確認し、[ルールを追加]をクリックします。 ルール一覧画面で作成されたルール名をクリックし、ルール詳細画面を開きます。 対象範囲内のリソースで「すべて」を選択し、CloudFormationスタックのドリフトステータス評価状況を確認します。 コンプライアンスが「準拠」となっていれば、ドリフトは発生していない状態となります。 通知設定 SNSトピックの作成 通知を構成するためにまずはSNSトピックを作成していきます。 SNS管理画面で[トピック]を選択し、[トピックを作成]をクリックします。 設定値を入力し、[トピックの作成]をクリックします。 今回は以下の設定値を使用します。 ※以下に記載のない設定値はデフォルトとします。 項目名 設定値 タイプ スタンダード 名前 drift-detection-topic 通知用Slackチャンネルの作成 Slackで通知を受け取るチャンネルをあらかじめ作成しておきます。 チャンネルはパブリック、プライベートのいずれでもOKですが、今回はプライベートチャンネルを作成して通知を構成します。 プライベートの場合、あらかじめAWS Chatbotの招待するためのコマンドをSlackで実行しておく必要があります。 If you configure a private Slack channel, run the /invite @AWS command in Slack to invite the AWS Chatbot to the chat room. 作成したプライベートチャンネル内で/invite @AWSと入力し、実行します。 また、Chatbotチャネル作成時にプライベートチャンネルのIDが必要になりますので控えておきます。 Chatbot用IAMロール・ポリシーの作成 Chatbotチャネルを作成するにあたり、Chatbotチャネルに割り当てるIAMロールとチャネルのメンバーが実行可能なアクションを制御する「Channelガードレール」に使用するポリシーを指定する必要があります。 Chatbotチャネル作成ウィザード内で新たにIAMロール・ポリシーを作成することもできますが、今回はChatbotチャネルに割り当てるIAMロールにアタッチするポリシーをChannelガードレールにも設定したいと思いますのでウィザードのデフォルト設定で作成されるIAMロール・ポリシーの設定値に合わせて事前に作成します。 ポリシーは以下の設定で作成します。 項目名 設定値 名前 AWS-Chatbot-NotificationsOnly-Policy AWS-Chatbot-NotificationsOnly-Policy { "Version": "2012-10-17", "Statement": [ { "Action": [ "cloudwatch:Describe*", "cloudwatch:Get*", "cloudwatch:List*" ], "Effect": "Allow", "Resource": "*" } ] } また、IAMロールは以下の設定で作成します。 項目名 設定値 名前 AWSChatbot-role ポリシー AWS-Chatbot-NotificationsOnly-Policy 信頼されたエンティティ chatbot.amazonaws.com Chatbotチャネルの作成 作成したSlackチャンネルへの通知を構成するためにChatbotチャネルを作成します。 Chatbot管理画面でチャットクライアントで[Slack]を選択し、[クライアントを設定]をクリックします。 Slackワークスペースへのサインイン画面にリダイレクトされます。 ワークスペースのURLを入力し、[続行する]をクリックします。 資格情報を入力し、[サインイン]をクリックします。 AWS ChatbotからSlackワークスペースへのアクセス権限リクエストが表示されるので、[許可する]をクリックします。 Management Console画面に戻ったら、[新しいチャネルを設定]をクリックします。 設定値を入力し、[設定]をクリックします。 今回は以下の設定値を使用します。 ※以下に記載のない設定値はデフォルトとします。 項目名 設定値 設定名 drift-detection-channel チャネルタイプ プライベート チャネル ID 通知に使用するチャネルのID ロール設定 チャネル IAM ロール チャネル IAM ロール 既存の IAM ロールを使用する ロール名 AWSChatbot-role Channel ガードレール AWS-Chatbot-NotificationsOnly-Policy トピック drift-detection-topic Slack通知のテストを行います。 作成されたチャネルを選択し、[テストメッセージを送信]をクリックします。 Slackの通知用チャンネルでテストメッセージを受信していることを確認します。 また、事前に作成していたSNSトピックにサブスクリプション設定が自動的に追加されていることを確認します。 EventBridgeルールの作成 ConfigによるCloudFormationスタックのドリフトの定期検出、SNS・ChatbotによるSlackへの通知をそれぞれ構成してきました。 その2つをEventBridgeを使用して紐づけることで、ドリフト検出時のSlack通知を構成していきます。 以下を参考に設定していきます。 EventBridge管理画面で[ルール]を選択し、[ルールを作成]をクリックします。 名前に任意のルール名を入力します。 パターンを定義ブロックで[イベントパターン]を選択肢、イベント一致パターンで[カスタムパターン]を選択します。 イベントパターンに以下を入力し、[保存]をクリック イベントパターン { "source": [ "aws.config" ], "detail-type": [ "Config Rules Compliance Change" ], "detail": { "messageType": [ "ComplianceChangeNotification" ], "configRuleName": [ "cloudformation-stack-drift-detection-check" ], "resourceType": [ "AWS::CloudFormation::Stack" ], "newEvaluationResult": { "complianceType": [ "NON_COMPLIANT" ] } } } ターゲットを選択ブロックでターゲットに[SNS トピック]を選択し、トピックで[drift-detection-topic]を選択後、[作成]をクリックします。 動作確認 Slack通知の動作確認をするためにドリフトを発生させてみましょう。 EC2インスタンスのインスタンスタイプを変更します。 今回Configルールを設定するにあたって、頻度を「1時間」としましたのでConfigルールが最後に評価を実行した時刻から1時間後に以下の流れでSlackに通知されます。 ※すぐに動作確認したい場合は評価を手動で実行することも可能です。 Configルールによる評価が実行される CloudFormationスタックのコンプライアンスが「非準拠」に変更される EventBridgeルールによってCloudFormationスタックのコンプライアンスが「非準拠」になったイベントをきっかけにSNSトピックにメッセージが発行される SNSトピックのサブスクリプションであるChatbotがメッセージを受信 ChatbotがSlackチャンネルへのメッセージ送信を実行 無事1時間後にスタックのコンプライアンスが非準拠であることがSlackに通知されました。 あとがき この記事は AWS CloudTech の課題として作成しました。 動画やハンズオン等で学習を進めることができるので、AWS初学者にはおすすめです。

最初に この記事はAWS認定試験を目指す学生のノートの１ページです。 間違いや言葉の言い回しが多少異なることがあります。ご了承ください AWSとは AWS(Amazon Web Services)とはAmazon社が提供している 従量課金制（使用した分しか取らない）Webサービスです。 またAWSでは様々なビジネスの場面で使えるようにたくさんの製品が用意されているのも一つの特徴です。 クラウドコンピューティングの利点 クラウドコンピューティングの利点は大きく分けて６つあります ・先行支出を変動支出に切り替えれる 使用するかどうかわからない膨大な量ではなく使用した分だけ料金を払うので結果的に費用が安くなる ・データセンターの維持管理費用が不要 データセンターのコンピューティングで必要なインフラストラクチャとサーバー管理に割く多くの時間と費用をカットできる ・キャパの予測がいらない クラウドコンピューティングではアプリケーションのデプロイ前に、インフラストラクチャに必要なキャパを予測する必要がなく、必要になった時だけ足せばいい ・圧倒的なスケールメリット クラウドコンピューティングを使用すると自社で環境構築するよりもコストを低く抑えることができる ・スピードと俊敏性の向上 クラウドコンピューティングの柔軟性で、アプリケーション開発とデプロイが簡単になります ・数分でグローバルに展開 AWSクラウドのグローバルなサービス規模により、世界中のお客様にアプリケーションを低レイテンシー（遅延時間）で提供します AWSのクラウドコンピューティング クラウドコンピューティングとは ITリソースをインターネット経由でオンデマンド配信（必要な時に必要な分だけ渡す） ことです。 AWSでは使用した分だけ料金を支払うので通常時は必要最低限、必要になったらメモリを増やして使わなくなったらまたもとにすぐに戻せます クラウドコンピューティングのデプロイモデル デプロイモデルとは何か？ 簡潔に書くとクラウドサービスの基盤のことです。基本的にはシステムごとに統一されます クラウドベースデプロイ ＜特徴＞ ・アプリケーションのすべてをクラウド上で実行する ・既存のアプリケーションをクラウドに移行する ・新しいアプリケーションをクラウド上で計画及び構築する クラウドベースデプロイは上記に記した通り既存のアプリケーションを クラウドに移行することや、新しいアプリケーションをクラウド上で計画、構築することができます。 オンプレミスデプロイ ＜特徴＞ ・仮想化ツールとリソース管理ツールを使用して、リソースをデプロイする ・アプリケーション管理と仮想化技術を使用して、リソースの使用率を向上させる オンプレミスデプロイは、プライベートクラウドとも呼ばれ、このモデルでは仮想化ツールとリソース管理ツールを使用して、リソースをオンプレミスにデプロイします。 ※オンプレミスとはサーバーやソフトウェアなどの情報システムを、使用者が管理している施設の機内や機器に設置して運用していくことです クラウドベースデプロイ ＜特徴＞ ・クラウドベースのリソースをオンプレミスのインフラストラクチャに接続する ・クラウドベースのリソースを従来のITアプリケーションと統合する ハイブリッドデプロイでは、クラウドベースのリソースをオンプレミスのインフラストラクチャに接続します。ハイブリッドデプロイは様々な状況で使用されます。 例えば、オンプレミスで最適化して管理しているレガシーアプリケーションを規定などでオンプレミスで保持を求められたときなどに使用します。 ※レガシーアプリケーションとは現在のOSではサポートされないアプリケーションを指します。 まとめ 初投稿で書き方や口調がぐちゃぐちゃになってしまいました。 AWS認定試験に向けた最初のページなのにとても長々と書いてしまいました。 何か間違いや不明瞭な点を発見しましたらコメントにて指摘していただけるとありがたいです。

はじめに AWS Databricksの使用料を確認した際に、UI上だけでは細かい分析ができなかったので詳細データを取得して分析してみましたので、その方法をご紹介したいと思います。 使用料や利用料金を確認するには？ AzureとAWS/GCPで確認の仕方は異なります。Azureの場合はAzure Serviceに組み込まれているため、Azure Portalから確認することが可能です。AWS/GCPは Databricks Account Console上から確認することができます。今回はAWS/GCPのケースにフォーカスしております。 Databricks Account Console -> [Usage] 上図のように、Workspace毎やSKU毎に使用量（DBU）や料金（$)を確認できます。日付指定もできるため簡易的な確認はこの画面で十分そうです。しかしもっと細かくクラスター単位やユーザー単位での使用量の分析やプロジェクト毎の使用量を把握したい場合はこの画面だけでは足りそうもありません。 詳細データを取得する 上図のUsage画面には、もう一つ機能として詳細データ(csv)を取得することができます。右上の[Usage actions]をクリックすると以下の画面が現れます。　取得する期間を指定してDownloadするとcsvファイルが取得できます。 どのようなデータが取得できるかというと以下のようなスキーマ情報になります。 https://docs.databricks.com/administration-guide/account-settings/usage-analysis.html#csv-file-schema 他にもAPI経由で取得することができるため、継続的にモニタリングしたい場合はAPI経由でS3などのストレージに保管するように設定するといいと思います。設定方法 データを使って分析してみる せっかくなのでDatabricks上で分析してみたいと思います。最後にサンプルノートブックも用意しておりますのでお手元で試してみてください。 また今回のサンプルノートブックはマニュアルにあるサンプルコードをカスタマイズして利用しております。 1) データのアップロード 先ほどダウンロードしたファイルをS3ストレージもしくはDatabricks上にアップします。S3上に保存してそれをマウントして利用することで長期的な運用が可能になるのでお勧めですが、お試しであれば直接アップロードでもいいかと思います。 [Data] -> [Upload]ボタン 2) サンプルノートブックのインポート 今回はこちらのサンプルノートブックを利用します。自分の環境にインポートしてご利用ください。 3) ファイルパスと料金設定の確認 アップロードしたファイルパスの編集と、利用しているEditionや各料金設定を確認します。金額設定はこちらの内容を元に金額を算出するためお客様の契約内容に応じて変更してください。defaultの金額はこちらで確認できます。AWS Pricing （契約内容によっては割引が適用されているケースもあります。） 4) RunAll実行と処理概要 あとはRunAll実行します。どのようなことを実行しているかというと今回取得した詳細データには、各Cluster毎のdbuが算出されておりますが、金額までは算出されておりません。そのため別途price表を作成してjoinしております。 join後のglobal data(globalDF) 取得したデータ(usageDF)に金額リスト（sku_rate_df)をjoinし、tag情報をいくつかパースしたデータフレームになります。tag情報は独自に追加できるため、適宜変更してご利用ください。 widget作成 またwidgetを作成してこの後、日付やtag指定などを出来るようにオプションを追加しております。Widgetを利用するとインタラクティブな分析が可能になります。 usage関数作成(累積算出のため） こちらはオリジナルのサンプルノートブックにあったため利用させていただきました。この後の処理が簡素化できるのと累積表示が可能になります。 5) 分析してみる それでは早速いくつか分析グラフを用意しましたのでみてみたいと思います。 workspace毎の使用金額 会社内で複数のワークスペースを用意している場合、ワークスペース毎にモニタリングすることは非常に重要です。ここでは累積データを使いました。 [plot Option]で累積ではないデータでの表示やDBU表示に切り替えることができます。 SKU毎の使用金額 Notebook上で実行したものはAll Purposeとして課金され、Job実行ではJobとして課金されます。そのためSKU単位で見ることでどのような処理が多いかが確認できます。 Tag毎の使用金額 Widgetのtagを指定することで、tag単位での使用料を確認できます。 以下はteamというタグを指定してますが、teamタグがないケースが多いため殆どnullになってしまってます。global設定でデフォルトtagなど指定すると更に良いかと。 tableを作成することでSQLを使った分析が可能になります。またDatabricks SQLからもアクセスできるようになり、ダッシュボード作成や外部のBIツールからのアクセスが可能になります。 SKUの割合をPieチャートで確認 利用の多いユーザー(Creator) Top5 利用の多いクラスター Top5 Cluster Node Type別利用料金 勿論他にも様々な分析ができるかと思います。是非お試しください。 7) Databricks SQL Dashboardで運用しよう 長期的なモニタリングを考えるなら是非Dashboardを作成して運用してみてください。Alert設定も可能ですので使いすぎの場合などアラートをあげて対応することが可能になります。 ここからはノートブックは利用しませんが、運用時には取得したデータを加工してDelta Tableとして保存する必要があるので、このノートブックをJob登録して定期実行すると良いかと思います。 Databricks SQLを使ったDashboard作成はまた別の記事でご紹介いたします。 サンプルノートブック AWS Databricks Usage Analytics Dashboard

先日、AWSにてアカウントが乗っ取られ、高額請求されました。 当時はかなり不安でしたが、サポートのおかげで無事解決することができました。 今回は解決までの行動・カスタマーサービスの対応を時系列で書きたいと思います。 同じ境遇の方は少しでも参考になれば幸いです。 ※当方はAWS初心者のため、この記事は初心者向けとなります。 [不正利用発生から解決まで] 12月7日:事件発生AWSから1346ドルの請求（およそ16万円）が届く。原因を確認したところ、高容量のインスタンスが複数作成されていた。（身に覚えが無い）作成元をCloudTrail（アカウントのアクセス日時・元を特定できる）で調べると、アメリカから不正にアクセスされていることが発覚。すぐに該当アカウントの停止を行った。 その後、AWSのセキュリティ部門にアクセス元のIPについて問い合わせ、返信待ち。この時点ではかなり焦っていた。余談だが、上記の部門は返金対応の部署では無いということに注意していただきたい。12月9日:結果届くセキュリティ部門の調査結果は次の通りだった。 Thank you for submitting your report. We have completed an initial investigation. Based on the information provided, we have determined that the reported content or activity is not hosted on or originating from the AWS network.（訳：ご報告をお寄せいただき、ありがとうございます。最初の調査を完了しました。報告されたコンテンツまたはアクテビティは、AWSネットワーク上でホストされていない、またはAWSネットワークから発信されていないと判断しました。） この調査結果をもとにawsサポートセンターに問い合わせを行った。サポートセンターの返信待ち中は心臓が止まりそうだった・・・ 12月13日:サポートセンターの報告届く 4日待ってやっと返信が届いた。 内容は以下の通りであった。（一部抜粋、数字は伏せてある） ご担当者様 不正アクセスによるご請求が発生しておりますことについてご不安なご心情とお察しいたします。 担当部署よりケース: を通じて○月○日以降に複数回ご連絡させていただいておりますように、アカウントが不正に使用された疑いがございます。 なお、不正なアクセスによるものであった場合でも、AWS カスタマーアグリーメントに基づき、 アカウント下で生じるあらゆる活動については、料金を含めてお客様の責任でセキュリティを保持していただくものとなっております。 お客様の事情を考慮して本アカウントがセキュアな状態になり次第、当窓口よりご請求金額調整の検討を依頼することは可能でございます。 担当部署による判断となり、現時点でお客様のご期待に沿う回答ができることお約束するものではございませんこと、何卒ご了承ください。 つまり、支払いが免除されない可能性があるとのこと。 これは、AWSの責任共有モデルにも記載されており大反省。（完全に見逃していた。。。） 同時にセキュア措置と不正アカウント・リソースの報告を依頼された。 セキュリティレベルを上げるために以下の対策を行う。 ・Amazon GuardDuty追加 ・Amazon Inspector追加 ・２段階認証の追加 ・アクセスキーの削除 ・パスワード変更 （改めて見るとセキュリティに対する認識の甘さが目に見える。。。） その他に対策を取りたい方はこちらを参考にしても良いだろう。 12月20日:セキュリティ措置の確認連絡届く セキュリティ措置、不正アカウントの特定完了。以下抜粋。 担当部署より、本アカウントの保護措置確認が完了したのでご報告いたします。 引き続き、別の担当部署へ不正利用により発生したご利用料金の請求調整の依頼をいたしました。 こちらも海外の別部署となりますため、返答を得られるまでに日数を頂戴する可能性がございます。 返答を得られ次第速やかにご報告をさせていただきますので、今しばらくお待ちくださいますようお願い申し上げます。 （年末のためか返信が遅くなっていたが、審査中の連絡が逐一届いた。サポートセンターには感謝しかない。。。） 12月30日:返金連絡 そしてついにサポートセンターからの連絡が来る。 結果は、、、全額返金！！！ 大変お待たせいたしました。 下記の通りご請求額の調整が完了し、担当部署よりクレジットカードへの返金手続きを行っております。 この度は、不正利用について早い段階でご相談いただき、またかかる調査や対策等に快くご協力をいただき誠にありがとうございました。 請求額調整のお手続きは以上で完了でございます。 本当にサポートセンターには感謝しかない。年末なのに対応していただいて大変助かった。 [発生の原因]これはセキュリティに対する認識が甘かったことが原因だった。 アクセスキーの放置、２段階認証の未実施など今振り返ると考えられないものばかりだ。 ただ、どのような経緯でログインされたのが分からない。よくあるのが、アクセスキーをGithubに載せてしまうといったケースだが私は行っていない。 （この辺りは知見がないため、何かわかる方いたら教えて欲しいです。。。） [まとめ] クラウド破産というワードもあるくらい、身近に不正アクセスが存在している。 返金対応のケースを調べたところ、半額返金だったり審査が通らなかったケースもあるようなので、すぐにセキュリティレベルを上げることをオススメする。 AWSを利用している方は、セキュリティに対する認識を再度改めた方がいいかもしれない。

こちらのハンズオンをやっていたところ、いくつかの問題に遭遇したので備忘録。 Rails アプリケーションをコンテナで開発しよう ! 第 1 回 - まずは Rails アプリケーション作りから Rails7のインストールに失敗する 記事では Ruby2.5 & Rails6 を使用しているが、現時点(2022/1)での最新版は 7.0.1。 エラーメッセージにもあるように7.0.1 ではRuby2.7以上が必要であるため gem install railsに失敗する。 root@810c33297af8:/work# gem install rails Fetching: concurrent-ruby-1.1.9.gem (100%) Successfully installed concurrent-ruby-1.1.9 Fetching: i18n-1.8.11.gem (100%) Successfully installed i18n-1.8.11 Fetching: tzinfo-2.0.4.gem (100%) Successfully installed tzinfo-2.0.4 Fetching: activesupport-7.0.1.gem (100%) ERROR: Error installing rails: There are no versions of activesupport (= 7.0.1) compatible with your Ruby & RubyGems. Maybe try installing an older version of the gem you're looking for? activesupport requires Ruby version >= 2.7.0. The current ruby version is 2.5.0. gem install のオプションでRailsのバージョンを指定してインストールすることとした。 root@810c33297af8:/work# gem install -v 6.0.3.2 rails Nokogiriのインストールに失敗する さて、Railのバージョン指定をして改めてgem installを実施したところ、 root@810c33297af8:/work# gem install -v 6.0.3.2 rails ... Fetching: activesupport-6.0.3.2.gem (100%) Successfully installed activesupport-6.0.3.2 ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) bad response Forbidden 403 (https://api.rubygems.org/quick/Marshal.4.8/nokogiri-1.13.0-x64-unknown.gemspec.rz) Nokogiri 1.13.0のインストールに失敗している。 403なのでライブラリが不足している的なやつではないみたい。 rubygems.org でNokogiriの過去バージョンを調べて 1.12.5 を予めインストールすることで解決。 root@810c33297af8:/work# gem install nokogiri -v 1.12.5 Fetching: nokogiri-1.12.5-x86_64-linux.gem (100%) Successfully installed nokogiri-1.12.5-x86_64-linux 1 gem installed root@810c33297af8:/work# gem install -v 6.0.3.2 rails Fetching: loofah-2.13.0.gem (100%) Successfully installed loofah-2.13.0 Fetching: rails-html-sanitizer-1.4.2.gem (100%) Successfully installed rails-html-sanitizer-1.4.2 Fetching: rails-dom-testing-2.0.3.gem (100%) Successfully installed rails-dom-testing-2.0.3 Fetching: builder-3.2.4.gem (100%) Successfully installed builder-3.2.4 Fetching: erubi-1.10.0.gem (100%) Successfully installed erubi-1.10.0 Fetching: actionview-6.0.3.2.gem (100%) Successfully installed actionview-6.0.3.2 Fetching: actionpack-6.0.3.2.gem (100%) Successfully installed actionpack-6.0.3.2 Fetching: activemodel-6.0.3.2.gem (100%) Successfully installed activemodel-6.0.3.2 Fetching: activerecord-6.0.3.2.gem (100%) Successfully installed activerecord-6.0.3.2 Fetching: globalid-1.0.0.gem (100%) Successfully installed globalid-1.0.0 Fetching: activejob-6.0.3.2.gem (100%) Successfully installed activejob-6.0.3.2 Fetching: mini_mime-1.1.2.gem (100%) Successfully installed mini_mime-1.1.2 Fetching: mail-2.7.1.gem (100%) Successfully installed mail-2.7.1 Fetching: actionmailer-6.0.3.2.gem (100%) Successfully installed actionmailer-6.0.3.2 Fetching: nio4r-2.5.8.gem (100%) Building native extensions. This could take a while... Successfully installed nio4r-2.5.8 Fetching: websocket-extensions-0.1.5.gem (100%) Successfully installed websocket-extensions-0.1.5 Fetching: websocket-driver-0.7.5.gem (100%) Building native extensions. This could take a while... Successfully installed websocket-driver-0.7.5 Fetching: actioncable-6.0.3.2.gem (100%) Successfully installed actioncable-6.0.3.2 Fetching: mimemagic-0.3.10.gem (100%) Building native extensions. This could take a while... Successfully installed mimemagic-0.3.10 Fetching: marcel-0.3.3.gem (100%) Successfully installed marcel-0.3.3 Fetching: activestorage-6.0.3.2.gem (100%) Successfully installed activestorage-6.0.3.2 Fetching: actionmailbox-6.0.3.2.gem (100%) Successfully installed actionmailbox-6.0.3.2 Fetching: actiontext-6.0.3.2.gem (100%) Successfully installed actiontext-6.0.3.2 Fetching: thor-1.2.1.gem (100%) Successfully installed thor-1.2.1 Fetching: method_source-1.0.0.gem (100%) Successfully installed method_source-1.0.0 Fetching: railties-6.0.3.2.gem (100%) Successfully installed railties-6.0.3.2 Fetching: sprockets-4.0.2.gem (100%) Successfully installed sprockets-4.0.2 Fetching: sprockets-rails-3.4.2.gem (100%) Successfully installed sprockets-rails-3.4.2 Fetching: rails-6.0.3.2.gem (100%) Successfully installed rails-6.0.3.2 29 gems installed

背景/目的 Admin権限をもったIAMユーザを使ってRayクラスターを立ち上げるのがシンプルだがセキュリティ的によろしくない 最小限の権限でRayクラスターを立ち上げたい 権限を絞ってIAMユーザ/ロールを作り、Rayクラスターを起動する 参考 下記を参考にしながらトライする。 概要 最小限の権限をもったユーザとロールを作成する。ロールをもとにインスタンスプロファイルを作成し、インスタンスプロファイルのARN(Amazon Resource Name)をRayクラスター起動用コンフィグファイルで参照してヘッドノードとワーカノードに最小限の権限を割り当てるようにする。コンフィグファイルをもとにRayクラスターを起動する。 手順 1. IAM Policy/Role/IAM User/AccessKeyを作成 CloudFormationのスタック用テンプレートを作成し、一括して作成する。テンプレートCloudFormationForRay.jsonは付録に記載。IAM Policy、IAM Role、IAM User、AccessKeyの概要は下記の通り。 IAM Policy ray-ec2-launcher-policy ray-s3-access-policy IAM Role ray-head-v1-role ray-ec2-launcher-policyとray-s3-access-policyの両方を割り当て ray-worker-v1-role ray-s3-access-policyのみ割り当て IAM InstanceProfile ray-head-v1-instanceprofile ray-head-v1-roleを割り当て ray-worker-v1-instanceprofile ray-worker-v1-roleを割り当て IAM User ray-launcher-user ray-ec2-launcher-policyとray-s3-access-policyの両方を割り当て IAM AccessKey SecretsManager Secret CloudFormationでスタックの作成が完了したら、AWS Secrets Managerの「シークレット」からray-launcher-user-credentialsを開いてaccessKeyIdとsecretAccessKeyの値をメモしておく。 以下のコマンドでIAMユーザray-launcher-userのクレデンシャル情報を登録する。対話式でAWS Access Key IDとAWS Secret Access Keyを尋ねられるので、それぞれ先ほどメモしたaccessKeyIdとsecretAccessKeyを入力する。Default region nameとDefault output formatは適当で構わない。 $ aws configure 2. Rayクラスター起動 下記を参考にしながらRayクラスター起動用コンフィグRayClusterConfig.yamlを作成する。詳細は付録を参照。 作成したRayClusterConfig.yamlでRayクラスターを起動する。 $ ray up -f RayClusterConfig.yaml 3. Jupyter notebookにアクセス 下記コマンドでヘッドノードにアクセスする。 ray attach /root/config.yaml Jupyter notebookを起動する。 jupyter notebook --ip=* --no-browser --port=8888 Chromeなど適当なブラウザでヘッドノード上に起動したJupyter notebookにアクセスする。tokenはJupyter notebook起動時にBash上に表示されたものを入力する。 http://＜クラスターヘッドのIP＞:8888/ 以上で終わりです。お疲れ様でした✨ 付録 CloudFormationスタック用テンプレート CloudFormationForRay.json { "AWSTemplateFormatVersion" : "2010-09-09", "Parameters" : { "ACCOUNTID": { "Type": "String", "Default" : "874210249752" }, "REGION": { "Type": "String", "Default" : "us-west-2" } }, "Resources" : { "RayEc2LauncherPolicy" : { "Type" : "AWS::IAM::ManagedPolicy", "Properties" : { "ManagedPolicyName": "ray-ec2-launcher-policy", "PolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:TerminateInstances", "ec2:DeleteTags", "ec2:StartInstances", "ec2:CreateTags", "ec2:StopInstances" ], "Resource": !Sub "arn:aws:ec2:${REGION}:${ACCOUNTID}:instance/*" }, { "Effect": "Allow", "Action": [ "ec2:Describe*", "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeKeyPairs", "ec2:DescribeSecurityGroups", "ec2:AuthorizeSecurityGroupIngress", "iam:GetInstanceProfile", "ec2:CreateSecurityGroup", "ec2:CreateKeyPair" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ !Sub "arn:aws:iam::${ACCOUNTID}:role/ray-head-v1-role", !Sub "arn:aws:iam::${ACCOUNTID}:role/ray-worker-v1-role" ] } ] } } }, "RayS3AccessPolicy" : { "Type" : "AWS::IAM::ManagedPolicy", "Properties" : { "ManagedPolicyName": "ray-s3-access-policy", "PolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:*" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::ray-data/*", "arn:aws:s3:::ray-data" ] } ] } } }, "RayHeadV1Role": { "Type" : "AWS::IAM::Role", "Properties" : { "AssumeRolePolicyDocument" : { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ec2.amazonaws.com" ] }, "Action": [ "sts:AssumeRole" ] } ] }, "ManagedPolicyArns" : [{"Ref": "RayEc2LauncherPolicy"}, {"Ref": "RayS3AccessPolicy"}], "RoleName" : "ray-head-v1-role" } }, "RayWorkerV1Role": { "Type" : "AWS::IAM::Role", "Properties" : { "AssumeRolePolicyDocument" : { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ec2.amazonaws.com" ] }, "Action": [ "sts:AssumeRole" ] } ] }, "ManagedPolicyArns" : [{"Ref": "RayS3AccessPolicy"}], "RoleName" : "ray-worker-v1-role" } }, "RayHeadV1InstanceProfile": { "Type" : "AWS::IAM::InstanceProfile", "Properties" : { "InstanceProfileName" : "ray-head-v1-instanceprofile", "Roles" : [{"Ref": "RayHeadV1Role"}] } }, "RayWorkerV1InstanceProfile": { "Type" : "AWS::IAM::InstanceProfile", "Properties" : { "InstanceProfileName" : "ray-worker-v1-instanceprofile", "Roles" : [{"Ref": "RayWorkerV1Role"}] } }, "RayLauncherUser": { "Type" : "AWS::IAM::User", "Properties" : { "ManagedPolicyArns" : [{"Ref": "RayEc2LauncherPolicy"}, {"Ref": "RayS3AccessPolicy"}], "UserName" : "ray-launcher-user" } }, "RayLauncherUserAccessKey": { "Type": "AWS::IAM::AccessKey", "Properties": { "UserName": {"Ref": "RayLauncherUser"} } }, "RayLauncherUserAccessKeySecret": { "Type": "AWS::SecretsManager::Secret", "Properties": { "Name": !Sub "${RayLauncherUser}-credentials", "SecretString": !Sub "{\"accessKeyId\":\"${RayLauncherUserAccessKey}\",\"secretAccessKey\":\"${RayLauncherUserAccessKey.SecretAccessKey}\"}" } } } } Rayクラスター用コンフィグファイル Rayクラスターコンフィグで特に大事なところをピックアップしていく。コンフィグ全文は最後に記載。 AWSリージョン＆セキュリティグループを指定 provider: region: us-west-2 availability_zone: us-west-2a,us-west-2b security_group: GroupName: str IpPermissions: - IpPermission デフォルトでセキュリティグループ上ポート22番は許可されていることに注意。ポート22番を許可する設定を入れると以下のエラーがでる。 ポート22番を許可すると、、、 security_group: GroupName: ray-cluster-sg IpPermissions: - FromPort: 22 IpProtocol: tcp IpRanges: - CidrIp: 0.0.0.0/0 ToPort: 22 ポートを重複して許可した場合のエラー botocore.exceptions.ClientError: An error occurred (InvalidParameterValue) when calling the AuthorizeSecurityGroupIngress operation: The same permission must not appear multiple times EC2インスタンスタイプ/インスタンスプロファイルの指定 available_node_types: ray.head.default: node_config: InstanceType: m5.large IamInstanceProfile: Arn: arn:aws:iam::<AccountID>:instance-profile/ray-head-v1-instanceprofile ray.worker.default: node_config: InstanceType: m5.large IamInstanceProfile: Arn: arn:aws:iam::<AccountID>:instance-profile/ray-worker-v1-instanceprofile ローカルのディレクトリをRayクラスターにコピー # Files or directories to copy to the head and worker nodes. The format is a # dictionary from REMOTE_PATH: LOCAL_PATH, e.g. file_mounts: { # "/path1/on/remote/machine": "/path1/on/local/machine", # "/path2/on/remote/machine": "/path2/on/local/machine", } RayClusterConfig.yaml RayClusterConfig.yaml # An unique identifier for the head node and workers of this cluster. cluster_name: default # The maximum number of workers nodes to launch in addition to the head # node. max_workers: 2 # The autoscaler will scale up the cluster faster with higher upscaling speed. # E.g., if the task requires adding more nodes then autoscaler will gradually # scale up the cluster in chunks of upscaling_speed*currently_running_nodes. # This number should be > 0. upscaling_speed: 1.0 # This executes all commands on all nodes in the docker container, # and opens all the necessary ports to support the Ray cluster. # Empty string means disabled. docker: image: "rayproject/ray-ml:latest-gpu" # You can change this to latest-cpu if you don't need GPU support and want a faster startup # image: rayproject/ray:latest-gpu # use this one if you don't need ML dependencies, it's faster to pull container_name: "ray_container" # If true, pulls latest version of image. Otherwise, `docker run` will only pull the image # if no cached version is present. pull_before_run: True run_options: # Extra options to pass into "docker run" - --ulimit nofile=65536:65536 # Example of running a GPU head with CPU workers # head_image: "rayproject/ray-ml:latest-gpu" # Allow Ray to automatically detect GPUs # worker_image: "rayproject/ray-ml:latest-cpu" # worker_run_options: [] # If a node is idle for this many minutes, it will be removed. idle_timeout_minutes: 5 # Cloud-provider specific configuration. provider: type: aws region: us-west-2 # Availability zone(s), comma-separated, that nodes may be launched in. # Nodes are currently spread between zones by a round-robin approach, # however this implementation detail should not be relied upon. availability_zone: us-west-2a,us-west-2b # Whether to allow node reuse. If set to False, nodes will be terminated # instead of stopped. cache_stopped_nodes: True # If not present, the default is True. security_group: GroupName: ray-cluster-sg IpPermissions: - FromPort: 8888 IpProtocol: tcp IpRanges: - CidrIp: 0.0.0.0/0 ToPort: 8888 # How Ray will authenticate with newly launched nodes. auth: ssh_user: ubuntu # By default Ray creates a new private keypair, but you can also use your own. # If you do so, make sure to also set "KeyName" in the head and worker node # configurations below. # ssh_private_key: /path/to/your/key.pem # Tell the autoscaler the allowed node types and the resources they provide. # The key is the name of the node type, which is just for debugging purposes. # The node config specifies the launch config and physical instance type. available_node_types: ray.head.default: # The node type's CPU and GPU resources are auto-detected based on AWS instance type. # If desired, you can override the autodetected CPU and GPU resources advertised to the autoscaler. # You can also set custom resources. # For example, to mark a node type as having 1 CPU, 1 GPU, and 5 units of a resource called "custom", set # resources: {"CPU": 1, "GPU": 1, "custom": 5} resources: {} # Provider-specific config for this node type, e.g. instance type. By default # Ray will auto-configure unspecified fields such as SubnetId and KeyName. # For more documentation on available fields, see: # http://boto3.readthedocs.io/en/latest/reference/services/ec2.html#EC2.ServiceResource.create_instances node_config: InstanceType: m5.large ImageId: ami-0a2363a9cff180a64 # Deep Learning AMI (Ubuntu) Version 30 # You can provision additional disk space with a conf as follows BlockDeviceMappings: - DeviceName: /dev/sda1 Ebs: VolumeSize: 100 # Additional options in the boto docs. IamInstanceProfile: Arn: arn:aws:iam::874210249752:instance-profile/ray-head-v1-instanceprofile ray.worker.default: # The minimum number of worker nodes of this type to launch. # This number should be >= 0. min_workers: 0 # The maximum number of worker nodes of this type to launch. # This takes precedence over min_workers. max_workers: 2 # The node type's CPU and GPU resources are auto-detected based on AWS instance type. # If desired, you can override the autodetected CPU and GPU resources advertised to the autoscaler. # You can also set custom resources. # For example, to mark a node type as having 1 CPU, 1 GPU, and 5 units of a resource called "custom", set # resources: {"CPU": 1, "GPU": 1, "custom": 5} resources: {} # Provider-specific config for this node type, e.g. instance type. By default # Ray will auto-configure unspecified fields such as SubnetId and KeyName. # For more documentation on available fields, see: # http://boto3.readthedocs.io/en/latest/reference/services/ec2.html#EC2.ServiceResource.create_instances node_config: InstanceType: m5.large ImageId: ami-0a2363a9cff180a64 # Deep Learning AMI (Ubuntu) Version 30 # Run workers on spot by default. Comment this out to use on-demand. # NOTE: If relying on spot instances, it is best to specify multiple different instance # types to avoid interruption when one instance type is experiencing heightened demand. # Demand information can be found at https://aws.amazon.com/ec2/spot/instance-advisor/ InstanceMarketOptions: MarketType: spot # Additional options can be found in the boto docs, e.g. # SpotOptions: # MaxPrice: MAX_HOURLY_PRICE # Additional options in the boto docs. IamInstanceProfile: Arn: arn:aws:iam::874210249752:instance-profile/ray-worker-v1-instanceprofile # Specify the node type of the head node (as configured above). head_node_type: ray.head.default # Files or directories to copy to the head and worker nodes. The format is a # dictionary from REMOTE_PATH: LOCAL_PATH, e.g. file_mounts: { # "/path1/on/remote/machine": "/path1/on/local/machine", # "/path2/on/remote/machine": "/path2/on/local/machine", } # Files or directories to copy from the head node to the worker nodes. The format is a # list of paths. The same path on the head node will be copied to the worker node. # This behavior is a subset of the file_mounts behavior. In the vast majority of cases # you should just use file_mounts. Only use this if you know what you're doing! cluster_synced_files: [] # Whether changes to directories in file_mounts or cluster_synced_files in the head node # should sync to the worker node continuously file_mounts_sync_continuously: False # Patterns for files to exclude when running rsync up or rsync down rsync_exclude: - "**/.git" - "**/.git/**" # Pattern files to use for filtering out files when running rsync up or rsync down. The file is searched for # in the source directory and recursively through all subdirectories. For example, if .gitignore is provided # as a value, the behavior will match git's behavior for finding and using .gitignore files. rsync_filter: - ".gitignore" # List of commands that will be run before `setup_commands`. If docker is # enabled, these commands will run outside the container and before docker # is setup. initialization_commands: [] # List of shell commands to run to set up nodes. setup_commands: [] # Note: if you're developing Ray, you probably want to create a Docker image that # has your Ray repo pre-cloned. Then, you can replace the pip installs # below with a git checkout <your_sha> (and possibly a recompile). # To run the nightly version of ray (as opposed to the latest), either use a rayproject docker image # that has the "nightly" (e.g. "rayproject/ray-ml:nightly-gpu") or uncomment the following line: # - pip install -U "ray[default] @ https://s3-us-west-2.amazonaws.com/ray-wheels/latest/ray-2.0.0.dev0-cp37-cp37m-manylinux2014_x86_64.whl" # Custom commands that will be run on the head node after common setup. head_setup_commands: [] # Custom commands that will be run on worker nodes after common setup. worker_setup_commands: [] # Command to start ray on the head node. You don't need to change this. head_start_ray_commands: - ray stop - ray start --head --port=6379 --object-manager-port=8076 --autoscaling-config=~/ray_bootstrap_config.yaml # Command to start ray on worker nodes. You don't need to change this. worker_start_ray_commands: - ray stop - ray start --address=$RAY_HEAD_IP:6379 --object-manager-port=8076 head_node: {} worker_nodes: {}