CloudFrontでS3の署名付きURLを発行する方法です。 暗号鍵、公開鍵の生成 openssl genrsa -out private_key.pem 2048 openssl rsa -pubout -in private_key.pem -out public_key.pem CloudFrontキーグループに公開鍵の追加 ここはAWSコンソールで作成するだけなので割愛します。 SecretsManagerに暗号鍵を登録 今回、作成した暗号鍵はシークレットキーに保存し、Lambdaから取得します。 AWSコンソールを利用して暗号鍵を貼り付けると値がおかしくなるようなので AWS CLIを利用し登録します。 aws secretsmanager create-secret --name ＜シークレット名＞ --secret-string file://private_key.pem --region ap-northeast-1 署名付きURLの発行(Lambda) import json, base64, sys, re, datetime import boto3 from botocore.exceptions import ClientError from botocore.signers import CloudFrontSigner sys.path.append('/opt/') from cryptography.hazmat.backends import default_backend from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives import serialization from cryptography.hazmat.primitives.asymmetric import padding def lambda_handler(event, context): cloudfront_signer = CloudFrontSigner('yourKeyId', rsa_signer) url = 'CloudFrontURI' expire_date = datetime.datetime(2021, 9, 15) #署名付きURLの発行 signed_url = cloudfront_signer.generate_presigned_url(url, date_less_than=expire_date) return { 'statusCode': 200, 'headers': { 'Access-Control-Allow-Headers': 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token', 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Methods': 'OPTIONS,POST,GET' }, 'body': signed_url } def rsa_signer(message): secret_name = "yourSecretname" region_name = "ap-northeast-1" session = boto3.session.Session() client = session.client( service_name='secretsmanager', region_name=region_name ) get_secret_value_response = client.get_secret_value( SecretId=secret_name ) cloudfront_pk_text = get_secret_value_response['SecretString'] cloudfront_pk_bytes = str.encode(cloudfront_pk_text, encoding='ascii') cloudfront_pk = serialization.load_pem_private_key(cloudfront_pk_bytes, password=None, backend=default_backend()) return cloudfront_pk.sign(message, padding.PKCS1v15(), hashes.SHA1())

