※本記事はあまりネットワークに詳しくない人向けとなります。 Amazon Direct Connectとは？ AWSはこのDirect ConnectやVPNを使わない場合は、 外部からの接続は、基本的にインターネットでの接続が必要になります。 ただし、会社の業務システムなどをインターネット接続による どこの誰でも(部外者でも)使える状態になるのはマズイ状態ですよね？ そんなときのために、会社とAWSネットワークを相思相愛で接続していて、 関係者以外、誰にも恋路を邪魔されない接続を実現する方法の一つです。 つまり、閉域網でAWSネットワークと接続するためのサービスです。 VPNよりお金はかかりますがその分、 セキュリティ面での強さ、安定性などがあります。 説明のための図を作成しました。 ※以下はファンタジーとなります。 あなたは"恋人のAWSちゃん"と付き合っていることとします。(AWS君でも可) ただ"AWSちゃん"と会おうと外に出ると、人が混雑しているため、時間がかかってしまうこともあります。 また、あなたと"AWSちゃん"との関係も週刊誌に狙われているかもしれません。 他の人には見えない ということで二人は、玄関から外に出ずに会える方法はないか考えました。 二人の家には2階に窓があり、これを撤廃して、他の人には見えない扉を作成し、 二人の家をつなぐ、他の人には見えない長い長い廊下を作成しました。 これをDirect Connectと名付けました。 二人は人混みを避けて、誰にもバレることなく会えるようになりました。 めでたしめでたし。 この図のように、このDirectConnectを利用できるのは家の住人だけなので、セキュリティも高く、 利用者も限られているので、回線の安定性があることが一番の魅力となります。 接続形態の種類 接続形態には、専有型と共有型というのが存在します。 回線1本まるまる借りるのを専有型 回線の1部を借りるのが共有型 となります。 例えるなれば、 マンション1棟の所有者があなたの場合は、専有型 マンション1室の所有者があなたの場合は、共有型となります。 マンション1棟の所有者であれば、空いている部屋を人に貸すことができますが、 マンション1室の所有権しかなければ、そんな好き勝手できない そんなイメージです。 接続できればなんでもいいというのであれば、あまり気にしなくて大丈夫ですし、 どちらかというと共有型を利用している方が多く感じております。 またマネジメントコンソールでの専有型か共有型かを確認する方法は、 接続が存在するかどうかで確認出来ます。 接続が存在している場合は、専有型 接続がなく、仮想インターフェイスが存在する場合は、共有型となります。 AWS側の受け口 DirectConnectの受け口として、AWSでは2つ存在しています。 1つが、VGW(VirtualGateway)です。 もう1つが、DXGW(DirectConnectGateway)です。 違いを簡単に言うと、DXGWを挟むのか挟まないのかの話となります。 受け口がVGWの場合、 DirectConnect　→ VGW になるのに対してDXGWの場合、 DirectConnect →　DXGW　→　VGW となるため、最終的な受け口はVGWになるのは共通となります。 ここはAWSではDXGWの利用が推奨されています。 理由は、拡張性が優れているためです。 例えば、Aというアカウントで利用しているDirectConnectを 他のBというアカウントでも共有して使いたいとなった場合、 DXGWでは可能ですが、VGWでは不可能になってしまいます。 また基本的に受け口の変更は後からできないため、 専有型であれば、ダウンタイムが発生してしまいますが、 一度削除したあと、再作成が自分でできたりしますが、 共有型であれば、自分で設定ができないため、 諦めるかDirectConnectを提供していただいている業者にお願いするかになります。 ※こちらの場合もダウンタイムが発生します。 そのため、受け口の選択は最初しかできないと思っていたほうがよいため、 この辺も考慮して、検討した上での選択をしたほうがよいです。 私も受け口をVGWにして、後から他のアカウントで利用したいと言われて困ってしまった経験があります・・・・ 最後に DirectConnectは、EC2のようにお気楽に個人で利用(契約)できるような代物ではないため、 そういった人たちにも伝えられる情報があれば、今後もアップデートしていきたいと思います。 もっと細かい情報に関しましては、AWSのBlackbeltにて確認していただければと思います。

背景・目的 以前、「VPC内のLambdaからインターネットに接続する」と「DynamoDBを試してみた」で作成したLambdaとDynamoDB（以降、DDBという。）を使用してQiitaの記事一覧を取得し、その内容をDDBに登録する。 内容 前提 DynamoDBテーブル DDBのテーブル名は「qiita_user_articles」、各項目は以下の通りとする。 項目名 キー/インデックス タイプ 例 user_id パーティションキー 文字列 test article_id ソートキー 文字列 00001 title グローバルセカンダリーインデックス 文字列 test title url 文字列 https://qiita.com/Qiita/items/c686397e4a0f4f11683d page_views_count 数値 100 likes_count 数値 100 reactions_count 数値 100 comments_count 数値 100 created_at 文字列 2000-01-01T00:00:00+00:00 updated_at 文字列 2000-01-01T00:00:00+00:00 開発環境の準備 「JupyterLabはじめの一歩」で作成した、Cloud9上のJupyterLabを使用する。 boto3のインストール 早速だが、Cloud9にboto3がインストールされていないようなのでインストールする。（以下は、ModuleNotFoundErrorになっている。） 1.あらためてboto3が入っているか確認。やはり無い。 $ pip freeze | grep boto3 $ 2.boto3をインスール $ pip install boto3 Defaulting to user installation because normal site-packages is not writeable Collecting boto3 Downloading boto3-1.21.32-py3-none-any.whl (132 kB) |████████████████████████████████| 132 kB 24.5 MB/s Collecting s3transfer<0.6.0,>=0.5.0 Downloading s3transfer-0.5.2-py3-none-any.whl (79 kB) |████████████████████████████████| 79 kB 18.1 MB/s Requirement already satisfied: jmespath<2.0.0,>=0.7.1 in /usr/local/lib/python3.7/site-packages (from boto3) (1.0.0) Collecting botocore<1.25.0,>=1.24.32 Downloading botocore-1.24.32-py3-none-any.whl (8.6 MB) |████████████████████████████████| 8.6 MB 57.7 MB/s Requirement already satisfied: python-dateutil<3.0.0,>=2.1 in /usr/local/lib/python3.7/site-packages (from botocore<1.25.0,>=1.24.32->boto3) (2.8.2) Requirement already satisfied: urllib3<1.27,>=1.25.4 in /usr/local/lib/python3.7/site-packages (from botocore<1.25.0,>=1.24.32->boto3) (1.26.9) Requirement already satisfied: six>=1.5 in /usr/local/lib/python3.7/site-packages (from python-dateutil<3.0.0,>=2.1->botocore<1.25.0,>=1.24.32->boto3) (1.16.0) Installing collected packages: botocore, s3transfer, boto3 Successfully installed boto3-1.21.32 botocore-1.24.32 s3transfer-0.5.2 $ 3.インストール後にあらためて確認する。 $ pip freeze | grep boto3 boto3==1.21.32 $ 4.JupyterLabであらためて確認する。 エラーが消えて取得できた。これで環境が整った。 DynamoDB操作のためにポリシーをアタッチ Cloud9が利用しているEC2のIAMロールのポリシーにDynamoDBFullAccessポリシーをアタッチする。 同様に、Lambdaのロールにもアタッチしておく。 AMTCを無効化 AMTCとは、「AWS Managed Temporary Credentials」のこと。詳細はクラスメソッドさんのブログに詳しく書かれている。 Cloud9ではデフォルトで、AMTCが有効化されているのでこれを無効化する。（出典：クラスメソッドさんのブログ。） 1.Cloud9のPreferencesをクリック。 2.AWS Setting＞CredentialsのAWS resource temporary credentialsをdisableに変更。 DynamoDBと疎通 取得できました。 $ aws dynamodb list-tables --region ap-northeast-1 { "TableNames": [ "qiita_user_articles" ] } $ 実践 修正前のコード 修正前のコード import urllib.request import json import boto3 from pprint import pprint # エンドポイント url = 'https://qiita.com/api/v2/items?page=1&per_page=50' # リクエスト req = urllib.request.Request(url) try: with urllib.request.urlopen(req) as res: body = json.load(res) for item in body: print("{0}".format(item['title'])) except urllib.error.HTTPError as e: if e.code >=400: print(e.reason) else: raise e 修正後のコード（Cloud9） import urllib.request import json import boto3 from pprint import pprint def get_table(): dynamodb = boto3.resource("dynamodb") return dynamodb.Table('qiita_user_articles') def put_item(ddb_table,item_json): return ddb_table.put_item(Item=item_json) # エンドポイント url = 'https://qiita.com/api/v2/items?page=1&per_page=10' # リクエスト req = urllib.request.Request(url) try: ddb_table = get_table() with urllib.request.urlopen(req) as res: body = json.load(res) for item in body: print("{0}".format(item['title'])) item_json={ 'user_id': item['user']['id'], 'article_id': item['id'], 'title': item['title'], 'url': item['url'], 'page_views_count': item['page_views_count'], 'likes_count': item['likes_count'], 'reactions_count': item['reactions_count'], 'comments_count': item['comments_count'], 'created_at': item['created_at'], 'updated_at': item['updated_at'] } response = put_item(ddb_table,item_json) pprint(response) except urllib.error.HTTPError as e: if e.code >=400: print(e.reason) else: raise e Lambdaで実行する際には、lambda_handler関数を書く lambda版 import urllib.request import json import boto3 from pprint import pprint def get_table(): dynamodb = boto3.resource("dynamodb") return dynamodb.Table('qiita_user_articles') def put_item(ddb_table,item_json): return ddb_table.put_item(Item=item_json) # エンドポイント url = 'https://qiita.com/api/v2/items?page=1&per_page=10' def lambda_handler(event, context): # リクエスト req = urllib.request.Request(url) try: ddb_table = get_table() with urllib.request.urlopen(req) as res: body = json.load(res) for item in body: print("{0}".format(item['title'])) item_json={ 'user_id': item['user']['id'], 'article_id': item['id'], 'title': item['title'], 'url': item['url'], 'page_views_count': item['page_views_count'], 'likes_count': item['likes_count'], 'reactions_count': item['reactions_count'], 'comments_count': item['comments_count'], 'created_at': item['created_at'], 'updated_at': item['updated_at'] } response = put_item(ddb_table,item_json) pprint(response) except urllib.error.HTTPError as e: if e.code >=400: print(e.reason) else: raise e JypyterLab（Cloud9）実行結果 200で返ってきた。(キャプチャなし) DDBのテーブルを雑に確認したところ、データは入っている。（11件） Lambdaの実行結果 200で返ってきた。(キャプチャなし) DDBのテーブルを雑に確認したところ、データは入っている。（20件） 考察 AMTCを完全に理解できてないので、後日確認する。 参考

