初めに 以下のチュートリアルをやってみました。初めはマイクロサービスについて勉強したかったのでこのチュートリアルをやってみたのですが、ALB についての勉強にもなりました。具体的には ALB のパスベースルーティングを初めて使い、非常に勉強になりました。 なお、このチュートリアルでは EC2 タイプを使っていますが、この記事では Fargate でチュートリアルを検証しています。また、チュートリアルでは CloudFormation を使っていますが、この記事では簡略化のため VPC などはデフォルトのリソースを使い、ALB は手動で作成しています。 マイクロサービスが重要な理由 マイクロサービスのメリットについて簡単に確認します。 モノリシックアーキテクチャ スケーリングが困難 アプリケーションのコードベースが拡大するにつれ、更新と維持が複雑化する 新しい機能、言語、フレームワーク、テクノロジーの導入が難しい マイクロサービス さまざまなフレームワークやプログラミング言語を使用して作成することができる マイクロサービスは、単一のサービスとして、またはサービスのグループとして個別にデプロイできる モノリスのコンテナ化 このチュートリアルに使用するリポジトリをクローンします。 git clone https://github.com/awslabs/amazon-ecs-nodejs-microservices ECR に api という名前のリポジトリを作成し、以下のようにモノリスアプリケーションの Dockerfile のあるディレクトリに移動し、ビルドします。 cd ~/amazon-ecs-nodejs-microservices/2-containerized/services/api docker build -t api . ECR にログインし、タグ付け・プッシュを行います。 $(aws ecr get-login --no-include-email --region ap-northeast-1) docker tag api:latest 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/api:v1 docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/api:v1 モノリスのデプロイ 以下の手順に従い ALB と ターゲットグループを作成し、モノリスをデプロイします。 /api/users 、/api/threads、/api/posts にアクセスし、適切なレスポンスが返ってくることを確認します。 モノリスの分割 以下のように機能ごとにマイクロサービスに分割し、それぞれのイメージをビルド・プッシュします。~/amazon-ecs-nodejs-microservices/3-microservices/services にはすでに分割済みのソースコードや Dockerfile が用意されています。 cd ~/amazon-ecs-nodejs-microservices/3-microservices/services docker build -t posts ./posts docker build -t users ./users docker build -t threads ./threads docker tag users:latest 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/users:v1 docker tag posts:latest 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/posts:v1 docker tag threads:latest 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/threads:v1 docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/users:v2 docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/posts:v2 docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/threads:v2 マイクロサービスのデプロイ users、threads、posts 用にタスク定義を作成します。 ELB はモノリスアプリケーションで使用したものを利用します。ターゲットグループごとにリスナールールを作成し、リクエスト URL のパスによってルーティングを行うことができます。 users、threads、posts 用に 3 つのターゲットグループを作成します。ターゲットタイプを「IP」にすることを除いて、デフォルトの設定で作成します。 以下のようにリスナールールを作成します。 サービスを作成します。作成後、以下のようにモノリスアプリケーションとマイクロサービスアプリケーションが両方デプロイされた状態ですが、上記のリスナールールにより、リクエストはすべてモノリスアプリケーションが処理するようになっています。これはモノリスアプリケーションからマイクロサービスアプリケーションに切り替える時のダウンタイムを 0 にするためです。 以下のようにトラフィックの切り替えを行います。これ以降、モノリスアプリケーションにリクエストが到達することはありません。 最後に api サービスのタスクの必要数を 0 にし、マイクロサービスアプリケーションに移行が完了します。 参考記事

AWS Directory Service とは Acive Directory を AWS クラウド上で実現したもの Active Directory(MS Active Directory) というのは　microsoft　が提供する、ユーザー情報管理する機能 理解用 AWS上に、MS Active Directory を構築するわけではない　→　AWS Directory Service for Microsoft Active Directoryによって、MS Active Directoryを構築する Simple AD と AD Connector の２種類 Simple ADはAWS に新規ディレクトリを構築する AD ConnectorはActive Directory と既存のDirectory（オンプレなど）をAWSに連携させる IAMユーザー管理とは併用できる

はじめに AWSが提供しているgit-secretsを導入して、AWSの機密情報を誤ってGitHubにあげないように設定します。 一度設定するとこれからも、わざわざ設定しなくて済むように導入していきます。 よろしくお願いします。 git-secretsとは git-secretsとはAWSが提供しているツールで、コードをコミットするときにパスワードだと推定されるような文字列が含まれていると、処理を中断してくれます。 つまりはうっかりミスを指摘してくれます。 git-secrets導入 ターミナルからHomebrewを経由してgit-secretsを導入します。 ターミナル % cd ~/ #ホームディレクトリに移動 % brew install git-secrets 続いてアプリケーションに適用します。 ターミナル % cd アプリケーション名 #開発中のアプリに移動 % git secrets --install 次に「Access key ID」や「Secret access key」などのアップロードしたくないAWS関連の秘密情報を一括で設定します。 下記のコマンドを開発中のアプリケーションで実行します。 ターミナル % git secrets --register-aws --global どのような設定がされているか気になる人は下記のコマンドで内容を表示できます。 様々な正規表現を用いて設定していることがわかります。 ターミナル % git secrets --list # ⬇️上記コマンドを実施すると、以下の内容が表示されます secrets.providers git secrets --aws-provider secrets.patterns [A-Z0-9]{20} 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 secrets --install」したリポジトリで、「git commit」コマンドを実行したときに秘密情報が含まれていないかチェックされるようになりました。 可視化ツール GitHub Desktopの場合 可視化ツールのGitHub Desktopを仕様している場合さらに設定が必要になります。 下記のコマンドで適用できます。 ターミナル % sudo cp /usr/local/bin/git-secrets /Applications/GitHub\ Desktop.app/Contents/Resources/app/git/bin/git-secrets もし「No such file or directory」というエラーが出る場合は、GitHub Desktopのバージョンが古いことが原因かもしれません。 下記のコマンドを実行しましょう。 ターミナル % sudo cp /usr/local/bin/git-secrets /Applications/GitHub\ Desktop.app/Contents/Resources/git/bin/git-secrets 自動に適用されるようにする これから作成するリポジトリには今回のように毎回設定せずに、自動でgit-secretsが適用されるようにします。 下記コマンドを実行します。 ターミナル % git secrets --install ~/.git-templates/git-secrets % git config --global init.templatedir '~/.git-templates/git-secrets' これで今後作成するアプリケーションはわざわざgit-secretsを適用させる作業する必要はありません。 最後に GitHubにうっかり鍵をプッシュしてしまうのはかなり危険ですので、万が一のことを考えて導入はしておいた方がいいですね。

