しょーもないことなのですが、若干時間かかったので。 やろうとしたこと TerraformでEC2インスタンスを作成する際にSSHキーをインポートしたかった。 出たエラー planが通ったのでapplyすると... $ terraform apply -var-file=vars.tfvars こういう感じで怒られました。 Error: Error import KeyPair: InvalidKey.Format: Key is not in valid OpenSSH public key format status code: 400, request id: 28fb3e7c-653f-41c2-a2ec-212d69b8a5e9 該当箇所のコード main.tf #略 # SSH key for EC2 resource "aws_key_pair" "ec2-key-pair" { key_name = var.ssh_key_name public_key = var.ssh_key_path } #略 変数ファイルと値は以下のような感じです variables.tf # AWS credential variable "access_key" {} variable "secret_key" {} # EC2 SSH key variable "ssh_key_name" {} variable "ssh_key_path" {} # AMI id variable "ami_id" {} vars.tfvars access_key = "XXXXXXXXXXXXXXXXXXXX" secret_key = "XXXXXXXXXXXXXXXXXXXX" ssh_key_name = "terraform_test_rsa" ssh_key_path = "~/.ssh/terraform_test_rsa.pub" ami_id = "ami-00000000000000" とりあえず公式を確認してみる 鍵ファイルの中身自体をpublic_keyの値に持たせるのが正解らしいです。全然読んでませんでした。 で、さらに確認するとこういう関数があるみたいでして... ということで修正します。 修正 main.tf # SSH key for EC2 resource "aws_key_pair" "ec2-key-pair" { key_name = var.ssh_key_name public_key = file(var.ssh_key_path) } これで再度applyするとうまく実行されました。

プログラミング勉強日記 2021年4月14日 ロードバランサ―(LB)とは 　サーバーへのアクセスを安定させるための装置・仕組みのこと。load(負荷) + Balancer(釣り合いをとるためのもの) という意味の言葉で、負荷分散装置とも呼ばれている。 　ロードバランサ―を使うと、アクセスの安定性が向上し、不具合のある危機を自動的に検知して他のサーバーに振り分けることができるので、システムが落ちることも防げる。 　Webサイトにアクセスがあった場合、通常は1台のサーバーがリクエストのすべてを処理する。しかし、ロードバランサ―を使うとアクセスを複数のサーバーに分割して処理することができる。 AWSのロードバランサ― 　AWSが提供しているロードバランサ―にはNLB(Network Load Balancer)とALB(Application Load Balancer)、CLB(Classics Load Balancer)の3種類ある。 NLB(Network Load Balancer)とは 　NLBはトランスポート層でルーティングの決定が行われるので、毎秒数百万の大量のリクエストを処理することができる。動的なマッピングで、効率がいいロードバランサ―。 トランスポート層とは、通信プロトコル（通信手順/通信規約）の機能や役割を階層構造で整理したモデルを構成する層の一つで、データの送信元と送信先の間での制御や通知、交渉などを担うもの。 (文献:トランスポート層 【transport layer】 第4層 / layer 4 / レイヤ4 / L4) ALB(Application Load Balancer)とは 　ALBは名前の通り、アプリケーション層でルーティングの決定を行う。1つのクラスター内で複数のリクエストを処理することができる。NLBと同様に動的マッピングである。 CLB(Classics Load Balancer)とは 　CLBはトランスポートレイヤーもアプリケーションレイヤーでもどちらでもルーティングを決定できる。CLBは静的なマッピングで、サービスと同じ数だけのコンテナインスタンスが必要なロードバランサ―。 参考文献 ロードバランサー（LB）とは？仕組みやDNSラウンドロビンとの違いについて解説

概要 先日AWS認定試験に合格したので、credlyからバッジのお知らせメールが来ておりました。 どうやらサイトにバッジを埋め込めるとのことだったので、 せっかくなので自分のポートフォリオに埋め込んでみました。 前提 credlyのアカウントを作成済みであること 方法 1. メールのリンクをクリック こんな感じでメールが届くので「バッジを入手する」をクリックします。 2. Accept Badgeをクリックしてバッジを公開OKにする 3. バッジ個別ページのshareボタンをクリック 4. 埋め込みコードをコピーしてサイトにペースト

実務未経験でも受験可能!!AWS認定 ソリューションアーキテクト アソシエイト 勉強法①「概念理解〜書籍学習」 参考 どのAWS資格を受けたらいいのか 参考サイト：https://qiita.com/nakazax/items/20458e146d3d9f2aa615 ソリューションアーキテクト用の勉強方法 参考サイト:https://qiita.com/fkooo/items/e5284a4ed3c3466ffd41 受験アカウントの作成(申し込みまではしません) ※AWSアカウントではなく受験アカウントの作成をする 作成後に英語表記での住所登録などが必要になります。 英語表記に自信のない方はこちらで日本語→英語の変換ができます。 登録後に受験方法が選択できるようになります。 受験方法は２種類 PSI ピアソンVUE おすすめはピアソンVUEです。 PSIからの申し込みの場合、基本的に申し込みは英語です。また本人確認書類にその英語表記の確認書類(パスポートなど)が必要になります。 その点、ピアソンVUEであれば、申し込み段階で日本語と英語を選ぶことができ、本人確認書類も運転免許証などの従来の本人確認書類も使えるため、おすすめです。 これで日程を決めれば受験ができる環境ができたので、勉強を進めて目処が立った時に申し込みます。 AWSアカウントの作成 こちらの内容については別の記事で執筆済のため、不明の方はこちらをご覧ください 書籍による学習 合格対策 AWS認定ソリューションアーキテクト アソシエイト

