はじめに AWSでお仕事？をしていて、amplify というのを用意する必要があったのでメモ。 amplify command line interface (CLI)は、AWS cloud service をアプリケーションで使うためのツールだそうです。何でも、作業しているproject のフォルダで $ amplify init とやると、設定が行われ、CUIでいろいろきるようになるのだとか。自分は、これで作業中のproject で amplify init できたところまでしかできていませんが、メモ。^^* このGet started の install の流れです。 インストール amplify configure するだけ。 インストールとアカウント設定 インストールのための準備 (1) Node.js version 12.0 以上、npm v 6.x 以上とあるが、自分はNode.js が古いことが判明。 $ npm --version 7.20.6 $ node -v v10.19.0 (2) Node.jsを新しくする。 $ sudo npm install -g n added 1 package, and audited 2 packages in 1s found 0 vulnerabilities $ n --stable 14.17.5 $ n --latest 16.6.2 $ sudo n stable installing : node-v14.17.5 mkdir : /usr/local/n/versions/node/14.17.5 fetch : https://nodejs.org/dist/v14.17.5/node-v14.17.5-linux-x64.tar.xz installed : v14.17.5 (with npm 6.14.14) Note: the node command changed location and the old location may be remembered in your current shell. old : /usr/bin/node new : /usr/local/bin/node To reset the command location hash either start a new shell, or execute PATH="$PATH" $ node -v v14.17.5 (3) 古いamplify を削除。（この前にごちゃごちゃ作業していたときにamplify をinstall していたので。これはnvm をインストールしたときに出てきたメッセージに従っただけ。） $ nvm use system Now using system version of node: v14.17.5 (npm v6.14.14) $ npm uninstall -g a_module up to date in 0.039s インストール コマンド一発。 $ sudo npm install -g @aws-amplify/cli npm ....... ---------------------------------------- Successfully installed the Amplify CLI ---------------------------------------- JavaScript Getting Started - https://docs.amplify.aws/start Android Getting Started - https://docs.amplify.aws/start/q/integration/android iOS Getting Started - https://docs.amplify.aws/start/q/integration/ios Flutter Getting Started - https://docs.amplify.aws/start/q/integration/flutter Amplify CLI collects anonymized usage data, which is used to help understand how to improve the product. If you don't wish to send anonymized Amplify CLI usage data to AWS, run amplify configure --usage-data-off to opt-out. Learn more - https://docs.amplify.aws/cli/reference/usage-data ... + @aws-amplify/cli@5.3.0 added 97 packages from 92 contributors, removed 146 packages and updated 1290 packages in 174.551s Configure でIAMユーザ作成 コマンド一発なのですが、そこでインタラクティブに AWS region を指定 新しいIAM user name を指定 AWS console （ブラウザ画面）でユーザの設定 AWS console での設定で得たaccessKeyId とsecretAccessKey を入力 を行います。 $ amplify configure 私のWSL2のubuntu ではこんな感じでした。 この結果、~/.aws/credentials に新しい IAM user のprofile が追加されてました。 ~/.aws/credentials [default] aws_access_key_id=XXXX0X000XX000XXXXXX aws_secret_access_key=5sH........................ [amplify-user01-profile] aws_access_key_id=XXXX0Y000XX111YYYYYYY aws_secret_access_key=tbf...................... 実行 あとは各プロジェクトに移動し、amplify initとすると、インタラクティブに問いに答える形で設定がされていきました。とりあえずエラーがでなかったので、良さそうです。。。 参考情報 下記など拝見しました。 AWS Amplify CLIの使い方〜インストールから初期セットアップまで〜 AWS Amplify フレームワーク 入門メモ まとめ とりあえず私の開発環境で amplify が使えるようになったらしい。ふー。 (2021/08/15)

勉強前イメージ 並列数を上げる？ 調査 Provisioned Concurrency とは 2019年に発表された機能で、 初期化処理が完了したlambdaの環境をプロビジョニングしておくことが出来ます。 要するにすぐに使えるようなlambdaの環境を用意しておくことができる、ということです。 lambdaのコールドスタート(HWが初期化された状態の再起動)対策として他にも方法が取られていましたが、 この機能で簡単に対策を行うことが出来ます。 lambdaでリクエストが大量に来たとき、 同時実行数に関わらず、バースト制限までしか最初の段階は増えないのです。 例えば同時実行数が3000で、バースト制限が1000だとしたら 一気にアクセス来た際は1000までしか最初は増えないということです。 その後の同時実行数はすぐには増えず1分間に500ずつ増えていきます。 その際の一定量環境を用意しておくという対策が、Provisioned Concurrencyになります。 費用 Provisioned Concurrency には費用がかかり、 東京リージョンの場合には以下になります。 Provisioned Concurrencyの有効時間 1GBの環境で、1秒あたり 0.0000053835USD リクエスト 100万件あたり 0.20USD 実行時間 1GBの環境で、1秒あたり 0.0000125615USD 例で計算してみると 1GBの環境でProvisioned Concurrencyを2時間有効にし、 用意した同時実行数は1000とする。 リクエストを100万回実行し、1リクエスト1秒間の稼働するとする。 Provisioned Concurrencyの有効時間 1GBの環境で、1秒あたり 0.0000053835USD 2時間→7200秒 同時実行の合計容量(GB/s) : 1000(同時実行数)*7200(秒) = 7200000GB/s 7200000(GB/s) * 0.0000053835(USD) = 38.7612(USD) リクエスト リクエスト量 : 100万回 100万件あたり 0.20USD 0.20(USD) 実行時間 1GBの環境で、1秒あたり 0.0000125615USD 実行時間の合計 1000000(リクエスト) * 1(1リクエストの稼働時間) = 1000000秒 1000000(秒) * 0.0000125615(USD) = 12.5615(USD) 合計 38.7612(USD) + 0.20(USD) + 12.5615(USD) = 51.5227(USD) 1ドル110円だとすると、 51.5227(USD) * 110 = 5,667.497(円) 約5670円ほどになる 勉強後イメージ バーストのリクエストの際は、それに応じるのが時間かかるから ある程度環境を準備しておくってことか・・・ 参考 AWS Lambda の Provisioned Concurrency について調べてみた AWS Lambdaが提供するProvisioned Concurrencyという機能を簡単に説明してみる

はじめに 業務でAWSを使うようになり、AWSの基礎を体系的・包括的に理解したいなと思い、AWS認定試験のクラウドプラクティショナーに挑戦しようと思いました。 AWS認定試験の全体像 AWS認定試験の概要 プラクティショナーの試験概要 問題数は65問 試験時間は90分 合格スコアは100-1000のスコアで700以上(≒正解率70%前後) 試験料は11,000円 試験範囲 クラウドの概念:28% セキュリティ:24% テクノロジー:36% 請求と料金:12% 受験前のステータス 現時点でのスキル・知識を整理 ICT及びプログラミングのある程度ある SIerで10年ぐらいの実務経験 情報処理技術者試験で高度試験(ITアーキテクト/NWスペシャリスト/安全確保支援士など)をいくつか保有 複数のプログラミング言語(Node/Java/Python/C/Dartなど)を扱える 業務以外にもプライベートでアプリをリリースしたり、サーバ立てたり、ラズパイで遊んだりする AWSはほぼ素人 2ヶ月間の業務経験 CloudFront,WAF,ALB,ECS,Code4兄弟,Dynamo,S3,Lambda,APIGWなどを使って簡単なWebサイトを構築 勉強方法と時間(1週間/25Hぐらい) 試験について調べる (2H) E-learningで勉強 (3H) AWS Cloud Practitioner Essentials 動画を倍速で確認 AWSが重要視している考え方を理解するのに有用 移行などはあまり出題されないので、CAFなどはいらないかも 書籍で勉強 (5H) AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー 出題範囲及び難易度を確認するために、一通り参考書を読破し、勉強ノートに整理 前提知識(WAFやDDoSなどの基本概念)部分は省略しながら、AWSの特徴/サービスの詳細を理解 過去問　(10H) Udemyの講座 安い(1000円ちょっと) & 次のレベルも含んでいる & 時間があるため追加で実施 基礎×2、応用×3を2回ずつ解いて、間違った部分や理解が怪しい部分を勉強 1回目：基礎×2が80%、応用×3が65-70% / 2回目：95% 勉強ノートで復習(3H) 作った勉強ノートを読み返して不明点や整合性のつかない部分の確認 暗記 受験予約 (2H) 受験方法の確認、テストセンターの空きの確認、受験方法の確認など 活動記録 8/7 夏休みで実家にも帰れず暇なので、なにかしようと思いたち、AWSの試験について調べ、参考書をポチる 8/8 E-learningで勉強する 8/10 - 8/11 参考書をやる 8/12 - 8/14 過去問題をやる 8/15 受験&結果確認 コロナに気をつけながら、テストセンターで受験 受験した所感 上記過去問の基礎編と同程度のレベル サービスよりも「クラウドとは」「AWSのメリット」の考え方が多かった印象 おもったよりもサービスなどを聞かれない 「XXXを実現するためのサービスは何か」よりも「XXXを実現するために必要な性質は何か」のようなものを聞かれる 可用性、グローバル性、セキュリティ、機敏性など 細かいオプションや運用時の懸念なども覚えていったが、ほぼ出ない。 練習問題と同じものはでない 当たり前だが練習問題と同じものはない。 貢献度は下記ぐらい E-learningが10%。参考書が30%,過去問が30%,ICTの予備知識が30%(笑) 結果 合格 点数は874 上記の過去問の実績や感覚的(自信がない問題が5問以下)に90%は軽く超えたと思っていたので、正直低くてショックでした。。。 そんなに甘くないぞという戒めだと思って、上位試験に挑戦したいと思います。 全セクションで「コンピテンシーを満たしている」の判定 振り返ってみて 6ヶ月の実務経験というが、そこまでは不要 書籍か過去問のどちらかだけで十分 AWSのサービスは代表どころだけ覚えておけば大丈夫 AWSやクラウドのメリットなどを理解しておくほうが重要だった AWSの提唱するクラウドの6つのメリットなど 参考書が古かったが、改定もされており、問題なかった サービスの個々の詳細よりも概念に近い問いが多く、そのような部分は変わらないため、問題なかった 苦労した点 「どちらでもできる」「違いが微妙」が多い 「Config」「Trail」「inspector」「trusted advisor」などサービスの違いを理解していても、問題文が「コンプライアンス対応に使えるのはどれか」のような曖昧で微妙な表現の場合はかなり悩む 本番では少ないが、練習問題では多く、ほぼ同じ問題で違う解答ががあり困った。。。 一般的な選択肢問題にはよくあることですが、 苦労しなかった点 ICT基礎知識があり、用語や技術要素を知らないということはなかった 2ヶ月間ではあるが、代表的なサービスを触ることができていた 注力したポイント マネージドサービスの名称とその役割や代表的な使い方 でも、実はそこまで出なかった AWS(出題者)が理解してほしいポイントの理解 過去問では問題文と選択肢から、どちらでもできるみたいなものが多く、ニュアンスを読み取るのに時間を使った 実際の問題では迷う問題は、そこまで多くなかったが、点数低いので汲み取れていなかったのかも。。。 まとめ 2ヶ月間の実務実績と1週間の勉強があれば、余裕で合格できる ただし、この程度の試験内容であれば、わざわざ1万円払って受けるよりも、もっとしっかり勉強してアソシエイトを受けるほうが良いかも。。。 (おまけ)マネージドサービス+αまとめ 勉強の中で出てきたマネージドサービスや機能 でも、殆ど使わなかった・・・ サービス/機能名 概要 CodeBuild ビルドプロジェクト CodeCommit リポジトリ CodeDeploy デプロイプロジェクト CodePipeline パイプライン Config 変更を記録 Connect コンタクトセンター Direct Connect 専用線 DMS(Database Migration Service) DBマイグレ DocumentDB ドキュメントDB DynamoDB NoSQLDB EBS(Elastic Block Store) ブロックストレージ EC2(Elastic Compute Cloud) 仮想マシン ECR コンテナリポジトリ ECS(Elastic Container Service)/EKS(Elastic Kubernetes Service) コンテナサービス Elastic Beanstalk 自動デプロイ ElastiCache インメモリキャッシュ EFS(Elastic File System) 共有ファイルシステム ELB(Elastic Load Balancing)/ALB・NLB・CLB LB EMR(ElasticMapReduce) ビッグデータ Fargate サーバレスコンピューティング Glacier アーカイブストレージ Global Accelerator 地理的に近いエンドポイント GuardDuty インテリジェントな脅威検知 IAM(Identity and Access Management) アカウント管理/ロール管理 IGW インターネットゲートウェイ Inspector 脆弱性診断 Kinesis ストリーム KMS(Key Management Service) 鍵管理 Lambda FaaS Lightsail 仮想プライベートサーバ Marketplace ソフトウェアカタログ NATゲートウェイ NAT Neptune グラフDB OpsWorks マネージド構成管理 Organizations アカウントの一元管理 OutPosts オンプレでの実行 Personal Health Dashboard アカウント関連のヘルスチェック RDS(Relational Database Service)/ Aurora リレーショナルDB RedShift データウェアハウス Route53 DNS RouteTable ルーティングテーブル S3(Simple Storage Service) スト1レージ STS(Security Token Service) 一時認証情報 SecurityGroup 仮想ファイアウォール SES メール Shield DDoS攻撃を保護する SMS サーバマイグレーション SnowCone/SnowballEdge/SnowMobile 移行時のデバイス SNS(Simple Notification Service) Pub/Sub SQS(Simple Queue Service) キューイング StepFunctions 処理の順次実行 Storage Gateway ハイブリッドクラウドのストレージ Systems Manager 運用の可視化 Trasted Advisor ベストプラクティス評価 VPC(Virtual Private Cloud ) プライベートネットワーク VPNGW VPNゲートウェイ WAF アプリケーションファイアウォール Well-Architected アーキテクチャ評価 X-Ray 分散アプリの分析とデバッグ