1:はじめに 本記事ではCloudWatch AgentをWindows10へインストール & 起動し、CloudWatch LogsとWindowsイベントログを同期させてログ解析を行えるようにします。 Windows機へのAgentのインストール手順は数も多くなく、MS特有のハマりポイントも多く存在し、インストール & 起動にとても苦労しました。 2:概要 ● 本記事の目的 WindowsPC(10)へCloudWatch Agentをインストールし、CloudWatch LogsにてWindowsイベントログの取得、及び解析を行う ● 本記事の流れ ① CloudWatch Agentのダウンロード、及びインストール ② 設定ファイルの作成、及び読み込み ③ Agantの起動 ④ AWSコンソールよりログが取得できているか確認 ● 機能要件 ・Windows EventLogを取得する（System, Application） ・SSMは使用しない 3:CloudWatch Agentのインストール & 起動 3.1:Agnetのダウンロード、及びインストール WindowsPCへCloudWatch Agentをダウンロードし、msiを起動しAgentをインストールします。 以下ダウンロードリンクをクリックし、msiをダウンロードします。 https://s3.amazonaws.com/amazoncloudwatch-agent/windows/amd64/latest/amazon-cloudwatch-agent.msi ダウンロードした[amazon-cloudwatch-agent.msi]をダブルクリックし、Agentをインストールします。 ※ウィザードは表示されません 以下パスを確認し、CloudWatchAgentディレクトリが作成されていることを確認します。 ・C:\Program Files\Amazon\AmazonCloudWatchAgent ・C:\ProgramData\Amazon\AmazonCloudWatchAgent 3.2: 設定ファイルの作成、及び読み込み ここからはPowershellにてCLI操作を行っていきます。 Powershellを管理者権限で起動し、カレントディレクトリをAmazonCloudWatchAgentディレクトリに移動します。 PS C:\> cd 'C:\Program Files\Amazon\AmazonCloudWatchAgent' PS C:\Program Files\Amazon\AmazonCloudWatchAgent> ディレクトリ内のexeファイルを起動し、ウィザード画面からAgentの設定ファイル(JSON)を作成します。 各パラメータを対話的に聞かれますので以下を参考に設定してください。 ※各項目の詳細はページ下部、<おまけ3.2 - 詳細>を参照してください PS C:\Program Files\Amazon\AmazonCloudWatchAgent>.\amazon-cloudwatch-agent-config-wizard.exe ============================================================= = Welcome to the AWS CloudWatch Agent Configuration Manager = ============================================================= On which OS are you planning to use the agent? 1. linux 2. windows 3. darwin default choice: [2]: 2 Trying to fetch the default region based on ec2 metadata... Are you using EC2 or On-Premises hosts? 1. EC2 2. On-Premises default choice: [2]: 2 Please make sure the credentials and region set correctly on your hosts. Refer to http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html Do you want to turn on StatsD daemon? 1. yes 2. no default choice: [1]: 2 Do you have any existing CloudWatch Log Agent configuration file to import for migration? 1. yes 2. no default choice: [2]: 2 Do you want to monitor any host metrics? e.g. CPU, memory, etc. 1. yes 2. no default choice: [1]: 1 Do you want to monitor cpu metrics per core? Additional CloudWatch charges may apply. 1. yes 2. no default choice: [1]: 1 Would you like to collect your metrics at high resolution (sub-minute resolution)? This enables sub-minute resolution for all metrics, but you can customize for specific metrics in the output json file. 1. 1s 2. 10s 3. 30s 4. 60s default choice: [4]: 4 Which default metrics config do you want? 1. Basic 2. Standard 3. Advanced 4. None default choice: [1]: 1 Current config as follows: { "metrics": { "metrics_collected": { "LogicalDisk": { "measurement": [ "% Free Space" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "Memory": { "measurement": [ "% Committed Bytes In Use" ], "metrics_collection_interval": 60 }, "Network Interface": { "measurement": [ "Bytes Sent/sec", "Bytes Received/sec", "Packets Sent/sec", "Packets Received/sec" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "Paging File": { "measurement": [ "% Usage" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "PhysicalDisk": { "measurement": [ "Disk Write Bytes/sec", "Disk Read Bytes/sec", "Disk Writes/sec", "Disk Reads/sec" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "Processor": { "measurement": [ "% Processor Time" ], "metrics_collection_interval": 60, "resources": [ "*" ] } } } } Are you satisfied with the above config? Note: it can be manually customized after the wizard completes to add additional items. 1. yes 2. no default choice: [1]: 1 Do you want to monitor any customized log files? 1. yes 2. no default choice: [1]: 2 Do you want to monitor any Windows event log? 1. yes 2. no default choice: [1]: 1 Windows event log name: default choice: [System] System Do you want to monitor VERBOSE level events for Windows event log System ? 1. yes 2. no default choice: [1]: 1 Do you want to monitor INFORMATION level events for Windows event log System ? 1. yes 2. no default choice: [1]: 1 Do you want to monitor WARNING level events for Windows event log System ? 1. yes 2. no default choice: [1]: 1 Do you want to monitor ERROR level events for Windows event log System ? 1. yes 2. no default choice: [1]: 1 Do you want to monitor CRITICAL level events for Windows event log System ? 1. yes 2. no default choice: [1]: 1 Log group name: default choice: [System] chibi-DESKTOP-Q0QSAHL-log-groups Log stream name: default choice: [{hostname}] {hostname}-System.log In which format do you want to store windows event to CloudWatch Logs? 1. XML: XML format in Windows Event Viewer 2. Plain Text: Legacy CloudWatch Windows Agent (SSM Plugin) Format default choice: [1]: 1 Do you want to specify any additional Windows event log to monitor? 1. yes 2. no default choice: [1]: 1 Windows event log name: default choice: [System] Application Do you want to monitor VERBOSE level events for Windows event log Application ? 1. yes 2. no default choice: [1]: 1 Do you want to monitor INFORMATION level events for Windows event log Application ? 1. yes 2. no default choice: [1]: 1 Do you want to monitor WARNING level events for Windows event log Application ? 1. yes 2. no default choice: [1]: 1 Do you want to monitor ERROR level events for Windows event log Application ? 1. yes 2. no default choice: [1]: 1 Do you want to monitor CRITICAL level events for Windows event log Application ? 1. yes 2. no default choice: [1]: 1 Log group name: default choice: [Application] chibi-DESKTOP-xxxxxx-log-groups Log stream name: default choice: [{hostname}] {hostname}-Application.log In which format do you want to store windows event to CloudWatch Logs? 1. XML: XML format in Windows Event Viewer 2. Plain Text: Legacy CloudWatch Windows Agent (SSM Plugin) Format default choice: [1]: 1 Do you want to specify any additional Windows event log to monitor? 1. yes 2. no default choice: [1]: 2 Saved config file to config.json successfully. Current config as follows: { "logs": { "logs_collected": { "windows_events": { "collect_list": [ { "event_format": "xml", "event_levels": [ "VERBOSE", "INFORMATION", "WARNING", "ERROR", "CRITICAL" ], "event_name": "System", "log_group_name": "chibi-DESKTOP-xxxxxxx-log-groups", "log_stream_name": "{hostname}-System.log" }, { "event_format": "xml", "event_levels": [ "VERBOSE", "INFORMATION", "WARNING", "ERROR", "CRITICAL" ], "event_name": "Application", "log_group_name": "chibi-DESKTOP-xxxxxxx-log-groups", "log_stream_name": "{hostname}-Application.log" } ] } } }, "metrics": { "metrics_collected": { "LogicalDisk": { "measurement": [ "% Free Space" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "Memory": { "measurement": [ "% Committed Bytes In Use" ], "metrics_collection_interval": 60 }, "Network Interface": { "measurement": [ "Bytes Sent/sec", "Bytes Received/sec", "Packets Sent/sec", "Packets Received/sec" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "Paging File": { "measurement": [ "% Usage" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "PhysicalDisk": { "measurement": [ "Disk Write Bytes/sec", "Disk Read Bytes/sec", "Disk Writes/sec", "Disk Reads/sec" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "Processor": { "measurement": [ "% Processor Time" ], "metrics_collection_interval": 60, "resources": [ "*" ] } } } } Please check the above content of the config. The config file is also located at config.json. Edit it manually if needed. Do you want to store the config in the SSM parameter store? 1. yes 2. no default choice: [1]: 2 Please press Enter to exit... Program exits now. 上記にて設定ファイルの作成が完了しました。 以下パスに設定ファイルが作成されていることを確認してください。 C:\Program Files\Amazon\AmazonCloudWatchAgent\config.json しかし、設定ファイルを作成しただけでは、CloudWatchでログの収集は行なえません。 作成した設定ファイルを読み込む必要があります。（ここがちょっとややこしいです。。） まずは、新たにCloudWatchAgent用のCLIプロファイルを生成します。 以下パスのAWS CLIの設定ファイルをテキストエディタで開いてください。 C:\Users<端末にログオンしているユーザー名>.aws\config C:\Users<端末にログオンしているユーザー名>.aws\credentials 以下を参考に設定ファイルを編集してください。 【.aws\config】 \.aws\config(修正前) [default] region = <リージョン名> output = <テキスト形式> ↓ 修正 \.aws\config(修正後) [default] region = <リージョン名> output = <テキスト形式> [profile AmazonCloudWatchAgent] region = <リージョン名> output = <テキスト形式> 　 【.aws\credentials】 \.aws\credentials(修正前) [default] aws_access_key_id = <アクセスキーID> aws_secret_access_key = <シークレットキーID> ↓ 修正 \.aws\credentials(修正後) [default] aws_access_key_id = <アクセスキーID> aws_secret_access_key = <シークレットキーID> region = <リージョン名> [AmazonCloudWatchAgent] aws_access_key_id = <アクセスキーID> aws_secret_access_key = <シークレットキーID> region = <リージョン名> 　 続いてCloudWatchAgentのエージェント設定を修正します。 デフォルトだと存在しないAdministoratorユーザーがカレントユーザになってしまうので、先程生成したCloudWatchAgentユーザが使用されるようにします。 以下パスの設定ファイルに書き込み権限を付与してください。 ※1:対象ファイルを右クリック - [プロパティ] - 画面中央[編集] ※2:[Users]を選択し、メニュー下部で書き込み権限にチェックを入れる C:\ProgramData\Amazon\AmazonCloudWatchAgent\common-config.toml 権限が付与できたら、テキストエディタで開いて以下を参考に中身を編集してください。 common-config.toml(修正前) # This common-config is used to configure items used for both ssm and cloudwatch access ## Configuration for shared credential. ## Default credential strategy will be used if it is absent here: ## Instance role is used for EC2 case by default. ## AmazonCloudWatchAgent profile is used for onPremise case by default. # [credentials] # shared_credential_profile = "{profile_name}" # shared_credential_file = "{file_name}" ## Configuration for proxy. ## System-wide environment-variable will be read if it is absent here. ## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy ## Note: system-wide environment-variable is not accessible when using ssm run-command. ## Absent in both here and environment-variable means no proxy will be used. # [proxy] # http_proxy = "{http_url}" # https_proxy = "{https_url}" # no_proxy = "{domain}" # [ssl] # ca_bundle_path = "{ca_bundle_file_path}" ↓ 修正 common-config.toml(修正後) # This common-config is used to configure items used for both ssm and cloudwatch access ## Configuration for shared credential. ## Default credential strategy will be used if it is absent here: ## Instance role is used for EC2 case by default. ## AmazonCloudWatchAgent profile is used for onPremise case by default. [credentials] shared_credential_profile = "AmazonCloudWatchAgent" shared_credential_file = "C:\\Users\\<端末にログオンしているユーザー名>\\.aws\\credentials" ## Configuration for proxy. ## System-wide environment-variable will be read if it is absent here. ## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy ## Note: system-wide environment-variable is not accessible when using ssm run-command. ## Absent in both here and environment-variable means no proxy will be used. # [proxy] # http_proxy = "{http_url}" # https_proxy = "{https_url}" # no_proxy = "{domain}" # [ssl] # ca_bundle_path = "{ca_bundle_file_path}" 続いてPowershellにて以下コマンドを実行し、以下のような結果が出力されることを確認してください。 PS C:\Program Files\Amazon\AmazonCloudWatchAgent> & "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m onPremise -s -c file:config.json ****** processing amazon-cloudwatch-agent ****** Got Home directory: C:\Users\Administrator I! Set home dir windows: C:\Users\Administrator I! SDKRegionWithCredsMap region: ap-northeast-1 Successfully fetched the config and saved in C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs\file_config.json.tmp Start configuration validation... 2021/09/14 21:36:21 Reading json config file path: C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs\file_config.json.tmp ... Valid Json input schema. Got Home directory: C:\Users\Administrator I! Set home dir windows: C:\Users\Administrator I! SDKRegionWithCredsMap region: ap-northeast-1 No csm configuration found. Under path : /logs/ | Info : Got hostname DESKTOP-xxxxxxx as log_stream_name Configuration validation first phase succeeded Configuration validation second phase succeeded Configuration validation succeeded AmazonCloudWatchAgent has been stopped AmazonCloudWatchAgent has been started 4:動作確認 ここまでで、CloudWatchAgentの起動は完了しました。 動作確認として、インストールしたAgentが起動しているか、CloudWatch logsでWindowsのログを取得できているかを確認しましょう。 4.1 Windows(オンプレ)での単体確認 まずはWindows側での確認です。 ここではサービスマネージャでAgentサービスが起動しているか確認します。 サービスマネージャを起動します。 ※1:[Windows] + [r]を押打 ※2:と入力し、[OK]をクリック サービス画面で[Amazon Cloudwatch agent]の状態が[実行中]であることを確認します。 状態が[実行中]ではない場合はファイルの読み込みに失敗している可能性がありますので、再度ファイルの読み込みを行って下さい。 4.2 AWS(クラウド)での単体確認 Windows側でAgentが起動中であることを確認できたので、続いてAWS側を確認します。 AWSマネジメントコンソールを開き、管理コンソール画面上部の検索バーでと検索をかけ、表示された[CloudWtahc]をクリックします。 CloudWatch管理画面が表示されたことを確認し、ナビゲーションペイン、[ログ] - [ロググループ]をクリックします。 ロググループ一覧が表示されるので、ウィザードで生成したロググループ名が表示されたことを確認します。 ロググループをクリックし、ウィザードで生成したログストリームが生成されていることを確認します。 いづれかのログストリームをクリックし、Windowsのイベントログを収集できていることを確認します。 5:まとめ 以上がCloudWatch Agentのダウンロードから起動までの手順になります。 Linuxと違って設定ファイルの読み込みという工程がLinuxと比べてわかりづらさを助長していると感じています。。 今回はログの取得を目標に作業を行いましたが、もっと様々なこと、例えばパフォーマンス計測なんかもできますので是非そちらもトライしてみてください。 では、本記事は以上になります。ありがとうございました。

