20210907のAWSに関する記事は18件です。

S3操作をするLambda関数(Python-image)をSAM CLIを使ってデプロイする手順をまとめてみる

はじめに Lambda関数を作成するにあたり、必要な手順をざっくりまとめました。 以下も試しました。 1つのアプリケーションで複数の関数の定義 S3の操作周りをLambdaで行う SAM CLIのローカルテストを試す 開発者のIAMユーザ作成 開発とデプロイで使用します。 あとは、デフォルトのまま作成し、アクセスキー、シークレットアクセスキーを保存 必要な場合アクセス権を追加 ユーザ作成時に追加した「AWSLambda_FullAccess」のみなので必要なものがあれば追加します。 権限 概要 AWSLambda_FullAccess Lambda、CloudWatchなど AmazonS3FullAccess S3 AmazonAPIGatewayAdministrator API Gatewayの作成やデプロイに必要なポリシー AmazonEC2ContainerRegistryFullAccess ECRの作成やデプロイに必要なポリシー  IAMFullAccess AWSCloudFormationの作成やデプロイに必要なポリシー AWSCloudFormationFullAccess AWSCloudFormationの作成やデプロイに必要なポリシー 実行ロールの作成 Lambda関数を実行するロールです。デプロイ時に指定しますのでしばらく使いません。 実行ロールにも必要な場合アクセス権を追加 Lambda実行時の権限で必要なものがあれば設定します。インラインポリシーを使うと最低限のポリシーを設定できます。 例)Lambdaから特定のS3のファイル取得を行う場合 ※実際には、S3アップロードを行う必要があるのでAmazonS3FullAccessをつけています。 まずはLambdaとは関係ないプログラムを書いてみる S3を操作するPythonプログラムのサンプルです。 テスト読み取り用バケットにテスト用画像をアップしておく ローカル実行用にテスト読み取り用バケットとテスト用画像をアップしておきます。 Lambda関数とトリガーで紐づけられるS3は新たに作成する必要があるため、実際にはこのバケットは使いません。 環境はこちらの記事のosイメージをpythonに変えたものですが、なんでも構いません。 aws認証情報には、先ほど作成した開発者のIAMユーザを使います。 必要なライブラリをインストールする $ pip install boto3 単に指定したS3バケットの画像「port.png」を取得してリネームし、書き込み用バケットにアップするプログラムです。 s3example.py import boto3 import tempfile s3 = boto3.resource('s3') s3_write_bucket = '{書き込み用バケット}' def hello(s3_read_bucket, filename): # ファイルの読み込み obj = s3.Object(s3_read_bucket, filename) response = obj.get() tmpdir = tempfile.TemporaryDirectory() fp = open(tmpdir.name + '/' + filename, 'wb') fp.write(response['Body'].read()) fp.close; # ファイル名に.zipをつけてS3にアップロード zipname = tempfile.mkstemp()[1] obj = s3.Object(s3_write_bucket, filename + '.zip') response = obj.put( Body=open(tmpdir.name + '/' + filename, 'rb') ) tmpdir.cleanup() return response if __name__ == '__main__': print(hello("{テスト読み取り用バケット}", "port.png")) 動作確認します。 $ python s3example.py アップされました。 Lambda関数にする lambda_handler関数を追加します。 トリガーから渡されるeventはS3オブジェクトの更新です。 中身については、「ローカルテスト」にて後述します。 s3example.py import boto3 import tempfile s3 = boto3.resource('s3') s3_write_bucket = '{書き込み用バケット}' #循環参照防止のためreadとは別のバケット ############# 追加部分 ############# def lambda_handler(event, context): for rec in event['Records']: filename = rec['s3']['object']['key'] s3_read_bucket = rec['s3']['bucket']['name'] hello(s3_read_bucket, filename) return { "statusCode": 200, } ############# 追加部分 ############# def hello(s3_read_bucket, filename): # ファイルの読み込み obj = s3.Object(s3_read_bucket, filename) response = obj.get() tmpdir = tempfile.TemporaryDirectory() fp = open(tmpdir.name + '/' + filename, 'wb') fp.write(response['Body'].read()) fp.close; # ファイル名に.zipをつけてS3にアップロード zipname = tempfile.mkstemp()[1] obj = s3.Object(s3_write_bucket, filename + '.zip') response = obj.put( Body=open(tmpdir.name + '/' + filename, 'rb') ) tmpdir.cleanup() return response if __name__ == '__main__': print(hello("{テスト読み取り用バケット}", "port.png")) ローカルテスト まず、コンソールのLambdaの「テスト」から「s3-put」のものを取得します。 取得した情報を自身の環境に変更したものをfixtureにし、テストプログラムを作成しました。 tests/unit/test_s3example.py import pytest from hello_world import s3example @pytest.fixture() def apigw_event(): return { "Records": [ { "eventVersion": "2.0", "eventSource": "aws:s3", "awsRegion": "ap-northeast-1", # 変更部分 "eventTime": "1970-01-01T00:00:00.000Z", "eventName": "ObjectCreated:Put", "userIdentity": { "principalId": "EXAMPLE" }, "requestParameters": { "sourceIPAddress": "127.0.0.1" }, "responseElements": { "x-amz-request-id": "EXAMPLE123456789", "x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH" }, "s3": { "s3SchemaVersion": "1.0", "configurationId": "testConfigRule", "bucket": { "name": "{テスト読み取り用バケット}", # 変更部分 "ownerIdentity": { "principalId": "EXAMPLE" }, "arn": "arn:aws:s3:::{テスト読み取り用バケット}" # 変更部分 }, "object": { "key": "port.png", # 変更部分 "size": 1024, "eTag": "0123456789abcdef0123456789abcdef", "sequencer": "0A1B2C3D4E5F678901" } } } ] } def test_lambda_handler(apigw_event, mocker): ret = s3example.lambda_handler(apigw_event, "") assert ret["statusCode"] == 200 pytestをインストールし、実行します。 $ pip install pytest pytest-mock --user $ python -m pytest tests/ -v tests/unit/test_handler.py::test_lambda_handler PASSED [ 50%] tests/unit/test_s3example.py::test_lambda_handler PASSED [100%] デプロイ デプロイの準備を進めます。 複数の関数のデプロイを試したかったためこれまで触れていなかったHelloWorldFunctionも含まれます。 hello_world/Dockerfile FROM public.ecr.aws/lambda/python:3.9 COPY app.py s3example.py requirements.txt ./ RUN python3.9 -m pip install -r requirements.txt -t . template.yaml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > python3.9 Sample SAM Template for lambda-python3.9 # More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst Globals: Function: Timeout: 3 Resources: MyS3Bucket: Type: AWS::S3::Bucket HelloWorldFunction: Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction Properties: PackageType: Image #Handler: app.lambda_handler ImageConfig: Command: - "app.lambda_handler" Role: {先の手順で作成したLambda 実行ロールの ARN} Events: HelloWorld: Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api Properties: Path: /hello Method: get Metadata: Dockerfile: Dockerfile DockerContext: ./hello_world DockerTag: python3.9-v1 S3exampleFunction: Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction Properties: PackageType: Image #Handler: s3example.lambda_handler ImageConfig: Command: - "s3example.lambda_handler" Role: {先の手順で作成したLambda 実行ロールの ARN} Events: S3exampleEvent: Type: S3 Properties: Bucket: !Ref MyS3Bucket Events: s3:ObjectCreated:* Metadata: Dockerfile: Dockerfile DockerContext: ./hello_world DockerTag: python3.9-v1 S3イベントの指定の仕方について参考にさせていただきました。 (samconfig.toml作成済み) $ sam build $ sam deploy デプロイが完了したら動作確認をします。 コンソールからS3サービス画面に行き、作成されているS3バケットでファイルをアップロードします。 書き込み用バケットにzipファイルが作成されました。 おわりに Lambda関数、慣れたら便利ですが、ログがわかりづらく慣れるまで戸惑いがありました。 config情報の環境変数化、レイヤーイメージやライブラリ同梱まで手が回りませんでした。 以下覚書です。 Commandを定義しないと2つ目の関数ハンドラが1つ目になる(関数名は2つ目だがハンドラがDockerfileのCMDにある1つ目になる) HandlerはImageと併用できない Bucketは、同じ定義ファイル内のものを!Refで呼ぶ必要がある Roleは、指定しないと特に権限がない実行ロールが作成され関数に紐づく S3トリガーは、コンソール画面のLambdaからは見えないがS3の「イベント通知」でLambdaと紐づいているのが確認できる S3の「イベント通知」でコンソールから編集(何も変えずOK)するとLambda側のトリガーとして表示される 動作確認は、Lambdaの「テスト」か、本来のイベントを実行しCloudWatch log デプロイ時、おかしくなったらコンソールからCloudFormationの関連スタックを削除 template.yamlを修正したらsam buildからやり直す boto3は、イメージに最初から含まれているのでinstall不要。 お疲れ様でした。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

terraformのworkspaceを利用してVPCをマルチリージョンに展開する

