terraformを使って、redisを作成する方法

terraformを使って、各AZに一つずつノード(合計３つ)が存在するredisクラスターを作成します。
完成イメージ は以下の通りです。






 tfファイルの内容は以下の通りです。

resource "aws_elasticache_subnet_group" "grp" {
  name = "redis-example"
  subnet_ids = ["${var.subnet_id_public_a}", "${var.subnet_id_public_c}", "${var.subnet_id_public_d}"]
}
resource "aws_elasticache_replication_group" "replica_grp" {
  automatic_failover_enabled = true
  availability_zones = ["ap-northeast-1d", "ap-northeast-1c", "ap-northeast-1a"]
  replication_group_id = "example-redis"
  replication_group_description = "This is a example for create redis by terraform."
  node_type = "cache.t2.small"
  snapshot_retention_limit = 5
  number_cache_clusters = 3
  port = 6379
  subnet_group_name = "${aws_elasticache_subnet_group.grp.name}"　
  security_group_ids = ["${var.default_security_group_id}"]
}

subnet_ids:作成されたサブネットのIDを入力します。プライベートサブネットにしましょう。
availability_zones :３つのゾーンを入力します。
snapshot_retention_limit:バックアップの保存期間になります

terraform環境毎に切り替える方法

terraformで環境毎に切り替えるにはterraform workspaceを使います。
今回はステージング環境と本番環境でそれぞれS3バケット一つの作成を例とします。具体的な操作手順は以下の通りです。

まず、ステージング環境と本番環境用workspaceを作成

※Terraformのワークスペースとは？ワークスペースのコマンド一覧

• ステージング環境のワークスペースを作成

$ terraform workspace new staging
Created and switched to workspace "staging"!
You're now on a new, empty workspace. Workspaces isolate their state,
so if you run "terraform plan" Terraform will not see any existing state
for this configuration.

• 本番環境用ワークスペースを作成

$ terraform workspace new prod
Created and switched to workspace "prod"!
You're now on a new, empty workspace. Workspaces isolate their state,
so if you run "terraform plan" Terraform will not see any existing state
for this configuration.

• ワークスペース一覧を確認

$ terraform workspace list
default
* prod
staging

• ステージング環境を作業中にします。

$ terraform workspace select staging
Switched to workspace "staging".

ステージングと本番用awsアカウント情報を設定

• aws認証情報ファイル(~/.aws/credentials)の中、以下のようにステージングと本番用アクセスキーを設定します。

$ vi ~/.aws/credentials
[stg]
aws_access_key_id = xxxxxx
aws_secret_access_key = xxxxxxxxxxxxxxxxxxx
region = ap-northeast-1
[prod]
aws_access_key_id = xxxx
aws_secret_access_key = xxxxxxxxxxxxxxxxxxx
region = ap-northeast-1

• main.tfというファイルを作成し、以下のようにアカウントを切り替えします。

$ vi main.tf
provider "aws" {
  region = "ap-northeast-1"
  profile = "${terraform.workspace == "staging"? "stg" : "prod"}"
}

簡単に説明すると、選択さらたワークスペースによってステージングと本番のプロフィルを使い分けます。

S3バケットを作成します

• ステージング環境と本番環境用変数を作成します。

$ vi staging.tfvars
bucket_name = "stg-workspace-test"

$ vi prod.tfvars
bucket_name = "workspace-test"

• バケットを作成するため、s3.tfというファイルを作成します。

$ vi s3.tf
variable "bucket_name" {}
resource "aws_s3_bucket" "example" {
  bucket = "${var.bucket_name}"
  acl = "private"
}

まず、ステージング環境で作成します。

• 初期化します。

$ terraform init
Initializing provider plugins...

• 実行します