はじめに 個人開発で独自ドメインを作りたいなと思い、先日↓の記事を参考にさせていただいた。 上記の記事では ・ドメイン作成　　　→ お名前.com ・ネームサーバ作成　 → AWS Route53 の方法で作成していたが、 先日業務でAWS Route53でドメイン作成できるということも知り、 ・ドメイン作成　　　→ AWS Route53 ・ネームサーバ作成　 → AWS Route53 でドメイン作成する機会があった。 この時点で「あれ、ドメインってそもそもなんだっけ？ネームサーバとドメインの関係性って？」と混乱してしまったので改めて整理。 ドメインとネームサーバ ドメイン：IPアドレスの別名 ネームサーバ：ドメイン情報(ドメイン --- IPアドレス)のマッピング情報を保持するサーバ ①ぐぐる時にURLに「https://qiita.com/ 」と打ち込む ②ドメイン「qlita.com」のIPアドレスを知っているネームサーバに問い合わせる。 ③返ってきたIPアドレスでQlitaのサイトに辿り着く。 「ドメイン⇄IPアドレス」の変換のことを名前解決という。 名前解決の仕組み Amazon Route 53 は、権威 DNS システムです。 https://aws.amazon.com/jp/route53/what-is-dns/ ドメインとネームサーバの関係性 ネームサーバは「ドメイン情報を皆に教える場所」なんだから、大前提としてドメインがないと何も始まらない。サッカーボールがないサッカー場みたいな？（表現下手か( ´_ゝ`) 逆に、ドメインを作ってもネームサーバを作らなければそのドメインのIPアドレスを誰も知ることができない。サッカー場がないサッカーボールみたいな？（表現下手か2回目( ´_ゝ`) 言いたいことは「ドメインとネームサーバはお互いに欠かせない存在」ってこと。 お互いに欠かせないのなら、どっちから作るのよ？同時に作らんの？ A. お名前.comは別のタイミング。Route53は同時に作る。 お名前.comでドメイン作成する場合 ①ドメイン作成 ②ドメインの設定＞ネームサーバの変更 にてネームサーバ作成/設定する ※ここでRoute53のホストゾーンで作成したネームサーバを設定することが可能 Route53でドメイン作成する場合 ①ドメイン作成と同時にネームサーバが作成される aws公式ドキュメントにはこう書いてある ドメインを Route 53 に登録する際に、そのドメインのホストゾーンが自動的に作成されます。 https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/domain-register.html ホストゾーンを作成すると、Route 53 は自動的に 4 つのネームサーバーをゾーンに割り当てます。 https://aws.amazon.com/jp/premiumsupport/knowledge-center/create-subdomain-route-53/ ドメイン作る ＝そのドメインのホストゾーンが自動的に作成される ＝自動的に４つのネームサーバがそのドメインに割り当てられる ってことだ まとめ ✔︎ ドメインとネームサーバは運命共同体（外部に共有すべき「もの」とそれを共有するための「場所」） ✔︎ お名前.com・Route53のどちらでもドメイン作成できる ✔︎ Route53の方はドメイン作成＆ネームサーバの作成が同時に行われる