はじめに この記事は、Boto 3 Docs 1.9.185 documentation の内容をベースとしています。 AWS外部のWebアプリケーションで組織やユーザが登録された場合にPython Boto3, API Gateway, Lambda, Step Functionsから成るAPIを利用してQuickSightでも同様の組織やユーザを作成するケースがあり、本記事ではその際に利用したPython Boto3 QuickSight Clientの関数を記載しています。 Preparation import boto3 import logging logger = logging.getLogger() logger.setLevel(logging.DEBUG) # set Variables REGION_NAME = os.getenv("REGION_NAME") AWS_ACCOUNT_ID = os.getenv("AWS_ACCOUNT_ID") NAME_SPACE = 'default' """ QuickSightへの必要に応じた権限を付与されているRoleをAssume RoleとしてLambdaで利用することにより、 aws_access_key_id, aws_secret_access_keyをパラメータに設定する必要がなくセキュア。 """ qs = boto3.client('quicksight', region_name = REGION_NAME) """ ダッシュボードをqs.create_dashboardで作成するにはテンプレートが必要なのであらかじめ作成。 QuickSightコンソール上で作成しておいた分析のIDをANALYSIS_IDに設定。 SourceEntityには分析および分析に利用しているデータセットのリソースネームを設定。 qs.create_templateで設定されるDataSetPlaceholderはqs.create_dashboardでも利用。 """ ANALYSIS_ID = 'analysis-id' qs.create_template( AwsAccountId = AWS_ACCOUNT_ID, Name = 'Dashboard Template', Permissions = [ { 'Principal': 'arn:aws:quicksight:{}:{}:user/{}/<QuickSightUserName>'.format(REGION, AWS_ACCOUNT_ID, NAME_SPACE), 'Actions': [ 'quicksight:UpdateTemplatePermissions', 'quicksight:DescribeTemplate', ] }, ], TemplateId = 'Dashboard-Template', SourceEntity = { 'SourceAnalysis': { 'Arn': 'arn:aws:quicksight:{}:{}:analysis/{}'.format(REGION, AWS_ACCOUNT_ID, ANALYSIS_ID), 'DataSetReferences': [ { 'DataSetPlaceholder': 'DataSetPlaceHolder1', 'DataSetArn': 'arn:aws:quicksight:{}:{}:dataset/<DataSetId1>'.format(REGION, AWS_ACCOUNT_ID) }, { 'DataSetPlaceholder': 'DataSetPlaceHolder2', 'DataSetArn': 'arn:aws:quicksight:{}:{}:dataset/<DataSetId2>'.format(REGION, AWS_ACCOUNT_ID) }, ] } }, Tags=[ { 'Key': 'name', 'Value': 'Dashboard Template' }, ], # VersionDescription = '1' ) Organization # create Group """ default Namespaceに組織IDと等しいGroupNameのグループを作成。 """ def CreateGroup(qs, AwsAccountId, Namespace, GroupName): qs.create_group( GroupName = GroupName, AwsAccountId = AwsAccountId, Namespace = Namespace ) # create Dataset """ ダッシュボードに表示するデータをデータセットとして作成。 ImportMode = 'DIRECT_QUERY'としてDBからクエリしたデータをQuickSightのデータセットとして利用。 DBのデータをQuickSightのデータセットとして利用するには対象のDBをデータソースとしてQuickSightに登録しておく必要があり、 DataSourceArnにはQuickSightに登録してあるデータソースのリソースネームを指定。 データセットとして読み込むデータとしてクエリデータのカラム情報をColumnsに指定。 QuickSightに作成してあるユーザやグループをPermissionsに設定することでデータセットへの権限の付与が可能。 """ def CreateDataset(qs, AwsAccountId, Region, Namespace, DataSetId, DataSetName, TableName, DataSourceArn, SqlQuery, Columns): qs.create_data_set( AwsAccountId = AwsAccountId, DataSetId = DataSetId, Name = DataSetName, PhysicalTableMap = { TableName: { 'CustomSql': { 'DataSourceArn': DataSourceArn, 'Name': 'Query', 'SqlQuery': SqlQuery, 'Columns': Columns }, } }, ImportMode = 'DIRECT_QUERY', Permissions = [ { 'Principal': 'arn:aws:quicksight:{}:{}:user/{}/<QuickSightUserName>'.format(Region, AwsAccountId, Namespace), 'Actions': [ "quicksight:DescribeDataSet", "quicksight:DescribeDataSetPermissions", "quicksight:PassDataSet", "quicksight:DescribeIngestion", "quicksight:ListIngestions", "quicksight:UpdateDataSet", "quicksight:DeleteDataSet", "quicksight:CreateIngestion", "quicksight:CancelIngestion", "quicksight:UpdateDataSetPermissions" ] }, ] ) # create Dashboard """ 組織名は変更されることが想定されるため、組織IDをDashboardIdとして利用してダッシュボードを作成。。 Permissionsにグループを設定することで、設定されたグループに属しているユーザにダッシュボード閲覧権の付与が可能。 SourceEntityではダッシュボードに読み込むデータセットおよびグラフビジュアルを作成する基となるテンプレートのリソースネームを設定。 DataSetIdとDataSetPlaceholderに1と2が存在しており、ダッシュボードに2つのデータセットを読み込むことを想定。 """ def CreateDashboard(qs, AwsAccountId, Region, Namespace, DashboardId, DashboardName, GroupName, DataSetId1, DataSetId2, DataSetPlaceholder1, DataSetPlaceholder2, TemplateID): qs.create_dashboard( AwsAccountId = AwsAccountId, DashboardId = DashboardId, Name = DashboardName, Permissions = [ { 'Principal': 'arn:aws:quicksight:{}:{}:user/{}/<QuickSightUserName>'.format(Region, AwsAccountId, Namespace), 'Actions': [ 'quicksight:DescribeDashboard', 'quicksight:ListDashboardVersions', 'quicksight:UpdateDashboardPermissions', 'quicksight:QueryDashboard', 'quicksight:UpdateDashboard', 'quicksight:DeleteDashboard', 'quicksight:DescribeDashboardPermissions', 'quicksight:UpdateDashboardPublishedVersion' ] }, { 'Principal': 'arn:aws:quicksight:{}:{}:group/{}/{}'.format(Region, AwsAccountId, Namespace, GroupName), 'Actions': [ "quicksight:DescribeDashboard", "quicksight:QueryDashboard", "quicksight:ListDashboardVersions" ] } ], SourceEntity = { 'SourceTemplate': { 'DataSetReferences': [ { 'DataSetPlaceholder': DataSetPlaceholder1, 'DataSetArn': 'arn:aws:quicksight:{}:{}:dataset/{}'.format(Region, AwsAccountId, DataSetId1) }, { 'DataSetPlaceholder': DataSetPlaceholder2, 'DataSetArn': 'arn:aws:quicksight:{}:{}:dataset/{}'.format(Region, AwsAccountId, DataSetId2) }, ], 'Arn': 'arn:aws:quicksight:{}:{}:template/{}'.format(Region, AwsAccountId, TemplateID) } }, Tags = [ { 'Key': 'name', 'Value': DashboardId }, ], # VersionDescription = '1' ) # delete Group def DeleteGroup(qs, AwsAccountId, Namespace, GroupName): qs.delete_group( GroupName = GroupName, AwsAccountId = AwsAccountId, Namespace = Namespace ) # delete Dataset def DeleteDataset(qs, AwsAccountId, DataSetId): qs.delete_data_set( AwsAccountId = AwsAccountId, DataSetId = DataSetId ) # delete Dashboard def DeleteDashboard(qs, AwsAccountId, DashboardId): qs.delete_dashboard( AwsAccountId = AwsAccountId, DashboardId = DashboardId ) # update Dashboard """ Permissionsを除き、qs.create_dashboardと同じ引数を利用。 引数に対応する値はqs.create_dashboardの際に指定した引数の値に等しい。 Nameのみを変更することでダッシュボード名を変更することが可能。 """ def UpdateDashboardName( qs, AwsAccountId, DashboardId, DataSetId1, DataSetPlaceholder1, DataSetId2, DataSetPlaceholder2, NewDashboardName, TemplateId ): update_dashboard_info = qs.update_dashboard( AwsAccountId = AwsAccountId, DashboardId = DashboardId, Name = NewDashboardName, SourceEntity = { 'SourceTemplate': { 'DataSetReferences': [ { 'DataSetPlaceholder': DataSetPlaceholder1, 'DataSetArn': 'arn:aws:quicksight:{}:{}:dataset/{}'.format(Region, AwsAccountId, DataSetId1) }, { 'DataSetPlaceholder': DataSetPlaceholder2, 'DataSetArn': 'arn:aws:quicksight:{}:{}:dataset/{}'.format(Region, AwsAccountId, DataSetId2) }, ], 'Arn': 'arn:aws:quicksight:{}:{}:template/{}'.format(Region, AwsAccountId, TemplateId) } }, # VersionDescription = '15', ) return update_dashboard_info # update Dashboard Published Version """ qs.update_dashboardでのダッシュボード名の変更を表示に反映。 ダッシュボード名が変更されたダッシュボードのバージョンナンバーをVersionNumberに設定。 qs.update_dashboardの返り値に含まれるバージョンナンバーを VersionArn = update_dashboard_info['VersionArn'] target = '/version/' idx = VersionArn.find(target) version_str = VersionArn[idx + len(target):] VersionNumber = int(version_str) のように取得することが可能。 """ def UpdateDashboardPublishedVersion (AwsAccountId, DashboardId, VersionNumber): qs.update_dashboard_published_version( AwsAccountId = AwsAccountId, DashboardId = DashboardId, VersionNumber = VersionNumber ) User # register User """ IdentityType = 'IAM'として登録されたユーザはパスワードを入力せずにEmbed URLからダッシュボードやコンソールのページを表示することが可能。 QuickSightに登録されるユーザ名はIamArnとSessionNameから成る。 IamArn = 'arn:aws:iam::{}:role/<Role>'.format(AWS_ACCOUNT_ID), SessionName = 'TestUser'として設定した場合の QuickSightに登録されるユーザ名は'<Role>/TestUser'。 登録するユーザが属している組織のIDをOrganizationListを指定することで、組織IDに等しいグループ名のグループがQuickSightに存在していれば グループに作成したユーザを追加。 """ def RegisterUser(qs, AwsAccountId, Email, IamArn, RegisterUserName, Namespace, qsUserName, UserList, OrganizationList): if qsUserName not in UserList: result = qs.register_user( IdentityType = 'IAM', Email = Email, UserRole = 'READER', IamArn = IamArn, SessionName = RegisterUserName, AwsAccountId = AwsAccountId, Namespace = Namespace, CustomPermissionsName = 'DataExplorer' ) if result['Status'] == 201: if OrganizationList != []: for GroupName in OrganizationList: qs.create_group_membership( MemberName = qsUserName, GroupName = GroupName, AwsAccountId = AwsAccountId, Namespace = Namespace ) else: logger.debug('The organization that {} belongs to does not exist in QuickSight.'.format(qsUserName)) # log else: logger.debug('User {} creation failed'.format(qsUserName)) # log else: logger.debug('User {} already exists'.format(qsUserName)) # log # delete User def DeleteUser(qs, AwsAccountId, qsUserName, Namespace): qs.delete_user( UserName = qsUserName, AwsAccountId = AwsAccountId, Namespace = Namespace ) # update User permission for dashboard def CreateGroupMembership(qs, AwsAccountId, qsUserName, GroupName, Namespace): qs.create_group_membership( MemberName = qsUserName, GroupName = GroupName, AwsAccountId = AwsAccountId, Namespace = Namespace ) # update User permission for dashboard def DeleteGroupMembership(qs, AwsAccountId, qsUserName, GroupName, Namespace): qs.delete_group_membership( MemberName = qsUserName, GroupName = GroupName, AwsAccountId = AwsAccountId, Namespace = Namespace ) まとめ 実際に開発を行う場合にはAPI仕様書や詳細設計書、シーケンス図の作成、DB設計などを行い、AWSであれば必要に応じてセキュリティグループやサブネットを設定、デプロイはserverless frameworkを利用しGitHubでソースコードのバージョン管理を行うなどの流れがありますが、ここではQuickSightに対して処理を行うPythonの関数を載せてみました。 認識の間違いなどありましたらご指摘のほどよろしくお願いいたします。

はじめに 最近、Amazon Elasticsearch Serivce(以下、Elasticsearch)を使う機会があるんですが、障害が発生したときに太刀打ち出来ないと感じたので対応方法を調べました。 今回は、AWSが推奨しているアラームが発生したことを想定して対応方法を考えます。(と言いつつドキュメントに書いてあることをまとめるだけです。) Amazon ElasticsearCloudWatch Service の推奨アラーム - Amazon Elasticsearch Service Elasticsearchの物理的な概念 Elasticsearchの物理的な概念を把握出来ていないとドキュメントを読み解くことが出来ないので、自分の理解出来ている範囲で説明します。すでに把握されている方は飛ばしてください。 全体図 クラスター Elasticsearchでは複数のノード(≒サーバ)を起動するとデータを分散して保持します。 この、ノードグループのことをクラスターと呼びます。 ノード Elasticsearchが起動しているサーバのことをノードと呼びます。 以下のコマンドを実行するとノードリストを確認出来ます。 terminal $ curl -XGET 'http://{ESのエンドポイント}/_cat/nodes?v' ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name 172.23.0.2 43 96 0 0.14 0.06 0.01 mdi * ****** Elasticsearchにはいくつかのノードが存在します。1つのノードで複数の役割を担うことも出来ますが、基本的に専用のノードとして役割を持ちます。 今回は、マスターノードとデータノードについて説明します。 マスターノード マスターノードとはクラスター管理を行うノードです。クラスター1つにつき、1つ以上のマスターノードを持つ必要があります。 マスターノードは以下の役割を持ちます。 ノードの管理 全ノードに対してpingを送って生死を確認する シャードの割当と再配置 新しいシャードの割当や、既存のシャードの再配置を行う マスターノードが停止するとクラスター自体が停止してしまいます。 そのため、可用性を高めるために候補となるノードを3台以上の奇数で設定することが推奨されています。(偶数台で構成する場合はスプリットブレインが起きる可能性があります。解説は省略します。) また、CPU使用率が50%を超えたタイミングでスケールアップすることが推奨されています。 データノード データの格納、クエリへの応答、インデックスのマージを行います。 シャード Elasticsearchではインデックスのデータを分割してノードごとに分散保持することが出来ます。 この、分散保持した部分をシャードと呼びます。 インデックスとはElasticsearchにおける論理的な概念です。RDBでいうとデータベースに相当します。 レプリカシャード ノードの可用性を高めるために、各シャードを自動的に複製する仕組みがあります。この複製されたシャードのことをレプリカシャードと呼びます。 一方で、元となるオリジナルのシャードをプライマリシャードと呼びます。 AWSの推奨アラームに対する対応 本編です。AWSの推奨アラームへの対応方法をまとめます。 Amazon ElasticsearCloudWatch Service の推奨アラーム - Amazon Elasticsearch Service クラスターのステータスが赤色 概要 1つ以上のプライマリーシャードとそのレプリカシャードがノードに割り当てられないことを意味します。 割り当てられない原因の多くは、高負荷によってノードが使用不可能になることです。 アラーム ClusterStatus.red maximum is >= 1 for 1 minute, 1 consecutive time 解消方法 まずはクラスターのステータスを緑色に戻すことを目指します。そのための最速の方法は赤色のインデックスを削除することです。 GET _cat/indicesでインデックスごとの、ステータスを確認で出来ます。 terminal $ curl -i -X GET 'http://{ESのエンドポイント}/_cat/indices?v' HTTP/1.1 200 OK content-type: text/plain; charset=UTF-8 content-length: 412 health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open .kibana 1Fe90g7sQ-e_3oWm_85-TQ 1 0 3 1 14.5kb 14.5kb green open index-1 3D-wOa8GQA-WSks-_jaKMg 5 1 2 0 8.2kb 8.2kb red open index-2 glQcO_fXRrmV7zZcGXE-2A 5 1 2 0 11.2kb 11.2kb 次に、DELETE /{インデックス名}を使用することでインデックスを削除することが出来ます。 terminal $ curl -XDELETE 'http://{ESのエンドポイント}/{index-2}' {"acknowledged":true} これでステータスは緑色になるはずです。 インデックスを削除出来ない場合 スナップショットを復元する 別のクラスターに向き先を変える 他のインデックスを削除してディスク容量を解放する などの選択肢もあるようです。 スナップショットの復元方法は以下に記述されているので、必要であれば御覧ください。 Amazon Elasticsearch Serviceでスナップショットを復元する方法 - Qiita その他役立つ情報 シャードが割当できない原因の特定 GET _cluster/allocation/explainを使用することで、シャードが割り当てられない原因を調べることが出来ます。 今回の例は、1ノード構成でレプリカシャードが割り当てられずyellowになっていましたが、explanationに原因が記述されていました。 terminal $ curl -i -X GET 'http://{ESのエンドポイント}/_cluster/allocation/explain?pretty' HTTP/1.1 200 OK content-type: application/json; charset=UTF-8 content-length: 1081 { "index" : "library", "shard" : 1, ...(省略) "allocate_explanation" : "cannot allocate because allocation is not permitted to any of the nodes", "node_allocation_decisions" : [ { "node_id" : "EUZFjPJQSZyLSXaziAJmRw", ...(省略) "node_decision" : "no", "deciders" : [ { "decider" : "same_shard", "decision" : "NO", "explanation" : "the shard cannot be allocated to the same node on which a copy of the shard already exists [[library][1], node[EUZFjPJQSZyLSXaziAJmRw], [P], s[STARTED], a[id=a-p0n6XoSlqmBMIr2LD5Vw]]" } ] } ] } 負荷の確認 クラスター障害の原因が高負荷によるものかを判断するときは以下のメトリクスを確認します。 JVMMemoryPressure CPUUtilization ノード数 必要によって、スケールアップやスケールアウトを行います。 クラスターのステータスが黄色 概要 1つ以上のレプリカシャードがノードに割り当てられないことを意味します。 1ノード構成の場合は、レプリカシャードを割り当てるノードが無いためスタータスは黄色になります。1ノード構成ではない場合は、赤色の場合と同様の原因になります。 アラーム ClusterStatus.yellow maximum is >= 1 for 1 minute, 1 consecutive time 解消方法 1ノード構成の場合は、レプリカシャードを削除する、もしくは2ノード以上の構成にしてください。 空きストレージ容量の不足 概要 シャードの移動に必要なストレージ領域を持つノードが無ければ、それ以降のドキュメントの追加やインデックスの作成に失敗する可能性があります。 そのため、各ノードのストレージ容量の25%を下回った段階でアラームを出すことが推奨されています。 アラーム FreeStorageSpace minimum is <= 20480 for 1 minute, 1 consecutive time 解消方法 解消方法としては、以下のアプローチがあります。 インデックスを削除してストレージ領域を解放する より大きなEBSをアタッチする インスタンスタイプごとにアタッチ出来るEBSのサイズが決まっている Amazon Elasticsearch Service - Amazon Elasticsearch Service 必要であればインスタンスタイプを変更する 高いCPU使用率が継続するとき 概要 ノードのCPU使用率が一時的に100%になることは珍しくありません。 しかし、CPU使用率が高い状態が継続するときには解消する必要があります。 アラーム CPUUtilizationまたはWarmCPUUtilizationmaximum is >= 80% for 15 minutes, 3 consecutive times 解消方法 より大規模なインスタンスタイプのノードを使用するか、ノードの追加を行います。 メモリ使用率増加 概要 メモリ使用率が増加している状態です。 アラーム JVMMemoryPressureまたはWarmJVMMemoryPressuremaximum is >= 80% for 5 minutes, 3 consecutive times 解消方法 より大規模なインスタンスタイプに変更します。 64MBのメモリを使用しても改善しないときはノードの追加を行います。 マスターノードのCPU使用率とメモリ使用率の増加 概要 マスターノードのCPU使用率とメモリ使用率が増加しています。 マスターノードが停止してしまうとクラスター全体の機能が停止してしまうので、50%のCPU使用率でアラームを出すことが推奨されています。 アラーム MasterCPUUtilization maximum is >= 50% for 15 minutes, 3 consecutive times MasterJVMMemoryPressure maximum is >= 80% for 15 minutes, 1 consecutive time 解消方法 より大規模なインスタンスタイプの専用マスターノードを使用します。 最後に 今回は、Elasticsearchで障害が起きた時の対応方法を調べました。 まだまだ運用経験が不足しているので、ノウハウが溜まり次第記事の更新をしていきます。 内容が間違っているなどありましたらコメントをお願いいたします。閲覧ありがとうございました！ 参考 Amazon ElasticsearCloudWatch Service の推奨アラーム - Amazon Elasticsearch Service Amazon Elasticsearch Service - Amazon Elasticsearch Service