初心者が実務でEC2へのデプロイをDeployerからGitHub Actionsに移行した時の手順まとめ的なメモです。 背景と目的 今回対象のプロジェクトはDeployerを使用して本番環境およびテスト環境にdeployを実行している。 この場合、デプロイを行う人がローカルでコマンドを手動で実行することになる。 これをGitHub Actionsを導入して「main(stag)ブランチが更新されたら自動でdeployされる」という状態に持っていく。 やること 踏み台サーバー経由でAWS EC2に接続できるようにする GitHub Actionsの自動デプロイの設定を行う Apacheのドキュメントルートの設定を行う SSL/TSLの自動更新設定を確認する 具体的な手順 AWSにIAMユーザーとしてログイン まずはAWSのマネジメントコンソールにログインするところから。 アカウントID(の入ったURL)とユーザー名とパスワードを管理者に共有してもらい、ログインする。 ログインしたら自分でパスワードの変更を行うこと。 右上のナビゲーションバーでユーザー名を選択して[セキュリティ資格情報]を選択すれば変更できる。 1. セキュリティグループの設定 セキュリティグループのインバウンドルールを変更する。これは今回のデプロイの設定とは関係ないが、もともと踏み台サーバーのIPアドレスの登録設定が最適になかったことによる作業である。 EC2のダッシュボードから[セキュリティグループ]を選択し、対象のグループ名を選択する。 次にインバウンドルールのタブから[インバウンドルールを編集]→[ルールを追加]の順に選択して、SSHのインバウンドルールを設定する。(踏み台サーバーのIPアドレスと名称) 2. IAMユーザーの作成 GitHub Actionsに割り当てるアタッチポリシーを割り当てる。 IAM→ユーザー→ユーザーを追加の順に選択していき.. 「物件名-github-actions-deploy」のような名前のIAMユーザーを作成してアクセス権限を割り当てる。 今回割り当てるアクセス権限のポリシー AmazonVPCFullAccess AmazonEC2ContainerServiceRole 以下のような感じで設定できればOK。 3. 自分のマシンからSSH接続確認 踏み台サーバーの設定 踏み台サーバーのプロキシの設定をする。 $ cd /.ssh $ vi config でconfigファイルにプロキシの設定を追加。追加する設定内容は管理者確認する。 .ssh/config ### xxx(プロジェクト名) ######################################## Host <テスト環境のHost名> HostName <サーバーのIP> User <ユーザー名> Port 22 IdentityFile ~/.ssh/<ローカルで作成した秘密鍵のファイル名> ProxyCommand ssh -W %h:%p -p <プロキシのパスワード> <プロキシの名前> Host <本番環境のHost名> HostName <サーバーのIP> User <ユーザー名> Port 22 IdentityFile ~/.ssh/<ローカルで作成した秘密鍵のファイル名> ProxyCommand ssh -W %h:%p -p <プロキシのパスワード> <プロキシの名前> ##################################################### 鍵を作成して公開鍵を管理者に共有する 自分のマシンでキーペアを作成する。 $ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/Users/username/.ssh/id_rsa): /Users/username/.ssh/xxx-develop 作成したら、 $ vi xxx-develop.pub で公開鍵を開いてコピーし、管理者に登録してもらう。 登録されれば$ ssh Host名でssh接続できるようになる。 __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| なお上記はテスト環境での作業なので本番環境も同様に行っていく。 その際は⌘+Dで左右にターミナルを分割して作業すると良い。 4. そのままsshでEC2のクレデンシャルセット SSHで接続した状態で、$ aws configureを実行し、クレデンシャルをセットする。 $ aws configure AWS Access Key ID [None]: アクセスキーを貼り付け AWS Secret Access Key [None]: シークレットアクセスキーを貼り付け Default region name [None]: リージョン名(ap-northeast-1とか) Default output format [None]:特になし(入力不要) これで与えられた権限にて作業ができるようになる。 5. GitHubリポジトリに設定する ①作業する前にイメージ(AMI)を作成する 現在の状態のインスタンスのバックアップとして、AMIを作成する。 (これは先にやっても良い) インスタンス→アクション→イメージを作成の順に選択。 イメージ名は今回は「プロジェクト名ボリュームのサイズ日付(20210401等)」の命名規則とする。 イメージの説明はイメージ名と同じものを貼り付けでOK。 イメージ作成時にダウンタイム(インスタンスが停止)が通常1〜2分程度発生するので留意。 本番環境でボリュームが大きいインスタンスを扱う時は、上長に確認すること。 ②サーバで鍵を作成する 今回は~/.ssh/github/id_rsa.pubという鍵がもともとあったが、 無い場合は$ ssh-keygen -t rsaでキーペアを作成する。 ③作った公開鍵をサーバの authorized_keysに追記 $ vi authorized_keys ~/.ssh/authorized_keyを開いて、サーバーの公開鍵id_rsa.pubの中身を追記する。 すでに別案件等の記述がある場合はその下に追記する。 ④作った公開鍵をGitHubリポジトリに設定 setting → DeployKeys → Add deploy key で公開鍵を設定する。 もしリポジトリに対する権限がなくて作業出来ない場合は、管理者に情報を送って設定してもらう。 TitleはわかりやすいものでOK。 ⑤SSH接続テスト サーバーでSSH接続できるかテスト。 $ ssh -T git@github.com Hi 〇〇! You've successfully authenticated, but GitHub does not provide shell access. こんな感じになれば接続成功。 ⑥GitHubリポジトリにActions secretsを設定 リポジトリのSettingsタブのSecretsを選択。ここのNameとValueを登録する。 下記の左側をNameに、右側をValueにひとつずつ設定していく。 ・設定するNameとValue 共通の設定 USER_NAME：ユーザー名 develop環境の設定 DEVELOP_ACCESS_KEY：作ったIAMのアクセスキー DEVELOP_SECRET_ACCESS_KEY：作ったIAMのシークレットキー DEVELOP_HOST_NAME：サーバIP DEVELOP_SECURITY_GROUP：セキュリティグループID DEVELOP_PRIVATE_KEY：サーバの秘密鍵(.pubじゃない方) production環境の設定 PRODUCTION_ACCESS_KEY：作ったIAMのアクセスキー PRODUCTION_SECRET_ACCESS_KEY：作ったIAMのシークレットキー PRODUCTION_HOST_NAME：サーバIP PRODUCTION_SECURITY_GROUP：セキュリティグループID PRODUCTION_PRIVATE_KEY：サーバの秘密鍵(.pubじゃない方) 上記はそのまま続けて入力すればOK。 この時、改行や空白の違いで動かなくなり、どれが間違っているかもわからなくなるので慎重に作業すること。 サーバーの秘密鍵は-----BEGIN RSA PRIVATE KEY-----や-----END RSA PRIVATE KEY-----も含めてコピーして貼り付けることを忘れずに。(-の数が合ってるかも確認すると良い) ・Actions Secretsの完成イメージ 6. EC2に新しいドキュメントルート作成 現状のEC2のサーバー内の構成を確認し、projdirというディレクトリを新規で追加する。 これからの作業は、そこにGitHubからpullしたドキュメントが入るように設定していくというもの。 /home/ユーザー名の状態を確認 $ cd /home/ユーザー名/ $ ls -la lrwxrwxrwx 1 ユーザー名 ユーザー名 18 x月 xx xxxx public_html -> deploy/pro/current 現状はpublic_htmlに対するdeploy/pro/currentというシンボリックリンクがある。 (deployerで自動デプロイを設定している) ここで、projdirというディレクトリを新規で作成する。 $ mkdir projdir 7. ローカルで階層を変える(番外) これは今回のGitHub Actionsとは関係ない工程だが、dockerをリポジトリに含めていなかったため、ローカル環境でもprojdirを作成して配下にアプリケーションデータたちを置き、dockerディレクトリとdocker-compose.ymlファイルもgitに含めるように変更する。 ディレクトリの構成を変えるときにgitの追跡が失われないように留意すること。 (必要に応じて再度$ git cloneした方が良いかも..) Xdebugの設定変更(番外) なおこれも今回のdeployとは関係ないが、このときDockerfileのXdebugの設定に以下を追加した。(もともとはコメントアウトで別の値が入っていた) Dockerfileに追記 zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20180731/xdebug.so 8. GitHub Actions Workflowの設定 & deployテスト Workflowファイルを作成してプロジェクトと同じディレクトリに入れる。(今回は管理者から共有) 内容としてはmain(stag)ブランチが更新されると自動的にjobsが走るというもの。 deploy_develop.ymlの雰囲気(の一部) name: StagingDeploy on: push: branches: [stag] env: ENV_FILE: .env.dev RSYNC_SOURCE: /projdir/ RSYNC_TARGET: /home/ユーザー名/〇〇/develop/public_html jobs: deploy_staging: if: github.ref == 'refs/heads/stag' runs-on: ubuntu-latest steps: .. ~後略~ 実行されてdeployが完了した時の図 完了すると、先ほどサーバーで作成したprojディレクトリにドキュメントが入っているのが確認できる。 9. virtualhostのconfファイルの編集 バックアップ作成 まずはディレクトリに移動して既存のdefault_vhost.confファイルのバックアップを作成する。 $ cd /etc/httpd/conf.d/extra $ sudo cp default_vhost.conf default_vhost.conf.bk0401 ドキュメントルート変更 viエディタで編集する。 $ sudo vi default_vhost.conf DocumentRoot /home/ユーザー名/public_html/public ←これを DocumentRoot /home/ユーザー名/public_html ←これに修正する <Directory>の部分も同様に修正する。 構文テスト default_vhost.confを修正したら、Apacheの構文のテストを行う。 $ httpd -t AH00526: Syntax error on line 32 of /etc/httpd/conf.d/extra/default_vhost.conf: SSLCertificateFile: file '/etc/letsencrypt/live/ドメイン名/fullchain.pem' does not exist or is empty 構文エラーとなるので確認。 $ cd /etc/letsencrypt/live/ -bash: cd: /etc/letsencrypt/live/: Permission denied liveディレクトリのパーミッションが原因で構文エラーとなっているので、 パーミッションの設定を変更する。 $ cd /etc/letsencrypt $ sudo chmod 755 archive/ $ sudo chmod 755 live/ この状態で再度テストして、OKなら再起動。 $ httpd -t Syntax OK $ sudo systemctl reload httpd なおテスト環境では次のシンボリック設定を先に行っても良いが、本番環境では今回のように 構文テスト→NG→パーミッション変更→confファイル変更→シンボリック設定 の順序としないとダウンタイム(アクセスできない状態)が発生することになるので留意。 10. ドキュメントルートにシンボリックリンク貼る /home/ユーザー名に移動し、ドキュメントディレクトリ名をpublic_htmlからpublic_html_bkにリネーム。 $ cd /home/ユーザー名 $ sudo mv public_html public_html_bk 再度public_htmlという名前で/home/ユーザー名/projdir/publicに対するシンボリックリンクを新たに作成する。 $ ln -s /home/ユーザー名/projdir/public /home/ユーザー名/public_html $ ln -sコマンドは、第一引数が本体(リンクの参照先)で、第二引数が作成するリンクである。 結果として以下のように変更される。 変更前 drwxrwsr-x 3 ユーザー名 ユーザー名 17 xxx deploy drwxrwxr-x 2 ユーザー名 ユーザー名 4096 xxx logs drwxrwsr-x 13 ユーザー名 ユーザー名 4096 xxx projdir lrwxrwxrwx 1 ユーザー名 ユーザー名 18 xxx public_html -> deploy/pro/current 変更後 drwxrwsr-x 3 ユーザー名 ユーザー名 17 xxx deploy drwxrwxr-x 2 ユーザー名 ユーザー名 4096 xxx logs drwxrwsr-x 13 ユーザー名 ユーザー名 4096 xxx projdir lrwxrwxrwx 1 ユーザー名 ユーザー名 29 xxx public_html -> /home/ユーザー名/projdir/public lrwxrwxrwx 1 ユーザー名 ユーザー名 18 xxx public_html_bk -> deploy/pro/current 11. SSL/TSL自動更新の確認 今回はコマンドラインからの手動更新ではなくCertbotとCronを使った自動更新を設定しており、 ドキュメントルートを変更したため設定の確認を行っていく。 CertbotはLet’s EncryptからSSL/TSL証明書を発行や更新の申請をするための無料ツールである。 ①Certbotコマンドのパスを確認 $ which certbot (なければcertbot-auto) /usr/bin/certbot ②dry-run(テスト)を実行する コマンドの場所が分かったのでrenewコマンド(証明書更新)をテストする。 $ sudo /usr/bin/certbot renew --dry-run --post-hook "systemctl restart httpd" --dry-runオプションはファイルに影響を及ぼさずにテスト実行をするオプション。 また--post-hookは更新実行後に行われる処理を記述できるオプションである。（--deploy-hookでも良いかも） コマンドを実行すると、 .. Challenge failed for domain ドメイン名 .. To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. となる。ドメイン名やDNSのAレコード、IPアドレスが正しいか確認してくださいとのこと。 ③ドメインのconfファイルを編集する これは今回ドキュメントルートを変更したことによるためで、 /letsencript/renewalディレクトリにあるドメインのconfファイルを編集していく。 $ sudo vi  /etc/letsencrypt/renewal/ドメイン名.conf webroot_path = /home/ユーザー名/public_html, ←ここと [[webroot_map]] ドメイン名 = /home/ユーザー名/public_html ←ここを、正しいドキュメントルートに修正 ④再度dry-runを実行する $ sudo /usr/bin/certbot renew --dry-run --post-hook "systemctl restart httpd" 今度は無事に成功。 Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/ドメイン名/fullchain.pem (success) ⑤Cronの状態を確認 $ sudo systemctl status crond これで、 Active: active (running) となっていればOK。 以上で作業完了です。お疲れさまでした〜

(Amazon Linux 2 より前の) Amazon Linux AMI プラットフォームで、Elastic Beanstalk のマルチDocker 環境をECSを使って構築する。 BuildしたDockerイメージをECRにプッシュした際に、以下のようなエラーが発生。 ECS Application sourcebundle validation error: We expected a VALUE token but got: START_OBJECT 結論から言うと、Dockerrun.aws.jsonのcommandプロパティが配列である必要があるが、Stringになっていた。 以下を参照のこと。 Weaponizing Haskell - Part Two: Deployment ~ Bows and Arrows 抜粋 One of the main issues I had was that my command property for one of my services was a string, but it should have been an array. Docker-Compose allows this, but Dockerrun doesn’t. I ended up reading the ECS Task-Definition Parameters manual with much more scrutiny and realized my mistake. Part of why it took me so long to do so was because of the misleading error message.

AWSとは Amazon Web Services（AWS）は、インフラストラクチャから機械学習まで、200以上のユニバーサル機能を備えたリソースを提供する最大のクラウドコンピューティングプラットフォームです。 これらの組み合わせ可能なシステムは、最大限の使いやすさを提供し、コンテンツ配信機能やデータストレージなどを通じてアプリケーションのパフォーマンスを最適化するために特別に設計されています。 AWSを使用すると、必要な支援の正確な量に対してのみ支払うため、生産性を損なうことなく、資本コミットメントが低くなり、価値実現までの時間が短縮されます。 AWSのメリット •AWSを使用すると、組織はすでに使い慣れたプログラミングモデル、オペレーティングシステム、データベース、およびアーキテクチャを使用できます。 •これは費用対効果の高いサービスであり、事前または長期の契約なしに、使用した分だけ支払うことができます。 •データセンターの運営と維持にお金をかける必要はありません。 •迅速な展開を提供します •容量を簡単に追加または削除できます。 •無制限の容量でクラウドアクセスを迅速に許可されます。 •総所有コストは、プライベート/専用サーバーと比較して非常に低くなっています。 •一元化された請求と管理を提供します •ハイブリッド機能を提供します •数回クリックするだけで、世界中の複数の地域にアプリケーションをデプロイできます AWSのデメリット •より迅速または集中的な支援が必要な場合は、有料のサポートパッケージを選択する必要があります。 •アマゾンウェブサービスでは、クラウドに移行するときに、いくつかの一般的なクラウドコンピューティングの問題が発生する可能性があります。たとえば、ダウンタイム、制限された制御、バックアップ保護などです。 •AWSは、リージョンごとに異なるリソースにデフォルトの制限を設定します。これらのリソースは、イメージ、ボリューム、およびスナップショットで構成されています。 •ハードウェアレベルの変更がアプリケーションに発生し、アプリケーションの最高のパフォーマンスと使用法を提供しない場合があります。 AWSのベストプラクティス •失敗に備えて設計する必要がありますが、失敗するものはありません。 •AWSサービスを使用する前に、すべてのコンポーネントを分離することが重要です。 •動的データを計算に近づけ、静的データをユーザーに近づける必要があります。 •セキュリティとパフォーマンスのトレードオフを知ることは重要です。 •時間単位の支払い方法でコンピューティング容量を支払います。 •予約するインスタンスごとに1回限りの支払いを行う習慣をつけ、時間料金の大幅な割引を受けます。