workspaceを使って複数リージョンのインフラ環境をサクッと作って管理してみる。 マルチリージョン構成ので同じ構成のVPCを展開する時に便利。 workspaceについてはこの記事を参考に 今回のversion $ terraform --version Terraform v1.0.3 on darwin_amd64 + provider registry.terraform.io/hashicorp/aws v3.42.0 Your version of Terraform is out of date! The latest version is 1.0.6. You can update by downloading from https://www.terraform.io/downloads.html やっていきましょう。 workspaceはawsのregion名で作成。 default * ap-northeast-1 us-east-1 us-west-2 下記のように変数を作成。 default配下はworkspace名と同一のものにする。 variable “region” { description = “AWS region.” type = map(string) default = { “default.region” = “ap-northeast-1" “ap-northeast-1.region” = “ap-northeast-1" “us-west-2.region” = “us-west-2" “us-east-1.region” = “us-east-1" } } workspace名を変数とし、以下のように呼び出し。 client.tf provider “aws” { region = lookup(var.region, “${terraform.workspace}.region”) access_key = “********” secret_key = “********” } ${terraform.workspace} でworkspace名を呼びだして vpc と文字列結合している。 workspaceが東京リージョンの場合、出力される文字列は ap-northeast-1.region となり、Valueの ap-northeast-1 が呼び出される。 ・変数リストの取り扱い 下記の様な記述でリストを変数に格納する。 subnetはご自由にどうぞ。 variable “public_subnet_cidr” { description = “public subnet cidr block” default = { “default.public_cidr” = [“10.184.0.0/19", “10.184.32.0/19”, “10.184.64.0/19", “10.184.192.0/22”, “10.184.196.0/22", “10.184.200.0/22”] “ap-northeast-1.public_cidr” = [“10.184.0.0/19”, “10.184.32.0/19", “10.184.64.0/19”, “10.184.192.0/22", “10.184.196.0/22”, “10.184.200.0/22"] “us-west-2.public_cidr” = [“10.182.0.0/19", “10.182.32.0/19”, “10.182.64.0/19", “10.182.192.0/22”, “10.182.196.0/22", “10.182.200.0/22”] “us-east-1.public_cidr” = [“10.180.0.0/19”, “10.180.32.0/19", “10.180.64.0/19”, “10.180.192.0/22", “10.180.196.0/22”, “10.180.200.0/22"] } } 呼び出し方は同様 # public subnet resource “aws_subnet” “public” { count = 6 vpc_id = aws_vpc.main.id availability_zone = element(lookup(var.az, “${terraform.workspace}.az”), count.index) cidr_block = element(lookup(var.public_subnet_cidr, “${terraform.workspace}.public_cidr”), count.index) map_public_ip_on_launch = element(var.launch_ip, count.index) tags = { Name = element(var.public_tags, count.index) } } lookupで対象リージョンのリストを呼び出し、element関数でsubnetを6つ作成している。 以下、ディレクトリ構造 tree./ ./ ├── client.tf ├── internet_gateway.tf ├── main.tf ├── nat_gateway.tf ├── route_table.tf ├── routing.tf ├── subnet.tf ├── terraform.tfstate.d │   ├── ap-northeast-1 │   │   ├── terraform.tfstate │   │   └── terraform.tfstate.backup │   ├── us-east-1 │   │   ├── terraform.tfstate │   │   └── terraform.tfstate.backup │   └── us-west-2 │   ├── terraform.tfstate │   └── terraform.tfstate.backup └──variables.tf client.tf provider “aws” { region = lookup(var.region, “${terraform.workspace}.region”) access_key = “********” secret_key = “********” } internet_gateway.tf # Internet Gateway resource “aws_internet_gateway” “main” { vpc_id = aws_vpc.main.id tags = { Name = lookup(var.vpc_name, “${terraform.workspace}.vpc_name”) } main.tf # VPC resource “aws_vpc” “main” { cidr_block = lookup(var.vpc, “${terraform.workspace}.vpc”) enable_dns_hostnames = true tags = { Name = lookup(var.vpc_name, “${terraform.workspace}.vpc_name”) } } nat_gateway.tf # Elastic IP resource “aws_eip” “nat_1a” { vpc = true tags = { Name = “natgw” } } # NAT Gateway resource “aws_nat_gateway” “nat_1a” { subnet_id = aws_subnet.public[0].id allocation_id = aws_eip.nat_1a.id tags = { Name = lookup(var.vpc_name, “${terraform.workspace}.vpc_name”) } } route_table.tf # Route table (private) resource “aws_default_route_table” “private” { default_route_table_id = aws_vpc.main.default_route_table_id tags = { Name = “private” } } # Route Table (public) resource “aws_route_table” “public” { vpc_id = aws_vpc.main.id tags = { Name = “public” } } routing.tf # Route (Private) resource “aws_route” “private_1a” { destination_cidr_block = “0.0.0.0/0" route_table_id = aws_vpc.main.default_route_table_id nat_gateway_id = aws_nat_gateway.nat_1a.id } # Route (public) resource “aws_route” “public” { destination_cidr_block = “0.0.0.0/0” route_table_id = aws_route_table.public.id gateway_id = aws_internet_gateway.main.id } # Association resource “aws_route_table_association” “public” { count = 6 route_table_id = aws_route_table.public.id subnet_id = element([aws_subnet.public[0].id, aws_subnet.public[1].id, aws_subnet.public[2].id, aws_subnet.public[3].id, aws_subnet.public[4].id, aws_subnet.public[5].id, ], count.index) } subnet.tf # public subnet resource “aws_subnet” “public” { count = 6 vpc_id = aws_vpc.main.id availability_zone = element(lookup(var.az, “${terraform.workspace}.az”), count.index) cidr_block = element(lookup(var.public_subnet_cidr, “${terraform.workspace}.public_cidr”), count.index) map_public_ip_on_launch = element(var.launch_ip, count.index) tags = { Name = element(var.public_tags, count.index) } } # private subnet resource “aws_subnet” “private” { count = 6 vpc_id = aws_vpc.main.id availability_zone = element(lookup(var.az, “${terraform.workspace}.az”), count.index) cidr_block = element(lookup(var.private_subnet_cidr, “${terraform.workspace}.private_cidr”), count.index) tags = { Name = element(var.private_tags, count.index) } } variables.tf variable “region” { description = “AWS region.” type = map(string) default = { “default.region” = “ap-northeast-1” “ap-northeast-1.region” = “ap-northeast-1” “us-west-2.region” = “us-west-2” “us-east-1.region” = “us-east-1” } } variable “vpc” { description = “AWS vpc.” type = map(string) default = { “default.vpc” = “10.184.0.0/16” “ap-northeast-1.vpc” = “10.184.0.0/16” “us-west-2.vpc” = “10.182.0.0/16” “us-east-1.vpc” = “10.180.0.0/16” } } variable “vpc_name” { description = “vpc name.” type = map(string) default = { “default.vpc_name” = “hoge JP” “ap-northeast-1.vpc_name” = “hoge JP” “us-west-2.vpc_name” = “hoge OR” “us-east-1.vpc_name” = “hoge VA” } } variable “az” { description = “availability zone.” default = { “default.az” = [“ap-northeast-1a”, “ap-northeast-1c”, “ap-northeast-1d”, “ap-northeast-1a”, “ap-northeast-1c”, “ap-northeast-1d”] “ap-northeast-1.az” = [“ap-northeast-1a”, “ap-northeast-1c”, “ap-northeast-1d”, “ap-northeast-1a”, “ap-northeast-1c”, “ap-northeast-1d”] “us-west-2.az” = [“us-west-2a”, “us-west-2b”, “us-west-2c”, “us-west-2a”, “us-west-2b”, “us-west-2c”] “us-east-1.az” = [“us-east-1a”, “us-east-1b”, “us-east-1c”, “us-east-1a”, “us-east-1b”, “us-east-1c”] } } variable “public_subnet_cidr” { description = “public subnet cidr block” default = { “default.public_cidr” = [“10.184.0.0/19”, “10.184.32.0/19", “10.184.64.0/19”, “10.184.192.0/22", “10.184.196.0/22”, “10.184.200.0/22"] “ap-northeast-1.public_cidr” = [“10.184.0.0/19", “10.184.32.0/19”, “10.184.64.0/19", “10.184.192.0/22”, “10.184.196.0/22", “10.184.200.0/22”] “us-west-2.public_cidr” = [“10.182.0.0/19”, “10.182.32.0/19", “10.182.64.0/19”, “10.182.192.0/22", “10.182.196.0/22”, “10.182.200.0/22"] “us-east-1.public_cidr” = [“10.180.0.0/19", “10.180.32.0/19”, “10.180.64.0/19", “10.180.192.0/22”, “10.180.196.0/22", “10.180.200.0/22”] } } variable “private_subnet_cidr” { description = “private subnet cidr block” default = { “default.private_cidr” = [“10.184.96.0/19”, “10.184.128.0/19", “10.184.160.0/19”, “10.184.204.0/22", “10.184.208.0/22”, “10.184.212.0/22"] “ap-northeast-1.private_cidr” = [“10.184.96.0/19", “10.184.128.0/19”, “10.184.160.0/19", “10.184.204.0/22”, “10.184.208.0/22", “10.184.212.0/22”] “us-west-2.private_cidr” = [“10.182.96.0/19”, “10.182.128.0/19", “10.182.160.0/19”, “10.182.204.0/22", “10.182.208.0/22”, “10.182.212.0/22"] “us-east-1.private_cidr” = [“10.180.96.0/19", “10.180.128.0/19”, “10.180.160.0/19", “10.180.204.0/22”, “10.180.208.0/22", “10.180.212.0/22”] } } variable “launch_ip” { default = [“true”, “true”, “true”, “false”, “false”, “false”] } variable “public_tags” { default = [“public1", “public2”, “public3", “elb_public1”, “elb_public2", “elb_public3”] } variable “private_tags” { default = [“private1”, “private2", “private3”, “elb_private1", “elb_private2”, “elb_private3"] } 作成時は少しややこしく感じますが、各リソースの依存関係や変数を理解して作ってしまえば後々使い回しができるのでなんだかんだ便利ですね。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

認証に関して調べた事を書き連ねてみる。