$ terraform workspace select staging && terraform apply -var-file=staging.tfvars
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
+ aws_s3_bucket.example
id: <computed>
acceleration_status: <computed>
acl: "private"
arn: <computed>
bucket: "stg-workspace-test"
bucket_domain_name: <computed>
bucket_regional_domain_name: <computed>
force_destroy: "false"
hosted_zone_id: <computed>
region: <computed>
request_payer: <computed>
versioning.#: <computed>
website_domain: <computed>
website_endpoint: <computed>

Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions in workspace "staging"?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes

上記、簡単に説明すると、まずstaging環境を選んで、設定ファイルstaging.tfvarsを適用した上でterraformを実行します。

本番環境で実行します。

ステージング環境で似てようで、以下のコマンドを使って本番でも実行します。

$ terraform workspace select prod && terraform apply -var-file=prod.tfvars

terraformで特定のリソースだけを削除/作成する

terraformで特定なリソースを削除

terraformでウェブアプリケーションのインフラを構築しました。
検証中にとあるリソースの設定にミスがあることに気づきました。すべて削除して再構築するには時間が…
terraformで特定のリソースだけを削除することができます。

以下、terraformで特定のresourceを削除する方法を紹介します。

以下のバケットの削除を例とします。

resource "aws_s3_bucket" "s3-example" {
    bucket = "${local.name_prefix}-example"
    acl    = "private"
}

オフィシャルサイトのドキュメントを読んだところ、特定のリソースを削除する時にオプション-target RESOURCE_TYPE.NAMEを追加するだけです。
でしたら以下のコマンドを試してみました。

$ terraform destroy --target aws_s3_bucket.s3-example

見事に上記のバケットだけが削除されました。
おまけに、複数のリソースを指定して削除を行う場合は複数回-targetfsオプションをつけることで一回の操作で複数のリソースを削除することができます。

terraform destroy -target RESOURCE_TYPE.NAME -target RESOURCE_TYPE2.NAME

terraformで特定なリソースを作成

terraformで特定なリソースを作成したい場合は削除と同じく-targetをつけます。例：

$ terraform apply --target aws_s3_bucket.s3-example

terraform workspaceとは？

terraformのworkspaceとは？

簡単に言うと、terraformで行った操作や、状態のデータなどを保持する場所です。

terraform workspaceのコマンド一覧は以下の通りです。

$ terraform workspace -h
Usage: terraform workspace

  New, list, show, select and delete Terraform workspaces.

Subcommands:
    delete    Delete a workspace
    list      List Workspaces
    new       Create a new workspace
    select    Select a workspace
    show      Show the name of the current workspace

• terraform workspace delete:ワークスペースを削除
• terraform workspace list:ワークスペースの一覧を表示する
• terraform workspace new:ワークスペースを新規作成
• terraform workspace select:ワークスペースを選択する
• terraform workspace show:現在作業中(選択された)ワークスペースの名前を表示

terraform initで最初にワークスペースを初期化した直後に、defaultという名前のワークスペースが作られます。

terraformでRoute53にレコードを追加しようとしたら、「but it already exist」のエラーが発生しました

terraformを使って、Route53にロードバランサーのレコードを追加しようとしたら、エラーが起きました。
使ったソースコードは以下の通りです。

resource "aws_route53_record" "www" {
  zone_id = "Z1234txxxxx"
  name    = "test.com"
  type    = "A"

  alias {
    name                   = "${aws_lb.elb.dns_name}"
    zone_id                = "${aws_lb.elb.zone_id}"
    evaluate_target_health = true
  }
}

調査したところ、タイプ「A」のレコードは一件しか存在できないです。追加ではなく、もし古いレコードが存在していればそれを削除しておく必要があります。
解決方法はとても簡単です。
引数allow_overwrite = trueを追加すれば、もしレコードが存在している場合は上書きしてくれます。
変更後のソースコードは以下になります。

resource "aws_route53_record" "www" {
  zone_id = "Z1234txxxxx"
  name    = "test.com"
  type    = "A"
  allow_overwrite = true

  alias {
    name                   = "${aws_lb.elb.dns_name}"
    zone_id                = "${aws_lb.elb.zone_id}"
    evaluate_target_health = true
  }
}