PHP・Laravelで作成したアプリをAWSのEC2へデプロイする際に、本番環境では常にHTTPS通信を行うことになると思います。 何も設定しないとHTTP通信になってしまうので、この記事ではLaravelをセキュア(=暗号化)な状態で通信するための設定を記載します。 環境の設定 config/app.php 'env' => env('APP_ENV', '〇〇〇'), 〇〇〇の箇所について、開発環境の場合（ローカルで開発する際）はlocal、本番環境の場合（デプロイする際）はproductionにしてください。 ここを設定することで、開発環境か本番環境のどちらか切り替えることができます。 URLをhttpsにする AppServiceProvider.phpを下記のように追記してください。 app/Providers/AppServiceProvider.php <?php namespace App\Providers; use Illuminate\Support\ServiceProvider; use Illuminate\Support\Facades\URL; //追記 class AppServiceProvider extends ServiceProvider { //略 public function boot() { // ここから追記 if (config('app.env') === 'production') { URL::forceScheme('https'); } // ここまで追記 } } これで開発環境の時のURLがhttp、本番環境の時のURLがhttpsになりました。 本番環境において、httpでアクセスされた際にhttpsへリダイレクトさせるための処理 middlewareの作成 次のコマンドを実行してmiddlewareを作成します。RedirectToHttpsの箇所はご自身が作りたいクラス名を記載してください。 $ php artisan make:middleware RedirectToHttps 作成されたRedirectToHttps.phpを下記のように追記してください。 app/Http/Middleware/RedirectToHttps.php <?php namespace App\Http\Middleware; use Closure; class RedirectToHttps { /** * Handle an incoming request. * * @param \Illuminate\Http\Request $request * @param \Closure $next * @return mixed */ public function handle($request, Closure $next) { // ここから追記 //このhandleメソッドで判別 if (!$this->is_ssl() && config('app.env') === 'production') { return redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']); } // ここまで追記 return $next($request); } // ここから追記 //Webサーバー毎にキーと値で判別 public function is_ssl() { if (isset($_SERVER['HTTPS']) === true) { // Apache return ($_SERVER['HTTPS'] === 'on' or $_SERVER['HTTPS'] === '1'); } elseif (isset($_SERVER['SSL']) === true) { // IIS return ($_SERVER['SSL'] === 'on'); } elseif (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) === true) { // Reverse proxy return (strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) === 'https'); } elseif (isset($_SERVER['HTTP_X_FORWARDED_PORT']) === true) { // Reverse proxy return ($_SERVER['HTTP_X_FORWARDED_PORT'] === '443'); } elseif (isset($_SERVER['SERVER_PORT']) === true) { return ($_SERVER['SERVER_PORT'] === '443'); } return false; } // ここまで追記 } Kernel.phpに登録 先程作成したRedirectToHttps.phpの内容を反映させるために、Kernel.phpのprotected $middlewareに追記します。 app/Http/Kernel.php // 略 protected $middleware = [ \App\Http\Middleware\TrustProxies::class, \App\Http\Middleware\CheckForMaintenanceMode::class, \Illuminate\Foundation\Http\Middleware\ValidatePostSize::class, \App\Http\Middleware\TrimStrings::class, \Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class, \App\Http\Middleware\RedirectToHttps::class, // 追記 ]; // 略 補足 全プロキシを信用 全プロキシを信用するために、TrustProxies.phpに*を追記します。 app\Http\Middleware\TrustProxies.php protected $proxies = '*'; 詳細は信用するプロキシの設定を確認してください。 CSSを反映させる URLがhttpsになると、CSSが適用されません。 assetをsecure_assetにすることで反映されます。 app.blade.phpのheaderタグにおいて、CSSを適用している箇所をこのように書き換えると良いと思います。 resources/views/app.blade.php @if(config('app.env') === 'production') <link rel="stylesheet" href="{{ secure_asset('css/app.css') }}"> @else <link rel="stylesheet" href="{{ asset('css/app.css') }}"> @endif 開発環境(http)の時はasset、本番環境(https)の時はsecure_assetにすることで、CSSが通常通り反映されます。 AWS側の設定 SSL証明書の作成、ロードバランサー、セキュリティーグループ等の設定が必要になります。 この記事がとてもわかりやすかったので、共有しておきます。 一点補足することがあります。 上記の記事ではロードバランサーの作成において、最後にターゲットの確認をして、Health statusがhealthyになっています。 しかし、URLをhttpからhttpsへリダイレクトさせると、Health statusがunhealthyになってしまします。 unhealthyになっていても通常通り動くので、大した問題ではありません。 ただ、unhealtyが気になる方は、下記の設定を行うことでhealthyになります。 1.ターゲットグループを選択 2.Health CheckのEditをクリック 3.Advanced health check settingsのSuccess codesに302を追加し、Save changesをクリック 参考記事 Laravelで作ったサービスをSSL化した時にやったことと参考記事一覧 LaravelでURLをHTTPS化させるメモ (Heroku) https対応したLaravelプロジェクトでassetを使う時の注意点 EC2上のwebサーバをSSL化対応 おわりに 最後まで読んでいただき、ありがとうございます。 間違いがあればご指摘いただけると幸いです。

前回の投稿 AWS上にサーバーを作る（その03-02：Amazon VPCの設定） インスタンスを起動 開始するには、クラウド内の仮想サーバーである Amazon EC2 インスタンスを起動します。 ステップ 1: Amazon マシンイメージ (AMI) AMI は、インスタンスの作成に必要なソフトウェア構成 (OS、アプリケーションサーバー、アプリケーション) を含むテンプレートです。 AMI は、AWS が提供するもの、ユーザーコミュニティが提供するもの、または AWS Marketplace に掲載されているものを選択できます。独自の AMI のいずれかを選択することもできます。 ここで、作成する仮想マシンのベースとなるイメージを選択します。 とりあえず、安くすませたいので、今回は「Amazon Linux」かつ「64ビット(Arm)」を選択。 一応、Windows ServerやRedHatみたいなイメージも準備されているので選べる。 ステップ 2: インスタンスタイプの選択 Amazon EC2 では、異なるユースケースに合わせて最適化されたさまざまなインスタンスタイプが用意されています。インスタンスとは、アプリケーションを実行できる仮想サーバーです。インスタンスタイプはさまざまな CPU、メモリ、ストレージ、ネットワークキャパシティの組み合わせによって構成されているため、使用するアプリケーションに合わせて適切なリソースの組み合わせを柔軟に選択できます。インスタンプタイプおよびそれをコンピューティングのニーズに適用する方法に関する詳細はこちら。 ここでは、仮想マシンのスペックを選択。 ここでも安くすませたいので、タイプ：t4g.nanoを選択。 ステップ 3: インスタンスの詳細の設定 要件に合わせてインスタンスを設定します。同じ AMI からの複数インスタンス作成や、より低料金を実現するためのスポットインスタンスのリクエスト、インスタンスへのアクセス管理ロール割り当てなどを行うことができます。 ステップ 4: ストレージの追加 インスタンスは次のストレージデバイス設定を使用して作成されます。インスタンスに追加の EBS ボリュームやインスタンスストアボリュームをアタッチするか、ルートボリュームの設定を編集することができます。また、インスタンスを作成してから追加の EBS ボリュームをアタッチすることもできますが、インスタンスストアボリュームはアタッチできません。Amazon EC2 のストレージオプションに関する詳細はこちらをご覧ください サイズ (GiB)も最低限でよいので「8GiB」を指定。 ステップ 5: タグの追加 タグは、大文字と小文字が区別されるキーと値のペアから構成されます。たとえば、キーに「Name」、値に「Webserver」を使用してタグを定義することができます。 タグのコピーは、ボリューム、インスタンス、またはその両方に適用できます。 タグは、すべてのインスタンスとボリュームに適用されます。Amazon EC2 リソースのタグ付けに関する 詳細はこちら。 分かりやすい名前タグを付けておくことにする。 ステップ 6: セキュリティグループの設定 セキュリティグループは、インスタンスのトラフィックを制御するファイアウォールのルールセットです。このページで、特定のトラフィックに対してインスタンスへの到達を許可するルールを追加できます。たとえば、ウェブサーバーをセットアップして、インターネットトラフィックにインスタンスへの到達を許可する場合、HTTP および HTTPS ポートに無制限のアクセス権限を与えます。新しいセキュリティグループを作成するか、次の既存のセキュリティグループから選択することができます。Amazon EC2 セキュリティグループに関する 詳細はこちら。 ようはファイアウォールですね。 一旦、今接続している場所のグローバルIPアドレスのSSHだけ許可しておく。 ちなみに「ソース」のところで、「マイIP」を選択すると、自動で現在のグローバルIPを入力してくれるみたい。 ステップ 7: インスタンス作成の確認 インスタンスの作成に関する詳細を確認してください。各セクションの変更に戻ることができます。[作成] をクリックして、インスタンスにキーペアを割り当て、作成処理を完了します。 最終的に設定内容を確認して、「起動」ボタンをクリック。 次回の内容 ようやく仮想マシン起動まできた！！ 次は起動した仮想マシンに接続するところから？？（まだ引っ張る） To be continued...