はじめに とある案件で新規にAWSアカウントを作成し、それなりに環境構築を完了。 アプリケーション側の開発がある程度進んだところで、検証環境は土日夜間は誰も触らないから自動起動/停止を実装して欲しいとリクエストされました。 とりあえずググった 以前別案件でも同じ仕組みを導入したことがあったので、まぁ同じようにやればいいか…と調べてみると最近は主流のやり方が異なる模様。以前はLambdaでEC2を制御するコードを書いて、Lambdaの呼び出しをCloudWatchからコントロールしてましたが、現在はSystems Managerと連携してEC2を制御するほうがシンプルで簡単らしいです。 実装方法を読むとインスタンスid直指定であればCloudWatchイベントだけで出来るようですが、今後を考えると出来ればタグで制御したい。皆同じことを考えるはず…と調べたらあっさり見つかりました。 タグを指定するだけでEC2インスタンスを自動起動・停止する 今回の実装は主にこちらの記事を参考にさせていただいています。 ちょっといじった 参考にした記事では起動/停止の時間をValueに個別に設定してインスタンス単位で制御するようになっていましたが、自分の要件だと環境単位で起動/停止の時間はどのインスタンスも同じなので、特定タグ「State-Schdule-Stag:enable」があればStop/Startどちらも動くようにちょっとだけ修正します。 停止 description: 'StopEC2Instances Using Tags:state-scheduler-stag' schemaVersion: '0.3' assumeRole: '{{ AutomationAssumeRole }}' parameters: StopStart: type: String default: enable description: (Required) enable allowedValues: - enable AutomationAssumeRole: type: String description: (Optional) The ARN of the role that allows Automation to perform the actions on your behalf. default: '' mainSteps: - name: StopEC2Instances action: 'aws:executeAwsApi' inputs: Service: ssm Api: StartAutomationExecution DocumentName: AWS-StopEC2Instance TargetParameterName: InstanceId Targets: - Key: 'tag:state-scheduler-stag' Values: - '{{ StopStart }}' 起動 description: 'StartEC2Instances Using Tags:state-scheduler-stag' schemaVersion: '0.3' assumeRole: '{{ AutomationAssumeRole }}' parameters: StopStart: type: String default: enable description: (Required) enable allowedValues: - enable AutomationAssumeRole: type: String description: (Optional) The ARN of the role that allows Automation to perform the actions on your behalf. default: '' mainSteps: - name: StartEC2Instances action: 'aws:executeAwsApi' inputs: Service: ssm Api: StartAutomationExecution DocumentName: AWS-StartEC2Instance TargetParameterName: InstanceId Targets: - Key: 'tag:state-scheduler-stag' Values: - '{{ StopStart }}' 実装した ssmドキュメントの投入や手動実行での動作確認は、先ほどの参考リンクの手順を元に実装します。CloudWatchイベントからの呼び出しには別途実行Roleの割り当てやcron式の記述が必要ですが、それらは以下の記事が分かりやすいです。なお末尾でも触れられていますが、cronで曜日指定する場合「日フィールドと曜日フィールドを同時に指定することはできない」ので注意です。 [AWS] CloudWatchでEC2の自動起動・停止をスケジュールする スケジュール登録すると動かない… これで問題ないはず！と終わったつもりでいましたが、翌日になって状況確認するとstop/startどちらも動いていません… 手動では動いていたのに何故？とSystems Manager > 自動化(オートメーション) のところにある実行履歴を確認すると、見慣れぬエラーが発生しています。 どうやらCloudWatchイベントに割り当てたロールに 「tag:GetResource」の権限がない と言われているようです。 tag:getresourceの権限を実行roleに追加 そもそもtag:getresourceって何？とググってみると、公式のドキュメントが出てきます。 リソースグループを使用するための前提条件 ドキュメントを斜め読みすると「SSMからタグ情報を取得する時はリソースグループおよびタグエディタオペレーションを呼び出すので、実行ロールにtag:getresourceの権限が必要」という意味？のようです。割り当てたSSMロールにアタッチした「AmazonSSMAutomationRole」ポリシーに「ec2:DescribeTags」があるのになんで？と思っていましたが、タグを読むために使われるところが違う？という事でしょうか。 とりあえずIAMから「tag:getresource」が含まれているポリシーを検索すると「ResourceGroupsandTagEditorReadOnlyAccess」がちょうど良さそうです（「AWSResourceGroupsReadOnlyAccess」でもいけそうでしたが、なるべく付与する権限は少なくしておいた方が安全でしょう）このポリシーをCloudWatchイベントを実行するロールにアタッチします。 無事動いた 設定変更後翌日になって動作を確認すると、無事に自動起動/停止が動いているのを確認できました。これで一件落着です。 最後に 呼び出す時刻の制御はCloudWatchイベント側でやるので、SSMドキュメント内でtagのvalueを判定してstopなら停止/startなら開始のapiを呼ぶ…ように改良できれば、登録するドキュメントも一つで完結してスマートかなと思います。 あとタグエディタとか今更ながら存在を知ったんですが、これはかなり便利ですね。マネジメントコンソールからの操作だと都度「更新」しないとEC2で変更したタグ情報が確認できずに不便を感じてたのですが、タグエディタ側から操作した方がレスポンス早くて効率も良さそうです。

参考・注意 この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com (注意)このハンズオンでは料金が12~13円/時間発生します。 内容 ELBの配下にAutoScalingグループを紐付けて、EC2インスタンスを希望2、最小2、最大4の範囲でスケーリングさせる。 AutoScaling全体のCPU使用率を監視するアラームを2つ作成。1つめをCPU使用率70%以上,2つめをCPU使用率を30%以下のアラームです。 アラームとAutoScalingポリシーを紐付けます。 目的 一時的にEC2に負荷をかけてEC2インスタンスが自動的に増減される動きを確認します。 AutoScalingの設定 EC2<AutoScaling<AutoScalingグループを選択、 グループを作成 ステップ１ 名前を入力(=Test-AutoScaling1) 起動テンプレート(=以前の講座で作成した物を選択)を設定 バージョンをLatestを選択(最新のもの) 次へ ステップ２ EC2インスタンスを起動する際の購入オプション(通常のオンデマンド)で設定 ネットワーク EC2インスタンスをどのVPCサブネットで起動するか(2つ選択) ステップ３ 詳細オプション ロードバランシングの有効化を選択 Application Load Balancerのターゲットグループを選択(TG1) ヘルスチェック EC2のステータスチェック、インスタンスを立ち上げた際2/2のチェックが合格したかというチェックのみ ELBにチェックを入れる(ELBのHTTP80番ポートのヘルスチェックを追加) その他の設定 モニタリング 後から変更できるので一旦空白で可 ステップ4 グループサイズ 希望容量2 最小キャパシティ2 最大キャパシティ4に設定 スケーリングポリシー CloudWatchアラームと後から紐づけるので一旦なしに設定 インスタンスのスケールイン保護 CPU使用率が低下した際EC2が削除される一般の動きを、削除しないように設定できるチェックボックス(=有効にしない) 次へ ステップ５ 通知の設定もできる ステップ６ AutoScalingにタグを追加できる 今回はなし ステップ７ 確認と作成 作成完了するとEC2インスタンスを確認した際既に今回作成したEC2インスタンスが2つ起動されています。 AutoScaling 動作テスト 　AutoScalingグループを作成した際に起動したEC2インスタンスを試しに終了してみて稼働しているインスタンスを1つに減らしてみます。 　すると、AutoScalingグループのアクティビティ<アクティビティ履歴にELBのヘルスチェックに失敗した履歴が表示されます。 　その後、設定した希望する容量と実際のキャパシティに差があるとAutoScalingが検知し、EC2インスタンスが起動したと表示されます。 結果 → インスタンスの一覧を見ると新しくEC2インスタンスが立ち上がっていることを確認できます。 CloudWatchでアラームを設定 　先ほど作成した、AutoScalingグループに紐づいている２台のEC2インスタンスの使用状況(平均のCPU使用率)によって ↓ ・CPU使用率が70%以上ならEC2インスタンスを1台追加 ・CPU使用率が30%以下ならEC2インスタンスを1台削除 このアラームをCloudWatchで設定 CloudWatch<アラーム<アラームの作成 ステップ1 メトリクスと条件の指定 メトリクスの選択ではどのグラフを選択するかという意味で AutoScaling機能はEC2<AutoScalingグループ別を選択 AutoScalingグループ名(Test-AutoScaling1)のメトリクス名(CPUUtilization)をチェックし、メトリクスの選択をクリック 統計→ 平均値 期間→ 5分 ※条件※ しきい値の種類→ 静的 CPUUtilization(CPU使用率)が次の時では 70 より大きい 時発動するといった設定ができます。 その他の設定で欠落データの処理 CPU使用率が極端に高まると、EC2インスタンスがメトリクスをCloudWatchに送れない事態が予想されるので 欠落データを不正(しきい値を越えている)として処理を選択して 次へをクリック ステップ2 アクションの設定 通知 アラームが発生した際の通知先にSNSを指定する 次へをクリック ステップ3 名前と説明を追加 アラーム名(=CPU_High) 次へをクリック ステップ4 プレビューと作成 アラームの作成をクリックすると作成される 同じようにCPU使用率が30%よりも低い条件、欠落データを見つかりませんとして処理を選択、アラーム名(CPU_Low)として作成 しばらくするとCPU_HighがOK、CPU_Lowがアラーム状態と表示されることを確認してください。 スケーリングポリシーにCloudWatchのアラームを紐付ける EC2<AutoScalingグループ<名前がTest-AutoScaling1を選択<自動スケーリングを選択 現在スケーリングポリシーは指定されていませんと表示があると思うのでポリシーを追加をクリックし作成します ポリシータイプ=シンプルなスケーリング スケーリングポリシー名=CPU_add CloudWatchアラーム=CPU_High アクションを実行=追加、1,キャパシティユニット(EC2インスタンスのこと) 発動後に何秒間待機できるか指定できる(=30秒) 作成をクリック 今度はCPU_Lowの条件でポリシー(名前をCPU_remove)を作成 テスト EC2インスタンス<接続<インスタンスに接続<EC2 Instance Connectを使用しブラウザでログイン(SSH接続)する。 負荷をかける # Linuxサーバーの負荷を確認するコマンド top # 今回確認箇所が上部の%Cpu(s): # topコマンドから抜けるには ctrl + c # 負荷をかけるコマンド # (ひたすらyesを出力し続けるコマンドで/dev/nullにリダイレクト(=>>)する(&=バックグラウンドで)) yes >> /dev/null & # 4回ほど負荷をかけるコマンドを実行した後topコマンドで確認するとCPU使用率が高まります。 # 同じようにもう一つのEC2インスタンスに接続し、この負荷をかけるコマンドを数回実行します。 アラーム確認 CloudWatch<メトリクスでメトリクスのグラフを確認 EC2<AutoScalingグループ<グループ名=Test-AutoScaling1,メトリクス名=CPUUtilizationを確認 CPU使用率が高く表示され、CloudWatch<アラームでもCPU_Highがアラーム状態になったのを確認したら,AutoScalingが発動しEC2インスタンスが新しく起動しているのが確認できます。 AutoScalingグループのアクティビティ履歴にログが出ています。 希望する容量が2→ 3に書き変わっているのが確認できます。 更に時間が経つと3→ 4になり、4台目のインスタンスが起動します。 負荷を解除する # 負荷を解除するコマンド # topコマンドで動いているプロセスのIDを確認し,killコマンドで停止できる kill PID # 連番時は{}が使用でき、まとめて削除できる kill {〇〇..××} # もう一つのEC2のyesコマンドも停止させるのを忘れずに 5分経過するとCPU使用率が落ち着いてきます。 CloudWatch<アラーム<CPU_HighのアラートがOKに変更されます。 更に待つとCPU使用率が低くなるのでCPU_Lowがアラーム状態になります。 低くなるとEC2インスタンスがすぐ削除されるわけではなく、AutoScalingグループの希望する容量が4→3、3→2に変更されているが、まだインスタンスは削除されていません。これは、ロードバランサー<ターゲットグループ<グループの詳細の属性に登録解除の遅延が300秒とあります。ターゲットを確認するとステータスがdrainingとなっています。ELBの配下のインスタンスをいきなり引き剥がすと、そこにアクセスしていたエンドユーザーに影響が出るので猶予期間がある状態のことをdrainingといいます。 テスト終了(後始末) このまま稼働しているEC2を削除しても、AutoScalingによって自動的にEC2インスタンスが作られるので、先にAutoScalingを削除しておきます。削除後にEC2インスタンスを削除しましょう。 CloudWatchアラームもアクションから手動削除 スナップショットを撮った上でRDSも削除

