かっぱえびせんの忘備録

情報系の勉強中に気になったこととか趣味やあれこれ

AWS ConfigとAWS CloudTrailとAWS CloudWatchの機能と違い

はじめに

AWSの中でも、これらのサービスは「リソースを監視する」という点で似ています。
AWSの勉強をしていると、毎回混乱するので、それぞれの機能と違いをまとめてみました。
(Associateレベルの資格勉強のメモ程度に書いています)

サービス概要

AWS Config

AWS上のリソースの構成を評価・監査することができるサービスです。
また、AWS上のリソースの変更を継続的に記録することができます。

機能概要

  • AWSリソースの変更の記録
    • 記録の保存
    • リソースの変更発生時の通知(AmazonSNSとの連携)
  • ポリシーに準拠しているか監査・評価
    • ポリシー違反の修正(AWS System Managerとの連携)
    • ポリシー違反の通知(Amazon SNSとの連携)

などなど

AWS CloudTrail

AWS上のユーザーアクティビティとAPI使用状況を追跡することができるサービスです。
AWSインフラ全体のユーザー操作を記録・監視することができます。

機能概要

  • AWSサービスへの変更を「いつ」「誰が」「どこで」実施したかを記録
    • 「データイベント」と「管理イベント」の2種類を記録
      • データイベント:AWSアカウント内のリソース内で実行されたリソースオペレーション(例:S3オブジェクトの操作等)
      • 管理イベント :AWSアカウント内のリソースに対し実行された管理オペレーション(例:IAMリソースの作成等)
  • 異常なアクティビティの検知(AWS CloudTrail Insight)

などなど

AWS CloudWatch

AWS上のリソースとアプリケーションを監視するサービスです。
メトリクスを監視し、リソースの状況を可視化したり、リソースが異常な状態になった場合にアラームの状態を変更したりすることができます。

機能概要

  • 各種メトリクスのトラッキング(EC2のパフォーマンス等)
  • ログファイルの収集・保存(各種アプリケーションログの収集等)
  • アラームの設定(メトリクスが閾値を超えた場合にアラーム状態を変更)
    • アラームとEvent Bridgeを連携し、アラームが発生したときに特定の動作を実施

などなど

AWS CloudWatch Eventという機能がありましたが、これはEventBridgeへ変更されるようです)

サービス比較

それぞれのサービスの目的を比較してみます

AWS Config vs AWS CloudTrail

  • AWS Config

    • 「リソースの変更管理」が主眼に置かれています
  • AWS CloudTrail

    • 「ユーザー操作(誰がいつどこから?)の管理」が主眼に置かれています

どちらもリソースの変更のモニタリングという点で似ていますが、 興味の対象が「リソース」であるか「ユーザー」であるか、の違いと考えられます。

AWS CloudTrail vs AWS CloudWatch

  • AWS CloudTrail

    • 「ユーザー操作の監査」に主眼が置かれています
  • AWS CloudWatch

    • 「アプリケーションの状態の監視」に主眼が置かれています

目的が「監査」なのか「監視」なのか、の違いと考えられます。

まとめ

それぞれ似た機能を持つサービスですが、ドキュメントを読んでみると目的等が異なることがよくわかります。 それぞれのサービスを利用する場合は、達成したい目的に沿ったサービスを利用したいですね。

Linux MintにSML#を導入してみた

 とある用事でSML#を使う必要があったのですが、自分が仮想環境で利用していたLinux MintにSML#を導入するのにかなり苦労してしまいました。というのも現在リリースされているSML#は32bit版なのに対し、SML#のコンパイルと実行に必要なライブラリがデフォルトで64bit向けになっているためapt-getが使えず。あちらこちらから必要なものを直接落としてコンパイルする必要がありました。
 後学のために導入の手順を残しておきます.(冗長な部分があるかもしれないので適宜取捨選択してください)

32bit向けコンパイラの導入

まずは必要なSML#に必要なライブラリの32bit向けコンパイルを行うためにgcc-multilibを導入します。(ついでにg++-multilibも導入しちゃいましょう。)

sudo apt-get install gcc-multilib g++-multilib

(もしかしたら32bit環境のライブラリを用意しておくと幸せになれるかもしれない)

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386

GMP,LLVMのダウンロード

続いてSML#のコンパイルと実行に必要なライブラリであるGMPとLLVMを導入します。それぞれ以下のサイトからダウンロードして適当なところ展開してください。

※この時、gmpのバージョンは5.1.2、LLVMのバージョンは3.4を推奨します。gmpに関しては別バージョンでも構いませんが、LLVMはバージョンによって仕様が大きく異なるため、3.4以外を導入すると最悪動きません。

gmp,LLVMの32bit向けコンパイル

gmp,LLVMの32bit向けコンパイルを行うために下準備をします。展開したそれぞれのフォルダの中に移動し、configureを実行します。これはgmpもLLVMも共通です。

./configure ABI=32 --prefix=(コンパイル後のファイルを置いておきたい場所の絶対パス)

もしかしたらLLVMのconfigureの実行時にMakefileが作成されないかもしれません。その場合はパッケージでM4をインストール(sudo apt-get install M4)してから再度configureを実行してみてください。 (ちなみにconfigureはMakefileを生成するスクリプトで、オプションとしてABI=32を付与することで32bit向けコンパイルを行ううためのMakefileを生成することができます。)
続いて、makeを行います。

make
make install

これでgmp,LLVMコンパイルが完了しました。

SML#のダウンロード・コンパイル

最後のステップです。SML#を以下のリンクからダウンロードし展開します。パッケージ種別はsourceで。

展開したら中に入り、configureを実行します。

./configure CC='gcc -m32' LD='ld -m elf_i386' CXX='g++ -m32' CPPFLAGS=-I(コンパイル後のgmpの絶対パス) --prefix=(コンパイル後のsmlsharpを作成したい場所の絶対パス) --with-llvm=(コンパイル後のLLVM絶対パス)

configureが完了したらMakeを行います。

make -j4
make install

※makeをするときに付けるオプション-j4の数字の部分はCPUのコア数にしてください。このオプションを付けることである程度高速にコンパイルできます。
以上がSML#の導入手順になります。

まとめ

結論から言ってしまえばSML#のコンパイル、実行に必要なライブラリを32bit向けにコンパイルすれば良かっただけの話でした。
で、64bit版SML#の公開はまだですか?