最近、別々のAWSアカウント越しにいろいろ連携する方法をリサーチしています。 今回は、Amazon Connectのコンタクトフローから、別のAWSアカウントにあるLexボットを呼び出したい！がゴールです。 フツーのLexボット連携の場合 Amazon Connectと同一アカウント内のLexボットを連携するフツーのケースでは、Get Customer InputブロックのAmazon LexセクションでSelect a Lex botを選択すると、ドロップダウンリストから目的のLexボットを選べるので、チョロいわけです。 じゃあ、Enter an ARNすれば他アカウントのLexボットも呼び出せるんじゃないか？ と思ったら、、、意外と簡単じゃなかった。。 Enter an ARNの公式ドキュメントがない問題 Enter an ARNを選んでみるも、パッと見とフィーリングで設定がわからないので グーグル先生に尋ねると・・・ 公式ドキュメントに記載がなーい！（2021年8月28日現在） LexボットのARNってどうやってゲットするの？問題 ・・・じゃあ、適当に設定してみるか。 ということで管理コンソールでAmazon Lexのいろいろなページを見ても、ボットのARNがズバリ！記載されているページがありません。。 公式ドキュメントの例をもとに、arn:aws:lex:ap-northeast-1:123456789012:bot:OrderFlowers的な（左記のアカウントIDとボット名は例）ARNをいろいろ試すわけですが ・・・ことごとくこのような エラーが出てPublishできません。 試行錯誤の結果たどり着いた答えは、、、 Amazon Lex v1 （Classic）はARN経由で連携できない です。 このドキュメントの 7.c. には、7.b. のClassicボット（v1）との対比で、「Amazon Lex ボットの場合は、ボットエイリアス ARN を手動で設定することもできます。」と書いてありますね。 Lex v2のボットならコンタクトフローをPublishできる Lex v1（Classic）ボットの連携がうまく行かないので、目先を変えてLex v2ボットでテストすることにしました。 Lex V2 開発者ガイドを見ると、例としてarn:aws:lex:Region:123456789012:bot-alias/MYBOT/MYBOTALIASというARNが載っています。 調べた結果、ここで言うMYBOTとは、これ↓を指し MYBOTALIASとは、これ↓を指します。 なので、 arn:aws:lex:ap-northeast-1:123456789012:bot-alias/DSPP8M6EKZ/O3SUP4JK56 的な（上記アカウントIDは参考例）ARNを指定すると、めでたくコンタクトフローがPublishできます！やったー！ ところが！ 当初このテストをしていた8月11日時点では、Amazon ConnectのコンタクトフローはLex v2ボットとは連携できない制約があり、結局コンタクトフローは動きませんでした。。。 というオチで終わる予定だったのですが 8月末に再調査していたら、なんと8月12日にこの制約がなくなったというじゃあーりませんか！ 本日（9月14日）再度テストしたところ、無事に他アカウントのボットを呼び出せました！ Yay！