目的 Amazon Linux 2 を 個人PCのローカル仮想マシンで実行するときに、 ISOファイルを自作する必要があります。 このISOファイルの作成で困ったので、ドキュメントとして残します。 これを読めば、あなたも今日からローカルAL2！ AWSを使い慣れていてAmazon Linuxをローカルでも使いたいなというときに便利です。 Amazon Linux 2 をオンプレミスで！ これです。 AWSでお世話になっている、Amazon Linux をオンプレミスでも活用してハッピーになりましょう。 モチベーション 最近のCPUだとWSL2ベースのDockerが使えるので、VirtualBoxでAmazonLinuxするよりもハッピーになれます。 そう、Development Environment On Docker On WSL2 On Windows 10 です。 しかし今回は、VirtualBoxで動作検証をしています。 そもそもWindows10ProでWSL2のDockerを使って開発しようと考えていましたが、 古いCPUで仮想化機能が物理レベルで足りなくてできませんでした。 そこで、Development Environment On Docker On AL2 On VirtualBox On Windows 10 をしよう！！と、 「簡単に出来るのならAWSの従量課金を節約しよう」と、そういうわけです。 isoが作れない 上記の公式ガイドで概要は理解できるし、とても丁寧に書かれていて助かります。 ところが、Windowsで作業していると「isoの作成」という壁が立ちはだかるのです。 （※WSL使えばいいじゃん） そもそもisoって？ isoというのは、CD/DVDにデータを書き込むためのイメージファイルです。 拡張子が、isoでもimgでも中身は同じです。 ここまでは良いでしょう。しかし、問題はこの先です。 じゃあ作ってみよう Linux系 ではこうやります。 genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data Unix系ではこうです。 hdiutil makehybrid -o seed.iso -hfs -joliet -iso -default-volume-name cidata seedconfig/ え？Windowsは？ うっせぇわ Windowsにgenisoimage？hdiutil ？mkisofs？そんなもの無いと見せつけてやる！ 最新の流行は当然のIaC コンテナの状態もKibabaでチェック GitでPullしてDockerでRun 最近じゃ当然のツールです はぁ！？うっせぇうっせぇうっせぇわ 一切合切ペンギンな あなたじゃわからないかもね？ という歌詞があるとかないとか。 解決方法 CDRTFEを使います。 このGUIソフトにCUIがあり、mkisofsが含まれます。これを使いましょう。 公式サイトからインストーラーをダウンロードして使うか、 Chocolateyを使ってインストールします。 Chocolateyの場合のインストールコマンドです。 choco install cdrtfe -y インストールが終わると、 C:\Program Files (x86)\cdrtfe\tools\scripts\cmdshell.cmdというバッチファイルがあります。 これをダブルクリックしてWindowsシェルを起動します。このバッチファイルが何をしているかというと、cygwinとmkisofsが使えるように環境変数Pathを一時的に設定してくれています。環境変数は立ち上がったシェルを閉じたら元に戻ります。 立ち上がったシェルでmkisofsコマンドを実行してみます。 mkisofs: Missing pathspec. Usage: mkisofs [options] [-find] file... [find expression] Use mkisofs -help to get a list all of valid options. Use mkisofs -find -help to get a list of all valid -find options. Most important Options: -posix-H Follow sylinks encountered on command line コマンドのヘルプが表示されましたね。 このまま、cdでuser-dataとmeta-dataがあるディレクトリに移動します。 user-dataとmeta-dataの書き方はAWSのドキュメントを参考にしてください。 cd "Path_To_SeedConfigurationDirectory_Include_TextFiles" 先ほどのAWSドキュメントから下記のコマンドをコピーしてきます。 genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data それを先頭のコマンド名を書き換えて使います。 genisoimageとmkisofsはコマンドオプションの互換性があるそうです。ソースが同じなのかもですね。 mkisofs -output seed.iso -volid cidata -joliet -rock user-data meta-data その結果、seed.isoファイルが生成されます。その時のログです。 Total translation table size: 0 Total rockridge attributes bytes: 363 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 10000 183 extents written (0 MB) seed.isoを仮想マシンに入れよう さて、生成したseed.isoを仮想マシンに入れてみてください。 仮想マシンが立ち上がって、下記のようなプロンプトが表示されたら成功です。 amazonlinux login: もしかして、下記のように表示されましたか？ localhost login: localhostの部分がmeta-dataファイルのlocal-hostname: amazonlinux.onpremと対応しています。 ファイルの内容が間違っているか、ファイルが読み込めていないかのどちらかだと思われます。 DNS設定 今回は仮想マシンをブリッジ接続にして、静的IPを設定しました。 DNSも固定IPです。meta-dataファイルにはnetwork-interfacesの設定はありますが、 DNSの設定項目が見つかりません。cloud-init Documentationに書き換え方の詳細がありますが、私では見つかりませんでした。DNSに接続できないとインターネットゲートウェイに行けないのでyumとかできません。詰みです。 同一LAN内のPC例 IPv4 : 192.168.0.1/24 Gateway : 192.168.0.254 DNS1 : 203.0.113.0 DNS2 : 203.0.113.1 仮想マシンの設定 ./meta-data local-hostname: amazonlinux.onprem # eth0 is the default network interface enabled in the image. You can configure # static network settings with an entry like below. network-interfaces: | iface eth0 inet static address 192.168.0.2 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 gateway 192.168.0.254 ./user-data #cloud-config #vim:syntax=yaml users: # A user by the name `ec2-user` is created in the image by default. - default chpasswd: list: | ec2-user:amazonamazonamazonamazonamazonamazonamazonamazonamazonamazonamazonamazon # In the above line, do not add any spaces after 'ec2-user:'. # NOTE: Cloud-init applies network settings on every boot by default. To retain network settings from first boot, add following ‘write_files’ section: write_files: - path: /etc/cloud/cloud.cfg.d/80_disable_network_after_firstboot.cfg content: | # Disable network configuration after first boot network: config: disabled SSH設定 sshdの設定ファイルを編集してみます。 sudo nano -l /etc/ssh/sshd_config 今回は65行目あたりにあったパスワード認証設定を有効化しました。 - PasswordAuthentication no + PasswordAuthentication yes sudo service sshd restart 上記のsshd設定ファイルの編集を省くには、seed.isoを作成するときのmeta-dataに1行追加します。 ssh_pwauth: True 仮想マシンを稼働させているホストから接続してみます。 ssh ec2-user@192.168.0.2 途中でつまづいたところ YAMLの定義ではインデントにタブが無いためエラーになる。 やっぱり止めた いろいろ頑張ったのですが、やめます。ネットワーク設定ができないからです。 stages.py[ERROR]: Unable to render networking. Network config is likely broken: No available network renderers found. Searched through list: ['eni', 'sysconfig', 'netplan'] 更に調査した結果としては、将来のリリースに期待するしかなさそうです。応急処置として手動設定するしかないですね。 というわけで、cloud-initで自動設定するのが難しいことが分かりました。 ただし、cloud-initのドキュメントを読み込めば解決できる可能性も残っています。 とはいえ、当初の目的が「簡単に・節約」だった以上はOUTです。 オンプレAmazonLinux君にはご退場いただきます。 今までありがとうございました。 まとめ WSL2を使おう。Dockerを使おう。k8sを使おう。 Excelsior!