このページに関して 今後重要になると思い、認証や認可やSSOとかの知見を得ようとしています。調べてると用語がたくさん出てきてどれがどう関係しているのかこんがらがってしまっています。その為、自分が整理する為のメモページです。とはいえ、同じ感覚を持つ人も多いと思うのでその方たちの参考になればと思います。初心者タグつけているのはその為です。 間違っている点など多々あるかと思います。その際には指摘など頂けると有り難いです。 認証って何? IT用語辞典によると、認証とは、対象の正当性や真正性を確かめること。ITの分野では、相手が名乗った通りの本人であると何らかの手段により確かめる本人確認(相手認証)のことを単に認証ということが多い。だそうです。 世の中ではどんな感じ? 大体のサービスでユーザーIDとログインパスワードを求められる形です。これは昔も今も同じかなと思います。 ただ、最近で世の中で流行っているのはシングルサインオンです。すなわちどこかのサービスでログインしておけば、それと連携しているサービスではログイン認証なしでそのサービスが使える機能です。 webサービスの世界では、FacebookログインとかGoogleログインとかが有名かと思います。 なんで他のサービスで認証するの? 基本的にセキュリティレベルを高める為かと思います。世の中で事件が色々あったかと思いますが、7Pay事件が知名度高いと思います。世の中の悪い人たちは一般の人が思いつかない様なエグい手法でセキュリティ情報、特に金銭が関わる情報を抜き出してきます。そんな悪い人たちに対応すべく色々な対策が施されていますが、それらはいたちごっこで、いつ今の仕組みを突破する悪人たちが出てくるか解りません。常にアンテナを高くして、情報収集して何かあったらすぐ対策しないといけないです。 そんな高度な事をサービス毎に管理するのは大変です。専門家に任せたい所です。また、認証の方法を統一しておくと、後述のシングルサインオンをしやすくなります。同時に認証の情報を保持する場所が少なくなり、危険性も少なくなります。 用語分類 各種用語がどの分類の単語なのか知っておかないとこんがらがり度合いがアップするのでその用語を分類します。 機能名 SSO(シングルサインオン) 一度ログインしたら、その情報を元に他のソフトウェアなどに再度ログインする必要が無い様にする為の機能です。その実現方法はいくつかあります。代行認証方式、リバースプロキシ方式、エージェント方式、SAML認証方式などがありますが、この記事では最後のSAML以外は触りません。 フェデレーション SSOとセットで使われている事が多いかと思います。単語そのものの意味は連盟と出てきます。パスポートに例えて説明されている事が多い様に思います。国をサービス(と認証側)に例えると、国の間でお互いのパスポートを信頼する関係が確立されていれば、別の国に入国する時に、パスポートチェックで人物チェックが出来て入国できる、という感じです。 ディレクトリ・サービス Wikiページに詳しく載ってます。コンピューターネットワーク上のリソース(人も)を一元管理して、検索などもできるサービスの様です。後述のMicrosoftのActiveDirectoryがデファクトになっているかとは思いますが、OpenLDAPなどのオープンのソフトウェアもある様です。こちらの機能を使用して前述のシングルサインオンが可能になります。 プロトコル名(やりとり規格) OAuth OAuthオフィシャルページがありますが、そのままだと良く解らないです。 色々解説ページあると思いますが、一番分かりやすい OAuth の説明が概要が良く解って助かりました。認証情報をやり取りする為の取り決めですね。 OpenID Connect OAuth2.0プロトコルに認証機能を追加したプロトコルの様です。後述「プロトコルの比較」を参照ください。こちらのページも詳しく説明してくれています。 OpenID Connectユースケース、OAuth 2.0の違い・共通点まとめ SAML OASISによる公式ドキュメントはすごく細かい事まで書いてあって概要把握しずらいですが、こちらも認証をする為のプロトコルの様です。後述「プロトコルの比較」を参照ください。 LDAP Wikiページに詳しくのってます。Lightweight Directory Access Protocolの略という事で、後述のActiveDirectoryなどのディレクトリサービスにアクセスする為のプロトコルの様です。 Kerberos IT用語辞典によると、Kerberosは利用者の手元のコンピュータ(クライアント)からネットワークを通じてサーバにアクセスする際に、利用者の身元や本人確認を行う仕組みという事です。 こちらのページも解りやすいです。Kerberosを構成するのにLDAPが必要らしいです。 【図解】初心者にも分かるKerberos認証とspnegoの仕組み ~SSOのシーケンス,統合windows認証について~ 重要ポイント:プロトコルの比較 こちらのページが解り易かったです。 SAMLとOAuth:比較と違い OpenID(OIDC)との関係 ポイントとしては、二つの同じ部分。 OAuthとSAMLはどちらも、相互運用を奨励し標準化するためのプロトコルです。 そして違ってる部分。 認証:このプロセスには、ユーザーのアイデンティティが関与します。SAMLは、家の鍵のようなものです。つまり、家に入る許可を与えます。 承認:このプロセスには、ユーザーの権限が関与します。OAuthは、その家のルールに若干似ています。つまり、家に入った後にできること/できないことを規定します。 そして、前述ページから参照できるページWhat is OpenID Connect?によると、OpenIDはOAtuhプロトコルの上に位置するプロトコルの様です。そして、前述の違いで、OAtuhが行っていない(訳ではない?)認証を行うという事だと思います。 こちらのページでも違いが分かりやすく書いてありました。OAuth vs SAML vs OpenID Connect vs SSO それぞれの違い。 SAMLは認可が出来無さそうな雰囲気ですが、強力なSSOを実現するXML認証・認可サービス(SAML) を見ると認可機能も提供できそうです。 ちなみにプロトコル内で使用する各機能ポイントの用語も違うようです。 プロトコル OpenID SAML ユーザーの認証を行うエンドポイント OpenID Provider (OP) ID Provider(IdP) 認証を利用するサービス Relying Party (RP) Service Provider(SP) ソフトウェア・サービス名 Active Directory 認証認可専用のサービスではなく、本質的には会社などの大規模組織に属する人や組織やモノを管理する機能らしいです。Windows Serverに備わっているサービスという事です。 Active Directory(アクティブディレクトリ)をゼロから解説、関連用語もまとめて紹介 ActiveDirectoryの機能を使って、どの共有PCにもログイン出来るようになって、そのログイン情報を元に社内の使用可能なリソースを制限できるという事が出来る様です。 こちらのページがActiveDirectoryのやり取り信号を詳しく説明してくれています。認証時にはKerberosプロトコルを使い、その他情報取得にはLDAPプロトコルを使用する感じでしょうか。 【図解】Active Directory の認証プロトコルと起動/ログオンシーケンス 先にも紹介しました【図解】初心者にも分かるKerberos認証とspnegoの仕組み ~SSOのシーケンス,統合windows認証について~ によると、ActiveDirectoryに管理されているPCでは、統合 Windows 認証を使用して、それに対応したウエブページへSSO出来る様です。 Azure AD(Azure ActiveDirectory) 今さら聞けないAzure ADとは?オンプレミスのActive Directory(AD)との違い 公式ページ:Azure Active Directory と認証および同期プロトコルの統合 によるとSAMLやOpenIDを始めとする各種認証をサポートして統合出来るっぽいです。 Active Directory Federation service(AD FS) Active Directory の認証情報(承認/認可も?)と他のサービスとの連携が出来る様にするサービス?以下のページが解りやすいかと思います。 AD FS の概要 前述の通り、せっかく社員のIDと組織管理が出来ているのでそれを他のサービスと連携できるようにしたというものかと思います。恐らくですが、営業部門の人には営業用の外部サービスをSSOで使えるようにするとかが出来そうです。 公式ページ:すべてのアプリを Azure AD と統合するための 5 つの手順 を見ると、Azure ActiveDirectoryに置き換える方向を推奨しているように見えます。 AtlassianをADFSと連携する設定 強力なSSOを実現するXML認証・認可サービス(SAML) などのページによると、少なくともSAMLプロトコルを使用した認証が可能な様です。 LDAPサーバー わわわIT用語辞典によると、LDAPプロトコルでディレクトリサービスを提供するサーバー、という事で、ActiveDirectoryもLDAPサーバーの一つという関係性の様です。 Kerberos 配布センター Kerberosプロトコルで、ユーザーのアカウントを管理するサービス 先にも紹介しました【図解】初心者にも分かるKerberos認証とspnegoの仕組み ~SSOのシーケンス,統合windows認証について~ によると、 Kerberos の一番有名な実装は Microsoft Windows の Active Directory (以降 AD) です。 という事です。 グループ分け 沢山用語が出てきましたが、独断と偏見で機能群としてグループ分けすると以下の様になると思います。 ActiveDirectory:オンプレミス環境でSSOを提供するサービスで、その構成要素にLDAP、Kerberosがある。 Azure ActiveDirectory:ActiveDirectoryをクラウド化して、他のOpenIDやSAMLでも連携できるようにしたサービス。 OpenIDベースサービス:OAuthと合わせる事で認証認可の両機能を提供する。Facebook、Twitter、Googleなどが提供している。 SAMLベースサービス:OpenID以外のweb系Saasで使用されてる?前述引用のAtlassianはSAML認証している 勢力図調査 OpenID SAML - 総務省 によると 民間デファクトであるOpenID との事で、Web系サービスではOpenID、それ以外はSAMLという勢力図なのかと想像します。 Azure ActiveDirectory はOpenIDともSAMLとも連携していると思います。AzureはMicrosoftオンリーなので、OpenID系とSAML系でそれぞれID Providerはどれぐらいあるのかちょっと調べてみます。 OpenIDに関しては既に調べている方がいました。 OpenID Connect 対応してるWebサービス/製品のログイン認証関連のドキュメントリンク集 AWS SSOのページで多数のSAML対応業務アプリが確認できたり、前述資料によると大学などはSAMLで構築しているので、世の中の勢力としてはSAMLの方が高そうです。OpenIDはOpenと言っているぐらいなので、不特定多数にオープンにしているサービスに合っているのでしょう。業務系のシステムではSAMLを意識しておいた方が良いかもしれません。 OpenID Google Paypal Auth0 LINE Yahoo!! OAuth Github Facebook twitter SAML LINE Works Salesforce AWS SSO 多数のSAML対応アプリケーションがあるようで、SAMLIDプロバイダーとして動くと思っていいと思います。 HENNGE ONE ArcGIS Enterpriseのドキュメント によると以下もSAML IDプロバイダーとして動作するようです。最初の二つ以外はオープンソースですね。 Azure Active Directory NetIQ Access Manager 3.2 以上 OpenAM 10.1.0 以上 Shibboleth 2.3.8 以上 SimpleSAMLphp 1.10 以上 OSSの存在調査 SSOではなく、OpenSourceSoftwareの方です。何かテストしようとして、社内の認証サーバー使ったらシステム管理者に怒られます。テスト用の認証サーバーが欲しいです。OSSの存在チェックです。 OpenAM (OpenID、SAML):CDDL Keycloak(OpenID、SAML):Apache-2.0 License SimpleSAMLphp(SAML):GNU LESSER GENERAL PUBLIC LICENSE Shibboleth 2(SAML):Apache 2.0 OpenLDAP(LDAP):The OpenLDAP Public License Samba(ActiveDirectory):GNU General Public License OpenID関係では前述ページで紹介されていたものしか見つけられませんでした。SAMLとOpenID両方に対応しているOSSもあるようです。Keycloakの方が新しい様で、これからSSOなどを開発用で試す時にはKeycloakを使って試すのがよさそうです。Shibbolethは学術系でデファクトらしいです(Shibboleth, 学認 を知ろう)。 (Azureでない方の)ActiveDirectoryを使ってこれから何かする事はあまりなさそうですが、一応準開発用に備する事は可能そうです(GPLっぽいので開発テストに使用するぐらいでしょうか)。 実装例 OSSで構築する時1から調べると大変なので先達の知恵は得ておきたいです。 OpenID Providerの実装例 ~OpenAM~ Keycloakのインストールと構築例 AWSでの認証周り機能 AWSとの関係は外せません。AWSで認証と関係するサービスも調べてみます。 Cognitoユーザープール ユーザープールは、アプリユーザーのサインアップとサインインオプションを提供するユーザーディレクトリです。 AWSのコンソールでCognitoを開くとこんな説明が現れます。ユーザー情報を扱うディレクトリサービスという事でしょうか。 実際にはログインユーザー情報や認証方法を管理しているので、認証を行うIDプロバイダーと考えてよいと思います。 Cognitoユーザープール単体でも認証は可能ですが、別サービスとの連携も出来る様です。AWSのユーザープールにてフェデレーション>IDプロバイダーを選択した時の画面です。 AWS再入門ブログリレー Amazon Cognito編 によると、Cognitoユーザープール本体のログインも別IDプロバイダーとの連携でのログインもCognitoユーザープールに登録されて一元管理される模様です。世の中では、サービス毎のサインアップも出来るしGoogleやFaceBookでもログインできるサービスをよく見かけますが、この機能を使用する事で実現できるのだと思います。 Cognito IDプール ID プールは、ユーザーに別の AWS のサービスへのアクセスを許可する AWS 認証情報を提供します。 いわゆる認可機能でしょうか。Cognitoユーザープールも含めた認証プロバイダーから得た情報を元にそのユーザーにどの機能を許可するかを処理するサービスですね。IDプールの設定画面です。 認証されてない場合と認証されている時のロールを指定できます。webサービスだと認証されているかどうかはクライアント側で処理するかと思いますが、APIなどでアクセスされた時のサーバーサイドバリデーションに使えそうです。 そして認証プロバイダの部分では、Cognitoを含めた認証プロバイダーを選択出来る事が解ります。どれか一つを選択と言うよりかは、それぞれの認証プロバイダーで認証された時の処理が設定できそうです。 自分が知る限りでは、DynamoDBとS3は以下の様な指定で、フォルダやキー指定でユーザー毎のアクセス範囲を指定できます。 認証された場合に使用するロールでのResource指定例 "Resource": [ "arn:aws:s3:::hogehoge-bucket/cognito/fugafuga/${cognito-identity.amazonaws.com:sub}", "arn:aws:s3:::hogehoge-bucket/cognito/fugafuga/${cognito-identity.amazonaws.com:sub}/*" ] 両方にSAML? ユーザープールとIDプール両方にSAMLとの連携が出来る様ですが、違いは何でしょう。 ユーザープール側でフェデレーション>IDプロバイダーにてSAMLを選択するとメタデータを読み込む様になってます。 IDプール側だと、以下の様に出てきます。まずはIAMでSAMLプロバイダーを登録する必要がある様です。 ID プールでの認証には、以下の SAML ID プロバイダーを選択します。Amazon Cognito は、任意の SAML 2.0 ID プロバイダーを通じた認証をサポートします。SAML プロバイダーの使用の詳細を参照してください。 このアカウントに対して設定されている SAML プロバイダーはありません。 SAML プロバイダーを作成して管理するには、AWS IAM コンソールにアクセスしてください。 IAMの画面で、IDプロバイダを追加する画面です。プロバイダ名とメタデータドキュメントを指定するという点では同じですね。 前述 AWS再入門ブログリレー Amazon Cognito編 に書いてありますが、ユーザープールでの連携の方が新しいサービスの様です。新しく構成するならユーザープール側で連携した方がよさそうです。認証に使うライブラリもユーザープールとIDプールのセットで使われる事を想定しているようです。 また、外部サービスとの連携は試した事ないので勝手な想像ですが、ユーザープール側で認証しておけば、その後はトークン有効性確認とかの各処理をAWS側で行う時に、外部IDプロバイダでなくCognitoで処理できるので高速化が見込めるとかもあるのではと想像します。 AWS SSO 公式ページ:AWS Single Sign-On 紹介 によると、オンプレのActiveDirectoryと連携して、AWS内のサービスはもとより外部のクラウドサービスやSAML対応アプリケーションとのシングルサインオンを可能にするようです。そうするとAzure ActiveDirectoryと同じような事が出来そうです。 使い始めるには、まず社内の Active Directory を AWS Directory Service を使って AWS SSO に接続します。社内のディレクトリを接続するには AWS Directory Service の AD Connector を使用する方法と、AWS Directory Service for Microsoft Active Directory (Microsoft AD) とオンプレミスの Active Directory と信頼関係を設定する方法の2つ選択肢があります。 とも書いてあり、DirectoryServiceは必須の様です。ActiveDirectoryをAWS内に作るか、外部のActiveDirectoryとの連携をするかという選択肢という事かと思われます。 公式ページ:アイデンティティソースの選択 では、AWS SSO単体でもユーザー管理できそうですが、 AWSSSOでのID の管理 によるとActiveDirectoryを使っているならそちらで管理してくださいという事で、ActiveDirectoryを薦めているようです。 AWS Directory Service そのAWS SSOに必要なActive DirectoryServiceです。AWSもディレクトリサービスを提供しているようです。4種類ある様です。 AWS Directory Service とは にそれぞれのユースケースが記載されていました。 AWSManaged Microsoft AD AWSManaged Microsoft AD は、実際の Active Directory 機能が必要な場合は、が最適な選択肢です。AWSアプリケーションや Windows ワークロード (for Microsoft SQL Server の Amazon Relational Database Service 含む) を使用します。また、AWS クラウドで Office 365 をサポートするスタンドアロンの AD が必要な場合や Linux アプリケーションをサポートする LDAP ディレクトリが必要な場合にも最適です。詳細については、「AWSManaged Microsoft AD」を参照してください。 名前の通り、フルマネージドのActiveDirectoryの様です。 AD Connector AD Connector は、既存のオンプレミスディレクトリをAWSのサービス。詳細については、「Active Directory Connector」を参照してください。 前述のAWS Single Sign-On 紹介 から引用した文章からすると、オンプレのActiveDirectoryを活用してAWSのSingleSignOnを使いたい時に使用するようです。 Simple AD Simple AD をクラウド内でスタンドアロンのディレクトリとして使用すると、基本的な AD 機能を必要とする Windows ワークロードをサポートし、互換性のある ADAWSアプリケーションを使用したり、LDAP サービスを必要とする Linux ワークロードをサポートしたりできます。詳細については、「Simple Active Directory」を参照してください。 また、詳細画面では以下の様に書かれていました。Sambaのフルマネージドサービスという事の様です。 Simple AD は、AWS クラウドでホストされるマネージド型の Samba 4 Active Directory Compatible Server であり、Microsoft Active Directory の機能のサブセットを提供します。 Amazon Cognitoユーザープール カスタム登録フィールドを作成し、そのメタデータをユーザーディレクトリ内に格納する必要があるときにも Amazon Cognito を使用できます。このフルマネージド型のサービスは、拡張して何百万というユーザーをサポートします。詳細については、「ユーザープールの作成および管理」を参照してください。 ちなみにユーザープールを選択して「次へ」に移ると、Cognitoユーザープール作成のページに移動します。ディレクトリサービスは階層的に各種リソースを管理できると思いますが、このモードだとユーザー情報をActiveDirectory形式で取得できるようになるという事になるのではと思います。 次へ向けて 今回、記事にまとめる事で大分自分の中での機能や用語の関係性が解ってきました。これから各種サービスへアクセスする時には、あぁ、ここはあそこへ認証へ行って開いているんだなとか感じそうです。 テスト的にCognitoは使った事あるのですが、業務システムとしての使い方は考えた事無い状態です。実際にSAMLを使用してログイン処理や機能認可を実装してみる事で理解を深めていきたい所です。 引用させて頂いたり参考にさせて頂いたページ オフィシャルページ OAuth OASISによるSAML公式ドキュメント Microsoft公式ページ:Azure Active Directory と認証および同期プロトコルの統合 Microsoft公式ページ:AD FS の概要 Microsoft公式ページ:すべてのアプリを Azure AD と統合するための 5 つの手順 AtlassianをADFSと連携する設定 AWS Single Sign-On 紹介 アイデンティティソースの選択 AWS Directory Service とは Wikiページ ディレクトリ・サービス LDAP 解説ページ 一番分かりやすい OAuth の説明 SAMLとOAuth:比較と違い OpenID(OIDC)との関係 OpenID Connectユースケース、OAuth 2.0の違い・共通点まとめ OAuth vs SAML vs OpenID Connect vs SSO それぞれの違い。 What is OpenID Connect? IT用語辞典:Kerberos Active Directory(アクティブディレクトリ)をゼロから解説、関連用語もまとめて紹介 【図解】初心者にも分かるKerberos認証とspnegoの仕組み ~SSOのシーケンス,統合windows認証について~ 【図解】Active Directory の認証プロトコルと起動/ログオンシーケンス 今さら聞けないAzure ADとは?オンプレミスのActive Directory(AD)との違い 強力なSSOを実現するXML認証・認可サービス(SAML) OpenID SAML - 総務省 OpenID Connect 対応してるWebサービス/製品のログイン認証関連のドキュメントリンク集 OpenID Providerの実装例 ~OpenAM~ Keycloakのインストールと構築例 AWS再入門ブログリレー Amazon Cognito編 その他 7Pay事件
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon Linux 2 に複数PHPバージョンを同居

