はじめに AWSには「Cloud9」というサービスがあります。 このサービスはクラウドIDEと呼ばれるもので、サーバーのファイル操作やコンソール操作をIDEで操作することができます。   Cloud9はEC2インスタンスを使用しているため、下記のメリットがあります。 サーバー上でIDEを使用しているかのようにコード開発をすることができる コード開発をしなくとも、ちょっとしたenv修正なんて使い方もGoodです 使っているパソコンのスペックが悪くても処理が重いプログラムを動かせる ネット環境さえ整っていれば、ハイスペマシンの操作をどこでもできます！ 他の人にも環境を共有することができる 同じインスタンスを見ることになるので。コンフリクトには要注意です 自分のローカル環境を汚さなくて済む スクラップ&ビルドが容易なクラウド環境でこの親和性は大変高いです！   個人的に最初触った時の衝撃が大きく、AWSサービスの中で一番好きなサービスだったりします。   さて、話は変わりますが、AWSには無料枠というものが存在します。 これはt2.microなどのインスタンスを1台分、無料で運用できるというものです。 ただし、アカウント作成から１年間の期間限定です。   GCPではus-***-1リージョンのe2-micro 系が永久に無料という魅力的な無料枠があります。 個人でちょっとしたサービスを作るときやサーバーで遊ぶ分にはこの枠が大変魅力的ですね。   ただ、GCPにはCloud9のようなクラウドIDEは存在しません。 コンソールくらいは動かすことができるのですが、vimmerなどの特殊な人以外、コード開発をするのには向いていません。   今回はそんなGCPにクラウドIDEを導入する方法を紹介します。 目次 GCPの無料枠 環境作成手順 まとめ GCPの無料枠 今回のインスタンス設定はGCPの無料枠を使うということを考慮し、下記で設定しています。 us-west1は日本に一番近いリージョンなので選択していますね。   リージョン：us-west1(オレゴン) ゾーン：us-west1-a マシン構成：e2-micro ブートディスクの種類：標準永続ディスク 30GB   参考資料：https://cloud.google.com/free/docs/gcp-free-tier/#compute 環境作成手順 まず、GCPアカウントを作っていない方はGCPアカウント・請求先アカウントの作成から初めてください。 また、請求アラート設定を行なっていない方は設定した方が安心かと思います。 今回はアカウト作成を行なった後を前提としてスタートします。   1.新規プロジェクト作成 GCPログイン後、左上の①プロジェクト→②新しいプロジェクトを選択する。 任意のプロジェクト名を設定し、プロジェクトを作成します。 GCPではプロジェクト単位でインフラを管理していきます。 プロジェクトの作成が終わったら、コンソール左上から先ほど作成したプロジェクトを選択します。 2.VMマシン作成 左のメニューよりVMインスタンスを選択します。 表示された画面より「インスタンス作成」をクリックし、インスタンス作成画面に移ります。 リージョンやマシン構成などは下記のとおり、無料枠で収まるよう、設定します。 OSは好きなもので大丈夫です。 今回はデフォルトのDebianを使用します。 ブートディスクは30GBまで無料で使用できるのでデフォルトから変更します。 今回はチェックを入れていませんが、ブログなど公開される方は「HTTPトラフィックを許可する」もしくは「HTTPSトラフィックを許可する」にチェックを入れてください。 セキュリティ設定は各々願いします。 最後に「作成」をクリックし、少し待つとインスタンスが作成されます。 3.静的外部IPアドレスの このままですとインスタンス停止のたび、IPアドレスが変わってしまうので静的なIPアドレスをインスタンスに設定します。 先ほど作成したインスタンスを選択し、画面上部の「編集」をクリックすると編集画面に遷移できます。 項目「ネットワークインターフェース」より「外部IPv4アドレス」を選択し、「IPアドレスを作成」をクリックします。 表示されたモーダルにて任意の名前を入力し、「予約」をクリックします。 最後にインスタンスの設定内容を画面左下の「保存」をクリックし、保存します。 インスタンス詳細画面にて静的IPが設定されていることが確認できますね。 これで静的IPの設定は完了です。 静的IPはインスタンスに割り当てていないと割高な料金を請求されているため、使用しなかった場合は必ず解放してください。 4.SSH通信環境の作成 次にインスタンスとSSH通信をできる環境を作成していきます。 ローカル環境のコンソールから下記コマンドなどで秘密鍵と公開鍵を作成してください。 ssh-keygen -t rsa 生成された公開鍵を下記コマンドなどで確認します。 cat id_rsa.pub それでは、公開鍵をインスタンスに設定していきます。 インスタンス詳細の上部にある「SSH」をクリックしてください。 別タブにてインスタンスのコンソール画面が表示されます。 コンソールにて下記コマンドを実行し、インスタンスに対して公開鍵を設定していきます。 cd .ssh vim authorized_keys インスタンスに公開鍵を設定し終えたらローカルのコンソール上から下記コマンドでssh通信ができるか試してみてください ssh {googleのアカウント名(.は_に置き換わる)}@{静的IPアドレス} -i ~/.ssh/id_rsa 無事、疎通確認が取れたかと思います。 次はローカル上で下記コマンドを実行し、configを編集します。 cd ~/.ssh vim config 設定内容は下記になります。 Host gcp HostName {静的IP} IdentityFile ~/.ssh/id_rsa User {googleのアカウント名(.は_に置き換わる)} ServerAliveInterval 60 TCPKeepAlive yes あとは下記コマンドを実行し、疎通確認を行います。 無事、インスタンスに入れたらsshの設定は完了です ssh gcp 5.VSCodeの設定 今回はローカルのエディタとしてVS Codeを使用していきます。 インストールされていない方は下記からインストールしてください。 https://code.visualstudio.com/ ここでは、VS CodeでのSSH接続設定をしていきます。 左のメニューから①拡張機能を選択し、②検索フォームに「ms-vscode-remote.vscode-remote-extensionpack」で検索します。 表示された拡張機能「Remote Development」を③インストールします。 無事、インストールできたら、左メニューにリモートエクスプローラが表示されます。 ①リモートエクスプローラをクリックすると、sshのconfig内容が一覧で表示されます。 先ほど設定したconfigの右にある②ボタンをクリックすると、新規 VSCodeが立ち上がります。 新規VSCodeでは画面左下にSSH通信の接続先が表示されているはずです。 これでVSCodeとインスタンスの紐付けは完了です！ ファイルを直接操作する際は「①エクスプローラー」→「②フォルダーを開く」で 下記のようにサーバー内のフォルダへアクセスすることができます。 あとはローカル環境で使用している感覚でサーバー内のソースコードを書き換えることができます。 ターミナルを開きたい場合は「ターミナル」→「新しいターミナル」で開くことができます。 ターミナルを開き、ソースコードを実行することも可能です。   以上でGCPでCloud9ライクな環境の作成は終了です！ まとめ 今回はGCP環境でCloud9のような環境を作成することができました。   この環境はGCPに限らず、どの環境でも作成することができます。 ぜひ、ご自身で試してみてください。   また、現在Cloud9を使用している場合でもCloud9よりもVSCodeを使った環境の方が いちいちコンソールにアクセスしなくて良い VSCodeの拡張機能を使用することができる といった面で、メリットが得られます。 これを機に環境を切り替えるのも良いと思います。   しかし、Cloud9にも下記のようなメリットがありますので用途に合わせて考えてみてください。 使用する時のみインスタンスを立ち上げる設定ができるのでインフラコストが安い 初期設定が1分程度でできてしまう サーバ運用とWebサイト運用・システム運用などが業者が別々で問題解決が困難、もしくは業務をワンストップでお願いしたいなどございましたら遠慮なくご相談ください。 サーバの設計や構築のみなどミニマムな業務からも承ってますので是非コムデへご相談ください。