はじめに AWSにはセキュリティを高めるためのサービスが豊富にあります。 それぞれがセキュリティを高める上でどんな役割を担っているのかについて、本記事では簡単に整理していきます。 過去に検証したことのあるサービスについては、[検証記事]のカラムにリンクを貼っております。 どんな人向け： AWSってサービス多くて何がなんだか分からない って人。 AWSを使っている。 セキュリティを高めるために 何を使うか検討中 って人。 Identity ＆ Access Management サービス名 概要 検証記事 AWS Identity & Access Management (IAM) AWS のサービスやリソースへのアクセスを安全に管理する AWS Single Sign-On AWS アカウントへの SSO アクセスを一元管理できる Amazon Cognito ウェブ / モバイルアプリ の 「認証」・「許可」・「ユーザ管理」をサポートする AWS Directory Service AWS のマネージド型 Microsoft Active Directory AWS Resource Access Manager AWS のリソースを任意の AWS アカウントまたは AWS 組織内で簡単かつ安全に共有できる AWS Organizations AWS リソースの増加やスケーリングに合わせて、環境を一元的に管理し統制する 検出 サービス名 概要 検証記事 AWS Security Hub セキュリティアラートを一元的に管理し、セキュリティチェックを自動化する あり Amazon GuardDuty 脅威検出と継続的なモニタリングで AWSアカウント、ワークロード、データを保護する あり Amazon Inspector 脆弱性を診断・自動でセキュリティ評価をする AWS Config AWS リソースの設定を評価、監査、審査する AWS CloudTrail ユーザーアクティビティと API 使用状況を追跡する AWS IoT Device Defender IoT デバイスのセキュリティを管理する インフラストラクチャの保護 サービス名 概要 検証記事 AWS ネットワークファイヤーウォール Amazon VPC に不可欠なネットワーク保護を簡単にデプロイする AWS Shield マネージドでDDoS攻撃に対してアプリケーションを保護する AWS Web Application Firewall (WAF) 一般的な攻撃やボットからアプリケーションや API を保護する あり AWS Firewall Manager 多くのアカウント、アプリケーションにわたって一元的にファイアウォールのルールを設定、管理する データ保護 サービス名 概要 検証記事 Amazon Macie 機械学習とパターンマッチングを使用して 大規模な機密データを検出して保護する AWS Key Management Service (KMS) データの暗号化やデジタル署名に使用するキーを簡単に作成して管理する AWS CloudHSM 暗号鍵の生成、保管、配布から廃棄までを管理し、サイバー攻撃から保護する AWS Certificate Manager パブリックとプライベートの SSL/TLS 証明書を簡単にプロビジョニング、管理、デプロイする AWS Secrets Manager データベース認証情報、API キー、その他機密情報を簡単にローテーション、管理、取得する インシデントへの対応 サービス名 概要 検証記事 Amazon Detective セキュリティデータを分析および視覚化して、不審なアクティビティの根本原因を簡単に調査する あり CloudEndure Disaster Recovery データセンターの障害やサーバーの破損、サイバー攻撃から物理・仮想・クラウドサーバーを保護する コンプライアンス サービス名 概要 検証記事 AWS Artifact AWS のコンプライアンスレポートにオンデマンドでアクセスできる AWS Audit Manager AWS の使用状況を継続的に監査して、リスクとコンプライアンスの評価方法を簡素化する まとめ 今回はAWSのセキュリティサービスの概要を整理してみました。 実際にサービスを触ってみないと分からないところもあるので、今後検証しては随時記事にしていきたいと思います。 参考

RDS for PostgreSQL x.x end-of-life date is approaching AWSより、DBのエンジンバージョンのサポートが終了すると通知がきたためアップデートしようと思います。 もしアップデートを手動で行わない場合は2月16日以降、自動的にアップデートされてしまいます。 ダウンタイムを伴うアップデート このアップデートはダウンタイムを伴うため、自動でアップデートされてしまっては困ります。 具体的には以下の様な危険性があります。 ・DBに不整合が起きる可能性がある ・サイトに突然アクセスできなくなる ・アップデート後、破壊的変更によってアプリケーションの再稼働ができなくなる 手動でアップデートしましょう AWS公式のアップデート手順が用意されているので、この手順通りアップデートしましょう。 Amazon RDS の PostgreSQL DB エンジンのアップグレード

Trend Micro Cloud One - Workload Security Trend Micro Cloud One - Workload Security とは？ https://qiita.com/k-li00n88/items/cd69e4094f465da81dae Workload Security 設定関連 【Trend Micro Cloud One - Workload Security】(Hands-on) 準備: アカウント取得／保護対象サーバ構築 https://qiita.com/k-li00n88/items/1e58bbdce3bdb6429885 【Trend Micro Cloud One - Workload Security】(Hands-on) 設定: Deep Security Agent (DSA) のインストール https://qiita.com/k-li00n88/items/a66c43adf8537904cafe 【Trend Micro Cloud One - Workload Security】(Hands-on) 設定: 不正プログラム対策モジュール https://qiita.com/k-li00n88/items/445f74744c70e2589ee8 Workload Security Hands-on 【Trend Micro Cloud One - Workload Security】(Hands-on) 不正プログラム対策: 外部からウイルスファイルをダウンロード → 隔離ファイルの操作 https://qiita.com/k-li00n88/items/5f3dd40583d129999c34

※ 疑似ウイルスファイル「eicar」をダウンロードします。誤って、本番環境や会社管理端末にダウンロードしないようにご注意ください。 概要 ウイルス対策などの検証に使用されるウイルスファイルである「eicar」をインターネットから保護対象サーバにダウンロードしてみます。実際のウイルス感染を擬似的に体験します。ダウンロード後に下記の内容を確認していきます。 Deep Security Agent（DSA）をインストールしている保護対象サーバはどうなるのか？ Workload Security 管理コンソール（DSM）上ではどう見えるのか？ 事前設定 保護対象サーバに DSA をインストール 参考：https://qiita.com/k-li00n88/items/a66c43adf8537904cafe 不正プログラム対策の設定 1 . 不正プログラム対策を「有効化」に設定 2 . 不正プログラム対策のリアルタイム検索を「Default Real-Time Scan Configuration」を選択 参考：https://qiita.com/k-li00n88/items/445f74744c70e2589ee8 ウイルスファイルのダウンロード 保護対象サーバから下記のコマンドを実行してウイルスファイルである「eicar」をダウンロードします。 [centos@localhost ~]$ wget https://files.trendmicro.com/products/eicar-file/eicar.com これでダウンロードは完了です。 ダウンロード先のディレクトリを確認してみますが、ダウンロードしたファイルが存在しないことを確認できるかと思います。保護対象サーバにインストールしている Deep Security Agent（DSA）により何かしらの処理がされたことが分かります。事象については次項で確認します。 [centos@localhost ~]$ ls Desktop Documents Downloads Music Pictures Public Templates Videos ダウンロードされたウイルスファイルは何処へ？ ウイルスファイル「eicar」をダウンロードしましたが、ダウンロード先でウイルスファイルを確認することが出来ませんでした。 「保護対象サーバにインストールした DSA に削除されてしまったのか？」と思われるかもしれませんが、実際には保護対象サーバに残っています。厳密に言うと、ウイルスが悪さをしないように暗号化されて特定の場所に隔離されています。ファイルの配置先は下記の場所となり、暗号化されたファイル（.qtn）を確認できます。また、ファイルを配置する場所を指定／変更することはできません。 [root@localhost quarantined]# pwd /var/opt/ds_agent/guests/0000-0000-0000/quarantined [root@localhost quarantined]# ls YCxRab.qtn Workload Security 管理コンソール（DSM）で確認 ウイルスファイルは保護対象サーバに暗号化された状態で隔離されていることを確認できました。次は、Workload Security 管理コンソール（DSM）上で下記のことを確認してみたいと思います。 どういうアラートが発生しているのか？ どういう不正プログラム対策イベントが発生しているのか？ 保護対象サーバに隔離されているウイルスファイルを操作（復元／削除／ダウンロード）してみる どういうアラートが発生しているのか？ DSM の上部メニュー「アラート」を選択すると、アラート一覧を確認することができます。 その中から、不正プログラム対策に関するアラート（下図の Default Real-Time Scan Configuration に関するアラート）を確認できると思います。 どういう不正プログラム対策イベントが発生しているのか？ DSM 上部メニュー「イベントとレポート」を選択し、左側メニュー「不正プログラム対策イベント」を選択すると、不正プログラム対策のイベント一覧を確認することができます。（※ 何も表示されない場合は、画面上部にある「期間」を変更してみてください。デフォルトでは「過去 24 時間」になっています）。 その中から、ダウンロードしたウイルスファイルがイベントとして残っていることを確認できると思います。赤枠で囲んだ行をダブルクリックすると、イベントの詳細画面を表示できますが、一覧で確認できる情報とほとんど変わりないです。 保管されているウイルスファイルを操作してみる DSM 上部メニュー「イベントとレポート」を選択し、左側メニュー「不正プログラム対策イベント」>「検出ファイル」を選択すると、不正プログラム対策で検出したファイル一覧を確認することができます。（※ 何も表示されない場合は、画面上部にある「期間」を変更してみてください。デフォルトでは「過去 24 時間」になっています）。その中から、保護対象サーバにダウンロードしたウイルスファイルを確認できると思います。 上図の画面の赤枠で囲んだ行をダブルクリックすると、ファイルの詳細とファイルに関する操作を選択できる下図の画面が表示されます。表示された画面下部に「復元」「ダウンロード」「削除」ボタンが表示されます。下記は各ボタンの説明となります。 復元：暗号化されたウイルスファイルを元の場所に復元します。（※ 今回の場合、再度、DSA に検知され、特定の場所に暗号化されて隔離されます） ダウンロード：暗号化されたウイルスファイルが zip 化され、ダウンロードされます。（※ 復号には Trend Micro が配布している専用ツールが必要です。このツールはダウンロードの操作の途中でダウンロードリンクが表示されるのでそちらをクリックします。また、このツールは Windows でのみ実行可能です。復号に関しては、下記の「おまけ」項目で解説しています。） 削除：暗号化されたウイルスファイルを保護対象サーバから削除します。 （Hands-on では「削除」を実行してください） おまけ Windows 環境で暗号化されたウイルスファイルを復元する Workload Security 管理コンソール（DSM）からダウンロードした暗号化されたウイルスファイルを Trend Micro が配布している専用ツールで復号してみます。用意した環境は下記の通りです。 環境：VMware Fusion + Windows 10（※ ネットワーク隔離 & Microsoft Defender リアルタイム保護を無効化） 　 1 . 暗号化されたウイルスファイル（.zip）と Trend Micro の専用ツール（.zip） を Windows 環境に移動して展開します。 2 . Trend Micro の専用ツール「QDecrypt」を起動します。起動すると、復号するファイルを選択するダイアログが表示されるので、暗号化されたウイルスファイルを選択します。 3 . 復号するファイルの保存場所とファイル名を指定します。「保存」ボタンをクリックすることで、暗号化されたウイルスファイルの復号に成功します。 ※ Microsoft Defender リアルタイム保護を「有効」にしている場合、復号したウイルスファイルが検知され、下記の通知が表示されます。 参考 Q&A | Trend Micro Business Support https://success.trendmicro.com/jp/solution/1114066 https://success.trendmicro.com/jp/solution/1112967 Trend Micro Software Download Center https://downloadcenter.trendmicro.com/index.php?regs=jp&clk=latest&clkval=3694&lang_loc=13&_ga=2.6179962.858878297.1618293844-274660703.1618057428 検出した不正プログラムの確認と復元 | Deep Security https://help.deepsecurity.trendmicro.com/12_0/on-premise/ja-jp/Events-Alerts/events-anti-malware-quarantine.html#restore

