ALBのターゲットグループ設定でHTTPSが選択できるため、バックエンドEC2とのHTTPS通信設定し通信できるのか確認してみました。 また、利用したサーバ証明書は、ALBはACM、EC2は自己証明書（オレオレ証明書）を利用してみました。どなたかのお役に立てれば光栄です。 こんにちは、コカコーラ大好きカジです。 ALBのターゲットグループ設定でHTTPSが選択できるため、バックエンドEC2とのHTTPS通信設定し通信できるのか確認してみました。 また、利用したサーバ証明書は、ALBはACM、EC2は自己証明書（オレオレ証明書）を利用してみました。 ELBとEC2間をSSL通信にしたい場合、以前だとCLB（Classic Load Balancer）では、TCPリスナーやHTTPS リスナーでBackend Certificateを利用していましたね。 構成 結果 ターゲットグループのプロト
uname は、システムに関する情報を標準出力に出力するLinux/Unixコマンドである。 構文 uname [options] options の指定を省略した場合はシステム名を表示する。つまり、uname -s と同じである。options には次に示すオプションを指定できる。 オプション 以下に示すオプションを uname コマンドに指定できる。 -a 全てのシステム情報を表示する。 (POSIX) $ uname -a Linux E595 5.15.0-86-generic #96-Ubuntu SMP Wed Sep 20 08:23:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux --all 全てのシステム情報を表示する。 (GNU) -i ハードウェア・プラットフォームを表示する。 (POSIX) $ uname -i x86_64
1.1. バージョン確認 cat /etc/system-releaseコマンドで確認できます [root@ip-10-1-10-243 etc]# cat /etc/system-release Amazon Linux release 2 (Karoo) 1.2. バージョン確認(詳細情報表示) cat /etc/os-releaseコマンドで確認できます [root@ip-10-1-10-243 etc]# cat /etc/os-release NAME="Amazon Linux" VERSION="2" ID="amzn" ID_LIKE="centos rhel fedora" VERSION_ID="2" PRETTY_NAME="Amazon Linux 2" ANSI_COLOR="0;33" CPE_NAME="cpe:2.3:o:amazon:amazon_linu
2022/12/10 最新の情報に更新しました。また一部の文章を修正・更新しています。 こんにちは！ BFT名古屋支店の佐野です。 今回はEC2インスタンスが一定時刻に起動、停止する仕組み作りについてのお話です。 EC2インスタンスは起動している間だけ料金が発生するので、誰も触っていない時間帯に起動させておくのは非常にコスト面で悪く、もったいないです。 多くの場合は「使わない時は停止しておく」運用をされていると思いますが、手動だとうっかり停止し忘れてしまう……なんてことも多々あるでしょう。 ですので、そもそも忘れてしまってもいいように、起動や停止を自動化してしまおうというのが、今回の趣旨になります。 はじめに：EC2の自動起動・自動停止の前提条件 今回のEC2インスタンスの自動起動・自動停止には、Systems ManagerとEventBridgeというふたつのAWSサービスを使用します
困っていた内容 1日のうち決まった時間帯のみ特定の EC2 インスタンスを起動させたい要件があります。毎回手動で行うのは手間なので、自動化させたいと考えています。 どうすればいいの？ Amazon Systems Manager のオートメーションと CloudWatch イベントを使用して自動起動、停止をスケジュールすることが可能です。 IAMロールを作成する CloudWatch イベントの作成時に使用する IAM ロールを作成します。 CloudWatch Events には、提供された Automation ドキュメントとパラメータを使用して SSM Start Automation Execution を呼び出すための権限が必要です。 IAM コンソールよりロールを作成します。今回は event-ssm-automation-role という名前のロールを作成しました。IAM ロ
コピー元インスタンスのAMIをつくってそこからインスタンスを作成することで、インスタンスのコピーを作れる Amazon マシンイメージ (AMI) は、ソフトウェア構成 (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど) を記録したテンプレートです。 インスタンスと AMI - Amazon Elastic Compute Cloud EC2インスタンスの画面を表示する AWSのコンソールにログイン > [EC2] イメージを作成する サイドメニューの[インスタンス] > コピー元のインスタンスを選択 [アクション] > [イメージ] > [イメージの作成]でダイアログを表示する [イメージ名]に何のイメージかわかるような値を設定する [再起動しない]チェックボックス : コピー元インスタンスを再起動しないでイメージを作成したい場合はチェックを入れる [終了時に削
こんにちは、インフラエンジニアの綿引です。 EC2 運用時に いつのまにかディスク使用率が 100% に、、 という経験がある方もいらっしゃるのでないでしょうか。 そこで今回は EC2 の EBS ボリュームを拡張したので、方法を共有したいと思います。 対象の方は以下のような方でしょうか。 EC2 のディスク使用率がそろそろ危ない、、 実施方法 では早速実施していきます。拡張対象の EC2 の情報は以下です。 OS : CentOS 7 拡張対象 : ルートパーティション そしてやる前に 必ずバックアップ を取得しておきましょう。 EBS ボリュームの拡張 まずは EBS ボリュームの拡張を行なっていきます。 マネジメントコンソールの EBS の画面から、拡張対象の EBS ボリュームを選択し 「アクション」 → 「ボリュームの変更」 を選択します。 そして画面遷移後、ボリュームタイプ・サ
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon EBS ボリュームのサイズ変更後にファイルシステムを拡張 EBS ボリュームのサイズを増やしたら、パーティションおよびファイルシステムを新しいより大きなサイズに拡張する必要があります。ボリュームが optimizing 状態に入るとすぐにこれを実行できます。 [開始する前に] 変更をロールバックする必要がある場合に備えて、ボリュームのスナップショットを作成します。詳細については、「Amazon EBS スナップショットの作成」を参照してください。 ボリュームの変更が成功し、optimizing または completed 状態になっていることを確認します。詳細については、「Amazon EBS ボリューム変更の進行状況のモニタリング」を参照してください
はじめに おはようございます､加藤です｡EC2の上で動くアプリケーションログを一時的にCloudWatch Logsに保管､長期的にS3バケットに保存というアーキテクチャを試してみました｡ こちらが概要図です｡ EC2インスタンスでCloudWatchエージェントを動かし､ログをCloudWatch Logsに転送します｡CloudWatch LogsのロググループからKinesis Data Firehose→S3と転送します｡ Kinesisエージェントをインスタンスにインストールすれば直接Kinesis Data Firehoseにログを転送できますが､CloudWatch Logsに短期間はログを保存して置きたい・CloudWatch Logsで任意の文字列を検出した場合はアラートを上げたいというシチュエーションを想定し､このようなアーキテクチャになりました｡ 永続的に保存したい要
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 第一回目: -事前準備編- 第二回目: -VPC構築編- 追記 第二回目のVPCの環境と名称が違っておりました。 3. EC2インスタンスの作成 で使うサブネット名は test-public-subnet-a となっております。 後日改定投稿いたします。 @mitch0807 さん、ご指摘いただきありがとうございました。 はじめに... VPCを構築したら、[EC2]の接続先の[RDS]を構築して見ましょう。 前回作成したサブネット、セキュリティグループに適用していきます。 ぽちぽち進めていけばあっという間に終わってしまいますので、DB
個人開発で EC-CUBE のプラグインを開発している Tirol と申します。 独自でプラグインを開発する過程で利用する動作確認等のテスト用のサーバとして、以前は Heroku を使っていたのですが、 いつぞやからかプラグインのインストールに失敗するようになりました。 → 該当 issue ローカルで動かしても失敗するため、この度 EC2 インスタンス上で EC-CUBE を構築する方法を調査しまとめました。 EC2 インスタンスのスペック t2.medium (t2.micro 以下だとメモリが足らなくてプラグインインストールに失敗します) Amazon Linux 2 参考にした記事 本記事は下記の記事を参考に、データベースをアプリケーションと同一のサーバ上で動かす場合に必要な設定をまとめたものになります。 Amazon Linux2にEC-CUBE4.0.4をインストールする手順
はじめに AWSにインスタンスを作成する方法がよく分からない ⇒ とりまインスタンス作成しながらQiitaにまとめて見よう (これも一つのアイカツ) AWS EC2にインスタンス作ります Step.1 AWSにログイン AWS マネジメントコンソールにてログイン Step.2 EC2のインスタンスを作成する Amazon EC2 ダッシュボードに移動 右上の「サポート」の左をクリックしてリージョンを選択する（画面では「オハイオ」） 画面中央の「インスタンスの作成」を選択する Step.3 インスタンスを設定する 1.AMIの選択 - ソフトウェア構成を選択する画面（今回は「Amazon Linux AMI」を採用） 2.インスタンスタイプの選択 - 仮想サーバーのスペックを選択する画面（今回は「t2.micro」を採用） 「確認と作成」を押すと一気に 7. まで飛ばされます、ストレージを増
AWSのインスタンスを立ち上げるなんて毎日やるわけでもないので、やるたびに忘れてしまいますよね。ちなみに今のいままでほぼ完全に忘れていました。以前一回やったことがあったのですが、数ヶ月前だし、一回しかやったことないし。 そこで、備忘録的にメモしておこうかと。 登場人物 ruby on Rails capistrano AWS itamae 手順をば 大まかには以下の通り。 1. インスタンスをつくる 2. itamaeを新たに作成したインスタンスに向けて実行する 3. capデプロイコマンドを実行する 4. EC2インスタンスのドメインを変更する(Route 53) 1. インスタンスをつくる 詳細なインスタンスの各種設定は他のQiita記事やドキュメントに譲ります。だいたいは既存のインスタンスを複製する（「同様のものを作成」っていうボタン）パターンが多いのかなと。 が、新規でインスタンス
Amazon EC2 M8g インスタンスには、AWS Graviton4 プロセッサが搭載されています。汎用ワークロードのために、Amazon EC2 で最高のコストパフォーマンスを提供します。 特徴: カスタムビルドの AWS Graviton4 プロセッサを搭載 M7g インスタンスと比較して最大 3 倍の vCPU とメモリを備えた大規模なインスタンスサイズ 最新の DDR5-5600 メモリを搭載 デフォルトで Amazon EBS 向けに最適化されています ホストサーバーに物理的にアタッチされた EBS または NVMe SSD を通じて提供されるインスタンスストレージ M8gd インスタンスでは、NVMe ベースのローカル SSD がホストサーバーに物理的に接続されており、インスタンスの寿命と連動するブロックレベルストレージを提供します m8g.24xlarge、m8g.48
はじめに Redmineすごく便利です。やる気が出ないときでもチケットの一覧として並んでいて、それをこなして行くと段々とやる気がでてきます。 またここ最近になってAWSを使い始めたのですがそのお手軽さに感動しています。 ということで今までは自前のサーバでRedmineを運用していましたが、AWSでRedmineを立ててみました。 自分用のメモとしつつ、次回同じサーバを立てるときに5分で構築、10分でバックアップという目標を達成できる用にメモします。 BitnamiのAMIをつかってEC2にインストール 全体の流れは次の通りです。 EC2インスタンスの作成画面へ行く AMIからインスタンスを選択する 作成が完了するのを待つ 管理者用のパスワードを確認する IPアドレスを確認して接続する 完了！ 個人的にあまりAWSには慣れていないので順に追って説明します。 AWSコンソールからEC2を選び、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く