新ネットワークスペシャリスト道

ネットワーク、セキュリティ、何の話?

【AWS 100日チャレンジ - 56日目】Systems ManagerからCloudWatchエージェントをインストールする

AWSの知識を血肉にするための「AWS 100日チャレンジ」の56日目です。

肌寒い一日でした。

 

AWS 100日チャレンジの記事を書く上でのルール

・100日連続アウトプット!

・継続が第一、クオリティは第二

・「社会人のリアル」を忘れない(持続可能な完走を目指す)

・コアな学習に全集中!
 テーマとするサービス以外は、CloudFormationや構築済みの資産をフル活用。効率よく「核心」を突き詰めます。

課題

Systems ManagerからCloudWatchエージェントをインストールする

実施 

Systems ManagerのRunCommandを使用してCWエージェントをインストールします。

1.インスタンスプロファイルにCWエージェントのロールを設定

以下ポリシーを含むものロールを作成する。

・AmazonEC2RoleforSSM

・CloudWatchAgentServerPolicy

 

そのポリシーをCWエージェントをインストールするEC2のインスタンスプロファイルに設定する。

 

2.RunCommandを新しく作成

コマンドのドキュメントに「AWS-ConfigureAWSPackage」を選択。

 

コマンドのパラメータを以下設定。

・Action: install
・Installation Type:Uninstall and reinstall
・Name: AmazonCloudWatchAgent
・Version:latest

 

ターゲットに対象EC2に選択。

 

コマンドを作成するとステータス画面になる。

ステータスは成功になってます。

 

3.動作確認

対象EC2にSSHログインしてCWエージェントがインストールされているか確認。

systemctl status amazon-cloudwatch-agent.service

rpm -qa | grep cloudwatch

 

今回のAWS利用料金

RunCommand自体の利用料は無料。

 

 

【AWS 100日チャレンジ - 55日目】AWS Resource Groups による一括管理

WSの知識を血肉にするための「AWS 100日チャレンジ」の55日目です。

今日は雨で肌寒かったです。

少しだけ遠出したのですが、道すがらまだ桜が散っていませんでした。

山中だから寒くて遅咲きなのかしら。

 

AWS 100日チャレンジの記事を書く上でのルール

・100日連続アウトプット!

・継続が第一、クオリティは第二

・「社会人のリアル」を忘れない(持続可能な完走を目指す)

・コアな学習に全集中!
 テーマとするサービス以外は、CloudFormationや構築済みの資産をフル活用。効率よく「核心」を突き詰めます。

課題

AWS Resource Groups による一括管理

実施 

1.前準備

タグづけして管理するサービスが必要なのでそれをまず準備する

 EC2インスタンス 2つ

 S3バケット 1個

それぞれに以下タグを設定。

キー:Environment 値:stg

キー: Project  値:soa

2.リソースグループの作成

次にResource Groups を開く。

リソースグループを作成をクリック。

グループタイプは「タグベース」を選択。

 

リソースタイプは、前準備で作成した以下。

 AWS::EC2::Instance

 AWS::S3::Bucket

タグキーはProjectで、値はsoaを入力する。

右下の「グループリソースをプレビュー」をクリック。

対象になるサービスが表示される。

グループ名を適当に入力。(グループ名:project-soa-tag-group)

グループを作成をクリック。

 

3.Systems Manager (SSM) との連携確認

対象タググループに対し、一括操作を行う。

SSMのRunCommandを開く。

コマンドAWS-RunShellScript を選択。

コマンドのパラメータを以下とする。

ls -al

 

 

ターゲットにタグキーProcet、値をsoaとする。

 

実行してみます。

 

実際に実行されているかわからないのですが、成功にはなっています。

 

今回のAWS利用料金

利用料は特になし。

 

 

【AWS 100日チャレンジ - 54日目】空ではないS3バケットをCLIから削除する

AWSの知識を血肉にするための「AWS 100日チャレンジ」の54日目です。

天気が良いので干せるもの全部干した。

冬シーツもやっと干せた。

 

AWS 100日チャレンジの記事を書く上でのルール

・100日連続アウトプット!

・継続が第一、クオリティは第二

・「社会人のリアル」を忘れない(持続可能な完走を目指す)

・コアな学習に全集中!
 テーマとするサービス以外は、CloudFormationや構築済みの資産をフル活用。効率よく「核心」を突き詰めます。

課題

空ではないS3バケットをCLIから削除する

実施 

まずはS3にバケットを用意して、適当なファイルをアップロードする。

 