はじめに コンテナって便利ですよね！ECSはexecが使えるようにアップデートされてからコンテナを利用する人も増えたのではないでしょうか？コンテナやサーバレス関連のアップデートは凄まじく、最近はEC2を使う機会がかなり減ってきましたね。今回はECS exec時のエラー対応方法を紹介します。 execエラー確認 最近こんなエラーがでました。 An error occurred (TargetNotConnectedException) when calling the ExecuteCommand operation: The execute command failed due to an internal error. Try again later. execのエラーが起きた場合は最初に下記の設定ができているか確認してみてください。 ・Amazon ECS タスクロールに execute-command コマンドを実行するために必要なアクセス権限がない ・コマンドを実行しているIAMロールまたはユーザーに、必要なアクセス権限がない ・AWS CLIがインストールされている ・Fargateのプラットフォームバージョン「1.4.0」以降を利用している ・「Session Managerプラグイン」をインストールしている   上記の設定すべてを対応してもエラーが解決しない場合も残念ながらあります。。その時は amazon-ecs-exec-checker スクリプトを実行してみてください。 amazon-ecs-exec-checker を使えばAWS CLI 環境および Amazon ECS クラスターまたはタスクを確認、検証できます。このスクリプトは、満たされていない前提条件 についても通知してくれます。   amazon-ecs-exec-checker スクリプト README.md 記載通りにやれば簡単に利用できます！     今回はnginxとphp-fpmのコンテナを用意して試して見ましたが問題なさそうですね！しかし、それでも最初のエラーが解決しませんでした。。。 結論 原因はタスク定義の環境変数の中に下記値が入っていたからでした。 AWS_ACCESS_KEY AWS_SECRET_ACCESS_KEY amazon-ecs-exec-checker スクリプトでも引っかからないので大変でした。。 アプリケーションへの権限付与はIAMユーザーを作成するのではなくタスクロールで権限を付与しましょう！！   参考 https://aws.amazon.com/jp/premiumsupport/knowledge-center/ecs-error-execute-command/