aws cliでインターネットゲートウェイを削除するコマンド

一つのVPCの中、インターネットゲートウェイが一つしか作れないです。

自分が間違って2回作成コマンドを押してしまいました。そしたら以下のようにエラーが起きました。

* aws_internet_gateway.gw: error attaching EC2 Internet Gateway (igw-094efbee9f367a97a): Error attaching internet gateway: InvalidParameterValue: Network vpc-43332a1a already has an internet gateway attached

status code: 400, request id: befcb4ad-c9a6-4a08-9622-0686b048a69b

detached状態なインテーネットゲートウェイを削除するには、もちろんコンソール上からできますが、いちいちコンソールにログインするのは少し手間なので、コマンドで削除します。
コマンドは以下の通りになります。

$ aws ec2 delete-internet-gateway --internet-gateway-id igw-c0a643a8

おまけに、本操作ではなく事前動作検証をしたいなら、--dry-run をつければ動作可能かどうかをチェックしてくれます。

aws 失敗したNATゲートウェイを削除する方法

AWSのNATゲートウェイ作成に失敗すると、コンソールから削除できなくなります。

削除するにはaws cliからするしかないです。
削除するコマンドは以下の通りです。

aws ec2 delete-nat-gateway --nat-gateway-id nat-04ae55e711cec5680

Golang言語でAWS SESを介してメールを送信する方法

Golangで開発したウェブアプリケーションからメール送信機能が必要になりました。インフラはAWS上にあるので、AWS SES(Simple Email Service)を使うことにしました。AWS SESサービスの開始から、Golangで送信までの手順をまとめてみました。

SESサービスを開始

AWSのSimple Email Serviceコンソール画面を開きます。
最初はリージョン選択になります。日本リージョンがないので、３つから任意の一つを選びます。

ドメイン認証

左メニュー「Domains」/「Verify a New Domain」順にドメイン認証画面を開きます。
自分のドメインを入力し、「Generate DKIM Settings」もチェックします。

確認画面の「Use Route 53」ボタンをクリックします。

Use Route 53画面の「Create Record Sets」ボタンをクリックします。
※一つ注意してほしいのは、もし「Email Receiving Record」にチェックを入れたら、MXタイプのレコードが全部上書きされることになります。回避するにはここでチェックを外して、Route 53の管理画面から手動でレコードを追加することです。

Route53の管理画面に、対象ドメインに先程のレコードが追加されたことを確認できます。
そのまましばらく待つと、認証ステータスが「verified」に変わります。

「FROM Domain」の設定

FROMドメインを設定しないと、メールの送信元はamazonses.comとなってしまいます。以下の手順で自分のドメインに変えられます。
「Domains」/「対象ドメイン名」/「MAIL FROM Domain」/「Set MAIL FROM Domain」の順にクリックします。
FROMドメインの設定画面に、MAIL FROMドメインの名前を入力します。例：info
そして、「Use amazonses.com as MAIL FROM」をチェックします。

次の画面に、「Publish Records Using Route 53」ボタンをクリックします。

更に次のUse Route 53画面に、「MX Record」と「SPF Record」にチェックを入れて、「Create Record Sets」ボタンをクリックします。

前のステップと同じくしばらく待つと、ステータスが「pending verification」から「verified」に変わります。

最後、サンドボックスの外への移動

サンドボックスから"脱出"するに、上限申請が必要です。
「Sending Statistics」/「Request a Sending Limit Increase」の順に申請画面に移動します。

申請する上限数のところに、自分の負荷に応じで必要な数値を入力します。
申請後1日、2日を待ってば処理されます。

ちなみに、申請が通りまでに、テストメールを送信すると、以下のエラーが起きます。

Email address is not verified. The following identities failed the check in region US-EAST-1: test@gmail.com (Request ID: 32301551-966e-462e-bdab-6a23ef58f6a4)