Amazon Linux 2 に複数のPHPバージョンを同居 PHPインストール時に複数バージョンを同居しても問題ないよう、インストールしてる手順をメモ 汎用的なやり方ではないと思いますが、簡単に設定・切替えしたい人向けです。 ① yum updateした後に、remiリポジトリを追加 # 最新版へupdate sudo yum -y update # remiリポジトリを追加 sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm sudo yum install -y http://rpms.famillecollet.com/enterprise/remi-release-7.rpm ② 利用するPHPバージョン毎にインストール # PHPを使うバージョン毎にインストール for v in 70 74 80; do sudo yum -y install php$v php$v-php php$v-php-{mbstring,mysqlnd,redis,pecl-apcu,opcache,xml,gmp}; done # PHP7.0を使う場合 php70 -v # PHP7.4を使う場合 php74 -v # PHP8.0を使う場合 php80 -v ③ apacheの自動起動を有効化 ※versionは2.4以上 sudo systemctl enable httpd sudo systemctl list-unit-files | grep -e httpd ④ apacheのphp.confを勝手にロードされないよう、ファイル名変更 cd /etc/httpd/conf.modules.d/ # php.confの拡張子を変更 sudo rename php.conf php.conf.org *php.conf ⑤ alternativesで各バージョンを管理 # PHP7.0 sudo update-alternatives \ --install /usr/bin/php php /opt/remi/php70/root/usr/bin/php 10 \ --slave /usr/bin/php-cgi php-cgi /opt/remi/php70/root/usr/bin/php-cgi \ --slave /usr/bin/phar.phar phar /opt/remi/php70/root/usr/bin/phar.phar \ --slave /etc/httpd/conf.modules.d/10-php.conf webphp /etc/httpd/conf.modules.d/15-php70-php.conf.org # PHP7.4 sudo update-alternatives \ --install /usr/bin/php php /opt/remi/php74/root/usr/bin/php 10 \ --slave /usr/bin/php-cgi php-cgi /opt/remi/php74/root/usr/bin/php-cgi \ --slave /usr/bin/phar.phar phar /opt/remi/php74/root/usr/bin/phar.phar \ --slave /etc/httpd/conf.modules.d/10-php.conf webphp /etc/httpd/conf.modules.d/15-php74-php.conf.org # PHP8.0 sudo update-alternatives \ --install /usr/bin/php php /opt/remi/php80/root/usr/bin/php 10 \ --slave /usr/bin/php-cgi php-cgi /opt/remi/php80/root/usr/bin/php-cgi \ --slave /usr/bin/phar.phar phar /opt/remi/php80/root/usr/bin/phar.phar \ --slave /etc/httpd/conf.modules.d/10-php.conf webphp /etc/httpd/conf.modules.d/20-php80-php.conf.org ⑥ メインで使うphpに切替え $ sudo update-alternatives --config php There are 3 programs which provide 'php'. Selection Command ----------------------------------------------- *+ 1 /opt/remi/php70/root/usr/bin/php 2 /opt/remi/php74/root/usr/bin/php 3 /opt/remi/php80/root/usr/bin/php Enter to keep the current selection[+], or type selection number: ④ PHP.ini設定を忘れずに(タイムゾーン等) # PHP7.0.ini sudo vi /etc/opt/remi/php70/php.ini # PHP7.4.ini sudo vi /etc/opt/remi/php74/php.ini # PHP8.0.ini sudo vi /etc/opt/remi/php81/php.ini コンテナ毎に各バージョンを用意してもOKだが、こちらがお手軽かなと。 殆ど自分用メモですが、ご指摘等頂けると助かります。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

2021年9月2日のAWS東京リージョン障害についてざっくり。

2021年9月2日、AWS東京リージョンでAWS Direct Connectの障害があり、調査のサマリが公開されました。 某所でこれ読むの辛いというコメントをもらったので、私の理解の範囲で要点をざっくり箇条書き。分かる人、読める人は上のサマリの方が間違いがなく、より詳しいので、そちらを読んでいただいた方がいいと思います。 概要 午前 7 時 30 分から、Direct Connectの東京リージョンに向かうトラフィックについて断続的な接続の問題とパケットロスの増加を観測。 午後 12 時 30 分に復旧を観測しはじめ、午後 1 時 42 分に接続の問題は完全に解決。 Direct Connect ロケーションと東京リージョンの間のネットワークデバイスの一部に障害が発生したことが原因。 他のすべてのネットワーク接続は影響を受けませんでした。他の AWS リージョンへの Direct Connect トラフィックも影響を受けませんでした。 根本原因 新しいプロトコルとオペレーティングシステムが、2021 年 1 月に初めて実稼働環境に導入された。 この組み合わせ上を非常に特殊なパケット属性とコンテンツのセットが流れたことで、OSの潜在的な問題が顕在化され障害が発生した。 これらの条件は非常に特殊で稀で、導入以降8か月正常に動作していたが、今回一致するカスタマートラフィックによってこのイベントが発生した。 このカスタマートラフィックは、悪意を持って流されたとは考えていない(たまたまだろう)。 対策 東京リージョンでは現在このプロトコルが無効化されている。 有効化前に問題検出・修正する手法を開発したので、新OSとプロトコルを今後導入予定だった他リージョンを含め、再発は起きない見込み。 終わりに こんな感じですかね。以下のあたりがちょっとぼんやりしていますが… 新プロトコルとは何だったのか、 今後も東京では無効化しっぱなしなのか、 既存の導入プロセスでは検出できなかったわけだけど、そこは厳格化するのか、それはやりすぎだと考えているのか、 …新プロトコルの話は興味本位でちょっと知りたいな。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSクラウドプラクティショナー合格体験記

時間的・金銭的にコスパよく合格するために取り組んだことを共有します. Step1: 基本的なAWSサービスを利用する 資格取得のみが目的であるまたは厳しい時間的制約がある方はこのステップを飛ばしてもOKです. しかしながら,特に初学者の多くの人にとってはこのステップによってAWSの理解が深まるかと思います. 私はAWS公式のハンズオンを用いて,以下のサービスを触ってみました. EC2 VPC IAM Lambda APIGateway RDS DynamoDB ELB AutoScaling Route53 CloudWatch S3 特にはじめの一歩として,EC2, VPC, IAMの機能に触れる上では以下を指針としました. 加えて,Qiita限定公開記事の執筆,同期・先輩との勉強会でのアウトプットによって,さらに理解を深めました. ちなみに,AWS公式のハンズオンは個人的にはかなり気に入っていて,すべてのAWS情弱向け商材を駆逐する潜在性があると思います.これが無料だなんて信じられませんでした. Step1.5: AWSクラウドプラクティショナー用参考書で学習する こちらの教材を購入し,読了しました. このフェーズはStep1を踏んだ方にとっては不要かもしれません. AWSCPの試験範囲を把握する上では有用ですが,ここで得られる知識はStep1やStep2の中で得られるもので十分カバーできるという印象です. Step2: AWSクラウドプラクティショナー問題集で学習する 以下の問題集を購入し,基本問題2つと応用問題3つを演習しました. 応用問題は難易度としては実践の問題よりも難しいように思いましたが,合格の確実性を上げるためのインプット教材として捉えると評価できる教材だなという印象です. 上記の問題集に加えて,試験直前には以下も利用しました. こちらの位置づけとしては,試験直前期により多くの問題に触れるためです. 解答に対する信頼性は少々不安が残りますが,十分な演習量を詰めるのは確かでしょう.奇しくも日本語の不自然さも実際の試験を継承していて,そちらも味方によっては評価しうる点かもしれません. おわりに 私は新卒研修の一環として取得を求められましたが,試験自体の難易度はそこまで高いとは個人的には感じませんでした. ご自身の目的やスケジュールにもよりますが,AWSのというサービスの特性や試験のレベル感等も考慮しますと,本資格に関しては短期間でサクッと取ってしまいたい資格だなという印象でした. 以上となります.
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Elastic Beanstalkの環境やアプリの削除でerror

状況 Elastic Beanstalkで環境やアプリケーションが削除できなくなる時がありました。 原因 RDSだったり、セキュリティグループなどの依存関係があると削除できなくなるようです。 エラーメッセージ 以下はElastic Beanstalk管理内にRDSを立てた環境でRDSを先に削除してしまった際に出たエラーメッセージです。 error.txt ERROR Stack deletion failed: The following resource(s) failed to delete: [AWSEBRDSDatabase]. 2021-xx-xx-xxxx ERROR Deleting RDS database named: xxxxxxxxxxxx failed Reason: DBInstance xxxxxxxxxxxx was not found during DescribeDBInstances 余談&注意点 今回のエラーの本筋とは関係ありませんが Elastic BeanstalkではRDSを『管理下に置かない』ことが推奨されています。 理由はElastic Beanstalkの環境を削除した際にRDSが管理下にあると 一緒に削除されてしまうからです。 これを防止する方法としてRDSインスタンス設定で削除防止の設定をすることもできます。 解決策 CloudFormationをラップして定番ウェブアプリケーションのAWSにおけるベストプラクティス的な 構築をサクッとサポートしてくれるのがElastic Beanstalkなんですね。なので 1.CloudFormationの管理画面を開きます。 2.左メニューからスタックをクリックします。 3.ステータスの欄が[DELETE_FAILED]となっているスタックを確認します。 (Elastic Beanstalk 環境の IDが出ていればその内容も含めて確認します) 4.失敗している処理を進めたい場合は左側のチェックを入れて[削除ボタン]を押します。 5.ポップアップウィンドウでチェックを入れるとその「リソースは無視する」という動きになりますのでチェックを入れます。 6.スタックのステータスが [DELETE_COMPLETE] に変わったら、 Elastic Beanstalkの管理画面から[環境を終了]します。 セキュリティグループが原因の場合 基本的には同様の手順で消すことができます。 しかし、セキュリティグループ自体も削除できない場合があります。 もし使っていないという確認が取れればセキュリティグループの インバウンド、アウトバウントを削除してセキュリティブループ同士の 依存関係をとってあげることで削除できたりします。 詳細は参考ページをご参照下さい。 参考情報 本家:Beanstalkの削除 本家:セキュリティグループの削除 蛇足 PaasやSaasなどで機能が豊富で手軽なゆえに実はブラックボックス化してしまっていることは結構ある気がします。 Beanstalkの中身を詳しく知るにはVPCやCloudFormationあたりを掘り下げれば理解が深まると思います。 ツールで便利になってはいますがまだまだ最低限の知識は必要ですね。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Elastic Beanstalkの環境の終了やアプリの削除でerror