はじめに 昔はお金が潤沢になければ1台のサーバーにサイトをいくつもいれてデータベースは勿論共用、どちらもカリカリにチューニングをして使っていました。 バックアップはテープにとっていたとしても、リカバリの予行練習なんてしてないことも・・・。 サーバーセンターで回線借りると1Mbpsあたり五万円くらいしてた様な気がします。 時代が進みAWSなどのクラウドサービスがでてきてお金が無くてもサーバーを複数台使って冗長化できるようになるとアプリケーションの更新は複数台のサーバーにSSHでログインして同じ事しないといけなくなりました。 tmuxつかって同時作業してみたり、chef使って頑張ってみたりです。そういえばAWSでchefを使うサービスもありました。 そして、最近インフラを触っていて感じるのはSSHを使う事が減ってきたなってことです。 その理由はいくつかあります。一番大きな理由はやはりコンテナを使うようになった事です。また、LambdaやAppSyncなどのサーバーレスのサービスを商用でそれなりに使うようになって来ました。 今回kubernetesよりはわかりやすいけれどそれなりに理解するのが大変な AWS ECS の概念について解説したいと思います。 目次 ECSってなんだろう？ ECSの構成 まとめ ECSってなんだろう？ まず、前提としてEC2を使ったECSについては考えないです。 ECSはコンテナを管理する仕組みです。たとえば自分でサーバーを立ててコンテナを起動してサービスを始めたとします。 コードを修正したときにやらないと行けない事はこの様な感じだと思います。 更新したプログラムをDockerイメージにコピーする。 そのイメージをDocker HubやAWS ECRにpushする。 と、ここまではCIを入れていればやってくれますし、手作業でも１回行うだけです。その後 コンテナを起動しているサーバーにSSHログインして新しいDockerイメージをpullする。 古いコンテナを停めて新しいコンテナを作成する。 サーバーが３台あれば３回これを行います。負荷がかかってサーバーを増やす場合、AutoScalingして起動時にコンテナが立ちあがるようにしておけば良いのですがその設定も一苦労です。また、EC2インスタンスは起動するのに数分かかります。 それをECSを使えば100個コンテナがあっても一気に更新できるし、負荷がかかれば数字を変えてボタンを押すだけで必要なだけコンテナを増やすことが出来ます。 ECSの構成 基本は以下の３つで構成されています。 タスク これで一つのアプリケーションみたいな感じ コンテナの集合 例えばPHPを動かすならnginxとphp-fpmのコンテナを連携させて動かすように設定する。 タスク定義として設定する タスク定義 ≒ docker-compose.yml サービス タスクを決めた数動かし続けてくれます。 他にも例えばどのロードバランサ使うのかとか、タスクをデプロイするときは１台ずつとか全部まとめてとか色々。 サービスで動かせるタスクの種類は一つ。 クラスタ サービスとタスクのカタマリ 一番大きな集合 箱入りの饅頭とか大福を想像するとちょっと分かりやすいかもです？ そして、饅頭の種類が色々あっても構わないわけです。茶色い饅頭はPHPのサービス、白い饅頭はnodeのサービスみたいに。 タスク ➡️ あんこ サービス ➡️ 皮 クラスタ ➡️ 箱 ECSはこれらをAWSのコンソールから簡単に管理出来るサービスです。 ただし、ELBやVPCなど他のサービスのことを理解してつかう必要があります。 まとめ 上記はECSのFargateでの運用について書きました。Fargateは出た当初高かったのですが今は価格もこなれてきてEC2インスタンスより細かく制御しやすいのとFargateスポットが激安なので上手く使えばコストも抑えられます。 AWSを使う理由の１つは管理を楽にするためなので使えるサービスはどんどん使っていきたいです。 サーバ運用とWebサイト運用・システム運用などが業者が別々で問題解決が困難、もしくは業務をワンストップでお願いしたいなどございましたら遠慮なくご相談ください。 サーバの設計や構築のみなどミニマムな業務からも承ってますので是非コムデへご相談ください。