はじめに 今回は Amazon Client VPN を試します。 AWSドキュメントのクライアント VPN の開始方法 の手順で進めました。 準備 少なくとも1つのサブネットとインターネットゲートウェイを持つVPCの準備。 今回は CloudFormation を利用し、準備しました。 使用したテンプレートはGithubに。 サーバーおよびクライアント証明書とキーの生成 AWSドキュメントの相互認証の手順に沿って生成しました。 クライアント VPN エンドポイントを作成する Amazon VPC コンソール から クライアント VPN エンドポイントを作成する 各証明書のARNを指定 クライアントの VPN 接続を有効にする Amazon VPC コンソール から 関連付けを選択 関連付けるVPC、サブネットを指定 クライアントのネットワークへのアクセスを承認する Amazon VPC コンソール から 受信の承認を選択 アクセスを許可するネットワークの CIDR を入力 クライアント VPN エンドポイント設定ファイルをダウンロードする Amazon VPC コンソール から 設定ファイルをダウンロード クライアント VPN エンドポイントに接続する AWS Client VPN downloadから AWS が提供するクライアントをダウンロードし、設定ファイルを指定して接続しました。 接続履歴の確認 Amazon VPC コンソール から 接続タブを選択 終わりに Amazon Client VPN を試しました。 サイト間のVPN ( AWS Site-to-Site VPN ) も今後試してきたいと思います。 参考資料 AWS Client VPN とは?

今回の記事について この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com 前回の続き 前回の記事の続きになります。 前回作成した環境に構築していきますので、まずはこちらをご覧ください。 今回やること ・起動テンプレートの作成 ・ELBの配下にAutoScalingGroupを紐付ける ・CloudWatchでAutoScalingのCPU使用率を監視するアラームの作成 （CPU使用率７０％以上、CPU使用率３０％以下） ・作成したアラームとAutoScalingのスケーリングポリシーを紐づける ・検証（意図的にEC2のCPUに負荷をかけてAutoScalingによりEC2が増減するか確認） 環境 macOS Big Sur バージョン１１.２.２ 構成図 起動テンプレートの作成（AutoScalingで起動するEC２インスタンスの設定） ＊起動設定でも出来ますが、Amazonは起動テンプレートの利用を推奨しているようです。 EC2コンソールを開き、左ペインからテンプレートの起動を選択 ↓ 起動テンプレートを作成 起動テンプレート名：　LaunchTemplate1　（任意の名前） テンプレートバージョンの説明：1.0.0 （任意） AutoScalingのガイダンス: このテンプレートをAutoScalingで使用するのでチェックを入れる AMI：以前のハンズオンで作成しているEC2を設定 インスタンスタイプ：検証用であれば無料枠でOK キーペア：すでに作成してあるものを使用 セキュリティグループ：後で設定するのでここでは空白でOK リソースタグ：リソースタイプをインスタンスに設定すると、AutoScalingによって立ち上がったインスタンスにタグ付けできる ネットワークインターフェイスの設定 セキュリティグループ：既存のEC2に紐付けているものと同じSGを選択 パブリックIPの自動割り当て：有効化 他デフォルトで起動テンプレートの作成 ＊ちなみに既存のEC2を選択してアクション→イメージとテンプレート→インスタンスからテンプレートを作成から簡単に作れます。 ELBの配下にAutoScalingGroupを紐付ける 前回までのハンズオンで作成したEC2２台を停止しておく。RDSは起動してる状態。 AutoScalingGroupの作成 ステップ１　起動テンプレートまたは起動設定を選択する Auto-Scaling　グループ名：Test-AutoScaling1　（任意） 起動テンプレート：先ほど作成した起動テンプレートを設定 ステップ２ 設定の構成 インスタンスの購入オプション：起動テンプレートに準拠する VPC、サブネット選択 （今回の場合、パブリックサブネット２つ選択） ステップ３ 詳細オプションを設定 ロードバランシング：前回までのハンズオンで作成したELBのターゲットグループを設定 ヘルスチェック：ヘルスチェックのタイプをELBにチェックを入れる その他の設定（モニタリング）：後で変更できるのでひとまず飛ばして次へ進む ステップ４ グループサイズとスケーリングポリシーを設定する 希望する容量：2 (任意) 最小キャパシティ：2 (任意) 最大キャパシティ：4 (任意) スケーリングポリシー：後から設定するのでひとまず飛ばして次へ ステップ５ 通知を追加 AutoScaling内のEC２が起動、終了するたびに、SNSなどで通知が欲しければ設定する ステップ６ タグを追加 任意で設定 ステップ７ 確認 確認して問題なければ作成 ＊作成後、現在EC2を２台とも停止してるので、AutoScalingで設定した希望する容量２台を維持するために、起動テンプレートで設定した２台のEC2インスタンスが新しく起動される。 CloudWatchでAutoScalingのCPU使用率を監視するアラームの作成 作成するアラーム ・CPU使用率が７０％以上になった場合に起動するアラーム ・CPU使用率が３０％以下になった場合に起動するアラーム 早速、CloudWatchコンソール画面で、アラームの作成を選択 ステップ１　メトリクスと条件の指定 メトリクスの選択⇨EC2⇨AutoScalingグループ別⇨先ほど作成したAutoScalingのCPU Utilization⇨メトリクスの選択 統計：平均値 期間：５分（デフォルト） しきい値の種類：静的 アラーム定義：７０　より大きい その他の設定：欠落したデータを不正（しきい値を超えている）として処理 ＊CPU使用率が極端に高まると、EC２がCloudWatchにメトリクスを送れないと予想されるから ステップ２　アクションの設定 SNSトピックで作成したメールアドレス宛に通知が届く設定 （SNSトピックを作成してなければ作成する） ステップ３　名前と説明を追加 アラーム名：CPU_high（任意） ステップ４　プレビューと作成 確認して問題なければ作成 ＊省略 もう一つのアラーム（CPU使用率３０％以下）も同じように作成しましょう。 （設定） アラーム定義：３０　より小さい その他の設定：欠落データを見つかりませんとして処理 アラーム名：CPU＿low（任意） ＊設定後のステータス CPU＿high　OK CPU＿low アラーム状態 となっていることを確認する 作成したアラームとAutoScalingのスケーリングポリシーを紐づける 作成したAutoScalingのタブ⇨自動AutoScaling⇨スケーリングポリシー⇨ポリシーを追加 ポリシータイプ：シンプルなスケーリング スケーリングポリシー名：CPU＿add（CPU_remove） CloudWatchアラーム：CPU＿high(CPU_low) アクションを実行：追加(削除)　１　キャパシティユニット スケーリングアクティビティを許可するまでの秒数：３０（任意） highとlowのスケーリングポリシーをそれぞれ作成する これでアラームに応じてAutoScalingによるEC2インスタンスが増減する仕組みができた。 検証（意図的にEC2のCPUに負荷をかけてAutoScalingによりEC2が増減するか確認） ・どちらか片方のEC2インスタンスへssh接続する ・EC2インスタンスに負荷をかける 負荷をかけるコマンド：yes >> /dev/null & ＊４つほど実行する ・Linuxサーバーの負荷を確認する Linuxサーバーの負荷を確認するコマンド：topでCPU使用率を確認できる （抜けるにはctrl+c） ＊もう一つのインスタンスでも同じように負荷をかける しばらくしてAutoScalingのグラフを確認するとCPU使用率が高まってるのが確認できる また、設定したCloudWatchアラームのCPU＿highもアラームになってるのがわかる さらに、EC2インスタンスが新しく立ち上がっているのが確認できるはず （AutoScalingグループのアクティビティログでも確認できる） ＊負荷がかかってる以上、設定した最大インスタンス数までインスタンスが立ち上がる 負荷を戻す 再びインスタンスに戻り、先ほど負荷をかけたyesコマンドをkillする kill プロセスIDで負荷を解除できる ＊kill {3974..3977}とすれば複数のIDをまとめて解除できる 最後にtopコマンドでCPU使用率が０％になっていることを確認 ＊もう一つのインスタンスでも同じように解除する しばらくするとCPU使用率が３０％を下回り、インスタンスが削除される動きになるが、ELBのConnection drainingの設定（デフォルトで３００秒後）により、その時間経過後に削除される。 ＊ELBのConnection drainingとは ELBから何らかの理由（障害など）でEC2が切り離されると、設定した時間経過後にEC2が削除される。 急に削除するとサーバーを使用しているユーザーに迷惑がかかるためこの機能がある。 （AWS SAAやSOAの資格試験にも出ます）（１〜３６００秒の間で設定可能） 最終的に希望の容量（EC2インスタンス２台）に戻ってれば今回のハンズオンは終了。 お疲れ様でした。