最後、Golangで送信する

まず、以下の４つのパッケージをインストール

  go get github.com/aws/aws-sdk-go/aws

  go get github.com/aws/aws-sdk-go/aws/credentials

  go get github.com/aws/aws-sdk-go/aws/session

  go get github.com/aws/aws-sdk-go/service/ses

次に、メールを送信(送信部分のソースコードのみ)

awsAccessKey := "awsのアクセスキー"
awsSecretKey := "awsのシークレットキー"
awsSession := session.New(&aws.Config{
Region:      aws.String("us-east-1"),
Credentials: credentials.NewStaticCredentials(awsAccessKey, awsSecretKey, ""),
})
client := ses.New(awsSession)
input := &ses.SendEmailInput{
Destination: &ses.Destination{
ToAddresses: []*string{
aws.String("送信先のメールアドレス"),
},
},
Message: &ses.Message{
Body: &ses.Body{
Text: &ses.Content{
Charset: aws.String("UTF-8"),
Data:    aws.String("メール本文"),
},
},
Subject: &ses.Content{
Charset: aws.String("UTF-8"),
Data:    aws.String("メール件名"),
},
},
Source: aws.String("送信元のメールアドレス"),
}
_, err := client.SendEmail(input)

AWSの外部からAWSのredisに接続可能にする方法

ローカル開発環境構築するため、自分のローカルPC（AWSの外）からAWS redisに接続する必要になりました。
調べたところ、aws redisはVPCのプライベートサブネットに作られているため、外部からの直接接続は不可能です。
踏み台用インスタンス(NATインスタンス)を立てて、アクセス転送の仕組みを使えばなんとかなることがわかりました。
具体的なやり方は以下にまとめました。

NAT用セキュリティグループを作成

EC2コンソール画面から「セキュリティグループ」/「セキュリティグループの作成」の順に操作します。

「インバウンド」タブから「ルールの追加」をクリックして、以下の２つルールを追加します。

・SSH　TCP　 22　自分のローカルIP

・カスタムTCP　TCP　6379　自分のローカルIP

NAT用インスタンスを作成

「AMIの選択」画面、左メニュー「コミュニティAMI」を選択、「amzn-ami-vpc-nat-hvm」を入れて検索します。

出てきた一番最新バージョンのamiを選択します。
PS:自分は最初普通のインスタンスを使っていたが、iptablesの設定など結構苦戦して結局設定できなかったです。やはり用意されたものを使うのが一番です。もしiptablesの設定に詳しいなら、通常のインスタンスでも大丈夫かと思います。

「インスタンス詳細の設定画面」、「自動割当てパブリックIP」を有効にします。

セキュリティグループの設定

前のステップで作成したNAT用セキュリティグループと「default VPC security group」を両方選びます。（２つ同時設定するのは大事！）

NAT インスタンスのSrcDestCheck属性を無効にします。

インスタンス一覧に対象インスタンスをチェックし、「アクション」／「ネットワーキング」／「送信元/送信先の変更チェック」の順に無効化します。

NATインスタンスにiptablesルールを追加

ローカルから作成したNATインスタンスにsshします。

NATインスタンスからのアクセスをRedisに転送するため、以下のiptablesルールを追加します。

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 6379 -j DNAT --to redisサーバのIPアドレス:6379

redisサーバのIPアドレスを知る方法はまずElastiCacheダッシュボード/Redis/対象クラスター名の画面からredisサーバのホスト名を取得します。次にhostコマンドでサーバのIPアドレスを取得します。ドメインからIPアドレスを逆引き方法について

service iptables statusコマンドでルールが追加されたことを確認します。

# service iptables status
Table: nat
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination      
1    DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:6379 to:172.31.78.185:6379

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination      

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination      

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination      
1    MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0

ローカルから接続確認

これで準備が整いましたので、ローカルから接続してみます。

