- 投稿日：2021-01-25T23:47:57+09:00
AWSのリソースを管理しやすくするVantageを試してみた
TechCrunchさんで紹介されていたVantageが気になったので、試してみました。
https://jp.techcrunch.com/2021/01/15/2021-01-12-vantage-makes-managing-aws-easier/AWSを使ってると、インスタンス消し忘れて課金が発生したってことはありませんか？vantageはそんな問題を解消してくれるかもしれないサービスです。
https://www.vantage.sh/Vantageとは
Vantageは以下の画像のように、AWSで作成したリソースの一覧を表示してくれるサービスです。複数のリージョンをまとめて表示してくれて、1か月あたりのコストも出してくれます。サポートしているサービスとリージョンはここに載っています。
これはfreeプランの画面ですが、有料だとCloudwatch LogやCloudwatch Metricsをいい感じに出してくれるみたいです。
ひとつひとつの項目はViewと呼ばれていて、自分で作成することもできます。
Topで「Create View」をクリックすると以下の画面でViewを作成できます。「Custom View」ではリソースごとに条件を指定したViewを作成できますし、「View from Tag」ではTagを指定したViewを作成できます。
アタッチされていないEBSや空のS3を表示するといったあらかじめ用意されているViewも追加できます。
「Custom View」は以下のように、表示するリソースの条件を指定します。
このように、VantageはAWSのリソースとコストをいい感じに管理できるサービスです。
導入方法
ここでアカウントを作成します。
https://console.vantage.sh/users/sign_upアカウントを作成すると、以下の画面が出るので「Connect Vantage to AWS」をクリックします。
そうすると、Cloudformationスタックの作成画面に移動するので、「スタックの作成」を押します。これはクロスアカウントアクセス用のIAMロールを作成します。付与される権限の一覧は以下のページに書いてます。
https://docs.vantage.sh/permissions/
設定はこれだけです。あとは以下の画面で「Continue」を押せば使えるようになります！
Viewは1時間に1回、自動で更新されます。また、右上の更新ボタンで更新もできます。
まとめ
今回は、AWSのリソースを管理しやすくするVantageを試してみました。
設定内容をいろいろと取得されるので、セキュリティ的に大丈夫かなという不安はありますが、readOnlyなのでたぶん大丈夫なんじゃないかと思います。（自己責任）
今後、Viewをシェアする機能やアラートを送る機能などがいろいろ追加されるようです。
気になった方は試してみてもよいかと思います。
- 投稿日：2021-01-25T23:34:58+09:00
RDS から オンプレミスの MySQL へレプリケーションをしてみる
はじめに
RDS for MySQL からオンプレミスの仮想マシンに準備した MySQL へレプリケーションを組む手順を備忘録として残しておきます。
前提
レプリケーション元 : RDS 5.7.31
レプリケーション先 : オンプレミス(Oracle Cloudで準備) : MySQL 8.0.23 : CentOS 7
VPC と オンプレミスは、site-to-site VPN で接続済みReplica : MySQL の構成
次の URL を参考に、適当に MySQL をインストールします。この記事では、8.0.23 を使っています。
https://qiita.com/sugimount/items/bf44904db8201d377536Replica : GTID Mode を有効
8.0.23 の Default では、gtid_mode が OFF になっている。Replication のために、ON へ変更
mysql> show variables like '%gtid%'; +----------------------------------+-----------+ | Variable_name | Value | +----------------------------------+-----------+ | binlog_gtid_simple_recovery | ON | | enforce_gtid_consistency | OFF | | gtid_executed | | | gtid_executed_compression_period | 0 | | gtid_mode | OFF | | gtid_next | AUTOMATIC | | gtid_owned | | | gtid_purged | | | session_track_gtids | OFF | +----------------------------------+-----------+ 9 rows in set (0.01 sec) mysql>編集
sudo vim /etc/my.cnf追記
[mysqld] ... 省略 ... log-bin server-id=100 log-slave-updates gtid-mode=ON enforce-gtid-consistency=true再起動
sudo systemctl restart mysqld有効化されている
mysql> show variables like '%gtid%'; +----------------------------------+-----------+ | Variable_name | Value | +----------------------------------+-----------+ | binlog_gtid_simple_recovery | ON | | enforce_gtid_consistency | ON | | gtid_executed | | | gtid_executed_compression_period | 0 | | gtid_mode | ON | | gtid_next | AUTOMATIC | | gtid_owned | | | gtid_purged | | | session_track_gtids | OFF | +----------------------------------+-----------+ 9 rows in set (0.00 sec) mysql>Source : レプリケーションユーザーの設定
ユーザー作成
CREATE USER rpluser@'%' IDENTIFIED BY 'Rpl001#!';REPLICATION SLAVE の権限付与
GRANT REPLICATION SLAVE on *.* to rpluser@'%';Source : Dump ファイルを Export
RDS に MySQL Shell を使って接続
mysqlsh admin@rds-source01.comulzzpkhpz.ap-northeast-1.rds.amazonaws.comdumpInstance を使って、Oracle Cloud の Object Storage にダンプファイルを出力します。出力先は、ローカルのファイルシステム上にも指定可能です。
util.dumpInstance("RDStoOnpremis4", {osBucketName: "mysqldump", osNamespace: "nrefeaanptgn", threads: 4, ocimds: true, compatibility: ["strip_restricted_grants"]})実行例
MySQL rds-source01.comulzzpkhpz.ap-northeast-1.rds.amazonaws.com:3306 ssl JS > util.dumpInstance("RDStoMDS1", {osBucketName: "mysqldump", osNamespace: "nrefeaanptgn", threads: 4, ocimds: true, compatibility: ["strip_restricted_grants"]}) Acquiring global read lock NOTE: Error acquiring global read lock: MySQL Error 1045 (28000): Access denied for user 'admin'@'%' (using password: YES) WARNING: The current user lacks privileges to acquire a global read lock using 'FLUSH TABLES WITH READ LOCK'. Falling back to LOCK TABLES... Locking instance for backup NOTE: Backup lock is not supported in MySQL 5.7 and DDL changes will not be blocked. The dump may fail with an error or not be completely consistent if schema changes are made while dumping. Table locks acquired Gathering information - done All transactions have been started WARNING: The dumped value of gtid_executed is not guaranteed to be consistent Global read lock has been released Checking for compatibility with MySQL Database Service 8.0.23 NOTE: MySQL Server 5.7 detected, please consider upgrading to 8.0 first. You can check for potential upgrade issues using util.checkForServerUpgrade(). NOTE: User 'admin'@'%' had restricted privilege (RELOAD) removed NOTE: User 'rdsadmin'@'localhost' had restricted privileges (CREATE TABLESPACE, FILE, RELOAD, SHUTDOWN, SUPER) removed Compatibility issues with MySQL Database Service 8.0.23 were found and repaired. Please review the changes made before loading them. Writing global DDL files Writing users DDL Running data dump using 4 threads. NOTE: Progress information uses estimated values and may not be accurate. Writing DDL for schema `innodb` Writing DDL for schema `sugitest` ?% (0 rows / ?), 0.00 rows/s, 0.00 B/s uncompressed, 0.00 B/s compressed Duration: 00:00:01s Schemas dumped: 2 Tables dumped: 0 Uncompressed data size: 0 bytes Compressed data size: 0 bytes Compression ratio: 0.0 Rows written: 0 Bytes written: 0 bytes Average uncompressed throughput: 0.00 B/s Average compressed throughput: 0.00 B/s MySQL rds-source01.comulzzpkhpz.ap-northeast-1.rds.amazonaws.com:3306 ssl JS >Object Storageに出力されている
Replica : Dumpfile を Import
Replica 先で local_infile が ON である必要あり
mysql> show variables like '%LOCAL_INFILE%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | local_infile | OFF | +---------------+-------+ 1 row in set (0.00 sec) mysql>編集
sudo vim /etc/my.cnf編集
[mysqld] 省略 local_infile=1再起動
sudo systemctl restart mysqld確認
mysql> show variables like '%LOCAL_INFILE%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | local_infile | ON | +---------------+-------+ 1 row in set (0.00 sec) mysql>MySQL Shell で接続
mysqlsh sugi01@10.0.0.5Dumpfile を Import
util.loadDump("RDStoOnpremis4", {osBucketName: "mysqldump", osNamespace: "nrefeaanptgn", threads: 4, ignoreVersion: true})実行例
MySQL 10.0.0.3:33060+ ssl JS > util.loadDump("RDStoOnpremis1", {osBucketName: "mysqldump", osNamespace: "nrefeaanptgn", threads: 4, ignoreVersion: true}) Loading DDL and Data from OCI ObjectStorage bucket=mysqldump, prefix='RDStoOnpremis1' using 4 threads. Opening dump... Target is MySQL 8.0.23. Dump was produced from MySQL 5.7.31-log WARNING: Destination MySQL version is newer than the one where the dump was created. Loading dumps from different major MySQL versions is not fully supported and may not work. The 'ignoreVersion' option is enabled, so loading anyway. Fetching dump data from remote location... Fetching 0 table metadata files for schema `innodb`... Fetching 0 table metadata files for schema `sugitest`... Checking for pre-existing objects... Executing common preamble SQL Executing DDL script for schema `innodb` Executing DDL script for schema `sugitest` Executing common postamble SQL No data loaded. 0 warnings were reported during the load. MySQL 10.0.0.3:33060+ ssl JS >GTID の状態を確認
mysql> show global variables like 'GTID%'; +----------------------------------+------------------------------------------+ | Variable_name | Value | +----------------------------------+------------------------------------------+ | gtid_executed | b6efa169-5f17-11eb-9d5b-02001700c965:1-4 | | gtid_executed_compression_period | 0 | | gtid_mode | ON | | gtid_owned | | | gtid_purged | | +----------------------------------+------------------------------------------+ 5 rows in set (0.01 sec) mysql>Source 側で実行済みの GTID を、Replica 側に反映していく。現状は何もなし。
mysql> select @@gtid_purged; +---------------+ | @@gtid_purged | +---------------+ | | +---------------+ 1 row in set (0.00 sec) mysql>Object Stoarge に出力された Dumpfile 群に、
@.jsonのメタデータあり
JSON ファイルの中身はこんな感じです。
gtidExecutedをメモっておきます。{ "dumper": "mysqlsh Ver 8.0.23 for Linux on x86_64 - for MySQL 8.0.23 (MySQL Community Server (GPL))", "version": "1.0.2", "origin": "dumpInstance", "schemas": [ "sugitest", "innodb" ], "basenames": { "sugitest": "sugitest", "innodb": "innodb" }, "users": [ "'admin'@'%'", "'rdsadmin'@'localhost'", "'rpluser001'@'%'", "'rpluser002'@'%'" ], "defaultCharacterSet": "utf8mb4", "tzUtc": true, "bytesPerChunk": 64000000, "user": "admin", "hostname": "onprem-server02", "server": "ip-172-23-2-162", "serverVersion": "5.7.31-log", "gtidExecuted": "90710e1c-f699-11ea-85c0-0ec6a6bed381:1-99", "gtidExecutedInconsistent": true, "consistent": true, "mdsCompatibility": true, "begin": "2021-01-25 14:17:39" }gtid_purged で、先ほどメモった値を入れます
SET global gtid_purged='90710e1c-f699-11ea-85c0-0ec6a6bed381:1-99';確認
mysql> select @@gtid_purged; +-------------------------------------------+ | @@gtid_purged | +-------------------------------------------+ | 90710e1c-f699-11ea-85c0-0ec6a6bed381:1-99 | +-------------------------------------------+ 1 row in set (0.00 sec) mysql>Replica : レプリケーションの設定
RDS特有テーブルも、オンプレミス側の MySQL へ作成しないとエラーになります
CREATE TABLE mysql.rds_heartbeat2 ( `id` int(11) NOT NULL, `value` bigint(20) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;RDS を Master として定義します
CHANGE MASTER TO MASTER_HOST='rds-source01.comulzzpkhpz.ap-northeast-1.rds.amazonaws.com', MASTER_PORT=3306, MASTER_USER='rpluser', MASTER_PASSWORD='Rpl001#!';レプリケーション開始
mysql> START SLAVE; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql>memo : 停止
STOP SLAVE; RESET MASTER;確認
mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: rds-source01.comulzzpkhpz.ap-northeast-1.rds.amazonaws.com Master_User: rpluser Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin-changelog.000090 Read_Master_Log_Pos: 991 Relay_Log_File: rds-onpremis-replica01-relay-bin.000006 Relay_Log_Pos: 1226 Relay_Master_Log_File: mysql-bin-changelog.000090 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 991 Relay_Log_Space: 1549 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1329226068 Master_UUID: 90710e1c-f699-11ea-85c0-0ec6a6bed381 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 90710e1c-f699-11ea-85c0-0ec6a6bed381:97-102 Executed_Gtid_Set: 90710e1c-f699-11ea-85c0-0ec6a6bed381:1-102, b6efa169-5f17-11eb-9d5b-02001700c965:1-5 Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: Master_public_key_path: Get_master_public_key: 0 Network_Namespace: 1 row in set, 1 warning (0.00 sec) mysql>レプリケーションの確認
Source で Table を作ります。
use sugitest; CREATE TABLE sample( id INT(11) NOT NULL AUTO_INCREMENT, value INT(5) NOT NULL DEFAULT 0, PRIMARY KEY (id) ); INSERT INTO sample(value) VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);Replica 側で確認。無事にレプリケーションされています。
mysql> select * from sugitest.sample; +----+-------+ | id | value | +----+-------+ | 1 | 1 | | 2 | 2 | | 3 | 3 | | 4 | 4 | | 5 | 5 | | 6 | 6 | | 7 | 7 | | 8 | 8 | | 9 | 9 | | 10 | 10 | +----+-------+ 10 rows in set (0.00 sec) mysql>参考URL
Amazon RDS for MySQL のアクティブ DB インスタンスのバイナリログを使用して、オンプレミスのスタンバイインスタンスにレプリケートするにはどうすればよいですか?
https://aws.amazon.com/jp/premiumsupport/knowledge-center/replicate-amazon-rds-mysql-on-premises/NAT越しにMySQLでレプリケーションすると接続が切れる
http://sarahetmoi.take-uma.net/mysql/nat%E8%B6%8A%E3%81%97%E3%81%ABmysql%E3%81%A7%E3%83%AC%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%99%E3%82%8B%E3%81%A8%E6%8E%A5%E7%B6%9A%E3%81%8C%E5%88%87%E3%82%8C%E3%82%8BMySQL 5.7 GTID レプリケーション設定メモ
https://blog.apar.jp/linux/6725/#toc8
- 投稿日：2021-01-25T22:44:58+09:00
【初心者向け】クラウドサービスの概要一覧(AWS, GCPの違い)
クラウドサービスの勉強にあたり、名前を聞いただけではどんな機能か想像がつかない…
…ということで、代表的なクラウドサービスであるAWS(Amazon Web Service)とGCP(Google Cloud Platform)で提供されている機能について、一覧表を作って概要を知ることにしました。
機能概要 AWS GCP メモ アカウント管理・アクセス制御 IAM
(Identity and Access Management）IAM
(Identity and Access Management)AWSもGCPも呼び名や機能概要は同じ ストレージ S3
(Simple Strage Service)GCS
(Google Cloud Strage)ファイルを保存できる 仮想マシン EC2
(Elastic Compute Cloud)GCE
(Google Compute Engine)仮想サーバ。AWSで出てくるElasticは「伸縮自在」の意。柔軟に性能や台数を変えられる。 ロードバランサ ELB
(Elastic Load Balancing)CLB
(Cloud Load Balancinge)複数仮想マシンを使用する場合の負荷分散 サーバ不要のプログラム実行環境 laｍbda GAE
(Google App Engine)得意な言語で関数を実行できる データベース
(RDB)RDS
(Relational Database Service)Cloud SQL MySQL,PostgreSQL,SQL ServerなどRDBMSを利用可能 NoSQL DynamoDB Cloud Bigtable NoSQLなので複雑な検索には向かないほうのデータベース リソース監視 CloudWatch Monitoring CPU使用率とかモニタリングできる ログ収集 CloudWatch Logs Logging ログを収集して閲覧できる AWS・GCPそれぞれ似た機能があるので、片方に慣れれば応用が効きそうですね。
他にもたくさん機能があるので、適宜追加しようと思います。
- 投稿日：2021-01-25T15:41:07+09:00
aws入門―Linuxサーバ環境構築、teratermで接続
一、先ず、AWS簡単に紹介します。
awsはamazon web service。簡単に言うと、前はAPとDBサーバのハードウェアはマシン室に構築します。今回はamzonのクラウドサービスを利用します。下記のURLを参照してください。
https://aws.amazon.com/jp/getting-started/fundamentals-overview/?e=gs2020&p=gsrc二、amazonのサーバ環境を構築してみます。
①amozonのアカウントを作成必要です。無料作成しますが、クレジットカードが必要です。ご注意ください。
サーバ作成後、起動時間より、費用がかかるかもしれません。使わない場合、サーバを停止したほがいいです。
アカウント作成は下記のURLを参照してください。
https://aws.amazon.com/jp/register-flow/②VPC環境構築
VPCとは：
Amazon Virtual Private Cloud (Amazon VPC) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークによく似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。VPC の主な概念は次のとおりです。
•Virtual Private Cloud (VPC) — AWS アカウント専用の仮想ネットワーク。
•サブネット — VPC の IP アドレスの範囲。
•ルートテーブル — ネットワークトラフィックの経路を判断する際に使用される、ルートと呼ばれる一連のルール。
•インターネットゲートウェイ — VPC 内のリソースとインターネット間の通信を可能にするために VPC にアタッチするゲートウェイ。
•VPC エンドポイント — PrivateLink を使用してサポートされている AWS のサービスや VPC エンドポイントサービスに VPC をプライベートに接続できます。
VPCについて、下記のURLを参照してください。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/what-is-amazon-vpc.html
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/how-it-works.html③手順：
下図とおり、VPCを開く
VPC new をクリックし、VPC作成クリック
下図とおり入力して、vpc作成ボタン押下
サブネット作成
下図とおり入力して、サブネット作成ボタン押下
※subnet作成するとき、vpc idは前回作成したVPCIDを選択する
作成後下記とおり
②ec2インスタンス作成
今回Red Hat例として作成する
注意、無料対象を選択してください。
次のステップ：インスタンスの詳細の設定ボタンを押すと、下記の画面を表示する。
下記とおり入力してください。
次のステップ：ストレージの追加ボタン押下、ディフォルト設定でいいです。
次のステップ：タグの追加
次のステップ：セキュリティグループの設定
確認と作成ボタン押下
起動ボタン押下
キーベアのダウンロードボタン押下、インスタンスの作成ボタン押下
起動済み（インスタンス newクリック、刷新）
VPC gateway作成
インターネットゲートウェイのアタッチボタン押下
ルートテーブル編集
ルート編集押下、自分のターゲット選択
ルートの保存
ここまで、teratermでサーバに接続できした。
ユーザ：ec2-user
パスワード：ec2-user
キーペア：ダウンロードされたもの
IP：下図のページにあり
IPアドレスはec2⇒インスタンス⇒自分のインスタンスIDリンククリック
- 投稿日：2021-01-25T13:58:29+09:00
SAMとCodePipelineでサーバーレスのCI/CDを構築する
AWSのSAMとCodePipelineを使用して、サーバーレス環境でのCI/CDを構築していきます。CodePipelineはCloudFormationは使用せずマネジメントコンソールから作成していきます。
全体像
以下のような構成でパイプラインを構築していきます。
出典：Amazon Web Services ブログ構築手順
前提
- SAMで必要なコードはgitにプッシュ済み（template.ymlとLambdaのソースコード）
- CloudFormationによるスタックは新規作成済み
上記を前提とし、templateやソースコードをgitにプッシュした際に自動でデプロイまで行ってくれる仕組みを構築していきます。なお全体像で引用している画像にはSource、Build、Deployのステージが定義されていますが、その記載の通りに説明していきます。
パイプラインの新規作成（Source〜Buildまで）
CodePipelineの初期画面から「パイプラインの作成」をスタート。
パイプラインの設定はお好きな名前をつけて次へ。
ソースステージの選択は、ご自身で使用するものを入力して次へ。
ビルドステージを追加します。プロバイダーは「AWS CodeBuild」を選択し、「プロジェクトを作成する」で新たに作成します。
CodeBuildで新たにプロジェクトを作成していきます。プロジェクト名はお好きなものを入力いただいたのち、環境を設定していきます。CodeBuildはビルドのたびに新規Dockerコンテナで実行されるため、そのコンテナのイメージを設定します。今回は以下のように設定しました。
サービスロールも既存のものではなく、今回新たに作成しました。
Buildspecに関して、「buildspecファイルを使用する」を選択した場合は、gitリポジトリにbuildspec.ymlをプッシュしておきます。CodeBuildではこのファイルの記載に則って処理を実行してくれます。今回は以下のようなシンプルな形にしています。s3-bucketはご自身のものを指定してください。buildspec.ymlversion: 0.2 phases: install: runtime-versions: python: 3.8 build: commands: - sam package --template-file template.yml --s3-bucket your-bucket-name --output-template-file packaged-template.yml artifacts: files: - packaged-template.ymlCodeBuildの入力が完了したら、CodePipelineの入力画面に戻るので次に進んだのち、デプロイステージの入力では「導入段階はスキップ」し、一度パイプラインの作成を完了します。デプロイステージは後で設定します。
これでパイプラインが実行されますが、CodeBuildのサービスロールを新たに作成した場合は、おそらく「Build」のステージで失敗します。これは作成されたサービスロールではアーティファクト格納先のS3バケットへのアクセス権がないためなので、IAMロールの画面からアクセスできるように修正してあげてください。パイプラインにDeployステージを追加
これまででS3バケットにパッケージの格納まではできているので、これをデプロイしていきます。デプロイはCloudFormationのchange setを使用して行います。簡単に言うと、前回との差分セットを作成してそれを実行することでスタック更新を行うといった流れです。なので「Change setを生成する」アクションと「Change setを実行する」アクションを定義していきます。
作成したパイプラインの画面から「編集」を選択し、一番下の「ステージを追加する」ボタンを押してDeployステージを追加していきます。「アクショングループを追加する」を押下し、以下のように入力します。「入力アーティファクト」はBuildステージで出力アーティファクトに設定したものを選択。
「スタック名」はすでに作成済みのスタックを選択、「セット名を変更する」はお好きな名前を設定、「テンプレート」の「アーティファクト名」はさきほど追加したもの、「ファイル名」はbuildspec.ymlのartifactsで記載した名称。今回の例だと「packaged-template.yml」です。「能力-オプショナル」では「CAPABILITY_IAM」を追加、「ロール名」はCloudFormationのサービスロールを選択します。なければIAM画面で要作成です。
これでChange setの生成は完了です。次にChange setの実行をするためのアクションを定義します。もう一度「アクショングループを追加する」を押下し、以下のように入力します。
これで完了です。あとはソースに何かしらの変更をしてgitにプッシュすればデプロイされるはずです。さいごに
いろいろ入力してパイプラインを構築してきましたが、実はCodeStarを使えば一瞬で作成されます。ですが、環境を分けるためにブランチごとにパイプラインを作りたいと思い、自分で構築してみた次第です。
- 投稿日：2021-01-25T12:53:27+09:00
AWS Certified Database - Specialty 合格記録
この記事
AWS Advanced Database Specialty を取得したので
学習内容や感想を記録します。about me
インフラエンジニア
AWS関連のインフラ構築や保守を４年ほど経験しています。Database自体の知識が少ないため、AWSといえど心配でした。
これまでのAWS資格は以下の流れで取得しました。
2019 Solution Architect Associate （7月） SysOps Administrator Associate (9月) Solution Architect Professional (11月) Developer Associate (12月) 2020 DevOps Engineer Professional (3月) Security Specialty（5月） Advanced Networking(10月) 2021 Database Specialty（1月）about DBS試験
AWS 認定 データベース – 専門知識
https://aws.amazon.com/jp/certification/certified-database-specialty/試験対策でやったこと
試験ガイドとサンプル問題
まずは、どんな内容の問題が出るのか目を通します。
上記リンクの「試験ガイド」「サンプル問題」推奨されるAWS の知識
一般的なデータベーステクノロジーを使用した4年以上の経験。私の場合、ここが最も不安でした。。
AWS公式ドキュメントによる対策
ElastiCache、DocumentDB、Neptuneなどあまり使ったことのないDBサービスがあったり
AuroraなどSolution Architectの範囲でも合った部分の復習をしたかったので毎度おなじみ、こちらで学習しました。
https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
※Databases 分野すべて他に、アーキテクチャはこちらを参考に
https://aws.amazon.com/jp/architecture/
※リファレンスアーキテクチャ「データベース」内Udemy
問題集は主にUdemyです。色々漁りました。
様々な問題に慣れる & 不足分の知識を補うというメインの作業です。不足していた知識
学習の前半、主に個人的に知識が不足していた(忘れていたものも多い)のは、以下の様なものでした。
・各DBサービスのバックアップの方法は？制限は？
・MultiAZの有無でどう変わる？どのように動作している？
・監査、セキュリティ対策は具体的にどんなオプションあったっけ？
・復元するのは具体的にどうやるの？SAPやDOPを取得してから期間も空いていたので、復習作業は半分くらいを占めていたかも。
たまたま学習中にDB移行なんかもやってたので、良い機会でした。
やはり実際に動かすのがベストですねまた、Database自体の知識も最低限は抑えようとしました。
用語の復習などですが。。データ制御（Control） DCL = GRANT, REVOKE, BEGIN, COMMIT, ROLLBACK データ定義（Definition） DDL = CREATE, DROP, ALTER データ操作（Manipulation） DML = SELECT, INSERT, UPDATE, DELETETips
問題集やって感じたのが
分野2: 展開および移行
自分はこの分野が苦手ということでした。
例えば移行要件があった時、時間やコストをかければ手段は複数ありますが、
ベストプラクティスはどれか？という選択が、知識不足だと躓きます。
消去法で２つ残って、そこで悩んでしまう。。Professionalまでの試験だと、DBサービスの詳細まで聞かれないかも知れないですが、
今回はDatabaseの試験なので隈無くチェックしておいたほうが良いと思います。
問題集やってて、わからなかった点はリストしておき、自分のノートを作ると捗ります。また、AWSの試験ですので、データベース自体に詳しい方でも
まずはAWSの各DBサービスの違いやそれぞれのメリットからしっかり理解されることをおすすめします。
データベース自体の知識が必要というよりもAWSDBサービスの知識が必要でした。
Networkの試験も同様です。結果&まとめ
今回は特に試験が難しく、後半「これは危ういな…」という気持ちでしたがギリギリ合格できました。
あとはいつもの試験日のルーティンに助けられました。
試験対策としての学習時間は、40時間程度でした。
場合によっては英語で解いたほうがわかりやすいこともあるので、そちらもおすすめです。因みに
分野2: 展開および移行
試験結果もこの分野だけは再学習が必要という内容でした(笑)
あちこち要復習ですね。次の試験
Data Analytics Specialtyを取ります。
分野的にも続けて取るべきだなと感じたからです。この記事が何かのお役に立てられれば幸いです。
戦いの記録
SAA
https://qiita.com/shinon_uk/items/5525178bf98034676b2fSOP
https://qiita.com/shinon_uk/items/e60bcb946b49bf5cabdaSAP
・勝利編
https://qiita.com/shinon_uk/items/c6b599d1cd3000e84d59
・敗走編（資料集め）
https://qiita.com/shinon_uk/items/ba839ba048ba439cc3ffDVA
https://qiita.com/shinon_uk/items/8015953c792ef4bc7223DOP
https://qiita.com/shinon_uk/items/5646d536e649b60b962a
- 投稿日：2021-01-25T11:03:02+09:00
AWS CLIの設定（WindowMs
AWS CLIを設定する。
AWS CLIでS3のリスト、アップロード、ダウンロードをしたい。インストール
公式ガイド：https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-install.html
AWS CLI Version2であれば以下からインストーラをダウンロードできる。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-windows.html↓入った。
構成
（なければ）アクセスキーとシークレットキーを作成する。
ペアは最大2個なので、すでに2個あれば新規作成はできない。
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]: text※Default output formatはjson, table, textから選べる。
確認
S3のファイルがリストできるか試してみる。（s3 URI）には自分がアクセスできるS3 BucketのURIを入れる。
aws s3 ls （s3 URI）ファイルがリストされていればOK。
- 投稿日：2021-01-25T11:03:02+09:00
AWS CLIの設定（Windows）
AWS CLIを設定する。
AWS CLIでS3のリスト、アップロード、ダウンロードをしたい。インストール
公式ガイド：https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-install.html
AWS CLI Version2であれば以下からインストーラをダウンロードできる。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-windows.html↓入った。
構成
（なければ）アクセスキーとシークレットキーを作成する。
ペアは最大2個なので、すでに2個あれば新規作成はできない。
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]: text※Default output formatはjson, table, textから選べる。
確認
S3のファイルがリストできるか試してみる。（s3 URI）には自分がアクセスできるS3 BucketのURIを入れる。
aws s3 ls （s3 URI）ファイルがリストされていればOK。
- 投稿日：2021-01-25T10:37:46+09:00
amplify-authenticator のサインアップを無効化する方法メモ
はじめに
ユーザーの登録は管理者側で行いたいので、amplify-authenticator(@aws-amplify/ui-vue) のサインアップリンクを無効化しようとしてハマったのでメモを残す。
isSignUpDisplayed: falseを食わせれば良いという記事はたくさんあるが、
肝心の食わせ方がまちまちでなかなか適用することができなかった。結論
<template> <amplify-authenticator> <amplify-sign-in slot="sign-in" hide-sign-up="true"></amplify-sign-in> <amplify-sign-out></amplify-sign-out> </amplify-authenticator> </template>
amplify-sign-inにslot="sign-in" hide-sign-up="true"を渡すことで無効化できた。参考リンク
- 投稿日：2021-01-25T07:05:54+09:00
ECSでタスクが起動しない場合に確認すべきこと
タスク起動に失敗する原因は主に下記ですが、ここでは上記２つに関する事象に対応するための確認事項を記載していこうと思います。
- ネットワークエラー
- IAM権限不足
- リソース不足
もし、ECSを利用してみたが、タスクが起動しなくて困っているなどあれば、下記の内容を見て実際の環境で確認してみてほしい。
まず、エラーの確認
なにはともあれ、起動しなかったタスクのエラーログを確認しましょう。
停止されたタスクでのエラーの確認 - Amazon Elastic Container Service
ここに下記のメッセージが出ている場合は、デプロイしたアプリケーションが正常に動作していない可能性が高いです。
- Essential container in task exited
- Task failed ELB health checks
この場合、タスクは一度起動したが、アプリが落ちた or アプリのヘルスチェックが失敗しているので、アプリのログやLBのヘルスチェックの設定を確認しましょう。
これ以外の理由が記載されている場合は、下記に記載している内容が原因であることが多いです。
1. ECRやS3へアクセス可能か
ECSのタスク起動時には、指定されたコンテナイメージのPullを実行しています。そのため、イメージが格納されているリポジトリへのアクセス可能である必要があります。
イメージがPullできない状態でタスクを起動した場合、
CannotPullContainerのエラーが発生し、タスクの起動に失敗します。CannotPullContainer task errors - Amazon Elastic Container Service
もし、上記のエラーが発生した場合は下記リソースの確認を行うと良いです。
- Public IP
- Internet Gateway
- Route Table
- Security Group
- Nat Gateway
- NACL
ECRにイメージが格納されている場合は下記も確認しましょう。
- VPC Endpoint
- IAM Role
DockerHubなどにイメージが格納されている場合
DockerHubなどの外部レジストリにイメージが存在する場合は、基本的にはそのレジストリへ通信できる環境があればよいです。（プライベートレジストリを利用しているパターンは、後に記載）
もしエラーが出ている場合は、インスタンスがインターネットへアクセス可能かどうか確認する必要があります。
※EC2インスタンスを利用している場合は、パブリックIPが付与できないパターンがあるので注意（下記参照）
ステップ 2: ネットワークの設定 - Amazon ECS
もし、DockerHubなどでプライベートリポジトリにイメージが格納されている場合、下記ドキュメントに従って認証を実施できるようにしないといけません。
タスクのプライベートレジストリの認証 - Amazon Elastic Container Service
ECRにイメージが格納されている場合
ECRにイメージが格納されている場合、「タスク実行ロール」に、ECRに対してPullする権限が必要となります。
また、実際にイメージが格納されているS3バケット（arn:aws:s3:::prod-<REGION>-starport-layer-bucket/*）にもアクセス可能である必要があります。さらに、VPC Endpointを構築しており、通信をVPCに閉じている場合は、下記2つのリソースに対して通信可能かどうか確認する必要があります。
- ECR (イメージが格納されているリポジトリ)
- S3 (
arn:aws:s3:::prod-**<REGION>**-starport-layer-bucket/*)というわけで、下記の流れで確認しておくと良いです。
よくやりがちなのが、S3バケットへのアクセスをVPC Endpointのポリシーで制限してしまっているパターンなので要確認。
Amazon ECR インターフェイス VPC エンドポイント (AWS PrivateLink) - Amazon ECR
もし、上記で説明したエラーではなく、
ResourceInitializationErrorが発生している場合は、この後の2つを確認してみると良いです。2. CloudWatch Logsへの権限はあるか
ECSでコンテナのログをCloudWatchに転送しようとした場合、一般的にはawslogsを用います。（※S3やElasticSearchに直接転送したいなどの要件があればFirelensなどを利用）
awslogsはデフォルトではロググループを新規作成することは無いですが、これでは不便なのでオプションを指定してロググループを自動生成させる事がよくあります。
この場合、「タスク実行ロール」には
CreateLogGroupの権限が必要です。
上記の権限が存在しない場合は、ResourceInitializationErrorが発生するので、もしこのエラーが発生していたら見直してみると良いです。awslogs ログドライバーを使用する - Amazon Elastic Container Service
なお、「タスク実行ロール」に一般的に付与するポリシーである
AmazonECSTaskExecutionRolePolicyには上記の権限は入っていないので、このエラーは発生しがち。。また、LogsのVPC Endpointを構築している場合は、もちろんアクセス可能な設定になっているか確認する必要があります。
3. KMS, SSM, SecretsManagerへの権限はあるか
ECSのタスクに機密情報などを環境変数を介して渡す場合、Systems ManagerのParameterStoreやSecrets Managerを用います。
これらを用いる場合も「タスク実行ロール」に追加で権限が必要になります。詳しくはリンク先のドキュメントを参照してください。
こちらも、権限不足の場合、
ResourceInitializationErrorが発生します。Systems Manager パラメータストアを使用した機密データの指定 - Amazon ECS
Secrets Manager を使用した機密データの指定 - Amazon Elastic Container Service繰り返し書いているが、こちらもVPC Endpointを構築している場合は、アクセス可能か確認する必要があります。
その他
もし上記を確認したが、解決しない or エラーメッセージが違うなどの場合は、下記のドキュメントを確認しましょう。トラブルシューティングの際に確認すべき事項がまとまっています。
Amazon ECS のトラブルシューティング - Amazon Elastic Container Service
※こちらの記事はnoteにも投稿しています。
ECSでタスクが起動しない場合に確認すべきこと
- 投稿日：2021-01-25T01:19:59+09:00
Amazon SNSでSMSする時のPolicy設定
「AWS LambdaからSMSを送りたい」と思い、こちらの記事「【AWS】Lambda+Amazon SNSでSMSを送信する - Qiita」を参考に実装していました。Lambdaへの権限を絞る時に少しつまづいたのでメモに残します。 結論を先に載せますと、こちらのStackOverflowの記事「Authorization when sending a text message using AmazonSNSClient - StackOverflow」を参考に解決しました。 つまづいたところ SMSの送信にはAmazon SNSサービスのsns:Publish 権限を利用します。 しかし、この権限にはリソースの指定が必要です。 以下のような「全てのリソースへのアクセスを許可する」ポリシーを作れば解決しますが、これではアカウント・リージョンを絞らないまま、今回使わないSNSトピックに手が届いてしまいます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sns:Publish" ], "Resource": "*" } ] } では、「SMS用のトピックを作ればいい」、という話になります。これが可能な場合はもちろんそうすれば良いですが、今回はサブスクライブ先の電話番号を管理したくありませんでしたのでその方法は取りませんでした。 解決方法 以下のように、まず ・「全てのアカウント・リージョンのトピック」に対するPublish権限を拒否 した後、 ・全てのリソースへのPublish権限を許可 することで解決しました。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "sns:Publish" ], "Resource": "arn:aws:sns:*:*:*" }, { "Effect": "Allow", "Action": [ "sns:Publish" ], "Resource": "*" } ] } おまけ：電話番号が固定の場合（未検証） 「特定の電話番号に対し許可」する場合は、エラーメッセージから推測するに、以下の方法でできるのではないかな、と思います（未検証です）。 以下では、日本国内電話番号のみ許可しています。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sns:Publish" ], "Resource": "+81*" } ] } おまけ：CDK CDK（TypeScript）ではこんな風に書きました。 Node.js： 14.15.4 CDK： 1.50.0 // 関数 public static createSMSPublishRoleStatement(): PolicyStatement[] { // SNSトピックリソースへのPublishを全面禁止 const denyPolicy: PolicyStatement = new PolicyStatement({ effect: Effect.DENY, actions: ["sns:Publish"], resources: ["arn:aws:sns:*:*:*"], }); // 電話番号でPublishできるよう許可 const allowPolicy: PolicyStatement = new PolicyStatement({ effect: Effect.ALLOW, actions: ["sns:Publish"], resources: ["*"], }); return [denyPolicy, allowPolicy]; } public static addPolicyStatementsToLambda( lambdaFunc: LambdaFunction /*(Function as LambdaFunction)*/, policyStatements: PolicyStatement[] ): void { policyStatements.forEach((policyStatement: PolicyStatement) => { lambdaFunc.addToRolePolicy(policyStatement); }); } // 実行 const smsPublishPolicyStatements: PolicyStatement[] = createSMSPublishRoleStatement(); addPolicyStatementsToLambda( ${"ポリシーを紐付けたいLambda"}, smsPublishPolicyStatements.concat([ ${"他のポリシーステートメント"}, ]) );
- 投稿日：2021-01-25T00:44:35+09:00
VyOS で site-to-site VPN をしてみた
はじめに
site-to-site VPN を使うことで、オンプレミスネットワークと VPC 間でセキュアな接続が出来ます。今回は、ソフトウェアルーターの VyOS を使って、site-to-site VPN の手順を紹介します。
NW構成図
オンプレミス (10.0.0.0/16) と AWS VPC (10.1.0.0/16) 間で、VPN を設定します。
図の中の Public IP は既に削除しているので、アクセスできません
オンプレミス側に、VyOS を作成
適当にオンプレミス側でVyOS の仮想マシンを作成します。詳細は Google さんに聞いてみましょう。
Customer Gateway を作成
AWS側で、VyOS に対応する Customer Gateway を作成します
Create
VyOS の Public IP などを指定して、Create します
作成完了
Virtual Private Gateway 作成
今回の記事では、Virtual Private Gateway を作成します。Transit Gateway でも大丈夫です。
Create
Attach to VPC
Yes, Attach
State が attached に変わります
Route Table の設定
Site-to-Site VPN のルートを自動的に Route Table に伝搬(Route Propagation) できます。対象の Route Table を選択して、Edit route propagation を押します。
作成した Virtual Private Gateway を選択を選択して、Save を押します
この段階では、まだ ルート伝搬されません
Site-to-Site VPN Connection を作成
Create
Create
Pending になります。available に一定時間後変わります
オンプレミス側 : VyOS の設定
VyOS の設定テンプレートは、AWS マネージメントコンソールからダウンロードできます。
Download Configuration
Download
VyOS に SSH 接続して、configure mode に変更
vyos@vyos:~$ configure [edit] vyos@vyos#この記事の環境では、ダウンロードした config ファイルから、一部変更が必要です。次の
local-addressの部分が、Customer Gateway の Public IP から、Private IP に変更します。# before set vpn ipsec site-to-site peer 3.115.81.204 local-address '168.138.206.122' set vpn ipsec site-to-site peer 35.72.50.96 local-address '168.138.206.122' # after set vpn ipsec site-to-site peer 3.115.81.204 local-address '10.0.0.2' set vpn ipsec site-to-site peer 35.72.50.96 local-address '10.0.0.2'変更した設定ファイルの内容を投入したのちに、設定を保存します。config ファイルの内容は、精査して問題なさそうか確認してください。
commit save2 つのトンネル Status が UP になる
AWS VPC の CIDR 全体が、オンプレミスのルーター側に広告されています。
10.1.0.0/16の Next Hop が表示されています。vyos@vyos:~$ show ip bgp BGP table version is 1, local router ID is 10.0.0.2, vrf id 0 Default local pref 100, local AS 65000 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 10.1.0.0/16 169.254.31.89 200 0 64512 i * *> 169.254.43.37 100 0 64512 i Displayed 1 routes and 2 total paths vyos@vyos:~$Next Hop に Ping 可能
vyos@vyos:~$ ping 169.254.31.89 PING 169.254.31.89 (169.254.31.89) 56(84) bytes of data. 64 bytes from 169.254.31.89: icmp_seq=1 ttl=254 time=3.34 ms 64 bytes from 169.254.31.89: icmp_seq=2 ttl=254 time=3.28 ms ^C --- 169.254.31.89 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 3.286/3.314/3.342/0.028 ms vyos@vyos:~$ vyos@vyos:~$ ping 169.254.43.37 PING 169.254.43.37 (169.254.43.37) 56(84) bytes of data. 64 bytes from 169.254.43.37: icmp_seq=1 ttl=254 time=4.11 ms 64 bytes from 169.254.43.37: icmp_seq=2 ttl=254 time=3.94 ms 64 bytes from 169.254.43.37: icmp_seq=3 ttl=254 time=4.11 ms ^C --- 169.254.43.37 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 3.944/4.056/4.112/0.079 ms vyos@vyos:~$VyOS のルーティングテーブルにも、正常に VPC の CIDR が反映されています
vyos@vyos:~$ ip route show default via 10.0.0.1 dev eth0 proto static metric 20 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.2 10.1.0.0/16 via 169.254.43.37 dev vti1 proto bgp metric 20 169.254.31.88/30 dev vti0 proto kernel scope link src 169.254.31.90 169.254.43.36/30 dev vti1 proto kernel scope link src 169.254.43.38 vyos@vyos:~$オンプレミス側のネットワークを AWS 側に広告する設定をいれます
set protocols bgp 65000 address-family ipv4-unicast network 10.0.0.0/16 commit save設定を入れたタイミングで、AWS の Route Table に、オンプレミス側のネットワークが自動的に伝搬されています
通信確認
OnPremis → AWS Ping
[opc@onprem-server01 ~]$ ping 10.1.1.166 PING 10.1.1.166 (10.1.1.166) 56(84) bytes of data. 64 bytes from 10.1.1.166: icmp_seq=1 ttl=253 time=7.27 ms 64 bytes from 10.1.1.166: icmp_seq=2 ttl=253 time=7.00 ms 64 bytes from 10.1.1.166: icmp_seq=3 ttl=253 time=6.87 ms ^C --- 10.1.1.166 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 6.871/7.049/7.270/0.165 ms [opc@onprem-server01 ~]$OnPremis → AWS SSH
[opc@onprem-server01 ~]$ ssh ec2-user@10.1.1.166 Last login: Sun Jan 24 14:14:24 2021 from 10.0.0.3 __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ 2 package(s) needed for security, out of 5 available Run "sudo yum update" to apply all updates. [ec2-user@ip-10-1-1-166 ~]$付録 : VyOS の Configure
この記事で動作確認したもの。VPN Connection は既に削除しているので、セキュリティ的に問題なし
! Amazon Web Services ! Virtual Private Cloud ! AWS utilizes unique identifiers to manipulate the configuration of ! a VPN Connection. Each VPN Connection is assigned an identifier and is ! associated with two other identifiers, namely the ! Customer Gateway Identifier and Virtual Private Gateway Identifier. ! ! Your VPN Connection ID : vpn-0d8baa48b752adf7d ! Your Virtual Private Gateway ID : vgw-0fa95229cd24be685 ! Your Customer Gateway ID : cgw-06e4f9cce27959659 ! ! ! This configuration consists of two tunnels. Both tunnels must be ! configured on your Customer Gateway. ! ! -------------------------------------------------------------------------------- ! IPSec Tunnel #1 ! -------------------------------------------------------------------------------- ! #1: Internet Key Exchange (IKE) Configuration ! ! A policy is established for the supported ISAKMP encryption, ! authentication, Diffie-Hellman, lifetime, and key parameters. ! Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2. ! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14. ! You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24. ! NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels. ! ! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic". ! The address of the external interface for your customer gateway must be a static address. ! Your customer gateway may reside behind a device performing network address translation (NAT). ! To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500. If not behind NAT, we recommend disabling NAT-T. ! set vpn ipsec ike-group AWS lifetime '28800' set vpn ipsec ike-group AWS proposal 1 dh-group '2' set vpn ipsec ike-group AWS proposal 1 encryption 'aes128' set vpn ipsec ike-group AWS proposal 1 hash 'sha1' set vpn ipsec site-to-site peer 3.115.81.204 authentication mode 'pre-shared-secret' set vpn ipsec site-to-site peer 3.115.81.204 authentication pre-shared-secret 'your secret1' set vpn ipsec site-to-site peer 3.115.81.204 description 'VPC tunnel 1' set vpn ipsec site-to-site peer 3.115.81.204 ike-group 'AWS' set vpn ipsec site-to-site peer 3.115.81.204 local-address '10.0.0.2' set vpn ipsec site-to-site peer 3.115.81.204 vti bind 'vti0' set vpn ipsec site-to-site peer 3.115.81.204 vti esp-group 'AWS' ! #2: IPSec Configuration ! ! The IPSec (Phase 2) proposal defines the protocol, authentication, ! encryption, and lifetime parameters for our IPSec security association. ! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14. ! Please note, you may use these additionally supported IPSec parameters for encryption like AES256 and other DH groups like 2, 5, 14-18, 22, 23, and 24. ! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic". ! set vpn ipsec ipsec-interfaces interface 'eth0' set vpn ipsec esp-group AWS compression 'disable' set vpn ipsec esp-group AWS lifetime '3600' set vpn ipsec esp-group AWS mode 'tunnel' set vpn ipsec esp-group AWS pfs 'enable' set vpn ipsec esp-group AWS proposal 1 encryption 'aes128' set vpn ipsec esp-group AWS proposal 1 hash 'sha1' ! This option enables IPSec Dead Peer Detection, which causes periodic ! messages to be sent to ensure a Security Association remains operational. ! set vpn ipsec ike-group AWS dead-peer-detection action 'restart' set vpn ipsec ike-group AWS dead-peer-detection interval '15' set vpn ipsec ike-group AWS dead-peer-detection timeout '30' ! -------------------------------------------------------------------------------- ! #3: Tunnel Interface Configuration ! ! The tunnel interface is configured with the internal IP address. set interfaces vti vti0 address '169.254.31.90/30' set interfaces vti vti0 description 'VPC tunnel 1' set interfaces vti vti0 mtu '1436' ! -------------------------------------------------------------------------------- ! #4: Border Gateway Protocol (BGP) Configuration ! ! BGP is used within the tunnel to exchange prefixes between the ! Virtual Private Gateway and your Customer Gateway. The Virtual Private Gateway ! will announce the prefix corresponding to your VPC. ! ! Your Customer Gateway may announce a default route (0.0.0.0/0), ! which can be done with the 'network' statement. ! ! The BGP timers are adjusted to provide more rapid detection of outages. ! ! The local BGP Autonomous System Number (ASN) (65000) is configured ! as part of your Customer Gateway. If the ASN must be changed, the ! Customer Gateway and VPN Connection will need to be recreated with AWS. ! set protocols bgp 65000 neighbor 169.254.31.89 remote-as '64512' set protocols bgp 65000 neighbor 169.254.31.89 soft-reconfiguration 'inbound' set protocols bgp 65000 neighbor 169.254.31.89 timers holdtime '30' set protocols bgp 65000 neighbor 169.254.31.89 timers keepalive '10' ! To advertise additional prefixes to Amazon VPC, replace the 0.0.0.0/0 from the ! the following line with the prefix you wish to advertise. Make sure the prefix is present ! in the routing table of the device with a valid next-hop. set protocols bgp 65000 network 0.0.0.0/0 ! -------------------------------------------------------------------------------- ! IPSec Tunnel #2 ! -------------------------------------------------------------------------------- ! #1: Internet Key Exchange (IKE) Configuration ! ! A policy is established for the supported ISAKMP encryption, ! authentication, Diffie-Hellman, lifetime, and key parameters. ! Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2. ! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14. ! You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24. ! NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels. ! ! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic". ! The address of the external interface for your customer gateway must be a static address. ! Your customer gateway may reside behind a device performing network address translation (NAT). ! To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500. If not behind NAT, we recommend disabling NAT-T. ! set vpn ipsec ike-group AWS lifetime '28800' set vpn ipsec ike-group AWS proposal 1 dh-group '2' set vpn ipsec ike-group AWS proposal 1 encryption 'aes128' set vpn ipsec ike-group AWS proposal 1 hash 'sha1' set vpn ipsec site-to-site peer 35.72.50.96 authentication mode 'pre-shared-secret' set vpn ipsec site-to-site peer 35.72.50.96 authentication pre-shared-secret 'your secret2' set vpn ipsec site-to-site peer 35.72.50.96 description 'VPC tunnel 2' set vpn ipsec site-to-site peer 35.72.50.96 ike-group 'AWS' set vpn ipsec site-to-site peer 35.72.50.96 local-address '10.0.0.2' set vpn ipsec site-to-site peer 35.72.50.96 vti bind 'vti1' set vpn ipsec site-to-site peer 35.72.50.96 vti esp-group 'AWS' ! #2: IPSec Configuration ! ! The IPSec (Phase 2) proposal defines the protocol, authentication, ! encryption, and lifetime parameters for our IPSec security association. ! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14. ! Please note, you may use these additionally supported IPSec parameters for encryption like AES256 and other DH groups like 2, 5, 14-18, 22, 23, and 24. ! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic". ! set vpn ipsec ipsec-interfaces interface 'eth0' set vpn ipsec esp-group AWS compression 'disable' set vpn ipsec esp-group AWS lifetime '3600' set vpn ipsec esp-group AWS mode 'tunnel' set vpn ipsec esp-group AWS pfs 'enable' set vpn ipsec esp-group AWS proposal 1 encryption 'aes128' set vpn ipsec esp-group AWS proposal 1 hash 'sha1' ! This option enables IPSec Dead Peer Detection, which causes periodic ! messages to be sent to ensure a Security Association remains operational. ! set vpn ipsec ike-group AWS dead-peer-detection action 'restart' set vpn ipsec ike-group AWS dead-peer-detection interval '15' set vpn ipsec ike-group AWS dead-peer-detection timeout '30' ! -------------------------------------------------------------------------------- ! #3: Tunnel Interface Configuration ! ! The tunnel interface is configured with the internal IP address. set interfaces vti vti1 address '169.254.43.38/30' set interfaces vti vti1 description 'VPC tunnel 2' set interfaces vti vti1 mtu '1436' ! -------------------------------------------------------------------------------- ! #4: Border Gateway Protocol (BGP) Configuration ! ! BGP is used within the tunnel to exchange prefixes between the ! Virtual Private Gateway and your Customer Gateway. The Virtual Private Gateway ! will announce the prefix corresponding to your VPC. ! ! Your Customer Gateway may announce a default route (0.0.0.0/0), ! which can be done with the 'network' statement. ! ! The BGP timers are adjusted to provide more rapid detection of outages. ! ! The local BGP Autonomous System Number (ASN) (65000) is configured ! as part of your Customer Gateway. If the ASN must be changed, the ! Customer Gateway and VPN Connection will need to be recreated with AWS. ! set protocols bgp 65000 neighbor 169.254.43.37 remote-as '64512' set protocols bgp 65000 neighbor 169.254.43.37 soft-reconfiguration 'inbound' set protocols bgp 65000 neighbor 169.254.43.37 timers holdtime '30' set protocols bgp 65000 neighbor 169.254.43.37 timers keepalive '10' ! To advertise additional prefixes to Amazon VPC, replace the 0.0.0.0/0 from the ! the following line with the prefix you wish to advertise. Make sure the prefix is present ! in the routing table of the device with a valid next-hop. set protocols bgp 65000 network 0.0.0.0/0 ! Additional Notes and Questions ! - Amazon Virtual Private Cloud Getting Started Guide: ! http://docs.amazonwebservices.com/AmazonVPC/latest/GettingStartedGuide ! - Amazon Virtual Private Cloud Network Administrator Guide: ! http://docs.amazonwebservices.com/AmazonVPC/latest/NetworkAdminGuide ! - XSL Version: 2009-07-15-1119716参考URL
AWS Site-to-Site VPN とは
https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/VPC_VPN.htmlAmazon Virtual Private Cloud ネットワーク管理者ガイド (Amzon でテスト済みの Customer Gateway Device あり)
https://docs.aws.amazon.com/ja_jp/vpc/latest/adminguide/vpc-nag.pdf
- 投稿日：2021-01-25T00:09:27+09:00
VPCピアリングを設定してみた
VPCピアリングのおさらい
VPCピアリングとは
異なるVPCを接続することができます。
CIDRブロックの重複や異なるリージョン間でのVPCピアリングはIPv6非対応です。構成図
今回構築する構成図はこちらになります。
10.0.0.0/16 と 192.168.0.0/24 の構成図があります。
こちらをVPCピアリング設定して内部のインスタンス同士でping接続出来るか確認してみます。
構築しながら書いてるので、順序がバラバラでわかりにくくてすみません
構築
VPC・subnetの構築 : 10.0.0.0/16
- VPCの作成します
VPC > VPCでこの画面になります
- 10.0.0系のVPCの構築
名前とIPv4 CIDRのブロックだけ変更しています
- VPCが構築できました
- subnet構築します
VPC > サブネットから構築します
- subnetの設定を行います
VPC IDは、↑で作ったVPC IDを打ち込みます。
サブネット名はわかりやすいように記載。
またIPv4 CIDRブロックはVPCの範囲フルフルに使っています
- subnet構築できました
VPC・subnetの構築 : 192.168.0.0/24
- VPCの作成します
こちらも10.0.0系と同じように構築
- 192.168系のVPCの構築
- VPCが構築できました
- subnet構築します
- subnetの設定を行います
こちらも↑で作った、192.168系のVPC IDを打ち込みます。
IPv4 CIDRも同じようにフルフルでVPCの範囲と同じように使います。
- subnet構築できました
ここで、10.0.0.0/16 と 192.168.0.0/24 のVPCとサブネットは完成しました。
EC2インスタンスの構築 : 10.0.0.0/16
- EC2インスタンスの構築を行います
EC2 > インスタンス でEC2インスタンスの構築をしていきます。
- AMIの設定
確認用のインスタンスなので適当なのを選びます。
- インスタンスタイプの設定
- インスタンスの詳細設定
以下をここでは変更します
ネットワーク : 10.0.0系VPCを選択 サブネット : 10.0.0系subnet を選択 自動割り当てパブリックIP : 有効
- ストレージの設定
終了したときにストレージも一緒に消えるように
終了時に削除にチェックを入れます。
- セキュリティグループの設定
セキュリティグループは新しいのを作成します。
中身は一旦自分のPCのIPアドレスを開けておきます。
※後で追加します
- 最終確認
- キーペアの作成
ここでは今回用に
qiita_vpc_testというキーペアを作成します。
192.168.0.0/24 のサーバにも同じキーペアを選択するので、キーペアは無くさないようにしてください
- 構築完了
EC2インスタンスの構築 : 192.168.0.0/24
- EC2インスタンスの構築を行います
10.0.0.0/16 のサーバと同じように構築していきます
- AMIの設定
- インスタンスタイプの設定
- インスタンスの詳細設定
こちらも以下を変更します
ネットワーク : 192.168系VPC サブネット : 192.168系subnet 自動割り当てパブリックIP : 有効
- ストレージの設定
同じように
終了時に削除にチェックを入れます。
- セキュリティグループの設定
10.0.0.0/16 のサーバと同じようにセキュリティグループを作ります。
同じセキュリティグループ名ですが、VPCが違うので中身はかぶりません。
今回も自分のPCのIPアドレスだけ設定しておきます。
- 最終確認
- キーペアの作成
先ほど作成したキーペアをこちらでも使いますので、既存のキーペアを選択します。
管理がややこしいのでこの対処にしていますが、実際は別のキーペアの方が望ましいです。
- 構築完了
VPCピアリング設定
- VPCピアリングの作成
VPCが構築できたので、VPCピアリングの設定を行います。
VPC > ピアリング接続 でこの画面に来れます。
ここからピアリング接続の作成を行います。
- ピアリング接続の設定
以下を変更しました
ピアリング接続ネームタグ : 10.0.0 to 192.168 (わかりやすければ何でもOK)以下は接続する自分と相手側の設定を行います。
今回はどちらも自分のアカウント内なのでどちらでも良いですが、
別アカウントともピアリング接続は出来るので、その際は自分のローカルVPCを設定してください。ピアリング接続するローカルVPC VPC : 10.0.0系VPC の VPC IDを選択 ピアリング接続するもうひとつのVPCを選択 アカウント : 自分のアカウント リージョン : このリージョン VPC : 192.168系VPC の VPC IDを選択
- ピアリング接続の承認
10.0.0系でピアリング接続の設定を行ったら、192.168系でリクエストの承認を行います。
同じ画面なのでややこしいかもしれませんが、
別アカウントなら勝手にVPCピアリング接続をされないために、相手側の承認が必要になります。
- 設定の完了
相手の承認がされたので、ステータスがアクティブになりました
ルーティングの設定 : 10.0.0.0/16
- ルートテーブルの編集
ルーティングの設定を行います。
- ルートテーブルに192.168.0.0のときの設定を追加
10.0.0系 → 192.168.0.0/24 の際の設定です。
送信先 : 192.168.0.0/24 ターゲット : ピアリング接続(10.0.0 to 192.168) のIDになります。 ※こちらは192.168.0.0/24の際も同じIDを使用します。
- 追加されていることを確認
ルーティングの設定 : 192.168.0.0/24
- ルートテーブルの編集
先ほどと同じように編集を行います。
- ルートテーブルに10.0.0.0のときの設定を追加
192.168.0.0/24 → 10.0.0.0/26 の際の設定です。
送信先 : 10.0.0.0/26 ターゲット : ピアリング接続(10.0.0 to 192.168) のIDになります。 ※こちらは10.0.0.0/26の際も同じIDを使用しました
- 追加されていることを確認
セキュリティグループの変更 : 10.0.0.0/16
- セキュリティグループの変更
次にセキュリティグループの変更を行います。
何をするかというと、EC2インスタンスは今自分のPCからしか接続できないので
192.168系からのアクセスを許可しないと接続できないので、その設定を行います。
- インバウンドルールの変更
今回はガバガバですが、192.168.0.0/24からすべてのトラフィックを許可します。
- 変更完了
許可できました。
セキュリティグループの変更 : 192.168.0.0/24
- セキュリティグループの変更
こちらも10.0.0系からのアクセスを受けれないので、その設定を行います。
- インバウンドルールの変更
同じようにガバガバですが、10.0.0.0/16からのすべてのトラフィックを許可します。
- 変更完了
インターネットゲートウェイを作成・アタッチ・ルートテーブルに追加 : 10.0.0.0/16
ここでEC2インスタンスに接続できなかったので、
インターネットゲートウェイを作ってVPCにアタッチ、
またルートテーブルにデフォルトゲートウェイの宛先をインターネットゲートウェイに設定します。
- インターネットゲートウェイの作成
VPC > インターネットゲートウェイ でインターネットゲートウェイを作成します
- インターネットゲートウェイの設定
名前をわかりやすいように、10.0.0系のインターネットゲートウェイとします
- インターネットゲートウェイの構築完了
- VPCにアタッチ
先程作成したインターネットゲートウェイを10.0.0系VPCにアタッチします
こちらで指定するVPCは 10.0.0系VPCの VPC ID を指定します
- VPCにアタッチ完了
状態がアタッチになったので、アタッチできました。
- ルートテーブルの変更
アタッチしただけでは使えないので、ルートテーブルでデフォルトゲートウェイはインターネットゲートウェイを向くようにします。
- デフォルトゲートウェイにインターネットゲートウェイを追加
以下を追加します
送信先 : 0.0.0.0/0 ターゲット : 10.0.0系のインターネットゲートウェイ の インターネットゲートウェイIDを指定
- 追加されたことを確認
こちらで、10.0.0.0/16でもなく・192.168.0.0/24 でもないときはインターネットゲートウェイを向くようになりました。
インターネットゲートウェイを作成・アタッチ・ルートテーブルに追加 : 192.168.0.0/24
- インターネットゲートウェイの作成
↑と同じように、インターネットゲートウェイを作ってVPCにアタッチしていきます。
- インターネットゲートウェイの設定
こちらも同じように 192.168系のインターネットゲートウェイとしました
- インターネットゲートウェイの構築完了
- VPCにアタッチ
192.168系VPCにアタッチします
指定するのは 192.168系VPCの VPC ID をここで指定します
- VPCにアタッチ完了
こちらもアタッチできました。
- ルートテーブルの変更
まだ使えないので、ルートテーブルに追加していきます。
- デフォルトゲートウェイにインターネットゲートウェイを追加
送信先 : 0.0.0.0/0 ターゲット : 192.168系のインターネットゲートウェイ の インターネットゲートウェイIDを指定こちらを追加することで、 192.168.0.0/24でもなく・10.0.0.0/16でもないときはインターネットゲートウェイを向くようになりました
- 追加されたことを確認
接続試してみる : 10.0.0.0/16
- ログイン
10.0.0系のEC2インスタンスにログインします
ssh -i .ssh/qiita_vpc_test centos@[グローバルIP]
- IPアドレスの確認
プライベートIPは
10.0.46.97でした[root@ip-10-0-46-97 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000 link/ether 06:62:35:d9:24:48 brd ff:ff:ff:ff:ff:ff inet 10.0.46.97/16 brd 10.0.255.255 scope global dynamic eth0 valid_lft 3183sec preferred_lft 3183sec inet6 fe80::462:35ff:fed9:2448/64 scope link valid_lft forever preferred_lft forever10.0.0系のサーバであることを確認できました
- 192.168系のサーバにpingを飛ばしてみる
192.168系のEC2インスタンスのプライベートIPアドレスは
192.168.0.254[root@ip-10-0-46-97 ~]# ping 192.168.0.254 PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data. 64 bytes from 192.168.0.254: icmp_seq=1 ttl=64 time=1.90 ms 64 bytes from 192.168.0.254: icmp_seq=2 ttl=64 time=1.93 ms 64 bytes from 192.168.0.254: icmp_seq=3 ttl=64 time=1.94 ms ^C --- 192.168.0.254 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 1.902/1.926/1.940/0.053 ms接続できました！
接続試してみる : 192.168.0.0/24
- ログイン
ssh -i .ssh/qiita_vpc_test centos@[グローバルIP]
- IPアドレスの確認
こちらも192.168.0.254 であることを確認できました
[root@ip-192-168-0-254 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000 link/ether 0a:f3:76:a2:ed:38 brd ff:ff:ff:ff:ff:ff inet 192.168.0.254/24 brd 192.168.0.255 scope global dynamic eth0 valid_lft 3067sec preferred_lft 3067sec inet6 fe80::8f3:76ff:fea2:ed38/64 scope link valid_lft forever preferred_lft forever192.168系のサーバであることを確認できました
- 10.0.0系のサーバにpingを飛ばしてみる
10.0系のEC2インスタンスのプライベートIPアドレスは
10.0.46.97[root@ip-192-168-0-254 ~]# ping 10.0.46.97 PING 10.0.46.97 (10.0.46.97) 56(84) bytes of data. 64 bytes from 10.0.46.97: icmp_seq=1 ttl=64 time=2.15 ms 64 bytes from 10.0.46.97: icmp_seq=2 ttl=64 time=1.98 ms 64 bytes from 10.0.46.97: icmp_seq=3 ttl=64 time=1.96 ms ^C --- 10.0.46.97 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 1.966/2.034/2.153/0.084 ms接続できました！
結局の構成図
EC2の名前とか変更したものを修正しています。
IPアドレスは当初書いてあったものとは変更しています。
元々のイメージとしては良かったのですが、VPC諸々の設定が足りていなかった印象です。
この手順で良くないところ
- 10.0.0系と記載していますが/16 なので、10.0系です。
- EC2インスタンスはピアリング接続している相手側のサーバからのアクセスは許可されているが、自分のVPC内のサーバ(2つ以上ある場合は)からはアクセスは許可されていない
- セキュリティグループガバガバ。pingだけならICMPでよかったかな
- 最初に構成図にIPアドレス書いてあったけど、プライベートIPをスタティック設定ではないので勝手に割り振られる
勉強後イメージ
実際のVPCピアリングの設定としては、
結構わかりやすいしすぐ出来る。
ただ、今回はどっちかというとただ単にVPC周りの設定で躓いたので変な順序になっちゃった。
↑にも書きましたが、良くないところを書いてて見つけましたので記載してます。
今回はピアリング接続を確認するためだけなので適当に作ってしまいました....
力尽きたので、今回はここまでにします。参考
- 投稿日：2021-01-25T00:05:08+09:00
AWSのDescribeAvailablePatchesを使ってみた
【執筆中】コードとかきれいにしてないけど現時点のメモ書きを載せておく
とりあえずセキュリティのパッチを取得してみるpublic static async Task<string> SayHelloAsync([ActivityTrigger] string name, ILogger log) { //log.LogInformation($"Saying hello to {name}."); var ssmClient = AwsSsmService.GetClient(); // Windows Server 2019 var request = new DescribeAvailablePatchesRequest(); var productFilter = new PatchOrchestratorFilter(); productFilter.Key = "PRODUCT"; productFilter.Values.Add("WindowsServer2019"); request.Filters.Add(productFilter); var classificationFilter = new PatchOrchestratorFilter(); classificationFilter.Key = "CLASSIFICATION"; classificationFilter.Values.Add("SecurityUpdates"); request.Filters.Add(classificationFilter); try { var response = await ssmClient.DescribeAvailablePatchesAsync(request); string nextToken = null; var patches = new List<Patch>(); int productCount = 0; int repositoryCount = 0; int savedProductCount = 0; int savedRepositoryCount = 0; if (response.HttpStatusCode == HttpStatusCode.OK) { do { Thread.Sleep(500); nextToken = response.NextToken; patches.AddRange(response.Patches); var platformList = patches.Select(r => r.Product).Distinct(); productCount = platformList.Count(); var repositoryList = patches.Select(r => r.Repository).Distinct(); repositoryCount = repositoryList.Count(); } while (nextToken != null); } else { // Error var code = response.HttpStatusCode; } // 2021/01のパッチだけ取得 var date = new DateTime(2021, 1, 1, 0, 0, 0, 0); var currentPatches = patches.Where(r => r.ReleaseDate > date).ToList(); var temp = string.Empty; return $"Hello {name}!"; } catch (Exception ex) { var message = ex.Message; throw; } }
- 投稿日：2021-01-25T00:02:59+09:00
Access Analyzerを全リージョンで有効化してみた
はじめに
Access Analyzerは、外部エンティティと共有されているリソースを検出しますので、意図しない公開設定がないか可視化でき、セキュリティに役立ちます。
グローバルサービスだと思っていましたがリージョン別サービスだったので、CloudFormationでまとめて有効化を目指します。
なお、利用は無料です。Access Analyzer有効化（コンソール）
右上のリージョン名をご覧いただければ分かる通り、グローバルではなく
東京と記載されていることが分かります。
IAMのコンソールにあるのでグローバルだと思ってしまうかもしれませんが、リージョン別サービスです。
対象リージョンは現在選択しているリージョンに固定されます。
アナライザーを作成すると、自動的にサービスにリンクされたロールも作成されます。
ロールの権限は以下の通りです。{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetBucketPublicAccessBlock", "s3:GetBucketPolicyStatus", "s3:GetAccountPublicAccessBlock", "s3:ListAllMyBuckets", "s3:GetBucketAcl", "s3:GetBucketLocation", "s3:GetBucketPolicy", "s3:ListAccessPoints", "s3:GetAccessPoint", "s3:GetAccessPointPolicy", "s3:GetAccessPointPolicyStatus", "iam:GetRole", "iam:ListRoles", "kms:DescribeKey", "kms:GetKeyPolicy", "kms:ListGrants", "kms:ListKeyPolicies", "kms:ListKeys", "ec2:DescribeVpcs", "ec2:DescribeVpcEndpoints", "ec2:DescribeByoipCidrs", "ec2:DescribeAddresses", "lambda:ListFunctions", "lambda:GetPolicy", "lambda:ListLayers", "lambda:ListLayerVersions", "lambda:GetLayerVersionPolicy", "sqs:GetQueueAttributes", "sqs:ListQueues", "organizations:ListAWSServiceAccessForOrganization", "organizations:ListDelegatedAdministrators", "organizations:ListRoots", "organizations:ListParents", "organizations:ListChildren", "organizations:ListOrganizationalUnitsForParent", "organizations:ListAccountsForParent", "organizations:ListAccounts", "organizations:DescribeAccount", "organizations:DescribeOrganization", "organizations:DescribeOrganizationalUnit" ], "Resource": "*" } ] }
Access Analyzerはリソースベースのポリシーを分析して外部エンティティと共有されているか検出するので、その分析のための権限が付与されていることが分かります。
Organizationsのアクションは、Access Analyzerの信頼ゾーンが組織にも適用できるので、その関係で必要なアクションであるから許可されているのだと思います。
アナライザーの作成が完了し、外部エンティティと共有しているリソースがあったので検出されました。
アクションのエクスポートを行うとこのような画面になり、JSON形式でダウンロードできます。
このリソースは外部エンティティと共有することを想定して作成したリソースなので、アーカイブ済みに移します。
問題のないリソースをアーカイブ済みに移すことで、問題あるリソースの発見が容易になります。
アーカイブルールを作成したら、ルールに一致する検出結果が自動的にアーカイブされるようになります。
作成してみたところ、自動的にアーカイブ済みに移動したことを確認できました。
今度はCloudFormationで作成します。Access Analyzer有効化（CloudFormaiton）
まず一つのリージョンで有効化します。
テンプレートは以下の通りです。AWSTemplateFormatVersion: 2010-09-09 Description: EnableAccessAnalyzer Parameters: AccountID: Description: Account ID to be archived Type: String MaxLength: 12 MinLength: 12 Resources: AccessAnalyzer: Type: AWS::AccessAnalyzer::Analyzer Properties: Type: ACCOUNT ArchiveRules: - Filter: - Property: principal.AWS Eq: - !Ref AccountID - Property: isPublic Eq: - false RuleName: ArchiveOfTrustedID Outputs: AccessAnalyzerOutput: Value: !Ref AccessAnalyzer
Access Analyzerの有効化と、指定したアカウントIDと共有するリソースが検出された場合は自動的にアーカイブするアーカイブルールを作成します。
アーカイブルールの作成は以下の公式ドキュメントとコンソールで作成した際のCloudTrailログ、CLIを参考にしました。
一番確実なのは、コンソールで自分が作成したいアーカイブルールを作成して、それをCLIで見る方法です。
https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-filter-keys.htmlなお、
Outputsを記載しているのは単に何が出力されるのか気になったので載せているだけです。
結果はARNが出力されました。
AWS::AccessAnalyzer::AnalyzerをRef関数に渡すとARNが返されるので当然の結果ですが、普段Outputsを使っていないせいか、すぐにその答えにたどり着きませんでした。スタックの作成は成功しました。
一つのリージョンで無事Access Analyzerを有効化できたので、今度は全リージョンに対して行います。
まず、スタックセット作成のために、二つのIAMロールを作成します。
作成は省略しますが、ほぼこちらの公式ドキュメント通りに行っています。異なる点は、ターゲットアカウント（同じアカウントなのですが）のIAMロールの権限を以下の通り小さくしているところです。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "access-analyzer:CreateArchiveRule", "access-analyzer:CreateAnalyzer", "cloudformation:*", "sns:*" ], "Resource": "*" } ] }SNSを許可しているのは、スタックセット作成時に以下のようにエラーが出たからです。
なぜ
SNSが？と思いましたが、公式ドキュメントでは以下のポリシーがスタックセットが機能するための最低限のポリシーだとしています。{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*", "s3:*", "sns:*" ], "Resource": "*" } ] }今までこの記載は、スタックセットで
S3とSNSを作成していると思っていましたが、勘違いだったようです。
しかし、ここで疑問なのはS3をポリシーに追加しなくても作成できたことです。
S3の許可がないと失敗する場合があるのでしょうか。
よく分からないのでスルーします。アカウント内のリージョンにデプロイするのにIAMロールを作成するのは少し不思議な感じがしますが、進めていきます。
リージョンはデフォルトで無効になっているリージョン(ケープタウン、香港、バーレーン、ミラノ)以外にします。
16リージョンで
Access Analyzerを有効化できました。
コンソールで確認してみます。
全リージョンで有効化を確認できました。
いつもは検証が終わったらスタックセットを削除するのですが、Access Analyzerは無料ですので残しておきます。おわりに
Access Analyzerは無料で使用できるのが嬉しいですね。
アーカイブルールの追加・削除もスタックセットで簡単にできそうなので、融通が効きそうです。
今回は同一アカウント内の全リージョンが対象でしたが、マルチアカウントの全リージョンにも簡単に作成できそうなので、規模が大きくなるほどスタックセットの効果が発揮できそうです。