前回までのあらすじ はじめに Azure Fundamentals AI に合格した7月9日から約3週間 DOP を目指して1週間勉強してみたものの、いまいち頭に入らなかった さらに横道にそれて AWS 認定データアナリティクス（DAS）取得へ目標をシフトしたのであった 本記事はどのように勉強したかと、その感想をまとめたものです （次回、資格更新時参考にできればよいなと思っている次第） データアナリティクス（DAS）とは HP の説明 この資格試験では、AWS データレイクおよび分析サービスの専門知識を検証します。効率的で費用対効果が高く、安全な分析ソリューションを AWS で設計、構築、保護、および維持する能力を強調して、信用を獲得し、信頼関係を構築しましょう。データから、幅広く、深い洞察を提供することができることを示します。 推奨される知識と経験 データ分析テクノロジー分野における最低 5 年間の経験 AWS を使う実践的な業務における、最低 2 年間の経験 AWS のサービスを使用して分析ソリューションを設計、構築、保護、および保守する経験および専門知識 引用：https://aws.amazon.com/jp/certification/certified-data-analytics-specialty/ つまり？ AWS のサービスを利用してデータ解析するための知識を持っているかを問うような問題がわんさか出てくる ただ、あくまでサービスについて問われるケースが多いので、分析の事細かい知識はなくても問題は解ける（はず） 学習教材 aws WEB問題集で学習しよう DVA を取得するために、プロフェッショナルを登録していたこともあり、こちらの問題集を引き続き使用しました 今見たらベーシックでデベロッパーアソシエイトまでサポートされるようになっているだと・・・ Udemy こちらの問題集を機械翻訳にかけて勉強してました 勉強期間と方法 学習期間 2週間 学習方法 WEB 問題集の問題集は#21(147問)しかないので、大体1周を3日ぐらいで実施する 合っていた問題、間違っていた問題の解説を読み込む 書かれているリンクも見ておいたほうが良いかも？ 2周目を残り4日ぐらいで実施しながら、本番試験モードも受ける 模擬試験を受ける 私は6割ぐらいしか取れなかったので↓を追加した Udemy の問題集をやって2番目の本試験問題以外を1日で一通り解く わからなかったところは解説をよく読む Udemy の問題集2番目の問題を実施する 一通りの解説は読んで理解を深める 残りの期間は Udemy を一通り2周しながら、WEB 問題集を1～2周する 試験1日前になったら以下のページの表を翻訳しながら読んで、表の組み合わせを理解できていることを確認する https://tutorialsdojo.com/aws-certified-data-analytics-specialty-exam-study-path/ 学習内容と試験の差 各教材で9割近く点数を取得できるぐらい理解を深めた つもり だった しかし、本試験はさらに深く角度の違った問いをしてくることが多い印象を受けた 上記の学習が無駄だったかというとそうではなく、何割かは得た知識で対応できるし知識を応用すれば半分は自信を持って解けると思う ただ試験を受けるときに感じた障壁として以下があげられる 文章がそこそこ長い問題が8割弱でた 休憩時間なし3時間一本勝負 ぶっ通しで3時間を越える試験は初めて受けたが、2時間で1周して、見直し30分と時間に余裕のない試験運びとなった 見直ししているときは集中力が切れていたので、2時間問題に取り組み続ける必要があったのは結構危うい状態だった 本試験に挑む前に実施しておいたほうがよいのは、WEB問題集の本試験問題とUdemyの本試験問題を試験時間以内に余裕をもって解けるようになること WEB問題集の本試験問題は3回か4回ほど実施した 本試験問題は1時間ぐらいで解けるのが理想に思う => 本試験は問題の質が異なるように感じやすく、知識と文章を落とし込むのに時間を消費するため焦りにつながる ついでに言うならば、午前中に試験を設定して、前日は早めの睡眠、朝食は少なめにだがしっかり取って万全の状態で受けるのがよい 試験結果 色々語ったが、スコアは789点 750点がボーダーラインなのでギリギリでした 採点ボタンを押したとき7割落ちたと思って押したので、受かっていたのが奇跡に近い 感覚値で言うと、1～2割全く小手先の知識では求められないわからない問題があった（WEB問題集とUdemyで被らない感じの問題） ノリで勉強している筆者からすると、8割を地力と運（2択）でもぎ取る資格でした 感覚にはなるが、付け焼刃の知識で5割は取れるが3割は運によるものという感想 とはいえ、筆者酒飲みながら勉強するのが常なので、個人差 があるでしょう（山崎12年手に入れたのでいつ開けようかと審議中、、、飴鞭大事） 「WEB問題で学習しよう」の合格記を参考にするのはありだと思う反面 基本的にその人の地力がかなり左右している感を感じたが、「WEB問題で学習しよう」のみ勉強していた人で8割超えた人がいないように見えるので、机上の勉強だけだと実力と運が混ぜ合わさって試験を受ける感じになるのかな？って思った 最後に 三度目の正直で DOP を目指すか、機械学習、セキュリティのどちらかを目指すのもありかも？と思っている 問題は DAS も機械学習も業務に全く関係ないので、勉強しているとき、どこを目指しているんだろうと日々思うようになるぐらい セキュリティもフロントエンドエンジニアだと、そこまで触ることがないので、結局役に立つのだろうか とはいえ知らないことを知るのは楽しい ただ資格を取得するとき実際のサービスは一切触ってないので、どの口が言っているんだと思ったりする とはいえ資格取得＝勉強すれば取得できる可能性が高いと考えれば、取得ハードルは結構下がるのではないでしょうか？この記事が参考になれば幸いです （ちなみに、この記事はイチローズモルトを飲みながら仕上げ部分を書いています）

前回までのあらすじ はじめに 前回の Azure Fundamentals AI を合格した7月9日から、約3週間勉強していなかったわけではなありません DOP を目指して1週間勉強してみたものの、いまいち頭に入らなかった なので、さらに横道にそれて AWS 認定データアナリティクス（DAS）取得と目標をシフトしてみました データアナリティクス（DAS）とは HP の説明 この資格試験では、AWS データレイクおよび分析サービスの専門知識を検証します。効率的で費用対効果が高く、安全な分析ソリューションを AWS で設計、構築、保護、および維持する能力を強調して、信用を獲得し、信頼関係を構築しましょう。データから、幅広く、深い洞察を提供することができることを示します。 推奨される知識と経験 データ分析テクノロジー分野における最低 5 年間の経験 AWS を使う実践的な業務における、最低 2 年間の経験 AWS のサービスを使用して分析ソリューションを設計、構築、保護、および保守する経験および専門知識 引用：https://aws.amazon.com/jp/certification/certified-data-analytics-specialty/ つまり？ AWS のサービスを利用してデータ解析するための知識を持っているかを問うような問題がわんさか出てくる ただ、あくまでサービスについて問われるケースが多いので、分析の事細かい知識はなくても問題は解ける 詳細は後記 学習教材 aws WEB問題集で学習しよう DVA を取得するために、プロフェッショナルを登録していたこともあり、こちらの問題集を引き続き使用しました 今見たらベーシックでデベロッパーアソシエイトまでサポートされるようになっているだと・・・ Udemy こちらの問題集を機械翻訳にかけて勉強してました 勉強期間と方法 学習期間 2週間 学習方法 WEB 問題集の問題集は#21(147問)しかないので、大体1周を3日ぐらいで実施する 合っていた問題、間違っていた問題の解説を読み込む 書かれているリンクも見ておいたほうが良いかも？ 2周目を残り4日ぐらいで実施しながら、本番試験モードも受ける 模擬試験を受ける 私は6割ぐらいしか取れなかったので↓を追加した Udemy の問題集をやって2番目の本試験問題以外を1日で一通り解く わからなかったところは解説をよく読む Udemy の問題集2番目の問題を実施する 一通りの解説は読んで理解を深める 残りの期間は Udemy を一通り2周しながら、WEB 問題集を1～2周する 試験1日前になったら以下のページの表を翻訳しながら読んで、表の組み合わせを理解できていることを確認する https://tutorialsdojo.com/aws-certified-data-analytics-specialty-exam-study-path/ 学習内容と試験の差 9割近く点数を取得できるぐらい理解を深めた つもり だった しかし、本試験はさらに深く角度の違った問いをしてくることが多い印象を受けた 上記の学習が無駄だったかというとそうではなく、何割かは得た知識で対応できるし知識を応用すれば合格ラインぐらいはギリギリ届きそう ただ本試験の一番の問題として以下があげられる 文章がそこそこ長い問題が8割弱でた 休憩時間なし3時間一本勝負 ぶっ通しで3時間を越える試験は初めて受けたが、2時間で1周して、見直し30分と時間に余裕のない試験運びとなった 見直ししているときは集中力が切れていたので、2時間問題に取り組み続ける必要があったのは結構危うい状態だった 本試験に挑む前に実施しておいたほうがよいのは、WEB問題集の本試験問題とUdemyの本試験問題を試験時間以内に余裕をもって解けるようになること WEB問題集の本試験問題は3回か4回ほど実施したが、平均1時間ぐらいで解けるようになっておくこと => 本試験は問題の質が異なるように感じやすく、知識と文章を落とし込むのに時間を消費するため焦りにつながる ついでに言うならば、午前中に試験を設定して、前日は早めの睡眠、朝食は少なめにだがしっかり取って万全の状態で受けるのがよい 試験結果 色々語ったが、スコアは789点 750点がボーダーラインなのでギリギリでした 採点ボタンを押したとき7割落ちたと思って押したので、受かっていたのが奇跡に近い 感覚値で言うと、1～2割全く小手先の知識では求められないわからない問題があった（WEB問題集とUdemyで被らない感じの問題） ノリで勉強している筆者からすると、8割を地力と運（2択）でもぎ取る資格でした 感覚にはなるが、付け焼刃の知識で5割は取れるが3割は運によるものという感想 とはいえ、筆者酒飲みながら勉強するのが常なので、個人差 があるでしょう（山崎12年手に入れたのでいつ開けようかと審議中） 「WEB問題で学習しよう」の合格記を参考にするのはありだと思う反面 基本的にその人の地力がかなり左右している感を感じたが、「WEB問題で学習しよう」のみ勉強していた人で8割超えた人がいないように見えるので、机上の勉強だけだと実力と運が混ぜ合わさって試験を受ける感じになるのかな？って思った 最後に 三度目の正直で DOP を目指すか、機械学習、セキュリティのどちらかを目指すのもありかも？と思っている 問題は DAS も機械学習も業務に全く関係ないので、勉強しているとき、どこを目指しているんだろうと日々思うようになるぐらい セキュリティもフロントエンドエンジニアだと、そこまで触ることがないので、結局役に立つのだろうか とはいえ知らないことを知るのは楽しい ただ資格を取得するとき実際のサービスは一切触ってないので、どの口が言っているんだと思ったりする とはいえ資格取得＝勉強すれば取得できる可能性が高いと考えれば、取得ハードルは結構下がるのではないでしょうか？この記事が参考になれば幸いです （ちなみに、この記事はイチローズモルトを飲みながら仕上げ部分を書いています） すべてを打ち消す本心：9月4日まで「WEB問題で学習しよう」のアカウントの有効期限がある。それまでにあと1つぐらいは資格を取得して、残業代代わりに会社の資格報奨金を貰うのもありかなと思っている

本記事について 2021年7月26日 に、AWS-SOA試験（SOA-C01）に合格しました。 自分向けの備忘録と、勉強中の方への情報共有を兼ねて、私の勉強方法を記載します。 取得スコア 1,000 点満点で、959点でした。 期待以上の高得点で嬉しいです? 100 ～ 1000 点のスコアレンジのため、得点率としては、95.4%となります。 ※ (959-100) ÷ (1000-100) = 0.954 筆者の基本スペック SIer勤務の新卒4年目。経済学部卒。 企画系の部署が長く、開発や運用の経験は浅い。 約2年前から趣味でAWSを触りはじめる。（サーバレスがメイン） 4か月前から仕事でもAWSを触りはじめる。（EC2やコンテナなど） 9か月前にAWS-SAA試験に合格済み。 勉強方法 勉強時間 期間は4週間くらい、業務後や休日に勉強をしました。 AWS-DVA試験も同時に勉強しており、それを含めての1か月です。 ※ DVA試験の勉強方法については、こちらの投稿をご参照ください。 勉強方法 主に３つのツールを使いました。 ツール1：[Udemy] Ultimate AWS Certified SysOps Administrator Associate 2021 動画学習サイトの Udemy で提供されている、SOA のコースです。 ですが、動画は少ししか見ていません！！ こちらのコース、スライドを pdf でダウンロードできるため、スライドpdf を1週間かけて1週読みました。 これによって、基礎知識を習得します。　なお、動画は長くて飽きそうだったので少ししか見ませんでした? 実はこのコース、フランス生まれの方が作成した全編英語の講座です。 そのため、動画もスライドもすべて英語です?? と、言っても安心してください。スライドではそんなに難しい英語は使われていません。 （分からない部分は翻訳サイトを使えばOKです。） 広い範囲を網羅しており、説明も簡潔で分かりやすいスライドでした。 ※ 動画はリスニングが追い付かないため、難しく感じました。。。英語も勉強せねば? ツール2：[学習コンテンツ] AWS Hands-on for Beginners とてもオススメです。 AWS公式が提供している、ビギナー向けのハンズオンコンテンツです。 これらのうち、興味があるものをいくつか実践しました。実際に手を動かすことで各サービスの解像度が上がります。 SOA 試験においては、EC2 / VPC / CloudFormation のハンズオンなどを実施することで、書籍で分からなかった部分の理解ができました。 ※ ビギナー向けとされていますが、結構深掘りした内容もあり、試験勉強に限らず学びが多いです。 ツール3：[問題集] AWS WEB問題集で学習しよう（koiwaclub） Udemy のスライドpdf を一読した後は、AWS WEB問題集で学習しよう（koiwaclub）で問題慣れをしました。 SOAの問題すべて（7問×89セット）を、2週間かけて2週しました。 こちらは1週目は全ての問題に目を通し、2週目は間違えた問題や理解が浅い問題に絞って実施しました。 最初は間違える問題が多くて嫌になるのですが、だんだんと問題のレベル感のようなものが分かってきて、正答率が上がってきます。（照準が合ってくるイメージ） 中には解説がイマイチで、読んでも「？」なものも多いです。 そういう問題は時間をかけても無駄なので、答えの文章を覚えてしまうか、ネットで検索してわかりやすい解説記事などを探しました。 例えば AWS-KMS の CMK などは、ネット上のサービス解説記事を見たことで、理解が深まり問題も解けるようになりました。 試験本番 試験会場 新宿駅前テストセンター（Daiwa西新宿ビル）で受験をしました。 駅チカ & キレイなのでオススメです。 ※ AWSの試験は自宅受験も可能ですが、環境を整えるのが大変とのことで、テストセンターでの受験としました。 試験問題 問題集とほぼ同じ問題が3割近くありました。 他に基礎知識で難なく解けた問題が3割くらいでした。 残り4割のうち、約3割は選択肢に迷い、1割はお手上げでした。 時間経過 開始から50分くらいで一通り解き終わり、悩んだ問題を再考して終了としました。全体で60分くらいだったと思います。 自信を持って答えられない問題があったため、受験中は結構ドキドキしていたのですが、合格してよかったです。 難易度 主観ですが、難易度は、SOA ≦ DVA ≦ SAA と感じました。 これは、単純にSAAの方が試験範囲が広いためです。 Tips1 問題文や選択肢の日本語がおかしいときは、英語に切り替えた方が楽です。 難しい英語ではないので、おそらく読めます。 Tips2 SOA 試験に関しては、koiwaclub の WEB 問題集と全く同じ問題を多数見かけました。 そのため、解説を読んでも理解ができない問題については、問題と解答をそのまま覚えてしまうのもありかと思います。 (DVA 試験に関しては、WEB 問題集と同じ問題は少なかった気がします。) おまけ DVA試験の勉強方法についても記事を書きました。 以上です。 必ずしも、最適な勉強方法とは言えないかと思いますが、皆様のご参考になれば幸いです。