はじめに 教材でAWS演習をこなして学習している中、 S3のバケット名を曖昧に決めてしまったことが原因で Route53でドメイン名を取得できないことに気づく。 「じゃあ、S3を作り直すか…」と思っていたが、 AWS CLIを使ってバケット名を変更する方法があると情報をゲット。 （学習教材にもその場合はググって調べたら何とかなると書いてあった。） そこで、学習がてらネットで情報収集して 解決できたので対応記録としてまとめる。 OS：MAC 教材 ・ゼロからわかる Amazon Web Services超入門 そもそもAWS CLIって？ AWSは、マネジメントコンソールからGUI（ボタン操作など）で EC2やS3などのインスタンス作成したり、VPCのネットワークを構成したりなど インフラ構成ができる。 それに対して、CLIはターミナル内で コマンドを入力して、各種インフラ構成をすることと ざっくり認識しておく。 おそらく、細かく言うとできることも異なると思う… 目的 目的はS3のバケット名を変更すること 恥ずかしいことに、私の場合はS3を下記のようなバケット名にしてしまっていた。 ■バケット名 www.〇〇〇〇〇.▽▽▽▽▽.com Route53で「〇〇〇〇〇.▽▽▽▽▽.com」ドメイン取得しようとしたら 登録できないと言われてしまった。 一方で.▽▽▽▽▽の部分を削除すると取得できるみたいだった。 演習だからといってテキトーに決めすぎた自分が悪い。笑 ということで、AWS　CLIで www.〇〇〇〇〇.com に修正しよう！という目論見。 早速CLI使ってみる ネットで、S3バケット名の変更に関連する AWS　CLIコマンドを発見したので、試してみる。 ターミナル % aws s3 mb s3://www.〇〇〇〇〇.com すると、下記エラーが発生。 AWS fatal error: Unable to locate credentials aws公式ページが下記エラーの原因を示してくれていたので、 自分がAWS CLIの基本設定を行えていないと気づけた。 　では、AWS CLIの基本設定 aws公式ページより基本設定の手順に従って基本設定を行う。 この時、設定するためのaws configureコマンドをする前に、 1.マネジメントコンソールでIAMを開き、指定ユーザーのアクセスキーを作成 2.使用するリージョンを確認 3.出力形式の種類を理解 を用意しておく。 ※上記のうち、1.は特に理解して進める。 （手順はaws同ページに参照されている。） ターミナル % aws configure AWS Access Key ID [None]: アクセスキーID AWS Secret Access Key [None]: 秘密鍵のコード Default region name [None]: リージョン（ap-northeast-1など） Default output format [None]: json 上記のように、aws configureコマンドで一つ一つ入力して ４つの基本設定を完了させる。 これで、AWS CLIコマンドがターミナル上で使用できる。 　S3のバケット名を変更 前置きとして、S3には作成後にバケット名を変更する機能はない。 そのため、以下手順で進めていく。 １、新しくS3のインスタンスを作成 ２、既存のS3内にあるデータを、新しいE3にコピー ３、既存のS3を削除 ※参考URL コマンドは以下の通り。 ターミナル % aws s3 mb s3://新規E3のバケット名 % aws s3 sync s3://既存E3のバケット名 s3://新規E3のバケット名 % aws s3 rb --force s3://既存E3のバケット名 最後に本当にS3を作成できたか確認 % aws s3 ls 上記まで完了すれば、マネジメントコンソール上でも反映されていることが確認できる。 終わりに AWS CLIコマンドの使用は、現時点で必須ではなかったが 失敗を機会に出会えて良かった。 恐らく、インフラのコード化する際にも お世話になるのではないかな？と想像している。 最後までお読み頂き、ありがとうございました。