これは何 SFTP専用ユーザーを作成し、特定directoryのみ更新できるよう制限してみたので、メモをここに残します。 FTPソフトはCyberduckを使ってます。 要件 sftp-userを作成する /home/sftp-user配下のファイルしか操作できない様にする（chrootする） ただし、/var/www/html/hogeだけは更新できる様にしたい やってみた ユーザー作成 useradd sftp-user httpd install yum -y install httpd sftp-userがアップロードしたファイルをApacheが動かせるようにする gpasswd -a apache sftp-user SSH directory 作成 cd /home/sftp-user mkdir .ssh chmod 700 .ssh 鍵作成 sudo su - sftp-user cd .ssh ssh-keygen key name : sftp-user rootに戻る exit 公開鍵の名称とパーミッションの変更 mv sftp-user.pub authorized_keys chmod 600 authorized_keys コピペで保存 cat sftp-user (pemファイル) sftp-user でログイン可能か確認する (bastionにて) vi sftp-user.pem コピペ内容貼り付け ssh -i sftp-user.pem sftp-user @Private IP sftp-userを、ファイル転送専用ユーザーにする vi /etc/ssh/sshd_config # override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server 　　↓ # override default of no subsystems #Subsystem sftp /usr/libexec/openssh/sftp-server Subsystem sftp internal-sftp ファイルの末尾に、以下を追記。 Match User sftp-user ChrootDirectory /home/sftp-user ForceCommand internal-sftp 特定のディレクトリを別のディレクトリにマウントする /var/www/htmlディレクトリの内容は、２つの 場所、 /var/www/html と /home/sftp-user/hoge/で利用できるようになる。 mount -B /var/www/html /home/sftp-user/hoge/ /home/sftp-userディレクトリの所有者とパーミッションを変更 chown root:root /home/sftp-user chmod 755 /home/sftp-user ユーザーディレクトリ内にディレクトリを作成し、ユーザーに所有させる mkdir /home/sftp-user/hoge chown sftp-user:sftp-user /home/sftp-user/hoge chmod 775 /home/sftp-user/hoge sshdを再起動し、設定を反映 sshd -t エラーがなければ再起動 service sshd restart sftpコマンドで転送する。 （hoge directoryにcdしなければ、putは失敗した。） sftp -i sftp-user.pem sftp-user@踏み台の先のEC2 Private IP Connected to XXX sftp> cd /hoge/ sftp> put XXX.jpeg Uploading XXX.jpeg to /hoge/XXX.jpeg XXX.jpeg 100% 11KB 20.3MB/s 00:00 sftp> exit /var/www/html配下に移動できているか確認 ls -la /var/www/html/XXX.jpeg -rwx------. 1 sftp-user sftp-user 11136 Sep 13 09:56 /var/www/html/XXX.jpeg 一応、ポートフォワーディングを行い、ファイル転送できるか確認 ポートフォワーディング ssh -f -N -L 10220(任意):踏み台の先のEC2 Private IP:22 -i 秘密鍵 踏み台OSユーザー@踏み台Public IP FTPソフトで接続し、ファイル転送。 総括 なかなかセキュアな環境ができたのではないでしょうか。（konami） 参考 https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/5/html/global_file_system_2/s1-manage-pathnames https://lab.taf-jp.com/sftp%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%92%E4%BD%9C%E6%88%90%E3%81%97%E3%81%A6%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E8%BB%A2%E9%80%81%E7%94%A8%E3%81%AB%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B/ https://cloudpack.media/14365 参考にさせていただきました。ありがとうございます。

Terraform環境構築（Windows編） Terraformとは HashiCorp社が提供するIaC（インフラをコード化して管理する）を実現してくれるツールです。 クラウド上のサーバーやネットワークなどのインフラ構築を自動化してくれます。 HCL記法でコードを記述し、インフラ管理していく。 AWSや、Azure、Google Cloudなどの複数のプロバイダーに対応しているので、HCLの記述さえ慣れれば、神ツールです。 今回はAWS環境にTerraformを使ってVPCを作成してみることについて解説します。 ※AWS Cliの設定済みの前提で話を進めます。 Terraformのバージョン管理ツール（tfenv）のインストール Terraformの公式ページから、直接ダウンロードしてきてもいいですが、 TerraformのHCLの記法がv0.13以降、大幅に変わったこともあり、今からはじめるなら バージョン管理できた方がいいねということで、tfenvをインストールしていきます。 今回はWSL2＋Ubuntuの環境にインストールしていきます。 Ubuntuのターミナル上で以下を実行していきます。 # tfenvのツールが置いているリモートリポジトリから、クローンしてきます $ git clone https://github.com/tfutils/tfenv.git ~/.tfenv # コマンドが実行できる/usr/local/bin にシンボリックリンクを設定 $ sudo ln -s ~/.tfenv/bin/* /usr/local/bin # tfenvコマンドが使えるかテスト $ tfenv --version # Terraform使えるバージョンを確認 $ tfenv list-remote # 使いたいバージョンのTerraformをインストール $ tfenv install <使いたいバージョン> # 指定したバージョンがインストールされているか確認 $ tfenv list # インストールしてきたバージョンを設定する $ tfenv use <使いたいバージョン> # 指定したバージョンが設定されているか確認 $ terraform --version 以上で環境構築は完了！お疲れさまでした。 では、早速でAWS上にVPCをサクッと作成してみます。 プロジェクトフォルダを作成し、その中に以下のVPCをつくるファイルを配置します。 ※Terraform v0.13.0以降のバージョンが対象 main.tf terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 3.0" } } } # AWSプロバイダーの設定 provider "aws" { region = "ap-northeast-1" } # CIDRが10.0.0.0/16のVPCを作成 resource "aws_vpc" "example" { cidr_block = "10.0.0.0/16" } ※Terraform v0.12.0以前のバージョンを使っている方はこちらを使ってください main.tf # プロバイダー（AWS）の設定 provider "aws" { version = "~> 3.0" region = "us-east-1" } # CIDRが10.0.0.0/16のVPCを作成 resource "aws_vpc" "example" { cidr_block = "10.0.0.0/16" } プロジェクトフォルダを作成したら、その中に、main.tfを配置。 再びUbuntuターミナルに戻り、以下を実行 # Terraform の初期化 $ terraform init # コードを反映してリソースを作成する前に、あらかじめ変化を確認 $ terraform plan Plan: 1 to add, 0 to change, 0 to destroy. # 設定を反映 $ terraform apply Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value:yes Apply complete! Resources: 1 added, 0 changed, 0 destroyed. AWSのマネジメントコンソールに入ってリソースが反映されているか確認 しっかり、反映されていますねー 最後はお片付け。作ったリソースを削除していきます。 # リソース削除 $ terraform destroy 再度マネジメントコンソールから確認してみると消えてます まとめ 今回は、IaC化に向けた第一歩として、Terraformの実行環境構築からTerraformのコードからAWS上にVPCを作成してみました 細かい記述の仕方などはまた今度！それでは、皆様の快適なIaCライフを～☆