はじめに 今回はGUIでシステムを構築できる楽しげなAWSサービス「AWS Step Functions」を使ってみました。 その使用感などをお伝えできればと思います。 目次 AWS Step Functionsとは 実際に試してみた 料金体系 まとめ AWS Step Functionsとは Step FunctionsはGUIでワークフローを定義することで簡単にシステム作成することができるAWSサービスです。 プログラムやインフラを用意せず、システムを作れてしまうので、ちょっとした問題であれば爆速で解決することができてしまいます！ また、AWSサービスを直接呼び出すことができるので、他のサービスへの統合がとても簡単なところも良いところですね。 今回はそんなStep Functionsを試しに使ってみました。 参考：AWS Step Functions とは 実際に試してみた 今回はStep Functionsで解決したい課題を「定時になったらインスタンスを停止する」に設定しました。 Step Functionsではステートマシン単位で実行していきます。 ステートマシンはワークフローとIAMロールなどの設定がまとまったものと考えてください。 Step Functionsのステートマシンの起動にはEventBridgeを使用し、毎日20時にステートマシンを起動するようにします。 新規ステートマシンの作成 AWS Step Functionsを開き、「ステートマシン」> 「ステートマシンの作成」を選択します。 今回はデフォルト設定で進んでいきます。 ワークフローの作成 Step Functionsではこのワークフローをキャンバスに、視覚的に操作するだけで簡単にシステム構築することができます。 まず初めにワークフローのタイムアウトを設定しましょう。 タイムアウトは初期画面の右側「TimeoutSeconds」にて設定可能です。 今回の処理は時間がそこまでかからないので60秒で設定しています。 ここはシステムの処理に合わせて設定してください。 また、タイムアウトの設定画面は背景をクリックすることで表示されます。 次にワークフローにアクションを追加していきます。 今回のシステムはインスタンスを停止させることが目的なので、インスタンスを停止するアクション「StopInstances」を追加します。 「ec2 stop」でアクションを検索すると「StopInstances」がヒットします。 この「StopInstances」をワークフローの真ん中までドラッグするだけで、アクションを追加することができます。 次にアクションのパラメータを設定していきます。 アクションのパラメータをJSON形式で設定します。 「StopInstances」はインスタンスを停止するアクションなので停止するEC2のインスタンスIDを設定する必要があります。 アクションごとに何を設定するべきかは公式ドキュメントに記載されているので確認してください。 ※公式ドキュメントのリンクがない場合もあります。その場合はアクション名などで調べてください。 ワークフローの確認 アクションの準備が整ったので、画面右上の「次に」を押下し、作成したステートマシンを確認します。 画面左側にて先ほど視覚的に作成したワークフローがスニペットで表記されていることが確認できます。 コードでも管理できるのはとても良い点ですね。 確認が終わったら「次へ」を押下します。 ステートマシンの各種設定 次にステートマシンの名前などを設定していきます。 今回は項目「ステートマシン名」に任意の名前（StepFunctions_test）を入力し、 「ステートマシンの作成」を押下します。 ロールの設定 今回はEC2の操作を行うため、ロール設定が必要になります。 IAM ロール ARNを押下し、ロールに必要なポリシーを追加しましょう。 今回は「AmazonEC2FullAccess」をアタッチしていますが、必要に応じて適切なポリシーをアタッチしてください。 実行 あとは「実行の開始」を押下して実行してください。 実行完了したらそれぞれのアクションが緑色になります。 実際に対象のインスタンスを確認すると、インスタンスが停止していることが確認できます。 これでステートマシンの作成は完了しました。 EventBridgeとの連携 インスタンスを停止するステートマシンが完了したので、次は毎日定時になったらステートマシンを動かすよう、EventBridgeと連携します。 今回は下記のようにEventBridgeのルールを作成しました。 cronはタイムゾーンはUTCであることに注意してください。 ターゲットには先ほど作成したステートマシンを選択してください。 以上で「定時になったらインスタンスを停止する」システムの作成が完了しました。 時間になったらちゃんとインスタンスが停止しているか確認してみてください。 料金 AWS Step Functionsの料金は安く、気軽に取り入れることができます。 料金はワークフローのステップが実行される際に発生する状態遷移の回数を元に計算されます。 無料枠は１カ月の状態遷移の回数が4000回/月まで用意されています。 無料枠を超えた分に関しましては、1000回毎に0.025USD加算されていきます。 1日数回程度、実行するバッチのようなものであれば無料枠で抑えられるのがとても良いですね！ 今回作成したワークフローの場合、ステップが１つだけ（StopInstancesのみ）なので月あたり4000回まで無料で動かせます笑 AWS Step Functions の料金 まとめ 今回はStep Functionsで簡単にシステムを作ることができました。 ワークフローでの構築は楽しく・すぐに完成するので大変良いですね！ ちょっと難しい処理がある場合はlambdaを入れてしまえば解決も難しくないというのもポイント高いです。 今回はインスタンスの停止でしたが、同じように「定時になったらインスタンスを起動する」システムを作ることで、 「勤務時間の間だけ開発環境を稼働させる」といった課題を解決できてしまいます。 これだけでも開発費が大幅に削減できますね。 他にも「Slackなどのチャットツールからデプロイを行う」や「月末にS3にある請求書から売上をまとめる」なんて課題も面白そうです。 みなさんも是非、日頃の小さな課題などをStep Functionsで解決してみてください！ サーバ運用とWebサイト運用・システム運用などが業者が別々で問題解決が困難、もしくは業務をワンストップでお願いしたいなどございましたら遠慮なくご相談ください。 サーバの設計や構築のみなどミニマムな業務からも承ってますので是非コムデへご相談ください。

