はてなブックマーク

概要 スループットモードについて Amazon EFS（Elastic File System）は、スケーラブルでバースト可能なスループット性能を提供します。EFSのファイルシステムで選択可能なスループットモードには、バースト(デフォルト) or プロビジョニング済み があります。 スループットモードは後から切り替え可能です。また、プロビジョニングされたスループットモードでスループットを減らすことができます。ただし、前回変更した時点から 24 時間経過している必要があります。 バーストスループットモード バーストスループットモードは、保存されたデータ量に応じてスループットが高くなる。現在のスループットがベースラインより低い場合にバーストクレジットが蓄積され、スループットがベースラインより高い場合にバーストクレジットが消費される。 いずれのサイズにおいても、100 MiB/s のスループット

概要 はじめに 今回は、同一VPCに配置されたEC2～RDS間の疎通確認について記載します。 なお、DBクライアントからの接続ではなく、TCP/IPレイヤーでの接続確認となります。 目的 EC2、RDSを起動した後にEC2～RDS間の疎通確認を行います。特に、インフラ構築とその後のアプリデプロイやDBのテーブル作成以降の構築が別担当となることが多く、責任分界点として、各プロダクト間のサブネット、ルーティングやセキュリティグループが正しいことを確認することが目的です。 TCP/IPレイヤーの確認であれば、EC2にDBクライアントをインストールする必要がないため、DBクライアントのインストールが不要です。RDSの種別ごとにクライアントのソフトも異なるため、この段階で準備の煩わしさを回避できます。 RDS疎通確認の方法 EC2（Windows Server）からのRDS疎通確認 以下に、Wind

概要 今回は、CentOS あるいは Amazon Linux に標準でインストールされているauditd を使って監査ログを取得する方法をご紹介します。 auditd は事前に設定したルールに基づき、システムで発生しているイベントを記録します。例えば、auditdは下記のイベントを監視して、ログにイベントを記録することができます。 ファイルアクセスの監視 システムコールの監視 ユーザーが実行したコマンドの記録 セキュリティーイベントの記録 ネットワークアクセスの監視 auditdは、CentOS、Amazon Linuxでデフォルトでインストールされているため、追加でインストールする必要はありません。 auditdにルールを設定して監査ログを有効化 以下の通り、デフォルトではルールは定義されていません。 $ sudo auditctl -l No rules 設定ファイルにルールを追加し

概要 今回は、MFA（多要素認証：Multi-Factor Authentication）を使用する環境において、aws cli を利用するための認証方法をご説明します。 AWSアカウントあるいはIAMユーザーのセキュリティを向上させるには、MFAを設定します。IAMユーザーに仮想MFA を有効にする方法は、以前記載したこちらの記事を参照ください。 MFAが設定された環境で、AWSコンソールにログインするときにはユーザー名、パスワードの他に、MFAコード（6桁の数字）が必要となりますが、aws cli を利用する時も同様にMFAコードを入力して認証する必要があります。 MFAの認証をせずにaws cli を実行した場合 MFAの認証をせずにaws cli を実行すると、下記のエラーとなります。これは、MFAを使った一時的な認証情報を取得する必要があるためです。 niikawa@niikaw

概要 今回、API Gatewayを使ったシステムを設計するにあたり、API Gatewayをプライベートのエンドポイントタイプで構成するか、パブリックのエンドポイントタイプ（リージョン or エッジ最適化）で構成するかを検討した際に改めて調査した結果をアウトプットします。 API Gatewayをプライベートタイプで使用する時の落とし穴 実は昨年担当した案件でも同じ悩みがありました。当初API Gateway をプライベートで構成しようと試みましたが、VPC Endpoint を設定したらなぜか繋がらない。その後構成見直しが入り、課題と思われたAPI Gateway の機能は廃止されたため、プライベートは要注意だという印象を持ったまま腹落ちしない状況でした。今日は、改めて当時の課題を再現しつつ、解決策を整理させていただきます。 API Gateway のプライベートタイプを使う時にハマる