本記事について 2021年7月22日 に、AWS-DVA試験（DVA-C01）に合格しました。 自分向けの備忘録と、勉強中の方への情報共有を兼ねて、私の勉強方法を記載します。 取得スコア 1,000 点満点で、947点でした。 期待以上の高得点で嬉しいです? 100 ～ 1000 点のスコアレンジのため、得点率としては、94.1%となります。 ※ (947-100) ÷ (1000-100) = 0.941 筆者の基本スペック SIer勤務の新卒4年目。経済学部卒。 企画系の部署が長く、開発や運用の経験は浅い。 約2年前から趣味でAWSを触りはじめる。（サーバレスがメイン） 4か月前から仕事でもAWSを触りはじめる。（EC2やコンテナなど） 9か月前にAWS-SAA試験に合格済み。 勉強方法 勉強時間 期間は4週間くらい、業務後や休日に勉強をしました。 AWS-SOA試験も同時に勉強しており、それを含めての1か月です。 ※ SOA試験の勉強方法については、こちらの投稿をご参照ください。 勉強方法 主に３つのツールを使いました。 ツール1：[書籍] ポケットスタディ AWS認定デベロッパーアソシエイト 分かりやすくて良い本だと思います。 基礎知識をインプットすることを目的に、10日かけて2週しました。 1週目は全て目を通し、2週目では理解が浅いところや、1週目に解けなかった問題を中心に見直しました。 ツール2：[学習コンテンツ] AWS Hands-on for Beginners とてもオススメです。 AWS公式が提供している、ビギナー向けのハンズオンコンテンツです。 これらのうち、興味があるものをいくつか実践しました。実際に手を動かすことで各サービスの解像度が上がります。 DVA 試験においては、Code シリーズのハンズオンなどを実施することで、書籍で分からなかった部分の理解ができました。 ※ ビギナー向けとされていますが、結構深掘りした内容もあり、試験勉強に限らず学びが多いです。 ツール3：[問題集] AWS WEB問題集で学習しよう（koiwaclub） 書籍を2週した後は、AWS WEB問題集で学習しよう（koiwaclub）で問題慣れをしました。 DVAの問題すべて（7問×39セット）を、10日かけて2週しました。 こちらも1週目は全て目を通し、2週目は間違えた問題や理解が浅い問題に絞って実施しました。 最初は間違える問題が多くて嫌になるのですが、だんだんと問題のレベル感のようなものが分かってきて、正答率が上がってきます。（照準が合ってくるイメージ） 正直、DVAの問題集については解説がイマイチで、読んでも「？」なものが多かったです。 そういう問題は時間をかけても無駄なので、答えの文章を覚えてしまうか、ネットで検索してわかりやすい解説記事などを探しました。 例えば AWS-KMS の CMK などは、ネット上のサービス解説記事を見たことで、理解が深まり問題も解けるようになりました。 試験本番 試験会場 新宿駅前テストセンター（Daiwa西新宿ビル）で受験をしました。 駅チカ & キレイなのでオススメです。 ※ AWSの試験は自宅受験も可能ですが、環境を整えるのが大変とのことで、テストセンターでの受験としました。 試験問題 問題集とほぼ同じ問題は1割。 基礎知識で難なく解けた問題は6割くらいでした。 残り3割のうち、約2割は選択肢に迷い、1割はお手上げでした。 時間経過 開始から55分くらいで一通り解き終わり、悩んだ問題を再考して終了としました。全体で60分くらいだったと思います。 自信を持って答えられない問題があったため、受験中は結構ドキドキしていたのですが、合格してよかったです。 難易度 主観ですが、難易度は、SOA ≦ DVA ≦ SAA と感じました。 これは、単純にSAAの方が試験範囲が広いためです。 Tips 問題文や選択肢の日本語がおかしいときは、英語に切り替えた方が楽です。 難しい英語ではないので、おそらく読めます。 おまけ SOA試験の勉強方法についても記事を書きました。 以上です。 必ずしも、最適な勉強方法とは言えないかと思いますが、皆様のご参考になれば幸いです。

はじめに Route53でドメイン取得したものではS3静的サイト構築したことあったが、 外部ドメイン（お名前ドットコム）でやったことなかったので書いてみました。 ほとんど同じですが。。。 今回はあるコーポレートサイトをAWSへ移行した時の学びをアウトプットします。 NSレコード書き換えやMX、CNAMEレコード書き換えで混乱、失敗したのでこの点は注意が必要です（＾＾；） AWSリソース ・S3 ・Cloudfront ・Route53 ・Certificate Manager 以下のようなアーキテクチャー。 S3設定 バケット作成 ※今回はドメインを仮のyamato.comで表記してるので置き換えてください。 S3のstatic hosting機能を用いて構築します。 まずは指定ドメインでアクセスするには、 バケット名をドメインと同じ名前にする必要があります。 今回https://www.yamato.com(仮)でアクセスしたかったので、 バケット名をwww.yamato.comで作成します。 ※そうしないとRoute53からアクセスができない仕様のため 作成したらバケットにリソースを配置。 アクセス許可 配置したリソースを書くセス可能にするために設定します。 まずはアクセス許可のタブを選び以下のように設定します。 次にバケットポリシーを設定します。 編集ボタンを押し以下のように設定。 { "Version": "2012-10-17", "Statement": [ { "Sid": "PublicReadGetObject", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::www.yamato.com/*" } ] } これでどこからでも該当バケットへのGetObjectを許可していることになります。 静的ウェブサイトホスティング この機能を有効にする設定です。 プロパティタブから一番下にある静的ウェブサイトホスティングを有効にします。バケット作成時に有効にできます。 バケットウェブサイトエンドポイントとしてURLが表示されるのでここで正常に表示されるか確認できます。 Route53設定 Route53の画面でまずはホストゾーンを作成します。 よこのタブのホストゾーンを選択し、ホストゾーン作成ボタンを押します。 ドメイン名にyamato.comを指定します。 タイプはパブリックホストゾーンを選びます。 そしてホストゾーンの作成ボタンを押して作成。 作成すると一覧に表示され、ホストゾーンを選択するとレコードを作成できる画面が表示されます。 今回のドメインはyamato.comをお名前.comで取得していたため、お名前.com側でNSレコードをRoute53のものを設定します。（Route53に記載のNSレコード４つ） その場合はもともと設定してあったTXT、MX、CNAMEレコードは忘れずにRoute53側に設定してください。 レコード作成のボタンから作成できます。 ※注意 TXTレコードが複数ある場合はダブルクオーテーションで囲い一つにまとめて登録する。 MXレコードについて、サブドメインに@は不要です。 もともと＠が設定していたので、Route53側で＠を設定するとメールが使用できなくなりテンパリました＾＾； 空白でよいです。 S3向けのレコード作成 以下のように設定します。 レコード名にwww ルーティングポリシーはシングルルーティングのままで。 レコードタイプはAレコード ルーティング先にエイリアスを有効に 選択できるようになるのでS3ウェブサイトエンドポイントを選択。 リージョンは東京リージョンを選択。 エンドポイントを入力に作成したバケットが選択肢にでてくるので選択。 レコード作成のボタンを押して作成完了します。 ここまでの設定でHTTP通信で指定ドメインを用いてアクセスが可能になります。 http://www.yamato.comで正常に表示されるか確認。 次にSSL化（HTTPS通信）します。 Certificate Managerの設定 サービスからCertificate Managerを選択。 リージョンをバージニア北部を選択。（Cloudfrontへ証明書を登録するため） 証明書のプロビジョニングを選択。 パブリック証明書のリクエストを選択し、証明書のリクエストボタンを押す。 ドメイン名にwww.yamato.comと入力し次へ。 DNSの検証を選択し次へ。 タグ追加は任意。 最後確認で確定とリクエストボタンを押して作成。 以下のようにレコードタブを押して画面にでてくるRoute53でのレコードの追加のボタンを押します。 ※画像は発行済のため状況が発行済になってるが、実際は検証中となる。 問題なければ30分程度で発行されます。 発行されたらCloudfrontの設定へ。 Cloudfrontの設定 create distributionボタンを押して作成開始。 Origin domainに選択してS3を選ぶのではなく、静的ホスティング機能に記載のアクセス先を直接ペーストする。 詳細は以下のように設定。 HTTP only以外を選ぶとアクセスできないので注意。 Origin pathは空白のまま。 Origin nameは自動設定。 Viewer protocol policyはRedirect HTTP to HTTPSを選択。 （HTTP通信をHTTPS通信へリダイレクトする設定） Alternate domain name (CNAME) でadd itemを選択しwww.yamato.comと入力し、このアドレスでアクセスできるよう設定。 Custom SSL certificateで発行した証明書を選択。 該当ドメイン名で選択できる。 画面は以下のようになる。 create distributionボタンを押して作成する。 cloudfrontのstatusがenabledになったら、 Route53からCloudfrontへトラフィックするために最後に設定する。 Route53再設定 yamato.comのホストゾーンを選択し、 www.yamato.comのレコードにチェック入れると右側に編集画面がでるので編集ボタンを押す。 エイリアスの箇所でCloudfrontを選択。 リージョンは自動選択。 該当のCloudfrontを選択。IDを確認して間違えないように。 保存を押して編集を反映させます。 これで設定終了です。 https://www.yamato.comで問題なく表示されるか確認。 またHTTP通信でリダイレクトされるかも確認。 作業終了。 保守作業時の対応 S3のリソースを変える保守が発生した場合は、変更を反映させるためにCloudfrontのキャッシュをクリアします。 AWSサービスでCloudfrontを選択。 該当のIDを選択。 Invalidationsタブを選択。 create invalidationボタンを押す。 Add object pathsにワイルドカードを使用してすべてのキャッシュを削除を指定。 create invalidationボタンを押して完了。 アクセスして変更点が反映されているか確認。