はじめに 今回は簡単にセキュリティー対策のできるAWSの脅威検知サービスであるAmazon GuardDutyを紹介したいと思います。オンプレミスの時代と比べるとAWSなどのパブリッククラウドでは簡単にサーバーを立てることができとても便利な時代になりました。気軽に利用できるためセキュリティー対策ができてなくマイニングにされたり、高額請求されたなどの話はよく耳にします。 AWS ではセキュリティー対策として下記のような様々なサービスを提供しております。今回はこの中でも簡単始めることのできるGuardDutyについて説明させていただきます！ ■　GuardDuty ■　Amazon Macie ■　AWS License Manager ■　Config ■　CloudTrail ■　AWS Security Hub etc.... Amazon GuardDutyとは AWSアカウント、ワークロード、および　Amazon S3 に保存されたデータを保護するために、悪意のあるアクティビティや不正な動作を継続的にモニタリングする脅威検出サービスです。悪意のある操作や不正な動作を継続的にモニタリングしてくれます。 機械学習、異常検出、および統合された脅威インテリジェンスを使用することで、潜在的な脅威を識別し、優先順位を付けてくれます。 料金 Amazon GuardDutyの利用料金はAWS CloudTrail 管理イベント数、AWS CloudTrail S3 データイベント数、VPC フローログと DNS ログのデータ量に対して課金が行われます。 Amazon GuardDuty の料金 計算はしづらいですがかなり安いです！！ また、1日あたりの合計推定コストはGuardDutyのコンソール画面で簡単に確認することができます。 Amazon GuardDutyの設定 GuardDutyはボタン１つで有効化することができ継続的にモニタリングをしてくれるため利用者側としては特に何もする必要はありません。しかし、注意していただきたいのはGuardDutyは攻撃や異変を検知するだけでその後の対応・対策はしてくれません。 また、Cloudwatchevent と SNSを連携することにより異変検知したらセキュリティー担当者へメールを送信させることができます。 手順はすごく簡単です。 1. Amazon GuardDutyを有効化にする 2. SNSトピックを作成する 3. Cloudwatchイベントを作成する これでAmazon GuardDutyが検知したときにメールを送信してくれるようになります。 まとめ Amazon GuardDutyはボタン一つで有効化することができ利用料金も比較的安いので全アカウント全リージョンで有効にすべきだと思います。 また、まだ利用されていない方は最初の３０日間は無料で利用できるので是非試してみてください！ サーバ運用とWebサイト運用・システム運用などが業者が別々で問題解決が困難、もしくは業務をワンストップでお願いしたいなどございましたら遠慮なくご相談ください。 サーバの設計や構築のみなどミニマムな業務からも承ってますので是非コムデへご相談ください。

AmazonLinux2 で lego を使い、Route53 を使った DNS 認証でサーバ証明書を取得する手順です ※lego・・・Go製のCLIツールです。 前提条件 AWS EC2 AmazonLinux2 IAM ポリシーを作成する <INSERT_YOUR_HOSTED_ZONE_ID_HERE> 部分は Route53 の管理画面で該当 DNS Zone 情報から取得 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "route53:GetChange", "route53:ListHostedZonesByName", "route53:ListResourceRecordSets" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "route53:ChangeResourceRecordSets" ], "Resource": [ "arn:aws:route53:::hostedzone/<INSERT_YOUR_HOSTED_ZONE_ID_HERE>" ] } ] }   インストールする AmazonLinux2 上で lego をインストール mkdir tmp cd tmp wget https://github.com/go-acme/lego/releases/download/v3.7.0/lego_v3.7.0_linux_amd64.tar.gz tar zxvf lego_v3.7.0_linux_amd64.tar.gz mv lego /usr/local/bin/ chmod 755 /usr/local/bin/lego chown root:root /usr/local/bin/lego サーバ証明書を取得する lego を使い、サーバ証明書を取得。 lego --accept-tos \ --path=/etc/letsencrypt \ --email="email@example.com" \ --dns="route53" \ --domains="www.example.com" \ run サーバ証明書を更新する サーバ証明書を更新 lego --accept-tos \ --path=/etc/letsencrypt \ --email="email@example.com" \ --dns="route53" \ --domains="www.example.com" \ renew \ --days 30

