[小ネタ] jq コマンドでEC2インスタンスの情報を取得する | DevelopersIO
はじめに こんにちは、川原です。 今回は(今回も?)小ネタです。 AWS CLIを使い始めると、コマンドレスポンスがJSON形式であるため必然的にJSON整形フィルタであるjqコマンドと仲良くせざるを得ません。 (JMESPath と仲良くするという手もありますが、jqコマンドと仲良くなるのとそんなに変わらないかな、と感じています) ただ、jqコマンドをそんなに頻繁に使わないので、どうやってフィルタリングするんだっけ? と、調べることが多々あります。 jq 使用例 ということで、jqの(知っていると便利そうな)エッセンスを含んだjqコマンドの使用例が以下になります。 >aws ec2 describe-instances | jq -r '.Reservations | sort_by(.Instances[].Tags[] | select(.Key == "Name").Value)
![[小ネタ] jq コマンドでEC2インスタンスの情報を取得する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/71d2db727920f29e1e777f4d419ea8726127f42d/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2017%2F06%2Fjq-icon-400x400.png){kind=icon}
7年続いたサービスをEC2構成からECS構成へ乗り換えた話 - KAYAC engineers' blog
この記事は Tech KAYAC Advent Calendar 2021 の20日目の記事です。 こんにちは、バックエンドエンジニアの @commojun です。今年のTech KAYAC Advent Calendarは3度めの参戦です！よろしくお願いいたします！ 本日の記事は、昨年の記事の続きで、Amazon EC2のプロダクトをAmazon ECS構成へと乗り換えた話になります！ techblog.kayac.com 目次 目次 背景 Amazon Linuxのサポート終了 ついでにPerlのバージョンもあげた 苦労したポイント 1，デプロイ方法がめっちゃ変わる デプロイのために都度コンテナイメージを焼く 2階建て作戦 2，batchサーバどうするの問題 sqsjfr + SQS + sqsjkr 作戦 3，泥臭い戦い ecspressoの存在 非エンジニアにもわかってもらおう 「
EC2のメモリ監視をCloudWatch Agentで実施してみた | DevelopersIO
AWSチームのすずきです。 EC2インスタンス(Amazon Linux 2) のメモリ使用率の監視を行うため、 CloudWatch Agent を設定する機会がありましたので、紹介させていただきます。 環境 以下のEC2インスタンスを対象としました。 インスタンスタイプ : m5.large OS: Amazon Linux 2 AMI : amzn2-ami-hvm-2.0.20191217.0-x86_64-gp2 (ami-011facbea5ec0363b) UserData CloudWatch Agent は、UserDataを利用し、EC2インスタンスの起動時に設定しました。 #cloud-config runcmd: - [ sh, -c, "dd if=/dev/zero of=/swapfile bs=1M count=512" ] - [ sh, -c, "chm
ボリュームサイズ変更後の Linux ファイルシステムの拡張 - Amazon Elastic Compute Cloud
次のトピックでは、Linux 用の XFS および Ext4 ファイルシステムを拡張するプロセスについて説明します。他のファイルシステムの詳細については、そのドキュメントを参照して、手順を確認してください。 EBS ボリュームのサイズを増やしたら、ファイルシステム固有のコマンドを使用して、ファイルシステムを新しいより大きなサイズに拡張します。ボリュームが optimizing 状態に入るとすぐにこれを実行できます。 Linux でファイルシステムを拡張するには、次の操作を実行する必要があります。 変更をロールバックする必要がある場合に備えて、ボリュームのスナップショットを作成します。詳細については、「Amazon EBS スナップショットの作成」を参照してください。 ボリュームの変更が成功し、optimizing または completed 状態になっていることを確認します。詳細については
Amazon EC2 Eメール送信ベストプラクティス | DevelopersIO
ども、大瀧です。 EC2からEメールを送るという案件、たくさんありますよね。そして結構な確率でトラブるんですよね(涙目)。そんな苦い経験をベストプラクティスとしてまとめてみました。一応技術的なところは網羅したつもりですが、メールセキュリティの専門ではないので、不備や間違いがあればご指摘ください。 では、メール送信トラブルの元凶である、スパムメールとその対策からご紹介していきます。 スパムメールとの闘いダイジェスト Eメールの歴史は、スパムメールとの闘いの歴史と言えます。 不特定多数に送信されるスパムメール(未承諾の広告メール)は、メール受信者に不快な思いをさせるとともに、メールサーバーのメール流量を爆発的に増加させ、長らくメールサーバー管理者を泣かせてきました。 このスパムメールをなんとか撃退しようと、現在では主に以下のような対策が行われています。 1. 送信メールサーバー側のネットワーク
CloudFront-ELB-EC2構成でApacheのディレクトリ名補完リダイレクト時の問題をAWS側で可能な限り対応してみた | DevelopersIO
CloudFront-ELB-EC2構成でApacheのディレクトリ名補完リダイレクト時の問題をAWS側で可能な限り対応してみた CloudFront-ELB-EC2な構成でEC2上のApacheがディレクトリ名のスラッシュを補完するためのリダイレクトレスポンスを返す際に、リダイレクト先ドメインが変わってしまう、リダイレクト先のプロトコルが変わってしまう、という問題に遭遇しました。CloudFrontのHostヘッダ転送、HTTPSリダイレクト機能を用いてAWS側のみで対応する方法を検討してみました。 はじめに 清水です。先日以下のようなCloudFront-ELB-EC2な構成で、EC2上のApacheがディレクトリ名のスラッシュを補完するためのリダイレクトレスポンスを返したときに発生する問題と出くわしました。解決策をできる限りAWS側で対応する方法を検討してみたのでまとめてみます。 A
Nginxを利用してCloudFront対応のWordPressを環境を最適化してみた | DevelopersIO
はじめに AWSチームのすずきです。 先日紹介させて頂いた、CloudFront、ELB、EC2を利用したWordPress環境。 ELBやEC2のパブリックIPアドレスを知り得た第三者により WordPressの実行環境が直接攻撃される事があった場合、DDoSなどの被害を受けやすいリスクがありました。 今回、この対策としてNginxをリバースプロキシとして導入し、 CloudFrontを経由と、正しい認証情報を持つ管理者のリクエストのみWordPress環境に中継、 他の不正なアクセスは遮断する方法を紹介させていただきます。 構成図 環境 OSは、Amazon Linux2のAMI (amzn2-ami-hvm-2.0.20190508-x86_64-gp2) を利用しました。 CloudFront、ELB、EC2の各リソースは、以下の環境を一部変更して利用します。 CloudFront
DockerでEC2、ECS、EKSの運用想定まとめ - Qiita
1つのサーバーに複数コンテナ 1サーバーの中に1webサービスがある。ただそれだけ。 同じサーバー内なので複数コンテナはport管理が必要 RDSとかELBとか使ってたら1EC2サーバーにはアプリケーションコンテナだけ ローカルかデプロイサーバーを立ててあらかじめデプロイ先のインスタンスを複数起動し、デプロイツールによって複数台に展開は可能 スケール前提のものでない or 最初の構成から増減することがなければ良 スケールはしずらい(できるが、Dockerの範疇を超える) 複数サーバーに複数コンテナ 複数サーバーを管理するのはECS Cluster サービスをタスクで起動させる(ここでいうサービスとはざっくりコンテナのこと) タスクの定義はコンソール上から行う コンソール上でdocker-compose.yml(厳密にはECS用の記法がある)定義して実行するような感じ ELBの設定も必要 コ
AMD製CPUを搭載した「T3a」インスタンスの 性能をLinuxカーネルのビルド時間で比較してみた | DevelopersIO
※料金は米国リージョン、Unix/Linux 1時間単価 CPU情報 AmazonLinux2の「lscpu」コマンドを利用してCPU情報を確認しました。 CPUモデルは「AMD EPYC 7571」、先行してリリースされていた「M5a」「R5a」と共通でした。 $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 2 Core(s) per socket: 1 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 23 Model: 1 Model name: AMD EPYC 7571
【速報】T3インスタンスがリリースされました！ | DevelopersIO
はじめに 中山（順）です。 みなさん、T2インスタンス使ってますか？お安いので検証環境などでは御用達という方／負荷が低い本番環境でバリバリ使ってるぜって方も多いと思います。 そんな中、T3インスタンスがリリースされました！ New T3 Instances – Burstable, Cost-Effective Performance Burstable Performance Instances 提供されるインスタンスタイプ t2インスタンス同様のラインナップです。 t3.nano t3.micro t3.small t3.medium t3.large t3.xlarge t3.2xlarge 利用できるリージョン 以下の12リージョンで利用可能です。 US East (Ohio) US East (N. Virginia) US West (N. California) US Wes
Now Available – Amazon Linux AMI 2017.09 | Amazon Web Services
AWS News Blog Now Available – Amazon Linux AMI 2017.09 I’m happy to announce that the latest version of the Amazon Linux AMI (2017.09) is now available in all AWS Regions for all current-generation EC2 instances. The AMI contains a supported and maintained Linux image that is designed to provide a stable, secure, high performance environment for applications running on EC2. Easy Upgrade You can up
長いEC2リソースIDが利用可能になりました | DevelopersIO
はじめに 昨年11月、大きな仕様変更の注意喚起がAWSより出されました。 Amazon Web Services ブログ: 2016年に導入のEC2, EBSのリソースIDの長さの変更について これは、2016年中に、EC2の インスタンス レザベーション(インスタンス起動リクエスト毎に発行されるID) ボリューム スナップショット を示すリソースIDが、長いフォーマットに変更されるというものです。詳細はAWSのFAQに記載された「より長い EC2 および EBS のリソース ID」をご覧下さい。 今回、移行期間中の検証を目的に、長いフォーマットでの利用を選択することが可能になりました！ They’re Here – Longer EC2 Resource IDs Now Available | AWS Official Blog Amazon Web Services ブログ: 本日より
インスタンスストアスワップボリューム - Amazon Elastic Compute Cloud
Linux のスワップ空間は、システムで物理的に割り当てられたよりも多くのメモリを必要とする場合に使用できます。スワップ空間を有効にすると、Linux システムは頻繁に使用されないメモリページを物理メモリからスワップ空間 (既存のファイルシステムの専用パーティションまたはスワップファイル) にスワップし、高速なアクセスを必要とするメモリページのためにその空間を解放します。 スワップ空間をメモリページングに使用しても、RAM 使用時ほど高速でも効率的でもありません。スワップ空間に定期的にメモリをページングするワークロードの場合は、RAM が多くサイズの大きいインスタンスタイプに移行することを検討してください。詳細については、インスタンスタイプを変更するを参照してください。 c1.medium および m1.small インスタンスタイプの物理メモリ容量は限られており、起動時には Linux
EC2 のAuto Recoveryが東京リージョンにリリースされました ｜ DevelopersIO
はじめに AWSチームのすずきです。 AWSのシステム側に起因するEC2障害が発生した場合、 インスタンスのSTOP、STARTによる再起動操作が必要となる事があります。 この再起動を自動化する「Auto Recovery」機能が東京リージョンでも利用可能となりましたので紹介させていただきます。 Auto Recovery設定 Auto Recovery、AWSコンソールのCloudWatch画面で設定します。 詳細な設定手順は、Auto Recoveryが先行提供されていた米国リージョンと同じです。下記記事をご覧ください。 【新機能】EC2 Cloudwatchの新機能「Auto Recovery」を使ってみた まとめ AWSのEC2環境が稼働している仮想ホストやネットワークなどに物理的な障害が生じ、 EC2インスタンス障害に至る可能性、頻繁に発生するものではありませんが、0ではありませ
EC2リソースIDが長くなります - サーバーワークスエンジニアブログ
サポート窓口よりお知らせです。 既に、AWSのブログなどでご存知の方も多いかと思いますが、 EC2とEBSのリソースIDの桁数がこれまでの8桁から17桁に増えます。 一般社会のグローバルIPアドレスの枯渇でIPv6が求められるのと同じで、 AWSを多くの方々に利用してもらったことでIDが足りなくなってきたためです。 EC2ダッシュボードに入ると以下のような「通知」も表示されてようになりました。 移行スケジュール 一定の移行期間を用意して切り替えますので、その間に必要に応じて対処が必要です。 まず、移行スケジュールを紹介します。 既に、17桁のIDを持つインスタンスの起動は可能です。2016年3月までは8桁のIDが標準です。 それ以降は17桁が標準になります。そして、2016年12月に8桁のIDを持つインスタンスを 新たにローンチすることができなくなります。 尚、これはEC2に関するスケジュ
バーストパフォーマンスインスタンス - Amazon Elastic Compute Cloud
多くの汎用ワークロードでは、平均的な状態はビジーではないので、持続的で高いレベルの CPU パフォーマンスを必要としません。以下のグラフは、現在 AWS クラウドのお客様が実行している多くの一般的なワークロードにおける、CPU の使用率を示しています。 これらの CPU 使用率が低～中程度のワークロードが、CPU サイクルを浪費するような場合には、使用量以上の料金が発生することになります。こういった問題に対処するには、低コストのバースト汎用インスタンス (T インスタンス) を活用します。 T インスタンスファミリーは、ベースラインの CPU パフォーマンスを提供しながら、いつでも必要な時間だけ、能力をベースライン以上にバーストさせる機能を備えています。ベースライン CPU は汎用ワークロードにおける大部分のニーズを満たすように構成されており、大規模なマイクロサービス、ウェブサーバー、中小
【AWS】CloudWatch入門／EC2のステータスチェックを行ってみよう | DevelopersIO
はじめに こんにちは植木和樹です。そもそもCloudWatchってどんなことができるの？という質問をお客様から受けまして、そのお答えの一つとして「 CloudWatch Metrics for EC2 Status Checks」（初出：2012/07/18）で発表された、CloudWatchを使ったEC2のステータスチェックをご紹介したいと思います。 EC2のステータスチェックというのは、AWS内部で行われているインスタンスの正常性テストのことで、EC2のコンソールで（2/2 checks passed）と表示されているものです。 仮想マシンレベルで疎通がとれているかチェックしている「System Status Checks」と、OSレベルで疎通がとれているかチェックする「Instance Status Checks」の2つがあります。「System Status Checks」がエラー
Amazon EC2(Linux)システム管理で知らないとハマる5つの環境設定 | DevelopersIO
ども、大瀧です。みなさん、EC2をバリバリ使ってますか?使いたいときにすぐ使える仮想マシンとして、開発・検証から本番まで幅広く活用されていると思います。 日頃EC2を業務で運用する中で、EC2インスタンスをコピーすると意図しない環境設定に変わってしまうというトラブルが度々あり、cloud-initというツールに拠ることがわかってきました。 「EC2インスタンスのコピーなんて、一旦インスタンスを作成したあとはあまりやらないのでは?」と思われがちですが、EC2独特の制限などもあり、実際の運用では思ったよりも頻繁にインスタンスのコピーが必要になります。インスタンスのバックアップ&リストアなどはイメージしやすいと思いますが、それ以外にも意外なケースとして以下があります *1。インスタンスのコピーは、AMI(Amazon Machine Image:インスタンスのバックアップ)を取得し、新規インスタ
AWS再入門 Amazon EC2(Linux)編 | DevelopersIO
はじめに 当エントリはDevelopers.IOで弊社AWSチームによる『AWS サービス別 再入門アドベントカレンダー 2015』の10日目のエントリです。昨日9日目のエントリは森永の『AWS Config』でした。 このアドベントカレンダーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 本日10日目のテーマは『Amazon EC2』をLinux編(EC2全般を含む)とWindows編に分けて2本同日リリースでお伝えします。 Amazon EC2 (仮想クラウドサーバー) | アマゾン ウェブ サービス（AWS 日本語） Windows編はこちら 目次 サービスの基本的な説明 プライベートなネットワーク環境に仮想マシンを構築可
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS EC2にredisをインストールする - Qiita