はじめに AWSのStep Functionsを勉強するためにBlack Belt Online Seminerを視聴したので内容をまとめます。 背景 本記事はAWSソリューションアーキテクトプロフェッショナルに合格するために、Udemyの模擬試験を解いて分からなかった部分を勉強してまとめるものです。 試験対策用のため、分からない知識を補足したり試験で問われなさそうなところを省略したりしながらまとめています。 なるべくわかりやすい記載を心がけますが、最終目的は自己学習用であるということをご容赦ください。 目次 1. セミナーの内容 1.1. AWS Step Functionsとは 1.2. ステートマシン 1.3. データの入出力 1.4. Stateの記述 1.5. 実行状況の確認 1.6. 補足や料金詳細など 1.7. その他類似のサービスとの使い分け 2. おわりに 3. 用語集 セミナーの内容 AWS Step Functionsとは 分散アプリケーション・マイクロサービスの全体をステートマシンと呼ばれる仕組みでオーケストレートできる。 定義したステートマシーンはAWSコンソールからワークフローという形式で可視化できる。 ステートマシンの各ステップの実行履歴をログから追跡できる。(プロセスごとにログを管理できる) ステートマシン 複数のプロセスが連携し実現されている、入出力を用いて状態を遷移させるもの。 身近なステートマシンの例 自動販売機をステートマシンと考えると以下のプロセスに分割できる。 ステートマシンを構成する要素のことをStateと呼ぶ 入金待ち：入金まで待機、入金されたら金額を次のプロセスに伝える ジュースの選択：ジュースの選択まで待機、選択されたらジュース・釣銭を次のプロセスに伝える ジュース・釣銭の払い出し：受け取り口に払い出す。並列実行可能。 特徴 Step Functionsで作成したステートマシンは、複数種類を同時実行可能。Step Functionsを使わない場合にはインフラで管理したり、アプリを作りこんだりする必要がある。 ASL (Amazon States Language) と呼ばれるJSON形式の言語でワークフローを定義する。 ステートマシンの実行方法 Amazon CloudWatch Events: S3へのファイル保存やEC2の起動と言ったイベントを契機に実行 Amazon API Gateway : あるAPIが呼ばれた際のバックエンドとして実行 マネジメントコンソール : コンソールから手動で実行 AWS CLI : コマンドラインから実行 各種SDK : LambdaやEC2に実装したアプリケーションから実行 ステートマシンから呼び出し可能なAWSのサービス Lambda : 関数の実行 DynamoDB : 既存アイテムの取得、新規アイテムの登録 AWS Batch : ジョブの実行 Amazon ECS : ECS/Fargate タスクの事項 Amazon SNS : SNSトピックへのメッセージ送信 Amazon SQS : SQSキューへのメッセージ送信 AWS Glue : Glueジョブの実行 SageMaker: トレーニングジョブｍトランスフォームジョブの起動 Activity : 自身で定義したサービス Activity サーバやコンテナ等に実装したアプリケーションからポーリングすることで、独自の処理を実行する仕組み。（Step Functionsから任意のアプリケーションを実行する） アプリケーションはオンプレミスでもよい。 以下のようなフローで実行される。 独自に実装したアプリケーションからStep Functions を定期ポーリングする（ここではまだ応答がない） ステートマシンを実行する Activity の State に達するとポーリングに対して応答が返却される アプリケーションで処理を実行し、結果をステートマシンに通知する。 データの入出力 データは32768文字以内のJSON形式で以下の通りやり取りされる。 InputPathやParametersというフィールドでデータを入力 Stateで処理 ResultPathというフィールドにデータを出力 OutputPathで出力するフィールドを最終的なOutputとして出力 Stateの記述 ASLで下記のようなフィールドを指定する。 Comment : テキストでコメントを記載 StartAt : 一番最初に実行するステート TimeoutSeconds : ステートマシン全体のタイムアウト時間 Version : ASLのバージョン States : ステートマシンを構成するstateを指定。 本記事は試験対策用のものであるため、細かい記法については省略。 実行状況の確認 マネジメントコンソール画面からの確認方法だが、本記事は試験対策用のものであるため省略。 補足や料金詳細など 料金 状態遷移1,000回あたり$0.025(Tokyo Resion) 毎月4000回までは無料 リトライは追加の状態遷移として計算 主な制限 SLA : 99.9% ステートマシンの最大数 : 10,000/1アカウント 最大リクエストサイズ : 1MB その他類似のサービスとの使い分け Amazon Simple Que Service(SQS) マネージドなキューイングサービス ワークフロー自体の設定はできない サービス間のメッセージの管理に、スケーラブルで信頼性の高いキューが必要な場合はSQS 処理の追跡やサービス間のメッセージの受け渡しが必要であればStep Functions Amazon Simple WorkFlow Service(SWF) プログラミングベースでワークフロー制御を行うサービス。 複雑化するため、新規開発ではStep Functionsを使うことを検討し、満たせない要件があればSWFを検討 結果を親に返す子プロセスを起動する場合はAmazon SWFを利用 Step Functionsのユースケース 相互に依存するような複数の処理を組み合わせたい場合に最適 データプロセシング : 複数のデータストアを利用する分析や機械学習 eコマーズ : 在庫の追跡や注文処理 動画処理 : サムネイルの生成、ビデオのエンコーディング ワークフロー作成にはSWFではなくAWS Step Functions の利用が推奨されている おわりに 初投稿でした。 内容の誤りや著作権的にまずい箇所などあればご指摘いただけますと幸甚です。 アウトプットすると頭が整理されるし、ノートのように見返すことができるのでいいですね。 用語集 オーケストレート：システムやソフトウェア、サービスなどの構築、運用管理を自動化すること SDK:あるシステムに対応したソフトウェアを開発するために必要なプログラムや文書などをひとまとめにしたパッケージ

初めに 以下を参考に Fargate で ALB を設定する手順を確認しました。 Docker イメージを作成する この章は以下のドキュメントを参考にしています。 Node.js をインストールします。 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash . ~/.nvm/nvm.sh nvm install node package.json ファイルを作成します。 package.json { "name": "docker_web_app", "version": "1.0.0", "description": "Node.js on Docker", "author": "First Last <first.last@example.com>", "main": "server.js", "scripts": { "start": "node server.js" }, "dependencies": { "express": "^4.16.1" } } パッケージをインストールします。 npm install service.js を作成します。 service.js 'use strict'; const express = require('express'); // Constants const PORT = 8080; const HOST = '0.0.0.0'; // App const app = express(); app.get('/', (req, res) => { res.send('Hello World'); }); app.listen(PORT, HOST); console.log(`Running on http://${HOST}:${PORT}`); 動作確認をします。 node server.js Dockerfile を作成します。 Dockerfile FROM node:12 WORKDIR /usr/src/app COPY package*.json ./ RUN npm install COPY . . EXPOSE 8080 CMD [ "node", "server.js" ] .dockerignore ファイルを作成します。 .dockerignore node_modules npm-debug.log ビルドしてこのイメージを ECR にプッシュします。 docker build . -t test-user/node-web Fargate の設定 クラスターを作成する サービスで ECS を選択し、「クラスターの作成」をクリックします。 「ネットワーキングのみ」を選択します。 「クラスター名」を入力し、「作成」をクリックします。 タスク定義を作成する 左のナビゲーションペインから「タスク定義」を選択します。 「新しいタスク定義の作成」をクリックします。 「Fargate」を選択します。 タスク定義名を入力します。タスクロールは「なし」を選択します。 初めてタスク定義を作成する場合はタスクの実行ロールは「新しいロールの作成」、2 回目以降であれば「ecsTaskExecutionRole」などのタスク実行ロールを選択します。 タスクサイズを選択します。メモリは「0.5 GB」、vCPU は「0.25 vCPU」を選択します。 「コンテナの追加」をクリックします。 コンテナ名を入力し、イメージの入力部分に使用する ECR リポジトリの URI を貼り付けます。ポートはアプリケーションがリッスンするポート番号を入力します。その後、右下の「追加」をクリックします。 コンテナの追加完了後、下までスクロールし「作成」をクリックします。 ALB を作成する サービスで EC2 を選択し、左のナビゲーションペインから「ロードバランサー」をクリックします。その後「ロードバランサーの作成」をクリックします。 Application Load Balancer の「作成」をクリックします。 名前を入力し、スキームは「インターネット向け」を選択します。ロードバランサーのプロトコルは、今回は Fargate に ALB の設定をすることが目的なので HTTP を選択します。 アベイラビリティゾーンを選択します。 セキュリティ設定の構成では、先ほどの設定で HTTPS が選択されていないので、以下のメッセージが表示されます。「次の手順」をクリックします。 なお、HTTPS を選択している場合、ここで以下のようにサーバー証明書を選択します。 セキュリティポリシーは「ELBSecurityPolicy-2016-08」が推奨されています。 互換性のために ELBSecurityPolicy-2016-08 ポリシーをお勧めします。 セキュリティグループを選択します。 ターゲットグループを作成します。以下のドキュメントの注意に従ってターゲットの種類は IP を選択します。 重要 サービスのタスク定義で、awsvpc ネットワークモード (起動タイプが Fargate の場合に必要) が使用されている場合は、instance ではなく、ip をターゲットタイプとして選択する必要があります。これは、awsvpc ネットワークモードを使用するタスクは、Amazon EC2 インスタンスではなく、Elastic Network Interface に関連付けられているためです。 「次の手順」をクリックします。 何も設定せずに「次の手順」をクリックします。 確認画面で設定を確認し、「作成」をクリックします。 サービスを作成する 作成したクラスターを選択し、以下の「作成」をクリックします。 サービスの設定は以下のように行います。 デプロイメントは「ローリングアップデート」を選択し、「次のステップ」をクリックします。 VPC 、サブネット、セキュリティグループを選択します。パブリック IP の自動割り当ては「ENABLED」を選択します。パブリック IP の自動割り当てを「DISABLED」にすると、以下のエラーでイメージをプルできませんでした。 ResourceInitializationError: unable to pull secrets or registry auth: pull command failed: : signal: killed 今回はパブリックサブネットでタスクを実行するので、以下に記述があるようにアウトバウンドネットワークのためにパブリック IP が必要です。 パブリックサブネットで Fargate 起動タイプを使用してタスクを実行している場合は、タスクを起動する際、自動割り当てパブリック IP に [ENABLED] を選択します。これにより、イメージを取得するためのアウトバウンドネットワークアクセスをタスクに付与できます。 なお、パブリック IP を使用しない場合は、エンドポイントを使用することでプルが可能になります。詳細は以下のドキュメントに記載されています。 「Application Load Balancer」を選択し、先ほど作成した ALB を選択します。 「ロードバランサーに追加」をクリックします。 作成したターゲットグループ名を選択します。その後、下までスクロールし「次のステップ」をクリックします。 「次のステップ」をクリックします。次の確認画面では「サービスの作成」をクリックします。 タスクのステータスが RUNNING に変わったら、以下の ALB の DNS 名をブラウザの URL 部分に張り付けます。 以下のように表示されていることを確認します。 以下のようにロードバランサーのターゲットグループに実行タスクが追加されていることが確認できます。 参考記事

