これらのオープンソース プロジェクトは、Amazon EKS によって管理されるクラスターを含む、AWS の内外で実行される Kubernetes クラスターの機能を拡張します。 管理ツール Amazon EKS および Kubernetes クラスターの関連する管理ツール。 eksctl eksctl は、Amazon EKS 上にクラスターを作成するためのシンプルな CLI ツールです。

接続先の DB インスタンスの確認 Aurora MySQL DB クラスター内のどの DB インスタンスに接続しているかを確認するには、次の例に示すように、innodb_read_only グローバル可変をチェックします。 SHOW GLOBAL VARIABLES LIKE 'innodb_read_only'; リーダー DB インスタンスに接続している場合、innodb_read_only 可変が ON に設定されます。プロビジョニングされたクラスターのプライマリインスタンスなどのライター DB インスタンスに接続している場合、この設定は OFF です。 この方法は、ワークロードを分散させるロジックや、書き込みオペレーションで適切な接続が使用されているかを確認するロジックを、アプリケーションコードに追加する場合に便利です。 Aurora MySQL のパフォーマンスとスケーリングの

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 AWS CLI スケルトンと入力ファイル ほとんどの AWS CLI コマンドは、ファイルからのすべてのパラメータ入力を受け入れます。これらのテンプレートは、generate-cli-skeletonオプションを使用して生成できます。 AWS CLI スケルトンと入力ファイルについて ほとんどの AWS Command Line Interface (AWS CLI) コマンドは、--cli-input-json--cli-input-yaml および パラメータを使用してファイルから入力されるパラメータのすべてを受け入れる機能をサポートしています。 これらの同じコマンドで、 JSON または YAMLの形式 でファイルが生成する --generate-cli-sk

ルーティングの優先度 一般的に、トラフィックと一致する最も具体的なルートを使用してトラフィックを誘導します。これは、プレフィックスの最長一致と呼ばれます。ルートテーブルに重複または一致するルートがある場合は、追加のルールが適用されます。 最長のプレフィックスの一致 IPv4 および IPv6 アドレスまたは CIDR ブロックへのルートは、互いに独立しています。IPv4 トラフィックまたは IPv6 トラフィックのいずれかに一致する最も具体的なルートを使用して、トラフィックのルーティング方法を決定します。 次の例のサブネットルートテーブルには、インターネットゲートウェイを指す IPv4 インターネットトラフィック (0.0.0.0/0) のルートと、ピアリング接続 (172.31.0.0/16) を指す IPv4 トラフィック (pcx-11223344556677889) のルートが含ま

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon EC2 Auto Scaling のライフサイクルフック Amazon EC2 Auto Scaling は、Auto Scaling グループにライフサイクルフックを追加する機能を提供します。これらのフックにより、Auto Scaling インスタンスライフサイクルのイベントを認識し、対応するライフサイクルイベントが発生したときにカスタムアクションを実行するソリューションを作成できます。ライフサイクルフックでは、インスタンスが次の状態に移行する前に、ライフサイクルアクションの完了を待つ時間 (デフォルトでは 1 時間) が指定されます。 Auto Scaling インスタンスでライフサイクルフックを使用する例として、以下を実行します。 スケールアウト

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 AWS Shield アンドシールドアドバンスドの仕組み AWS Shield Standard また、ネットワーク層、トランスポート層 (レイヤー 3 と 4)、アプリケーションレイヤー (レイヤー 7) AWS のリソースに対する分散型サービス拒否 (DDoS) AWS Shield Advanced 攻撃からの保護も提供します。DDoS 攻撃は、侵害された複数のシステムが、ターゲットに対してトラフィックでフラッディングを試みる攻撃です。DDoS 攻撃は正当なエンドユーザーがターゲットのサービスにアクセスするのを妨げ、圧倒的なトラフィック量のためにターゲットがクラッシュする可能性があります。 AWS Shield さまざまな既知の DDoS 攻撃ベクトルやゼロデ

拡張ネットワークのサポート 現行世代のすべてのインスタンスタイプ (T2 インスタンスを除く) は、拡張ネットワークをサポートしています。 次のいずれかのメカニズムを使用して、拡張ネットワークを有効にすることができます。 Elastic Network Adapter (ENA) Elastic Network Adapter (ENA) は、サポート対象のインスタンスタイプに対して最大 100 Gbps のネットワーク速度をサポートします。 AWS Nitro System 上に構築されたインスタンスはすべて、ENA を使用してネットワークを強化しています。さらに、H1、I3、G3、m4.16xlarge、P2、P3、P3dn、R4 の Xen インスタンスタイプは ENA をサポートしています。 詳細については、「EC2 インスタンスで Elastic Network Adapter

タグとは、お客様または AWS が AWS リソースに割り当てるカスタム属性ラベルです。各 タグは 2 つの部分で構成されます: タグキー (例: costcenter、environment または project) タグ値として知られるオプションのフィールド (例: 111122223333 または production) AWS のコストの追跡。これらのタグは、AWS Billing and Cost Management ダッシュボードで有効にします。AWS では、タグを使用してコストを分類し、毎月のコスト配分レポートを提供します。詳細については、AWS Billing ユーザーガイド の「コスト配分タグの使用」を参照してください。 タグに基づいて、Auto Scaling グループへのアクセスを制御します。IAM ポリシーで条件を使用して、そのグループのタグに基づき、Auto S