※ 下記が不正プログラム対策の全設定項目というわけではありません。設定項目が多いため、少しずつ追記していきます。 ※ DSM のバージョンによっては下記の内容と一致しない場合があります（※ Workload Security の DSM バージョンは公開されていません）。 不正プログラム対策ステータス こちらの設定では、不正プログラム対策機能を「有効化」「無効化」することができます。選択できる値は「継承（オン or オフ）」「オン」「オフ」の 3 種類となります。 継承：保護対象サーバに適用しているポリシーの親ポリシーから継承された設定（オン or オフ）となります。 オン：不正プログラム対策機能を「有効化」します。 オフ：不正プログラム対策機能を「無効化」します。 不正プログラム対策機能を「有効化」したい場合は、「継承（オン）」もしくは「オン」を選択すれば OK です。 ※ 不正プログラム対策を初めて「オン」にした場合、保護対象サーバに不正プログラム対策モジュールがインストールされます。また、「オン」→「オフ」に変更した場合、インストールされた不正プログラム対策モジュールは保護対象サーバからアンインストールされません。保護対象サーバに残ったままとなりますが、不正プログラム対策機能は問題なく「無効化」されます。 不正プログラム検索手段 不正プログラム対策には、検索手段として「リアルタイム」「手動」「予約」の 3 つがあります。 1. リアルタイム検索 不正プログラム対策をリアルタイムに実行します。 保護対象サーバにインストールされた Deep Security Agent（DSA）が、保護対象サーバを継続的に監視しており、ファイルの受信／開封／ダウンロード／コピー／編集などのタイミングで設定されているルールに基づいて処理が実行されます。デフォルトでは下記の 2 つのルールが用意されており、ユーザが新規追加することもできます。 これらの設定は、Workload Security 管理コンソール（DSM）の上部メニュー「ポリシー」を選択し、左側メニュー「その他」>「不正プログラム検索設定」から行います（※ 説明は後述）。 Default Real-Time Scan Configuration デフォルトの設定となります。 Advanced Real-Time Scan Configuration Default Real-Time Scan Configuration の設定に加え、既知の攻撃コードに加えて未知の攻撃コードを検索する、プロセスメモリ内の不正プログラムを検索する、などの設定が有効化されています。 2. 手動検索 ユーザが実行すると不正プログラムの検索が実行されます。 デフォルトでは「Default Manual Scan Configuration」というルールが用意されており、ユーザが新規追加することもできます。 3. 予約検索 指定した日時に不正プログラムの検索が実行されます。 デフォルトでは「Default Scheduled Scan Configuration」というルールが用意されており、ユーザが新規追加することもできます。 参考 不正プログラム対策設定 https://help.deepsecurity.trendmicro.com/10/0/ja-jp/Protection-Modules/Anti-Malware/ui-editor-am.html

構成 こちらの記事は AWS セキュリティサービスを使ってみた シリーズの Part.3 の記事です。 他にも以下のサービスについてまとめております、ぜひご覧ください。 Part.1 AWS WAF Part.2 Amazon GuardDuty Part.3 AWS Detective （本記事） Part.4 AWS Security Hub 【随時更新】 AWS セキュリティ製品一覧： https://qiita.com/omiyu/private/830477c436b4000ae680 Amazon Detective とは Amazon Detective では、潜在的なセキュリティ問題や不審なアクティビティの根本原因を簡単に分析、調査し、すばやく特定できます。Amazon Detective は、AWS リソースからログデータを自動的に収集し、機械学習、統計的分析、グラフ理論を使用して、リンクされたデータセットを構築します。これにより、より迅速かつ効率的なセキュリティ調査を簡単に行えます。 引用元：https://aws.amazon.com/jp/detective/ 以下のタイプの AWS ログからデータを取得します。 Virtual Private Cloud (VPC) Flow Logs AWS CloudTrail Amazon GuardDuty 仕組み ログイン試行、API コール、ネットワークトラフィックなどの時間ベースのイベントを自動的に抽出します。 また、GuardDuty によって検出された結果も取り込みます。 特徴 異種のイベントをグラフモデルに統合 効率的な調査のためのインタラクティブな視覚化 セキュリティに関する調査結果を調べるためのシームレスな統合 事前にデータソースを統合したり、複雑な設定を維持したりする必要のないシンプルなデプロイ 料金 取り込まれたデータ 料金 最初の 1,000 GB/アカウント/リージョン/月 2.70USD/GB 次の 4,000 GB/アカウント/リージョン/月 1.35USD/GB 次の 5,000 GB/アカウント/リージョン/月 0.68USD/GB 10,000 GB 以上/アカウント/リージョン/月 0.34USD/GB 詳細：https://aws.amazon.com/jp/detective/pricing/ 開始方法 ゴール 前提条件 AWS にサインアップする Amazon GuardDuty が少なくとも 48 時間有効になっている アカウントデータボリュームは Detective クォータ内にある GuardDuty CloudWatch 通知の更新頻度は、デフォルトで6 時間です。GuardDuty 管理者アカウントはディテクターの設定を 15 分に変更することをお勧めします。 手順 手順はざっくり以下の通りです。 Amazon Detective の有効化 メンバーアカウントを招待 データの抽出を確認 Amazon Detective でのアクションと使用状況の追跡 1. Amazon Detective の有効化 Amazon Detective コンソールに移動→[開始方法]を選択します。 管理者アカウント向けの推奨事項が表示されます。 Detective 有効の前に、動作グラフ管理のために必要な IAM ポリシー を IAM プリンシパルにアタッチします。 このポリシーでは、Detective ですべての管理者アカウントアクションを実行できます。 IAM ポリシーをコピーします。 IAM ポリシー コンソールに移動 → [ポリシーの作成]を選択します。 [JSON]を選択 → コピーした IAM ポリシーをペースト → [次のステップ: タグ]を選択します。 今回はタグの設定をスキップします。 [次のステップ：確認]を選択します。 ポリシー名を入力して[ポリシーの作成]を選択すると、IAMポリシーが作成されます。 Detective のセットアップのページに戻り、[Amazon Detectiveを有効化]を選択します。 これで Detective が有効化されます。 2. メンバーアカウントを招待 下図のような流れでメンバーアカウントを招待することができます。 [アクション]メニューから[アカウントを招待]を選択します。 招待したい AWS アカウント ID と E メールアドレスを入力します。 招待メールを編集することもできますが、今回は既定のままでいきます。 メンバーアカウント側でも メンバーアカウント用のIAMポリシーを設定する必要があります。 [招待]を選択します。 これで新しいメンバーが招待されました。 招待を受けたアカウントには以下のように通知が来ます。 [other notifications]タブ→[Detective member invitation]を選択します。 招待の詳細情報が表示されます。 招待を承認するには 以下の赤枠内のリンクをクリックします。 [招待を承諾]を選択します。 これで招待は承諾されました。 管理者アカウントでメンバーアカウントの有効化をします。 有効にしたいアカウントのチェックボックスにチェックを入れ、[アカウントの有効化]を選択します。 [有効化]を選択します。 3. データの抽出を確認 Detective を有効にすると、AWS アカウントのデータを動作グラフに取り込み、抽出し始めます。 ナビゲーションペインで[検索]を選択→[タイプを選択]メニューから項目の種類を選択します。 今回は[AWSアカウント]を見てみます。 下図のように、成功した呼び出しと失敗した呼び出しがグラフで確認できます。 下にスクロールしてアクティビティの詳細を確認します。 IPアドレスごとのAPIコールの種類や成功/失敗の数を見ることができます。 4. Amazon Detective でのアクションと使用状況の追跡 Detective アクティビティを追跡しやすくするために、[使用状況] ページには、取り込まれたデータ量と推定コストが表示されます。 管理者アカウントの場合は 動作グラフ全体のデータ量と推定コストが表示され、 メンバーアカウントの場合は 寄与する動作グラフ全体でアカウントのデータ量と予測コストが表示されます。 動作グラフの使用状況とコストのモニタリング (管理者アカウント)：https://docs.aws.amazon.com/ja_jp/detective/latest/adminguide/usage-tracking-admin.html さいごに Amazon Detectiveを使うと、AWS環境のセキュリティ問題を簡単に分析・調査できることが分かりました。 30日間の無料トライアル期間が設けられているのもいいですね。 参考ドキュメント

勉強前イメージ guard duty で見張り役という意味なので、セキュリティの何かを定期的に見るサービス？ 調査 Amazon GuardDuty とは AWSアカウントや環境に対して継続的にセキュリティチェックを行ってくれるサービスで、難しく言うと脅威検出サービスな感じです これを有効にするとCloudTrailやVPCフローログなどのイベントログが自動的に分析されます。 使用方法は有効化するだけで上記を行ってくれます。 メリット 総合的な脅威の特定 検知対象はAWSのネットワーク上のログとアカウントの操作ログ、 分析対象はCloudTrailやVPCフローログなどのイベントログになります。 最新の脅威インテリジェンスから悪意のあるAPIコールなどの検出を行います。 オートメーションによるセキュリティ強化 CloudWatch EventsとLambdaを使うことで 自動で修復させるアクションも実施することが出来ます。 エンタープライズ規模の一元的な管理 AWS Organizationsを使用して複数アカウントまとめて有効化することが出来ます。 組織全体をまとめて集約された調査結果をCloudWatch Eventsから入手できます。 GuardDuty有効化の方法 ホーム > GuardDuty > 今すぐ始める から すぐに有効化できる画面が出てきますので、こちらをクリックすると有効化することが出来ます。 勉強後イメージ 他にもセキュリティの検知を行うサービスいくつかあってごっちゃになってきた気がする。 一度まとめないと。 参考 AWS環境における脅威検知と対応 Amazon GuardDuty 【初心者向け】AWSの脅威検知サービスAmazon GuardDutyのよく分かる解説と情報まとめ