AWSのIoT Coreに接続するためには、証明書が必須と思っていましたが、カスタム認証を使うと、ユーザー名とパスワードで認証ができます。 証明書を使った認証は、IoT Coreが自動でやってくれますが、ユーザー名とパスワードによる認証の場合は、認証用のLambdaを作成して認証を行います。 ※図は公式ドキュメントからの引用です。 MQTT接続で行う場合には以下の制約があります。 接続ポートはMQTTSの8883ではなく443である必要がある ALPN拡張にMQTTの値を指定する必要がある オーソライザーを呼び出すには、MQTT とカスタム認証を使用して AWS IoT Core に接続するデバイスがポート 443 に接続する必要があります。また、mqtt の値を持つ Application Layer Protocol Negotiation (ALPN) TLS 拡張と、AWS IoT Core データエンドポイントのホスト名を持つ Server Name Indication (SNI) 拡張を渡す必要があります。 手順 カスタム認証用のLambdaの作成 公式ドキュメントのサンプルをそのまま使ってみます。 この例では、パスワードがtestだったら認証OKとなっています。 LambdaにはBase64エンコードされたパスワードが渡されるのでエンコードして使用します。 Lambda // A simple Lambda function for an authorizer. It demonstrates // how to parse an MQTT password and generate a response. exports.handler = function(event, context, callback) { var uname = event.protocolData.mqtt.username; var pwd = event.protocolData.mqtt.password; var buff = new Buffer(pwd, 'base64'); var passwd = buff.toString('ascii'); switch (passwd) { case 'test': callback(null, generateAuthResponse(passwd, 'Allow')); default: callback(null, generateAuthResponse(passwd, 'Deny')); } }; // Helper function to generate the authorization response. var generateAuthResponse = function(token, effect) { var authResponse = {}; authResponse.isAuthenticated = true; authResponse.principalId = 'TEST123'; var policyDocument = {}; policyDocument.Version = '2012-10-17'; policyDocument.Statement = []; var publishStatement = {}; var connectStatement = {}; connectStatement.Action = ["iot:Connect"]; connectStatement.Effect = effect; connectStatement.Resource = ["arn:aws:iot:us-east-1:123456789012:client/myClientName"]; publishStatement.Action = ["iot:Publish"]; publishStatement.Effect = effect; publishStatement.Resource = ["arn:aws:iot:us-east-1:123456789012:topic/telemetry/myClientName"]; policyDocument.Statement[0] = connectStatement; policyDocument.Statement[1] = publishStatement; authResponse.policyDocuments = [policyDocument]; authResponse.disconnectAfterInSeconds = 3600; authResponse.refreshAfterInSeconds = 300; return authResponse; } 認証がOKだった場合に、IoTポリシーを返却します。この例ではこのようなポリシーが返却されます。 クライアントIDがmyClientNameでのiot:Connectと、telemetry/myClientNameトピックへのiot:Publishが許可されます。 IoTポリシー { "Version": "2012-10-17", "Statement": [ { "Action": [ "iot:Connect" ], "Effect": "Allow", "Resource": [ "arn:aws:iot:us-east-1:123456789012:client/myClientName" ] }, { "Action": [ "iot:Publish" ], "Effect": "Allow", "Resource": [ "arn:aws:iot:us-east-1:123456789012:topic/telemetry/myClientName" ] } ] } カスタムオーソライザーの登録 IoT Coreのマネジメントコンソールを開き、左メニューのオーソライザーを選択します。 作成ボタンをクリックします。 名前をつけて、先程作成したLambdaを選択します。 トークンの検証は今回は有効にはせず、オーソライザーのアクティブ化にチェックを入れ、オーソライザーの作成ボタンをクリックします。 デフォルトのオーソライザーを登録 作成したオーソライザーが呼び出されるようにするには、デフォルトのオーソライザーの登録が必要です。 マネジメントコンソールからはできないようですので、CLIで行います。 AWSCLI aws iot set-default-authorizer --authorizer-name custom-authorizer これでAWS IoT Coreの設定は完了です。 接続するクライアントの作成 PahoクライアントのPython版を使います。 こちらのブログ記事を参考にしました。 pip install paho-mqtt ブログのものから、以下の項目を変更します。 IoT_protocol_nameをmqttに変更 証明書認証に関する部分をコメントアウト Publishするトピック名をtelemetry/myClientNameに変更 クライアントIDにmyClientNameを指定 username_pw_setでユーザー名とパスワードを指定 もちろんエンドポイントの変更も必要です。 from __future__ import print_function import sys import ssl import time import datetime import logging, traceback import paho.mqtt.client as mqtt IoT_protocol_name = "mqtt" ### 変更 aws_iot_endpoint = "AWS_IoT_ENDPOINT_HERE" # <random>.iot.<region>.amazonaws.com url = "https://{}".format(aws_iot_endpoint) # ca = "YOUR/ROOT/CA/PATH" ### 変更 # cert = "YOUR/DEVICE/CERT/PATH" ### 変更 # private = "YOUR/DEVICE/KEY/PATH" ### 変更 logger = logging.getLogger() logger.setLevel(logging.DEBUG) handler = logging.StreamHandler(sys.stdout) log_format = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s') handler.setFormatter(log_format) logger.addHandler(handler) def ssl_alpn(): try: #debug print opnessl version logger.info("open ssl version:{}".format(ssl.OPENSSL_VERSION)) ssl_context = ssl.create_default_context() ssl_context.set_alpn_protocols([IoT_protocol_name]) # ssl_context.load_verify_locations(cafile=ca) ### 変更 # ssl_context.load_cert_chain(certfile=cert, keyfile=private) ### 変更 return ssl_context except Exception as e: print("exception ssl_alpn()") raise e if __name__ == '__main__': topic = "telemetry/myClientName" ### 変更 try: mqttc = mqtt.Client(client_id='myClientName') ### 変更 ssl_context= ssl_alpn() mqttc.tls_set_context(context=ssl_context) mqttc.username_pw_set('username', 'test') ### 変更 logger.info("start connect") mqttc.connect(aws_iot_endpoint, port=443) logger.info("connect success") mqttc.loop_start() while True: now = datetime.datetime.now().strftime('%Y-%m-%dT%H:%M:%S') logger.info("try to publish:{}".format(now)) mqttc.publish(topic, now) time.sleep(1) except Exception as e: logger.error("exception main()") logger.error("e obj:{}".format(vars(e))) logger.error("message:{}".format(e.message)) traceback.print_exc(file=sys.stdout) 　接続テスト 無事にPublishできました。 パスワードが間違っていたり、クライアントIDやトピック名が許可されたもの以外の場合にPublishしたメッセージが届かないことも確認しました。

ポートフォリオ紹介 アプリ名: BookLike Github: https://github.com/tera487/book_like 概要 BookLikeは、本の気づきを共有、発見するSNSアプリです。 開発背景 大学生になってから、ビジネス本や自己啓発本を読むようになりました。本を読むことで、新しい発見やさまざまな考えを知ることができましたが、本を読んでもその本の知識を日常生活に生かしきれていませんでした。このことから、本の知識を自分の知識として吸収し、日常生活で活用することで読書をする意味があると思いました。 そこで本の内容をアウトプットすることで、「本の知識が定着し、日常生活に生かしやすいのでは？」と考えました。そして本の感想や気づきをアウトプットし、また他人の感想から新たな学びが生まれると思い、『BookLike』を開発しようと思いました。 使用技術 フロントエンド HTML/CSS JavaScript（jQuery） Bootstarp 5.0 バックエンド Ruby 2.6.6 Rails 6.1.4 Mysql 8.0.25 開発環境 Docker/Docker-compose MySQL 5.7 本番環境 AWS(VPC、EC2、RDS for MySQL、S3、ALB、 IAM、Route53） MySQL 5.7 CircleCI (CI/CD) その他 Rubocop(コード整形） Rspec（単体・統合テスト) レスポンシブ化 お名前.com（独自ドメインの取得） 実装機能 ユーザー関連 新規登録機能・登録情報編集機能（画像登録可能） ログイン機能 ゲストログイン機能 フォロー機能（非同期） 管理者関連 管理者情報編集機能 記事投稿・編集・削除 アカウント削除 投稿関連 新規投稿・編集・削除 いいね機能（非同期） 通報機能（非同期） 書籍関連 書籍検索機能（楽天APIの利用） 読んだ本一覧 ER図 インフラ構成図 工夫した点 UI/UX 本を読んでいる人にも読んでいない人に、手軽に使ってもらいたいと思い、簡単に使ってもらうにはどのように設計していけばいいか考えながら作成しました。 モダンな技術の使用 自動デプロイ 開発環境にDockerを使用 AWSにデプロイ CircleCIでCI/CDパイプラインの構築 今後の技術的課題 本番環境でのDockerコンテナの利用(ECS) Terraformでインフラをコード化 SPAでの開発(vue.js React) 反省点 ポートフォリオ作成 完璧に理解してからポートフォリオを作成しようと思い、技術書を購入し、繰り返し勉強をしていたため、ポートフォリオ作成が遅れてしまいました。ポートフォリオを作成することで、あいまいに覚えているところの復習や自分がわからないところがわかるようになると思います。なので、基本的な知識を身につけたらポートフォリオの情報収集・作成すべきだと思いました。 エラー対応 エラーをしてからの対応が良くなかったと思います。エラー内容を理解せずに、Googleにエラー文をコピーしてエラーを解決しようとしていました。そのため、余計に時間がかかることがありました。まず何がエラーをおこしているか確認し、エラーしている意味を理解してから、それに対しての対応を模索することがエラー解決の近道であると考えます。 最後に 最後までご覧いただき、ありがとうございました。 ポートフォリオを作成してみて、改めて自分はプログラミングが好きだと思いました。まだ実力不足ですが自分が考えたものが形になるのが面白いと思いました。今後は反省点を活かし、プログラミングに励んでいきたいと思います。