CDKとは AWS クラウド開発キット (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースを定義するためのオープンソースのソフトウェア開発フレームワークです。 出展：https://aws.amazon.com/jp/cdk/ AWS CDK（以降CDKに省略）はソースコードでインフラ構築・管理を行うフレームワークです ソースコードによるインフラ構築であればCloudFormationも候補に上がりますが、 CloudFormationの場合、ソースコードとしてjsonファイルもしくはyamlファイルに論理名の紐付けなど細かく記載する必要があります。 しかし、CDKの場合はTypeScritp、Python、Javaなど普段使い慣れたプログラム言語を使用することができ、細かい設定はCDKが吸収してくれるため、実装負荷が大変少ないです。 CDKで変わったインフラ構築 これまではAWSのコンソール上からインフラを構築していました。 しかし、コンソール上から手作業でインフラを用意するのは下記のこともあり”とても”大変です。 構築に時間がかかる インフラ構築にはVPC、EC2、RDSなどさまざまなものを構築する必要がある それぞれ人の手で行うと一つの環境を作るのに数時間掛かってしまう 構築ミスが発生 人の手による作業なので当然構築ミスも発生する 当然、ミスが出た際の問題解決に時間が割かれてしまう 殆ど同じ環境を作らなければいけない苦行 web開発では通常、 PROD,STG,DEV+α環境と多くの環境を作ることが求められる。 そのため、同じ作業を複数回行わなければならず、マラソンをやっているような気持ちになる ※こちらとても私的な意見です 上記の問題はCDKを使うことで大幅に改善される CDKのソースコードがあれば短時間でインフラ構築が完了する CDKではソースコードさえあればターミナル上で片手で数えられるコード入力のみでインフラの構築が済んでしまう   例えば、下記のコマンド一発でソースコード記載のインフラ構築ができてしまいます。 cdk deploy --all 複数のインフラ構築作業が圧倒的に楽になりますね。 ミスが少なくて済む ソースコードを読み込んでインフラ構築を行うため、いつでも同じ環境を作成することができる 属人化を防ぐ意味でも良いですね また、CDKはライブラリを使用するため、エディタの補完機能を使用することができ、ソースコード作成時のミスも少なくて済みます。 バージョン管理ができる CDKはソースコードでインフラ構築ができるため、gitなどでバージョン管理ができます 下記のコマンド一発でソースコード記載のインフラ環境と実際にインフラ環境の差分が表示されます cdk diff CDKはいいぞ CDKは便利の一言です   一度ソースコードを組んでしまえば同じ環境をいくらでも量産できるので、ちょっと新しい環境を作って試してみたいことがあった際に簡単にスクラップ&ビルドを行えてしまいます。 開発速度の向上が期待できますね。 また、インフラ構築自体はコマンド一発で出来上がってしまうので、属人化しないのが非常に良いですね。極論を言ってしまえば、ソースコードさえあればサルでもインフラ構築ができてしまいます。   問題のソースコードの実装自体は慣れさえすれば簡単です。特にAWSを使用したことがある方であれば構築時の設定と同じ内容を記載すれば良いので、すぐに感覚が掴めると思います。   一度触ってしまったらコンソール上でのインフラ構築には戻れません CDKにはそれほどの魅了が詰まっています 初心者用にAWSがワークショップを作ってくれているのも敷居が低くて大変良いです 皆さんも是非機会がありまたら触ってみてください！

　外部APIとの接続があるときautoscalingで起動されたec2にも固定IPをつけたくなることがあると思います。その場合はNATゲートウェイを使うのがベストプラクティスだそうです。しかし、NATゲートウェイは意外と料金が高くつくので今回はEIPをAutoscaling時に自動でアタッチさせる方法を試してみます。  実装手順  1. アタッチさせるEIPを事前にプールしておく  2. IAMポリシーの作成  3. シェルスクリプトの設定   1. アタッチさせるEIPを事前にプールしておく     今回はこちらのIPを使っていきます。概要欄に割り当てIDが表示されているのでコピーしておきます。 2. IAMポリシーの作成   　EC2 APIの多くはリソースレベルでのアクセス許可制限が可能ですがすべてのEC2アクションでリソースを指定できるわけではないそうです。そして今回のアクションがリソースレベルのアクセス許可がサポートされていないアクションだそうです。。。       スクリプトを貼り付けて実行するだけでは権限が足りないようでこんなエラーが出ます。 An error occurred (UnauthorizedOperation) when calling the DescribeAddresses operation: You are not authorized to perform this operation. {     "Version": "2012-10-17",     "Statement": [         { "Sid": "ec2eip",             "Effect": "Allow",             "Action": [                 "ec2:CreateImage",                 "ec2:CreateSnapshot",                 "ec2:Describe*",                 "ec2:DescribeInstances",                 "ec2:DescribeAddresses",                 "ec2:AssociateAddress"             ],             "Resource": [                 "*"             ]         }, {             "Sid": "ec2",             "Effect": "Allow",             "Action": [                 "ec2:RebootInstances",                 "ec2:StartInstances",                 "ec2:StopInstances"             ],             "Resource": [                 "arn:aws:ec2:ap-northeast-1::instance/"             ]         } ] } なのでAutoscalingのEC2にアタッチするポリシーを作る必要があります。ポリシーを作成してAutoscalingで利用するロールにアタッチします。   3. シェルスクリプトの設定 　インスタンスの起動時にスクリプトを実行させるためユーザーデータの設定に下記のコードを設定します。     ・　Autoscaling起動設定の作成　->追加設定 -> ユーザーデータ #!/bin/bash yum install jq -y # EIPの割り当てID eip_alloc_ids="eipalloc-07fad2290f8915762" export AWS_DEFAULT_REGION=ap-northeast-1 instance_id=$(curl -s http://169.254.169.254/latest/meta-data/instance-id) available_alloc_id=$(aws ec2 describe-addresses --allocation-ids ${eip_alloc_ids} | jq -r '[.Addresses[] | select(.InstanceId == null)][0] | .AllocationId') echo $available_alloc_id aws ec2 associate-address --instance-id ${instance_id} --allocation-id ${available_alloc_id} ■まとめ 　今回はAutoscaling起動時のec2のIPを固定化するためにEIPをアタッチさせました。EIPは月に300円程度なのでNatゲートウェイを使うよりも安く収まります。しかし、Natゲートウェイを利用したほうがec2をプライベートサブネットに置くことができるなどのメリットがあるのでNatゲートウェイの利用をおすすめします。 ■参考 https://aws.amazon.com/jp/blogs/security/demystifying-ec2-resource-level-permissions/?nc1=h_ls https://dev.classmethod.jp/articles/choose-eip-from-addresspool/

　AWSは従量課金制のため手軽にサービスを利用をしていくことができとても便利ですが料金の全体像が見えにくいため想定以上に料金がかかってしまうことが多いかと思います。なので今回は運用時のコスト削減方法を紹介したいと思います！ 　AWSのコスト削減にはスポットインスタンスやリザーブドインスタンスなどが有名ですが今回はあまり知られていないAWS Instance Schedulerについて説明します。   AWS Instance Schedulerによってできること 　Amazon EC2および RDSインスタンスの開始スケジュールと停止スケジュールを設定して、AWS リソースコストを管理することができます。 また、使用されていないリソースを停止し、キャパシティーが必要なときにリソースを開始することで、運用コストを削減するのに役立ちます。例えば、企業は本稼働環境で AWS Instance Scheduler を使用して、毎日営業時間外にインスタンスを自動的に停止できます。現在すべてのインスタンスを完全に使用したままにしている場合、このソリューションによってインスタンスの使用率が低下し、設定されたスケジュールに基づいて全体的なコストが削減される可能性があります。   　簡単にまとめると会社の業務時間内(9:00~18:00)のみインスタンスを稼働させ業務時間外はインスタンスを止め費用の削減をすることができ、起動と停止の作業をを自動でやってくれます !   　上記の構成図の通り、Instance SchedulerはAWSが提供するサービスそのものではなく各サービスの組み合わせでの総称なため使ったことのない人も多いと思いますがコストを削減していく上でかなり重要なサービスです。ただし、注意してもらいたいのがCloudformationで作成したLamdbaなどのサービスコストが月に$5ほどかかります。   こちらの構成図を1から作るのはかなり面倒ですがすでに公式でCloudformationのテンプレートが用意されているので簡単に作成することができます！！ Instance Schedulerの設定手順 1. Cloudformationの設定 下記のurlを開き画面右側にある　”awsコンソールで起動する”　を押す https://aws.amazon.com/jp/solutions/implementations/instance-scheduler/ ※最初はバージニアリージョンになるので正しいリージョンへ変更する これでcloudformationの設定は完了です。CloudFormation によって、 下記のResourcesが作成されます。 ・Lambda  ・DynamoDB ・IAM Policy ・EventBridge Rule ・KMS ・SNS 2. スケジュールの設定 コンソール画面からDynamodbのページへ行きます。cloudformationの設定がうまく出来ていれば3つのテーブルが作成されているはずです。スケジュールの設定はDynamodbのテーブルからできます。 instance-scheduler-ConfigTableを開き ①Instance−scheduler−ConfigTableを選択 ②name: office-hoursを選択->アクション->編集 ③name: uk-office-hoursを選択-> アクション-> コピー これでスケジュールの設定は以上です。あとは裏でLambdaがいい感じに対応してくれます！ 3.インスタンスにタグ付け あとはインスタンス(EC2,RDS)に 特定の Tag をつけるだけです。Tagをもとに自動起動・停止が動作します。 まとめ かなり駆け足でしたが簡単にAWS Instamce Schedulerの使い方について説明しました。 Instamce Schedulerは今回説明した機能だけではなくインスタンスサイズのアップグレードの変更などもできます。 開発環境やStaging環境のコスト削減していくにはおすすめなサービスだと思います。 参考 https://d1.awsstatic.com/Solutions/ja_JP/instance-scheduler.pdf

Dynamodb上のデータをグラフ化するにはBIツールであるAmazon QuickSightやElasticsearchなどのサービスがあります。しかし、Amazon QuickSightでグラフ化するにはLambdaを使ってDynamoDBのデータをCSVに変換しS3に格納したりする必要があるため面倒です。なので今回はcloudwatchを使ってデータをグラフ化(可視化)したいと思います。 設定手順 ①Dynamodbテーブルの作成 今回はデバイスの温度を管理するテーブルを作成し、データをグラフ化したいと思います。   - テーブル名: SensorTable - プライマリキー: SensorID  数値型 - ソートキー: Time  文字列型   作成したSensorTableにデータを入れます。 ■Dynamodb Streamの有効化 Dynamodb StreamとはDynamoDBに対する項目の追加、変更、削除をイベントとして検出できる機能です。 テーブルで DynamoDB Streams を有効にした場合、書き込む AWS Lambda 関数にストリーミングの Amazon リソースネーム (ARN) を関連付けることができます。テーブルの項目が変更されると、新しいレコードがテーブルのストリーミングに直ちに表示されます。AWS Lambda はストリーミングをポーリングし、新しいストリーミングレコードを検出したときに Lambda 関数を同期的にコールします。 公式より引用 ②Lambdaの作成    - 関数名(今回はput_cloudwatch)  - ランタイム Python 3.8 画像4 これでLambda関数が作成されたと思います。関数を作成すると自動でロールが作成されます。しかし、このロールはCloudwatch logsの権限しかついていないためポリシーをつけ加えます。 下記2つのポリシーをアタッチする - CloudWatchFullAccess - AWSLambdaDynamoDBExecutionRole トリガーの追加 最後にソースコードをDeployすればDynamodbをトリガーとするLamabda関数の完成です。   import json import boto3 cloudwatch = boto3.client('cloudwatch') def lambda_handler(event, context): SensorID = event['Records'][0]['dynamodb']['Keys']['SensorID']['N'] Temperature = event['Records'][0]['dynamodb']['NewImage']['Temperature']['N'] # print(Temperature) # print(SensorID) try: cloudwatch.put_metric_data( MetricData = [ { 'MetricName': 'SensorTable', 'Dimensions': [ { 'Name': 'SensorID', 'Value': f'SensorID-{int(SensorID)}' }, ], 'Unit': 'Count', 'Value': int(Temperature) }, ], Namespace = 'SensorTable' ) except Exception as e: print('Error: Dynamodb error', e) print(e)   SensorTableにテーブルにデータを入れるとcloudwatchカスタムメトリクスが作成されているはずです。エラーが出た場合はCloudwatch logsを確認してみてください。   ■まとめ 今回はDynomodb上のデータをcloudwatchを利用してグラフを作成しました。cloudwatchで作成したことによりアラームの作成やほかサービスとの連携が簡単にできると思います。しかし、cloudwatchの料金は意外と高いため注意が必要です！   参考 https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Streams.Lambda.Tutorial.html   cloudwatchの料金 https://aws.amazon.com/jp/cloudwatch/pricing/?nc1=h_ls