はじめに CSVファイルのデータをAWSのS3に保存するロジックを実装したので、よかったら参考にしてみてください。 Rails: 5.2.6 Ruby: 2.7.2 実装したコード S３のバケットに 例: 2021_10/2021_10_01.csv といったファイル名で出力されます。 こちらは毎日バッチで実行することを想定して作成おります。 export_csv.rb # frozen_string_literal: true require 'csv' require 'aws-sdk-s3' class ExportCsv def self.execute(params) output = CSV.generate do |csv| csv << params['headers'] params['values'].each do |value| csv << value end end export_csv_to_s3(output, params) end def self.export_csv_to_s3(data, params) s3_client = Aws::S3::Client.new(stub_responses: Rails.env.test?, access_key_id: params['access_key_id'], secret_access_key: params['secret_access_key'], region: params['region']) bucket_name = params['bucket_name'] folder_name = Time.current.yesterday.strftime('%Y_%m').to_s file_name = "#{Time.current.yesterday.strftime('%Y_%m_%d')}.csv" file_full_path = "#{folder_name}/#{file_name}" # バケットの存在確認とアクセス権の確認 if bucket_exists_and_accessible?(s3_client, bucket_name) Rails.logger.info "Bucket '#{bucket_name}' exists and is accessible to you." else Rails.logger.info "Bucket '#{bucket_name}' does not exist " \ 'or is not accessible to you.' end # ファイルアップロードが完了したか確認 if file_uploaded?(s3_client, bucket_name, file_full_path, data) Rails.logger.info "Object '#{file_full_path}' uploaded to bucket '#{bucket_name}'." else Rails.logger.info "Object '#{file_full_path}' not uploaded to bucket '#{bucket_name}'." end end def self.bucket_exists_and_accessible?(s3_client, bucket_name) s3_client.head_bucket(bucket: bucket_name) return true rescue StandardError return false end def self.file_uploaded?(s3_client, bucket_name, path, data) response = s3_client.put_object( bucket: bucket_name, key: path, body: data, content_type: 'text/csv' ) return true if response.etag rescue StandardError => e Rails.logger.info "Error uploading object: #{e.message}" return false end private_class_method :export_csv_to_s3, :bucket_exists_and_accessible?, :file_uploaded? end

What is chalice? AWSが提供するPythonのサーバーレスフレームワークで、flaskみたいな書き心地でLambdaなどにデプロイできます。 今回はこのChaliceのCDを構築するお話。 TL;DR Chaliceは自動でCDパイプラインを構築する機能がある。でもなんか難しくて結局自分で作った。 使用バージョン chalice==1.24.1 Deploy Command 公式ドキュメントのQuickstartではローカル環境からCLIでデプロイする方法が紹介されています。 $ chalice deploy --stage dev １コマンドで簡単！ しかしこれだとチームで開発している場合は問題になります。 Chaliceは作成したAWSリソースを把握するため、.chalice/deployed/配下に下記のようなJSONを作成します。 deployed.json { "resources": [ { "name": "foo_role", "resource_type": "iam_role", "role_arn": "arn:aws:iam::...", "role_name": "foo" }, { "name": "foo_lambda", "resource_type": "lambda_function", "lambda_arn": "arn:aws:lambda:ap-northeast-1:..." }, { "name": "foo_event", "resource_type": "s3_event", "bucket": "foo-dev", "lambda_arn": "arn:aws:lambda:ap-northeast-1:..." } ], "schema_version": "2.0", "backend": "api" } ローカルでデプロイする際にこのJSONがチームで共有できていないとリソースの作成・更新・削除がうまくできないわけです。 このあたりはterraformのtfstateに似てる。 CI/CD pipeline generation そのため、ChaliceはCodePipelineによるCDパイプラインを自動的に構築する機能を持っています。 → https://aws.github.io/chalice/topics/cd.html $ chalice generate-pipeline --pipeline-version v2 pipeline.json このコマンドを打つとCloudFormation用の設定ファイルが吐き出されます。 吐き出された設定ファイルを元にCloudFormationを使うことでCDパイプラインが出来上がるという二段構えです。ややこしい CloudFormation?? CDパイプラインのための設定が自動で出来上がっていいじゃないか。最初はそう思いました。 デフォルトの設定で十分な方はこれでもいいかもしれません。しかしドキュメントにはこんなワードがありました。 Chalice can generate a CloudFormation template that will create a starter CD pipeline. そうstarterなのです。 プッシュしたら自動的にデプロイしてほしい。デプロイしたら通知がほしい。そういうオマケは自前で作る必要があります。 「でも実は私、CloudFormation使ったことない。」 さあ困った。CloudFormationがわかる方は生成された設定をいじればいいと思います。 以降は私のようなCloudFormationワカラナイ人向けです。 Be Simple そもそもローカルでデプロイするときはchalice deployの1コマンドで済んだのに、CDになると複雑すぎない？という疑問もあり、勝手知ったるCodeBuildでchalice deployさせる方針を取ります。 問題になるのは状態を持っているdeployed.jsonですが、tfstateのようにS3に入れてしまいましょう。 buildspec.yml version: 0.2 phases: install: runtime-versions: python: 3.8 commands: - python -V pre_build: commands: - echo Install dependencies... - pip install -r requirements.txt - aws s3 cp s3://chalice-deployed/${STAGE}.json .chalice/deployed/${STAGE}.json || true build: commands: - echo Deploy ${STAGE}... - chalice deploy --stage ${STAGE} post_build: commands: - aws s3 cp .chalice/deployed/${STAGE}.json s3://chalice-deployed/${STAGE}.json - echo Build completed at `date '+%Y-%m-%d %H:%M:%S'` うん。シンプル。 初回は${STAGE}.jsonがなくダウンロードに失敗するので|| trueでごまかしてます。 念の為、CodeBuildの同時ビルド制限を1にしておきます。 完成！ ハマったところ 今回Chaliceで作成したLambda関数は一部Layerでpyodbcを入れていました。 requirements.txtに入れてもChaliceがパッケージングできないライブラリだからです。 こうしたrequirements.txtに書いていないライブラリがあるとCodeBuildでchalice deployしたときに「pyodbc入ってないよ」というエラーが出ます。 とりあえずインポートエラーを補足するワークアラウンドでしのぎました。 app.py import warnings try: import pyodbc except ImportError: warnings.warn("pyodbcをインポートできません。CD環境の場合はこの警告を無視できます。") まとめ ローカルでもCDでも同じ方法でデプロイすることができました。 CloudFormation版では何をしたかったのかを読み解けておらず、まずい点があったら教えていただきたいです。