ストレージサービス Amazon Simple Storage Service（S3） 高耐久・大容量のオブジェクトストレージサービス データをオブジェクトとして扱い、IDとメタデータによって管理する バケットと呼ばれる単位で作成し、その中にオブジェクトを保管する 耐久性は99.999999999%に達するため、バックアップストレージとしても利用できる 利用した容量分の料金が発生する バケット名はグローバルで重複できない データの復元性と大規模災害対策に関するS3の機能 ◉誤ってデータを削除してしまった場合 バージョニング機能 オブジェクトの世代管理を提供する 設定に基づいて、以前の世代に戻すことができる バージョンはオブジェクト単位でバージョンIDで管理される 同名オブジェクトをアップロードすると標準で上書きされる バージョニング機能を有効化することで復元性は向上するが、その分のコストが発生する ◉大規模災害対策として クロスリージョンレプリケーション 別のリージョンのS3バケットにオブジェクトを自動複製する 複製先に別のAWSアカウントも指定可能 S3に保存したデータは、デフォルトで同じリージョン内の3ヶ所のAZに自動複製される S3におけるセキュリティ対策 ◉アクセス制御 ◎IAMポリシーによるアクセス制御 IAMユーザー／IAMロールからRead／Get／Put操作に対する制御が可能 ◎バケットポリシーによるアクセス制御 S3バケットにJSONコードを記載してバケット全体のアクセス制御が可能 ◎ACL（Access Control List）によるアクセス制御 S3バケットに対して、AWSアカウントレベルのアクセス制御を行う ACLからパブリックアスセスの設定を行い、不特定多数のユーザへファイル公開も可能 ◎ブロックパブリックアスセスによるアスセス制御 バケットポリシーやACLの設定に対して、一括で制限を設けることができる パケットポリシー／ACLによる制御はS3の各バケットやオブジェクトデータを監視しないと、意図せず外部に公開されてしまう可能性がある ◉暗号化 S3のデフォルトキーを使用したAES-256暗号化 AWS Key Management Service（KMS）で管理されている鍵によるAES-256暗号化 ユーザー任意の鍵によるAES-256暗号化 ・デフォルトキー／AWS KMSを利用した場合、AWS側で鍵の管理を行う ・ユーザー任意の鍵は、暗号化キーと暗号化したオブジェクトのマッピングはユーザーが管理する S3のコスト最適化 ◉ストレージクラスの種類 ユースケースに応じて利用形態を選択する ◎スタンダード デフォルトのストレージクラス 99.999999999%の高耐久性 ◎標準低頻度アクセス（Standard-Infrequent Access） スタンダードと同じ耐久性で低コストで利用可能なストレージ データの読み取りに対して課金される 長期保管やバックアップに利用される ◎1ゾーン低頻度アクセス（One Zone-Infrequent Access） 標準低頻度アクセスほど耐久性を必要としない場合に利用 1ヶ所のAZのみにデータ保存のため、標準低頻度よりさらに低コスト ◎低冗長化ストレージ（Reduce Redundancy Storage） スタンダードでは３ヶ所のAZに複製するものを、２ヶ所に複製する 耐久性は落ちるがコストが抑えられる ◎Amazon S3 Glacier アーカイブを目的としたストレージ 大容量データを安価で補完できるがデータアクセスに時間がかかる S3 Glacierよりもアクセスに時間がかかるがより安価な、GlacierDeep Archiveもある アーカイブ 専用の記憶領域に保存すること ◎Intelligent-Tiering 低頻度／高頻度の2階層のストレージ層を用意し、オブジェクトへのアクセス頻度の応じてストレージ層を自動的に使い分ける コストが自動で最適化される ◉柔軟なライフサイクルポリシー ライフサイクルポリシーを設定することで、設定期間が経過したらオブジェクトを自動削除／アーカイブする S3のデータ転送効率化を実現する機能 ◉マルチパートアップロード 大容量のオブジェクトをパートと呼ばれる複数の単位に分割してアップロードする 全てのパートのアップロードが完了するとS3側で自動的にオブジェクトを再構築 ◉Amazon S3 Transfer Acceleration 機能を有効化することでクライアントとS3間の通信を高速化する データ転送時にエッジロケーションとAWSネットワークを利用 ストレージ以外でのS3の用途 ◉Webサイトホスティング 静的コンテンツのWebサイトホスティング機能 サーバー構築せずに公開できる Route 53のDNSフェイルオーバー機能と組み合わせてWebサイトのSorryページとして利用される Sorryページ Webサイトのメンテナンス／障害発生時に表示するページ ◉データストア 実質目制限にデータ保管できるため、データレイクやビックデータ分析用のデータストアとして利用される データレイク 規模に関わらずデータをそのままの形で保存できるストレージレポジトリ ◉署名付きURL AWS CLIやAWS SDKを利用してS3上のデータに対して一定時間アクセスを許可するURLを発行する Amazon Elastic Block Store（EBS） 永続可能なブロックストレージサービス AZ間ではなく、AZ内で自動複製される AZ障害時には影響を受けるが、単一ディスク障害を回避できる ◉EBSの機能 ◎複数のボリュームタイプ ○汎用SSD（General Purpose SSD：gp2） デフォルトのボリュームタイプで安価 確保した容量に対してIOPSが設定されている OSのルート領域や高性能なI／Oを要求されないデータ領域で利用 I／O inputとoutputの頭文字（入出力）のこと IOPS 1秒あたりに処理できるI/Oのアクセス数 ○プロビジョンドIOPS SSD（PIOPS SSD：io1, io2） ユーザーが自由にIOPSを設定できる 汎用SSDより高パフォーマンス ストレージ容量／指定したIOPSに対して課金される ○スループット最適化HDD（st1） HDDタイプで大容量ストレージを安価に利用できる ○コールドHDD（sc1） アクセス頻度が低い大量データの保存に適している st1より安価 ○マグネティック 旧世代のHDD SSD（Solid State Drive） 容量単価がHDDより高い HDD（Hard Disk Drive） 容量単価として安くなる ◎スナップショットによるバックアップ スナップショットは自動的にS3に保管 初回はフルバックアップ、以後は増分を取得 オンプレ環境のストレージはバックアップ取得完了までの待ち時間がある EBSスナップショットは取得実行した時点のものが保管されるため待ち時間がない Amazon Elastic File System（EFS） 複数のEC2インスタンスから共有ファイルストレージとして利用できる ◉EFSの特徴 ◎高可用性 複数のAZに冗長化してデータ保管する AZをまたいでもファイルアクセス可能 ◎自動スケーリング ストレージ容量／パフォーマンスを自動的にスケーリング ファイル削除時は自動で縮小 EBSより柔軟に対応できる ◎標準的なファイルシステム NFSによってアクセスする EC2インスタンスだけでなくオンプレサーバーからも利用可能 NFS（Network File System） LinuxなどのUNIX系のOSで利用されるファイル共有システム Amazon FSx コスト効率の良いファイルシステム サイジング／冗長化／ソフトウェア管理／バックアップなどの検討事項を簡素化する ◉FSxの特徴 ◎高可用性と高耐久性 マルチAZに対応している S3へのバックアップが可能 ◎高速で柔軟なパフォーマンス データ保管用ストレージはSSD／HDDに対応している ◎セキュリティ保護 FSxに保管されたデータ／通信中のデータは全て暗号化されている IAMポリシーによるAPIコールやセキュリティグループによるアクセス制御が可能 ◎FSxのファイルシステム ○Fxs for Windows Windowsサーバーで使われるSMBプロトコルを利用してデータアクセス可能なファイルシステム Active Directoryとの連携 WindowsのACLによるアクセス制御可能 ○FSx for Lustre 機械学習など、処理速度を重視するシステムに利用されるLinuxベースのファイルシステム Linuxコマンドで実行でき、アプリケーションの変更を加えずに利用可能 SMB（Server Message Block） 主にWindows OSのネットワークでファイル／プリンタ共有などに使用される通信プロトコル その他のストレージサービス ◉インスタンスストア（エフェメラルディスク） 特定のEC2インスタンスで利用できる無料ストレージサービス ホストコンピュータのローカル領域を使用 高パフォーマンスだがインスタンスが停止するとデータが消失するため冗長化の検討が必要 ◉AWS Storage Gateway（SGW） S3へNFS／SMB／iSCSIなど標準プロトコルでアクセスできるサービス EC2インスタンス／オンプレサーバーにS3を認識させ（マウントして）利用する iSCSI（Internet Small Computer System Interface） データ転送にTCP／IPを使用する仕組み ◉SGWの種類 ◎キャッシュ型ボリュームゲートウェイ データはS3に保管するが、アクセス頻度の高いデータはローカルにキャッシュ インターフェイスにiSCSIを使用 キャッシュ PCやスマホに一時的にWebページのデータを保存しておいて、次に開いた時に素早く表示させる仕組み ◎保管型ボリュームゲートウェイ データをスナップショットとしてS3に保管 インターフェイスにiSCSIを使用 ◎テープゲートウェイ 物理テープ装置の代替として、データをS3（Glacier）に保管 インターフェイスにiSCSIを使用 ◎ファイルゲートウェイ データをオブジェクトとして直接S3に保管 インターフェイスにNFSを使用 ◉AWS Import／Export ユーザーから送付された物理ディスクのデータをAWSがAWS内のストレージに転送（Import） ユーザーの物理ディスクにデータを書き出す（Export） ・通常のネットワーク転送では非常に時間がかかるため、大容量のデータ移行に有効 ・反面、高価なディスクを購入したりディスクの耐久性／セキュリティに懸念事項がある ◉AWS Snowball（80TB） AWSから物理的に搬送される耐久性の高い筺体に大容量のデータを保管 保管した筺体はAWSマネジメントコンソールからジョブを作成し、登録先の住所へ発送 指定したリージョン、AZにあるストレージへ転送される Snowball内のデータは自動的に暗号化される ◉AWS Snowball Edge（１００TB） Snowballより大容量で多くのネットワークインターフェイスをサポート S3のAPIやNFSによる転送が標準で行うことが可能 参考

概要 LambdaにデプロイしたNode.jsからDynamoDBに接続し、データを取得する。 早い話が下記図を実施します。 TBLの準備 下記TBLを用意します。マイグレーション方法はリンクを参考にしてください。 ディレクトリ構成 ディレクトリ構成 ~/develop/study/aws/dynamo2 $ tree -I node_modules . ├── dynamo.js ├── package.json ├── serverless.yml └── yarn.lock dynamo.js 'use strict'; require('dotenv').config() var AWS = require('aws-sdk'); var documentClient = new AWS.DynamoDB.DocumentClient({ region: "ap-northeast-1", accessKeyId: process.env.ACCESS_KEY, secretAccessKey: process.env.SECRET_KEY }); module.exports.olympic = async (event) => { var params = { TableName: 'Olympic', Key: { 'Id': 1, 'Country': '日本' } }; var result; try { result = await documentClient.get(params).promise(); } catch (e) { result = e; } const country = result.Item.Country const goldMedal = result.Item.Medal.GoldMedal const silverMedal = result.Item.Medal.SilverMedal const bronzeMedal = result.Item.Medal.BronzeMedal let message = country +'金メダル:' + goldMedal + ' 銀メダル' + silverMedal +' 銅メダル:'+ bronzeMedal return { statusCode: 200, body: JSON.stringify(message), }; }; serverless.yml service: dynamodb2 frameworkVersion: '2' provider: name: aws runtime: nodejs12.x lambdaHashingVersion: 20201221 region: ap-northeast-1 plugins: - serverless-offline functions: lineWebhook: handler: dynamo.olympic events: - http: path: dynamo/webhook method: post ローカル実行 ローカルデプロイ ~/develop/study/aws/dynamo2 $ sls offline start offline: Starting Offline: dev/ap-northeast-1. offline: Offline [http for lambda] listening on http://localhost:3002 offline: Function names exposed for local invocation by aws-sdk: * lineWebhook: dynamodb2-dev-lineWebhook ┌───────────────────────────────────────────────────────────────────────────────┐ │ │ │ POST | http://localhost:3000/dev/dynamo/webhook │ │ POST | http://localhost:3000/2015-03-31/functions/lineWebhook/invocations │ │ │ └───────────────────────────────────────────────────────────────────────────────┘ offline: [HTTP] server ready: http://localhost:3000 ? offline: offline: Enter "rp" to replay the last request 実行 ~/develop/study/aws/dynamo2 $ curl -XPOST http://localhost:3000/dev/dynamo/webhook "日本金メダル:17 銀メダル11 銅メダル:11"% サーバ実行 サーバデプロイ ~/develop/study/aws/dynamo2 $ serverless deploy Serverless: Packaging service... Serverless: Excluding development dependencies... Serverless: Uploading CloudFormation file to S3... Serverless: Uploading artifacts... Serverless: Uploading service dynamodb2.zip file to S3 (10.79 MB)... Serverless: Validating template... Serverless: Updating Stack... Serverless: Checking Stack update progress... .............. Serverless: Stack update finished... Service Information service: dynamodb2 stage: dev region: ap-northeast-1 stack: dynamodb2-dev resources: 12 api keys: None endpoints: POST - https://URL/dev/dynamo/webhook functions: lineWebhook: dynamodb2-dev-lineWebhook layers: None Serverless: Removing old service artifacts from S3... Serverless: Deprecation warning: Detected ".env" files. In the next major release variables from ".env" files will be automatically loaded into the serverless build process. Set "useDotenv: true" to adopt that behavior now. More Info: https://www.serverless.com/framework/docs/deprecations/#LOAD_VARIABLES_FROM_ENV_FILES

問題 クラウドフロントで下記のようなエラーが表示されてページが閲覧できない <Error> <Code>AccessDenied</Code> <Message>Access Denied</Message> <RequestId>BASD5JKLZQBI8</RequestId> <HostId>X9Slmr75bLv4sfgCm5Y3Fx+qys/MEk+8NfsdfbMy0t5Qc19oaV4XFea3vsB/A0nmWzdfgkRoq4tk=</HostId> </Error> 対処法1 エラーページで　404の時と403の時、ステータスコード　２００で/index.htmlを開くようにする。 なぜかというとSPAは基本的に一つのhtmlファイルでパスごとに表示を切り替えているので、Vue.jsなどで /page /create などを定義していたとしてもS3からファイルを見つけられることができないので403が帰ってしまう。 それを防ぐために403でも200で一度/index.htmlにリダイレクトさせて作成したVue.jsのrouterなどに開くページを制御してもらう必要がある。 対処法２ S3のBucket policy を CloudFront から参照できるように更新する origins -> 対象を選択 -> edit で画像のような画面に遷移できる。 OAIをなければ作成あれば選択して update の方を選択して保存をする。 最後に Youtubeチャンネルはじめてます！ エンジニアの姿は十人十色。 今後も色んなエンジニア像を捉えて、それを目指す人たちの参考になる動画を作っています。 あと、プログラミングもメンタで教えているので興味があったらみてください。

きっかけ 案件でS3ファイルのPUTをトリガーにLambdaを動かして、PUTされたファイルを加工するような処理が必要なため、仕組みの具体的な設定内容の確認をしたかったため。 やりたいこと概要 前提 AWS: 社用アカウント利用 構築Step S3バケット作成 Lambdaの構築、ソース修正 Lambdaに紐づくIAMロール修正 Originバケット PUTトリガー設定 動作確認 1. S3バケット作成 デフォルト設定のまま、Origin、Copiedバケットを作成 2. Lambdaの構築、ソース修正 デフォルト設定(ランタイム:Node.js 14.x)でLambdaを構築 Lambdaのソースコードを以下の内容に修正、デプロイを実施 index.js 'use strict'; const aws = require('aws-sdk'); const s3 = new aws.S3(); exports.handler = async (event) => { //S3から送られたトリガー内容を確認 console.log(event); const bucket = event['Records'][0]['s3']['bucket']['name']; const key = event['Records'][0]['s3']['object']['key']; console.log(bucket); console.log(key); //S3.copyObjectを実施(params内Bucket,CopySource, Keyは必須) const params = { Bucket: "copied-bucket-210731/210731", CopySource: bucket+'/'+key, Key: key }; const result = await s3.copyObject(params).promise(); console.log(result) }; 3. Lambdaに紐づくIAMロール修正 Lambdaに紐づいているLambda実行ロールにAmazonS3FullAccessをアタッチ (ベストプラクティスでは最小権限原則ですが今回は割愛) 4. Originバケット PUTトリガー設定 S3のOriginバケットでプロパティ>イベント通知からイベント通知を作成 任意のイベント名を設定、イベントタイプを"PUT"に設定、送信先を今回作成したLambda関数を指定してトリガーを設定 5. 動作確認 OriginバケットにAWS CLIでファイルをアップロードする AWS CloudShellを起動、適当なテキストファイルを作成、CLIコマンドによりS3のOriginバケットへファイルをアップロードする Originバケットにファイルがアップロードされていることの確認 Copiedバケットにファイルがコピーされていることの確認 Lambdaの実行ログの確認 参考サイト