CLIを開く。

←右上のこのマーク

 

CLIにて以下コマンドを実行する。

aws s3 rb s3://rm-test-backet --force

 

削除されていました!

 

S3バケット自体、空でないと削除できないので、このコマンドであれば楽ちんです。

 

今回のAWS利用料金

特に費用なし

 

 

【AWS 100日チャレンジ - 53日目】CPU使用率を高め、CloudWatchアラームからEC2アクションを発生させる

AWSの知識を血肉にするための「AWS 100日チャレンジ」の53日目です。

今日は雨で肌寒かった。

 

AWS 100日チャレンジの記事を書く上でのルール

・100日連続アウトプット!

・継続が第一、クオリティは第二

・「社会人のリアル」を忘れない(持続可能な完走を目指す)

・コアな学習に全集中!
 テーマとするサービス以外は、CloudFormationや構築済みの資産をフル活用。効率よく「核心」を突き詰めます。

課題

CPU使用率を高め、CloudWatchアラームからEC2アクションを発生させる

実施 

1.インスタンスプロファイルにCloudWatchAgentServerPolicyを含んだロールを設定

 

2.Cloudwatchアラームを作成

メトリクスの選択画面でEC2のインスタンスIDを指定して検索する。

 

CPUUtilizationにチェックを入れる。

メトリクスを選択をクリック。

 

統計を最大にして、期間を1分にする。

条件に80以上を設定。

 

アクションの設定でSNSを設定

(SNSは以前使用したものを指定)

 

EC2アクションを設定

「このインスタンスの再起動」を選択

 

アラーム名を入力する。

アラーム名:XXX-Test-Alarm

 

 

3.動作確認

EC2にリモートログインする。

 

CPU負荷commandをインストールする

sudo dnf install stress -y

 

CPU負荷を挙げるコマンドを実行

stress --cpu 1 --timeout 300

 

EC2が再起動かかるか確認する。


コマンドを入力してから5分くらい?たった後に再起動がかかりました。

 

アラームメールも受信。

 

【AWS 100日チャレンジ - 52日目】CloudWatch LogsのサブスクリプションフィルターでLambdaへ転送してみる

AWSの知識を血肉にするための「AWS 100日チャレンジ」の52日目です。

今日も頑張ります。

 

AWS 100日チャレンジの記事を書く上でのルール

・100日連続アウトプット!

・継続が第一、クオリティは第二

・「社会人のリアル」を忘れない(持続可能な完走を目指す)

・コアな学習に全集中!
 テーマとするサービス以外は、CloudFormationや構築済みの資産をフル活用。効率よく「核心」を突き詰めます。

課題

CloudWatch LogsのサブスクリプションフィルターでLambdaへ転送してみる

実施 

CloudWatch Logsのサブスクリプションフィルターは、ロググループに届いたログデータをリアルタイムで他のAWSサービス(Lambda、Kinesis Data Streams、Kinesis Data Firehoseなど)に転送するための仕組みです。

転送先は複数種類がありますが、Lambdaにします。

1.CloudWatchのロググループ設定

EC2にエージェントをインストールして、CloudWatch Logsにログが記録されるようにします。


CWエージェントのconfig.jsonはAPACHEのerror_logのみを収集する設定にしました。

sudo vi /opt/aws/amazon-cloudwatch-agent/bin/config.json

{
    "agent": {
    "run_as_user": "root"
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/etc/httpd/logs/error_log",
            "log_group_name": "Apache-Error-Logs",
            "timestamp_format": "[%a %b %d %H:%M:%S.%f %Y]"
          }
        ]
      }
    }
  }
}

CWエージェントを起動。

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s

CWエージェント起動確認

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status

 

2.Lambda関数作成

サブスクリプションフィルタの送信先にLambdaを指定するので受け皿であるLambda関数が必要。

 

関数プログラムは以下

import base64
import json
import gzip
import boto3

sns = boto3.client('sns')

def lambda_handler(event, context):
    # データのデコードと解凍
    data = event['awslogs']['data']
    decoded_data = base64.b64decode(data)
    log_json = json.loads(gzip.decompress(decoded_data))

    # ログメッセージの抽出
    for log_event in log_json['logEvents']:
        msg = log_event['message']

        # SNSへ送信(ARNを直接指定)
        sns.publish(
            TopicArn='SNSのARN',
            Subject="Apache Error Alert",
            Message=f"Server Log: {msg}"
        )

    return {'statusCode': 200}

 