LambdaProjectを新設したので、デプロイ周りを構築中。 環境変数をパラメータストアから取得しようとしたら・・・ SSM Secure reference is not supported in: [AWS::Lambda::Function/Properties/Environment/Variables/ENV_NAME] なん....だと？ 公式ドキュメントを見ると。 Resources that support dynamic parameter patterns for secure strings Resources that support the ssm-secure dynamic reference pattern currently include: - AWS::DirectoryService::MicrosoftAD - AWS::DirectoryService::SimpleAD - AWS::ElastiCache::ReplicationGroup - AWS::IAM::User - AWS::KinesisFirehose::DeliveryStream - AWS::OpsWorks::App - AWS::OpsWorks::Stack - AWS::OpsWorks::Stack - AWS::RDS::DBCluster - AWS::RDS::DBInstance - AWS::Redshift::Cluster Lambdaがサポートされていない...!!! しょうがないので強引にパラメータストアから取得するように挑戦。 成果物 CodePipeLine + CloudFormationの構成を想定。 その他基本設定については割愛する。 template.yaml AWSTemplateFormatVersion: 2010-09-09 Resources: Lambda: Type: AWS::Lambda::Function Properties: Code: app.zip FunctionName: LamndaFunction Handler: index.handler Runtime: nodejs12.x Environment: Variables: ENV01: __ENV01__ ENV02: __ENV02__ Role: Fn::GetAtt: - "Role" - "Arn" MemorySize: 1024 Timeout: 3 Role: Type: "AWS::IAM::Role" Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: - "edgelambda.amazonaws.com" - "lambda.amazonaws.com" Action: - sts:AssumeRole buildspec.yaml version: 0.2 phases: install: runtime-versions: nodejs: 12 commands: - yum install -y aws-cli pre_build: commands: - json=$(aws --region ap-northeast-1 ssm get-parameters-by-path --path "/" --with-decryption | jq -r .Parameters) - len=$(echo $json | jq length) - for i in $( seq 0 $(($len - 1)) ); do Name=$(echo $json | jq .[$i].Name);Value=$(echo $json | jq .[$i].Value);Key=__$(echo $Name | sed 's/\"//g')__;sed -i -e "s/$Key/$Value/g" ./template.yaml; done build: commands: - yarn install --production=true - zip -r app.zip index.js node_modules post_build: commands: - aws cloudformation package --template-file template.yaml --s3-bucket BUCKET_NAME --s3-prefix `date '+%Y%m%d%H%M%S'` --output-template-file packaged.yaml - aws cloudformation deploy --region ap-northeast-1 --template-file packaged.yaml --stack-name STACK_NAME --capabilities CAPABILITY_IAM artifacts: files: - packaged.yaml 説明 簡単に説明すると、CodeBuild内でパラメータストアからキーと値を取ってきて、template.yaml内の文字列を置換しています。 template.yaml AWSTemplateFormatVersion: 2010-09-09 Resources: Lambda: Type: AWS::Lambda::Function Properties: 〜〜〜 Environment: Variables: ENV01: __ENV01__ ENV02: __ENV02__ 〜〜〜 置換対象の文字列は__${パラメータストアのkey名}__としております。 buildspec.yaml version: 0.2 phases: 〜〜〜 pre_build: commands: - json=$(aws --region ap-northeast-1 ssm get-parameters-by-path --path "/" --with-decryption | jq -r .Parameters) - len=$(echo $json | jq length) - for i in $( seq 0 $(($len - 1)) ); do Name=$(echo $json | jq .[$i].Name);Value=$(echo $json | jq .[$i].Value);Key=__$(echo $Name | sed 's/\"//g')__;sed -i -e "s/$Key/$Value/g" ./template.yaml; done 〜〜〜 まずは、パラメータストアの値をjson形式で取得。 json=$(aws --region ap-northeast-1 ssm get-parameters-by-path --path "/" --with-decryption | jq -r .Parameters) その後、jsonレコード分ループし、文字列を置換。 len=$(echo $json | jq length) for i in $( seq 0 $(($len - 1)) ); do Name=$(echo $json | jq .[$i].Name);Value=$(echo $json | jq .[$i].Value); Key=__$(echo $Name | sed 's/\"//g')__;sed -i -e "s/$Key/$Value/g" ./template.yaml; done 以上。

まず、コンソールからec2インスタンスに接続しましょう。 現在の容量を確認します。 $ df -h ファイルシス サイズ 使用 残り 使用% マウント位置 devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 516K 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/nvme0n1p1 300G 281G 20G 94% / tmpfs 389M 0 389M 0% /run/user/1000 tmpfs 389M 0 389M 0% /run/user/0 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 300G 0 disk ├─nvme0n1p1 259:1 0 300G 0 part / └─nvme0n1p128 259:2 0 1M 0 part /dev/nvme0n1p1　が94%使用中であることがわかります。 次に、 AWS コンソールをぽちぽちして　EBS　の容量を追加。 やり方はネットにたくさんあるので省略、参考文献からも見れます。 (30分くらい待たされるので注意) $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 400G 0 disk ├─nvme0n1p1 259:1 0 300G 0 part / └─nvme0n1p128 259:2 0 1M 0 part ルートが400Gに増えましたが、今回増やしたい　nvme0n1p1　は300Gのままなので、growpartで割り当てます。 $ sudo growpart /dev/nvme0n1 1 CHANGED: partition=1 start=4096 old: size=629141471 end=629145567 new: size=838856671 end=838860767 CHANGED になれば成功です。 lsblk で確認してみましょう。 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 400G 0 disk ├─nvme0n1p1 259:1 0 400G 0 part / └─nvme0n1p128 259:2 0 1M 0 part nvme0n1p1 が400Gに変わったことが確認できました。 が、ファイルシステムはまだ増えていません。 $ df -h ファイルシス サイズ 使用 残り 使用% マウント位置 devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 460K 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/nvme0n1p1 300G 281G 20G 94% / tmpfs 389M 0 389M 0% /run/user/1000 ファイルタイプを確認します。 /dev/nvme0n1p1 は xfs であることがわかります。 $ df -T ファイルシス タイプ 1K-ブロック 使用 使用可 使用% マウント位置 devtmpfs devtmpfs 1970604 0 1970604 0% /dev tmpfs tmpfs 1988928 0 1988928 0% /dev/shm tmpfs tmpfs 1988928 460 1988468 1% /run tmpfs tmpfs 1988928 0 1988928 0% /sys/fs/cgroup /dev/nvme0n1p1 xfs 314560492 293627624 20932868 94% / tmpfs tmpfs 397788 0 397788 0% /run/user/1000 ファイルタイプが xfs の場合は xfs_grows で。 $ sudo xfs_growfs -d / meta-data=/dev/nvme0n1p1 isize=512 agcount=151, agsize=524159 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1 spinodes=0 data = bsize=4096 blocks=78642683, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 78642683 to 104857083 ファイルタイプが xfs 以外の場合は以下のように。 $ sudo resize2fs /dev/nvme0n1 1 無事に容量が追加できたことを確認します。 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 400G 0 disk ├─nvme0n1p1 259:1 0 400G 0 part / └─nvme0n1p128 259:2 0 1M 0 part $ df -h ファイルシス サイズ 使用 残り 使用% マウント位置 devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 492K 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/nvme0n1p1 400G 281G 120G 71% / tmpfs 389M 0 389M 0% /run/user/1000 参考文献