ベストプラクティスとして、ロールを作成する場合、そのアクセス許可は、アプリケーションが AWS のサービス にアクセスするために必要な最低限のレベルにすることを強くお勧めします。 前提条件 Amazon EC2 で実行されているアプリケーションが引き受けることができる IAM ロールを作成します。結果としてロールを引き受けたアプリケーションが必要な特定の API 呼び出しを実行できるように、適切なアクセス許可を選択します。 AWS CLI または AWS SDK の代わりに IAM コンソールを使用すると、コンソールによってインスタンスプロファイルが自動的に作成され、対応するロールと同じ名前が付けられます。 IAM ロールを作成するには（コンソール）IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。 左側のナビゲーションペインで、[

Auto Scaling インスタンスのヘルスステータスは、正常または異常のどちらかを示します。Auto Scaling グループ内のすべてのインスタンスは Healthy ステータスで開始します。インスタンスに異常があるという通知を Amazon EC2 Auto Scaling が受け取らない限り、インスタンスは正常であると見なされます。この通知は、Amazon EC2、Elastic Load Balancing、VPC Latiice、またはカスタムヘルスチェックなどのソースから送信されます。Amazon EC2 Auto Scaling は、異常なインスタンスを検出すると、それを新しいインスタンスに置き換えます。

起動する各インスタンスには、Amazon EBS ボリューム、またはインスタンスストアボリュームのどちらかのルートデバイスボリュームが関連付けられています。ブロックデバイスマッピングを使用すると、インスタンスの起動時にそのインスタンスにアタッチする追加の EBS ボリュームまたはインスタンスストアボリュームを指定できます。追加する EBS ボリュームは、実行中のインスタンスにアタッチすることもできます。ただし、インスタンスストアボリュームについては、ブロックデバイスマッピングを使用して、インスタンスの起動時にアタッチする以外方法はありません。 ルートデバイスボリュームの詳細については、永続的ルートボリュームへの変更を参照してください。 ブロックデバイスマッピングの概念 ブロックデバイスは、一連のバイトまたはビット (ブロック) でデータを移動するストレージデバイスです。これらのデバイスはラ

To ensure that a Classic Load Balancer stops sending requests to instances that are de-registering or unhealthy, while keeping the existing connections open, use connection draining. This enables the load balancer to complete in-flight requests made to instances that are de-registering or unhealthy. When you enable connection draining, you can specify a maximum time for the load balancer to keep c

これらのトピックでは、MySQL DB エンジンを実行する Amazon RDS インスタンスで使用できるシステムストアドプロシージャについて説明します。マスターユーザーがこれらの手順を実行する必要があります。

しかし、実行中のクエリの PID を調べたいときもあります。例えば、実行に時間がかかりすぎているクエリをキャンセルしたい場合などに、この PID が必要です。STV_RECENTS システムテーブルに対してクエリを実行すると、実行中のクエリのプロセス ID とそれに対応するクエリ文字列のリストを取得することができます。クエリに複数の PID がある場合は、クエリテキストを参照して、どれが目的の PID かを判断することができます。 実行中のクエリの PID を調べるには、以下の SELECT ステートメントを実行します。

この機能は以下を使用して設定します。 max_attempts-AWS config 共有ファイル設定 AWS_MAX_ATTEMPTS-環境変数 1 回のリクエストの最大試行回数を指定します。 デフォルト値:この値が指定されていない場合、retry_modeデフォルトは設定の値によって異なります。 If retry_mode is legacy — SDK 固有のデフォルト値を使用します (max_attemptsデフォルトについては、特定の SDK ガイドまたは SDK のコードベースを確認してください)。 retry_modeその場合 standard — 3 回試行します。 retry_modeその場合 adaptive — 3 回試行します。

Aurora MySQL レプリケーション機能は、クラスターの高可用性とパフォーマンスにとって重要な要素です。Aurora では、最大 15 個の Aurora レプリカを使用して、簡単にクラスターの作成またはサイズ変更を行うことができます。 すべてのレプリカは同じ基盤となるデータから機能します。一部のデータベースインスタンスがオフラインになると、他のデータベースインスタンスがクエリの処理を続行します。あるいは、必要に応じてライターの機能を引き継ぐことができます。Aurora は複数のデータベースインスタンスに読み取り専用接続を自動的に分散させ、Aurora クラスターがクエリ負荷の重いワークロードをサポートできるようにします。 以下のトピックでは、Aurora MySQL レプリケーションのしくみと、レプリケーション設定を最大限の可用性とパフォーマンスを得るために調整する方法について説明

Amazon Aurora は定期的に更新をリリースします。更新はシステムメンテナンスの時間中に Aurora DB クラスターに適用されます。更新が適用されるタイミングは、リージョンや DB クラスターのメンテナンスウィンドウの設定、および更新のタイプによって異なります。 Amazon Aurora のリリースは、数日のうちに、すべての AWS リージョンで使用可能になります。一部のリージョンでは、別のリージョンではまだ使用できないエンジンバージョンが一時的に表示されることがあります。 更新は、DB クラスター内のすべてのインスタンスに同時に適用されます。更新では、DB クラスター内のすべてのインスタンスでデータベースを再起動する必要があるため、20 ～ 30 秒のダウンタイムが発生します。その後、DB クラスターの使用を再開できます。AWS Management Console でメン