AWSを利用するにあたって AWS(Amazon Web Services)とはAmazonが提供するクラウドサービス(レンタルサーバー)のことをいいます。クラウドサービスはデータをクラウドと呼ばれるインターネット上の保管場所に保管できるサービスのことです。主に、インターネット上でWEBサービスを展開したり、データ管理をしておくなど、災害リスクに備えているケースも最近では見られます。AWSはパブリッククラウドに分類されるクラウドサービスで、個人や企業など不特定なユーザーにサーバーやストレージ、データベース、ソフトウェアといったクラウド環境をインターネットを通じて提供するサービスのことをいいます。①WEBサイト・WEBサービスの構築・運用「EC2(Amazon Elastic Compute Cloud)やAmazon Lightsail」、②災害時のデータバックアップ「AmazonS3(Amazon Simple Storage Service)」、③ビッグデータの蓄積・分析・運用「AmazonEMR(Amazon Elastic MapReduce)」、④基幹・業務システムの構築、⑤統合開発環境(IDE)の構築が目的となります「Amazon Cloud9」。従来の一般的なレンタルサーバーが月額に対し、AWSは１時間単位で料金が発生します。サーバーが大幅な読み込みによりダウンした場合、AWSは一時的に課金しサーバーを増強できたり、サーバーの負荷が高くなってきても自動的にサーバーの容量を増やしたりできます。更にサーバーが壊れてもスナップショットと呼ばれる。保存機能を使って復元したりできます。従来、HTTPリクエストを送った場合→ロードバランサー→WEBサーバー→データベースといったサーバー構成になりますが、AWSの場合は、HTTPリクエスト→ELB(ロードバランサー)→EC2(WEBサーバー)→RDS(データベース)と呼んでいます。ロードバランサーとは、HTTPのリクエストをどのWEBサーバーに割り振りするかを決定するためのものになります。分散させる為にEC2(WEBサーバー)を２台用意したとしましょう。アクセス負荷を分散させるために、EC2(WEBサーバー)の台数を増やして負荷分散することをスケールアウトといいます。サーバーの台数を増やさずにメモリやCPUを増やしてサーバーのグレードを上げることをスケールアップといいます。 料金体系 AWSでは、ELB(ロードバランサー) EC2(WEBサーバー) RDS(データベース)各サービス毎に料金が発生します。 Elastic Load Balancing 料金 「１時間単位で使用した量で課金する金額が変わっていきます。ClassicからApplicationまでグレードによっても料金が違います。」 Amazon EC2 の料金 「LinuxOSやWindowsOSなどのOSを選べるようになっていて、OSを選択したらメモリやCPUなどのスペックを選んで行きます。それぞれのスペック毎に１時間あたりの料金が設定されています」 Amazon RDS の料金 「MySQLやPostgreSQL、ORACLEなど色々なデータベースが選べるようになっています。こちらもサーバーのスペックによって１時間あたりの料金が変わって参ります」 料金を抑えるためにEC2一つだけのシンプルな構成でまずは試してみましょう。そうすることで、サーバーが１台になり、ロードバランサーが不要になります。更にこのEC2サーバーに直接MySQLやPostgreSQLをインストールすることでRDSの料金もカットすることが出来ます。ただ、RDSのサービスを利用したほうが、自動で定期バックアップを取ってくれたりするので、設計や予算で考えましょう。 また上記では、１時間単位での料金設定を説明してきましたが、リザーブドインスタンスといって１年先までを一括払いすることもでき、その場合料金が半分近く割引になるプランや、登録してから１年間無料で使える枠があるものもあります。 AWSへのサインアップ AWSを利用するにはアカウントを作成する必要があり、予めメールアドレス、クレジットカード、電話番号の準備をしましょう。まずは、ブラウザでこちらのAWSサインアップ画面にアクセスして下さい。画面左下の新しいAWSアカウントの作成をクリックしてEメールアドレス、パスワード、AWSアカウント名を入力して続行(ステップ1/5)をクリックしましょう。連絡先情報→請求情報→本人確認(電話にて暗証番号を入力)の順にステップを進んでいきサインアップを完了させます。サインアップ完了ボタンをクリックし、AWSマネジメントコンソールへ進みましょう。上記のサインアップ画面に戻ってくるので、日常的なタスクを実行とあったのでIAMユーザー(Identity and Access Management)を選択してアカウントIDを入力し次へをクリック→セキュリティチェックが入るので6桁の文字を入力し送信。最終的にルートユーザーでサインインをしますが以下の画面になり、無事サインイン完了です。 実際にEC2を起動させてみましょう まずは、契約をしてAWSマネジメントコンソールという管理画面から操作をしていきます。右上の▲からリージョン(どの地域のサーバーを使うか選択すること)を設定します。基本は「東京」を選択しましょう。次に左上のサービスをクリックし、検索窓にEC2と打って選択します。そしてメニューのインスタンス(起動する１台１台のサーバー)を選択し、インスタンスの作成を選択、次にどのOSを使うか選択「centos7系 LinuxOS Amazon Linux 2 AMI」が無料利用枠の対象なのでスタンダードでしょうか。OSを決めたらCPUやメモリなどのスペックを選択します。無料利用枠の対象であるt2.microを選択し確認と作成ボタンを押し確認画面で起動を押します。既存のキーペアか新しいキーペアを作成するか選択されます。キーペアというのはこのあと作成するサーバーへのSSHログインするための鍵になります。既存にした場合、すでに登録済みのSSHの鍵を使うことになるので、新しいキーペアの作成を選択してキーペアのダウンロードを行いましょう。最後にインスタンスの作成を押します。すると、インスタンスは現在作成中ですとでますので、インスタンスの表示というボタンを押してインスタンスの一覧画面に戻りチェックを入れてみましょう。情報が色々と表示されるので、チェックが入った状態でアクションというところを押してみます。インスタンスの状態という所があるので、そこから停止や再起動が行えます。停止を行っている間は料金はかかりません。次にネットワーキングのセキュリティグループ（ポートの開放設定）の変更をクリックし紐付け設定を行います。メニューからセキュリティグループを選択して見てみると、セキュリティグループを作成するボタンがあったり、一覧でセキュリティグループがならんでいたりするのですが、いずれかをクリックしてみると各詳細が見れるようになっていて、インバウンドルール(WEBサーバーとして使えるようにHTTPの80番ポートやHTTPSの443番ポート、SSHにログインできるように２２番ポートが開放されていてサーバーに向かって入ってくるリクエストに対しどのポートを開放するか設定が行われる)やアウトバウンドルール(サーバーから出ていく方のルールを設定)を確認することが出来ます。 EIP(エラスティックIP) エラスティックIPとは、インスタンスは再起動することでIPアドレスが変わります。一般的なWEBサーバーはドメインをIPアドレスに紐付けて使用するので再起動するたびにIPアドレスが変わってしまうのを防ぐため、IPアドレスを固定する機能のことをいいます。メニュー画面からelasticIPを選択しIPアドレスの割り当てというボタンを押し固定IPアドレスの発行を行います。IPアドレスの発行を行ったら一覧画面から対象のIPアドレスにチェックを入れActionsボタンを押します。IPアドレスの開放や関連付けメニューが選択できるので、IPアドレスをどのインスタンスに紐付けるか設定を決めます。 EC2に対してのSSHログイン 私はmacを扱っているので、今回はmacからEC2にSSHログインを行いたいと思います。macでSSHの設定をするときはターミナルより、vi ~/.ssh/configのコマンドで編集を行います。 Host freename User ec2-user Hostname 54.178.1xx.xx Identityfile~/.ssh/awsfolder/awskey.pem まずはHostには好きな名前を付けれます。User名はec2-user(EC2にログインする時のデフォルトのユーザー名)を指定します。Hostnameには発行したelasticIPを指定しましょう。Identityfile(アイデンティティーファイル)は鍵を設定するところなのでダウンロードした、キーペアの鍵を指定します。.sshフォルダの下にawsfolderというフォルダを今回は掘って鍵を置いてみました。ターミナルよりssh freename(ホスト名)を入力すると、EC2サーバーに対してSSHでログインすることができます。 スナップショット スナップショットでのバックアップ取得方法です。左メニューからボリュームを選択し、それぞれのEC2インスタンスに対するボリューム(ハードディスクの一覧)が表示されるので、ハードディスクを選択してアクションボタンでスナップショットの作成を実行させます。メニューのスナップショットにバックアップが作成されるのでサーバーに不具合が生じた場合に元の状態に戻してくれます。バックアップ→アクション→イメージの作成の順に進んで作成し、イメージの作成リクエストを受け取ります。次に左メニューのイメージの中のAMIをクリック、作成したサーバーの作成イメージが並んでいるので、対象のイメージを選択してアクション→起動させます。インスタンスタイプの選択画面になるのでどのタイプのEC2を立ち上げるか選択します。ここからは、新規にEC2インスタンスを作成した手順と一緒です。前にスナップショットを撮った時の状態でEC2インスタンスが立ち上がります。 S3 AWSでよく使われるサービスの一つであるS3はファイルサーバーのことを指します。パソコンの容量が足りなくなった時に外付けハードディスクを使用するのと一緒でインターネットのクラウド上にファイルを保管して置けるのというものです。EC2の場合はサーバー1台のことをインスタンスと呼んでいましたが、S3の場合は、サーバー1台のことをバケット(S3バケット、バケツ)と呼びます。