状況 Elastic Beanstalkで環境やアプリケーションが削除できなくなる時がありました。 原因 RDSだったり、セキュリティグループなどの依存関係があると削除できなくなるようです。 エラーメッセージ 以下はElastic Beanstalk管理内にRDSを立てた環境でRDSを先に削除してしまった際に出たエラーメッセージです。 error.txt ERROR Stack deletion failed: The following resource(s) failed to delete: [AWSEBRDSDatabase]. 2021-xx-xx-xxxx ERROR Deleting RDS database named: xxxxxxxxxxxx failed Reason: DBInstance xxxxxxxxxxxx was not found during DescribeDBInstances 余談&注意点 今回のエラーの本筋とは関係ありませんが Elastic BeanstalkではRDSを『管理下に置かない』ことが推奨されています。 理由はElastic Beanstalkの環境を削除した際にRDSが管理下にあると 一緒に削除されてしまうからです。 これを防止する方法としてRDSインスタンス設定で削除防止の設定をすることもできます。 解決策 CloudFormationをラップして定番ウェブアプリケーションのAWSにおけるベストプラクティス的な 構築をサクッとサポートしてくれるのがElastic Beanstalkなんですね。なので 1.CloudFormationの管理画面を開きます。 2.左メニューからスタックをクリックします。 3.ステータスの欄が[DELETE_FAILED]となっているスタックを確認します。 (Elastic Beanstalk 環境の IDが出ていればその内容も含めて確認します) 4.失敗している処理を進めたい場合は左側のチェックを入れて[削除ボタン]を押します。 5.ポップアップウィンドウでチェックを入れるとその「リソースは無視する」という動きになりますのでチェックを入れます。 6.スタックのステータスが [DELETE_COMPLETE] に変わったら、 Elastic Beanstalkの管理画面から[環境を終了]します。 セキュリティグループが原因の場合 基本的には同様の手順で消すことができます。 しかし、セキュリティグループ自体も削除できない場合があります。 もし使っていないという確認が取れればセキュリティグループの インバウンド、アウトバウントを削除してセキュリティブループ同士の 依存関係をとってあげることで削除できたりします。 詳細は参考ページをご参照下さい。 参考情報 本家:Beanstalkの削除 本家:セキュリティグループの削除 蛇足 PaasやSaasなどで機能が豊富で手軽なゆえに実はブラックボックス化してしまっていることは結構ある気がします。 Beanstalkの中身を詳しく知るにはVPCやCloudFormationあたりを掘り下げれば理解が深まると思います。 ツールで便利になってはいますがまだまだ最低限の知識は必要ですね。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

TerraformでS3を構築