telnet NATインスタンスのパブリックIP 6379

macにTerraformをインストールする方法

まず、Terraformの公式ダウンロードページから対応OSのパッケージをダウンロードします。

ファイルダウンロード後解凍します。そしたらterraformという名前のファイルが表示されます。

前のステップで獲得した「terraform」ファイルを自分のPATHディレクトリーにコピーあるいは移動します。

PATHディレクトリーを確認するには、echo $PATHコマンドを使います。

$ echo $PATH
 /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

上記のように、PATHディレクトリーが表示されました。
自分の場合はファイルを/usr/local/binにコピーしました。

最後動作確認

terraform --versionをうつとバージョン情報が表示されるはずです。

$ terraform --version
 Terraform v0.12.7

aws s3、とあるバケット、特定のIPからのみを許可する方法

コンソールから対象バケットを選んで、「アクセス権限」→「バケットポリシー」の順にポリシーエディターを開きます。
以下の内容を入力して保存します。

{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Sid": "IPAllow",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::対象バケット名前/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "192.168.143.3/24"
                }
            }
        }
    ]
}

設定画面は以下のように↓

さらに、複数IPからのみを許可するの場合「IpAddress」のところに以下のように複数を入れます。

"IpAddress": {
                    "aws:SourceIp": [
                        "192.168.143.3/24",
                        "202.3.245.201/32"
                    ]
                }

aws CodeDeployによりデプロイ失敗調査メモ

CodeDeployを使ってデプロイを行ってみましたが、失敗しました。調査した経過をメモしておきます。

まず、Console上のエラーを確認します。
The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems.
それをみてもよくわからないので、EC2にログインして、codedeployエージェントのログを確認します。

>less /var/log/aws/codedeploy-agent/codedeploy-agent.log

そしたら、以下のようなエラーが大量に出力されてました。

/opt/codedeploy-agent/bin/../lib/codedeploy-agent.rb:90:in `<main>'
2019-08-02 07:00:49 ERROR [codedeploy-agent(2040)]: booting child: error during start or run: SystemExit - exit - /opt/codedeploy-agent/lib/instance_agent/runner/child.rb:90:in `exit'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:90:in `rescue in with_error_handling'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:78:in `with_error_handling'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:31:in `prepare_run'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:64:in `block in prepare_run_with_error_handling'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:78:in `with_error_handling'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:63:in `prepare_run_with_error_handling'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:20:in `start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:206:in `block in spawn_child'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:204:in `fork'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:204:in `spawn_child'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:196:in `block in spawn_children'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:195:in `times'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:195:in `spawn_children'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:134:in `start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:37:in `block in start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:36:in `fork'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:36:in `start'
/opt/codedeploy-agent/bin/../lib/codedeploy-agent.rb:43:in `block (2 levels) in <main>'
/opt/codedeploy-agent/vendor/gems/gli-2.11.0/lib/gli/command_support.rb:126:in `call'
/opt/codedeploy-agent/vendor/gems/gli-2.11.0/lib/gli/command_support.rb:126:in `execute'
/opt/codedeploy-agent/vendor/gems/gli-2.11.0/lib/gli/app_support.rb:284:in `block in call_command'
/opt/codedeploy-agent/vendor/gems/gli-2.11.0/lib/gli/app_support.rb:297:in `call'
/opt/codedeploy-agent/vendor/gems/gli-2.11.0/lib/gli/app_support.rb:297:in `call_command'
/opt/codedeploy-agent/vendor/gems/gli-2.11.0/lib/gli/app_support.rb:79:in `run'
/opt/codedeploy-agent/bin/../lib/codedeploy-agent.rb:90:in `<main>'
2019-08-02 07:00:49 INFO  [codedeploy-agent(2036)]: master 2036: Received CHLD - cleaning dead child process
2019-08-02 07:00:49 INFO  [codedeploy-agent(2036)]: master 2036: been told to replace child 2040
2019-08-02 07:00:49 INFO  [codedeploy-agent(2036)]: master 2036: not enough child processes running - missing at least 1 - respawning
2019-08-02 07:00:49 INFO  [codedeploy-agent(2036)]: Started master 2036 with 1 children
2019-08-02 07:00:54 INFO  [codedeploy-agent(2036)]: master 2036: Spawned child 1/1
2019-08-02 07:00:54 INFO  [codedeploy-agent(2513)]: On Premises config file does not exist or not readable
2019-08-02 07:00:54 INFO  [codedeploy-agent(2513)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandExecutor: Archives to retain is: 5}
2019-08-02 07:03:06 ERROR [codedeploy-agent(2513)]: InstanceAgent::Plugins::CodeDeployPlugin::CodeDeployControl: Error during certificate verification on codedeploy endpoint https://codedeploy-commands.ap-northeast-1.amazonaws.com
2019-08-02 07:03:06 ERROR [codedeploy-agent(2513)]: Error validating the SSL configuration: Invalid server certificate
2019-08-02 07:03:06 ERROR [codedeploy-agent(2513)]: booting child: error during start or run: SystemExit - Stopping CodeDeploy agent due to SSL validation error. - /opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_poller.rb:64:in `abort'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_poller.rb:64:in `validate'
/opt/codedeploy-agent/lib/instance_agent/agent/base.rb:11:in `runner'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:32:in `block in prepare_run'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:78:in `with_error_handling'