初めに 入門中の React を使って Cognito のサインアップ・サインインのサンプルを作ってみました。 リポジトリは以下になります。 パッケージ Cognito で認証機能を実装するには以下のパッケージが必要です。 npm install --save amazon-cognito-identity-js npm install --save cross-fetch import 'cross-fetch/polyfill'; import * as AmazonCognitoIdentity from 'amazon-cognito-identity-js'; 使い方 必要なことは、以下のコードにユーザープール ID とクライアント ID を設定することです。 App.js const poolData = { // setting ids UserPoolId: '', ClientId: '' }; 参考記事

AWSについて代表的なストレージサービスのS3の理解を深めるために投稿しました。 S3とは S3とは「Amazon Simple Storage Service」という名称でAWSが提供するオンラインストレージサービス。 S3は、2006年からサービスを開始していて、安価で高い耐久性をもっているAWSの代表的なサービスの一つ。 オンラインストレージなので、インターネットが接続できる環境でデータをアップロードしたり、ダウンロードしたりすることが可能。 また、データを保存する場所（リージョン）は自身で選択することができる。 例えば、東京リージョンを選択した場合は、リージョン外に出ることがないので、日本国内にデータが保存されるようになる。 S3のメリット S3のメリットは以下のようになる ・　堅牢 ・　いつでも利用できる ・　スケールできる ・　安全 ・　高速に動く ・　シンプルに利用できる ・　コストがばり安い 堅牢 S3はデータを3箇所以上に冗長化して保存される。なので、99.999999999％という高い耐久性が実現できている。 いつでも利用できる SLAが99.9%で計画停止がない。 スケールできる 容量の制限がない。※ただし１つのファイルサイズは５TBまでという制限がある。 安全 S3との通信はSSLで暗号化される。さらに接続元のIPアドレス等でS3にアクセスできる通信を制限すルことができる。 高速に動く 常に安定したレイテンシで専用線でS3にアクセスすることも可能。 シンプルに利用できる データの容量やデータ数の設計不要で事前のキャパシティプランも不要。保存したい分だけ保存することができる。 S3へのアクセスは、AWSの管理画面やFTPツールでアクセスすることができる。 コストが安い S3は従量課金で「保存した容量」、「S3からダウンロードした転送量」等の利用した分だけ料金が発生する仕組みとなる。 料金は１GB約3円で利用する事ができる。 S3に関連する用語 オブジェクト S3に保管するファイルのこと バケット S3上に保存するフォルダのようなもの バケットポリシー バケットへのアクセス制限等のセキュリティポリシー。バケット毎に自由に設定することができる。 マルチパートアップロード 大きいファイルは複数に分割してアップロードできて、アップロード後に統合することができる機能の名称。 WEBサイト機能 WEBサーバとして公開することができる。 バージョニング 一度削除したものを復元できる機能の名称。 S3のユースケース コンテンツ保存＆配信 画像等の静的コンテンツの保存先及び配信。 データ保存用のストレージ ログ保存用やアプリケーションのストレージとして利用。 バックアップ サーバのバックアップ、DR用にバックアップ。 S3と関連するサービス Glacier GlacierはS3よりもさらに安価なアーカイブ用の長期保存用ストレージサービス。 S3に格納されたファイルを一定期間が経過したら自動的にGlacierに転送する連携機能がある。 データ保存に関するコストを低減することができる機能。 CloudFront CloudFrontはCDNのサービス。コンテンツを海外に配信する場合や、国内でも大量のデータを配信する場合などに利用。

この記事の概要 2021/08/15に AWS認定セキュリティ - 専門知識 (AWS Certified Security – Specialty (SCS-C01)) を受験したので、その時の記録 試験の概要 AWSを利用する上でのセキュリティに的を絞った試験です。 「セキュリティロールを遂行する人を対象としており、AWS プラットフォームのセキュリティ保護についての理解度を評価するものです。」 AWS公式より引用：引用元 ◼︎ 試験要項 問題数　　：65問 試験時間　：170分 受験料　　：¥30,000(税別) 合格ライン：100~1000点中750点(約72%) 受験資格　：なし 有効期限　：3年 ◼︎ 出題範囲 分野 出題割合 分野 1: インシデント対応 12% 分野 2: ログ収集と監視 20% 分野 3: インフラストラクチャのセキュリティ 26% 分野 4: IDとアクセスの管理 20% 分野 5: データ保護 22% 2021/08時点の最新バージョン(Ver.2.0)のものです。 バージョンアップで範囲等は変更されるので、受験時は公式で確認してください。 AWS 認定 セキュリティ - 専門知識 | AWS 勉強開始前の状態 AWSで動いているWebアプリ開発の業務経験4年(SDKによる開発を2年、インフラの設計構築は1年程度) アソシエイト3種とSAP取得済み AWSソリューションアーキテクトを受験した時の話 https://qiita.com/aminosan000/items/24c6dff9532658a5c4d5 AWSデベロッパーアソシエイトを受験した時の話 https://qiita.com/aminosan000/items/89bc76f77626314f3182 AWS SysOpsアドミニストレーターアソシエイトを受験した時の話 https://qiita.com/aminosan000/items/b1765260e8ad1435a366 AWS認定ソリューションアーキテクトプロフェッショナルを受験した時の話 https://qiita.com/aminosan000/items/f172b7add8303926bddc 勉強に使ったもの 1. 試験対策本 要点整理から攻略する『AWS認定 セキュリティ-専門知識』 (Compass Booksシリーズ) 2021/06時点での唯一のSCS対策本、いままで購入していたシリーズとは異なりますが、要点を抑えてあってなかなか良かったです。 ただ、この本に書かれている内容だけだと各サービスの詳細など出題範囲を網羅できていない感じはあるので、その他の教材も合わせて利用します。 2. オンライン練習問題(非公式) AWS Certified Solution Architect Professional | Whizlabs AWS認定対策として毎回購入しているWhizlabs、SCSのコースは最新のバージョンの問題が315問(65問×4パターン+サービス別問題40問+無料問題15問)用意されています。 今回50%offクーポンが使えたので、価格は 19.95USD の 50%off で 9.97USD でした。(利用できる最新のクーポンは「whizlabs coupon」で検索) いつもどおり、Google翻訳で翻訳しながら日本語が怪しい部分は原文とあわせながら利用。 3. AWS公式模擬試験 前回合格時クーポンを利用して、勉強開始時の実力確認に利用 1.の対策本だけ読んだ状態で実施して正答率45%(9/20問)、SAP持ってるしサンプル問題は全問正解だったから余裕かと思っていたが、SAPとは重複していない範囲も広く予想よりスコアは低かった。 4. Black Belt Online Seminar過去資料 サービス別資料 | AWS クラウドサービス活用資料集 対策本や練習問題を解きながら理解不足を感じたサービスの資料を見て学習 5. AWSアカウント 解答/解説やBlack Belt過去資料を見ていてイメージしづらい部分は実際にマネコンでUIを見てみたり、公式チュートリアルに沿って一度触ってみて理解を深める。 **6. 公式デジタルトレーニング Exam Readiness: AWS Certified Security - Specialty AWS公式の「AWS認定セキュリティ - 専門知識」向けトレーニング資料も用意されているので活用。 日本語で提供されているが、翻訳が怪しい部分もいくつかある・・・ 最後の模擬テストも誤訳によって正答を導けなくなっているような部分もあるが、公式模試や実試験と類似の内容もいくつかあったり、試験範囲で問われる内容についてわかりやすく説明してくれているので、受ける価値はある。 (「IAMロール」→「IAMユーザ」となっていたり、「WAF」を「Well Architectedフレームワーク」と訳してしまっていたり) 学習の流れ 以下の流れで勉強実施 対策本(体系的に学習) 　↓ 公式模試(実力確認)　 　↓ 練習問題(実際の出題内容をインプット・アウトプット) 　↓ Black Belt(苦手箇所の解消)+実操作 忘れそうな部分や、より理解を深めたい部分は自分の言葉で要約しながらメモとしてアウトプットして、毎日勉強開始時に見返す。 勉強時間 約50時間 SAPでは深く問われないサービス KMS、ACM、GuardDuty、Inspector、Macieあたりの知識とポリシー関連の出題が多いので、公式ドキュメントやネットの記事を見ながら学習。 特にKMS・ACMは理解が浅かったのでBlack Beltも見ながらマネコンで操作してみて時間をかけて理解。 受験後 結果はスコア936で合格、180分使ってちょうど全問きっちり見直しが終わるぐらい。 SAPのときよりは余裕を持って「受かったな」と思いながら提出できました。 防止・監視・インシデント対応の具体的な方法がイメージできるようになったので、仕事で活かせるスキルアップにもなったような気はします。 AWS認定10冠(CLF以外全部)まであと半分！ 次は未知の分野Machine Learning、Data Analyticsか…無難にDB、NWか… また受験したら書いていきます。 勉強になったことメモ 試験のために勉強しながら忘れないように書き溜めたメモたち ※ここに書いてあることはあくまで私が理解が足りないと感じ覚えたかったことで、必ずしも試験で出る範囲ではありません。試験範囲を網羅はしていません。 ■ 全般 ・予防的統制と発見的統制 予防的統制(Preventive Control)：リスクを未然に防ぐ(SCPなど) 発見的統制(Detective Control)：リスク発生時に発見して対処する(Config Rules+SSMなど) ・フォレンジック フォレンジック(Forensics)とは、犯罪の法的な証拠を見つけるための鑑識捜査を指す。 その中でも特に、コンピュータやデジタル記録媒体の中に残された証拠を調査・解析する分野をデジタルフォレンジックという。 ・インシデント発生時の対応 インシデント(ウイルス感染や踏み台にされているなど)を検知した場合、セキュリティグループにより論理的にNWから切り離す。 切り離し後、EBSスナップショットやメモリダンプを取得し調査する。 ASG配下のインスタンスの場合はスナップショット取得等のための停止によりターミネートされないよう、先にASGからデタッチする。 ■ 監査 ・AWS Artifact 下記の第三者による監査レポートをダウンロードできるサービス。 Global Financial Services Regulatory Principles ISO Payment Card Industry(PCI) Service Organization Control(SOC) Quality Management System Overview ・AWS管理ポリシー AWS管理ポリシーの中には監査向けなどの職務機能のポリシーがある。 職務機能 AWS管理ポリシー名 管理者の職務機能 AdministratorAccess 請求職務機能 Billing データベース管理者の職務機能 DatabaseAdministrator データサイエンティストの職務機能 DataScientist デベロッパーパワーユーザーの職務機能 PowerUserAccess ネットワーク管理者の職務機能 NetworkAdministrator 読み取り専用アクセス ReadOnlyAccess セキュリティ監査の職務機能 SecurityAudit ユーザー職務機能のサポート SupportUser システム管理者の職務機能 SystemAdministrator 表示専用のユーザーの職務機能 ViewOnlyAccess ※補足 SupportUser：サポートに問い合わせするためのポリシー ViewOnlyAccess：ReadOnlyAccessと似ているが、Describe、Listなどリソースの存在やメタデータのみ表示できるポリシー ・認証情報レポート 監査のための情報として、アカウントのすべてのユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータスが示された認証情報レポートを生成しダウンロードすることができる。 認証情報レポートは、マネコン(IAMのコンソールから)、AWS SDK、CLI、またはIAM APIから取得できる。 ・AWS Configの活用 AWS Configを利用することで利用中のAWSリソースのレポートを生成することができる。 ■ AWS IAM 基本は以前勉強したことの思い出し AWS IAM再入門 ・IAMアクセスアドバイザー アカウント内の個々のIAMリソースのアクセス可能なAWSサービスと最終アクセス履歴の取得ができる。 ・IAMアクセスアナライザー 対称リソースのリソースベースポリシーを分析して信頼ゾーン(自アカウント or Organizations全体)外部のエンティティからアクセス可能になっていないか調査できる。 ・アクセス許可の境界(Permission Boundary)使い所 OUやアカウント単位で許可範囲を絞りたいときはSCPだが、特定のロールに対して許可範囲を絞りたいときはPermission Boundaryを利用する。 ・ポリシーの条件演算子 意外と知らない演算子があって勉強になったのでメモ 模試や本番試験でもポリシーが問題文や選択肢に登場する問題は結構多いので、どんなものがあるかは要把握。 Stringxxx系は大文字/小文字区別ありなし(IgnoreCase)とワイルドカードありなし(EqualsorLike)がある 一部のサービスにはArnEquals、ArnLikeが使える 全ての条件演算子の末尾にIfExistsを追加できる ※条件キーが存在しないときtrue Nullは条件キー自体の存在有無をチェックする CLIによるアクセスの際はaws:MultiFactorAuthPresentキー自体が存在しないので、↓のようにIfExistsをつけないとCLIでの操作にMFAを強制できない。 { "Effect" : "Deny", "Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : "false" } } 参考： https://aws.amazon.com/jp/premiumsupport/knowledge-center/mfa-iam-user-aws-cli/ ・グローバル条件キー KMSキーポリシーやS3バケットポリシーでは専用の条件キー(kms:xxx、s3:xxx)があるが、これらのリソースベースポリシーや、ロールベースポリシーで共通で利用できる条件キーもある。 例） aws:SourceVpceはKMSやS3にVPCエンドポイントを作成した際、アクセス元のVPCを制限する際に利用 aws:TokenIssueTimeは一時的な認証情報を利用している(アクセスキーを利用していない)場合のみ許可する際等利用 ・アシュームロールのセッション時間 アシュームロールで引き受けたロールのセッション時間はそのIAMロールの設定で変更できる。 秒単位で3,600(1時間)~43,200(12時間)の範囲を指定できる。 ■ AWS Systems Manager SSMはサーバを管理/運用するための複数の機能群をまとめたサービス 主な機能は以下 機能名 内容 セッションマネージャー(Session Manager) マネコン上でインスタンスにSSHやPowerShellで接続できるセキュリティグループの許可やSSHキーの登録も不要、認証をIAMに集約できるデフォルトの「ssm-user」は権限が強いため、「Run As」設定を利用することが推奨される メンテナンスウインドウ(Maintenance Windows) Cron式またはRate式でスケジュールを設定し、この時間内にAutomationなどのタスクを実行させるよう事前定義できる。 実行コマンド(Run Command) インスタンスに対するコマンドの実行を自動化する複数のサーバに対し一括で同時にコマンドを実行できる同時に実行するサーバのレート(割合)を指定することもできる オートメーション(Automation) 定期的に実行が必要な運用管理タスクを自動化する複数の処理ステップを「Automation Document」として記載(JSON or YAML)"複数ステップ"の定義ができることとAWSサービスの設定変更などができることがRun Commandとの違い ステートマネージャー(State Manager) サーバを予め定義された状態に維持する為に利用Run CommandとAutomationを定期実行させる インベントリ(Inventory) インストールされたソフトウェアの情報を一覧表示するS3へインベントリ情報を同期することもできるAWS Configの「ec2-managedinstance-inventory-blacklisted」を利用するとBLに定義した禁止SWのインストールを検知することもできる パッチマネージャー(Patch Manager) パッチの適用状況の確認および自動適用を行えるパッチベースラインとして対象OSバージョンや適用対象のパッチの重要度、公開後の日数を設定するパッチ適用状況のレポート生成も可能になった パラメータストア(Parameter Store) パスワードや環境変数などの複数のAWSサービスで共有で利用したいパラメータを保存する ドキュメント(Document) Run CommandやState Managerから実行するアクションを保存(定義)することができる事前定義されたマネージドのDocumentもある OpsCenter AWS上で発生したイベントを管理する。自動でチケット起票させられるインシデント管理ツール Explorer インスタンス数、パッチ適用状況、OpsCenterのイベント状況をダッシュボードで確認することができるマルチリージョン、マルチアカウント対応 Change Calendar Cronでは表現できないような、カレンダー形式のスケジュールを定義し、Automationなどの実行を許可/拒否ができる(WL/BLどちらか選べる)iCal形式で保存され、EventBridgeとの連携によりLambdaなどの実行も可能(2020/11より追加) AppConfig アプリケーションの設定データを管理、LambdaやEC2上のアプリケーションを停止することなく安全に、設定を更新できるデプロイするインスタンスの比率設定などもできる コンプライアンスCompliance パッチコンプライアンス、および設定の不整合についてマネージドインスタンスのフリートをスキャンするために使用できる フリートマネージャー(Fleet Manager) 統合されたユーザーインターフェイスで、AWSまたはオンプレミスで実行されているサーバー群をリモートで管理できる1つのコンソールからサーバーフリート全体の正常性とパフォーマンスステータスを表示できる これらを組み合わせてサーバを管理する 例 ) Documentで実行内容を定義 Run Commandで1のDocumentで実行するコマンドと対象サーバを定義 メンテナンスウインドウで2のRun Commandの実行スケジュールを定義 Change Calendarで例外的に実行させない日時を定義 ■ AWS Config AWS Configでできること 設定の変更履歴を確認 設定変更を検知し、通知や自動修復 AWSリソースの利用状況レポートの生成 「高度なクエリ」を利用することでSQLにより特定の条件で設定変更のイベントを検索することもできる。 事前定義されている「マネージドルール」とLambdaで自由に実装する「カスタムルール」がある。 主要なマネージドルールは以下 ルール名 内容 approved-amis-by-id 実行中のインスタンスが指定したAMI IDになっているか ec2-instance-no-public-ip インスタンスにパブリックIPが関連付けされていないか encrypted-volumes EBSボリュームが暗号化されているか restricted-ssh セキュリティグループのインバウンドSSHのIPアドレスが制限されているか rds-instance-public-access-check RDSパブリックアクセスが無効になっているか cloudtrail-enabled CloudTrailが有効になっているか required-tags 指定したタグがリソースに設定されているか vpc-flow-logs-enabled VPC Flow Logsが有効になっているか guardduty-enabled-centralized GuadDutyが有効になっているか iam-password-policy IAMパスワードポリシーが文字数、記号などの要件を満たしているか iam-root-access-key-check rootユーザのアクセスキーが作られていないか iam-user-mfa-enabled IAMユーザのMFAが有効になっているか access-key-rotated アクティブなアクセスキーが指定された日数内にローテーションされているか(指定可能な日数は最大90日) s3-bucket-public-read-prohibited S3のパブリック読み込みが禁止されているか s3-bucket-public-write-prohibited S3のパブリック書き込みが禁止されているか s3-bucket-server-side-encryption-enabled S3のサーバサイド暗号化が有効になっているか Configルールに反していることを検知した場合のアクションとして自動修復を設定する方法は以下の2種類 System Manager Automationによる事前定義された修復(2019年9月追加、実装不要) ConfigをCloudWatchイベントのイベントソースに設定し、Lambdaのトリガーにする カスタムルールによるチェックは1,3,6,12,24hの定期実行が可能。 ■ AWS CloudTrail CloudTrailのログを保護する方法はいくつかある KMSを利用した暗号化：利用するCMKのポリシーにより操作できるユーザを絞る MFA Delete：S3の機能によりMFAを利用しないと削除できないようブロックする 別アカウントへの出力：ログの保管先は異なるアカウントのバケットも指定できるため、別アカウントのバケットへ出力することで保護する CloudTrailを利用した検知はCloudWatch LogsのアラームとCloudWatchイベントのどちらかで行える。CloudWath Logsのほうが細かい検知が可能だが、CloudWatch Logsの利用料もかかってくるため、コストが増える。 CloudTrailで取得できるイベントは以下の3種類、デフォルトで有効なのは管理イベントのみ イベント 内容 管理イベント マネコンへのログインとAWSリソースの作成・変更・削除などの管理操作 データイベント S3バケット上のオブジェクトへの操作、Lambda関数の実行等のデータプレーンオペレーション インサイトイベント AWSアカウント内で検知された異常なアクティビティ CloudTrailの証跡はデフォルトでSSEが有効 ログファイルの整合性の検証 CloudTrailがS3へ保存したログファイルが変更、削除されなかったかどうかを判断するための機能。 証跡の作成時にこの機能を有効にするとログファイルのハッシュ(ダイジェストファイル)がS3に作成される。 アカウントへの不正アクセスの疑いがある場合、下記のAWS CLIでログには変更が加えられていないことを検証できる。 コマンド例 aws cloudtrail validate-logs \ --trail-arn arn:aws:cloudtrail:us-east-2:111111111111:trail/example-trail-name \ --start-time 2015-08-31T22:00:00Z \ --end-time 2015-09-01T19:17:29Z \ --verbose ■ AWS X-Ray サービス間のリクエストをトレースできる。 対応するサービスはEC2, ECS, Lambda, Elastic Beanstalk(Java, Node.js, .NET) X-Ray SDKの統合(ライブラリのインストール+初期化処理の実装)とX-Rayエージェントのインストール(EC2, ECSの場合)が必要 ■ Amazon QuickSight マネージド型のBI(ビジネス・インテリジェンス)サービス、以下をデータソースとしてビジネス分析のための可視化を行える。 Amazon Athena Amazon Redshift Amazon Aurora MySQL(オンプレも可) PostgreSQL(オンプレも可) S3(CSV/TSV/CLF/ELFのテキストファイル)※ELBアクセスログなどの圧縮ファイルの場合、Athenaを経由 その他SaaS(Salesforceなど) ■ AWS KMS 覚えることが多いので個別にまとめ ■ AWS CloudHSM 特徴 対称キーと非対称キー両方対応 対障害性や可用性はユーザが担保(クラスター作成時にVPCとAZを指定できる) KMSよりコストがかかる 目的 専用のHWが必要などのコンプライアンス要件がある場合 キーの管理をAWSに委任したくない(AWSからもキーにアクセスさせない)場合 キーをVPC内に配置してアクセス制御をしたい場合 ■ AWS Certificate Manager(ACM) ・複数リージョンでの適用 ACMで発行した証明書エクスポートやリージョン間のコピー不可、複数リージョンで同一ドメインを利用したい場合それぞれで作成が必要。 ・証明書の自動更新 自動更新を行うために必要な前提条件 証明書の各ドメインとHTTPS接続を確立できる状態であること 各接続で返される証明書がACMの証明書と一致すること ACMに統合されるサービス(ELB等)に関連付けられていること ACMが証明書に記載されているドメイン名を検証できること インポートされた証明書ではないこと ・プライベートCA プライベートCAはリージョン単位で作成が必要。 ACMのプライベートCAでは監査レポートをS3に出力できる。監査レポートにはCAが発行/取り消しした証明書のARN、サブジェクト、有効期限などの情報が含まれる。 SNI(Server Name Indication) 一つのサーバで複数の証明書を利用する技術(AWS固有ではない) ALBもSNIに対応しているため、1つのリスナーに複数の異なるドメインの証明書を登録できる。 ■ AWS Secrets Manager シークレットの管理サービス、RDSの認証情報の自動ローテーションが簡単に行える シークレットのローテーションを有効にすると、AWS管理のLambda関数がデプロイされる。 SSM Parameter StoreのSecureStringでも似たことができる。自動ローテーションが必要な場合Secrets Manager、そうでない場合Parameter Storeが推奨。 ・マルチユーザローテーション シークレットのローテーション時に新しいシークレットが有効になるまでの間ダウンタイムが発生する可能性がある。 マルチユーザローテーションを有効にすることで、2つのシークレットが交互に利用されるため、新しいシークレットが作成された後も古いユーザが即時無効にはならない。 ■ Amazon VPC Flow Logs(VPCフローログ) VPC Flow Logsで取得できるのは送信元/送信先IP、送信元/送信先ポート、通信許可/遮断などのNWの基本情報。 ログ保存先はCloudWatch Logs/S3から選択できる。保存のコストはS3のほうが低い(0.025USD/1GB:0.76USD/1GB)ため、監視の要件がなく、検索の頻度が低い場合S3推奨。 監視目的でCloudWatch Logsを利用する場合、古いログはアーカイブする設定を有効にするとコストが削減できる。 利用にはENI単位でフローログの作成(有効化)が必要。 ■ Amazon Macie 機械学習を使ってS3に保存されている機微情報(機密データ)を検出できる。 個人識別情報(PII)などのデータを特定し、通知や保護処理を実行することが出来る。 Macieで機密データが検知されるとCloudWatchイベントに送信されるため、SNSによる通知やLambdaによる保護処理を設定する。 検知は15分以上(設定可能)の間隔で定期実行 検出できる情報の例 氏名フルネーム メールアドレス クレジットカード番号、有効期限 運転免許証ID(米国) 生年月日 AWSシークレットキー OpenSSHプライベートキー 日本語の情報検知には対応していないが、「カスタムデータ識別子」として正規表現によるパターンマッチングもできる。 ■ Amazon GuardDuty AWSの各種ログを自動的に取得して、機械学習で分析して脅威を検知+通知してくれる、2017年に公開 設定は有効/無効と検知設定のみ(ほぼ) GuardDutyのインプット情報は以下の3つ CloudTrail VPC Flow Logs DNS Logs GuardDutyで検知できる脅威は以下 一部抜粋： アカウント内のEC2インスタンスが暗号通貨関連のIP|ドメインへリクエストしている アカウント内のEC2インスタンスがブルートフォース攻撃と思しき挙動をしている S3のパブリックアクセスブロックがアカウントレベルで無効になった S3またはIAM APIが特定のLinuxディストリビューション(KaliLinux|ParrotLinux|PentooLinux)から呼び出された アカウントルートのクレデンシャルでAPIが呼び出された CloudTrailが無効にされた IAMのパスワードポリシーが弱化された ■ Amazon Inspector EC2にエージェントをインストールし、潜在的なセキュリティ上の問題(NWアクセス及び実行されているアプリケーションの問題)を発見するホスト型脆弱性診断サービス。 ※ネットワーク評価はエージェントのインストールなしで実行可能。 ルールパッケージ ルール内容 評価種別 Network Reachability(ネットワーク到達可能性) Security Groupなどの各種ネットワークリソースの設定を分析し、 インターネット、Direct Connect、VPCピアリングなどの外部ネットワークから、EC2インスタンスに到達できるかどうかを評価、ポート開放状況だけでなく、アクティブなリスニングプロセスの有無も評価される ネットワーク評価 共通脆弱性識別子(CVE) CVEの該当有無チェック 東京リージョンチェック対象リスト ホスト評価 Center for Internet Security (CIS) ベンチマーク Center for Internet Security (CIS) ベンチマークに基づいたチェック ホスト評価 Amazon Inspector のベストプラクティス SSHのrootログイン、SSHバージョン、SSHパスワード認証、パスワード設定、DEPの有効化、アドレス空間配置のランダム化（ASLR）の有効化、システムディレクトリでのroot以外のユーザ書き込み権限有無 ホスト評価 ■ AWS Shield AWS ShieldはAWSのNWインターフェースになるサービスに無料で自動適用、Shield Advancedは有料 ・Shield Advancedを利用する目的 Shield Advancedを有効にすることでAWS DDoSレスポンスチーム(DRT)に対応を支援してもらえる。 DRTはDDoS攻撃を緩和するWAFルールの作成や攻撃の分析/診断/可視化などを提供してくれる。 DDoS攻撃による使用量の増加による請求を無効にする「スケーリングへの DDoS コスト保護」を受けられる。 ■ AWS Security Hub GuardDutyやMacie、Inspector、Firewall Manager、IAM Access Analyzerなどによる検知状況を1箇所で確認できる、2019/6公開 CIS AWS Foundations BenchmarkやPCI DSSといった基準に従ったコンプライアンスチェックもできる ■ Amazon Detective VPC Flow Logs、CloudTrail、GuardDutyなどをインプットに、潜在的なセキュリティ問題や不審なアクティビティを分析、調査できる。2020/4公開 過去のログやイベント情報をグラフで視覚化することができ、時間帯、実行数、実行内容など傾向分析に利用できる。 ■ AWS Audit Manager AWSの使用状況を継続的に監査して、リスクの評価方法と規制や業界標準への準拠を簡素化する際に役立つサービス ■ AWS WAF AWS WAFのロギングを行うためにはKinesis Data Firehoseにログを送信させる必要がある。 ALBにWAFをアタッチした状態でALBのログを有効にしてもALBのログで見られる情報はWAFに弾かれて403を返したことだけ。 WAFの設定で登場する要素の関係は「条件 in ルール in ACL」 ・AWS WAFで設定可能な条件 条件 リクエストを許可またはブロックする基準 クロスサイトスクリプティングの一致 リクエストに悪意のあるスクリプトが含まれているおそれがあるかどうか IPの一致 送信元のIPアドレス 地理的な一致 リクエストの発生元の国 サイズの制約 リクエストが指定した長さを超えているかどうか SQLインジェクションの一致 リクエストに悪意のあるSQLコードが含まれているおそれがあるかどうか 文字列の一致 リクエスト内の文字列 正規表現の一致 リクエスト内の正規表現パターン ■ Amazon Route53 DNS Resolver Firewall VPCからのアウトバウンドDNSリクエストを保護する。 悪意のあるサイトへの不良な名前解決をさせないなど、DNSを悪用した攻撃からの保護に利用。2021/04公開、現時点では試験には出ないはず。 ■ AWS Firewall Manager 複数のアカウントおよび複数のリソース間でFirewallに関する設定(AWS WAF,AWS Shield Advanced、Amazon VPC セキュリティグループ、AWS Network Firewall、およびAmazon Route53リゾルバーDNSファイアウォール)をまとめて管理できる。保護を一度設定するだけで、既存のアカウントやリソース、追加する新しいリソースに自動的に適用させることができる。2018/5公開 ■ AWS Network Firewall VPC向けのステートフルなマネージドネットワークファイアウォールのサービス。 インターネットゲートウェイ、NATゲートウェイ、VPC、DirectConnectなど "VPCの境界で" トラフィックをフィルタリングすることができる。2020/11公開 ※あまりユースケースは多くない、試験でもでないかもしれない。 ↓AWSのファイアウォール関連のサービスや機能の比較、使い分け サービスor機能 用途/概要 AWS Firewall Manager アカウントをまたいだファイアウォール管理 Amazon Route53 DNS Resolver Firewall DNSを悪用した攻撃からの保護 AWS Network Firewall VPCピアリングやDX利用時のVPC間のアクセス制御 AWS WAF CloudFrontやELBなどのネットワークの入り口でのIP制限やL7の要素による防御 Network ACL サブネット単位のアクセス制御 Security Group ENI単位(インスタンスやELB単位)でのアクセス制御 ↓覚えやすいように図にしてみた ■ AWS Single Sign-On 既存Directoryサービスや外部IDPを利用した認証でAWSへログインできる。 複数アカウントへのスイッチロールも可能。 ActiveDirectory(AD)を利用する場合ADのグループとIAMロールの紐付けを行うことで、権限を制御する。 前提条件としてAWS Organizationsの「すべての機能」が有効になっている必要がある。 ■ Amazon Cognito ・Cognitoの２つのプール プール 目的 ユーザープール ・ユーザそのものを登録するプール、Cognitoのみで認証をする場合に必要・API Gatewayのオーソライザーに設定するのはこっち IDプール ・ユーザに一意のIDを作成し保存するプール、その他のSAMLやWEBIDフェデレーションで認証した結果に対し、認可をするのに利用・ゲストログインが可能にするための許可設定はこっち スコープ：ユーザ属性の定義(name、email、profileなど) アプリIDとアプリシークレット：IdPとの紐付け/認証のための情報 ・ユーザープールワークフローのカスタマイズ Lambdaトリガーを利用し、認証フローをカスタマイズすることができる。 ■ AWS Direct Connectにおけるセキュリティ AWS Direct Connect(DX)を利用することでVPCと企業NWを物理的に専用線接続できるが、DXの通信は暗号化されないため、「暗号化」という要件が含まれる場合、VPNと組み合わせる必要がある。DXでVPNを利用する場合パブリック接続の必要がある。 ■ Amazon CloudFrontにおけるセキュリティ ビューワープロトコルポリシー：CloudFrontでHTTPSを強制させる設定 OAI(オリジンアクセスアイデンティティ)：S3バケットの読み取りをCloudFront経由のみに制限するための機能 ■ Amazon Kinesisにおけるセキュリティ ・ストリームの暗号化 サーバサイド暗号化機能を利用することでKinesisストリームストレージレイヤーの書き込み時にKMSのCMKにより暗号化される。 ・KCLに必要なポリシー KCLを利用するIAMユーザまたはIAMロールはDynamoDBとCloudWatchのWriteを許可する必要がある。 DynamoDBでのアプリケーションの状態情報の保持、CloudWatchへのメトリクス送信を行うため。 ■ Amazon DynamoDBにおけるセキュリティ ・DynamoDBの暗号化 DynamoDBに格納するデータはKMSのCMKで強制的に暗号化される。 テーブル作成時にCMKの種類を選択できる。 テーブル作成後の変更も可能。 DynamoDBとの通信はAPI経由でHTTPSで行われるため、必然暗号化される。 ・DAXの暗号化 DAXはクラスター作成時に暗号化の有効/無効を選択する。作成後の変更は不可。 ■ Amazon S3におけるセキュリティ ・バケットポリシーの条件キー バケットポリシーのConditionとして指定するキー名は知らないと答えられないので覚える ※逆に基本的なものを知っておけばこれだけで得点につながる 条件キー 内容 値 s3:x-amz-grant-full-control リクエストにs3:x-amz-grant-full-controlヘッダーが含まれる 正規ユーザID(例："id=AccountA-CanonicalUserID") s3:x-amz-acl オブジェクトACLの付与 ACL名 s3:x-amz-server-side-encryption サーバサイド暗号化が有効 暗号化アルゴリズムを表す文字列 s3:x-amz-copy-source コピー元バケット バケット名とオブジェクトキーを表す文字列(例："bucket/folder/*") s3:VersionId オブジェクトのバージョンID バージョンID s3:x-amz-storage-class オブジェクトのストレージクラス ストレージクラスを表す文字列(例："STANDARD_IA") s3:TlsVersion TLSバージョン※"NumericGreaterThan": {}で指定したバージョン以上かを条件にできる TLSバージョンを表す数値 s3:LocationConstraint バケットのリージョン リージョンを表す文字列 s3:prefix オブジェクトキーのプレフィックス オブジェクトキーのプレフィックス ・ポリシーと2つのACL ACLにはバケットACLとオブジェクトACLがある。 種類 用途 バケットポリシー バケット全体へのアクセス制御、ポリシーなのでJSON バケットACL ・アカウント単位のアクセス許可のみ設定できる、バケットポリシーのような条件付きの許可はできない。・明示的な許可のみ設定するWL方式・S3のアクセスログの保存先バケットに対し使用が推奨される。それ以外のバケット全体へのアクセス制御はバケットポリシーを利用する。マネコンやCLIのオプションで設定。 オブジェクトACL ・アカウント単位のアクセス許可のみ設定できる、バケットポリシーのような条件付きの許可はできない。・明示的な許可のみ設定するWL方式・クロスアカウントアクセスを行う場合、オブジェクトの所有者がオブジェクトACLにより権限を制御する。・オブジェクト単位でアクセス制御を行いたい時。マネコンやCLIのオプションで設定。 ・データ格納時の暗号化 SSE(サーバサイド暗号化)の種類と使用するキー 種類 キー SSE-KMS カスタマー管理CMK SSE-S3 AWS管理CMK SSE-C ユーザ指定のキー SSE-CはS3へのAPIリクエスト時にパラメータとしてキー情報を指定する。 AWS上にキー情報が保存されない。 その他 レプリケーション設定時は双方のバケットにバージョニング設定必須 ・Glacier S3 Glacierに保存されるデータは自動的にAWS管理キーで暗号化される。 それ以外のキーで暗号化したい場合、クライアントサイド暗号化を利用する。 ・オブジェクトのロック ユーザの操作ログなど修正が許されないオブジェクトはGlacierのボールトロック(VaultLock)を行うことで変更や削除ができなくなる。 ボールトロックは下記の通りAPI Callにより状態遷移する。 API Call Call前の状態 Call後の状態 備考 ロック開始(InitiateVaultLock) ロックなし テスト状態(InProgress) ボールトロックポリシーをボールトに関連付ける ロック完了(CompleteVaultLock) テスト状態(InProgress) ロック状態(Locked) ボールトロックを確定させる ロック中止(AbortVaultLock) テスト状態(InProgress) ロックなし ボールトロックを取り消す テスト状態(InProgress)移行時にロックIDが払い出され、24時間の間次の状態遷移待ちの状態となる。 この間にポリシーに問題がないか検証を行う。 通常のS3もオブジェクトロックの機能がある。バケット作成時に有効化が必要で、バージョニングも合わせて有効にする必要がある。 リテンションモードをガバナンスモードとコンプライアンスモードの2種類から選択する。 モード 内容 ガバナンスモード 一部のユーザにはロック解除を許可 コンプライアンスモード rootアカウントを含めたすべてのユーザに対して変更を拒否 ■ その他忘れそうなことおさらい ・EC2接続用キーペアの秘密鍵を削除してしまったとき 新しいキーペアの生成 ルートボリュームを別のインスタンスに接続し、ボリューム上の/home/ec2-user/.ssh/authorized_keysファイルを新しい公開鍵で上書きする インスタンスを作り直しても問題ない場合、AMI作成→新規作成時に別のキーペア指定でもOK ・2種類のVPCエンドポイント ゲートウェイエンドポイント：DynamoDBとS3のみ インターフェイスエンドポイント：その他 ・リソースベースのポリシーが存在するAWSリソース例 S3バケット CMK API GatewayのAPI Lambda関数 SQSキュー

はじめに AWS 認定 データベース – 専門知識に合格したので、勉強方法を備忘として書いておきます。参考になれば幸いです。これで８冠、残り３冠・・・・がんばります・・・ 職業：現在インフラエンジニア6年目でAWSをメインに設計構築をするようになって、2年くらい。 最近はもっぱらオンプレミスからAWSへの移行などのコンサルをやることが多いです。 AWSをやる前は、VMwareやWindows、Linuxなどいろいろやってましたが、 今では、AWSが得意！と言えるくらいになってます。 他のAWS関連の資格： 　ソリューションアーキテクトアソシエイト(SAA)(2018年取得) 　SysOpsアドミニストレータアソシエイト(SOA)(2019年取得) 　ソリューションアーキテクトプロフェッショナル(SAP)(2020年取得) 　セキュリティ – 専門知識（SCS）(2021年取得) 　デベロッパーアソシエイト（DVA）(2021年取得) 　クラウドプラクティショナー（CLF）(2021年取得) 　DevOpsエンジニアプロフェッショナル（DOP）(2021年取得) 試験について SAP、DOPを取得しており、データベース関連の基礎知識はあったので、それほど難しくないかなと行く所感でした。 あまり触れたことのないサービス（Neptune、DocumentDB、QLDBなど）を中心に勉強したのと、Auroraの復習も実施しました。全体的に見て、対象サービスも限定されるので、取得はしやすいと感じました。 試験までに何をやるか 1.「AWS 認定試験に備える」を参照する これは基本です。どの試験にも共通しますが、出題範囲、見るべきドキュメント、トレーニングが列挙されています。 基本的に私の勉強方法は以下URLのリンク先を潰していくことがメインとなります。 学習のヒントとして、出題範囲や、参考とするドキュメントなど事細かにリンクが載っていますので、 最初に見ることをおすすめします。 2.試験ガイド、サンプル問題を読む 出題される分野、配分、問題の形式をしっかり読みましょう。 配分は以下のとおりです。 分野 1: ワークロード固有のデータベース設計 26% 分野 2: 展開および移行 20% 分野 3: 管理および運用 18% 分野 4: 監視およびトラブルシューティング 18% 分野 5: データベースセキュリティ 18% 試験ガイド サンプル問題 3.公式トレーニングを受ける 無料でデジタルトレーニングが受けられます。 分野ごとの基本的な解説、練習問題、模擬試験を受けることができますので、イントロとしてはちょうど良いレベル感です。ただし、このトレーニングを受けたからといって試験に受かるというわけではなく、更に深堀りして勉強することが必要です。残念ながら日本語ではないのですが、Chromeの翻訳機能を使って一通り学習しました。 Exam Readiness: AWS Certified Database - Specialty 4.参考書を読む 以下の本を購入しました。 この本はかなりよかったです。 試験に出題されるサービスを網羅的に抑えていて、試験のポイントとなりそうな機能や仕様を解説してくれています。 この本だけでも十分合格できるレベルかと思います。 5.問題集を解く 先程の本の問題集を２周しました。かなりよくできた問題集なので、本は是非オススメです。 やはり、問題集を解くことが一番ためになります。試験で求められる知識をチェックできる、間違えた問題から苦手な分野、深堀りすべきドキュメントが参照できるというところがあるので、一番おすすめです。 Udemyも購入してみました。 本だけでもよかったかもですが、念の為・・・ 案の定英語なので、Chromeの翻訳機能を利用しました。 6.ホワイトペーパー、よくある質問、BlackBeltを見る 全体的に苦手な分野を軽く目を通すレベルでよいかなと思います。 私の場合、BlackBeltで、DMS、Neptune、ElasticCacheなど、苦手なサービスをメインに 見ました。 最後に 専門知識系の制覇に向けたスタートでしたが、順調な滑り出しだったかと思います。 対策本にだいぶ助けてもらいましたね。 結果、847点 もうちょい取りたかった！ これで、CLF、SAA、SOA、DVA、SAP、SCS、DOP、DBSの8冠を取得しました。 次回ANSの取得を目指します！

NLBのターゲットにAuto Scallingグループを指定できます。 AWS公式のドキュメントとしてはAuto Scaling グループにロードバランサーのアタッチにやり方が書いてあります。 今回はこれをTerraformでやる方法を残しておきます。 ざっくりとは普通にNLB、リスナー、ターゲットグループを作成し、Auto Scallingグループをターゲットグループにアタッチしています。 nlb.tf nlb.tf resource "aws_lb" "nlb" { name = "${var.base_name}-nlb" internal = false load_balancer_type = "network" subnets = var.public_subnet_ids tags = { "Name" = "${var.base_name}-nlb", } } nlb-listener.tf nlb-listener.tf resource "aws_lb_listener" "listener" { load_balancer_arn = aws_lb.nlb.arn port = var.listener_port protocol = "TCP" default_action { type = "forward" target_group_arn = aws_lb_target_group.target-group.arn } tags = { "Name" = "${var.base_name}-listener" } } nlb-target-group.tf nlb-target-group.tf resource "aws_lb_target_group" "target-group" { name = "${var.base_name}-target-group" port = var.target_port protocol = "TCP" vpc_id = var.vpc_id tags = { "Name" = "${var.base_name}-target-group" } } nlb-autoscaling-attachment.tf 今回のキモです。パラメータ名はalb_target_group_arnですがNLBTのターゲットグループでもちゃんと紐付けてくれます。また、今回はEKSのマネージドノードグループをターゲットとしたかったため、マネージドノードグループからAuto Scallingグループ名を引っ張ってくる書き方をしています。 nlb-autoscaling-attachment.tf resource "aws_autoscaling_attachment" "attachment" { autoscaling_group_name = aws_eks_node_group.worker.resources.0.autoscaling_groups.0.name alb_target_group_arn = aws_lb_target_group.target-group.arn } variables.tf variables.tf variable "base_name" { description = "作成するリソースに付与する接頭語" type = string } variable "vpc_id" { description = "リソース群をデプロイするVPCのID" type = string } variable "public_subnet_ids" { description = "パブリックサブネットのID" type = list(string) } variable "listener_port" { type = number } variable "target_port" { type = number }

したいこと unicornの起動を成功させたい。（エラー文master failed to start, check stderr log for details） 経緯 本番環境としてEC2を使ってポートフォリオをデプロイしようとしています。 rails6で作成したアプリです。 下記記事を参考にしています。 https://qiita.com/Yuki_Nagaoka/items/dbb185feb6d4f051c2f2 https://qiita.com/naoki_mochizuki/items/5a1757d222806cbe0cd1#unicorn%E3%81%AE%E8%A8%AD%E5%AE%9A 出ているエラー 下記コマンドを実行し、 $ bundle exec unicorn_rails -c /var/www/rails/アプリ名/config/unicorn.conf.rb -D -E production 以下の様にエラーが表示される。 master failed to start, check stderr log for details 考えられる原因 ・設定したunicorn.conf.rbに問題がある？ ・unicornのバージョンが悪い？ ・EC2にあるアプリのcredentials.yml.enc、master.key周りの設定？ とりあえずログを見る。 試したこと unicornのエラーログを見るために下記を実行。 $ cd log $ tail unicorn.log 間違っている部分は見つからず、よくわかりませんでした。 次にproduction.logをみるために下記を実行。 $ tail production.log 間違っている部分は見つからず、よくわかりませんでした。 次にunicorn_error.logを見るために下記を実行。 $ tail unicorn_error.log ファイルがない、とのことで記録を見ることができませんでした。 次に、unicorn_stderr.logがあると思い下記を実行。 $ tail unicorn_stderr.log ファイルがありませんでした。 次にアプリのディレクトリに戻り、下記を実行したところログが表示されました。 $ cat log/unicorn.log -n 気になるエラーが表示されました。 ActiveSupport::MessageEncryptor::InvalidMessage: ActiveSupport::MessageEncryptor::InvalidMessage check_for_activated_spec!': You have already activated unicorn 5.5.4, but your Gemfile requires unicorn 5.4.1. Prepending bundle exec to your command may solve this. (Gem::LoadError) →調べたところそれぞれmaster.key周りのエラーとunicornのバージョンのエラー。 unicornのgemのバージョンが5.5.0の場合はエラーが出るとのことなので5.4.1に変えてみました。 参考記事→https://qiita.com/TeruhisaFukumoto/items/f1f0be91bc7b43b4f79d →EC2内のアプリのgemを変えてbundle intallができたので、再び下記コマンドを実行したところ同じエラーが表示されました。 bundle exec unicorn_rails -c /var/www/rails/Portfolio/config/unicorn.conf.rb -D -E production →すると下記のエラー。 master failed to start, check stderr log for details 先ほどおぼえたcat log/unicorn.log -nコマンドを使って558番以上の最新のログをみてみたところ、下記のエラー文が見つかりました。 ActiveSupport::MessageEncryptor::InvalidMessage: ActiveSupport::MessageEncryptor::InvalidMessage ActiveSupport::MessageEncryptor::InvalidMessage: ActiveSupport::MessageEncryptor::InvalidMessageというエラー文があったのでcredentials.yml.enc、master.keyを確認。 ローカルのアプリにて以下を実施し、master.keyをメモ。 $ vi config/master.key サーバー環境のアプリ内でmaster.keyを開きローカル環境のmaster.keyを貼り付け:wq。 $ vi config/master.key ローカル環境にて下記コマンドでシークレットキーを発行し、サーバー環境にあるアプリのcredentials.yml.encに貼り付けて保存。 $ bundle exec rake secret そして下記を実行したところ、同じエラーが表示されました。 $ bundle exec unicorn_rails -c /var/www/rails/Portfolio/config/unicorn.conf.rb -D -E production ここまでの考察 ・credentials.yml.enc、master.key周りの設定が怪しい。 ・unicornのバージョンの問題はなし。 ・ログの中にdirectory for pid=/home/username/appname/tmp/pids/unicorn.pid not writable (ArgumentError) というエラーが見つからないので、権限周りの問題ではない。 ・ArgumentError: wrong number of arguments (given 0, expected 2) というエラーはないので、unicorn.conf.rbの設定ファイルによるエラーではない。 ・他にエラーログがある？ というわけで、とりあえずローカル、サーバーのcredentials.yml.enc、master.key周りを確認してみる。 解決法 犯人はローカル環境にて行った$ bundle exec rake secretだった。 $ bundle exec rake secretにより、ローカル環境のmaster.key、credentials.yml.enc、サーバー環境のmaster.key、credentials.yml.encが噛み合わなくなっていたのが原因です。 私の環境はrails6.0。したがってcredentials.yml.encでのキーの管理をする必要がある。 もっと詳しくいうと、私は以前ローカル環境にあるmaster.key、credentials.yml.encを消して、ローカル環境で何回もEDITOR=vim bundle exec rails credentials:editをすることによって2つのキーを作っては壊しを繰り返してました。 当然サーバーとローカルの両アプリ内のキーが合わなくなるわけです。 ローカル、サーバーそれぞれ合計4つのmaster.key、credentials.yml.enc作成して紐づける手順 ・ローカルのmaster.keyとcredentials.yml.encを手作業で削除し、以下コマンドで新しく2つのキーを作成し、secret key baseをコピーしておく。 ローカル. EDITOR=vim bin/rails credentials:edit ※念の為目視でローカル環境のcinfig内に2つのキーが作られたか確認しましょう。 ・次にサーバーのmaster.keyとcredentials.yml.encを以下のコマンドで削除。 サーバ. [ユーザ名@ip-10-0-0-58 アプリ名]$ rm config/master.key [ユーザ名@ip-10-0-0-58 アプリ名]$ rm config/credentials.yml.enc ls configで消されたか確認。 サーバ. [ユーザ名@ip-10-0-0-58 アプリ名]$ ls config application.rb cable.yml database.yml environments locales routes.rb storage.yml unicorn.conf.rb webpacker.yml boot.rb credentials environment.rb initializers puma.rb spring.rb unicorn webpack 消されている。 で、サーバー環境でEDITOR=vim bin/rails credentials:editをして2つのキーを作成し、vimの編集画面に入る。 編集画面ですかさずローカル環境の際にメモをしておいたsecret key baseを貼り付けます。 [ユーザ名@ip-10-0-0-58 アプリ名]$ EDITOR=vim bin/rails credentials:edit Adding config/master.key to store the encryption key: d1616fa3117dd0c4a662c547e0c5ba28 Save this in a password manager your team can access. If you lose the key, no one, including you, can access anything encrypted with it. create config/master.key File encrypted and saved. 作れた。 念の為目視でファイルがあるかどうか確認。 サーバ. [ユーザ名@ip-10-0-0-58 アプリ名]$ ls config application.rb cable.yml credentials.yml.enc environment.rb initializers master.key routes.rb storage.yml unicorn.conf.rb webpacker.yml boot.rb credentials database.yml environments locales puma.rb spring.rb unicorn webpack credentials.yml.enc、master.keyが作れている。 サーバー環境のmaster.keyは変更しない。そのままにする。ローカルと異なっていて良い。 で、本記事の本題である以下を実行。 [ユーザ名@ip-10-0-0-58 アプリ名]$ bundle exec unicorn_rails -c /var/www/rails/アプリ名/config/unicorn.conf.rb -D -E production [ユーザ名@ip-10-0-0-58 アプリ名]$ ps -ef | grep unicorn | grep -v grep ユーザ名 27923 1 2 07:13 ? 00:00:01 unicorn_rails master -c /var/www/rails/アプリ名/config/unicorn.conf.rb -D -E production ユーザ名 27926 27923 0 07:13 ? 00:00:00 unicorn_rails worker[0] -c /var/www/rails/アプリ名/config/unicorn.conf.rb -D -E production ユーザ名 27927 27923 0 07:13 ? 00:00:00 unicorn_rails worker[1] -c /var/www/rails/アプリ名/config/unicorn.conf.rb -D -E production unicornが起動できたっぽい。 credentials.yml.encについての参考記事 https://qiita.com/scivola/items/cc06ddbfd94d3118f693 まとめ｜この認識を持ちましょう。 master.key・・・カギ。 credentials.yml.enc・・・鍵穴。

症状 AWS API Gateway で作成した APIに GET通信したら、動かなくなったので、Chromeの検証画面を見ると、こんなエラーが出ていた。 Access to XMLHttpRequest at 'https://xxxxxxx.execute-api.ap-northeast-1.amazonaws.com/xxxxx/xxxxx' from origin 'http://xxxxx.co.jp' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. 解決方法 AWS API Gateway でCORSを有効にする。 アクション > メソッドの作成 OPTIONS を選び、横のチェックマークをクリックする セットアップ画面が出るが、ここは何を入力しても影響がないらしいので、入力項目がない mock にでもチェックして、保存。 メソッドレスポンスをクリック 「▶」をクリック ヘッダーの追加 レスポンスの追加 以下追加する ・Access-Control-Allow-Headers ・Access-Control-Allow-Methods ・Access-Control-Allow-Origin 統合レスポンス すでに先ほど入力したのが反映されている。 右端の鉛筆マークをクリックしてマッピングの値を入力する。 上から ・'Content-Type,X-Amz-Date,Authorization,X-Requested-With,X-Requested-By,X-Api-Key' ・'GET,POST' ・'*' GET > メソッドレスポンス 展開して「ヘッダーの追加」 Access-Control-Allow-Origin のみ追加 CORSの有効化 APIをデプロイ これで、エラーは出ず、APIにGET通信できた。 P.S. ただ、まだこんなエラーが残っている。 APIは正常に動作するけど気になる。（未解決） Refused to get unsafe header "ETag" 参考サイト

症状 AWS API Gateway で作成した APIに GET通信したら、動かなくなったので、Chromeの検証画面を見ると、こんなエラーが出ていた。 Access to XMLHttpRequest at 'https://xxxxxxx.execute-api.ap-northeast-1.amazonaws.com/xxxxx/xxxxx' from origin 'http://xxxxx.co.jp' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. 解決方法 AWS API Gateway でCORSを有効にする。 アクション > メソッドの作成 OPTIONS を選び、横のチェックマークをクリックする セットアップ画面が出るが、ここは何を入力しても影響がないらしいので、入力項目がない mock にでもチェックして、保存。 メソッドレスポンスをクリック 「▶」をクリック ヘッダーの追加 レスポンスの追加 以下追加する ・Access-Control-Allow-Headers ・Access-Control-Allow-Methods ・Access-Control-Allow-Origin 統合レスポンス すでに先ほど入力したのが反映されている。 右端の鉛筆マークをクリックしてマッピングの値を入力する。 上から ・'Content-Type,X-Amz-Date,Authorization,X-Requested-With,X-Requested-By,X-Api-Key' ・'GET,POST' ・'*' GET > メソッドレスポンス 展開して「ヘッダーの追加」 Access-Control-Allow-Origin のみ追加 CORSの有効化 APIをデプロイ これで、エラーは出ず、APIにGET通信できた。 P.S. ただ、まだこんなエラーが残っている。 APIは正常に動作するけど気になる。（未解決） Refused to get unsafe header "ETag" 参考サイト

概要 TerraformのインストールからAWSでのEC2インスタンスの作成までの手順をまとめました。 ・Terraformをどう始めるか ・AWSリソースをコードからどうやって作成するのか 上記の2点にフォーカスをあてているため、細かい設定等は省きます。 Terraform学習の一歩目として参考にどうぞ。 環境や前提条件 OS ・macOSを使用 ・homebrewがインストール済みであること AWS ・AWSアカウントが作成済みであること ・IAMユーザーを作成しアクセスキー、シークレットキーを取得済みであること 目次 AWS CLIをインストール Terraformをインストール EC2インスタンスの構築 EC2インスタンスの更新 1. AWS CLIのインストール AWS CLIとは? AWS CLI（コマンドラインインターフェース）とは、コマンドラインからAWSのサービスを管理・操作するためのツール。 使用するメリットとしてはマネジメントコンソールでのGUI操作を自動化できることが挙げられる。 インストール手順 AWS CLIをインストール。 インストールができていることを確認。 $ curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg" $ sudo installer -pkg AWSCLIV2.pkg -target / $ aws --version IAMユーザーの設定（CLIとの紐付け） いくつか方法があるがaws configureコマンドでのセットアップが簡単な方法。 このコマンドでは下記の4つの情報の入力が求められる。 $ aws configure AWS Access Key ID: #アクセスキーID AWS Secret Access Key: #シークレットアクセスキー Default region name: #リージョン Default output format: #デフォルトはjson # 環境変数から設定する場合はこちら $ export AWS_ACCESS_KEY_ID= #アクセスキーID $ export AWS_SECRET_ACCESS_KEY= #シークレットアクセスキー $ export AWS_DEFAULT_REGION= #リージョン #設定後、下記コマンドを実行して確認 $ aws sts get-caller-identity { "UserId": "ユーザーID", "Account": "12桁のアカウントID", "Arn": "arn:aws:iam::12桁のアカウントID:user/IAMユーザー" } 意図した通りの設定内容が返って来れば、IAMユーザーとAWS CLIの紐付けは成功！ 2. Terraformをインストール Terraformとは? インフラ構成をコードで宣言し、管理の自動化を実現できるツール。 構成初期プロビジョニング、更新、破棄のいずれもTerraformを使ってコードで実行できる。 IaC（Infrastructure as Code）の実現によりインフラ環境のバージョン管理が容易く、DevOpsで開発を進めるには最適。 インストール手順 今回はhomebrewを使ってインストールする。 #Terraformのインストール $ brew install terraform $ terraform --version #tfenvもインストール $ brew install tfenv $ tfenv --version tfenvを使うことでTerraformのバージョンの管理・切り替えができる。 tfenv list-remoteコマンドでインストールできるTerraformのバージョンの一覧を表示。 tfenv installで使用するバージョンを選択してインストール。 インストールしたバージョンはtfenv useコマンドで切り替えができる。 tfebv listコマンドでインストール済みのバージョンを確認。 $ tfenv list-remote #バージョン一覧を表示 1.0.4 1.0.3 1.0.2 ... ... 0.2.0 0.1.1 0.1.0 $ tfenv install 1.0.4 #選択したバージョンをインストール $ tfenv install 0.12.5 $ tfenv list #インストール済みバージョンの確認 1.0.4が設定されている * 1.0.4 (set by /usr/local/Cellar/tfenv/2.2.2/version) 0.12.5 $ tfenv use 0.12.5 #0.12.5へ切り替え Switching default version to v0.12.5 Switching completed $ tfenv list 1.0.4 * 0.12.5 (set by /usr/local/Cellar/tfenv/2.2.2/version) #0.12.5が設定された tfenvがインストールできない！という方へ ... Error: Cannot install tfenv because conflicting formulae are installed. terraform: because tfenv symlinks terraform binaries Please `brew unlink terraform` before continuing. ... 上記のエラーが発生している場合は、brew unlink terraformを実行してから、 tfenvのインストールを再実行。 ここまででTerraformのインストールは完了！ 3. EC2インスタンスの構築 main.tfを作成 作業用フォルダにてmain.tfを作成し、コードを書いていく。 （HCL: HashiCorp Configuration Language） Terraformに触れることが目的のため、今回はEC2のみを作成しその他サービスは扱わない。 main.tf #Amazon Linux2のAMIベースにt2.microのEC2を作成 resource "aws_instance" "example" { ami = "ami-09ebacdc178ae23b7" #Amazon Linux2 instance_type = "t2.micro" } init / plan / apply main.tsを作成したら、terraform initを実行。リソース作成に必要なバイナリファイルをダウンロード。 $ terraform init Initializing the backend ... ... ... Terraform has been successfully initialized! #terraform initが成功 続いて、terraform planコマンドで実行計画を表示。 $ terraform plan provider.aws.region The region where AWS operations will take place. Examples are us-east-1, us-west-2, etc. Enter a value: #リージョン名を入力 Terraform will perform the following actions: # aws_instance.example will be created ... #リソースの情報が続く... ... Plan: 1 to add, 0 to change, 0 to destroy. #いくつの追加、変更、削除が実行されるかを表示 terraform applyコマンドでリソース作成を実行する。 $ terraform apply #コマンドではplan結果が表示され、実行して良いか確認が行われる ... #リソースの情報が続く... ... 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 #yesと入力した場合のみリソース実行に進む ... #進行状況を表示 aws_instance.example: Creating... aws_instance.example: Still creating... [10s elapsed] ... Apply complete! Resources: 1 added, 0 changed, 0 destroyed. #Apply完了のメッセージが出力されたらリソース作成の完了 マネジメントコンソールでEC2が作成されていたら成功！ 4. EC2インスタンスの更新 Nameタグ追加 作成したEC2の情報を更新する。 main.tfにNameタグの設定内容を追記し、再びterraform applyを実行。 main.tf #Amazon Linux2のAMIベースにt2.microのEC2を作成 resource "aws_instance" "example" { ami = "ami-09ebacdc178ae23b7" #Amazon Linux2 instance_type = "t2.micro" #ここから追記 tags = { Name: "my-ec2-001" } } $ terraform apply Terraform will perform the following actions: # aws_instance.example will be updated in-place ~ resource "aws_instance" "example" { ... ... Apply complete! Resources: 0 added, 1 changed, 0 destroyed. #リソースが1つ更新（changed）された 追記した内容のタグが追加される。 Apacheをインストール・起動 さらにEC2インスタンス起動時にApacheをインストールして起動させる設定を追記し、 再びterraform applyを実行してみる。 main.tf #Amazon Linux2のAMIベースにt2.microのEC2を作成 resource "aws_instance" "example" { ami = "ami-09ebacdc178ae23b7" #Amazon Linux2 instance_type = "t2.micro" tags = { Name: "my-ec2-001" } # ここから追記 user_data = <<EOF #!/bin/bash sudo su - yum install -y httpd systemctl start httpd EOF } $ terraform apply Terraform will perform the following actions: Terraform will perform the following actions: # aws_instance.example must be replaced -/+ resource "aws_instance" "example" { ... ... aws_instance.example: Destroying... ... ... aws_instance.example: Creating... ... ... Apply complete! Resources: 1 added, 0 changed, 1 destroyed. # リソースが1つ追加され、1つ削除された 今回のケースでは、既存のEC2インスタンスをそのまま更新するのではなく、 既存のEC2インスタンスを削除され、新規にEC2インスタンスを作成されている。 このようにTerraformでのリソースの更新は、 既存リソースの継続して更新 既存リソースを削除して新規で再作成 上記の2ケースで実行されることがあるため、terraform plan結果を念入りに確認しよう。 思わぬサービスダウンを引き起こす恐れがある。 その他 terraform destroyコマンドでリソースの削除。 terraform apply (or destroy) —auto-approveで実行確認をスキップできる。 yesと毎回入力する必要はなくなるが、意図しないリソースの再作成や誤削除を避けるためにも使わない方が良いと思う。 終わりに まだネットワークやアクセス関連のサービスを実装していないので、何かができるものを構築したとは言えないが、、、 今回は「Tearraformを使って、インフラをコードで構築する」という最初の一歩目をまとめてみました。 今後、その他必須のAWSサービスについても記事もまとめようと思います。