これは何 CFをTFで作成した( https://qiita.com/namely_/items/7686771cb682f756116f ) 際に、 実はS3も作成していたのですが、書き忘れたのでメモを書きました。 構成図 S3のアクセス制御について いつもこんがらがるので、書いておきます。 ユーザポリシー • IAM Userに対して、S3やバケットへのアクセス権限を設定 • 「AWSにおいて、このユーザは何ができるか?」 • バケットポリシー • S3バケット毎に、アクセス権限を指定 •「このS3リソースには誰がアクセスできるのか?」 • ACL • 各バケットおよびオブジェクトのアクセス権限を指定 • ACLはバケット単位のACLとオブジェクト単位のACLが存在 • バケットACLはバケット内のオブジェクトにも影響を与えるが、オブジェクトが個別にACLを設定している場合、オブジェクトACLが優先させる • ACLよりも、ユーザポリシーやバケットポリシーが優先される • 例えば、違うアカウントが所有するオブジェクトのアクセス許可を管理する場合に、オブジェクトACLが有用 • バケットACLを利用するのは、Amazon S3 のログ配信グループに、バケットへのアクセスログオブジェクトの書き込みアクセス許可を付与する場合のみ =>通常は、バケットポリシーを使う ACL<ユーザー・バケットポリシー バケットACL<オブジェクトACL コード # S3 # VPCフローログ and ALBログ and Cloudfrontログ 保管用 resource "aws_s3_bucket" "log-bucket" { bucket = "vpcflow-and-alb-and-cfloglog" region = var.aws_region #acl = "private" acl = "log-delivery-write" force_destroy = true } resource "aws_s3_bucket_public_access_block" "vpc-log" { bucket = aws_s3_bucket.log-bucket.id /* S3がこのバケットのパブリックACLをブロックする必要があるか。デフォルトはfalseです。 この設定を有効にしても、既存のポリシーやACLには影響しません。 trueに設定すると、次の動作が発生します。 指定されたACLがパブリックアクセスを許可している場合、PUTバケットaclおよびPUTオブジェクトacl呼び出しは失敗します。 リクエストにオブジェクトACLが含まれている場合、PUTオブジェクトの呼び出しは失敗します。 */ block_public_acls = true /* AmazonS3がこのバケットのパブリックバケットポリシーをブロックする必要があるかどうか。デフォルトはfalseです。 この設定を有効にしても、既存のバケットポリシーには影響しません。 trueに設定すると、AmazonS3は次のようになります。 指定されたバケットポリシーがパブリックアクセスを許可している場合、PUTバケットポリシーへの呼び出しを拒否します。 */ block_public_policy = true /* AmazonS3がこのバケットのパブリックACLを無視するかどうか。デフォルトはfalseです。 この設定を有効にしても、既存のACLの永続性には影響せず、新しいパブリックACLの設定が妨げられることもありません。 trueに設定すると、AmazonS3は次のようになります。 このバケットとそれに含まれるオブジェクトのパブリックACLは無視してください。 */ ignore_public_acls = true /* AmazonS3がこのバケットのパブリックバケットポリシーを制限する必要があるかどうか。デフォルトはfalseです。 この設定を有効にしても、特定のアカウントへの非公開の委任を含む、公開バケットポリシー内の公開およびクロスアカウントアクセスがブロックされることを除いて、 以前に保存されたバケットポリシーには影響しません。 trueに設定した場合: パブリックポリシーがある場合、バケットの所有者とAWSサービスのみがこのバケットにアクセスできます。 */ restrict_public_buckets = true } resource "aws_s3_bucket_policy" "log-bucket-policy" { bucket = aws_s3_bucket.log-bucket.id policy = data.aws_iam_policy_document.log-bucket-policy.json } # ポリシードキュメントなのでS3アクセス制御にも使える data "aws_iam_policy_document" "log-bucket-policy" { statement { principals { type = "AWS" # 操作主体、誰が identifiers = [ "arn:aws:iam::AWSアカウントナンバー:root", ] } effect = "Allow" actions = [ "s3:Put*" ] resources = [ "arn:aws:s3:::${aws_s3_bucket.log-bucket.bucket}/AWSLogs/${data.aws_caller_identity.self.account_id}/*", ] } } #CF配布用のS3バケットを作成 #OAI使用 #バケットポリシー data "aws_iam_policy_document" "oai_bucket_policy" { statement { sid = "" effect = "Allow" ## アクセス元の設定。 principals { identifiers = ["${aws_cloudfront_origin_access_identity.origin_access_identity.iam_arn}"] type = "AWS" } ## バケットに対して制御するアクションを設定する。 actions = [ "s3:GetObject" ## オブジェクトの読み取りアクション。 ] ## アクセス先の設定。 resources = [ "arn:aws:s3:::${aws_s3_bucket.oai_bucket.bucket}/*" ] } } #S3バケット(OAI) resource "aws_s3_bucket" "oai_bucket" { bucket = "oai-bucket" region = var.aws_region /* OAIによってアクセスするのでprivateでも問題ない。 private:デフォルトACL。所有者に FULL_CONTROL が付与される。 バケット上の READ、WRITE、READ_ACP、WRITE_ACP アクセス許可を許可する。 */ acl = "private" /* デフォルト:false バケットをエラーなしで破棄できるように、 すべてのオブジェクト(ロックされたオブジェクトを含む)をバケットから削除する必要があることを示す値。 オブジェクトは回復できない。 */ force_destroy = true ## Webサイト設定。 website { ## バケットにアクセスした時にデフォルトで表示されるコンテンツを設定。 index_document = "画像" } /* server access logging. log-bucketへ送る。 */ logging { target_bucket = aws_s3_bucket.log-bucket.id target_prefix = "s3-logging-server-log/" } } resource "aws_s3_bucket_public_access_block" "oai_bucket" { bucket = aws_s3_bucket.oai_bucket.bucket block_public_acls = true block_public_policy = false ## バケットポリシーで制御したいため無効にする。 ignore_public_acls = true restrict_public_buckets = false ## バケットポリシーで制御したいため無効にする。 } resource "aws_s3_bucket_policy" "oai_bucket_policy" { bucket = aws_s3_bucket.oai_bucket.id policy = data.aws_iam_policy_document.oai_bucket_policy.json } /* 画像格納用のS3バケットを作成 バケットポリシー */ data "aws_iam_policy_document" "image_bucket" { statement { sid = "" effect = "Allow" principals { identifiers = ["*"] type = "*" } actions = [ "s3:ListBucket", "s3:PutObject", "s3:GetObject" ] resources = [ "arn:aws:s3:::${aws_s3_bucket.image_bucket.bucket}/*" ] } } #S3バケット #image保存用  resource "aws_s3_bucket" "image_bucket" { bucket = "image-bucket" region = var.aws_region acl = "private" force_destroy = true versioning { enabled = true mfa_delete = false } request_payer = "BucketOwner" } # S3 Public Access Block ## パブリックアクセスはしないため全て有効にする。 resource "aws_s3_bucket_public_access_block" "image_bucket" { bucket = aws_s3_bucket.image_bucket.bucket block_public_acls = true block_public_policy = true ignore_public_acls = true restrict_public_buckets = true } 結果 ログ集約バケット OAIバケット 画像保存用バケット 総括 コメント付きで構築したので、結構長くなってしまいました。 CFと分けてよかったかもしれません。 ここ間違っているのでは…?や、こうした方がいいのでは、という書き方があれば、教えていただけると大変助かります。 参考 https://discuss.hashicorp.com/t/how-do-i-prepare-an-s3-bucket-to-receive-s3-logs/5919 https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket#enable-logging https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/enable-server-access-logging.html https://qiita.com/ryo0301/items/791c0a666feeea0a704c
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

IAMロールとAWSサービスロールの違いって何?(自分なりの理解)

はじめに レプリケーションの設定をしている時に、IAMロール・AWSサービスロールという2つが出てきてそれぞれのロールの違いって何?となったので色々調べて自分なりに理解したのでそれを備忘録として残す IAMロール(単に「ロール」)とは 公式の説明の通り、IAMロール(単に「ロール」)とは、一時的な権限としてユーザとかサービスに権限を付与するのに使うもの このロールは同一AWSアカウント内のユーザの権限を制御するためにあるものではなく、 AWSのサービスに対して権限を付与する 他のAWSアカウントのユーザに一時的に使ってもらうための権限を付与する WebサービスからAWSのアクセスしたりするための権限を付与する という事をするために存在する そのため、AWSアカウントに属するユーザに対して権限を制御をするのにロールをアタッチして・・・という事は行わない (AWSアカウントに属するユーザに対する権限設定は、ユーザに管理ポリシー・インラインポリシーなどを付与する) それは実際にManagement Console上から新規ロールを作成するという手順を見ると分かるが、以下の画像のようにロール作成時には信頼されたエンティティの種類の選択というStepが必須で存在し、信頼されたエンティティとは、自分のAWSにアクセスしてもいいと思う=信頼するアクセス元(エンティティ)という意味と思われるので、何か(ユーザ・サービスなど)に権限を与えるためのものと考えられる ・参考:ロールの用語と概念 ロール ・参考:IAMロールと信頼されたエンティティの関係性 ・参考:自分なりにAWS IAMについてまとめた ロール AWSサービスロール(単に「サービスロール」)とは 公式の説明の通り、AWSの各サービス1に、ユーザに代わって何かを行う権限を付与するためのロール ※ユーザに代わって何かを行うの例としては、 S3のレプリケーション Code BuildでBuildする時にCode Commitからソースコードをチェックアウトする LambdaからECSのUpdateService、CloudFrontのCreateInvalidationを実行する といった事で、ユーザがAWSの各サービスAPI(AWS CLIコマンドでできる事と思ってOK)を呼び出して行う操作 ここで、『あれIAMロールもAWSのサービスに権限を付与するために使えるとなっていたけどどういう事?』となるが、サービスロールとは上記で書いたIAMロールの中のサービスに限定したものでARNのパスでサービスロールと識別できるものと考えられる (「信頼されたエンティティの種類」がAWSサービスを選択したIAMロール = AWSサービスロール) ロールとしての機能は、IAMロールもAWSサービスロールも同じ(実際にIAMロールとサービスロールとで同じ事ができる事を確かめた記事はここを参照) ※IAM 識別子というページに書かれているように、あくまで識別子で分かりやすくするためにロールのARNのパスを/service-role/としているだけ(ARNを見た時に、/service-role/となっていれば見ただけで、『あーこれはサービスロールなのね』と分かるという事) ・参考:自分なりにAWS IAMについてまとめた サービスロール 各ロールの見分け方 IAMロールロールのARNのパスが/であるものロールのARNはarn:aws:iam::123456789012:role/{role名}という形式 AWSサービスロールロールのARNのパスが/service-role/であるものロールのARNはarn:aws:iam::123456789012:role/service-role/{ロール名}という形式 IAMロール サービスロール ちなみに、Management ConsoleからAWS のサービス用ロールの作成 (コンソール)の手順でロールを作成すると必ずIAMロールになる これはAWS CLIコマンドのcreate-roleの説明を見ると、 This parameter is optional. If it is not included, it defaults to a slash (/).このパラメーターはオプションです。 含まれていない場合、デフォルトでスラッシュ(/)になります。 と書かれているように、オプションで指定しないとデフォルトでパスが/になるため つまり、Management Consoleからではpathのオプション設定ができないので、サービスロールである事を識別できるようにしたい時はAWS CLIコマンドでロール作成を行う必要がある ・参考:AWS CLI create-role ・参考:【AWS】IAM ロールのパスをルート(/)以外にする ・Lambda・S3・Code Buildなどなど ↩
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

S3のレプリケーション(同一AWSアカウント)

はじめに DevOpsの一環でCICDを構築した際、レプリケーション先でレプリケート後にDeployを実行させる仕組みを構築したが、自分ではレプリケーションを設定した事がなかったので試しにやってみた また、今回レプリケーションの設定をやる中でIAMロール?サービスロール?といった言葉出てきて、それぞれのロールの違いって何?となったのでそれについても調べたりして自分なりに理解を深めてみたを参照) ※一応自分の理解を確かめるという意味でも、ここではあえてIAMロールとサービスロールの2パターンでレプリケーションをやってみた ・参考:チュートリアル: レプリケーションの設定 ・参考:同じアカウントが所有するレプリケート元バケットとレプリケート先バケットのレプリケーションの設定 IAMロール版 IAMロールの作成 レプリケーションは、S3というAWSサービスがユーザに代わってやる事なのでS3にロールを渡す必要があり、IAMロール版ではIAMロールをS3に渡す事になるのでまずはそのIAMロールを作成する ここではManagement Consoleから作成した(サービスロール版ではAWS CLIコマンドで作成) ※パスの部分が/になっているように、これはサービスロールではなくIAMロール { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetReplicationConfiguration" ], "Resource": "arn:aws:s3:::repli-source" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "s3:GetObjectVersionTagging", "s3:GetObjectVersionAcl", "s3:GetObjectVersionForReplication" ], "Resource": "arn:aws:s3:::repli-source/*" }, { "Sid": "VisualEditor2", "Effect": "Allow", "Action": [ "s3:ReplicateObject", "s3:ObjectOwnerOverrideToBucketOwner", "s3:ReplicateTags", "s3:ReplicateDelete" ], "Resource": "arn:aws:s3:::repli-destinat/*" } ] } action名 説明 s3:ListBucket Amazon S3バケット内のオブジェクトの一部またはすべてを一覧表示する権限。レプリケーションするオブジェクトの対象を把握するのに必要。 s3:GetReplicationConfiguration AmazonS3バケットに設定されたレプリケーション構成情報を取得する権限。 s3:GetObjectVersionTagging オブジェクトの特定のバージョンに設定されたタグを返す権限。 s3:GetObjectVersionAcl 特定のオブジェクトバージョンのアクセス制御リスト(ACL)を返す権限。 s3:GetObjectVersionForReplication 暗号化されていないオブジェクトとSSE-S3またはSSE-KMSで暗号化されたオブジェクトの両方を複製する権限 s3:ReplicateObject オブジェクトとオブジェクトタグを宛先バケットに複製する権限。 s3:ObjectOwnerOverrideToBucketOwner レプリカ(レプリケーションされたオブジェクト)の所有権を変更する権限。・参考:レプリケート先バケットポリシーへのレプリカの所有権を変更するアクセス許可の追加 s3:ReplicateTags オブジェクトタグをレプリケーション先のバケットに複製する権限。 s3:ReplicateDelete 削除マーカーをレプリケーション先のバケットに複製する権限。 ・参考:AWS のサービス用ロールの作成 (コンソール) ・参考:許可のセットアップ S3(レプリケーション元)の設定 IAMロールに上記IAMロールの作成で作成したロールを指定する事で、S3にレプリケートを行う権限を付与できる ※レプリケーション時間のコントロール (RTC)については追加で課金されるので注意が必要だが、検証する上で時間がかかり過ぎるのも困るので☑している(私はテキストファイル1kbを5、6回レプリケーションをやったが特に課金はされていなかった) #1 #2 S3(レプリケーション先)の設定 今回は同一AWSアカウントのバケット間でのレプリケーションなので設定不要 実際にレプリケーションを確認してみる 以下のようにそれぞれレプリケーションが成功しているか?がステータスで分かる レプリケーション元 レプリケーション先 サービスロール版 サービスロールの作成 サービスロールはAWS CLIコマンドからしか作れない(と思っている) ので以下のようなコマンドでサービスロールを作成する ※--path /service-role/のようにパスを指定する事でサービスロールになる(サービスロールか?は識別子でしかなくロールの本質的な部分はIAMロールもサービスロールも同じでそれぞれ便宜上の区分で名前が違う。詳細はIAMロールとAWSサービスロールの違いって何?(自分なりの理解)を参照。) aws iam create-role \ --role-name replication-service-role \ --assume-role-policy-document file://replication-service-role-trust-policy.json \ --path /service-role/ aws iam put-role-policy \ --role-name replication-service-role \ --policy-name replication \ --policy-document file://replication-service-role-inline-policy.json replication-service-role-trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ※replication-service-role-inline-policy.jsonの中身はIAMロールの作成の項のJSONとほぼ同じで、"Resource"のバケット名の部分だけ変更したもの(repli-source-cli, repli-destinat-cli) AWS CLIコマンドのリファレンスは以下 https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-role.html https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/put-role-policy.html ・参考:IAM 識別子 IAM ARN ・参考:IAM ロールの作成 S3バケットの作成 単にバケットを作成しただけだと、デフォルトでパブリックアクセス制限がオフになっているので、作成後にパブリックアクセス制限をオンにする aws s3api create-bucket --bucket repli-source-cli --create-bucket-configuration LocationConstraint=ap-northeast-1 aws s3api create-bucket --bucket repli-destinat-cli --create-bucket-configuration LocationConstraint=ap-northeast-1 aws s3api put-public-access-block --bucket repli-source-cli \ --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true" aws s3api put-public-access-block \ --bucket repli-destinat-cli \ --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true" AWS CLIコマンドのリファレンスは以下 https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/create-bucket.html https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-public-access-block.html ・参考:【AWS CLI】ap-northeast-1でcreate-bucketした際にIllegalLocationConstraintExceptionがスローされた場合の対処法 create-bucketを行う際にはcreate-bucket-configurationをしてしないとエラーになるので注意 xxxxxxxxxx:/mnt/c/Users/user/OneDrive/ドキュメント$ aws s3api create-bucket --bucket repli-source-cli An error occurred (IllegalLocationConstraintException) when calling the CreateBucket operation: The unspecified location constraint is incompatible for the region specific endpoint this request was sent to. xxxxxxxxxx:/mnt/c/Users/user/OneDrive/ドキュメント$ aws s3api create-bucket --bucket repli-source-cli --region ap-northeast-1 An error occurred (IllegalLocationConstraintException) when calling the CreateBucket operation: The unspecified location constraint is incompatible for the region specific endpoint this request was sent to. S3(レプリケーション元)の設定 レプリケーションの設定を行うconfigurationのJSONが今回はかなり大きめなのでテンプレ(スケルトン)を作成して、それを編集するようにする また、IAMロールではなく、サービスロールをレプリケーション設定に渡す("Role": "arn:aws:iam::xxxxxxxxxxxx:role/service-role/replication-service-role") aws s3api put-bucket-replication --generate-cli-skeleton > replication-config.json aws s3api put-bucket-versioning --bucket repli-source-cli --versioning-configuration Status=Enabled aws s3api put-bucket-replication --bucket repli-source-cli --replication-configuration file://replication-config.json replication-config.json { "Role": "arn:aws:iam::xxxxxxxxxxxx:role/service-role/replication-service-role", "Rules": [ { "ID": "sync_to_destinat_cli", "Priority": 0, "Status": "Enabled", "Filter": { "Prefix": "" }, "Destination": { "Bucket": "arn:aws:s3:::repli-destinat-cli", "ReplicationTime": { "Status": "Enabled", "Time": { "Minutes": 15 } }, "Metrics": { "Status": "Enabled", "EventThreshold": { "Minutes": 15 } } }, "DeleteMarkerReplication": { "Status": "Disabled" } } ] } AWS CLIコマンドのリファレンスは以下 https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-replication.html https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-versioning.html ・参考:JSON または YAML 入力ファイルからの AWS CLI スケルトンと入力パラメータの生成 put-bucket-replicationを行う際にはバケットのバージョン管理が有効になっている必要があるので注意 xxxxxxxxxx:/mnt/c/Users/user/OneDrive/ドキュメント$ aws s3api put-bucket-replication --bucket repli-source-cli --replication-configuration file://replication-config.json An error occurred (InvalidRequest) when calling the PutBucketReplication operation: Versioning must be 'Enabled' on the bucket to apply a replication configuration --replication-configurationのJSONについて、Rule内に"Filter": {"Prefix": ""}がないとエラー1になるので注意 "Filter": { "Prefix": "" } S3(レプリケーション先)の設定 バケットのバージョン管理が有効になっている必要があるのでそれを設定する aws s3api put-bucket-versioning --bucket repli-destinat-cli --versioning-configuration Status=Enabled 実際にレプリケーションを確認してみる レプリケーション元にレプリケーションのテスト用.txtを追加して、レプリケーション先のオブジェクトを取得してみると・・・ aws s3 cp レプリケーションのテスト用.txt s3://repli-source-cli xxxxxxxxxx:/mnt/c/Users/user/OneDrive/ドキュメント$ aws s3api head-object \--bucket repli-source-cli --key レプリケーションのテスト用.txt { ..., "ReplicationStatus": "COMPLETED" } xxxxxxxxxx:/mnt/c/Users/user/OneDrive/ドキュメント$ aws s3api list-objects --bucket repli-destinat-cli { "Contents": [ { "Key": "レプリケーションのテスト用.txt", "LastModified": "2021-09-06T14:40:46+00:00", ..., "Owner": {...} } ] } xxxxxxxxxx:/mnt/c/Users/user/OneDrive/ドキュメント$ aws s3api head-object --bucket repli-destinat-cli --key レプリケーションのテスト用.txt { ..., "ReplicationStatus": "REPLICA" } "ReplicationStatus": "COMPLETED"・"ReplicationStatus": "REPLICA"となっているようにレプリケーションが成功している事が分かる AWS CLIコマンドのリファレンスは以下 https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/cp.html https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/get-object.html https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/list-objects.html まとめ レプリケーションはかなり簡単に設定できる また、IAMロールでもサービスロールでもレプリケーションは設定できる おまけ 作成したサービスロールは、ちゃんとサービスロールになっているか? ※パスの部分が/service-role/になっているように、これはIAMロールではなくサービスロール An error occurred (MalformedXML) when calling the PutBucketReplication operation: The XML you provided was not well-formed or did not validate against our published schema参考:Python Boto3 PutBucketReplication operation: The XML you provided was not well-formed or did not validate against our published schema ↩
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Systems Manager(SSM) パラメータストアのクロスアカウント設定

Bのアカウントに存在するパラメータストアをAのアカウントから参照するための設定について確認した記事です。 構成 Aアカウント パラメータストアの値にアクセスする方のアカウント アカウントIDを仮に0123456789012とする Bアカウント パラメータストアに値を保管しているアカウント アカウントIDを210987654321とする アカウントBでパラメータストアに値を保管する 設定値としては画像の通り - キー名:cross-test - 種類:String - 値:test アカウントBでパラメータストアアクセスするロールを作成する(671268391729) パラメータストアのARN形式 arn:aws:ssm:REGION:ACCOUNT-ID:parameter/ID:parameter-name 作成したパラメータを取得できるPolicyを作成します。 policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:DescribeParameters" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ssm:GetParameters", "ssm:GetParameter" ], "Resource": "arn:aws:ssm:ap-northeast-1:210987654321:parameter/cross-test" } ] } 上記PolicyをセットしたロールtestBRoleを作成します。 信頼関係Policyは下記のようにAアカウントを指定しましょう。 アカウントAからこのロールをAssumeして使用したいからです。 policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::0123456789012:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] } アカウントAでIAMのRoleを準備する Bアカウントで用意したロールをAssumeするためのロールを作成します。ロール名はAssumeTestBRoleとします。 まずはPolicyの準備 policy { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::210987654321:role/testBRole" } } Resourceには先程作成したアカウントBのtestBroleを指定します。 今回はテストでアカウントAのユーザーでクラウドシェルからCLIを叩きたいので、このロールの信頼関係ポリシはAアカウント全体として指定しました。 policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::0123456789012:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] } テスト アカウントAで上記ロールを用いてCLI経由でアカウントBのパラメータストアの値を取得する AWS CloudShellを利用しました。 まず、testBroleをAssumeしたいのでAssumeTestBRoleにAssumeします。 aws sts assume-role \ --role-arn "arn:aws:iam::0123456789012:role/AssumeTestBRole" \ --role-session-name test-AssumeTestBRole-Session 出力された一時クレデンシャル情報を環境変数に指定してtestBroleにAssumeできるようにします。 続いて、testBroleにAssumeします。 aws sts assume-role \ --role-arn "arn:aws:iam::210987654321:role/testBRole" \ --role-session-name testBRole-Session この状態でAssumeした主体が保持している権限は一番最初に作成したBアカウントのパラメータを参照するための権限になります。 policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:DescribeParameters" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ssm:GetParameters", "ssm:GetParameter" ], "Resource": "arn:aws:ssm:ap-northeast-1:210987654321:parameter/cross-test" } ] } 一番最初のコレですね。 したがって、parametersやparameterが使えます。 aws ssm get-parameters \ --names cross-test \ --query "Parameters[*].{Name:Name,Value:Value}" [ { "Name": "cross-test", "Value": "test" } ]
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS EC2にSSL/TLSを追加する(https化)

AWS EC2インスタンスWEBサーバーをムームードメインなどで取得した独自ドメインでHTTPS化を有効にする手順について ムームードメインの操作 取得したいドメインを検索>カートに追加 ドメイン設定 WHOIS公開情報:チェック ネームサーバー(DNS):ムームーDNS ドメインの利用方法:選択しない ムームーメール:チェックしない ACMの操作 *AWS Certificate Managerのコンソール画面>証明書のリクエスト *パブリック証明書のリクエストを選択して、証明書のリクエストをクリック *取得したドメインを入力し、次へ *DNSの検証を選択して、次へ *任意のタグをして、確認 *確定とリクエスト *検証状態のステータスが「検証保留中」になっていることを確認する *ドメイン名左の▼をクリックして、CNAMEレコードの名前欄と値欄を控える ムームードメインの操作 *カスタムドメインの操作 *コントロールパネルからムームーDNSをクリック *取得したドメインの 利用する をクリック *DNS設定をする *カスタム設定 をクリック *設定2にCNAMEを追加する ※1「控えたCNAME名前欄の".ドメイン名."より前」をサブドメインに入力する ※2「控えたCNAME値欄」を内容に入力する AWS Load Balancerを作成 EC2のコンソール>ロードバランサー>ロードバランサーの作成>Application Load Balancerの作成 をクリック ロードバランサーの設定 名前:任意の名前 スキーム:インターネット向け リスナーのロードバランサーのプロトコル:HTTPS AZ:対象のインスタンスが配置されているAZVPCとAZを選択 セキュリティ設定の構成 証明書タイプ:ACMから証明書を選択する 証明書の名前:今回作成した証明書 セキュリティポリシー:任意のポリシーを選択 セキュリティグループの設定 セキュリティグループ名:任意の名前 タイプ:HTTPS ソース:0.0.0.0/0 ルーティングの設定 ターゲットグループの名前:任意の名前 ヘルスチェックの名前:/index.html(や/index.php) ターゲットの登録 対象のインスタンスを追加 対象インスタンスのセキュリティグループを編集 対象のインスタンス>セキュリティタブ>セキュリティグループ>インバウンドルールの編集 タイプ:HTTP ソース:今回作成したロードバランサーのセキュリティグループ 参考 *チュートリアル: Amazon Linux 2 に SSL/TLS を設定する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIからDynamoDBを操作してみる。

はじめに 業務でDynamoDBを利用しているのですがAWS CLIからコマンドを打つ機会があったので忘れずに操作内容をメモしておこうと思います。 事前準備 今回はローカル環境からコマンドを打っているため、AWS CLIを利用するにあたってAWS Configureの設定をする必要があります。 C:\WINDOWS\system32>aws configure AWS Access Key ID [None]: IAMユーザのアクセスキー AWS Secret Access Key [None]: IAMユーザのシークレットアクセスキー Default region name [None]: ap-northeast-1 Default output format [None]: json DynamoDBの作成 今回はこの「test_dynamoDb」というテーブルを利用して色々と操作をしていこうと思います。 パーティションキーは"TestKey"とします。 注意 今回、僕はコマンドプロンプトを利用したのですが、一つのハマりポイントとしてJsonの""は前に\を入れる必要がありました。 もしコマンドプロンプトを利用している方は気をつけてくださいね! テーブルの一覧を取得 テーブルの一覧を取得するにはlist-tablesコマンドを利用します。 テーブルの一覧を取得 aws dynamodb list-tables test_dynamoDbが取得できました。 データの挿入 データの挿入にはput-itemコマンドを利用します。 データの挿入1 aws dynamodb put-item --table-name test_dynamoDb --item "{\"TestKey\":{\"S\": \"TestKey1\"}, \"item1\": {\"S\": \"テスト1\"}}" ちゃんと値が入ったことが確認できました! 同じキーを持つ項目がすでにテーブル内にある場合はその値が上書きされます。 データの挿入2 aws dynamodb put-item --table-name test_dynamoDb --item "{\"TestKey\":{\"S\": \"TestKey1\"}, \"item1\": {\"S\": \"テスト2\"}}" 先ほど作成した「テスト1」が「テスト2」へ上書きされました。 キーの値を変更すると新しく挿入されます。 データの挿入3 aws dynamodb put-item --table-name test_dynamoDb --item "{\"TestKey\":{\"S\": \"TestKey2\"}, \"item1\": {\"S\": \"テスト3\"}}" 単一の項目を取得する キーを指定してデータを取得する場合はget-itemコマンドを利用します。 単一の項目を取得する aws dynamodb get-item --table-name test_dynamoDb --key "{\"TestKey\": {\"S\": \"TestKey2\"}}" キーがTestKey2の項目が取得できました。 特定のデータを持つ、特定の項目のみ取得する 特定のデータを持つ、特定の項目を取得する場合はscanコマンドと--filter-expressionオプション、--expression-attribute-valuesオプション、--projection-expressionオプションを利用します。 今回はキー以外のものでフィルターしているためにscanを利用しています。 下記はitem1項目の値が"テスト3"である項目のTestKeyを出力します。 特定のデータを持つ、特定の項目のみ取得する aws dynamodb scan --table-name test_dynamoDb --filter-expression "item1 = :item" --expression-attribute-values "{\":item\": {\"S\": \"テスト3\"}}" --projection-expression "TestKey" ちゃんと取得できましたね! おわりに 普段はSQLServerやMySQLを触ることが多いのですがDynamoDBのようなNoSQLはクエリ等が全然違うのでしっかり勉強しなきゃですね...(;´∀`) 今回調査していたら「PartiQL エディタ」というものを見つけました。どうやらそれを利用するとSQLでDynamoDBを操作できるっぽいのでここら辺もまた試してみようと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

zabbixによるプロセス監視

バージョンは4系 今回のポイント 対象環境のEC2インスタンスについて、特定プロセス監視の追加。 例えばこんな感じ inotifywait -e CLOSE_WRITE,DELETE -mrq /var/www/html/hoge/huga inotifywaitでディレクトリの変更を監視しつつそれをzabbixに飛ばしてそこからslack通知なりなんなり便利に使ってみましょうという流れ。 今回困ったこと プロセスの引数がいっぱいあってどうやって指定するのかわからん プロセスの引数にオプション指定ある プロセスの引数の中にカンマがある ここに書いてあるように proc.num[] []の中は引数が四つある 第一引数 [name] プロセス名(ps -e の出力結果) 第二引数[user] プロセスの実行ユーザ名 第三引数[state] 監視するプロセスの状態を指定 第四引数[cmdline] フィルタする文字列(ps -ef の出力結果から文字を選べる) 今回書いたのは一と四 name $ ps -e | grep inotifywait 22375 ? 00:00:00 inotifywait cmdline $ ps -ef | grep inotifywait ec2-user 822 725 0 16:03 pts/4 00:00:00 grep --color=auto inotifywait root 22375 22374 0 13:21 ? 00:00:00 inotifywait -e CLOSE_WRITE,DELETE -mrq /var/www/html/hoge/huga 正解 proc.num[inotifywait,,,“-e CLOSE_WRITE.DELETE -mrq /var/www/html/hoge/huga”] コマンドの引数は第四引数の位置に書いてあげる カッコ[]内のカンマ“,”はドット“.”で代用できる 検索文字列内の ハイフン“-” を文字列として認識させたい時は ダブルクォーテーションで括る “” この形が作れたらproxyでzabbix_getを投げて値が返ってくるかどうか確認 OKだったらitemとtrigger作ってseverityをinfoで確認 OKだったら第四引数の文字列を適当に変えてinfoが発砲するか確認 今回のzabbix_getはこれ $ zabbix_get -s <ip address> -k proc.num[inotifywait,,,“-e CLOSE_WRITE.DELETE -mrq /var/www/html/hoge/huga”] 1 1が返ってくる事を正常と判断して設定 以下備忘 -s 監視対象のIP 対象自体にzabbix_getが入ってたら127.0.0.1でおk -k key 監視したい項目を入れる
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

zabbixによるURL監視の備忘録

zabbix触り始めて割と最初の頃に躓いた時のメモ バージョンは4系 対象はALB配下のwebサーバー Hosts作成のあれこれ zabbix-web上での設定 Agent interfacesは厄介 ELB配下のURLについてはDNS設定が出来ない(当然ELBいるから) -> というそもそもコンテナで稼働しているzabbixサーバーはport 10050 をlistenしている -> ELBでそんなport開いてるわけ無いでしょ -> しかしuser agentを設定しないわけにも行かないので自分のローカルIPを設定すれば結果的におk IPを選択して、127.0.0.1 / port 10050 ※zabbixサーバー自身のローカルを指定してる(ELB配下じゃなかったら監視対象のDNSを指定したい所) Groupsは監視対象次第(EC2とかRDSとか)で適宜 VisibleNameはそのまんまhost名になるので、パット見でわかりやすい名前や、既存の設定に合わせて命名しましょう。 ・Triggersについて 既に環境をクライアントに引き渡している場合、アラート通知設定済みの環境であれば即通知が行ってしまう。 --->ミスっていないか確認する為、通知はWarningからInformationに変えておきましょう。安牌大事 ・Web scenarios(シナリオ)についての勘所さん ここのエラーが解決できなくて、当時頭を抱えてた所 {$REQUIRED_STRING} とは ※REQUIRED -> 必須 監視対象のURLにアクセスした時に、そのwebページ上の特定の文字列を取得する。 ここの設定は必須では無いが、Monitoring Webの項目はなんかしら絶対取得できる文字列を設定すると◎ -> 例えばhogehoge社のwebページなら「hogehoge」って単語はどこかしらに必ずあるでしょっていう文字列を設定 -> もしくは、「Macros」で{$REQUIRED_STRING} のValueを「空欄」にしちゃって結果的におkにしてしまう方法もあるがちょっとナンセンス これでひとしきりおk
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

zabbix-agent.conf での個人的勘所

serverバージョンは4系、AmazonLinux2環境 ubuntu環境に入れた時はこの記事をまんま進めてた(大感謝)。 ubuntuにagentを入れた時はインスコ完了時点でstartしている。 zabbix-agent.confでよく弄る箇所 ### Option: LogFile # Log file name for LogType ‘file’ parameter. # # Mandatory: yes, if LogType is set to file, otherwise no # Default: # LogFile= LogFile=/var/log/zabbix/zabbix_agentd.log agentのLogを吐き出す場所の指定。 各agentのログを一箇所にまとめたい時等に割と弄る ### Option: EnableRemoteCommands # Whether remote commands from Zabbix server are allowed. # 0 - not allowed # 1 - allowed # # Mandatory: no # Default: # EnableRemoteCommands=0 リモートコマンドを許可するかどうかの設定。 コンテナのdownを検知してActionから $docker restart〜 等々、アラートに応じて自動でコマンドを流したい時に弄る。 # EnableRemoteCommands=0 EnableRemoteCommands=1 こんな感じに書いておけばconf.orgとdiff撮った時に見やすい、個人的に。 ### Option: LogRemoteCommands # Enable logging of executed shell commands as warnings. # 0 - disabled # 1 - enabled # # Mandatory: no # Default: # LogRemoteCommands=0 説明の通り。ログは大事、マジで。 ##### Passive checks related ### Option: Server # List of comma delimited IP addresses, optionally in CIDR notation, or DNS names of Zabbix servers and Zabbix proxies. # Incoming connections will be accepted only from the hosts listed here. # If IPv6 support is enabled then ‘127.0.0.1’, ‘::127.0.0.1’, ‘::ffff:127.0.0.1’ are treated equally # and ‘::/0’ will allow any IPv4 or IPv6 address. # ‘0.0.0.0/0’ can be used to allow any IPv4 address. # Example: Server=127.0.0.1,192.168.1.0/24,::1,2001:db8::/32,zabbix.example.com # # Mandatory: yes, if StartAgents is not explicitly set to 0 # Default: # Server= Server=127.0.0.1 zabbix-serverのIP入力欄。 proxyを噛ませている場合はproxyのIP。そらそうでしょって感じだが意外と忘れてる事がある。 ##### Active checks related ### Option: ServerActive # List of comma delimited IP:port (or DNS name:port) pairs of Zabbix servers and Zabbix proxies for active checks. # If port is not specified, default port is used. # IPv6 addresses must be enclosed in square brackets if port for that host is specified. # If port is not specified, square brackets for IPv6 addresses are optional. # If this parameter is not specified, active checks are disabled. # Example: ServerActive=127.0.0.1:20051,zabbix.domain,[::1]:30051,::1,[12fc::1] # # Mandatory: no # Default: # ServerActive= ServerActive=127.0.0.1 アクティブチェックの設定。 基本的には Serverの設定と一緒。 serverやらproxyがコンテナで稼働している時はコンテナが使っているportを要確認。 ### Option: Hostname # Unique, case sensitive hostname. # Required for active checks and must match hostname as configured on the server. # Value is acquired from HostnameItem if undefined. # # Mandatory: no # Default: # Hostname= Hostname=Zabbix server Hostnameの設定。 Autoregistの設定をしている時はココで設定した値がHostnameになる(そのまんま) ### Option: HostMetadata # Optional parameter that defines host metadata. # Host metadata is used at host auto-registration process. # An agent will issue an error and not start if the value is over limit of 255 characters. # If not defined, value will be acquired from HostMetadataItem. # # Mandatory: no # Range: 0-255 characters # Default: # HostMetadata= web側のauto registration設定で拾うHostMetaDataの設定。 ココ次第でHostGroupsの振り分けとかもできる。 ### Option: RefreshActiveChecks # How often list of active checks is refreshed, in seconds. # # Mandatory: no # Range: 60-3600 # Default: # RefreshActiveChecks=120 ActiveCheckの更新間隔。 デフォの120secは少々長い印象。自分用に構築するときは大体60sec ### Option: Timeout # Spend no more than Timeout seconds on processing # # Mandatory: no # Range: 1-30 # Default: # Timeout=3 timeoutの長さ。 デフォの3secは短い印象。30sec位でええでしょ程度に。 雑多なメモ ・Elasticache memcacheの監視反映は思ったより時間がかかる。 ・発報テスト時はseverityに注意しましょう(slack転送設定をした後とか稼働中のサービスがあったりすると。。。) ・Templateのimport時、Discovery配下設定はimportされない ※一例 All Template -> 対象Template -> Discover rules -> filesysteのtrigger prototypes
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【二週間でAWS SAA対策!】結局どの教材がいいの?SAA試験対策に使った教材まとめてみた!

はじめに SAAの対策にどの教材を使うか迷ってませんか? 私もSAA取得に向けて勉強を始めた時、数多くの教材のどれから初めるべきか迷いました....迷った末に、色々な合格体験記にある教材を片っ端から買って試す事にしました! そこで今回は、二週間で合格するまでの過程で私が使用した書籍、サイトなどを勝手にレビューして重要度付けしていきます! 2021/09/05にAWS SAA試験を受けて合格しました✌️ いきなり結論 これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版) 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問) この二つの教材を活用することでSAA対策は十分にできます! Udemyの講座を先に受講し、ハンズオンを通してAWSサービスの理解を深めてから模擬試験問題集を解いていくことをオススメします。 各教材の説明は使用したSAA対策教材一覧に記載しますが、より多くの問題を解くことよりも、一つの問題の複数の選択肢に対してなぜこの選択肢は間違っているのか?を考えながら解くと本試験でも迷わず解ける問題が多くなると思います。 より多くの模擬問題を解いて、本試験と同じ問題文の長さに慣れる(SAA試験はCLF試験と比べて問題が長い)のであれば、【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問)にトライするのも対策として効果的です。 使用したSAA対策教材一覧 【★★★】これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版) Udemyで購入できるハンズオン講座 ¥2,400(2021/09/05現在)です。 AWSのアカウント登録からAWSの中核となるサービスのハンズオン、さらにSAAの模擬試験が3つ付いてくるという、非常にボリュームのある講座です! 各コンテンツごとに章立てされているので、AWS未経験者は冒頭から、AWSを業務で使用している人は業務で使用しているサービス以外を集中的に受講することもできます。(※VPCなどは作成したものを他の章でも使うので注意) 付属の模擬試験はハンズオンで触れたサービスについて問われる事が多いので、本試験よりも少し簡単でした! 動画の再生速度は変更できるので、時間のない人は1.5倍速にすることをオススメします。(私は1.5倍速で受講しました) 【★★★】AWS WEB問題集で学習しよう SAAの模擬問題を1000問以上購読できる学習サイトです。 料金はプランによって異なりますが、購読してから90日間のみ閲覧できるのでアソシエイト三冠向けのベーシックプランをオススメします。 問題集には#1~#149まで項目があり、各項目に7問用意されています。#80以降で本試験との類似問題が複数あったので、#80以降から解くといいと思います。 問題集には以前間違った箇所を記録する機能はないので、間違った箇所をメモし苦手分野を把握することが大切です。 問題の難易度は本試験と同等になっており、この問題集を解いて解説までしっかりと理解することで確実に合格に近づきます。 また、このサイトには「合格記」という合格者が試験の感想やアドバイスを記載している一覧があります。非常に有益な情報が多数載っているので、問題集を解く前や受験前に一読することをオススメします。 【★★☆】【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問) Udemyで購入できる模擬試験問題集 ¥2,400(2021/09/05現在)です。 タイトルの通り6回分390問を解くことができます。問題集は①基本問題、②〜⑥高難易度問題となっています。 ②以降は他の問題集よりも難易度は高めで、「AWS WEB問題集で学習しよう」で7割以上の正答率がある状態で解いても、この高難易度問題集の正答率は5~6割でした。 この問題集は詳細な解説が付いているので、正解した箇所も含めて解説を見て理解する。理解できない箇所は、AWS公式サイトやホワイトペーパーなどの更に詳細に記載されているものを見て理解することを意識するといいと思います。 本試験はこの問題集ほど難しくはなかったですが、模擬問題を多くこなして苦手分野を見つけるといった点で役に立ちます。 【★★☆】この1冊で合格! AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集 Amazonなどで購入できる試験対策本 ¥2,618(2021/09/05現在)です。 この本は図や表が分かりやすくまとめられていました。VPC仮想ネットワーク構成や3層アーキテクチャについて、問題で問われた際に脳内で構成を組めるようになるまで読み込む価値はあると思います。 各サービスについて重要度が表示されているので、それを参考にして重点的に学ぶこともできます。 しかし、発売から少し経過している本なので最新のサービスの記載がなかったり一部間違いなどがあります。(例:2020年12月にS3は結果整合性のサポートから強い一貫性もサポートできるようになった、などなど.....) 試験対策本の最後の章には模擬試験が付いていますが、解説が他の教材に比べて薄いので何度も解いて復習する事はあまりオススメできません。 【★☆☆】AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版 Amazonなどで購入できる試験対策本 ¥2,618(2021/09/05現在)です。 試験で問われる基礎的な部分を知ることができます。あくまでも基礎的な部分であって、この一冊を読み込むことで合格するのは難しいです。 本には一つのサービス毎の説明が多いので、そのサービスを組み合わせてどのようにアーキテクチャ設計をするかは自分で調べる必要があります。 試験対策本の最後の章には模擬試験が付いているので、自分の基礎知識を測るのには使えます。 【★☆☆】AWS公式模擬試験 AWSが提供している公式の模擬試験 ¥2200(2021/09/05現在)です。 実際の試験と同じ形式で模擬試験を受験することができます。問題数と試験時間は短縮されています。 受験後はスコアレポートとして正答率を確認できますが、正解、不正解の箇所と回答を確認することはできません。 模擬試験の難易度としては本試験より簡単です。模擬試験の正答率が70%以上取れたから本試験!と考えてると、痛い目を見るかも知れません..... もし事前にCLFを取得しているなら、AWSから公式模擬試験を無料で受けれる特典が配布されています。特典を使用して試しに受けてみる、くらいの気持ちであれば受験しても良いと思います。 【★☆☆】Black Belt AWSが提供しているサービス別資料集です。 YouTubeやPDFで閲覧することができ、各サービスについて非常に細かく解説されています。 しかし、短期間で試験対策をすることを考えたときに時間対効果はあまり良くないと思います。また、問題を解くわけではないので復習などが行いにくいです。 活用方法としては、各問題を解いた後に苦手分野を確認するのに使うのがベストだと思います。私はネットワークが弱いのでCloudFrontとRoute 53の対策に活用しました。 時間がある方は頻出範囲(ELB,VPC,S3など....)を重点的に見てユースケースやアーキテクチャを頭に入れておくことをオススメします。 【番外編】オススメQiita記事 最後に これら全ての教材とSAA試験代を合わせると結構な金額になっていました....コストが気になる方は、教材を取捨選択した上で、Udemyのセールなどを活用して貰えればと思います!(高頻度で開催されています) SAAの教材はAWSの中でも一番多いと思いますが中には、古い教材や問題があります。ここで紹介したWeb問題集は日々更新されていますが、本やQiitaなどのブログを参考にする時は、いつ発刊されたかを確認して新しい問題に対応したものを参考にするのがベストです。 人によって学習方法は様々ですが、何から始めれば良いか迷ってる人の参考になればと思います! 最後まで読んでいただき、ありがとうございました!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む