3.サブスクリプションフィルターの作成

CloudWatchの管理画面よりログ「Apache-Error-Logs」をクリック。

サブスクリプションフィルタータブをクリック。

作成ボタンを押す。

 

作成するのは、Lambdaサブスクリプションフィルタ。

 

SNSはすでに作成しているものを使用しました。

 

3.動作確認

Ec2にログインして、以下コマンドを実行しログを出力する。

echo "[$(date)] [error] これは本物のApacheから送られたテストメッセージです!" | sudo tee -a /etc/httpd/logs/error_log

 

Gmailを確認するとメールが飛んできているのがわかりました。

 

【AWS 100日チャレンジ - 51日目】API Gateway + Lambda でAPIアプリを構築してみる

AWSの知識を血肉にするための「AWS 100日チャレンジ」の51日目です。

今日のご飯はなんだろなぁ~。

 

AWS 100日チャレンジの記事を書く上でのルール

・100日連続アウトプット!

・継続が第一、クオリティは第二

・「社会人のリアル」を忘れない(持続可能な完走を目指す)

・コアな学習に全集中!
 テーマとするサービス以外は、CloudFormationや構築済みの資産をフル活用。効率よく「核心」を突き詰めます。

課題

API Gateway + Lambda でAPIアプリを構築してみる

実施 

最も標準的な「REST API」を作成し、Lambda で「Hello World」を返す構成を作成する。

1.Lambda関数作成

タイプ:「一から作成」

関数名:XXX-Function

言語:Python

実行ロール:自動生成

2.API Gateway の作成

次に、入り口となる「窓口」を作ります。

API タイプを選択:REST API

 

API名:XXX-REST-API

API GsteWayの画面からリソースを作成する。

次にメソッドを作成する。上記画像の「メソッドの作成」をクリック。

メソッドタイプ:GET

統合タイプ:Lambda関数
Lambdaプロキシ統合:ON

Lambda関数:手順1で作成した関数のARN

APIをデプロイする。

APIデプロイをクリックする。

ステージ:新しいステージ

ステージ名:prod

表示された 「URL の呼び出し」 をコピー

 

3.動作確認

手順2でコピーしたURLに対しCURLcommandを実行して確認。

コマンドプロンプト開きcommand入力して実行

curl https://cod4gwxwyc.execute-api.ap-northeast-1.amazonaws.com/prod

エラーがでました。

{"message":"Missing Authentication Token"}

最後に「/hello」をつけ忘れていたのが原因でした。

curl https://cod4gwxwyc.execute-api.ap-northeast-1.amazonaws.com/prod/hello

"Hello from Lambda!"

 

Lambdaの画面からモニタリングを確認すると実行されているのがわかります。

 

今回のAWS利用料金

.①AWS Lambda

 無料枠:  1ヶ月あたり 100万リクエスト、および 400,000 GB-秒のコンピューティング時間が無料。 

 

②Amazon API Gateway

 無料枠:  REST API の場合、1ヶ月あたり 100万リクエストまで、12ヶ月間の無料枠があります。 


無料枠の期間内であれば無料ですが、期間を過ぎている場合は 100万リクエストごとに数ドルのコストが発生します。

 

 

【AWS 100日チャレンジ - 50日目】S3 バケットキーとサーバー側の暗号化 (SSE-KMS)

LambdaによるEC2の自動停止(スケジュール実行)AWSの知識を血肉にするための「AWS 100日チャレンジ」の50日目です。

やっとこさ、半分です。

100日って長い。

すごく長く感じます。

 

AWS 100日チャレンジの記事を書く上でのルール

・100日連続アウトプット!

・継続が第一、クオリティは第二

・「社会人のリアル」を忘れない(持続可能な完走を目指す)

・コアな学習に全集中!
 テーマとするサービス以外は、CloudFormationや構築済みの資産をフル活用。効率よく「核心」を突き詰めます。

課題

S3 バケットキーとサーバー側の暗号化 (SSE-KMS)

実施 

途中でも作成できるがまずはKMSキーを作成する。

1.KMSキー作成

エイリアスは、XXX-S3-TestKeyで作成。

キーの管理者は、ログインIAMユーザにしました。

キーの使用者

作成完了。

 

2.S3バケットに設定

S3バケットのプロパティタブから手順1で作成したKMSキーを選択する。

 

2.動作確認

◆バケットにファイルをアップロードして確認してみる。

 

◆CloudTrailから確認

PutBucketEncryptionの履歴が残っている。