laravelを使ってYoutube上にある料理動画を管理するサービスを作成しました。 Youtubeには様々な料理動画が日々アップされていますが、実際に作ってみてよかったものをストックしたり、 少し自分好みにアレンジした時のメモを残したいと思ったので、当サービスを作ってみました。 セキュリティ面など至らない点が多いとは思いますが、興味があれば使ってみていただけると幸いです。 ⇩作成したサービス 自己紹介 PHPを本格的に学習し始めて３ヶ月目の駆け出しエンジニア。前職はインフラ系で現在Webエンジニアになるため転職活動中です。 使用技術 フロントエンド Javascript Jquery Bootstrap バックエンド PHP(Laravel8) YoutubeAPI Mysql インフラ AWS Git 認証機能はLaravelにデフォルトで備わっているlaravel-authを使用しました。 また、AWSはEC2でサーバーをたて、データベースにRDS、ドメインの割り当てにRoute53(ドメインはお名前ドットコムで取得)、メールの送信にAmazonSESを使用しています。 作成期間 2022年2月下旬～2022年3月下旬の約一ヶ月間。 使い方 会員登録画面 ログイン画面 Home画面 ライブラリ 「レシピ本を見る」⇒ 自分のレシピ本を作成する。フォルダ分けしてレシピを保存するイメージ。 「保存したレシピ」⇒ 自分が保存したレシピをすべて表示する。検索可能。ここからもレシピを追加できる。 レシピを探す 「みんなのレシピ」⇒ 他のユーザーが作成したレシピを探す。 「動画から探す」⇒ 他のユーザーが追加したレシピをYoutubeの動画単位で探す。平均評価順など並び替え可能。動画をクリックすると、動画再生ページに遷移し、レシピの追加が可能になる。 Library画面 作成したレシピ本一覧。「+ Create New Recipeboook」でレシピ本を新規作成できる。 Book画面 作成したレシピ本の内容を表示する。右下の「+」ボタンを押すと、、、 レシピ作成用のモーダルが表示される。ここに追加したいYoutube動画のURLを入力し、「動画のタイトルとサムネイルを取得」をクリックすると、、、 Youtubeからタイトルとサムネイルが取得でき、「追加」ボタンをクリックしてレシピを追加できる。 レシピの追加方法は以上。その他のページも基本的にはこれと似たような使い方になる。

背景・目的 先日、Lambdaを定期実行するで作成したLambdaで、Qiitaの記事をデータストアに保存してみる。 データストアには、今まであまり触ってこなかったDynamoDBを使用してみる。 本ページでは、まずはDynamoDBでテーブル作成、簡単なサンプルデータを登録するところまでをスコープとし、Lambdaを利用してのデータ登録等は次回以降に試す。 内容 DynamoDBの概要 DynamoDB（以降、DDBという。）とは フルマネージドNoSQLデータベースサービス 高速、予測可能なパフォーマンスとシームレスにスケールを提供する。 ディストリビューションデータベースの運用とスケーリングに伴う管理作業をまかせることができる。 ハードウェアのプロビジョニング、設定と構成、レプリケーション、ソフトウェアパッチ適用、クラスタースケーリングなどを自分で行う必要はない。 保管時の暗号化を提供し、機密データの保護に伴う複雑な運用の負担を取り除く。 高い可用性と耐久性 一貫性のある高速パフォーマンスを維持しながら、スループットとストレージの要件を処理できるように、テーブルのデータとトラフィックが十分な数のサーバに自動的に分散される。 全てのデータをSSDに保存し、リージョン内の複数AZ間で自動でレプリケートするため、高い可用性とデータ堅牢性が実現する。 グローバルテーブルにより、DDB テーブルをAWSリージョン間で同期可能。 仕組み コアコンポーネント テーブル、項目、属性を指す。 テーブルは項目の集合、各項目は属性の集合。 PKを使用してテーブルの各項目を一意に識別し、セカンダリインデックスを使用してクエリの柔軟性を高める。 プライマリーキー テーブル作成時には、テーブル名とPKを指定する必要がある。 パーティションキー DDBはパーティションキーを内部ハッシュ関数への入力として使用する。ハッシュ関数からの出力により、項目が保存されるパーティションが決まる。 パーティションキーとソートキー 複合プライマリーキー 2つの属性で決まり、1つめがパーティションキー。2つめがソートキー 2つめのソートキーでソートされて保存される。 セカンダリーインデックス 指定することで、プライマリーキー以外の検索に柔軟性が出る。 ２種類ある グローバルセカンダリーインデックス（以降、GSIという。） パーティションキーおよびソートキーを持つインデックス。 テーブルのものとは異なる。 ローカルセカンダリーインデックス（以降、LSIという。） パーティションキーはテーブルのものと同じ。ソートキーが異なるインデックス。 各テーブルには、２０個のGSIと5個のLSIのクォータがある。 DynamoDB Streams DDBテーブルの変更イベントをキャプチャする。 ほぼリアルで、イベントの発生順にストリームに表示される。 テーブルでストリームを有効にすると、DDB Streamsは以下のイベントごとにストリーミングレコードを書き込む 新しい項目がテーブルに追加された場合、全てをキャプチャ 項目が更新された場合、更新された項目の更新前後のキャプチャ 削除された場合、削除前の項目全体のキャプチャ 24Hの有効期限を持つ。 DDB StreamとLambdaで、トリガーを作成できる。 実践 DynamoDBの使用開始を参考に始める。ただし、テーブル名や項目は適宜変更する。 ステップ 1: テーブルを作成する qiita_user_articlesというテーブル名で、以下の項目を作成する。 項目名 キー タイプ user_id パーティションキー 文字列 article_id ソートキー 文字列 1.マネコンのDynamoDBコンソール＞ダッシュボード＞右側のテーブルの作成をクリック。 2.テーブル名と、パーティションキーを予め決めたものを入力し、設定は一旦デフォルトのままでテーブルの作成をクリック。 3.しばらくするとActivateされ、以下のように確認ができる。 ステップ 2: コンソールまたは AWS CLI を使用して、テーブルにデータを書き込む 作成したテーブルにデータを書き込む。 1.テーブルの一覧でテーブル名をクリックする。 2.画面右上の「テーブルアイテムの探索」をクリック。 3.画面右上の「項目の作成」をクリック。 4.「新しい属性の追加」でタイプを選ぶと新しい項目が追加される。 5.以下の様に作成し、「項目を作成」をクリック。 ステップ 3: テーブルからデータを読み込む スキャンとクエリがある。スキャンを実行してみる。 1.フィルタの属性に「user_id」、値に「test」を入力し、「実行する」をクリックすると、以下のように表示される。 2.フィルタの属性に「user_id」、値に「test2」を入力し、「実行する」をクリックすると、以下のように表示される。（結果は返されない。） ステップ 4: テーブルのデータを更新する 更新をしてみる。 1.検索結果のパーティションキーがリンクになっているのでクリックする。 2.titleの値を「updated test title」に変更し「変更を保存」をクリックすると、変更されたことが分かる。 ステップ 5: テーブルのデータをクエリする ステップ3とほぼ同様なので、省略する。 ステップ 6: グローバルセカンダリインデックスを作成する 1.テーブルを選び、「インデックス」タブをクリック後、画面右上の「インデックスの作成」をクリックする。 2.インデックスの詳細でパーティションキー「title」を指定し、その他は変更せずに「インデックスの作成」をクリックする。 キャプチャなし。 3.しばらくするとActiveになる。最大5分くらいかかるらしい。 ステップ 7: グローバルセカンダリインデックスをクエリする 作成したGSIでクエリしてみる。 1.アイテムのスキャン/クエリでテーブルまたはインデックスに先程作成した「title-index」が表示された。 2.title-indexに「updated test title」を指定し「実行する」をクリックする。 3.以下は、title-indexに「deleted test title」を指定し結果が帰らなかった例。 考察 マネコン上で、テーブルの作成から、データ操作まで簡単にできる。 DDBのキャパシティーユニットなどは、今後確認する予定。 参考

[前回] AWS公式資料で挑むSCS認定(25)-こんな時どうする(全分野その2) はじめに 早速、今回も「こんな時どうする」の追記です。 精査はしていますが、過去と似たような項目を取り上げる可能性あります、悪しからず。 分野1: インシデント対応 EC2インスタンスで使用されていないポートが攻撃された、稼働中システムを止めずにすぐ対処したい セキュリティグループのインバウンドルールから問題のポート番号を削除 分野2: ログとモニタリング(監視) S3バケットのアクセスログに「認証失敗」「HTTP Referer情報」を含め記録したい S3サーバーアクセスログを使用し、S3リクエストをログ記録 S3バケットのアクセスログに「IAM/ユーザー特定情報」「クロスアカウントログ」を含め記録したい、かつログファイルを暗号化したい AWS CloudTrailを使用し、S3のAPIコールをログ記録 Amazon GuardDutyによる監視で、特定EC2インスタンスから頻繁に誤検知(false positive)の通知発生するため、監視対象から除外したい 信頼できるIPリストに、問題EC2インスタンスのIPアドレスを追加し、Amazon GuardDutyに適用 ※ 信頼できるIPリストのアップロード数は各リージョンのAWSアカウントにつき1つのみ ※ Amazon GuardDutyとは セキュリティの観点から脅威リスクを検知するマネージドサービス 分析のソースに下記を利用、メタデータの連続ストリームを分析 VPC Flow Logs AWS CloudTrail Event Logs DNS Logs 統合脅威インテリジェンスを使用し脅威を認識 分野3: インフラストラクチャのセキュリティ VPC内複数コンテナ間で相互TLS認証による通信を行いたい ACMプライベートCA(証明機関)を使用し、下位CAを作成 ACM(AWS Certificate Manager)を使ってプライベート証明書を作成、すべてのコンテナに適用する ※ ACMプライベートCAとは、プライベート証明書のライフサイクルを簡単かつ安全に管理するマネージドサービス 自社プライベートCAを先行投資やメンテナンスコストをかけず運用でき、可用性の高いプライベートCAを得られる 分野4: アイデンティティ(ID)及びアクセス管理 AWSアカウントを保護したい AWSアカウントのルートユーザーまたはIAMユーザーに対しMFA(多要素認証)を有効に EC2 Linuxインスタンスにログインしたい キーペアによる認証でログイン キーペアには、プライベートキーとパブリックキーが含まれる パブリックキーは、EC2インスタンス内に保管 プライベートキーは、ユーザー自身が保管 セキュリティ監査の実施タイミングが不明 定期的監査 従業員が退職するなど組織変更があった場合 1つ以上のAWSサービスを使用しなくなった場合(不要になったアクセス許可を削除するため重要) AWSアカウントでソフトウェアの追加/削除があった場合(EC2インスタンスのアプリケーション、AWS OpsWorksスタック、AWS CloudFormationテンプレートなど) 権限のない人がアカウントにアクセスした疑いがある場合 分野5: データ保護 S3バケットのオブジェクトに対し、KMSキーを用いたサーバー側暗号化(SSE-KMS)を強制するポリシーを作成したい ポリシーで下記Statementを定義 { ... ... "Effect": "Deny", "Action": "s3:PutObject", "Condition": { "StringNotEquals":{ "s3:x-amz-server-side-encryption":"aws:kms" } } } S3バケットのオブジェクトに対し、S3バケットキーを用いたサーバー側暗号化(SSE-S3)を強制するポリシーを作成したい ポリシーで下記2つのStatementを定義 { ... ... "Effect": "Deny", "Action": "s3:PutObject", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "AES256" } } }, { ... ... "Effect": "Deny", "Action": "s3:PutObject", "Condition": { "Null": { "s3:x-amz-server-side-encryption": "true" } } } 独自のキーマテリアルをインポートしているKMSキー(カスタマー管理キー)を毎年更新したい 新しいKMSキーを作成し 新しいキーマテリアルをインポート 既存のKMSキーのエイリアスを新しいKMSキーにマッピング ※ KMSキー(カスタマー管理キー)の種類とローテーション カスタマー管理の対称KMSキー キーマテリアルをAWS KMSで生成 1年ごとの自動更新を設定可 キーマテリアルをAWS CloudHSMクラスターで生成(KMSカスタムキーストア機能を使用) 自動更新不可、要手動更新 独自のキーマテリアルをインポート 自動更新不可、要手動更新 カスタマー管理の非対称KMSキー キーマテリアルはAWS KMS HSMでのみ生成可能 自動更新不可 おわりに 「こんな時どうする」の追記でした。 次回も続きます、お楽しみに。 [次回] AWS公式資料で挑むSCS認定(27)-こんな時どうする(全分野その4)