概要 はじめに クライアントからのリクエストに対して、ELBからHTTP 503のエラーが返ることがあります。今回は、ELB（主にALB）からHTTP 503が返されたときのトラブルシューティングをまとめます。 HTTP 503とは HTTP 503とは”Service Unavailable”であり、一時的にサーバーにアクセスできないことを示します。一般的な原因として、サーバーに多数のアクセスが集中してサーバーが処理不能となった、サーバーの最大データ転送量を超過したなどがあるようです。 また、AWSのドキュメントには、下記の記述があり、ALBに対応したターゲットグループに有効なターゲットがいない場合が原因となるようです。しかし、全ての原因が下記とは限りませんので、もう少し深堀します。 ロードバランサーのターゲットグループに登録済みターゲットがありません。 構築時のトラブルシューティング

概要 はじめに 今回はALB（Application Load Balancer）にEC2を組み合わせたポピュラーなシステム構成の構築方法をご紹介します。 ALBはInternet-facingとし、クライアントからhttpsで接続します。そのため、ACM（AWS Certificate Manager）でSSL証明書を取得し、ALBにSSL証明書をセットします。 ドメインはRoute 53で登録しましたので、Route 53についても合わせてご説明します。 システム構成 以下にシステム構成のイメージを図示しました。ALBはInternet-facingとなるため、Public Subnetに配置します。EC2はPrivate Subnetとします。EC2には、Webサーバー（Nginx）が動作しています。 重要なポイントはクライアントからインターネット経由のALBまではhttps接続（4

次は、cloud-initの設定を変更します。cloud-initは、Linux OSを初期設定するためのサービスです。 Linux OSの構築後、インスタンスのイメージ（AMI）を取得することは一般的かと思います。AMIは、Auto Scalingによるスケールアウト時や単純に2台目以降を複製するケース、あるいは障害からの復旧や人為的ミスから以前の状態を復元するなどの目的で取得します。 下記のcloud-initの設定変更によって、インスタンスの起動時に本記事で設定した内容がデフォルトに戻らないようにします。 以下、設定変更するパラメータの説明です。他のパラメータは必要に応じて、調査・変更ください。 ssh_pwauth → “1"を設定して、インスタンス初回起動時に、デフォルトでパスワード認証を選択する（後述するプライベートなサブネットに配置したEC2で認証方法にパスワード認証を選択し

Oji-Cloud クラウドとテクノロジーが人生をHappyにする。クラウドインテグレーターに転職したぱぱエンジニアが発信するテクニカルブログ。 概要 はじめに ここ最近NLBを使ったシステムを構築していますので、本日はALB、NLBロードバランサーの比較と、NLBの特徴を中心に記事にまとめたいと思います。 ALB、NLBとは ALB、NLBのどちらもELB（Elastic Load Balancing）の1つです。ELBはAWSが提供するロードバランサーであり、受信したアプリケーションまたはネットワークトラフィックをEC2 インスタンス、コンテナなど、複数のターゲットに分散させることが可能です。 ALB、NLBは、ヘルスチェックを利用して、異常なターゲットを検出すると、それらのターゲットに対するトラフィックの送信を中止し、残りの正常なターゲットに負荷を分散できます。 以下に、ALB、NL

DynamoDBテーブルからレコードを抽出したい びっくり。DynamoDBのコンソールは検索に弱い… DynamoDBで多くのレコードが登録されたテーブルの場合、AWSコンソールから条件を指定してフィルターしても検索が中断されてしまい、検索結果が表示されないことが分かりました。残念、コンソールでは多くのレコードを持つテーブルでのレコード検索ができませんでした！（驚 次に、AWS CLI を使い、テーブルをscanして安易に全レコードをファイルにリダイレクトしましたが時間が掛かり…、効率的ではありませんでした（汗 DynamoDBのテーブルをクエリする 次にドキュメントを読みながら、テーブルのクエリを行います。初めてのクエリで複雑な指定に戸惑いましたが、KeyConditionsを指定することでレコードの条件が指定できます。以下ドキュメントに、aws dynamodb query –key