Amazon EC2 Auto Scaling のスケールアウトが遅い時に確認すること | DevelopersIO
困っていること Amazon EC2 Auto Scaling のターゲット追跡スケーリングポリシーを作成しました。 ターゲットの追跡スケーリングポリシーでは、指定されたメトリクスがターゲット値を超えている場合、Auto Scaling グループをスケールアウトする挙動と認識してます。 指定されたメトリクスがターゲット値を超えているものの、時々スケールアウトするまでの応答時間が長く掛かっていることを確認しています。 確認するべき点（原因）と、対処法を教えてください。 どう対応すればいいの? 確認するべき点（原因） ターゲットグループに対して CloudWatch の詳細モニターリングを使用しているか確認する CloudWatch の基本モニタリング は 5 分間隔でメトリクスが公開されます。 基本モニタリング データは自動的に 5 分間隔で取得されます。 詳細モニタリング データは 1 分
Amazon EC2(Linux)のswap領域ベストプラクティス | DevelopersIO
ども、大瀧です。 Linuxのメモリ管理で欠かせないのがswapですよね。EC2のディスク管理には独特な仕様があるのでその辺りを踏まえつつ、EC2(Linux)でどのようにswap領域を用意するのが良いのかまとめてみたいと思います。 理屈をこねながらの解説になるので、先に本エントリーの結論を。 公式AMIにはswap領域が含まれない m1.small、c1.mediumには900MBのスワップ領域がおまけでついてくる(Amazon Linux AMIであれば、Cloud-initによって自動マウントされる) swap領域には、インスタンスストア(別名Ephemeral Disk)を使うべし では、それぞれ見ていきます。 公式Linux AMIの初期構成にはswapパーティションが無い Amazonから提供される公式のLinux AMIのブートディスクには、swapパーティションが含まれてい
EC2における単位時間あたりの名前解決制限の対応 - BASEプロダクトチームブログ
この記事はBASE Advent Calendar 2019の2日目の記事です devblog.thebase.in SREの ngsw です。 BASEはAWSを採用しており、その中でもEC2に大きく依存する部分があります。EC2においては以下の制約があります。 DNS の制限 VPC での DNS の使用 - Amazon Virtual Private Cloud DNS の制限 各 Amazon EC2 インスタンスは Amazon が提供する DNS サーバーへ送信できるパケット数を ネットワークインターフェイスあたり最大 1024 パケット/秒に制限しています。 この制限を増やすことはできません。 AWSのマネージドサービスはエンドポイントの提供になり、そのエンドポイントへのアクセスに名前解決は必要となります。BASE全体へのアクセス数は増加傾向にありますので、名前解決試行回数
EC2 スポットインスタンスの price-capacity-optimized 戦略のご紹介 | Amazon Web Services
Amazon Web Services ブログ EC2 スポットインスタンスの price-capacity-optimized 戦略のご紹介 この記事は、2022年11月15日にJagdeep Phoolkumar、Peter Manastyrnyによって投稿された「 Introducing the price-capacity-optimized allocation strategy for EC2 Spot Instances 」を翻訳したものです。 Amazon EC2 スポットインスタンスは、AWSクラウド内で使用されていない Amazon Elastic Compute Cloud ( Amazon EC2 ) のキャパシティを、オンデマンド価格と比較して最大90%割引で利用できるものです。EC2 スポットインスタンスを利用する際のベストプラクティスの1つは、幅広いインスタン
特定の時間帯にCPU使用率が高騰した時のみEC2インスタンスを自動で再起動させる方法 | DevelopersIO
EC2インスタンス内部でcronを使用し、aws cliで特定の時間にCloudWatchアラームの作成と削除するようにスケジュールを設定しました。 困っていた内容 特定の時間帯にCPU使用率が高騰した時のみEC2インスタンスを自動で再起動させたいです。 どうすればいいの？ 他にも方法はあると思いますが、今回はEC2内部でcronを使用し、特定の時間にCloudWatchアラームの作成と削除するようにスケジュールを設定しました。 設定方法 EC2インスタンス用のIAMロールを作成する CloudWatchにアクセス可能なIAMポリシーを設定します。 今回は、IAM ポリシー「CloudWatchFullAccess」をアタッチしました。必要な権限を付与してください。 EC2 を起動する EC2を起動します。 今回は Amazon Linux 2 を使用しています。 $ cat /etc/o
【AWS SSMステートマネージャー】複数のEC2インスタンス(Linux)に対するプロセスチェック | DevelopersIO
全インスタンスに特定アプリケーション(例えばエンドポイントセキュリティ) がインストールされていて、 かつ「稼働もしている」ことを棚卸ししたいケースがあると思います。 今回は特定アプリケーションが「稼働している」ことを棚卸しする一手段を紹介します。 Systems Manager(SSM) ステートマネージャーを使います。 ※1: 「インストールされている」ことは Configルールを使って簡単に実現できます。 (参考: DevelopersIO) ※2: プロセスダウンをすぐに検知しないといけない、といったリアルタイム性が求められる場合は CloudWatch Agent や他 Third Party の「ちゃんとしたプロセス監視」を実装しましょう。 前提条件 EC2インスタンスが SSM管理下であることが前提条件です。 SSM管理下にする方法については以下ブログが参考になります。 EC
令和なのに NAT インスタンスを手作りして使ってみた | DevelopersIO
（※）データ処理は 100 GB の前提で計算していますが、戻りの通信も課金対象であるため実際にはもっと増えるはずです。 NAT Gateway は利用期間に応じた単価が高いのと、データ処理量に応じた料金が発生します。NAT インスタンスは、使わない時間は停止することでオンデマンド料金をさらに減らせます。 大抵の場合、NAT インスタンスの方がコストは安くつきます。 このコストの差を鑑みてもなお 本番環境では NAT Gateway の採用をお勧めします。 NAT Gateway がマネージドでやってくれる部分や性能のメリットの方が大きいと考えるためです。検証環境や、万が一インターネットへのアウトバウンドが途切れてもクリティカルなことにはならない、というワークロードであればコスト抑制をモチベーションに NAT インスタンスを採用するのもアリだと思います。 それぞれの料金の以下をご参照くださ
[アップデート] EC2 インスタンスの無停止でのルートボリューム置き換え時に任意の AMI を復元のソースとして指定可能になりました！ | DevelopersIO
コンバンハ、千葉（幸）です。 EC2 インスタンスのルートボリュームを無停止で置き換える際、任意の AMI をソースとして指定できるようになりました。 Amazon EC2 enables easier patching of guest operating system and applications with Replace Root Volume ここでの任意とは、置き換え対象のインスタンスおよびルートボリュームと関係ないものを指定できる、という意味で使っています。 この新機能は、OS、アプリケーションの迅速なパッチ適用を可能にするものとして想定されているようです。 何が変わったのか 実行中の EC2 インスタンスのルートボリュームを無停止で置き換える、という機能は 2021年4月にリリースされました。 ルートボリュームの置き換えはルートボリュームの復元を伴います。そうすると何をソ
![[アップデート] EC2 インスタンスの無停止でのルートボリューム置き換え時に任意の AMI を復元のソースとして指定可能になりました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/b78e1b00fb2da19e9cae6ca64621e34b0d3796b7/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2022%2F08%2Famazon-ec2.png)
EC2のユーザーデータでS3に配置したシェルスクリプトを実行してみた | DevelopersIO
はじめに EC2のユーザーデータを使って起動時に色々とインストールするのはよくあることだと思います。 今回はそのユーザーデータを任意に変更できるよう、S3に配置したシェルスクリプトをユーザーデータに読み込んで実行できるかを試してみました。 シェルスクリプトの準備 ユーザーデータとして読み込ませるシェルを準備し、S3に配置します。今回は以下のような「jq」をインストールするシェルスクリプトを準備しました。 ec2-template.sh #!/bin/bash sudo yum update -y sudo yum -y install jq 上記のシェルスクリプトを、今回は「dev-honda-ec2-test」バケットに保存しました。 CloudFormationテンプレート EC2を起動するためのCloudFormationテンプレートを準備します。以下のようになりました。 AWSTe
AWS CLIで特定のEC2インスタンスタイプをサポートしているリージョンを確認するスクリプトを作成してみた | DevelopersIO
prismatixのとばち（@toda_kk）です。 利用中のリージョンやAZが特定のEC2インスタンスタイプをサポートしているかどうかを調べる際に、AWSマネジメントコンソールからEC2「インスタンスタイプ」のページを表示することで確認できます。 ただ、特定のリージョンがサポートしているEC2インスタンスタイプではなく、特定のEC2インスタンスタイプをサポートしているリージョンの一覧を調べたいときがあります。 そこで、下記ページを参考にしながら、AWS CLIを利用したBashスクリプトを作成してみました。 注意点 このスクリプトでは、実行するAWSアカウントで有効になっているリージョンのみを確認の対象とします。 明示的に有効化が必要なリージョンについては、有効化していない場合にはスクリプトの実行結果に表示されません。 インスタンスタイプをサポートしているリージョンの一覧を表示するスクリ
EC2からFargateへの移行 ~shadow proxyとカナリアリリース~ | GREE Engineering
こんにちは、メディア事業でエンジニアをしている木村洋太です。 昨年のGREE Tech Conferenceでは「LIMIA」のフレームワーク移行プロジェクトにおけるコードの自動修正について話させていただきましたが、今回は同時に行ったインフラ移行について紹介いたします。 EC2からFargateへの移行例は多く存在しているとは思いますが、今回の移行では安全な移行のために、shadow-proxy環境での移行前のテストやEC2とFargateの同時稼働によるカナリアリリースなどさまざまな工夫を行いました。これらの中で得られた知見や失敗をまとめられたらと思っています。 インフラ移行の概要 フレームワーク移行プロジェクト フレームワーク移行プロジェクトでは、グリーが運営するメディアの一つである「LIMIA」のフレームワークをFuelPHPからLaravelへ移行することを目的としていました。 移
運用中のEC2インスタンスにAuto Healingを設定してみた | DevelopersIO
こんにちは。AWS事業本部トクヤマシュンです。 運用中のEC2インスタンスにAuto Healingを設定することがありました。 EC2の耐障害性を向上させるはじめの一歩として使うことのできる機会も多いかと思い、今回紹介します。 Auto Healingって何？ Auto Healingとは、Auto Scaling Groupを使って、起動中のEC2インスタンスを常に一定数に保つデザインパターンのことです。 Auto Scaling Groupのヘルスチェック失敗を契機として、インスタンスをサービスから切り離し、新たなインスタンスをサービスインさせることで障害復旧を行います。 Auto Scalingを複数AZで設定しておけば、AZ障害の際も別AZにEC2インスタンスを起動させることができます。 余談ですが、EC2インスタンスの自動復旧の仕組みとして、Auto Recoveryというもの
EC2インスタンスの選び方とGraviton2の始め方で良い資料を見つけたので是非紹介したい | DevelopersIO
こんにちは！コンサル部のinomaso(@inomasosan)です。 7月7日はクラスメソッドの創立記念日ということで、たまには普段書かないようなブログを書いてみようと思います。 2021年6月3日に開催されたAWSへのマイグレーションのその先に ～リフト＆シフトからのクラウド最適化～というセミナーの最適な Amazon EC2インスタンスの選び方という資料が良かったので、オススメのスライドを抜粋して紹介していきます。 セッション概要 350 以上ある EC2 インスタンスのバリエーションの中から、お客様のシステムに最適なインスタンスはどれなのか？と悩まれるお客様が多くいらっしゃいます。本セッションでは、用途によるインスタンスの使い分けをご説明し、さらに性能面・コスト面で最適なインスタンスを選ぶ方法をお話ししました。 おすすめスライド Amazon EC2 インスタンスタイプについて E
AWS CDKでEC2のキーペアを作成してみた | DevelopersIO
先日、EC2のキーペアに新しい管理機能が追加されて、CloudFormationでキーペアが作成できるようになりました。 [アップデート]EC2のキーペアに新しい管理機能が追加されました。 | DevelopersIO CloudFormationでキーペアが作成できるようになったんだから、そのうちcdkでもキーペアが作成できるようになるだろうと待っていました。 v2.25.0 でできるようになったので試してみました。 Release v2.25.0 · aws/aws-cdk 前提条件 AWS CDKはv2.25.0以上を使用します。 $ cdk --version 2.25.0 (build ae1cb4b) 構成図 ざっくりこんな感じの環境を作ります。 AWS CDKのサンプルプログラム TypeScriptのサンプルプログラムは次のとおりです。 cdk.ts #!/usr/bin/
停止保護を有効にしているEC2インスタンスがAuto Scalingでスケールインすると、保護を無視して削除される | DevelopersIO
コンサル部のとばち（@toda_kk）です。 2022年5月のアップデートにより、EC2インスタンスの「停止保護」の機能が追加されました。 従来の「削除保護」に加えて、「停止」の動作に対しても保護機能が追加されたことになります。 そこでふと疑問に思いました。 Auto Scalingを利用している場合、「停止保護」を有効にしているEC2インスタンスがスケールインしようとすると、どういう動作になるんでしょうか？ ドキュメントに答えがあった 疑問をそのままTwitterに呟いていたら、同僚から教えてもらいました。 削除保護と一緒でAuto Scallingの場合は無視して削除するみたい > Enabling stop protection does not prevent Auto Scaling from terminating an instance when the instance i
ALBにアタッチしたEC2インスタンスの監視&修復方法について~Auto Healing編~ | DevelopersIO
こんばんは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。 先日、ALBにアタッチしたEC2インスタンスの監視&修復について色々と考えることがありました。 この記事はその時の備忘録です。雑多な内容になってしまいましたがご了承ください。 そもそもEC2の監視&修復方法には EC2インスタンスを監視&障害が発生したインスタンスを自動的に修復したいな〜と思って調べてみたところ、インスタンスの修復方法には"CloudWatchアラームを使用するパターン"と"Auto Scalingを使用するパターン"があります。 CloudWatchアラームを使用するパターン 復旧 通称"Auto Recovery" AWS基盤側の障害に起因したアラーム(システムステータスのチェック)に応じてインスタンスの復旧を行う 再起動 OSの再起動が実施される Auto Scalingを使用するパター
[アップデート]EC2のキーペアに新しい管理機能が追加されました。 | DevelopersIO
おはようございます、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。 先ほどEC2のキーペアに新たな管理機能が加わったとのアップデート情報が入ったので早速試してみました。 内容は以下のようなものでした。 コンソール上やAPI経由(AWS CLI, SDK)でキーペアの作成日を参照出来るようになったよ。 ED25519タイプでも秘密鍵の形式で.ppk形式を選択出来るようになったよ。 API経由で公開鍵を参照出来るようになったよ。 CloudFormationでキーペアが作成/削除出来るようになったよ。 このうち、本記事では下の2つについて検証してみました。 まずは上の2つについても簡単にご紹介します。 コンソール上やAPI経由(AWS CLI, CDK)でキーペアの作成日を参照出来るようになったよ。 作成日についてはこちらの記事で紹介されていますのでご覧ください。本記事で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
aws-cfn-alb-ec2/template.yaml at main · Tak1wa/aws-cfn-alb-ec2
[AWS]EC2のメール送信ベストプラクティスをまとめてみた
【AWS】AmazonLinuxにSWAP領域を追加してみた