概要 SAP-C01合格したのでその記録です。 僕のレベルとしては掛け値なしの初学者です。 2021年5月末からITの勉強を始めて同年11月頭にSAA認定、2022年の2月からSAPの勉強を始めまして、同年4月頭に合格しました。 勉強中の模試の点数を載せている方は少ないので参考になれば幸いです。 SAA-C02の記録はこちら 結論 AWS業務未経験ではなく、IT自体未経験の真の初心者がやるには相当時間がかかります。 僕の場合は2ヶ月ちょっとかけました、1日3時間(模試の制限時間)かそれ以下で、年度末ということで仕事が忙しく途中やってない日も含んでいます。年度末に納期合わせてくるのはエグすぎる。 ネットのAWS業務未経験の何時間で受かる系はレベルが高すぎて参考になりませんでした。 使用教材 AWS ホワイトペーパー：無料 AWS サービス別資料：無料 AWS認定ソリューションアーキテクト－プロフェッショナル～試験特性から導き出した演習問題と詳細解説～：2970円（書籍版） Udemy模擬試験 AWS Certified Solutions Architect Professional Practice Exam：1840円 公式模試：0円（SAA認定特典） *本試験：16500円（SAA認定特典） 合計21310円 勉強方法 勉強順 参考書解説部分 →Udemy模試4回4度ずつ →公式模試 →参考書模試2度 →AWS サービス別資料、ホワイトペーパー →Udemy模試5度目 →参考書模試3度目 →AWS サービス別資料、ホワイトペーパー 模試に関して Udemy模試はchromeの翻訳をかけてやりました。各1度目が2時間40分で2度目以降は2時間未満で解き終わりました。 参考書の模試は1度目が2時間40分、2度目以降は1時間半です。 公式模試は45分かかりました *合格は75%以上です。 第n回 1度目 2度目 3度目 4度目 5度目 1 58 92 77 84 90 2 60 90 72 90 97 3 62 89 85 93 93 4 57 92 82 93 96 参考書 60 93 97 公式模試 60 2月第1週：参考書解説部 2月第2週~3月第3週：Udemy模試4度ずつとその復習 3月第3週末：参考書模試2度 3月第4週：AWS公式模試、AWS サービス別資料、ホワイトペーパー 3月第4週末：Udemy模試5回目、参考書模試3回目 3月第5週：総復習 試験 1問2分で解いて2時間半、残り30分を見直しに使おうと思いましたが、見直しは疲れ切ってぼーっと眺めてただけでフラグを立てた回答を変えることはできませんでした。 所感 全ての模試で最初は60%なので成長が感じられず無謀なのかと思っていました。媒体を変えても60%なのが更にきつかったです。 Udemyをchrome翻訳で解いていて不自然な日本語に慣れて本番対策になりました、それでもわからない時は仕方なく原文を読みました。 一番難しいなと思ったのは本番ではなく公式模試でした、、、 試験3時間は長すぎます、もちろん2時間くらいのところでトイレに行きました。 受ける方はトイレ休憩の想定をお勧めします。 ちなみに普段の勉強は20分毎に休憩が必要なくらい集中力がありません、、、