はじめに ついにControl Towerが東京リージョンにリリースされました。 検証用で使っていたControl Towerを一旦廃止して、東京をホームリージョンとしたControl Towerを再作成してみます。 バージョンは以下の通りで、アカウントを最新版にしていないのは意図的です。 このようにバージョンが異なる場合に廃止措置をしても、正常に廃止されるのか確認します。 また、Log archive, Auditアカウントを閉鎖せずにランディングゾーンを再設定します。 環境・前提 Control Tower Version 2.7 個別のアカウントはVersion 2.6 Control Towerにより作成されたVPCなし Log archive, Auditアカウントは閉鎖しない Log archive, Auditアカウントのメールアドレス、アカウント名の変更 このセクションはControl Towerの再設定時に旧Log archive, Auditアカウントを閉鎖するなら不要です。 Eメールの変更は、Control Tower再設定時のLog archive, AuditアカウントのEメールに、現在のEメールを使用したいからです。 アカウント名の変更は、上記同様Control Tower再設定時のLog archive, Auditアカウントと名前が被ってしまうからです。 エラーになるか分かりませんが、同じOrganizations内に同一のアカウント名のアカウントを作りたくないので変更します。 変更するために、それぞれのアカウントにルートユーザとしてサインインします。 私はパスワードを設定していないので、パスワードをお忘れですか？を押下します。 メールが届きますので、手順に従ってパスワードを設定。 パスワードを設定したら、ルートユーザとしてサインインします。 マネジメントコンソールのナビゲーションバーのアカウント名から、マイアカウントを押下。 アカウント設定の編集を押下します。 名前とEメールを編集から変更し、完了。 Auditのアカウント名はOld Auditにしました。 同様にLog archiveはOld Log archiveにしますが、記事では省略します。 なお、アカウント名、Eメールを変更するとメールが届きます（Eメールは新旧メールアドレス両方で受信）。 Control Towerのコンソールでも、アカウント名とメールアドレスの変更が反映されていることが分かります(メールアドレスは黒塗りしていますが、ちゃんと変更されています。)。 Control Towerの廃止措置 Control TowerのコンソールのLanding zone settingsからDecommision landing zoneを押下します。 以下のことが起きると注意されます。 アカウントがOrganizationsのルートに移動する* Control Towerにより作成されたリソースが削除される。VPCとSSOは削除されない。VPCの削除には追加の手順が必要。 Organizationsはそのまま *こちらの注意書きを見ると、アカウントが現在いるOUからルートOUに移動することを示唆しているように見えますが、実際のところアカウントは現在のOUから移動していませんでした。 同意してDecommision landing zoneを押下。 廃止措置に2時間かかるそうです。 その間はControl Towerのアクションはしないように注意しています。 私の場合は1時間もかからず終了しました。 アカウントが少ないからでしょうか。 廃止措置中エラーは発生しなかったので、Control Towerのバージョンとアカウント自体のバージョンが異なっていても、廃止措置には関係ないことが分かりました。 では、何が残っているか確認してみます。 まずはCloudFormationのStackSetです。 2つのStackSetが残っていましたが、これは私がStackSetをControl Tower管理外で操作したことが原因です。 私は、StackSetを使用してCloudTrailとS3バケットを東京リージョンに追加でデプロイしていました。 スタックインスタンスを確認すると、東京リージョンにデプロイしているものが残っています。 つまり、Control Towerの廃止措置で削除するのは、Control Towerが作成したリソースだけだということが分かりました。 廃止措置実行前の注意書きにあったYou're uninstalling resources that AWS Control Tower installed.は言葉通りでしたね。 これらのスタックインスタンスはControl Tower再設定時に邪魔になるので、削除しておきます。 詳細な手順は記載しませんが、StackSetのIAM実行ロールが廃止措置により削除されているため、再作成しなければなりません。 面倒な作業になりますので、私と同様にStackSetをサポート外のリージョンにデプロイしている方は、廃止措置前に削除をした方がいいでしょう。 こちらが本来のControl Tower廃止措置後のあるべき姿です。 StackSetが全て削除された状態です（VPCを作成されている方は、VPCのStackSetのみ残っている状態だと思います。）。 次にOrganizationsを確認すると、廃止措置前後で変わっているのはガードレールのSCPが削除されていることくらいでした。 OU内のアカウント移動はありません。 今度はService Catalogを確認します。 ドキュメントではProvisioned products以外は削除されているとのことでしたが、そのとおりでした。 ドキュメントではProvisioned productsを終了すると、アカウントがルートOUに移動するとなっているので試してみましたが、エラーになりました。 解決方法が分からないので、終了せずに次に進みます。 この処理はControl Towerの再設定には必要のない処理なので、スルーします。 Old Log archiveとOld Auditアカウントを確認したところ、Control Towerにより作成されたリソースが綺麗に掃除されていました（Old Log archiveのS3除く）。 他のアカウントを確認すると、ドキュメントでは残っていると説明されていたCloudWatchLogs LogGroupのaws-controltower/CloudTrailLogsがありませんでした。 削除されているようです。 Control Tower最新バージョンだったらCFnテンプレートでRetain設定をしているのでしょうか。 Control Tower再設定前の準備 Control Towerの再設定前に、いくつか作業を行います。 それは、以下の4つです。 コアOUとカスタムOUの削除または名前変更 ロール、ポリシーが削除されていることを確認 AWS SSOの削除 CLIの実行 コアOUとカスタムOUの削除または名前変更 今回は、コアOUは名前変更、カスタムOUは削除で対応します。 終了しました。 ロール、ポリシーが削除されていることを確認 以下のロール、ポリシーが削除されていることを確認します。 これらは、ランディングゾーン設定時に作成されるので、残ったままだとおそらくエラーになります。 ロール AWSControlTowerAdmin AWSControlTowerCloudTrailRole AWSControlTowerStackSetRole ポリシー AWSControlTowerAdminPolicy AWSControlTowerCloudTrailRolePolicy AWSControlTowerStackSetRolePolicy 全て残っていたので、全て削除しました。 AWS SSOの削除 Control Towerのホームリージョンを東京にするため、バージニアのAWS SSOを削除します(Control TowerのホームリージョンとAWS SSOのリージョンは合わせなければなりません。)。 Delete AWS SSO configuration押下。 チェック、入力の上削除。 削除できました。 私はSSOでサインインしていたので、削除して少ししたらサインアウトされました。 CLIの実行 最後に、以下のCLIを実行します。 私はIAMユーザにアクセスキーを発行していなかったので、CloudShellから実行しました。 aws organizations disable-aws-service-access --service-principal controltower.amazonaws.com 念の為以下のコマンドでControl Towerが存在しないか確認。 [cloudshell-user@ip-10-0-8-18 ~]$ aws organizations list-aws-service-access-for-organization { "EnabledServicePrincipals": [ { "ServicePrincipal": "config.amazonaws.com", "DateEnabled": "2021-01-14T11:51:03.748000+00:00" }, { "ServicePrincipal": "member.org.stacksets.cloudformation.amazonaws.com", "DateEnabled": "2021-02-18T11:35:22.693000+00:00" }, { "ServicePrincipal": "securityhub.amazonaws.com", "DateEnabled": "2021-01-26T12:13:07.004000+00:00" }, { "ServicePrincipal": "sso.amazonaws.com", "DateEnabled": "2021-01-14T11:32:59.692000+00:00" } ] } 予想外の設定が見つかりました。 ランディングゾーンの設定時はConfigの信頼できるアクセスを有効にできないので、Organizationsコンソールから無効にしておきます。 Control Towerの再設定 ようやくControl Towerの再設定まで来ました。 必ずホームリージョンにしたいリージョンに移動してからランディングゾーンの設定を行います。 今回、ランディングゾーンは東京のみに設定します。 以前はランディングゾーンを設定するリージョンを選べなかったので嬉しい機能です。 Log archiveとAuditアカウントのEメールには、以前と同一のEメールを設定します。 通常であればエラーが発生しますが、旧Log archiveとAuditアカウントのEメールを変更しているので問題ありません。 無事作成が完了しました。 試しにCloudTrailのStackSetを確認すると、きちんと東京リージョンにデプロイされていました。 AWS SSOも東京リージョンに適切に作成されていました。 SSOのユーザポータルに移動する前に、ユーザポータルの招待メールが届いているので招待を受けます。 こちらの方からパスワードを設定できます。 新Log archive, Auditアカウントも適切に作成されています。 既存OUのControl Towerへの登録 いよいよ最後の作業です。 既存アカウントをControl Tower管理下にするために、既存OUをControl Towerに登録します。 残念ながら失敗しました。 失敗すると、原因などを記載したCSVがダウンロードできるようです。 今回は、一部のアカウントの東京リージョンにConfigが設定されていることが原因でした。 原因を取り除いて再度登録すると、成功しました。 登録されたアカウントを確認したところ、適切にランディングゾーンが設定されていました。 また、各アカウントのEメール宛に、AWS SSOのユーザポータルへの招待が届きます。承認すれば、このSSOユーザのパスワード設定画面に移動します。 おわりに Control Towerの廃止措置から再設定までやってみましたが、時間がかかるだけで案外簡単でした。 実務で行うことは少ないと思いますが、するなら事前調整をしっかりする必要がありそうです。 CloudTrailが存在しない間の措置をどうするか、古いログのS3バケットの処遇や、SSOの削除期間のサインイン問題など色々と検討・調整することはありそうです。 Control Towerの廃止から再設定を通じて、Control Towerでエラーを起こしても致命的なミスは発生しないのでは？と思いました。 Control Towerを試したことがない方は、気軽に始めてみてはいかがでしょうか。 この記事が誰かのお役に立てれば幸いです。

はじめに AWS CloudFormationを使ってとある仮想アプライアンスを起動させようとして2つのパターンのエラーが発生してデプロイに失敗したのでその時のメモ。 ※CloudFormationで使ったテンプレートのjsonファイルの書き方に問題があった等、コードの中身に言及した記事ではないです その1(AWS MarketPlaceでの事前準備) エラー画面 CREATE_FAILEDとエラーメッセージが出力されている。エラー内容は以下 In order to use this AWS Marketplace product you need to accept and subscribe. To do so please visit https://aws.amazon.com/marketplace/xxxxxx 原因 どうやらデプロイする前にAWS Marketplaceで使いたいプロダクトをSubscribeしておかないといけなかったようなので エラーメッセージに出力されているmarketplaceのURL(デプロイ対象の仮想アプライアンスのURL)にアクセス。 以下の画面のContinue to Sbscribeと書いてあるオレンジの部分をクリック。 ※今回CloudFormationで貯めそうとした製品は別製品。今回は例としてCiscoMerakiの仮想版(vMX)を選択 Subscribeをクリックしたら次に以下の画面のAccept Termsをクリック。 最終的には以下のようなSubscribe to this softwareというメッセージが出力されて完了。 ここまでの工程を済ませてCloudFormationを実行すると、表示されていたエラーは発生しないようになった。 その2(ElasticIPを割り当てるタイミングでデプロイに失敗) エラー画面 エラー内容は以下 The maximum number of addresses has been reached. (Service: AmazonEC2; Status Code: 400; Error Code: AddressLimitExceeded Request ID:xxxxxx 原因 ElasticIPアドレスの割り当て中にAddressLimitExceededのエラーメッセージが出力されデプロイに失敗したようで この場合は未使用のElasticIPを開放してあげるか制限緩和を申請して解決をする。 自分は未使用のElasticIPを開放した後に、再度CloudFormationを実行してデプロイに成功しました。 参考URL https://aws.amazon.com/jp/premiumsupport/knowledge-center/unlock-move-recover-troubleshoot-eip/ 最後に 今までハンズオントレーニング等でしっかり動くように作られてきたCloudFormationのテンプレートしか使ったことがなく、 自分の環境にテンプレートを合わせていくことを今回初めてやった結果、上記のエラーとどうやったら回避できるのかということを実体験することができた。 まだ大して触れているわけではないですが、ある試験項目をこなしたい場合にテンプレートを読みだして、終わったら削除するというサイクルが組めるので、CloudFormationは使いこなせるととても有意義だと実感しました。

目標 aws のコマンドを、ローカルは散らかさずに使いたい 使うためにはそれ用のパッケージをインストールする必要があるが、それはインストールしたくない 前提 Docker コマンドが使える やり方 $ docker run --rm -it -v ~/.aws:/root/.aws -v (pwd):/aws -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_DEFAULT_REGION amazon/aws-cli usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters] To see help text, you can run: aws help aws <command> help aws <command> <subcommand> help 環境変数を使って認証できるので、 direnv を使うと相性が良い alias aws で呼び出せて、docker を意識せず使えるので便利 bash_profile alias aws "docker run --rm -it -v ~/.aws:/root/.aws -v (pwd):/aws -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_DEFAULT_REGION amazon/aws-cli"

概要 AWSのIAMユーザーでサインインしようとすると、アカウント作成時にランダムで生成された12桁のアカウントIDが求められる。 サインインする際にいちいち覚えていられないので変更などできないか調べたところエイリアスを設定できることがわかった。 そのため、設定方法を記載する。 参考サイト 手順 AWSマネジメントコンソールにサインインする。 [サービス]メニューからIAMサービスをクリックしてIAMダッシュボードを開く。 IAMダッシュボードにあるこのアカウントのIAMユーザーのサインインURL横の[カスタマイズ]を選択する。 以下のようなダイアログが表示されるので、設定したいエイリアスを入力し[エイリアスの作成]をクリックする。 上記の手順を実施することで次からアカウントIDに設定したエイリアスを入力してサインインすることができるようになる。