前提 複数のAWSアカウントを1つのPCから操作している時に eb cliが現在どのアカウントを向いているかを確認したい状況でした。 新しいAWSアカウントで新しいBeansTalk環境を作成した時に確認した方法です。 AWSアカウントは複数の要素から判定されます 以下優先度の高い要素から書いていきます。基本的にはAWS CLIと同じ構成ですが後述する注意点もあります。 コマンドオプション ebコマンドを実行する際に--profileオプションを付けることでアカウントを指定することができます。このオプションは後述するローカルPCのファイルに書いてある情報を見てアカウントを判断します。 init.sh $ eb init --profile account1 環境変数 AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEYを設定することで使用できます。 export.sh #環境変数設定 $ AWS_ACCESS_KEY_ID=EBCLIEBCLIEBCLIEBCLIEBCLIEBCLI $ AWS_SECRET_ACCESS_KEY=BCLIEBCLIEBCLIEBCLIEBCLIEBCLIBCLI #環境変数削除 $ unset AWS_ACCESS_KEY_ID $ unset AWS_SECRET_ACCESS_KEY AWS 認証情報ファイル ローカルmacに保存されている設定ファイルです。 テキストエディタで編集もできます。 ~/.aws/credentials [default] aws_access_key_id = EBCLIDEFAULTEBCLIDEFAULTEBCLIDEFAULT aws_secret_access_key = EBCLIDEFAULTEBCLIDEFAULTEBCLIDEFAULTEBCLIDEFAULT [account1] aws_access_key_id = EBCLITESTEBCLITESTEBCLITEST aws_secret_access_key = EBCLITESTEBCLITESTEBCLITESTEBCLITEST eb-cli｜注意点 eb-cli独自の仕様として以下どちらか記述がある場合 ~/.aws/credentials [eb-cli] aws_access_key_id = EBCLIEBCLIEBCLIEBCLIEBCLIEBCLI aws_secret_access_key = BCLIEBCLIEBCLIEBCLIEBCLIEBCLIBCLI ~/.aws/config [profile eb-cli] aws_access_key_id = EBCLIEBCLIEBCLIEBCLIEBCLIEBCLI aws_secret_access_key = BCLIEBCLIEBCLIEBCLIEBCLIEBCLIBCLI 以下のデフォルトより優先される動きになります。 ~/.aws/credentials [default] aws_access_key_id = EBCLIEBCLIEBCLIEBCLIEBCLIEBCLI aws_secret_access_key = BCLIEBCLIEBCLIEBCLIEBCLIEBCLIBCLI 注意したいのはconfigにeb-cliの記述があった場合 credentialsのデフォルトより優先される動きです。 AWS CLI 設定ファイル AWS CLIの設定ファイルでも設定ができます。 ~/.aws/config [profile eb-cli] aws_access_key_id = EBCLIEBCLIEBCLIEBCLIEBCLIEBCLI aws_secret_access_key = BCLIEBCLIEBCLIEBCLIEBCLIEBCLIBCLI レガシー EB CLI 設定ファイル 自分で使用していないので項目だけ紹介します。詳細は参考ページをご確認下さい。 インスタンスプロファイルの認証情報 自分で使用していないので項目だけ紹介します。詳細は参考ページをご確認下さい。 運用中のローカルディレクトリで確認する場合 現在運用中のプロジェクトディレクトリ（eb init済みのディレクトリ）では 以下のコマンドで現在ebコマンドが見ているAWSアカウントのBeansTalk環境一覧が見れます。 eb.sh $ eb list 参考ページ 構成設定と優先順位

背景 AWS上にECRとECSでバックエンドサービスを構築している one clickでコードデプロイを実施したい 開発環境と本番環境は別のAWSアカウントになる 内容 AWS CodeBuildとは 完全マネージド型のビルドサービス ソースコードをコンパイルする 単体テスト デプロイ buildspec.yml 単体テスト実施 docker image build ECRへpush 問題 開発アカウントのCodeBuildから本番アカウントのECRへプッシュする時に、権限設定が必要 対策 本番アカウントの側 ECRリポジトリにアクセス許可を追加する 開発アカウントのputimage権限を許可する {    "Version": "2008-10-17",    "Statement": [      {        "Sid": "AllowPushPull",        "Effect": "Allow",        "Principal": {          “AWS”: “arn:aws:iam::開発アカウントID"        },        "Action": [  ......         "ecr:PutImage",          "ecr:UploadLayerPart"        ]      }    ]  }  開発アカウントの側 ビルドプロジェクトのサービスロールに、STSとECR操作権限を追加する sts-policy: {      "Version": "2012-10-17",      "Statement": [          {              "Sid": "VisualEditor1",              "Effect": "Allow",              "Action": [                  "sts:AssumeRole"              ],              “Resource”: “arn:aws:iam::開発アカウントID:role/service-role/ロール名"          }      ]  }  ECRへpush権限: {      "Version": "2012-10-17",      "Statement": [          {              "Sid": "VisualEditor0",              "Effect": "Allow",              "Action": [    ....                 "ecr:PutImage",  ......             ],              “Resource”: “arn:aws:ecr:ap-northeast-1:本番アカウントID:repository/リポジトリ名"          },          {              "Sid": "VisualEditor1",              "Effect": "Allow",              "Action": "ecr:GetAuthorizationToken",              "Resource": "*"          }      ]  }