はじめに Amazon S3 を使っている中で、他の AWS アカウント上にある S3 バケットのデータを利用したくなるときがあります。この時は、主に以下の3つの方法が利用可能です。 S3 バケットのクロスアカウントレプリケーション バケットポリシー スイッチロール 今回は、「S3 バケットのクロスアカウントレプリケーション」について、設定手順の確認をしていきます。 前回の記事では、「S3 バケットのクロスアカウントレプリケーション」を取り上げました。今回の記事は「バケットポリシー」と「スイッチロール」の方法を確認していきましょう。 バケットポリシー 構成図 構成図はこんな感じです。S3 Bucket の共有元でバケットポリシーを設定し、共有先のユーザーに紐づく IAM Policy でアクセス許可を行う形です。 アカウント1 : S3 Bucket の作成 クロスアカウントアクセス用の S3 Bucket を作成します。 ファイルの中身はこんな感じです。 アカウント1: バケットポリシーでクロスアカウントを許可 他のアカウントにアクセスさせたい S3 バケットを開いて、Bucket Policy の個所で Edit を押します。 以下のポリシーを指定します。 アクセスを許可する、異なる AWS アカウントの IAM User ARN を指定 アクセス許可の操作種別を指定 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::xxxxxxxxxxxxx:user/cliuser" }, "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::s3-crossaccount-bucket01", "arn:aws:s3:::s3-crossaccount-bucket01/*" ] } ] } アカウント2 : IAM Policy について アクセスを行う IAM User は、既に AdministratorAccess を付与しており、S3 Bucket へのアクセスが出来る状態になっています。 アカウント2 : 動作確認 バケットポリシーをつかったクロスアカウントアクセスは、マネージメントコンソールからアクセスできません。AWS CLI や SDK を利用して API 経由でアクセスをします。今回は。AWS CLI を使っていきましょう。 まず、AWS CLI で利用しているユーザーを確認します。たしかに AWS アカウント2 側で、アクセス許可を設定したユーザーです。 > aws sts get-caller-identity --profile sub1 { "UserId": "AIDA4DSZG6OWJQFTUCNOH", "Account": "xxxxxxxxxx", "Arn": "arn:aws:iam::xxxxxxxxx:user/cliuser" } s3 ls コマンドで、異なるアカウントのバケットの中身を確認します。正常に実行ができましたね。 > aws s3 ls s3://s3-crossaccount-bucket01 --profile sub1 2022-04-02 15:42:55 18 crossaccount-file01.txt 実際にファイルをダウンロードしてみます > aws s3 cp s3://s3-crossaccount-bucket01/crossaccount-file01.txt test.txt --profile sub1 download: s3://s3-crossaccount-bucket01/crossaccount-file01.txt to ./test.txt ファイルの中身も確認できます > cat test.txt 見えますか？ スイッチロール 構成図 構成図はこんな感じです。アクセスを共有したい AWS アカウント 1 の方で、スイッチロール用の IAM Role を準備します。スイッチロールは、AWS アカウント2 に限定が可能なので、セキュアに構成可能です。 アカウント1 : IAM Role の作成 Create role で スイッチロール用の IAM Role を作成します。 スイッチロールを許可させたい AWS アカウント2 側の Account ID を指定します。 今回は、作業を簡単にするために、すべての S3 Bucket にアクセス可能な AmazonS3ReadOnlyAccess を指定します。実際の環境では、Resource の指定で具体的なバケットに限定したアクセスを設定するとよいでしょう。 名前を指定します スイッチロール用の IAM Role が作成されました アカウント2 : スイッチロール アカウント2 側でスイッチロールを行います。 ロールの切り替えを選択します せってい スイッチロールが出来ました。このまま S3 のページに移動します。 AWS アカウント1 側のバケットが参照できます。 バケットの中のファイルも確認可能です 正常にファイルの中身も確認できました。 検証を通じてわかったこと 「バケットポリシー」を使ったクロスアカウントアクセスの方法は、マネージメントコンソールのバケット一覧に表示されない。AWS CKI や SDK などで API を経由してアクセスする必要がある 「スイッチロール」の場合はマネージメントコンソールから GUI アクセスが可能

興味関心から始めた技術 　最初に「IT」という言葉の意味を知った時のことをなぜか覚えています。 私が小学校の高学年の頃、私が父に間違った知識で「ITはインターネットテクノロジーの略だよね」と聞いたことがあります。もちろん「インフォメーションテクノロジーの略だよ」という答えが返ってくるのですが、その頃はまだインターネットの技術とインフォメーションの技術の違いすら判らず、知識がないまま父のコンピュータを使って、ローマ字表を印刷してそれを見ながらキーボードで文字を打っていたのを覚えています。思い返せば、生まれた時から近くにコンピュータがありました。 　しばらくして私は、興味があるという感情をきっかけにプログラミングを始めました。 最初の作品はGASで記述した、ウェブサイトの情報をスプレッドシートに記録するスクレイピングプログラムでした。初めてプログラムが思い通りの結果に反映された時の感動を覚えています。 　私は情報や工学の出身ではありませんが、このように試行錯誤しながら勉強していく中でITの自由度やインフラとしての確かさに改めて気付かされました。今では、ITは、世界の政治・経済を構成する様々な場所で扱う情報の精度と速度を加速させる革命的な技術であると認識しています。 人の需要に応えるための技術レベル 　この流行が激しく比較的新しい分野をモチベーションを維持・拡大していきながら継続的に学習するためには、前述のような技術の可能性の広さを知りながら興味関心を中心に自分が扱うことのできる技術が増えていく体験が重要だと思います。 　一方で、興味や関心といった感情のみで培った技術を人の需要に応えるレベルまで昇華させるとなると話は変わってきます。そのためには相手の需要を満たす手段を得る必要があり、それが必ず興味のあることだとは限りません。そもそも興味関心とは、無知の知と自分の実績から更に達成できそうな期待が重なった限られた範囲で起こる一時的で不安定な感情であると考えてます。 この定義が正しいとすると、人の需要に応えるという目標を達成するには自分の興味関心を判断基準にして手段を習得していくだけでは足らず、人の需要を満たすための手段を逆算して出し、段階的に習得していくことが両者満足の最適な解決策だと考えました。 今後について そこで実際に需要から逆算した技術を自分なりに調べてみて、自分の興味関心が社会の需要が高い技術から勉強をし始めました。 今後学習進捗やメモを記録として投稿しようと思います。

はじめに ２２年度文系学部卒のたいきです。この記事では、システムの開発経験もないのに、見よう見まねで「プロジェクトごっこ」をしていきます。 ・保有資格 : 応用情報技術者・AWS-SAP ・プログラミング言語:軽くPython 本記事について 　前回記事で定めた要件定義をもとにして、今回は本プロジェクトごっこの基本設計をしていきたいと思います。下記が前回記事です、よかったら読んでみてください。 【明日から社会人】開発未経験がクラウドを企業に導入するプロジェクトごっこをしてみた~その2~【要件定義編】 本企画の最初の記事から読んでいただける方はコチラ 前回のシステムの基本設計の続きとして、クラウド環境構築の基本設計をしていきます。 本記事は、下記のサイトを参考にして基本設計を行わせていただきました。 https://pm-rasinban.com/rd-write 仕様書・設計書テンプレート | 基本設計書・詳細設計書サンプル クラウド環境構築の基本設計 以下の要件定義書に記した、要件ごとに設計していきます。 ・1.セキュリティの基準とAWSのベストプラクティスに沿っていない場合を検知する。 ・2.脆弱性・インシデントの自動復旧による発見的統制 ・3.Organizationsとの統合によるセキュリティの一元管理 ・4.ログ収集の一元化 ・5.AWS SSOを利用した既存のアクティブディレクトリとの統合 1.セキュリティの基準とAWSのベストプラクティスに沿っていない場合を検知する。 CloudTrail・Amazon Config・Guard Dutyなどの情報収集リソースを起動し、Security Hubで脆弱性やFindings(検知)を管理。 下図がAWSリソースの概要 2.脆弱性の自動修復 特定の脆弱性を発見した際に自動的にその脆弱性を自動修復する。 以下が自動修復アーキテクチャ こちらのアーキテクチャは、自力での１からの実装は自分では不可能なので、AWS公式さんの実装ガイドを参考にさせていただきます。 AWS Security Hubによる自動対応と修復 https://aws.amazon.com/jp/blogs/news/automated-response-and-remediation-with-aws-security-hub/ 3. Organizationsとの統合によるセキュリティの一元管理 Security Hubを全アカウントに適用し環境を一元的に管理し、統制します。アカウントをグループ化（OU化）してワークフローを整理し、ガバナンスのためにアカウントまたはグループ（OU）にポリシーを適用します。加えて、統制アカウントの支払いを一元化できます。 以下が組織体制です。 OrganizationalRoot unitは、管理アカウント以外を一括制御するためのもの。 4. 操作ログ・アクセスログの全てのログを特定のS3バケットにて集中管理を行う フェイルオーバー先にもS3バケットを作成し、データをレプリケーションする。そして、同様のアーキテクチャを事前に用意し、DR時も変わらずロギングを続ける。 Kinesis Data Firehose：データをまとめて、かつ圧縮して転送可能なサービス。これにより、直接S3へログを送信するよりもコストを削減できる。 5.AWS SSOを利用した既存のアクティブディレクトリとの統合とSSOの実装 ユーザはユーザポータルに普段使っているユーザ名とパスワードでサインインして、管理者がアクセスを許可したAWSアカウントやアプリケーションへのアクセスを可能にする。 オンプレミスActive Directoryの情報を参照し、その情報を利用してAWS SSOがクラウド上で認証情報を管理する。 おわりに 改めてになりますが、詳細設計に関しては今回作成しません。理由としましては、私自身がアーキテクチャの知識しかなく開発の知識が全くなく、利用するコードなどの想像が全くできていないからです。開発は、その場その場で壁にぶつかりながら試行錯誤をしながら開発していきます。今後ですが、次回記事で大まかな開発工程を決めていきます。その後は、その開発工程に沿って実際に開発していくことになりそうです。引き続きよろしくお願い致します。 PS.無事社会人になれました。

SSHのポート番号と聞くと、昔大学院卒の同期に年齢を聞かれ「22」と答えたら、「SSHのポート番号じゃん」と言われたのを今でも思い出します。 それはさておき、サーバにファイルを送るためには、SCPコマンドを利用してという手順があると思いますが、利用できるポートが限られる場面も少なからずあるかと思います。 私はMacを利用しているのですが、通常なら以下の手順を取ります。 ターミナル起動 scp -i [キーペアパス] [ローカルファイルパス] ec2-user@[IPアドレス]:[サーバのパス]でファイルのアップロード (WindowsならTera Termを使うことが多いかと思います) ただ、先日これを行おうとしたところ、ポート番号の問題で許可されませんでした。 その時の代替案として、S3とSystems Managerを利用して解決しましたので、備忘として残しておきます。 前提 EC2を利用して、Webサーバを公開している PCのローカル環境からscpやsshは都合上できない AWSは割と強めの権限を持っていて、ロールの付与権限などもある 大まかな手順としては以下です。 S3にサーバで利用するファイルをアップロード EC2にSystems Managerとの接続ができるようなロールを付与 System Managerに入り、S3からファイルをダウンロードするコマンドを実行し、EC2にダウンロード S3のバケットとファイル準備 バケット名が被らないように設定を行います。バケットの設定は初期状態のままで問題ありませんでした。 (パブリックアクセスも全てブロックのまま) その後、必要なファイルをドラッグ&ドロップなどでアップロードすれば完了です。 EC2にSystem Managerとの接続ができるようなロールを付与 EC2の画面より、対象のEC2を選択し、[IAMロールを変更]をクリック 遷移した画面よりロールの作成に飛べますので、そのまま新しいロールを作成します。 EC2を選択し次へ 検索窓より、ssmと入力し[AmazonEC2RoleforSSM]を選択 その後わかりやすいロール名を記載して完了 System ManagerよりEC2へアクセス System Managerに入り[セッションマネージャー]を選択 セッションの開始を押す サーバが起動している場合は、以下のように表示がされるため選択して[セッションを開始する]を押す 以下のような画面に遷移するため、cliを利用してaws s3 ls s3://バケット名バケット内のファイルを確認 (Amazon linuxなら、特に何も作業せずAWS cliの利用ができました。) sudo suで管理者権限になり、作業が行えるディレクトリに移動し、ダウンロードコマンドを実行 aws s3 cp s3://バケット名/index.html ./ #現在いるディレクトリにコピー 必要に応じてmvを行いディレクトリの移動などをさせれば完了です。 平日は結構遅くまで仕事をしていることが多く、勉強したり記事を書くのは休日になることが多いのですが、 やはり奥さんから「休みの意味知ってる？」と煽られますのでぷよぷよしてきます。

はじめに ２２年度文系学部卒のたいきです。この記事では、システムの開発経験もないのに、見よう見まねで「プロジェクトごっこ」をしていきます。 ・保有資格 : 応用情報技術者・AWS-SAP ・プログラミング言語:軽くPython 本記事について 　前回記事で定めた要件定義をもとにして、今回は本プロジェクトごっこの基本設計をしていきたいと思います。下書きをした際に思った以上に、長くなってしまったので、「システムの基本設計」と「クラウド環境構築の基本設計」の二つに分割していきます。 前回記事【明日から社会人】開発未経験がクラウドを企業に導入するプロジェクトごっこをしてみた~その2~【要件定義編】 本企画の最初の記事から読んでいただける方は開発未経験がクラウドを企業に導入するプロジェクトごっこをしてみた~その１~ 本記事は、下記のサイトを参考にして基本設計を行わせていただきました。 https://pm-rasinban.com/rd-write 仕様書・設計書テンプレート | 基本設計書・詳細設計書サンプル< システムの基本設計書 システム化業務フロー 前回の要件定義の内容をより具体的に、少し技術よりに設計してみました システム機能説明 システム化業務フローの各プロセスを説明したものです。 クラウド構成図 本プロジェクトのクラウド構成図を完璧に自作してみました。多分、これは自分の首をしめることになりそうです。笑　AWS-SAPにて、アーキテクチャの仕方は学びましたが、開発の仕方は全くの無知です。加えて、コードもほとんど書けません。これからどうなるのか、恐ろしいと共にどこまで自力でできるかワクワクしています。非常にチャレンジングです。 簡単にこのアーキテクチャの概要を説明します。 1.ユーザーは、CloudFrontを前段にし、Amplifyでホストされているページにアクセスします。 2.Cognitoで認証 3.S3への写真のアップロードを引き金にイベントを発行しLambda起動 4.アプリケーションでの画像分析 5.推論結果(きのこの山とたけのこの里の各数量)をLambda経由でDynamoDB 6.DynamoDBは24時間ごとにAthenaでデータ型の整形をしS3へ送信するバッチ処理 7.送信後DynamoDBのデータは消去 8.LambdaにてS3のデータを集計し集計結果をcsvに保存(今までのきのこの山とたけのこの里の総計)および、集計結果の更新 アーキテクチャを作成してみて思ったこと このアーキテクチャでは、s3にて日毎に別のcsvファイルを保持して、バッチ処理時にそのファイルの内容を一つのcsvファイルに保存および集計を想定しています。しかし、個人的にもうちょっと賢いやり方があるのでは、、、？と考えています。もしかしたら、リアルタイムでランキングを更新したりするアーキテクチャを参考にできるかもしれませんので、開発時に変更があるかもしれません。 各AWSリソースの概要説明 セキュリティ自動化アーキテクチャ これも、またまた難しそうなものを見つけてしまいました。このアーキテクチャは、AWS公式さんが設計の開発方法を公開しているのでそちらを参考にしていきます。 https://aws.amazon.com/jp/solutions/implementations/aws-waf-security-automations/ AWS WAFセキュリティオートメーション 上記のAWSが推奨するAWS WAFを用いた自動化アーキテクチャを採用します。このアーキテクチャは４つの方法によりD-Iの６つの脅威から防ぐことができます。 1.WAFへのアクセスログに基づくWAFルールの更新によるアクセス制御 2.アプリケーションへのアクセスログに基づくアクセス制御 3.ハニーポットの設置による攻撃者の特定及びアクセス制御 4.サードパーティー企業所有のIP元評価リストの活用によるアクセス制御 おわりに 基本設計において、顧客側・技術者側両方にシステムの設計意図ができるだけ伝わるように頑張ってみました。技術の説明を、深すぎず浅すぎずといった感じです。今後ですが、この基本設計をもとに開発していきます。詳細設計に関しては今回作成しません。理由としましては、私自身がアーキテクチャの知識しかなく開発の知識が全くないからです。現段階では、利用するコードなどの想像が全くできていません。開発は、その場その場で壁にぶつかりながら試行錯誤をしながら開発していきます。Googleさんを頼りに。笑

初めに AWS Systems Manager Fleet Managerを利用して、プライベートサブネットに配置したWindowsServerにWeb GUIからRDP接続してみました。 検証構成図 検証前提 以下は実施済みの前提となります。 検証構成図に記載のAWSネットワーク環境（VPC、サブネット）作成 EC2インスタンス(Windows)作成 事前準備 SSMエージェントのインストール IAMロールの作成 IAMロールのアタッチ SSM関連エンドポイントの作成 1. SSMエージェントのインストール WindowsServerをAWS公式のAMIから構築した場合にはSSM Agentがすでにインストールされています。 2. IAMロールの作成 IAMポリシー「AmazonSSMManagedInstanceCore」を設定した、IAMロールを作成します。 信頼されたエンティティタイプ：AWSのサービス、ユースケース：EC2 を選択 「AmazonSSMManagedInstanceCore」をチェックし、ポリシーをアタッチ 任意のロール名を設定（ここではSSM-Test-Role） 必要に応じてタグを設定し、ロールを作成 ロールが作成されたことを確認 3. IAMロールのアタッチ 作成したIAMロールを対象のインスタンスにアタッチします。 IAMロールを変更を選択し、IAMロール設定画面に遷移 作成したIAMロールをアタッチ 正常にアタッチされたことを確認 IAMロールの反映のためEC2インスタンスを再起動 IAMロールの反映について、EC2の再起動は必須ではありません。 SSM AgentがIAMロールを検出するまで待機するか、SSM Agentの再起動により反映ができます。 参考：既存の IAM ロールを EC2 インスタンスに割り当てるにはどうすればよいですか? 4. SSM関連エンドポイントの作成 以下のエンドポイントを作成します。 SSM Session Managerとの通信用エンドポイント ※セキュリティグループでは、VPC内からHTTPS（443）のインバウンド通信を許可 com.amazonaws.ap-northeast-1.ssm com.amazonaws.ap-northeast-1.ssmmessages com.amazonaws.ap-northeast-1.ec2messages AWS SSMユーザーズガイド ステップ 6: (オプション) AWS PrivateLink を使用して Session Manager の VPC エンドポイントを設定する 例としてエンドポイント：com.amazonaws.ap-northeast-1.ssmの作成手順を記載 対象VPCを選択、DNSを有効化をチェック、対象サブネットを選択 対象のセキュリティグループを選択 セキュリティグループでは、VPC内からHTTPS（443）のインバウンド通信を許可しておく （例）セキュリティグループ　ルール 任意のタグを設定し、エンドポイントを作成 エンドポイントが作成されたことを確認 同様の手順で、 com.amazonaws.ap-northeast-1.ssmmessages com.amazonaws.ap-northeast-1.ec2messages についても作成 SSM Fleet Managerを利用したWindowsインスタンスへの接続確認 ここまでの事前準備が完了したら、Windowsインスタンスへの接続確認を行っていきます。 1. Fleet Manager上への表示確認 対象ノードがマネージドノード一覧に表示されていることを確認 2. Fleet ManagerからのRDP接続確認 [ノードアクション]-[リモートデスクトップ(RDP)との接続]を選択 認証情報を入力し（ここでは認証タイプをユーザ認証情報として接続）Connectを選択 接続ができました。 最後に プライベートサブネット上のWindowsインスタンスへの接続に関して、 Bastionインスタンスを用意してssh転送などを行わなくても直接GUI画面接続が可能となります。Bastionインスタンスが不要となり、構築後の運用・保守の面でも便利な機能なので、積極的に活用していければと思います。

はじめに Amazon S3 を使っている中で、他の AWS アカウント上にある S3 バケットのデータを利用したくなるときがあります。この時は、主に以下の3つの方法が利用可能です。 S3 バケットのクロスアカウントレプリケーション バケットポリシーと IAM ポリシー スイッチロール 今回は、「S3 バケットのクロスアカウントレプリケーション」について、設定手順の確認をしていきます。 S3 バケットのクロスアカウントレプリケーションの概要図 まず概要図はこんな感じです。 左側にある AWS アカウント1のバケットに格納されたデータが、自動的に右側の AWS アカウント2 のバケットにコピーされます。データのコピーを行うことで、同じデータを双方に持つ形です。料金の観点だと、それぞれのバケットでデータを持つため、単純に料金がそれぞれ掛かってきます。 アカウント1 : S3 Bucket を準備する レプリケーション対象の S3 Bucket を用意します。レプリケーションを開始したときに既にファイルが存在する場合、どういった挙動になるのか気になるので、2つのファイルを作成しています。 S3 レプリケーションを行うには、バージョニングの設定が必要です。デフォルトでは無効になっているので、有効にしていきます。 S3 Bucket の詳細ページにある Properties から、Edit を選択します。 Enable を選択して、Save changes を押します 有効になりました アカウント2 : S3 Bucket を準備する 同様に、AWS アカウント 2 でもバケットを準備して、バージョニングを有効化します。 アカウント1 : IAM Role の作成 レプリケーションを行うために、IAM Role を作成していきます。IAM Role の作成画面で Custom trust policy を選択します。 次の trust policy を入力します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } 次に、作業を簡単にするために次の AmazonS3FullAccess を選択します。実際の環境では、厳密な設定をしていくと良いでしょう。 コマかな設定を行う場合、例えば、このようなポリシーを組み立てます。 { "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:ListBucket", "s3:GetReplicationConfiguration", "s3:GetObjectVersionForReplication", "s3:GetObjectVersionAcl", "s3:GetObjectVersionTagging", "s3:GetObjectRetention", "s3:GetObjectLegalHold" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::s3-replicaton-source01", "arn:aws:s3:::s3-replicaton-source01/*", "arn:aws:s3:::s3-replication-dest01", "arn:aws:s3:::s3-replication-dest01/*" ] }, { "Action": [ "s3:ReplicateObject", "s3:ReplicateDelete", "s3:ReplicateTags", "s3:ObjectOwnerOverrideToBucketOwner" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::s3-replicaton-source01/*", "arn:aws:s3:::s3-replication-dest01/*" ] } ] } IAM Role の名前を指定して保存します 作成されました。 アカウント2 : レプリケーション許可設定 次のを参照しながら、レプリケーション先の AWS アカウントで、レプリケーション許可のバケットポリシーを設定していきます。 URL : https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/setting-repl-config-perm-overview.html#setting-repl-config-crossacct Bucket Policy で Edit を押します。 AWS アカウント1 で作成した IAM Role の ARN に変更して、以下のJSON Policy を指定します。 { "Version":"2012-10-17", "Id":"PolicyForDestinationBucket", "Statement":[ { "Sid":"Permissions on objects", "Effect":"Allow", "Principal":{ "AWS":"arn:aws:iam::xxxxxxx:role/S3-Replication-Role" }, "Action":[ "s3:ReplicateDelete", "s3:ReplicateObject" ], "Resource":"arn:aws:s3:::s3-replication-dest01/*" }, { "Sid":"Permissions on bucket", "Effect":"Allow", "Principal":{ "AWS":"arn:aws:iam::xxxxxxxx:role/S3-Replication-Role" }, "Action": [ "s3:List*", "s3:GetBucketVersioning", "s3:PutBucketVersioning" ], "Resource":"arn:aws:s3:::s3-replication-dest01" } ] } アカウント1 : レプリケーションの設定 S3 Bucket の詳細ページで、Management から Create replication rule を選択します。 レプリケーションルールに好きな名前を指定できます all-replicaton-to-another-account01 すべてのオブジェクトをレプリケーションの対象にします。プレフィックスなどを指定して、レプリケーション対象を指定することも可能です。 宛先の S3 Bucket を指定します。AWS アカウント2 側の アカウントID と バケット名を指定します。 アカウント1 で作成した IAM Role を指定します。 追加のオプション設定が出来ます。Metrics のみ有効にして Save を押します。 Replication Time Control (RTC) : RTC を有効にすることで、ほとんどのオブジェクトは数秒でレプリケーションが完了します。99.99% のオブジェクトは 15 分以内にレプリケートします。 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/replication-time-control.html Delete marker replication : チェックをオンにすると、レプリケート元での削除がれプリケート先に反映します https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/delete-marker-replication.html Replica modification sync : タグや ACL などのメタデータレプリケーション設定 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/replication-for-metadata-changes.html 既に存在するオブジェクトもコピーするか聞かれるので、Submit を押します 既存のオブジェクトのコピーを有効化したため、Batch Operations の作成画面に遷移します。 Report の設定をしたうえで、Save を押します。 作成されました。 一定時間後、Batch Operation が処理されていることがわかります。この記事の環境では、4分ほどで処理が完了しました。 アカウント2 : 初期ファイル レプリケーション確認 レプリケーションを設定するときに、既に存在していたファイルが正常にレプリケーション先にコピーされているか確認します。AWS アカウント2 側の S3 Bucket を確認しましょう。 想定通り、正常にコピーされています。 アカウント1 : 新しくファイルをアップロード 初期のコピーが済んだので、新しくファイルをアップロードしてみましょう。まず、新しいファイルのアップロード前の状況です。 NewFile01.txt という名前のファイルをアップロードしました。 アカウント2 : レプリケーション確認 レプリケーション先の S3 Bucket に、正常にコピーされています！記事の環境では数秒でレプリケーションされていました。 検証を通じてわかったこと S3 Bucket のレプリケーション先は、異なるリージョンでも設定可能 レプリケーション設定時に既に存在しているファイルも、レプリケーションの対象にすることが出来る Replication Time Control (RTC) を有効にすることで、ほとんどのオブジェクトは数秒でレプリケーションが完了する。99.99% のオブジェクトは 15 分以内にレプリケートと説明されている。 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/replication-time-control.html 参考URL

はじめに 今回、本番環境にデプロイしようとEC2に色々インストールした結果環境が汚れたので、インスタンスを初期化して新たに作ろうと考えた。 コンソール画面のEC2にて、動いていたインスタンスを削除し、全く同じ設定で新たにインスタンスを作成した。 EC2にログインしようとした結果、エラーが出てすぐに解決できたがキータの記事が見当たらなかったため簡単に記載致します。 前提 EC2 ElasticIP（関連つけている） 起きたエラー はじめに書いた通り、新たに作成したEC2にログインしようとした結果こんなエラーが出た。 $ ssh -i [pem名].pem ec2-user@[ElasticIP] @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ED25519 key sent by the remote host is SHA256:ハッシュ〜〜〜〜〜〜〜〜〜〜〜〜. Please contact your system administrator. Add correct host key in /Users/〜〜〜〜/.ssh/known_hosts to get rid of this message. Offending ED25519 key in /Users/〜〜〜〜/.ssh/known_hosts:11 Host key for [ElasticIP] has changed and you have requested strict checking. Host key verification failed. 本番環境でこういうのでると焦りますよね。 とりあえず、エラーを全部コピーして、翻訳。 警告: リモートホストの識別が変更されました! 誰かが何か悪さをしている可能性があります! 今まさに盗聴されているかもしれない（中間者攻撃）! ホスト鍵が変更されただけかもしれません。 リモートホストから送信された ED25519 鍵のフィンガープリントは次のとおりです。 SHA256:ハッシュ〜〜〜〜〜〜〜〜〜〜〜〜. システム管理者にお問い合わせください。 正しいホストキーを/Users/~~~~~~/.ssh/known_hostsに追加すると、このメッセージは消えます。 /Users/~~~~~~/.ssh/known_hosts:11にある問題のあるED25519 key [ElasticIP] のホスト鍵が変更されたので、厳密なチェックを要求しています。 ホスト鍵の検証に失敗しました。 以前のホストキーと違うため、エラーが出ている。 /Users/~~~~~~/.ssh/known_hosts ここに。known_hostsファイルから[ElasticIP]に関する情報を取り除けば、以前のホスト鍵も削除される。 ※[ElasticIP]設定していない方は、前に削除したEC2のパブリック IPv4 アドレスが記載されています。 解決方法 ssh-keygenコマンドを使用します。 ssh-keygenコマンドとは、秘密鍵と公開鍵の鍵ペアを作成できるコマンドです。 ssh-keygenコマンドにオプション**-R**をつけると、 指定したホストに属する鍵を全て取り除く事ができます。 そちらを使用いたします。 $ ssh-keygen -R [ElasticIP] # Host [ElasticIP] found: line 11 /Users/~~~~~/.ssh/known_hosts updated. Original contents retained as /Users/~~~~~~/.ssh/known_hosts.old 上記コマンドを打った後、 $ ssh -i [pem名].pem ec2-user@[ElasticIP] The authenticity of host '[ElasticIP] ([ElasticIP])' can't be established. ED25519 key fingerprint is SHA256:ハッシュ〜〜〜〜〜〜〜. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? ＄ yes yesと打てばログインできます。 以上。

やりたいこと AWS の何らか (今回は EC2) を使って、外部に公開できる (されている) サーバを用意する 用意したサーバで、WebApp (今回は FastAPI) を公開する (WebApp に限らず、httpd (Apache) で Web ページ公開できる) AWS の無料枠内で完結させる データベースに特化したサービスや、Web サーバに特化したサービスなどもあり、それらを活用する方法もありますが、今回は　EC2 単品で完結させ、「とりあえず動くようにしてみる」ことを目標にします。 AWS のアカウントは準備できているという前提で話を進めます。 軽く EC2 や AWS の話 EC2 というのは、AWS において仮想サーバを利用できるサービスです。EC2 の仮想サーバのことはインスタンスと呼ばれます。 自宅での自家サーバに比べ、AWS などのレンタルサーバ (仮想サーバ) の良い所は、Amazon社で適切に管理されている物理マシンを利用でき、自宅でハードウェアを管理する必要が無い所、様々なネットワーク設定などを、ハードウェアを自分でいじることなく制御できる所ですね。 EC2 インスタンスの作成 リージョン設定 AWS コンソールの「サービス」から、「コンピューティング -> EC2」押下で EC2 のダッシュボードを開きます。 画面右上から、リージョン (サーバの所在位置) を設定します。 日本に住んでいて、かつ特別な事情が無ければ、「アジアパシフィック (東京 or 大阪)」を選ぶと良いです。一般に、距離的に近い方がアクセス速度が早いです。 セキュリティグループ設定 画面左のメニューから「セキュリティグループ」を選択します。セキュリティグループは、EC2 のファイアウォール的なものです。 デフォルトのグループが 1つあります。 これを利用することもできますが、ここでは新しく 1つグループを作成します。画面右上の「セキュリティグループを作成」を押下します。 適当なグループ名、説明を設定します。VPC はデフォルトで問題ありません。 インバウンドルール (外からサーバに対する通信) は、サーバの操作のため SSH (22) に加え、用途によって必要なポートを開けます。今回は WebApp へのアクセスのため「カスタムTCP」で、FastAPI デフォルトの 8000 ポートを開けます。 Apache などでのアクセスをする場合は、8000 の代わりに HTTP (80) を開けます。 ソースに 0.0.0.0/0 (Anywhere-IPv4) を設定すると、誰からでもアクセス可能になります。より安全をとるのであれば、自身のグローバル IP を調べ、その IP からのアクセスのみを設定しましょう。 アウトバウンドルール (サーバ内から外に対する通信) は、特に事情が無ければ「すべてのトラフィック」で問題無いです。これにより、APT や YUM、PIP コマンドなどでのダウンロードが行えます。 インスタンス作成 インスタンスのダッシュボードから「インスタンスを起動」を押下します。 無料枠で利用できる AMI (OS) は、Amazon Linux の他に Ubuntu や Windows Server などがあります。特に事情やこだわりが無ければ Amazon Linux で問題無いでしょう。 インスタンスタイプでは、サーバのスペックを決められます。無料枠で使えるのはデフォルトで選ばれているものだけなので、今回はそのままにします。 インスタンスの詳細設定はデフォルトのままにします。 ストレージの追加では、無料使用枠では汎用 SSD を 30GB まで利用できます。無料使用枠ではマグネティックストレージも利用できますが、SSD の方が良いでしょう。 終了しなければ消されませんが、一応「終了時に削除」のチェックは外しておきます。 タグの追加の設定は何もせずに次に進みます。 セキュリティグループは、「既存のセキュリティグループを選択する」を選び、さきほど作成したセキュリティグループを選択します。 最後に、確認画面が出てきますので、確認して「起動」を押下します。 その次に、キーペアの設定が出てきます。キーペアというのは、簡単に言えばインスタンスの操作 (SSH 接続) でアクセスするにあたって必要なキー (ファイル) です。「新しいキーペアの作成」で、適当なキーペア名を設定します。 (この後の方法によっては不要にはなりますが、)「キーペアのダウンロード」から xxx.pem ファイルのダウンロードを忘れずに行い、また、このファイルが漏洩しないように保管してください。 以上でインスタンス作成完了です。少しの間待つと、インスタンス状態が実行中に変わります。 インスタンスの操作 (SSH 接続) レンタルサーバの操作をするには、遠隔操作を用いる他ありません。EC2 Instance Connect または OpenSSH を用いて、インスタンスに SSH 接続します。 EC2 Instance Connect (ブラウザ) で接続 ブラウザ上でターミナル操作ができる方法です。追加でアプリなどを用意する必要が無いため、最も手軽に利用できます。 さきほど作成したインスタンス (操作したいインスタンス) を選択した状態で、画面右上の「接続」を押下します。すると、4つの接続方法を確認できる画面に移ります。 「EC2 Instance Connect」タブが選ばれた状態にし、右下の「接続」を押下します。何か別の設定をしていなければ、ユーザはデフォルトの「ec2-user」のままで問題ありません。すると、新しいブラウザタブが開き、そこからインスタンスをターミナル操作できます。 OpenSSH で接続 OpenSSH は、Linux や　Windows10 においてプリインストールされている SSH クライアントです。すなわち、自前環境の SSH クライアントや端末からアクセスする方法になります。 さきほど取得したキーファイル (xxx.pem) のアクセス権限を変更します。これを行わないと、公開範囲の広いアンセキュアなキーと判定され、利用できなくなってしまいます。 chmod 400 xxx.pem キーの準備ができたら、説明にある通りのコマンドを実行して接続できます。 ssh -i "xxx.pem" ec2-user@ec2-000-000-000-000.ap-northeast-1.compute.amazonaws.com ローカルファイルをインスタンスへコピーするには、SCP コマンドを利用します。 scp -i "xxx.pem" ./any-file ec2-user@ec2-000-000-000-000.ap-northeast-1.compute.amazonaws.com: 何か作ってアクセスしてみる FastAPI セキュリティグループで 8000 ポートを解放し、FastAPI でデフォルトの 8000 ポートを使う前提です。 初めに、FastAPI の動作に必要な最低限のパッケージを入れます。 pip3 install fastapi uvicorn 適当に JSON を応答するルートを作成し、実行します。 fapi.py from fastapi import FastAPI import uvicorn app = FastAPI() @app.get("/") def index(): return {"hello": "from AWS"} if __name__ == "__main__": uvicorn.run("fapi:app", host="0.0.0.0", port=8000, reload=True) python3 fapi.py 適当なブラウザからアクセスしてみます。インスタンスの詳細表示から、「パブリック IPv4 DNS」または「パブリック　IPv4 アドレス」を確認し、このアドレスのいずれかをブラウザの URL 欄に入力します。 ここで、ポートを 8000 と指定するのをお忘れなく。 http://ec2-000-000-000-000.ap-northeast-1.compute.amazonaws.com:8000/ または http://000.000.000.000:8000 正しくできていれば、ブラウザに JSON データが表示されます。 httpd (Apache) セキュリティグループで 80 ポートを解放している前提です。 httpd をインストールします。 sudo yum install httpd systemctl コマンドから起動します。一応、自動起動しないようにしておきます。 sudo systemctl start httpd sudo systemctl disable httpd FastAPI と同様の URL に、ブラウザからアクセスします。今度はポート指定をせずにアクセスします。 http://ec2-000-000-000-000.ap-northeast-1.compute.amazonaws.com/ または http://000.000.000.000 正しくできていれば、httpd のデフォルトページが表示されます。 せっかくなので、適当な自作ページに変えて確認してみます。 sudo sh -c 'echo "<h1>Hello from AWS</h1>" > /var/www/html/index.html' インスタンスの起動/停止 使わないときは、インスタンスを停止させておきましょう。もう使うことが無いようであれば、「インスタンスを終了」を選択し、インスタンスを削除します。

[前回] AWS公式資料で挑むSCS認定(24)-こんな時どうする(全分野その1) はじめに AWS資格11冠制覇の名人(同僚)のブログ記事から、 「公式ドキュメント(理論)とハンズオン(実践)のクイックな往復こそ最も有効な試験対策」 自分のやり方あっていたようです。よっしゃ、試験準備続けよう。 引き続き、AWS公式資料を参考に「こんな時どうする」の追記です。 分野1: インシデント対応 外部からIAMアクセスキーを悪用した不正アクセス発生、どのような操作が行われたか特定したい AWS CloudTrailを使用し、IAMアクセスキーと関連付けされたユーザの操作履歴を確認 AWS CloudTrailは、インフラストラクチャ全体のアカウントアクティビティをモニタリング/記録し、保存、分析、修復アクションをコントロールできる 分野2: ログとモニタリング(監視) CloudTrailログへの不正アクセスと改ざんを防止したい CloudTrail設定で、ログファイルの整合性を有効に 一元化された専用S3バケットにログ保存 S3ライフサイクルを設定し、古いログファイルをS3 Glacierにアーカイブしてから削除 KMS管理キーを使用したサーバー側の暗号化(SSE-KMS) 組織複数アカウントのCloudTrailログをS3バケットで一元管理しているが、一部アカウントの証跡がS3バケットに保存されない バケットポリシーで、問題アカウントのCloudTrailからのアクセスが許可されているか確認 マスターアカウントのCloudTrail設定で、ストレージがS3バケットに指定されているか確認 CloudTrailコンソールで、ログファイルをS3バケットへ配信するための証跡が有効か確認 S3バケット設定に対する変更を記録/監視し、SNS通知したい バケットポリシーで、AWS Configがバケット設定変更を記録できるように許可 AWS管理ポリシーのAWSConfigRoleをAWS ConfigのIAMロールにアタッチ 分野3: インフラストラクチャのセキュリティ EC2インスタンスの侵入テスト(ペネトレーション)を行いたい AWSの事前承認について 許可されたサービス(8つ)は事前承認不要(https://aws.amazon.com/jp/security/penetration-testing/) その他シミュレートされたイベントは、事前承認要 AWSユーザーの責任 セキュリティ評価に使用するツールとサービスが、禁止されたDoS攻撃などを使用せず正常動作できるように適切に設定し事前検証を行う サードパーティに依頼する場合も、侵入テストポリシーに違反しない方法でセキュリティ評価を実施することを保証 禁止された行為 Amazon Route 53ホストゾーン経由のDNSゾーンウォーキング サービス妨害(DoS)、分散サービス妨害 (DDoS)、シミュレートされたDoS、シミュレートされたDDoS ポートフラッディング プロトコルフラッディング リクエストフラッディング(ログインリクエストフラッディング、APIリクエストフラッディング) コンプライアンス要件に従って、EC2インスタンスの脆弱性リストを取得したい Amazon Inspectorを使用 Amazon Inspectorは、ソフトウェアの脆弱性や意図しないネットワーク露出がないか継続的にAWSワークロードをスキャンする自動脆弱性管理サービス 分野4: アイデンティティ(ID)及びアクセス管理 EC2操作に対し、MFAによる認証を強制したい MFA以外の認証を拒否するIAMポリシーを作成 "Effect": "Deny" "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": false}} AWS CLI使用時、MFAによる認証を強制したい IAMロールを作成、ロール信頼ポリシーでMFA以外の認証を拒否する ポリシーの"NotAction"に"sts:AssumeRole"を追加 Role権限を引き受けるため、CLIコマンドaws sts assume-roleを実行、下記パラメータを指定、 --role-arn: 上記ロール --serial-number: MFAデバイスのARN --token-code: MFAで発行されるトークン 分野5: データ保護 AWS Secrets ManagerでAmazon RDSのシークレット(パスワードなど)を自動的にローテーションさせたい VPCのプライベートサブネットにRDSインスタンスとAWS Lamda関数を配置 Secrets Managerからプライベートサブネットへ接続 方法1: VPCエンドポイントを使用 方法2: NATゲートウェイを使用 Lamda関数でシークレットのローテーションをスケジュール ELB配下のEC2に構築したアプリケーションのトラフィックに対し、暗号化を強制したい ELBのHTTPSリスナー(ポート番号443)を有効に設定 ELBのHTTPSリスナーからEC2インスタンスへのリクエストはHTTPS送信(送信先ポート番号443) おわりに 試験対象の各分野における「こんな時どうする」追記でした。 次回も続きます、お楽しみに。 [次回] AWS公式資料で挑むSCS認定(26)-こんな時どうする(全分野その3)

本番運用だと無効化することもないと思ったので、参考までに無効化までやってみます。 1.Amazon GuardDuty とは GuardDuty は、AWS 上で発生しているログを自動的に収集し、機械学習や、悪意のある IP アドレスやドメインのリストなどの脅威インテリジェンスフィードを利用して、怪しい動きを検知する。 Amazon GuardDuty 脅威検知のために使用するログは以下の6種類。 AWS CloudTrail イベントログ AWS CloudTrail 管理イベント AWS CloudTrail S3 データイベント VPC フローログ DNS ログ Kubernetes 監査ログ（New!） 2.設定 基本有効化するだけ。GuardDutyを有効化すれば、上記のログが内部的に自動で収集開始される。 ただし、GuardDutyが内部的に生成・検出したログはユーザがコンソール上から閲覧することができないため、インシデント発生時にGuardDuty画面からしかログの参照ができない。このため、VPC フローログ、 Cloud Trail 監査ログは自身で別途有効化しておくことが推奨される模様。S3 バケットにエクスポートすることもできる。 2-1.有効化 GuardDuty はリージョナルサービスのため、有効化するリージョンをしっかり確認して設定を始める。 今回は東京リージョンで設定する。 GuardDutyが各種ログを収集するためのアクセス権限はここで確認できる。 有効化する。 上部にリリース情報が記載されているが、閉じてよい。 2-2.S3 バケットへのエクスポート S3 バケットへのエクスポートが推奨されているため設定する。 [設定]-[結果のエクスポートオプション] 更新された結果の頻度は以下から選択できるが、検証環境なので15分ごとにエクスポートさせてみる。 6時間ごとに CWE と S3 を更新する 1時間ごとに CWE と S3 を更新する 15分ごとに CWE と S3 を更新する GuardDuty用にS3 バケットを新たに作成する。 バケット名：ユニークである必要がある。アンダーバーは使えない。 プレフィックス：<AWSアカウントID>/GuardDuty/<リージョン名> とした。 デフォルトだと<バケット名>/AWSLogs/になった。 KMS キーがないので作成する必要がある。 [KMS コンソールに移動して新しいキーを作成する]をクリックすると、KMS のマネジメントコンソール（カスタマー管理型のキー）に飛ぶので、[キーの作成]からKMS キーを作成する。 キーのタイプは「対象」を選択し、その他はデフォルトで[次へ]をクリックする。 [エイリアス]を入力する。その他の項目は任意で設定し[次へ]をクリックする。 [キー管理のアクセス許可を定義]は何もせず[次へ]をクリックする。(後で設定する) [キーの使用アクセス許可を定義]は何もせず[次へ]をクリックする。(後で設定する) [完了]をクリックする。 2-3.KMS キーのキーポリシーを設定する GuardDutyの[設定]画面で探知機 ID （SourceDetectorID）をコピーしておく。 KMS の カスタマー管理型のキー画面に戻り、ARNをコピーしておく。[キーポリシー]タブで[ポリシービューへの切り替え]をクリックする。 [編集]をクリックする。 デフォルトのキーポリシーに、次のステートメントを "Statements": セクションに追加する。 "Resource":コピーしておいた KMS キーのARN "aws:SourceAccount":対象AWSアカウントID "aws:SourceArn":コピーしておいたGuardDutyの探知機 ID （SourceDetectorID） { "Sid": "AllowGuardDutyKey", "Effect": "Allow", "Principal": { "Service": "guardduty.amazonaws.com" }, "Action": "kms:GenerateDataKey", "Resource": "arn:aws:kms:Region:111122223333:key/KMSKeyId", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333", "aws:SourceArn": "arn:aws:guardduty:Region:111122223333:detector/SourceDetectorID" } } } [変更の保存]をクリックする。 任意でキーローテーションを有効にする。 GuardDutyの画面に戻り、作成した KMS キーを設定して[保存]をクリックする。 S3 バケットへの GuardDuty 結果のエクスポート設定が完了した。 S3 の AWS マネジメントコンソール画面を見ると、S3 バケットが作成されている。 3.サンプル生成 何も検出結果がないが、サンプルを生成することでどんなアクティビティが検出されるか確認できる。 [設定]-[結果サンプルの生成]をクリックすると、サンプル結果が生成される。 サンプル結果詳細まですべて理解する必要はなく、インシデント発生時に確認すればよい。 GuardDutyで検出できる結果の見方については以下を参照。 （サンプル内容についてはあとで書けたら書く。） 4.検出結果のフィルタリング 結果についてはフィルタ機能があり、特定のインスタンスやVPCについて絞り込んで表示することができる。 今回は重要度低のサンプルに絞って表示してみる。 12/102件の検出結果に絞れた。 検出結果を調査したのち、大きな問題ではないと判断できたら、その検出結果をアーカイブすることができる。 アーカイブした検出結果は[アーカイブ済み]から閲覧できる。 検出結果をエクスポートすることもできる。フィルタして必要な検出結果を表示・選択し、JSON形式でエクスポートする。 GuardDutyを有効化してから30日間は無料で使用できる。この30日間の間は料金がかからないが、どれくらいのコストがかかるかの情報は収集してくれていて、以下の[使用状況]画面で確認できるので、無料利用期間の間にどれくらいのコストがかかるか試算できる。 5.GuardDuty の停止と無効化 5-1.GuardDuty の停止 [設定]から GuardDuty の停止ができる。GuardDuty の停止はモニタリングが停止するだけで、既存の検出結果はそのまま残る。 [停止]をクリックする。 「GuardDuty が停止されています」というメッセージが出る。「再有効化」をクリックして再有効化することもできる。 5-2.GuardDuty の無効化 [設定]から GuardDuty の無効化ができる。GuardDuty の無効化は既存の検出結果もすべて消えてなくなる。検出結果のデータが必要な場合は、S3 バケットへのエクスポートを有効化しておくか、マネジメントコンソール画面上からエクスポートしておく。 [無効化]をクリックする。 初期画面に戻る。 [今すぐ始める]から再度有効化すると、今までのサンプル検出結果もすべて消えているのがわかる。 6.Organizations の管理アカウントとメンバーアカウントの画面の違い Organizations の管理アカウントでGuardDutyの画面を見ると「委任された管理者」に、GuardDutyの管理を任せる AWS アカウント ID を設定することができる。 Organizations 内のアカウントで、セキュリティ管理のためのアカウントを保持している場合、Organizations 管理アカウントではなくセキュリティ管理アカウントに GuardDuty の管理を任せた方が適切な場合もあるため、マルチアカウントで運用している場合はうまく活用できるとよい。 感想 KMS と S3 の設定部分がやや時間かかる印象です。 参考

WHAT S3 Bucket を ap-northeast-1 に 作成し、CloudFront の Origin に指定し、その CloudFront に WAFv2 の WebACL を assosiate します WHY CDKで構成する場合、下記のような構成をとることがあると思います WAF を先に us-east-1 で作成する ap-northeast-1 に S3 Bucket を作成し、CloudFront の Origin に指定し、さらに WAF を設定する このときに手順の 2 では ap-northeast-1 に S3 Bucket を作成する関係上、CloudFront に渡す WAF の WebACL を us-east-1 から引っ張ってこようとすると cross-region error に引っかかってしまうことがあると思います これを回避するには カスタムリソースを使うパターン や cdk-remote-stack を使うパターン が考えられると思います ただ今回、S3 はリージョンサービスなので CloudFront を us-east-1 からデプロイしてしまえば、この構成に限ってはこれらのパターンを使わずに作れるんじゃないかと思ったのでチャレンジしてみました HOW 説明はかなり省略していきます、あしからず コード上もかなり省略していきます、あしからず まずは index.ts は下記のような感じで bin/index.ts import * as cdk from "aws-cdk-lib"; import { WafStack } from "../lib/waf-stack"; import { S3Stack } from "../lib/s3-stack"; import { WafCloudfrontS3Stack } from "../lib/waf-cloudfront-s3-stack"; const app = new cdk.App(); const bucketName = "xxxxxxxxxxxxxx" const bucket = new S3Stack(app, "S3Bucket", { env: { region: "ap-northeast-1" }, bucketName }); const cloudFrontWebACL = new WafStack(app, "CloudFrontWebACL", { env: { region: "us-east-1" }, }); new WafCloudfrontS3Stack(app, "WAFCloudFrontS3", { env: { region: "us-east-1" }, bucketName, webAclArn: cloudFrontWebACL.webACL.attrArn, }); 次に WafCloudfrontS3Stack だけ示すと lib/waf-cloudfront-s3-stack.ts import { aws_cloudfront, aws_iam, aws_s3, Stack, StackProps } from 'aws-cdk-lib'; import { Construct } from 'constructs'; export type Props = StackProps & { bucketName: string; webAclArn: string; }; export class WafCloudfrontS3Stack extends Stack { constructor(scope: Construct, id: string, props: Props) { super(scope, id, props); const { bucketName, webAclArn } = props; const originAccessIdentity = new aws_cloudfront.OriginAccessIdentity(this, "OriginAccessIdentity",{ comment: `OIA for ${bucketName}`, }); const bucket = aws_s3.Bucket.fromBucketAttributes(this, "bucket", { bucketName, region: "ap-northeast-1", }); // See: https://github.com/aws/aws-cdk/issues/941 const policyStatement = new aws_iam.PolicyStatement(); policyStatement.addActions("s3:GetBucket*"); policyStatement.addActions("s3:GetObject*"); policyStatement.addActions("s3:List*"); policyStatement.addResources(bucket.bucketArn); policyStatement.addResources(`${bucket.bucketArn}/*`); policyStatement.addCanonicalUserPrincipal( originAccessIdentity.cloudFrontOriginAccessIdentityS3CanonicalUserId ); const bucketPolicy = new aws_s3.CfnBucketPolicy(this, "cloudfrontAccessBucketPolicy",{ bucket: bucket.bucketName, policyDocument: new aws_iam.PolicyDocument({ statements: [policyStatement], }), }); const distribution = new aws_cloudfront.CloudFrontWebDistribution(this, "Distribution", { webACLId: webAclArn, originConfigs: [{ s3OriginSource: { s3BucketSource: bucket, originAccessIdentity, }, behaviors: [{ isDefaultBehavior: true }], }, ], }); でいけます・・・きっと Point 注意点のようなポイントがいくつかあります aws_s3.Bucket.fromBucketAttributes を使うのがよい これは region: "ap-northeast-1" と region を指定できるからです もし指定しなかった場合 CloudFront に設定される origin は xxxxxxxxxxxxxx.s3-us-east-1.amazonaws.com となります us-east-1 ではダメのかはわかっていませんがコンソールから作成したときに合わせるようにしています IBucket の grantRead は使えない 当初、下記のようなコードでラクをしたかったんですが残念ながら使えず、しかも理由がわからずしばらくハマっておりました const originAccessIdentity = new aws_cloudfront.OriginAccessIdentity(this, "OriginAccessIdentity",{ comment: `OIA for ${bucketName}`, }); const bucket = aws_s3.Bucket.fromBucketAttributes(this, "bucket", { bucketName, region: "ap-northeast-1", }); bucket.grantRead(originAccessIdentity) ですが https://github.com/aws/aws-cdk/issues/6548 にたどりつき、IBucket では無理なことがわかり、また途中のコメントにある aws_s3.CfnBucketPolicy を使うことで BucketPolicy を適用することができました aws_iam.PolicyStatement はもうちょっと違う書き方ができると思います - ex. https://dev.classmethod.jp/articles/i-tried-building-cloudfronts3-static-site-hosting-with-aws-cdk-v2/ が、先に前述の書き方で成功してしまったので、まだ試せていません const webSiteBucketPolicyStatement = new aws_iam.PolicyStatement({ actions: ['s3:GetObject'], effect: aws_iam.Effect.ALLOW, principals: [ new aws_iam.CanonicalUserPrincipal( originAccessIdentity.cloudFrontOriginAccessIdentityS3CanonicalUserId ), ], resources: [`${websiteBucket.bucketArn}/*`], }); 以上となります 他に Route53 や Certificate Manager との組み合わせも試さなければ、のちほど

WHAT S3 Bucket を ap-northeast-1 に 作成し、CloudFront の Origin に指定し、その CloudFront に WAFv2 の WebACL を assosiate します WHY CDKで構成する場合、下記のような構成をとることがあると思います WAF を先に us-east-1 で作成する ap-northeast-1 に S3 Bucket を作成し、CloudFront の Origin に指定し、さらに WAF を設定する このときに手順の 2 では ap-northeast-1 に S3 Bucket を作成する関係上、CloudFront に渡す WAF の WebACL を us-east-1 から引っ張ってこようとすると cross-region error に引っかかってしまうことがあると思います これを回避するには カスタムリソースを使うパターン や cdk-remote-stack を使うパターン が考えられると思います ただ今回、S3 はリージョンサービスなので CloudFront を us-east-1 からデプロイしてしまえば、この構成に限ってはこれらのパターンを使わずに作れるんじゃないかと思ったのでチャレンジしてみました HOW 説明はかなり省略していきます、あしからず コード上もかなり省略していきます、あしからず まずは index.ts は下記のような感じで bin/index.ts import * as cdk from "aws-cdk-lib"; import { WafStack } from "../lib/waf-stack"; import { S3Stack } from "../lib/s3-stack"; import { WafCloudfrontS3Stack } from "../lib/waf-cloudfront-s3-stack"; const app = new cdk.App(); const bucketName = "xxxxxxxxxxxxxx" const bucket = new S3Stack(app, "S3Bucket", { env: { region: "ap-northeast-1" }, bucketName }); const cloudFrontWebACL = new WafStack(app, "CloudFrontWebACL", { env: { region: "us-east-1" }, }); new WafCloudfrontS3Stack(app, "WAFCloudFrontS3", { env: { region: "us-east-1" }, bucketName, webAclArn: cloudFrontWebACL.webACL.attrArn, }); 次に WafCloudfrontS3Stack だけ示すと lib/waf-cloudfront-s3-stack.ts import { aws_cloudfront, aws_iam, aws_s3, Stack, StackProps } from 'aws-cdk-lib'; import { Construct } from 'constructs'; export type Props = StackProps & { bucketName: string; webAclArn: string; }; export class WafCloudfrontS3Stack extends Stack { constructor(scope: Construct, id: string, props: Props) { super(scope, id, props); const { bucketName, webAclArn } = props; const originAccessIdentity = new aws_cloudfront.OriginAccessIdentity(this, "OriginAccessIdentity",{ comment: `OIA for ${bucketName}`, }); const bucket = aws_s3.Bucket.fromBucketAttributes(this, "bucket", { bucketName, region: "ap-northeast-1", }); // See: https://github.com/aws/aws-cdk/issues/941 const policyStatement = new aws_iam.PolicyStatement(); policyStatement.addActions("s3:GetBucket*"); policyStatement.addActions("s3:GetObject*"); policyStatement.addActions("s3:List*"); policyStatement.addResources(bucket.bucketArn); policyStatement.addResources(`${bucket.bucketArn}/*`); policyStatement.addCanonicalUserPrincipal( originAccessIdentity.cloudFrontOriginAccessIdentityS3CanonicalUserId ); const bucketPolicy = new aws_s3.CfnBucketPolicy(this, "cloudfrontAccessBucketPolicy",{ bucket: bucket.bucketName, policyDocument: new aws_iam.PolicyDocument({ statements: [policyStatement], }), }); const distribution = new aws_cloudfront.CloudFrontWebDistribution(this, "Distribution", { webACLId: webAclArn, originConfigs: [{ s3OriginSource: { s3BucketSource: bucket, originAccessIdentity, }, behaviors: [{ isDefaultBehavior: true }], }, ], }); でいけます・・・きっと Point 注意点のようなポイントがいくつかあります aws_s3.Bucket.fromBucketAttributes を使うのがよい これは region: "ap-northeast-1" と region を指定できるからです もし指定しなかった場合 CloudFront に設定される origin は xxxxxxxxxxxxxx.s3-us-east-1.amazonaws.com となります us-east-1 ではダメのかはわかっていませんがコンソールから作成したときに合わせるようにしています IBucket の grantRead は使えない 当初、下記のようなコードでラクをしたかったんですが残念ながら使えず、しかも理由がわからずしばらくハマっておりました const originAccessIdentity = new aws_cloudfront.OriginAccessIdentity(this, "OriginAccessIdentity",{ comment: `OIA for ${bucketName}`, }); const bucket = aws_s3.Bucket.fromBucketAttributes(this, "bucket", { bucketName, region: "ap-northeast-1", }); bucket.grantRead(originAccessIdentity) ですが https://github.com/aws/aws-cdk/issues/6548 にたどりつき、IBucket では無理なことがわかり、また途中のコメントにある aws_s3.CfnBucketPolicy を使うことで BucketPolicy を適用することができました aws_iam.PolicyStatement はもうちょっと違う書き方ができると思います - ex. https://dev.classmethod.jp/articles/i-tried-building-cloudfronts3-static-site-hosting-with-aws-cdk-v2/ が、先に前述の書き方で成功してしまったので、まだ試せていません const webSiteBucketPolicyStatement = new aws_iam.PolicyStatement({ actions: ['s3:GetObject'], effect: aws_iam.Effect.ALLOW, principals: [ new aws_iam.CanonicalUserPrincipal( originAccessIdentity.cloudFrontOriginAccessIdentityS3CanonicalUserId ), ], resources: [`${websiteBucket.bucketArn}/*`], }); 以上となります 他に Route53 や Certificate Manager との組み合わせも試さなければ、のちほど

背景 Laravelで作成したポートフォリオのAWSデプロイに苦労していた時、MENTAにて@adachin0817さんよりお声がけいただき、インフラ構築のフォローをしていただきました。 以下のプランよりフォローしていただきました。 構築過程 まず最初に開発環境構築に使用すたDockerの設定があまりよろしくなかったので、 開発環境の再構築から始めました。 (本番環境と設定を合わせる目的もあります) 開発環境 開発環境にはDockerを使用しています Docker 20.10.12 Docker Compose v2.2.3 Docker image laravel-app(appコンテナ) php7.4-fpm-alpine(nginx,php-fpm,supervisor) Laravel 6.20.34 laravel-db(mysqlコンテナ) MySQL 8.0.27 以下構成図です。 具体的な構成、構築内容は以下の記事にまとめました。 【Docker+Laravel6】開発環境構築についてまとめてみました 本番環境 本番環境はAWSを使用し、CircleCIで自動デプロイを可能にしています AWS：EC2, RDS, VPC, Route 53, ALB, ACM, S3, CloudWatch EC2 : nginx, php-fpm RDS : mysql 8.0.27 CircleCI deploy job : git pullデプロイ自動化 slack orb : Slackデプロイ結果通知 　 以下構成図です。 具体的な構成、構築内容は以下の記事にまとめました。 【AWS＋Laravel】本番環境構築についてまとめてみました 身についたこと Docker, AWSのインフラの構造とCircleCIの設定・操作の理解 構成を理解し構成図として表記できる能力 公式ドキュメントを軸に、あらゆる記事を読み、最適な実装方法を導き出せる能力 自走力 実装中に意識したこと 後で見返してもわかりやすいように、タグや説明をその都度付け加える。 各サービス同士の繋がりを意識しながら構築していく。 とにかく諦めないこと。 振り返り ちょうど1ヶ月でのデプロイ完了でした。技術力のみならず質問力も鍛えられました。 まだまだ理解不足なところもあるので、普段の学習と実務経験で、もっと対応できる幅を広げていきたいです。 最後に @adachin0817さんのMENTAプランについて紹介します。 初学者が一番悩むであろう構築までのロードマップを速攻で作っていただき、構築完成まで手厚いサポートをしていただきました。 とにかく質問への回答が早く、問題を素早く解決できます。 また、実務レベルのフォローで、メンティー自身が解決までたどり着けるよう導いてくださるので、自走力爆上がりすると思います！ 初学者にとっては決して甘くはないですが、インフラの知識のみならずエンジニアとしての心得を学ぶにおいて、@adachin0817さんのサポートは最高です。 おすすめです！！

背景 Laravelを使用して開発したポートフォリオのデプロイをする目的で、AWSで本番環境を構築しました。 AWSを使用した理由は、インフラの構造をしっかりと理解したかったからと、 実務に入るとプログラミングだけではなく、サーバーやネットワークについての知識も必要だろうと考えたからです。 開発環境構築(Docker＋Laravel6)については以下にまとめました 【Docker+Laravel6メモ】開発環境構築についてまとめてみました 本番環境について AWS：EC2, RDS, VPC, Route 53, ALB, ACM, S3, CloudWatch EC2 : nginx, php-fpm RDS : mysql 8.0.27 CircleCI deploy job : git pullデプロイ自動化 slack orb : Slackデプロイ結果通知 本番環境構成図 構築ロードマップ 順番 手順 1 お名前.comで独自ドメイン取得する 2 お名前.comで取得したドメインをRoute53に登録する 3 VPCを作成する 4 セキュリティーグループを作成する 5 EC2インスタンスを作成する 6 ACMでSSL証明書を発行する 7 ELBを作成する 8 Route53でAレコードのエイリアスを作成する 9 RDSを作成する 10 EC2インスタンスにLaravel環境を構築してアプリのデプロイをする 11 CircleCIを使用した自動デプロイ(執筆中) 12 AWS S3を使用した画像アップロード(執筆中) 構築手順(記事) 1.お名前.comで独自ドメイン取得する 2.お名前.comで取得したドメインをRoute53に登録する 3.VPCを作成する 4.セキュリティーグループを作成する 5.EC2インスタンスを作成する 6.ACMでSSL証明書を発行する 7.ELBを作成する 8.Route53でAレコードのエイリアスを作成する 9.RDSを作成する 10.EC2インスタンスにLaravel環境を構築してアプリのデプロイをする 11.CircleCIを使用した自動デプロイ(執筆中) .... 12.AWS S3を使用した画像アップロード(執筆中) .... 振り返り 今回のAWSの環境構築を通して、Webサービスがどのように運用されているのかを知るキッカケになりました。 インフラ周りの知識を理解するのに、AWSは最適だ思います!! 自分が構築した環境は、コストを考えたシンプルな構造となっているため、おそらく基本の域だと思います。 実務でも通用する技術を身につけるためには、更に深く学んでいく必要があります。 なので、これからもAWSを通じてインフラ周りの知識を磨いていこうと思います！！ 難しいけど、がんばります(笑)

背景 Laravelを使用して開発したポートフォリオのデプロイをする目的で、AWSで本番環境を構築しました。 AWSを使用した理由は、インフラの構造をしっかりと理解したかったからと、 実務に入るとプログラミングだけではなく、サーバーやネットワークについての知識も必要だろうと考えたからです。 (CircleCIについての記事は執筆中です。) 開発環境構築(Docker＋Laravel6)については以下にまとめました 【Docker+Laravel6メモ】開発環境構築についてまとめてみました 本番環境について AWS：EC2, RDS, VPC, Route 53, ALB, ACM, S3, CloudWatch EC2 : nginx, php-fpm RDS : mysql 8.0.27 CircleCI deploy job : git pullデプロイ自動化 slack orb : Slackデプロイ結果通知 本番環境構成図 構築ロードマップ 順番 手順 1 お名前.comで独自ドメイン取得する 2 お名前.comで取得したドメインをRoute53に登録する 3 VPCを作成する 4 セキュリティーグループを作成する 5 EC2インスタンスを作成する 6 ACMでSSL証明書を発行する 7 ELBを作成する 8 Route53でAレコードのエイリアスを作成する 9 RDSを作成する 10 EC2インスタンスにLaravel環境を構築してアプリのデプロイをする 11 CircleCIを使用した自動デプロイ(執筆中) 12 AWS S3を使用した画像アップロード(執筆中) 構築手順(記事) 1.お名前.comで独自ドメイン取得する 2.お名前.comで取得したドメインをRoute53に登録する 3.VPCを作成する 4.セキュリティーグループを作成する 5.EC2インスタンスを作成する 6.ACMでSSL証明書を発行する 7.ELBを作成する 8.Route53でAレコードのエイリアスを作成する 9.RDSを作成する 10.EC2インスタンスにLaravel環境を構築してアプリのデプロイをする 11.CircleCIを使用した自動デプロイ(執筆中) .... 12.AWS S3を使用した画像アップロード(執筆中) .... 振り返り 今回のAWSの環境構築を通して、Webサービスがどのように運用されているのかを知るキッカケになりました。 インフラ周りの知識を理解するのに、AWSは最適だ思います!! 自分が構築した環境は、コストを考えたシンプルな構造となっているため、おそらく基本の域だと思います。 実務でも通用する技術を身につけるためには、更に深く学んでいく必要があります。 なので、これからもAWSを通じてインフラ周りの知識を磨いていこうと思います！！ 難しいけど、がんばります(笑)

概要 AWS EC2インスタンスを久しぶりに作って、初回ログイン時に、忘れていたことを備忘録として記載 前提 EC2インスタンスを作成済みであること ※ OSは、[ubuntu OS]を使用していること。 目次 Ⅰ. 権限設定 Ⅱ. ログイン方法 Ⅰ：権限設定 まず、インスタンス作成した際に、作成した「秘密鍵」の権限の修正が必要です。 権限は「600」でないと「秘密鍵」の権限が広すぎると怒られる。 chmod 600 XXXXXXX.pem Ⅱ：ログイン方法 ssh -i XXXXXXX.pem ubuntu@XX.XXXX.XXX（IPアドレス） ここで注意が必要で、ubuntuで作成した場合は、ユーザー名=ubuntu。 一方、amazon_linuxで作成した場合のユーザー名=ec2-user。 ここら辺は、よく忘れがち！！！ ※CentOSに関しては、分からないので未記載です。ご存知の方、いらっしゃれば教えてください。 終わりに 基本、上記２点さえ、間違わなければスムーズにログインできるかと思います。 他に、ここ躓くよとかあれば、教えてください！！！ 追記したいです。