どうやっらインスタンスから外部に接続が失敗したようです。

ping google.co.jp

案の定失敗しました。ネットワーク接続を確認したとろこ、ルートテーブルの設定が足りてなかったです。ルートを追加したらうまくインテーネットに接続ができて、デプロイもできるようになりました。

redisにデータを入れようとしたら、エラーが発生しました。(error) READONLY You can't write against a read only replica.

AWSのElastiCacheでredisタイプのサーバを作ってみました。

以下のコマンドで、telnetを入れて接続しました。

$ sudo yum install -y telnet
telnet test-myredis-for-web-ro.5irjbr.ng.0001.apne1.cache.amazonaws.com 6379

いざデータを入れようとしたら、エラーが発生しました。

$-1

set hoge hogehoge

-READONLY You can't write against a read only replica.

調査したところ、awsはデフォルト３つのノートを作成されるらしいです。
一つ「primary」と２つ「replica」が作られます。
書き込み用として使えるのは「primary」のみです。

「primary」用エンドポイントを使って再度接続し、データを入れてみたら、問題が解消できました。
以下↓「primary」用ノートのエンドポイントとなります。

s3、特定のバケットに対して外部からのアクセス（閲覧のみ）を許可設定

まず、バケット作成から

S3のコンソールから、「バケットを作成する」をクリックします

バケット名は「test-open-to-public」と入力

プロパティはデフォルトのままで進みます

「アクセス許可の設定」に上の２つをチェックする。後でポリシーを追加できるため、下の２つを外しておきます。

新しいアクセスコントロールリスト (ACL) を介して許可されたバケットとオブジェクトへのパブリックアクセスをブロックする

任意のアクセスコントロールリスト (ACL) を介して許可されたバケットとオブジェクトへのパブリックアクセスをブロックする

最後「バケットを作成」ボタンを押します。

作成したバケットに対して、アクセス権限を設定します。

「アクセス権限」→「バケットポリシー」の順にバケットポリシーエディター画面を開きます。

以下のソースコードを貼り付けした後、「保存」ボタンを押します。

※注意してほしいのは、「Resource」のところ、自分のバケット名に書き換えるが必要です。

{     "Version": "2008-10-17",     "Statement": [         {             "Sid": "AllowPublicRead",             "Effect": "Allow",             "Principal": {                 "AWS": "*"             },             "Action": "s3:GetObject",             "Resource": "arn:aws:s3:::test-open-to-public/*"         }     ] }