20210430のAWSに関する記事は22件です。

AWS日記26 (AWS Fargate)

はじめに 今回は AWS Fargate を試します。 スケジュールでタスクを実行する機能を作ります。 今回作成した SAMテンプレート 準備 AWS SAM の準備をします AWS Fargateの資料 Fargate を使用した Amazon ECS の開始方法 Dockerの資料 Docker ドキュメント 作業手順の概略 Dockerfile作成 管理コンソールのAmazon ECR リポジトリからイメージリポジトリの作成 「プッシュコマンドの表示」の手順に従い Docker Image を作成、プッシュ AWS SAM アプリケーションをデプロイ Dockerfile作成 FROM golang:alpine COPY main.go /go/ AWS SAM テンプレート作成 AWS SAM テンプレートで ECS , CloudWatch の設定をします。 [参考資料] AWS SAM テンプレートを作成する AWS ECSの設定は以下の部分 Cluster: Type: AWS::ECS::Cluster Properties: ClusterName: !Ref ProjectName TaskDefinition: Type: AWS::ECS::TaskDefinition Properties: Family: !Ref ProjectName RequiresCompatibilities: - FARGATE Cpu: !Ref TaskCpu Memory: !Ref TaskMemory NetworkMode: awsvpc ExecutionRoleArn: !GetAtt EcsTaskExecutionRole.Arn TaskRoleArn: !GetAtt EcsTaskRole.Arn ContainerDefinitions: - Name: app Image: !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${ProjectName} EntryPoint: - 'sh' - '-c' Environment: - Name: TZ Value: Asia/Tokyo LogConfiguration: LogDriver: awslogs Options: awslogs-region: !Ref 'AWS::Region' awslogs-group: !Ref LogGroup awslogs-stream-prefix: app Essential: true 終わりに AWS Fargate を使用し、スケジュールでタスクを実行する機能を作りました。 ECS Exec を利用したコンテナへのアクセスも行える為、今後試そうと思います。 参考資料 CloudFormationを使ってAWS Fargateの環境を構築する ECS Fargate 楽々構築テンプレート CloudformationでFargateを構築する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

S3コンテンツをCloudFrontでHTTPS配信(独自ドメイン)してみた

目次 1.はじめに 2.前提 3.s3コンテンツの準備 4.acmの証明書発行 5.cloudfrontディストリビューションの作成 6.route53のレコード設定 7.cloudfrontのoai設定 8.まとめ はじめに 静的コンテンツを配信する方法として、S3の「静的Webサイトホスティング」があります。設定が簡単で使いやすい機能ではありますが、こちらを有効にした場合、公開されるS3バケットのURLは「http://[バケット名].s3-website-[region].amazonaws.com/~」となり、S3までの通信がHTTPとなります。今回、よりセキュアなHTTPS通信での配信が可能な、CloudFrontとACM (AWS Certificate Manager)を使用した環境を構築しましたので、おおまかな手順を残しておきたいと思います。 前提 今回、構築したAWS環境の構成は以下の通りとなります。 以降の構築手順における前提を記載します。 無料で使用できるドメインプロバイダ「Freenom」で独自ドメインを取得済 ※ 今回は「aws-uni.ga」 Freenomで取得したドメインに対するRoute53のパブリックホストゾーンを作成済 Freenomのマイドメイン管理画面でNameServerにAWS Route53のDNSサーバを指定済 ※ Route53:パブリックホストゾーンの設定 上記のような前提のもと、CloudFrontとACMを使用したHTTPS配信環境を構築しましたので、おおまかな手順をまとめていきます。 s3コンテンツの準備 S3バケットの作成 まずは今回、CloudFrontで配信するコンテンツを格納するためのS3バケットを作成します。 S3の画面から「バケットを作成」を押下する。 以下のバケット設定を行い、画面右下のバケットを作成」を押下する。 ・バケット名を入力 ※ 取得した独自ドメイン名を入力した。 ・AWSリージョンを選択 ※ 東京リージョンとした。 ・「パブリックアクセスをすべてブロック」にチェックが入っていることを確認 バケットが作成されたことを確認し、名前の部分を押下する。 S3コンテンツのアップロード バケットが空の状態であることを確認し、「アップロード」を押下する。 アップロード画面に遷移するので、「ファイルを追加」を押下する。 アップロードしたいファイルを選択の上、右下の「アップロード」を押下する。 S3バケットにファイルがアップロードされたことを確認する。 以上で、S3コンテンツの準備は完了になります。 acmの証明書発行 続いて、ACM (AWS Certificate Manager)にて証明書を発行していきます。 ACMの画面にて、「証明書のプロビジョニング」の「今すぐ始める」を押下する。 ※ CloudFront ディストリビューションに関連付ける SSL 証明書は「米国東部 (バージニア北部) (us-east-1)」 リージョンで実施する必要がある。 「パブリック証明書のリクエスト」にチェックが入っていることを確認し、「証明書のリクエスト」を押下する。 「ドメイン名」を入力し、「次へ」を押下する。 ※ 今回は独自ドメイン「aws-uni.ga」を入力した。 検証画面の選択に遷移するので、「DNSの検証」にチェックが入っていることを確認し、「次へ」を押下する。 タグの追加画面に遷移するので、必要に応じて、「タグ名」と「値」を入力し、「確認」を押下する。 確認画面に遷移するので、内容に問題がなければ「確定とリクエスト」を押下する。 指定したドメインにて、検証状態が「検証保留中」になる。ドメインのDNS設定にCNAMEレコードを追加すべく、「Route53でのレコードの作成」を押下する。 右下の「作成」を押下する。 Route53でCNAMEレコードが作成されると、ドメインの検証状態が「成功」になり、証明書の状況も「発行済み」となる。 以上で、ACMの証明書発行は完了になります。 cloudfrontディストリビューションの作成 続いて、CloudFrontディストリビューションの作成をしていきます。 CloudFrontの「Distribution」画面にて、「Create Distribution」を押下する。 「Get Started」を押下する。 ディストリビューションの作成画面に遷移するので、「Origin Settings」にて、オリジンの設定をしていく。「Origin Domain Name」にて今回作成したS3バケットを選択する。「Origin ID」は自動入力される。その他の項目は必要に応じて設定する。 「Defalut Cache Behavior Settings」ではキャッシュに関わる設定などができるが、今回はデフォルトの設定とする。 「Distribution Settings」でディストリビューションの設定をしていく。「Alternate Domain Names」に、ユーザがコンテンツにアクセスする際のドメイン名を入力する。「SSL Certificate」では「Custom SSL Certificate」にチェックを入れ、ACMで発行した証明書を選択する。 「Defalut Root Object」でS3バケットにアップロードしたHTMLファイル名を入力する。 その他はデフォルトの設定とし、右下の「Create Distribution」を押下する。 CloudFrontディストリビューションが作成され、「Status」が「Deployed」、Stateが「Enabled」となることを確認する。 以上で、CloudFrontディストリビューションの作成は完了になります。 route53のレコード設定 続いて、Route53のレコード設定をしていきます。 独自ドメインのホストゾーン設定画面にて、上記、「ACMの証明書発行」手順内で作成された「CNAME」レコードが存在することを確認し、「レコードを作成」を押下する。 以下の通り、レコードの設定をし、「レコードを作成」を押下する。 ・レコード名を入力 ※ 今回は入力せずドメイン名のままとした。 ・レコードタイプにてAレコードを選択 ・ルーティングポリシーを選択 ※ 今回はシンプルルーティングを選択した。 ・トラフィックのルーティング先を選択 ※上記、「CloudFrontディストリビューションの作成」手順内で作成したディストリビューションのドメイン名を選択する。 CloudFrontディストリビューションのAレコードが作成されたことを確認する。 以上で、Route53のレコード設定は完了となります。 cloudfrontのoai設定 諸々の設定が完了したので、ブラウザにて「ドメイン名」でアクセスを試みる。   →「AccessDenied」となり、S3にアップロードしたコンテンツが表示されない。これは現在、作成したS3バケットに、アクセスのためのポリシーが設定されていないからである。そこで今回、CloudFront経由でのみS3バケットにアクセスができるように、OAIの設定をしていく。 CloudFrontで作成したディストリビューションのIDを押下する。 「Origin and Origin Groups」タブで「Edit」を押下する。 以下の通り、OAIの設定を行い、右下の「Yes,Edit」を押下する。 ・「Restrict Bucket Access」で「Yes」を選択 ・「Origin Access Identity」で「Create a New Identity」を選択 ・「Comment」は自動入力される ・「Grant Read Permissions on Bucket」にて「Yes, Update Bucket Policy」を選択 ディストリビューションにてOAIが設定されたことを確認する。 S3のバケットポリシーにOAIの設定が反映されたことを確認する。 ブラウザにて独自ドメインのHTTPSアクセスを試みる。 →S3バケットへアップロードしたコンテンツをCloudFront経由で表示することができた。 以上で、CloudFrontのOAI設定は完了となります。 まとめ 以上より、CloudFrontとACMを使用したHTTPS配信環境を構築することができました。 今回の構築では、CloudFront設定はおおよそデフォルトのまま進めたので、細かいキャッシュの設定などはまた別の記事としてまとめていけたらなと思います。 以上、最後まで読んで頂きありがとうございました! ※この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」の課題カリキュラムで作成しました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSとWordPressを使ってWebサイトを構築しよう④

■VPC・Public subnetを構築しよう! いよいよ実際に手を動かしてAWSを使ってネットワークを構築していきましょう。 目次 1.AWSアカウント作成 2.VPC作成 3.サブネットの作成 4.なぜサブネットを作る必要があるのか 5.パブリックサブネットの作成 6.【おまけ】「冗長性」とは 1. AWSアカウント作成 まずAWSアカウントを作成しましょう。 下記URLにAWSアカウントの作成方法が記載してありますのでこちらを参考にアカウント作成を行ってください。 https://aws.amazon.com/jp/register-flow/ AWSアカウントが作成できたら下記URLからAWSマネジメントコンソールにアクセスしましょう。 https://aws.amazon.com/jp/console/ 2. VPC作成 「VPC」とはAWSアカウントに紐づいたプライベートな仮想ネットワークのことです。 このVPC上に今後作成する「EC2」などのサービスを構築していきます。 マネジメントコンソールへアクセスできたら下記の画像のように、検索バーへ「VPC」と入力してください。 「VPC」と入力したら下記画像のようにサービス一覧に表示された「VPC」をクリックしてください。 (ちなみにシステムエンジニアの世界ではクリックと似た言葉で「押下」という言葉を使うこともあります。クリックだとマウスのボタンを”押して離す”動作ですが、押下は”押す動作のみ”になります。) VPCを選択したら次はリージョンの選択です。 リージョンとは世界中に配置されたデータセンター群の事で、現時点(2021/03/27時点)では世界25か所に分かれて存在しています。 今回は東京リージョンにネットワークを構築していきますので「アジアパシフィック(東京)」をクリックしてください。 次はVPC領域を作成していきます。 マネジメントコンソール左側にあるメニューの中から「VPC」をクリックしてください。 既に最初から「デフォルトVPC」というVPCが作成されていますが、新しくVPC を作成していきます。 「VPCの作成」をクリックしてください。 VPCの作成画面にて下記のように入力していきましょう。 ・名前タグ:VPC  →これから作成するVPC領域の名前を入力 ・IPv4 CIDR ブロック:10.0.0.0/16  →VPC領域で使うIPアドレスを指定 (「IPv6 CIDR ブロック」は今回使用しないので「IPv6 CIDR ブロックなし」でOKです。「テナンシー」はハードウェアの占有をするかどうかの設定で、これを設定することで物理サーバーを占有し他人が物理サーバー上に仮想サーバーを建てられないようにできます。占有するには費用が発生するので注意してください。今回は占有はせずにデフォルト設定で構築します。) これらを入力したら「作成」ボタンをクリックしてください。 3. サブネットの作成 さてこれでVPC領域の作成ができました。 今度は作成したVPC領域をさらに細かく分けていきサブネットを作成しましょう。 「サブネット(subnet)」とは割り当てたCIDRブロックをさらに細分化したCIDRブロックのことを言います。 実際のネットワークでは割り当てたCIDRブロックをそのまま用いることなく細分化して使用することがほとんどです。 なので今回もパブリックサブネットとプライベートサブネットに分割して作成します。 さきほど「10.0.0.0/16」のCIDRブロックを作成しVPC領域として割り当てましたが、このCIDRブロックを「10.0.0.0/24」という形でさらに細かく分けてサブネットを作成します。 「10.0.0.0/24」なので使用できるIPアドレスの範囲は「10.0.0.0~10.0.0.255」になります。 (VPCに割り当てた「10.0.0.0/16」のIPアドレスの範囲は「10.0.0.0~10.0.255.255」だったのでサブネットの方が細かく別れているのが分かります。) 4. なぜサブネットを作る必要があるのか そもそもなぜサブネットを作成しなきゃいけないのか? 「さっき作ったVPC領域だけじゃダメなの?」 と思われるかもしれませんがサブネットを作るメリットがあります。 1、障害が起きた時に影響が出づらくなる 同じVPC内に複数のサーバーを作成して、もし何かが原因で障害が起きた時に原因を突き止めようと思っても調査対象が多く原因を調べるのに時間がかかってしまいます。 しかしサブネットを作成し、それぞれのサブネットにサーバーを作成しておけばどちらかのサブネット内で障害が起きても原因の切り分けができて調査が楽になります。 さらにどちらかのサブネット内で障害が起きたとしても片方のサブネットには影響が出づらくなります。 2、セキュリティ面 今回作成していく構成もそうですがセキュリティ面においてDBサーバーやファイルサーバーなどのデータを扱っているサーバーをインターネットからアクセスできる状態にしてしまうと、もしサイバー攻撃に遭ってしまった場合にデータを盗まれてしまう恐れがあります。 これが企業だった場合は情報漏洩に当たり社会的に大きなダメージを負ってしまいます。 なのでこれを防ぐためにデータを扱うサーバーはインターネットからアクセスできない状態にしてセキュリティを高めます。 前置きが長くなりましたが早速サブネットを作成しましょう。 下記の画像のようにパブリックサブネット(10.0.1.0/24)と、プライベートサブネット(10.0.2.0/24)を作っていきますが、まずはパブリックサブネットを作成していきましょう。 5. パブリックサブネットの作成 マネジメントコンソールの検索バーへ「VPC」と入力し、VPCの設定画面へ移動してください。 左のメニューから「サブネット」をクリックしてください。 既にデフォルトのサブネットが作成されていますが、新しくサブネットを作成するので「サブネットの作成」をクリックしてください。 「サブネットを作成」の画面へ移行したら下記のように入力してください。 ・VPC ID:グレー色で「10.0.0.0/16」と書かれたVPCを選択  →さきほど作成したVPCを選択します。 ・サブネット名:Public_subnet  →サブネットの名前を命名します。ここでは「Public_subnet」とします。 ・アベイラビリティゾーン:指定なし  →「指定なし」の場合はランダムでアベイラビリティゾーンが作成されます。(アベイラビリティゾーンとはリージョン内に置かれたデータセンターのことで、東京リージョンであれば3つのアベイラビリティゾーンが存在しており各アベイラビリティゾーンはそれぞれ完全に独立し、地理的に離れた距離に設置されています。 そうすることで例えば1つのアベイラビリティゾーンに障害が起こったとしても、他の2つは正常に稼働することができAWS利用者は安心してサービスを作成することができます。) ・IPv4 CIDR ブロック:10.0.1.0/24  →パブリックサブネットには「10.0.1.0/24」を割り当てます。 全て入力できたら「サブネットの作成」をクリックしてください。 これでパブリックサブネットの作成が完了しました。 6. 【おまけ】「冗長性」とは 最近ではシステム障害でシステムが停止してしまった、と言ったニュースが報道されています。 このような障害を防ぐための考え方の1つとして「冗長化」があります。 一般用語としてではなくIT用語として冗長化とは、同じ機能を持つサーバーなどを複数用意しシステム障害によって一部の機能が停止しても全体は動くように構成することです。 例えばAWSで言えば「マルチAZ構成」というシステム構成があり、同じ機能を持つAZ(アベイラビリティゾーン)を複数用意し片方のAZに障害が発生した際に、もう片方の正常なAZを使用して稼働を継続させるという冗長化の方法があります。 このように冗長化によってシステムの安全性が向上した状態を「冗長性を持たせる」と表現します。 はい、今回はここまで! 「VPC」と「subnet」はAWSを触る上で基本中の基本になるので作成方法は押さえておきましょう。 次回はインターネットゲートウェイとルートテーブルを作成していきます。 次の記事でネットワークの構築がひと段落するので頑張っていきましょう! 次の記事はこちらから AWSとWordPressを使ってWebサイトを構築しよう⑤
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSとWordPressを使ってWebサイトを構築しよう③

■ネットワーク構築の前にIPアドレスを理解しよう 手を動かして実際に構築する前に最低限覚えておきたい知識として「IPアドレス」について学びましょう。 次回からは手を動かして実際に構築していきますので、今回は座学を頑張っていきましょう! 目次 1.ネットワークイメージ図 2.VPC領域 3.IPアドレスの構成 4.IPアドレスの表記方法 5.CIDR表記 1. ネットワークイメージ図 今回は以下の画像のようなネットワークを構築していきます。 構築内容 ・VPC領域 ・インターネットゲートウェイ ・パブリックサブネット ・プライベートサブネット ・ルートテーブル 2. VPC領域 VPCとは前回説明した通りネットワーク領域の事です。 VPCを構築するに当たってVPCにIPアドレスを割り振るので、まずはIPアドレスの概念を知る必要があります。 インターネットで使用されているプロトコル(ネットワーク上でコンピュータ同士が通信するための通信規約のこと)に「TCP/IP」と言うのがあります。 「TCP/IP」とは「Transmission Control Protocol」と「Internet Protocol」を組み合わせた機能で、通信先特定のために「IPアドレス」を使います。 3. IPアドレスの構成 IPアドレスとは簡単に言えばネットワーク上の住所のようなものです。 IPアドレスは「10.0.0.1」のように「.」で区切って構成されており、それぞれ8ビットで区切って10進数で表記されています。 よってIPアドレスで表記できる範囲は「0.0.0.0〜255.255.255.255」となっています。 IPアドレスにはインターネットへ接続する際に使われるパブリックIPアドレス(グローバルIPアドレスとも言う)と、インターネットで使われないプライベートIPアドレスがあります。 パブリックIPアドレスはプロバイダーやサーバー事業者に払い出してもらう必要があり自分で勝手に決めることはできません。 その逆でプライベートIPアドレスは下記のような決められた範囲内であれば自由に設定することが可能です。 「プライベートIPアドレスの範囲」 10.0.0.0~10.255.255.255 172.16.0.0~172.31.255.255 192.168.0.0~192.168.255.255 またIPアドレスにはバージョンがあり、現在主に使用されているのが「IPv4」です。 IPv4はIPアドレスを32ビットで表しており、使用できるIPアドレスの総数は「2×32乗個=42億9496万7296個」となります。 しかしインターネットの普及に伴い今後IPv4のアドレス数だけでは足りなくなるとされており、そこで誕生したのが「IPv6」です。 IPv6では使用できるIPアドレスの総数は「2×128乗個=340澗(かん)個」となり、事実上無限に使用できる数となっています。 ※今回はIPv6は使用しません。 4. IPアドレスの表記方法 ネットワーク構築する際に最初にすべきことはIPアドレスの範囲を決めることです。 IPアドレスの範囲は使用するサーバーや、クライアントや接続するネットワーク機器の数が余裕を持って納まるように設計します。 しかし「今回は10個だけ範囲を確保しよう」と思ってもできません。 なぜならIPアドレスの区切りの範囲は下記のように決まっています。 「4,8,16,32,64,128,256,512.....65536個」(2のn乗個で区切られている) 例えば下記のIPアドレスを256個で区切った場合を見てみましょう。 「192.168.2.0~192.168.2.255」 どのようにして区切られたのかと言うと下記のような考え方で区切っていきます。 1、256個は2の8乗 2、8乗なのでIPアドレスの最後から8ビットを数える(IPアドレスは「.」毎に8ビットで区切られている) 3、つまり「192.168.2」と「0~255」で区切られている。 この区切られた前半の部分をネットワーク部と言い、後半の部分をホスト部と言います。 ネットワーク部は同じネットワークに存在する機器と同じ値になります。 ホスト部は機器によってそれぞれ異なる値を割り振っていきます。 5. CIDR表記 もう一つIPアドレスの表記方法として知っておくべきCIDR表記について解説します。 上記で紹介した「192.168.2.0~192.168.2.255」このようなIPアドレスを表したい時に、これでは表記が長いのでIPアドレスを表記する方法として「CIDR表記」と「サブネットマスク表記」があります。(この記事では良く使われるCIDR表記を紹介します) 「192.168.2.0~192.168.2.255」このIPアドレスをCIDR表記で表す場合は下記のように表記します。 「192.168.2.0/24」 この「/24」のことを「プレフィックス」と言い、ネットワーク部のビット長を表しています。 つまり「192.168.2.0~192.168.2.255」のネットワーク部は「192.168.2」までで、これをビットで表すと24ビットになります。(8ビット毎に「.」で区切られているから) 16ビットで区切った場合だと以下のようになります。 「192.168.0.0~192.168.255.255」        ↓    「192.168.0.0/16」 またIPアドレスをCIDR表記で表したものを「CIDRブロック」と言います。 IPアドレスの概念については初めての方では少し難しいと思うかもしれません。 なのでここでもう一度今回構築するネットワーク図を見てもらうとわかりやすいと思います。 まずVPC領域としてIPアドレス「10.0.0.0/16」という範囲を割り振っています。 「10.0.0.0/16」のネットワーク部は「10.0.〇.〇」で、今回VPC領域内に各ネットワークやサーバーなど構築していくのでネットワークはすべて「10.0.〇.〇」の範囲内で作られます。 VPC領域内に構築するPublic subnetはVPC領域と同じネットワークなのでIPアドレスのネットワーク部も同じ「10.0.〇.〇」になります。 IPアドレスについて理解できましたでしょうか? 次回は学んだIPアドレスを使ってネットワークを構築していきましょう。 次の記事はこちらから AWSとWordPressを使ってWebサイトを構築しよう④
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSとWordPressを使ってWebサイトを構築しよう②

前回はWebサイトを構築していくために必要な「サーバー構築の考え方」と「ネットワーク構築の考え方」を学びました。 今回はどんなサーバー構成とネットワーク構成でWebサイト環境を構築するかについて解説していきます。 目次 1.全体の設計図 2.NATゲートウェイとは 3.インターネットゲートウェイとは 1. 全体の設計図 まずはこれから構築していくWebサイト環境の全体設計図を見ていきましょう。 上記の画像が今回構築していくサーバーとネットワークの全体図となります。 ・サーバー:「Webサーバー」と「DBサーバー」、この2つのサーバーを構築します。 ・ネットワーク:「VPC」、「Public subnet」、「Private subnet」を構築。 「VPC」→灰色のアイコンで「VPC」と書かれたネットワーク領域のこと。 「Public subnet」→緑色のアイコンで「Public subnet」と書かれたネットワーク領域のこと。こちらはインターネットに公開するネットワークとなります。 「Private subnet」→青色のアイコンで「Private subnet」と書かれたネットワークのこと。こちらはインターネットからは接続できないネットワークとなります。 ※subnetというのはVPCのネットワーク領域を分割して構築されたネットワークのことを言います。 そしてオレンジ色のアイコンがある「NATゲートウェイ」「インターネットゲートウェイ」も必要なので各種設定します。 2. NATゲートウェイとは NATゲートウェイとは「片方向からの通信のみ接続可能にする機能」です。NATゲートウェイを設定する理由として、DBサーバーはPrivate subnetのネットワーク内に配置するのでインターネットと接続することができません。 あえてDBサーバーがインターネットと接続できなくしている理由は外部から接続してデータが改ざんされるのを防ぐためです。 しかしインターネットと接続しインターネット上にあるソフトウェアをダウンロードしてきて、DBサーバーへインストールする必要があります。 この時にDBサーバーからインターネットへの通信のみ可能にする機能がNATゲートウェイなのです(DBサーバーからインターネットへ通信した時にインターネット側から返ってくる情報は通してくれます)。 3. インターネットゲートウェイとは インターネットと接続するために必要な機能です。 インターネットゲートウェイを設定することでインターネットと接続ができるようになります。 さて全体の設計図がわかったところで次回はネットワークの構築に必要なIPアドレスについて学びましょう! 次の記事はこちらから AWSとWordPressを使ってWebサイトを構築しよう③
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

マインドマップでAWSサービスを勉強【データ分析 – データ収集編】 第�一回:Kinesis Stream

AWSのデータ分析系のサービスを体系的に学ぶため、UdemyのAWS Certified Data Analytics Specialty 2021 - Hands onコースを受けました。 一般的なデータ分析流れに含まれるステップ、データ収集、データ保存、データ処理、データ分析、データ可視化に、それぞれが利用するサービスを学び、マインドマップに整理しました。 元々データ分析編を全て1つのマインドマップに整理したかったが、 サービスの利用には、Kinesis Data Streamだけでも把握しないといけないポイントが沢山ありました。。。 そのため、データ分析編は3回に分けてまとめたいと思います。 今回はKinesis Data Streamのまとめです。 ※ こちらの記事は、AWS クラウドサービス活用資料集とUdemyにあるAWS Certified Data Analytics Specialty 2021 - Hands onというコースを参照しております。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWSで始める異常検知】Part3. 異常検知に便利なAWS製品

Amazon Monitron センサー、ゲートウェイ、機械学習サービスで構成されるエンドツーエンドの機械モニタリングソリューションを提供し、メンテナンスが必要な機器の異常を検知 Amazon Lookout for Equipment 既存の機器センサーをご利用のお客様が AWS 機械学習モデルを使用できるようにし、機器の異常を検知および予知保全を実現 Amazon Lookout for Vision AWSが学習させたコンピュータビジョンモデルを元に、画像やビデオストリームを使って、製品もしくはプロセスの異常や欠陥を検出 Databricks 説明をかく その他 機械学習 推論の実行トリガー Amazon FreeRTOS 機械学習 推論の実行 AWS IoT Greengrass テレメトリーデータ収集 AWS IoT Core データ前処理と保存 AWS IoT Analytics 機械学習モデル構築 Amazon SageMaker 機械学習モデル保存 Amazon Simple Storage Service 参考 https://aws.amazon.com/jp/about-aws/whats-new/2020/12/aws-announces-five-industrial-machine-learning-services/ https://aws.amazon.com/jp/cdp/iot-predictive/
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWSで始める異常検知】Part2. SageMakerでクレジットカードの不正使用検知

はじめに やりたいこと ゴールはこれ 使うデータセットはこれ 前提条件 手順 あ あ あ さいごに 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWSで始める異常検知】Part1. 異常検知の始め方

異常検知とは何か 他の大多数のデータとは振る舞いが異なるデータを検出する技術で、 クレジットカードの不正使用検知や機械故障の検知等の分野で用いられています。 異常検知の代表的な手法 以下のような手法がよく用いられています。 ホテリング理論 k近傍法 局所外れ値因子法(LOF法) 異常検知の活用事例 製品の品質チェック 画像認識の技術を用いて、今まで目視で完成品をチェックしていたものを自動化します。 設備や機器に対する異常検知 センサーから取得したデータを用いて、異常データを検出するようにモデルを構築し、トラブルを早期に発見します。 クレジットカードの不正使用検知 不正利用のパターンをデータ化し、24時間365日カード利用を監視します。 不正利用の事例と類似した場合は、カード利用を停止したり カード名義人へ連絡が入ったりなどの対応が行われます。 異常検知にAIを活用するメリット 人の目や長年の経験がないと分からなかった故障などの判断をAIに置き換えることができる 人間では感じられない違いを画像やデータによって補完することが可能 トライ&エラーの繰り返しで検知精度を向上 まとめ 本記事では、異常検知とは何で、どんな分野で使われているのかについて紹介しました。 異常検知の技術を用いた業務の自動化は、人員の削減や生産性の向上にもつながるため様々な分野で取り入れられています。 次回は実際にAWSのサービスを使って、簡単に異常検知を試してみます。 次の記事:【AWSで始める異常検知】Part2. SageMakerで設備故障の検知
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

(初心者向け)ほぼコピペでAWS SDK For Java2.0 Rekognitionのサンプルコード(Java)で顔認証してみた

背景 GW暇ですね。お家で手軽に遊べる技術はないか?ということでAWSの公式DOCを見ていると面白そうな題材を発見しましたので試してみました。 https://github.com/awsdocs/aws-doc-sdk-examples/tree/master/javav2/example_code/rekognition/src/main/java/com/example/rekognition つくるもの AWS RekognitonをJavaで実装した顔認証アプリ 大まかな流れ IAMユーザー作成→IAMユーザーを作成して、Rekognitionサービスにアクセスするための鍵取得→鍵を環境変数に設定→Javaソースコピペ 用意するもの EclipseでMavenプロジェクトを開発できる環境(Java8以上) AWS無料アカウント ①AWSコンソールのIAMでユーザーを作成する まずはJavaでAWSサービスを使うために必要なアクセスキーとシークレットキーを取得するため、IAMユーザー作成を行います。 IAMをAWSコンソール上で検索 メニュー:ユーザーからユーザーを追加ボタンを選択 ユーザー名を入力し、アクセスの種類で「プログラムによるアクセス」にチェックを入れ次へ。 「既存のポリシーを直接アタッチ」を選択し、Rekognitionで検索をかけAmazonRekognitionFUllAccessのチェックボックスにチェックします。 この画面は何もしなくて問題ないです。 この画面もそのまま進みます。 この画面がとても重要です。アクセスキーIDとシークレットキーをメモします。シークレットアクセスキーはこの段階でしか見れないので、忘れてしまうとまたユーザーを作り直す必要があります。 ②手順①で取得したキー2つを環境変数に設定する JAVAの環境構築時にJAVA_HOMEを設定したと思いますがそれと同様です。 ③EclipseでMavenプロジェクトを作成する Eclipseツールバーのファイル→新規→Mavenプロジェクト シンプルなプロジェクトの作成をチェックし次へ 適当なグループIdとアーティファクトID入力し完了 ④Javaファイルを作成する src/main/java上で右クリック→新規→クラス 名前を入力しどのメソッドスタブを作成しますか?はpublic static void...にチェック 作成したクラス(DetectFaces)ファイルに下記コードを入力。エラーが出まくりますが次の手順で解消します。 公式のGithubソースから変えてるのはRegionを東京(ap-north-east-1)にしているのとSysoutの一部を消しています。 import java.io.File; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.InputStream; import java.util.List; import software.amazon.awssdk.core.SdkBytes; import software.amazon.awssdk.regions.Region; import software.amazon.awssdk.services.rekognition.RekognitionClient; import software.amazon.awssdk.services.rekognition.model.AgeRange; import software.amazon.awssdk.services.rekognition.model.Attribute; import software.amazon.awssdk.services.rekognition.model.DetectFacesRequest; import software.amazon.awssdk.services.rekognition.model.DetectFacesResponse; import software.amazon.awssdk.services.rekognition.model.FaceDetail; import software.amazon.awssdk.services.rekognition.model.Image; import software.amazon.awssdk.services.rekognition.model.RekognitionException; public class DetectFaces { public static void main(String[] args) { String sourceImage = args[0]; Region region = Region.AP_NORTHEAST_1; RekognitionClient rekClient = RekognitionClient.builder() .region(region) .build(); detectFacesinImage(rekClient, sourceImage ); rekClient.close(); } public static void detectFacesinImage(RekognitionClient rekClient,String sourceImage ) { try { InputStream sourceStream = new FileInputStream(new File(sourceImage)); SdkBytes sourceBytes = SdkBytes.fromInputStream(sourceStream); // Create an Image object for the source image Image souImage = Image.builder() .bytes(sourceBytes) .build(); DetectFacesRequest facesRequest = DetectFacesRequest.builder() .attributes(Attribute.ALL) .image(souImage) .build(); DetectFacesResponse facesResponse = rekClient.detectFaces(facesRequest); List<FaceDetail> faceDetails = facesResponse.faceDetails(); for (FaceDetail face : faceDetails) { AgeRange ageRange = face.ageRange(); System.out.println("The detected face is estimated to be between " + ageRange.low().toString() + " and " + ageRange.high().toString() + " years old."); System.out.println("There is a smile : "+face.smile().value().toString()); } } catch (RekognitionException | FileNotFoundException e) { System.out.println(e.getMessage()); System.exit(1); } // snippet-end:[rekognition.java2.detect_faces.main] } } ⑤pom.xmlファイルに追記する projectタグの間に追記しctrl+Sなりで保存します。保存するとほとんど前手順のエラーが消えます。 <dependencyManagement> <dependencies> <dependency> <groupId>software.amazon.awssdk</groupId> <artifactId>bom</artifactId> <version>2.16.29</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>software.amazon.awssdk</groupId> <artifactId>rekognition</artifactId> </dependency> </dependencies> ⑥コンパイラ設定 コンパイラがデフォルトで1.5などになってしまっている場合今回のコードだと扱えない箇所があるので自分が使うバージョンに設定します。プロジェクト名で右クリック→ビルドパス→ビルド・パスの構成 メニューからJavaコンパイラーを選択し、Javaビルド・パス上の実行環境'J2SE-1.5'から準拠を使用のチェックを外し、プルダウンから自分か使うJavaのバージョンを選択し適用して閉じるを押す。 ⑥顔認証実行 プロジェクト名上で右クリック→実行→実行の構成 プログラムの引数に、顔認証対象の画像の絶対パスを入力 ちなみに笑顔pngの中身です。 コンソールを見てみると、画像の人は14-26歳の人で、笑顔という解析結果が出ます。 怒り顔でもやってみましょう。 コンソールを見てみると、画像の人は25-39歳の人で、笑顔ではないという解析結果が出ます。 感想 特に機械学習の知識や技術力がなくても楽しめました。今後はフロントでファイルアップロード機能なりカメラ機能(フロント?Kotlin)なり実装して、連携してもっと身近なものも作りたい所存です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

(初心者向け)ほぼコピペでAWS SDK For Java2.0 Rekognitionのサンプルコード(Java)で顔認識してみた

背景 GW暇ですね。お家で手軽に遊べる技術はないか?ということでAWSの公式DOCを見ていると面白そうな題材を発見しましたので試してみました。 https://github.com/awsdocs/aws-doc-sdk-examples/tree/master/javav2/example_code/rekognition/src/main/java/com/example/rekognition つくるもの AWS RekognitonをJavaで実装した顔認識アプリ 大まかな流れ IAMユーザーを作成して、Rekognitionサービスにアクセスするための鍵取得→鍵を環境変数に設定→Javaソースコピペ 事前に用意するもの EclipseでMavenプロジェクトを開発できる環境(Java8以上) AWS無料アカウント ①AWSコンソールのIAMでユーザーを作成する まずはJavaでAWSサービスを使うために必要なアクセスキーとシークレットキーを取得するため、IAMユーザー作成を行います。 IAMをAWSコンソール上で検索 メニュー:ユーザーからユーザーを追加ボタンを選択 ユーザー名を入力し、アクセスの種類で「プログラムによるアクセス」にチェックを入れ次へ。 「既存のポリシーを直接アタッチ」を選択し、Rekognitionで検索をかけAmazonRekognitionFUllAccessのチェックボックスにチェックします。 この画面は何もしなくて問題ないです。 この画面もそのまま進みます。 この画面がとても重要です。アクセスキーIDとシークレットキーをメモします。シークレットアクセスキーはこの段階でしか見れないので、忘れてしまうとまたユーザーを作り直す必要があります。 ②手順①で取得したキー2つを環境変数に設定する JAVAの環境構築時にJAVA_HOMEを設定したと思いますがそれと同様です。 ③EclipseでMavenプロジェクトを作成する Eclipseツールバーのファイル→新規→Mavenプロジェクト シンプルなプロジェクトの作成をチェックし次へ 適当なグループIdとアーティファクトID入力し完了 ④Javaファイルを作成する src/main/java上で右クリック→新規→クラス 名前を入力しどのメソッドスタブを作成しますか?はpublic static void...にチェック 作成したクラス(DetectFaces)ファイルに下記コードを入力。エラーが出まくりますが次の手順で解消します。 公式のGithubソースから変えてるのはRegionを東京(ap-north-east-1)にしているのとSysoutの一部を消しています。 import java.io.File; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.InputStream; import java.util.List; import software.amazon.awssdk.core.SdkBytes; import software.amazon.awssdk.regions.Region; import software.amazon.awssdk.services.rekognition.RekognitionClient; import software.amazon.awssdk.services.rekognition.model.AgeRange; import software.amazon.awssdk.services.rekognition.model.Attribute; import software.amazon.awssdk.services.rekognition.model.DetectFacesRequest; import software.amazon.awssdk.services.rekognition.model.DetectFacesResponse; import software.amazon.awssdk.services.rekognition.model.FaceDetail; import software.amazon.awssdk.services.rekognition.model.Image; import software.amazon.awssdk.services.rekognition.model.RekognitionException; public class DetectFaces { public static void main(String[] args) { String sourceImage = args[0]; Region region = Region.AP_NORTHEAST_1; RekognitionClient rekClient = RekognitionClient.builder() .region(region) .build(); detectFacesinImage(rekClient, sourceImage ); rekClient.close(); } public static void detectFacesinImage(RekognitionClient rekClient,String sourceImage ) { try { InputStream sourceStream = new FileInputStream(new File(sourceImage)); SdkBytes sourceBytes = SdkBytes.fromInputStream(sourceStream); // Create an Image object for the source image Image souImage = Image.builder() .bytes(sourceBytes) .build(); DetectFacesRequest facesRequest = DetectFacesRequest.builder() .attributes(Attribute.ALL) .image(souImage) .build(); DetectFacesResponse facesResponse = rekClient.detectFaces(facesRequest); List<FaceDetail> faceDetails = facesResponse.faceDetails(); for (FaceDetail face : faceDetails) { AgeRange ageRange = face.ageRange(); System.out.println("The detected face is estimated to be between " + ageRange.low().toString() + " and " + ageRange.high().toString() + " years old."); System.out.println("There is a smile : "+face.smile().value().toString()); } } catch (RekognitionException | FileNotFoundException e) { System.out.println(e.getMessage()); System.exit(1); } // snippet-end:[rekognition.java2.detect_faces.main] } } ⑤pom.xmlファイルに追記する projectタグの間に追記しctrl+Sなりで保存します。保存するとほとんど前手順のエラーが消えます。 <dependencyManagement> <dependencies> <dependency> <groupId>software.amazon.awssdk</groupId> <artifactId>bom</artifactId> <version>2.16.29</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>software.amazon.awssdk</groupId> <artifactId>rekognition</artifactId> </dependency> </dependencies> ⑥コンパイラ設定 コンパイラがデフォルトで1.5などになってしまっている場合今回のコードだと扱えない箇所があるので自分が使うバージョンに設定します。プロジェクト名で右クリック→ビルドパス→ビルド・パスの構成 メニューからJavaコンパイラーを選択し、Javaビルド・パス上の実行環境'J2SE-1.5'から準拠を使用のチェックを外し、プルダウンから自分か使うJavaのバージョンを選択し適用して閉じるを押す。 ⑥顔認識実行 プロジェクト名上で右クリック→実行→実行の構成 プログラムの引数に、顔認識対象の画像の絶対パスを入力 ちなみに笑顔pngの中身です。 コンソールを見てみると、画像の人は14-26歳の人で、笑顔という解析結果が出ます。 怒り顔でもやってみましょう。 コンソールを見てみると、画像の人は25-39歳の人で、笑顔ではないという解析結果が出ます。 感想 特に機械学習の知識や技術力がなくても楽しめました。今後はフロントでファイルアップロード機能なりカメラ機能(フロント?Kotlin)なり実装して、連携してもっと身近なものも作りたい所存です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS BackupでEBSをバックアップと復元

ただのやってみた系で個人の感想です。 はじめに 対象リソースはAurora, DDB, EBS, EC2, EFS, FSx, RDS, Storage Gateway などありますが今日はEBS ここではタグをbackup:trueで付けているEBSを対象としました。試す場合はタグを付けておいてください。 AWS Backup ではバックアップ対象のリソースをタグベースで指定することが基本。環境とかチームとか言うタグで環境単位/チーム単位でバックアップという世界観がありそう。対象リソースが限られてるので今は狭い世界かも。 この記事では、アクセス管理には踏み込みません AWS Backup用語 用語の理解が最初難しいかも。今はざっくりと理解してもらいあんまり気にせず、実際のEBSのバックアップ復元操作を進め最後に用語の意味を振り返ります バックアップボールト:EC2のバックアップである AMI 、RDS のバックアップであるスナップショットなどをまとめて管理する単位。暗号化や権限管理もこの単位。 バックアッププラン:バックアップのスケジュール機能 復旧ポイント:リストアする単位で、バックアップ時の情報が記録されている。EBSならスナップショットIDとか。 ジョブ:バックアップや復元の処理のこと。ジョブのメニューからジョブのステータスが確認出来てジョブ停止操作も出来て、ジョブの履歴が残り確認出来る 保護されたリソース :バックアップしたリソース。EBSとかRDSとかのリソースIDがリストされる AWS Backup操作 EBSを例にバックアップやリストアをやってみます バックアップボールト作成 とりあえず意味は考えず作っちゃいます。 "バックアップボールト"をクリックし、[バックアップボールトを作成]をクリック 以下を入力して右下の[バックアップボールトを作成]をクリック バックアップボールト名:tmp-vault 暗号化キー:(デフォルト)aws/backup オンデマンドバックアップ 名前の通りだけどオンデマンドでバックアップすること。 "保護されたリソース"をクリックし、[オンデマンドバックアップを作成]をクリック 次の値を入れて右下の[オンデマンドバックアップを作成]をクリック リソースタイプ:EBS ボリュームID:任意のボリュームID 今すくバックアップを作成(1時間以内に実行):チェック 保持期間:常時(これは消さない。期間を指定すれば期間が来たら自動削除ができます) バックアップボールト:tmp-vault IAMロール デフォルトのロール:チェック すぐにジョブが実行されます。すぐにジョブは実行されますが1時間以内のタイムウインドウでの実行になります。タイムウインドウをカスタマイズした場合はそのタイムウインドウでの実行になります。つまり、オンデマンドバックアップは、バックアップ実行のタイムウインドウを指定したジョブの定義でありそのジョブ実行が即時で行われますが、バックアップそのものの実行はバックアップウインドウに従い行われます。 注意点としては、オンデマンドバックアップのこの定義自体は残りません。 あと、オンデマンドバックアップだと、クロスリージョン、クロスアカウントの設定項目がないので出来なそう EBSの復元 "復旧ポイント"はバックアップ時に作成されるバックアップしたリソースやバックアップした時間を示すものです。EBSであればスナップショットIDを示します。AWS Backupではこの復旧ポイントから復元します。 復旧ポイントは以下の2箇所(以下の①と②)から辿れます ①バックアップボールト=>tmp-vault=>復旧ポイントID(対象のバックアップ)にチェック=>右上の[アクション]から[復元]をクリック 復元するEBSのタイプや容量やAZなど任意で変更し復元できます。 ②保護されたリソース=>対象の復旧ポイントID(バックアップ)にチェック=>右上の[復元]をクリック あとの操作は①と同じです。 スケジューリング AWS Backupでバックアップのスケジューリングは"バックアッププラン"で行います。 AWS Backupのバックアッププランをクリックし、右上の[バックアッププランを作成]をクリック 次を入力し、[プランを作成]をクリック 新しいプランを立てる:チェック バックアッププラン名:tmp バックアップルール名:tmp バックアップボールト:tmp-vault (事前に作ったもの) バックアップ頻度:カスタムcron式 cron式:cron(0 0/1 ? * * *) (1時間おき) バックアップウインドウをカスタマイズ 次の時間以内に開始:1時間 次の時間以内に完了:2時間 ※ ここでは使わないが、コピー先として別リージョンの指定もできる。コピー先として別アカウントのボールトの指定も出来る。 作成したバックアッププランをクリックし、[リソースを割り当てる]をクリックし、このバックアッププランの対象となるリソースを定義します。 * リソース名:tmp * リソースにアクセスするIAMロール:デフォルト * リソースを特定するタグ:backup:true リソースはタグで指定する感じです。ここではbackup:trueで付けているEBSを対象としました。 時間になったら動き出しました。基本的にタイムウインドウをベースに動くので、ジョブとしては指定した毎時の14:00に実行され(多分キューイングされ)、実際のバックアップはタイムウインドウの1時間以内の開始である14:04:40に開始されています(多分)。対象のEBSリソースもタグで指定したものになってます。 バックアッププランのイメージ図はこんな感じ 作成したバックアッププランを任意のタイミングで手動実行は出来なそう。バックアッププランはジョブの定義としても残るので、なにかの原因で失敗したとか、データやアプリに手を加える直前などの任意のタイミングでも実行できたらいいなと思う。 リトライとかなさそうなので欲しい。スケジュールの簡単なスケジュールオンオフがない。欲しい あと、取得したスナップショットの保持期間の設定はないっぽい。EBSのData Lifecycle Managerとの統合か独自でいいのでローテーション出来るようにしてほしいこれは。 クロスリージョン/クロスアカウント クロスリージョンにバックアップ実行 先程のバックアッププランを、大阪リージョンにも取得するように修正します。 バックアッププランで作成されたバックアップルールを選択し、[編集する]をクリック 以下の修正を加える コピー先にコピー - オプション:アジア・パシフィック(大阪) 送信先バックアップボールト:Default スケジュールされた時間になると実行されます。 実行結果 実行した復旧ポイントIDはこちら。作成されたスナップショットIDもあります。 このスナップショットIDは大阪リージョンにできていることが確認できます。 クロスアカウント また、クロスアカウントへのコピーは以下の画面のように"別のアカウントのボールトにコピー"をクリックし、"外部ボールトARN"にARNを入力します。今回は試してない。 運用時のよくありそうな操作 リソース単位で確認 保護されたリソースをクリックし、AWS Backupの管理下にあるリソースの確認。対象リソースをクリックしてバックアップや復元操作 バックアップ 保護されたリソース=>対象のリソース(EBSとかEFSとかそれぞれのID)選択=>[オンデマンドバックアップを作成]クリック=>対象リソースに対するバックアップ(対象リソースが選ばれた状態で、オプション設定し[オンデマンドバックアップを作成]で実行) 復元 保護されたリソース=>対象のリソース(EBSとかEFSとかそれぞれのID)選択=>対象の復旧ポイントにチェックを入れ[復元]をクリックし、復元のオプション入れて[バックアップを復元] ジョブの確認 バックアップ/復元/コピーのジョブの履歴を確認する。完了やエラーなどのステータス、対象リソースID、実施日、復旧ポイントARNなど クロスアカウントモニタリングでOrganizationの親で有効化していれば、他のAWSアカウントのジョブの状態確認も可能 ボールト単位で確認 バックアップボールトをクリックし、AWS Backupのバックアップボールトの管理下にある復旧ポイントの確認。復旧ポイントを選択してコピー,削除,編集,復元の操作が出来る(保護されたリソースからの復旧ポイントへの操作時は復元のみ)。 用語の振り返り バックアップボールト: AWS公式ではバックアップが保存されるコンテナという説明。 定義する項目は、名前、暗号キー(デフォルトでaws/backupというキーあり)、タグ。あとからアクセスポリシーをアタッチできる アクセスポリシーは、組織からバックアップボルトへのアクセスを許可する。バックアップボルトへのアカウントレベルのアクセスを許可する。などが設定できるもの。 オンデマンドバックアップ、バックアッププランのいずれでもバックアップボールトは必須の設定 アクセスポリシーや暗号化キーなどが含まれることから、これらの観点で管理する単位と考え作成すると良さそう。少なくとも大きい組織では分ける。権限分けたければその中でもチームで分ける。他チームから見られたり操作されたくない単位で分ける感じかなと。 復旧ポイント:バックアップボールトで任意のバックアップボールトを選びその中に復旧ポイントがある。また、保護されたリソースで任意のリソースを選びその中に復旧ポイントがある。 保護されたリソース バックアップボルト内の取得されたバックアップは、バックアップの基となるリソースとして保護されたリソースに登録される 保護されたリソース側からリソースの削除はできない。復旧ポイントの削除もできない。これらはボルト側から復旧ポイントを削除する形で行い、復旧ポイントの削除がされ、復旧ポイントの削除に伴い対象のリソースがなくなれば結果的にリソースが削除されることになる 簡易的操作。ボルトを横断したリソース確認、リソースのオンデマンドバックアップ、復旧ポイントからの復旧が簡単に行える 感想 基本はタグでリソース指定,タイムウインドウ制御でのバックアップやリストア実行。これらの制約が問題なければいいかも バックアップの一元管理として、バックアップボルトの中に復旧ポイントが作られる。バックアップの取得状態、対象を選択してリストア、実行した各処理のジョブ履歴、管理するリソースのリスト表示などはバックアップという観点で見通しがいいと思う ボルトを決めないと始められず、どのような単位で切るべきか自由度が高くそこが手始めしずらい点かも。ボルトが決まってしまえば、ボルトの単位でバックアップの状況の整理と見通しは良くなる タグなどを使い大量なリソースに対して、正確な時間は気にせずリトライなども気にせずざっくりとバックアップを実現したい時は楽が出来る。一定期間残す設定もありバックアップのライフサイクルを作れ、別リージョンへのバックアップや一元的な管理は満たせると思う
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】EC2をまとめてみた

EC2とは AWSの仮想サーバーサービスです。 まずサーバーとは? 業務用コンピューターです。 クライアントからのリクエストに対して、 サーバーからレスポンスを返します。 仮想サーバーとは? OS+CPU+Memory+SSD+NIC(Network Interface Card)などが構成要素となっている。 これがAWSでは、 OS→AMI(Amazon Machine Image) CPU, Memory→インスタンスタイプ(t2nano, t3microなど) SSD→EBS(Amazon Elastic Block Store) NIC→ENI(Elastic Network Interface) となっています。 これらが纏まったのが、Amazon EC2です。 AMIとは? AMIはインスタンスの作成に必要な情報です。 EC2作成時に使用するAMIの指定が必要です。 インスタンスタイプ 無料利用枠の対象となっているt2.microを例に説明します。 tはファミリー名です。 2は世代番号です。 世代番号に関しては、数字が大きいものほど新しいので、できるだけ数字が大きいものを使う方がいいです。 microはインスタンスのサイズを表しています。 T系 主な用途は、テストです。 インスタンス vCPU CPU メモリ(GB) t3.nano 2 6 0.5 t3.micro 2 12 1 t3.small 2 24 2 t3.medium 2 24 4 t3.large 2 36 8 t3.xlarge 4 96 16 t3.2xlarge 8 192 32 M系 バランスの取れたCPUとバランスの取れたメモリ数のため、どんな仕様にも使えます。 インスタンス vCPU メモリ(GB) m5.large 2 8 m5.xlarge 4 16 m5.2xlarge 8 32 m5.4xlarge 16 64 m5.8xlarge 32 128 m5.12xlarge 48 192 m5.16xlarge 64 256 m5.24xlarge 96 384 C系 CPUに優れたインスタンスです。 用途はWEBサーバーなどです。 インスタンス vCPU メモリ(GB) c5.large 2 4 c5.xlarge 4 8 c5.2xlarge 8 16 c5.4xlarge 16 32 c5.9xlarge 36 72 c5.12xlarge 48 96 c5.18xlarge 72 144 c5.24xlarge 96 192 R系 メモリに優れたインスタンスです。 用途はビッグデータなどDBなどです。 インスタンス vCPU メモリ(GB) r5.large 2 16 r5.xlarge 4 32 r5.2xlarge 8 64 r5.4xlarge 16 128 r5.8xlarge 32 256 r5.12xlarge 48 384 r5.16xlarge 64 512 r5.24xlarge 96 768 簡単にまとめると、 開発時にはT系を使用し、 特別な用途などがない限りはM系で十分です。 EBS 外付けディスクのことを指します。 種類に応じて性能が異なってきます。 また、バックアップ(スナップショット)が取得できます。 EBSの特徴は以下の3つです。 ①EC2とEBSは外部でアタッチされる ②同一のAZ内でしかEC2とEBSはアタッチできない ③1つのEBSに対して複数のEC2をアタッチできない(1EBS→1EC2、1EC2→複数のEBSはOK) 種類 タイプ 名前 特徴 SSD 汎用 SSD 特別な要件がない限りこれで OK。 SSD プロビジョンド IOPS SSD 汎用 SSD よりも高スペック、特別な要件がある時はこれ。 HDD スループット最適化 HDD(st1) データをひたすらにためる時に使う、ビッグデータとか。 HDD Cold HDD(sc1) データを保管するだけ、あんまり使わないでデータを保持する時。 スナップショット(バックアップ) バックアップを差分のみ行ってくれる仕様です。 例えば、 1MBのファイルがあり、そのファイルに更新をしていくものとします。 ①1MBの更新を行う ②2MBの更新を行う ③1MBの更新を行う このように3回の更新を行うケースを考えてみましょう。 通常のコピーの場合 1MB ①2MB+2MB(コピー①) ②4M+2MB(コピー①)+4MB(コピー②) ③5MB+2MB(コピー①)+4MB(コピー②)+5MB(コピー③) 計16MBの容量が必要となります。 スナップショットの場合 1MB ①2MB+2MB(スナップショット①) ②4M+2MB(スナップショット①)+2MB(スナップショット②) ③5MB+2MB(スナップショット①)+2MB(スナップショット②)+1MB(スナップショット③) 計10MBの容量が必要となります。 6MBの削減となりました!! EC2が作成されるまでの流れ ①AMI(Amazon Machine Image)の選択 ②インスタンスタイプの選択 ③Amazon EC2が起動→User dataを起動 ④EBSをEC2にアタッチ ⑤ENIをEC2にアタッチ(ここでセキュリティグループなども決定する) User data EC2が初回起動する際に実行するスクリプトです。 実行権限はrootユーザー権限のみです。 ■よく使われる内容 ・パッケージのアップデート → yum update -y ・ソフトウェアのインストール → yum install httpd -y ・設定ファイルの取得 2つの形式が使える ・シェルスクリプト形式(1行目が#!で始まる) ・cloud-init形式(1行目が#cloud-configで始まる) Instance Meta Data インスタンスの中に埋め込まれているデータ。 例えば、EC2のIPアドレスやホストネーム、AMIのID番号などがあります。 キーペア EC2へログインするために使用する秘密鍵、公開鍵のペアのことを指します。 それでは実際にEC2を使ってみましょう! EBSをEC2にアタッチしてマウントしましょう ■場所 EC2>ボリューム この後、 アクション>アタッチを行う ターミナルでアタッチされているか確認する。 ターミナル // root権限に移動 $ sudo su - $ ls -l /dev/sdf lrwxrwxrwx 1 root root 4 Apr 30 06:05 /dev/sdf -> xvdf // 中を調べる $ df -h /dev/xvda1 8.0G 1.5G 6.6G 18% / // ファイルを確認 $ file -s /dev/sdf /dev/sdf: symbolic link to `xvdf' // 中に何もない $ file -s /dev/xvdf /dev/xvdf: data // ファイルを作成するコマンド $ mkfs -t ext4 /dev/xvdf // 中に追加された $ file -s /dev/xvdf /dev/xvdf: Linux rev 1.0 ext4 filesystem data, UUID=XXXXXXXXXXXXXXXX (extents) (64bit) (large files) (huge files) // logフォルダを作成 $ mkdir /log // フォルダを確認 $ ls -l / total 16 lrwxrwxrwx 1 root root 7 Apr 24 09:37 bin -> usr/bin dr-xr-xr-x 4 root root 4096 Apr 24 09:38 boot drwxr-xr-x 15 root root 2860 Apr 30 06:05 dev drwxr-xr-x 81 root root 8192 Apr 30 05:47 etc drwxr-xr-x 3 root root 22 Apr 30 05:47 home lrwxrwxrwx 1 root root 7 Apr 24 09:37 lib -> usr/lib lrwxrwxrwx 1 root root 9 Apr 24 09:37 lib64 -> usr/lib64 drwxr-xr-x 2 root root 6 Apr 24 09:37 local drwxr-xr-x 2 root root 6 Apr 30 06:15 log drwxr-xr-x 2 root root 6 Apr 9 2019 media drwxr-xr-x 2 root root 6 Apr 9 2019 mnt drwxr-xr-x 4 root root 27 Apr 24 09:38 opt dr-xr-xr-x 108 root root 0 Apr 30 05:46 proc dr-xr-x--- 3 root root 103 Apr 30 05:47 root drwxr-xr-x 28 root root 960 Apr 30 05:47 run lrwxrwxrwx 1 root root 8 Apr 24 09:37 sbin -> usr/sbin drwxr-xr-x 2 root root 6 Apr 9 2019 srv dr-xr-xr-x 13 root root 0 Apr 30 05:46 sys drwxrwxrwt 9 root root 261 Apr 30 05:47 tmp drwxr-xr-x 13 root root 155 Apr 24 09:37 usr drwxr-xr-x 20 root root 280 Apr 30 05:47 var // マウントされているかを確認(EBSはアタッチしてマウントしてようやく使える) $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 482M 0 482M 0% /dev tmpfs 492M 0 492M 0% /dev/shm tmpfs 492M 468K 492M 1% /run tmpfs 492M 0 492M 0% /sys/fs/cgroup /dev/xvda1 8.0G 1.5G 6.6G 18% / tmpfs 99M 0 99M 0% /run/user/1000 tmpfs 99M 0 99M 0% /run/user/0 // 上記にないのでされていない、だからマウントしましょう $ mount /dev/xvdf /log // マウントされているか確認しましょう $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 482M 0 482M 0% /dev tmpfs 492M 0 492M 0% /dev/shm tmpfs 492M 468K 492M 1% /run tmpfs 492M 0 492M 0% /sys/fs/cgroup /dev/xvda1 8.0G 1.5G 6.6G 18% / tmpfs 99M 0 99M 0% /run/user/1000 tmpfs 99M 0 99M 0% /run/user/0 /dev/xvdf 123G 61M 117G 1% /log →あった EC2インスタンスが再起動した時に、EBSが自動的にマウントされるように設定する ターミナル // ①ファイル作成完了 $ touch /log/testlogfile.log $ ls -l /log/testlogfile.log -rw-r--r-- 1 root root 0 Apr 30 06:21 /log/testlogfile.log // ②マウントしたいファイルシステムのUUIDを取得する $ file -s /dev/xvdf /dev/xvdf: Linux rev 1.0 ext4 filesystem data, UUID=edc2cbbe-XXXX-XXXX-8883-909522484c6d (needs journal recovery) (extents) (64bit) (large files) (huge files) // ③viで/etc/fstabにUUIDを追記する $ vi /etc/fstab UUID=edc2cbbe-XXXX-XXXX-8883-909522484c6d /log ext4 default 1 1 これで自動的にマウントされるようになりました。 スナップショット ①インスタンスの停止 アクション>インスタンスの停止 ②イメージの作成 アクション>イメージを作成 ③イメージの確認 ブロックデバイスが2つあることを確認できました。 008b9ff 04e3d35 ④スナップショットを確認 スナップショットが2つあることを確認できました。 008b9ff 04e3d35 これで完了です。 ではこのスナップショットを使ってEC2を起動してみましょう! スナップショットを使ったEC2の起動方法 ①インスタンスを起動 マイAMI内にイメージがあります。 ②EC2にログインする ターミナル // ログイン(パブリックIP) $ ssh -i test-keypair.pem ec2-user@(パブリックIP) // バックアップが取れているか確認 $ sudo su - $ df -h /dev/xvdf 123G 61M 117G 1% /log →あった
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】VPCとCIDR

プログラミング勉強日記 2021年4月30日 VPCとは  こちらの記事にもある通り、WSクラウドのネットワークからユーザ専用の領域を切り出して作る仮想ネットワーク。  AWSクラウドのネットワーク空間に様々なネットワーク機器やネットワークが使われている。その中に自分専用のAWSクラウドを利用する領域としてVPCを設定する。まず、AWSのアカウントを作ったらVPCがデフォルトで設定される。 CIDRとは  こちらの記事にもある通り、サブネットマスクの値を設定して同じネットワークとして扱うIPアドレスの個数を調整できるIPアドレスの設定方法。  2進数表記にしたときにサブネットが指定する数が利用できないようにロックされて変更できないようになり、ロックされていない桁分のビット間が有効なIPアドレスとして活用できる。 VPCのCIDR  VPCでは/16 ~ /28のCIDR範囲を指定できる。  CIDRに/16を設定したときに設定可能になるサブネット数とIPアドレス数の組み合わせは、以下の表のようになる。(AWS管理IPの5つを引いたもの) サブネットマスク サブネット数 サブネット当たりのIPアドレス数 /18 4 16,379 /20 16 4091 /22 64 1019 /24 256 251 /26 1,024 59 /28 4,096 11  すでに利用されていて設定できないアドレスもある。/24の場合は以下の表のようになる。 ホストアドレス 用途 .0 ネットワークアドレス .1 VPCルータ .2 Amazonが提供するDNSサービス .3 AWSで予約されているアドレス .255 ブロードキャストアドレス
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【初心者向け】AWS-SAM-CLIを用いて APIGateway と Lambda の設定を行う

1、はじめに  今回の記事では忘備録として、AWS-SAM-CLIのビルド・デプロイ時の設定ファイルであるテンプレートファイルについて私のわかる範囲で説明させていただきます。  前回の記事でAWS CLIを用いてLambda関数の情報とコードの一覧を取得するという記事を書かせていただきました。  アプリ毎のAPIGatewayとlambdaの管理を楽にしたかったのですが、正直あまり便利になりませんでした。例えば、ver1だったらこのapiとlambdaを紐づけ、ver2だったらこのapiとlambdaを紐づけ、アプリをver3に更新したけどやっぱver2の時に戻したい、等を簡単に実現したかったのですが、前回の記事の内容では中々うまくいきません。  それらの実現のために、使えたらかっこいいからIaCを用いることにしました。AWS内ではCloudFormationというIaCが提供されています。今回はSAMというCloudFormationの中でも、サーバーレスアプリケーション(lambda, APIGateway等)を利用する部分に特化したIaCを使います。  まずは環境構築の話が出ると思うのですが、そちらはまた次の機会に記事にします。(現環境はvirtualbox, vagrant, docker等勉強不足なものだらけなのでもう少し勉強してからにしたいです。何回か環境ぶっ壊したし、なんか知らんけど動いてるし手順としてpython3.8でSAMを使える環境を書き記すのは現状の知識では厳しい。。。)  とりあえず、環境構築で参考にさせていただいたサイト様だけでも紹介させていただきます。 ・aws-sam-cliのインストールとHello Worldの実行(Ubuntu 18.04 LTS, CentOS 7) ・Windows10で VirtualBoxとVagrantをインストールして仮想環境の構築 ・Linux への AWS SAM CLI のインストール ・【Vagrant/Mac】ローカルと仮想マシンのフォルダを共有/同期する方法 ・Ubuntu18.04にPython3.8を入れる ・pipコマンドが壊れた件  それではテンプレートファイルの説明に入る前に、まずはsamを用いて実際にlambdaとAPIGatewayを作成してみましょう。 2、SAMを用いてlambdaとAPIGateway作成  SAMを使えばこんなことができる、こんなのが作成できるといわれても実際にやらないといまいちピンとこないと思います。というわけでSAM公式が用意してくれているhello-worldテンプレートを使ってlamdaとAPIGatewayをデプロイしてみましょう。 環境 vagrant内の環境は以下のようになっております。 ・ubuntu/bionic64 ・Docker version 20.10.5 ・SAM CLI, version 1.22.0 プロジェクトの作成 以下コマンドで任意の名前でプロジェクト作成できます。 sam init --name <プロジェクト名> 今回は testPj という名前でやっていきたいと思います。 runtimeはpython3.8、template は Hello World Exmapleを用います。 $ sam init --name testPj Which template source would you like to use? 1 - AWS Quick Start Templates 2 - Custom Template Location Choice: 1 What package type would you like to use? 1 - Zip (artifact is a zip uploaded to S3) 2 - Image (artifact is an image uploaded to an ECR image repository) Package type: 1 Which runtime would you like to use? 1 - nodejs14.x 2 - python3.8 3 - ruby2.7 4 - go1.x 5 - java11 6 - dotnetcore3.1 7 - nodejs12.x 8 - nodejs10.x 9 - python3.7 10 - python3.6 11 - python2.7 12 - ruby2.5 13 - java8.al2 14 - java8 15 - dotnetcore2.1 Runtime: 2 Cloning app templates from https://github.com/aws/aws-sam-cli-app-templates AWS quick start application templates: 1 - Hello World Example 2 - EventBridge Hello World 3 - EventBridge App from scratch (100+ Event Schemas) 4 - Step Functions Sample App (Stock Trader) 5 - Elastic File System Sample App Template selection: 1 ----------------------- Generating application: ----------------------- Name: testPj Runtime: python3.8 Dependency Manager: pip Application Template: hello-world Output Directory: . Next steps can be found in the README file at ./testPj/README.md  testPjディレクトリが作成されました。この中に関数のコードやlambda, APIGatewayの設定ファイルが入っています。 $ ls testPj $ cd testPj/ /testPj$ ls README.md __init__.py events hello_world template.yaml tests  一旦説明は省きますが、 テンプレートファイル:'template.yaml' 内に 関数:'HelloWorldFunction' が定義されています。samとdockerを用いればこの関数をデプロイせずにローカルで実行することができます。 さっそくローカル環境でこの関数を動かしてみましょう。 /testPj$ sam local invoke "HelloWorldFunction" -e events/event.json Invoking app.lambda_handler (python3.8) Image was not found. Building image...................................................................... Skip pulling image and use local one: amazon/aws-sam-cli-emulation-image-python3.8:rapid-1.22.0. Mounting /home/vagrant/testPj/hello_world as /var/task:ro,delegated inside runtime container START RequestId: 81dd12f6-e529-4f38-8190-37711ea15a7b Version: $LATEST END RequestId: 81dd12f6-e529-4f38-8190-37711ea15a7b REPORT RequestId: 81dd12f6-e529-4f38-8190-37711ea15a7b Init Duration: 0.46 ms Duration: 166.21 ms Billed Duration: 200 ms Memory Size: 128 MB Max Memory Used: 128 MB {"statusCode": 200, "body": "{\"message\": \"hello world\"}"}  最後の'{"statusCode": 200, "body": "{\"message\": \"hello world\"}"}'の部分が関数のreturnになります。hello_world/app.pyの中にコードが定義されているので気になったら見てみましょう。  末尾の'-e events/event.json' ですが、こちらはlambda関数のテストイベントになります。今回は特にいじらずデフォルトで。 プロジェクトのデプロイ  何もいじってはいませんが、無事にローカルでの動作が確認できたため、ビルドしてデプロイしちゃいましょう  ビルドは以下コマンドで実行できます。 ~/testPj$ sam build -t template.yaml Building codeuri: ~/testPj/hello_world runtime: python3.8 metadata: {} functions: ['HelloWorldFunction'] Running PythonPipBuilder:ResolveDependencies Running PythonPipBuilder:CopySource Build Succeeded Built Artifacts : .aws-sam/build Built Template : .aws-sam/build/template.yaml Commands you can use next ========================= [*] Invoke Function: sam local invoke [*] Deploy: sam deploy --guided  '-t' でテンプレートファイルを指定できます。テンプレートファイルにはlambda, APIGateway等の設定が書かれています。複数のテンプレートファイルを用いて運用することもありえると判断し紹介させていただきます。 では、続いてデプロイします。 ~/testPj$ sam deploy --guided Configuring SAM deploy ====================== Looking for config file [samconfig.toml] : Not found Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: AWS Region [ap-northeast-1]: #Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [y/N]: y #SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]: y HelloWorldFunction may not have authorization defined, Is this okay? [y/N]: y Save arguments to configuration file [Y/n]: y SAM configuration file [samconfig.toml]: SAM configuration environment [default]: いくつか入力を求められるのでその項目を説明します。(--guidedを記入しなければこれらの値はデフォルトで行われます。) Stack Name:  CloudFormation内でのストックの名前です。CloudFormationで作成されたリソース(lambda, APIGateway等)は、このストック名に紐づいて作成されます。例えば、テンプレートファイルでAPI Gatewayとlambdaの名前を変更したと仮定します。この時、ストック名を変更してデプロイすればその前に作成したAPIGatewayとlambdaは残った状態で新しいAPIGatewayとlambdaは作成されます。一方、ストック名を変更せずにデプロイした場合はその前に作成したAPIGatewayとlambdaが削除され、新しいAPIGatewayとlambdaは作成されます。  この辺はCloudFormationの仕様の話ですが、勘違いすると後で痛い目に合うのでよく頭に入れておいてください。現行のシステムが全部消して上書きしちゃうなんて笑い話にならないですから。私も気を付けます。。。 AWS Region:  AWSのリージョンです。この記事を読んでいる方なら多分'ap-northeast-1'でいいかと Confirm changes before deploy:  こちらを'Y'しておくとデプロイ前に変更されるリソースの一覧を表示した上で本当のデプロイするかどうか聞いてくれるようになります。それ上で間違えそうな心折設計 新設設計です。 Allow SAM CLI IAM role creation:  SAM CLIがIAMロールを作っても良いかどうかです。'Y'で問題ありません。 HelloWorldFunction may not have authorization defined, Is this okay?:  関数'HelloWorldFunction'に認証設定がないけど良いですかって聞いてます。とりあえず'Y'です。(この項目は正しく認証を設定すると消えます。) Save arguments to configuration file:  samconfig.tomlを作成してその中にデフォルトのデプロイパラメータを記入・保存するかどうか。'Y'でOKです。 では、コンソールでlambdaとAPIGatewayが作成されたか確認してみます。 lambda APIGateway 作成できていますね。 ちなみにlambdaとAPIGatewayの削除はCloudFormationコンソール上でストックの削除を行うか以下コマンドで実行できます。 aws cloudformation delete-stack --stack-name <ストック名> 3、テンプレートファイルの説明  ここからが本題です。ここからはテンプレートファイルの中身の見方、書き方についてみていきたいと思います。今からの内容は、こちらの公式ドキュメントの内容の一部になります。英語が得意な方はそちらをご覧ください。   また、SAMのテンプレートファイルの書き方の基本はCloudFormationと同じになります。その上で、一部の書き方がSAMにしかできないという認識を持って読んでください。  SAMのテンプレートファイルでは、最初に 'AWSTemplateFormatVersion' と 'Transform' が定義されています。こちらはSAMによって定義されたリソースを、CloudFormationで定義しなおすために必ず書く必要があります。特に意識する必要はありません。  テンプレートファイルは以下のオプションにわけられます。 Description こちらはCloudFormationストックの説明文です。コンソール上から確認できます。必要に応じ適宜変更するようにしましょう。 Globals(SAM特有)  こちらには、ストック全体の共通設定を書きます。lambda, APIGateway, DynamoDB の共通設定をこちらで書くことができます。後に説明するResourcesでは一つ一つこれらの設定を定義する必要がありますが、Globalsを用いることでまとめて設定することができます。ただし、Globalsで設定できる項目には制限があります。詳しくはこちらのページをご覧ください。 Metadata  (SAMを使用しているとあんまり意識しませんが)、CloudFormationのデザイナー上のリソース表示位置が記載されています。 Parameters  デプロイコマンド実行時にテンプレートに渡すことができる値を定義できます。定義した値はResourcesとOutputsのパラメータとして使用できます。sam deployコマンドについてはこちらを参照ください。 Mappings  任意のキーと値とを対応付けることができます。例えば、リージョンに基づく値を設定する場合、リージョン名をキーとして必要な値を保持することができます。FindInMap関数を用いることで必要な値を取り出したり、Parametersの入力パラメータに応じキーを選択することができます。詳しくはこちらのサイトをご覧ください。 Conditions  条件分岐を設定することができます。例えば、条件をResourcesまたはOutputsに紐づけることで、条件がtrueの時のみResources、Outputsを出力するようにできます。  ただしスタックの更新時に、条件を単独で更新することはできません。条件を更新できるのは、リソースを追加、変更、または削除する変更を含める場合だけです。 Resources(必須)  lambdaやAPIGatewayを定義することができます。Globalsにいくら設定をかいても、こちらに何も書かなければCloudFormationでリソースは作成されません。詳しい書き方は後述します。 Outputs  こちらでは、CloudFormationコンソール上で表示する出力値や、他のストックにインポート・応答として返す出力値を宣言できます。  では、testPj のテンプレートファイルの中身を見ていきましょう。(余計な部分は消しております) ~/testPj$ more template.yaml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > testPj Sample SAM Template for testPj Globals: Function: Timeout: 3 Resources: HelloWorldFunction: Type: AWS::Serverless::Function Properties: CodeUri: hello_world/ Handler: app.lambda_handler Runtime: python3.8 Events: HelloWorld: Type: Api Properties: Path: /hello Method: get Outputs: HelloWorldApi: Description: "API Gateway endpoint URL for Prod stage for Hello World function" Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/" HelloWorldFunction: Description: "Hello World Lambda Function ARN" Value: !GetAtt HelloWorldFunction.Arn HelloWorldFunctionIamRole: Description: "Implicit IAM Role created for Hello World function" Value: !GetAtt HelloWorldFunctionRole.Arn  上から見ていきます。AWSTemplateFormatVersionとTransformを飛ばすと、'Globals: Function: Timeout: 3' と書かれています。日本語で言うとResourcesに記述のあるすべての'Type: AWS::Serverless::Function'のタイムアウトを3秒に設定するという意味です。  Globalsではそれぞれ以下のようにResourcesの共通設定を記述することができます。詳しくはこちらのページをご覧ください。 Function:   →  Type: AWS::Serverless::Function Api:   →  Type: AWS::Serverless::Api HttpApi:    →  Type: AWS::Serverless::HttpApi SimpleTable:  →  Type:AWS::Serverless::SimpleTable  続けて、'Resources: HelloWorldFunction:'と書いてあります。こちらは、今から'HelloWorldFunction'という名前のリソースの設定を記述しますという宣言になります。また、この'HelloWorldFunction'はあくまでCloudFormationとSAM内での呼び名になります。例えばAPIGatewayとこの関数を結び付ける場合、この'HelloWorldFunction'という名前をテンプレート内に記述して結びつけますが、実際の関数の名前とは異なる場合があります。  続けてその'HelloWorldFunction'に対し、'Type'と'Properties'という二つのオプションが与えられています。テンプレートファイルにはあらかじめリソースタイプというのが定義されており、Typeはその中から選択します。SAM特有のリソースタイプは以下6種類が当てはまります。CloudFormationのリソースタイプは公式ドキュメントをご覧ください。 AWS::Serverless::Function AWS::Serverless::Api AWS::Serverless::HttpApi AWS::Serverless::Application AWS::Serverless::SimpleTable AWS::Serverless::LayerVersion  Propertiesには'HelloWorldFunction'の細かい設定が記述されています。Type毎に設定できるPropertiesが決まっており、このテンプレートを日本語に訳すとこのようになります。 CodeUri: hello_world/  → ディレクトリ'hello_world/'内を参照して 'HelloWorldFunction' を作成します。 Handler: app.lambda_handler  → app.py内で定義されている関数lambda_handlerをlambdaで実行する関数とする。 Runtime: python3.8  → python3.8を使います。 Events: HelloWorld: Type: Api Properties: Path: /hello Method: get → この関数のトリガーである'HelloWorld'の中身を設定します。   'Type: Api'でHelloWorldがAPIGatewayを通じてlambdaを起動することを宣言しています。   'Proparties'はその設定です。  ちなみに、私はかなりハマったのですが、'Runtime: python3.8'の記述は、SAMの環境上で python3.8 が使用できる状態になっていないとbuild・deployできませんでした。Dockerをうまく使えばかわせそうだったのですが、結局環境にpython3.8をインストールすることになってしまいとても大変でした。(だれかDockerの使い方教えてください。)  最後に'Outputs'です。こちらはテンプレートを見るよりコンソールを直接見た方が早いと思います。このようにテンプレートで記述したOutputsが出力されています。  さて、ここまで読んでいただければテンプレートファイルに何が書けるのか、どのように書くのかが大体わかったと思います。では、テンプレートファイルへの追記を開始しましょう。 4、テンプレートファイルの変更 今回行う設定は以下の通りです。簡単なものから説明していきます。 1,Lambdaにroleを追加 2,APIGatewayの設定を記述できるよう修正 3,APIGatewayにCORSを設定  以上の3つができるようになれば、テンプレート内でリソースを作成し、それを利用して他のリソースを作成できるようになります。 1,Lambdaにroleを追加  まず、Lambdaにroleを追加してみましょう。使用するroleはあらかじめ作成済みのものを使用します。こちらは簡単で'Resources: HelloWorldFunction: Properties:'に以下の記述を追加すれば完了になります。 Role: <追加したいroleのarn> ただし、'Globals: Function:'に記述しても意味がないことに注意してください。Propertiesには、Globalsに設定できるものと個別のResourcesに記述の必要なものがあります。Roleは後者の当たります。 2,APIGatewayの設定を記述できるよう修正  'Resources: HelloWorldAPIGateway' を追加して、APIGatewayの設定を細かく記述できるようにします。'AWS::Serverless::Api' は Properties のStageNameが必須であるため、それも一緒に記述します。 Resources:  ~~HelloWorldFunctionの記述~~ HelloWorldAPIGateway: Type: AWS::Serverless::Api Properties: StageName: <任意のステージ名>  念のため、うまくいったか確認のため、ビルドしてデプロイしてみましょう。。。 Error: Failed to create/update the stack: sam-app, Waiter StackCreateComplete failed: Waiter encountered a terminal failure state: For expression "Stacks[].StackStatus" we matched expected path: "ROLLBACK_COMPLETE" at least once  あれ!? うまくいきません!! 。 。 。  そうです。勘の良い方ならお気づきでしょうか。  HelloWorldAPIGatewayとHelloWorldFunctionが紐づいていません。  HelloWorldFunction側に 'Event: HelloWorldの詳しい説明はHelloWorldAPIGatewayに書いてある'、と追記しなければなりません。 Resources:  ~~HelloWorldFunctionの記述~~ HelloWorld: Type: Api Properties: Path: /hello Method: any RestApiId: Ref: HelloWorldAPIGateway HelloWorldAPIGateway: Type: AWS::Serverless::Api Properties: StageName: <任意のステージ名>  これでHelloWorldAPIGatewayとHelloWorldFunctionが紐づきました。  ちなみにあまり本編とは関係ありませんが、このままデプロイしてもうまくいきません。OutputsのHelloWorldApi:の記述を以下のように変更してください。 Outputs: HelloWorldAPIGateway: Description: "API Gateway endpoint URL for Prod stage for Hello World function" Value: !Sub "https://${HelloWorldAPIGateway}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/" ~~ HelloWorldFunctionの記述 ~~ ~~ HelloWorldFunctionIamRoleの記述 ~~ 3,APIGatewayにCORSを設定  いよいよ最後の設定です。APIGatewayにCORSの設定を加えます。CORS設定はGlobals, Resourcesどちらでも記述できますが、今回はGlobalsに設定します。以下の記述を追加します。 Globals: Function: ~~ Functionの共通設定 ~~ Api: Cors: AllowMethods: "'<任意のメソッド>'" AllowHeaders: "'<任意のヘッダー>'" AllowOrigin: "'<任意のオリジン>'" これでCORSの設定が無事にできました。 めでたしめでたし。。。とはいきません!! こちらのCORSの設定、なんとOPTIONSメソッドにしか記述がされていません。私はアプリでPOSTを使いたかったのですが、最初のPreflightは通過したのに本命のPOSTではじかれるという苦い経験をさせられました。  じゃあ今度はPOSTのCORSの設定を記述する必要が出てきました。それにはPropertiesの 'DefinitionBody' を使います。こちらの 'DefinitionBody' はパスのメソッド毎に細かい設定ができるという優れもの(記述が多い)になります。これを 'Resources: HelloWorldAPIGateway: Properties:' にぶち込みます。長いので説明は割愛。 Resources:  ~~HelloWorldFunctionの記述~~ HelloWorldAPIGateway: Type: AWS::Serverless::Api Properties: StageName: <任意のステージ名> DefinitionBody: swagger: '2.0' info: version: '1.0' title: !Ref 'AWS::StackName' paths: /hello: post: x-amazon-apigateway-integration: httpMethod: POST type: aws uri: !Sub >- arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${HelloWorldFunction.Arn}/invocations responses: default: statusCode: '200' responseParameters: method.response.header.Access-Control-Allow-Origin: "'<任意のオリジン>'" method.response.header.Access-Control-Allow-Methods: "'<任意のメソッド>'" method.response.header.Access-Control-Allow-Headers: "'<任意のヘッダー>'" responses: '200': headers: Access-Control-Allow-Origin: type: string Access-Control-Allow-Headers: type: string Access-Control-Allow-Methods: type: string これでCORSの設定は完璧です。 最終的にテンプレートファイルはこのようになりました。 AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > testPj Sample SAM Template for testPj Globals: Function: Timeout: 3 Api: Cors: AllowMethods: "'<任意のメソッド>'" AllowHeaders: "'<任意のヘッダー>'" AllowOrigin: "'<任意のオリジン>'" Resources: HelloWorldFunction: Type: AWS::Serverless::Function Properties: CodeUri: hello_world/ Handler: app.lambda_handler Runtime: python3.8 Role: <追加したいroleのarn> Events: HelloWorld: Type: Api Properties: Path: /hello Method: any RestApiId: Ref: HelloWorldAPIGateway HelloWorldAPIGateway: Type: AWS::Serverless::Api Properties: StageName: <任意のステージ名> DefinitionBody: swagger: '2.0' info: version: '1.0' title: !Ref 'AWS::StackName' paths: /hello: post: x-amazon-apigateway-integration: httpMethod: POST type: aws uri: !Sub >- arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${HelloWorldFunction.Arn}/invocations responses: default: statusCode: '200' responseParameters: method.response.header.Access-Control-Allow-Origin: "'<任意のオリジン>'" method.response.header.Access-Control-Allow-Methods: "'<任意のメソッド>'" method.response.header.Access-Control-Allow-Headers: "'<任意のヘッダー>'" responses: '200': headers: Access-Control-Allow-Origin: type: string Access-Control-Allow-Headers: type: string Access-Control-Allow-Methods: type: string Outputs: HelloWorldAPIGateway: Description: "API Gateway endpoint URL for Prod stage for Hello World function" Value: !Sub "https://${HelloWorldAPIGateway}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/" HelloWorldFunction: Description: "Hello World Lambda Function ARN" Value: !GetAtt HelloWorldFunction.Arn HelloWorldFunctionIamRole: Description: "Implicit IAM Role created for Hello World function" Value: !GetAtt HelloWorldFunctionRole.Arn 5、最後に  ここまで読んでいただきありがとうございました。AWSを触り始めて半年も経ってないペーペーですので、書いてあることには誤りがあるかもしれません。  何か気付いたことがあればぜひコメントでご指摘頂けると幸いです。 CloudFormation・SAMの知識が全くない中やってみたので中々に大変でした。そもそも最初はCloudFormationとSAMが別物だと思っていましたし。。。CloudFormation・SAM・CKDについてもう少し勉強してからまた取り組みたいと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】VPCの基礎をまとめてみた

はじめに VPSの勉強を始めました。 備忘録としてまとめてみました。 基礎 リージョン リージョンは東京や大阪など、データセンターが置かれている物理的な場所のことです。 アベイラビリティゾーン(AZ) アベイラビリティーゾーンは一つ以上のデータセンターで構成される論理的なデータセンターです。 東京は4つ、大阪は3つあります。 各AZは、独立した冗長性のある電源やネットワークを備えています。 そのため障害が発生しても他のアベイラビリティーゾーンに影響を与えません。 リージョンとAZを詳しく知りたい場合はこちらをお読みください。 サブネット ネットワークが大規模なものになってくると、単一のネットワークで管理することが厳しくなってきます。 例えば、ブロードキャスト(ネットワーク全体に向けて発信するデータ転送)を行う場合、必要のない分まで回線を利用することになり、全体のパフォーマンスが下がります。 なので、IPアドレスの範囲を指定してネットワークを小さな単位に切り分けることで部分最適を図りましょうというのがサブネットです。 一応簡単に図解してみました。 CIDR /8や/16などをCIDR(サイダー)表記と言います。 8の場合、第2〜第4オクテットまで自由に使えます。つまり16,777,216通りのIPアドレスが使えます。 16の場合、第3〜第4オクテットまで自由に使えます。つまり65,536通りのIPアドレスが使えます。 24の場合、第4オクテットのみ自由に使えます。つまり256通りのIPアドレスが使えます。 32の場合、IPアドレスが指定されています。 10.0.0.0/8 → 10.0.0.0〜10.255.255.255 10.0.0.0/16 → 10.0.0.0〜10.0.255.255 10.0.0.0/24 → 10.0.0.0〜10.0.0.255 10.0.0.0/32 → 10.0.0.0 Amazon VPCとは? AWS内部のネットワーク環境を指します。 セキュリティ面での設定もこちらで行います。 それでは実際に作っていきましょう! 構成図 このような感じで作っていきます。 手順 ①リージョンを確認 東京に設定しましょう。 ②VPCを作成 流れは以下の通りです。 ・コンソールで「VPC」と検索 ・左ペイン内の「VPC」を選択 デフォルトで1つありますが、 こちらは使わずに新規に作成します。 「VPCを作成」を選択します。 ③サブネットを作成 流れは以下の通りです。 ・コンソールで「VPC」と検索 ・左ペイン内の「サブネット」を選択 こちらもデフォルトで何個かあります。 こちらは使わずに新規で作成していきましょう。 ここまですべて完了しました。(1cの分は省略してます。) ④internet gatewayの作成 インターネットゲートウェイとは? インターネットゲートウェイは、VPC とインターネットとの間の通信を可能にするコンポーネントです。 つまりこれがないとインターネットにインターネットにつながりません・・ 流れは以下の通りです。 ・コンソールで「VPC」と検索 ・左ペイン内の「インターネットゲートウェイ」を選択 またこちらもデフォルトで1つありますが、 こちらは使わずに新規に作成します。 作成したインターネットゲートウェイですが、状態が「Detached」になっています。 それではVPCにアタッチして状態を変更していきましょう。 インターネットゲートウェイを選択>アクション>VPCにアタッチでOK。 これで、アタッチが成功します。 ④パブリックテーブルのルートテーブルの変更 ルートテーブルとは? ネットワークの経路を設定するコンポーネントです。 サブネット内の通信がどの宛先のネットワークに対して転送されて欲しいかを設定します。 ここでおさらいです。 VPCは、10.0.0.0/21でした。 publicサブネットは、10.0.0.0/24でした。 ということで、publicサブネットのルートテーブルを表にすると、、 送信先 ターゲット 10.0.0.0/21 local となります。 ここにインターネットゲートウェイが追加されるので、 送信先 ターゲット 10.0.0.0/21 local 0.0.0.0/0 internet gateway となります。 それでは作成していきましょう。 流れは以下の通りです。 ・コンソールで「VPC」と検索 ・左ペイン内の「サブネット」を選択 ・サブネット内の「ルートテーブル」を選択 ・ルートテーブル内の「ルート」で新規に追加 これで完了です。 ⑤EC2インスタンスを作成 流れは以下の通りです。 ・コンソールで「EC2」と検索 ・ダッシュボード内で「インスタンスを起動」を選択 ・【STEP1】「Amazon Linux 2 AMI (HVM), SSD Volume Type」を選択 ・【STEP2】「t2.micro」を選択 ・【STEP3】ネットワークを「test-vpc」、サブネットを「test-public-subnet」、自動割り当てパブリックIPを「有効」にして作成 ・【STEP4】ストレージの追加はこのままでOK ・【STEP5】タグは、「Name→test-ec2-1」に設定 ・【STEP6】セキュリティはこのままでOK 最後にキーペアをダウンロードすれば完了です。 ⑥セキュリティグループの作成 ・コンソールで「EC2」と検索 ・左ペイン内の「セキュリティグループ」を選択 ・セキュリティグループを作成(SSH接続をするため) ・インスタンスからセキュリティグループを紐付ける ⑦Elastic IPアドレスの作成 Elastic IPアドレスとは? EC2のインスタンスに対して固定IPを割り当てるコンポーネントです。 Public IPアドレスの場合、停止などをするたびIPが変わってしまうため、独自ドメインのWebサイトを外部公開する時などに影響が出てしまいます。 流れは以下の通りです。 ・コンソールで「VPC」と検索 ・左ペイン内で「Elastic IP」を選択 ・「Elastic IP アドレスの割り当て」を選択 ・そのままOK ・アクション>「Elastic IP アドレスの関連付け」を選択 ・インスタンスを選択してアタッチを行う ⑧privateサブネット用のEC2インスタンスを作成 特に変わらないので省略します。 ⑨キーペアをpublicサブネットのEC2インスタンスに送る ターミナル // desktopにキーペアを設置したため $ cd desktop // 権限変更 $ chmod 400 test--keypair.pem $ ls -l test--keypair.pem -r--------@ 1 ryo staff 1704 4 30 09:54 test--keypair.pem // 送る(パブリックIP) $ scp -i test--keypair.pem test--keypair.pem ec2-user@3.115.33.139:/tmp/ // ログイン(SSH)(パブリックIP) $ ssh -i test--keypair.pem ec2-user@3.115.33.139 // キーペアがあるかを確認 $ cd /tmp/ $ ls -l -r-------- 1 ec2-user ec2-user 1704 4月 30 01:29 test--keypair.pem // privateサブネットのEC2インスタンスにログインする(プライベートIPアドレス) $ ssh -i test--keypair.pem ec2-user@10.0.2.198 The authenticity of host '10.0.2.198 (10.0.2.198)' can't be established. ECDSA key fingerprint is SHA256:9poToR45hcjPPjyBbmaiIVEr6ZWWPAPNOomueoYlwQk. ECDSA key fingerprint is MD5:a6:89:3b:b0:78:c4:0e:b6:28:fe:4d:86:a1:d9:1c:f5. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.0.2.198' (ECDSA) to the list of known hosts. __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ ⑨NAT gatewayでprivateサブネットのEC2インスタンスをインターネットに接続する NAT gatewayとは? アドレス変換を行うためのコンポーネントです。 パブリックサブネットに設置し、プライベートサブネットから外部への通信ができるようにします。 流れは以下の通りです。 ・コンソールで「VPC」と検索 ・左ペイン内で「NAT ゲートウェイ」を選択 ・NAT ゲートウェイを作成 次に、privateサブネット用のルートテーブルを作成します。 流れは以下の通りです。 ・コンソールで「VPC」と検索 ・左ペイン内で「ルートテーブル」を選択 ・ルートを編集 ・「サブネット」から「ルートテーブルの関連付けを編集」する これでVPC完成しました。 しかし、このままでは料金がかかってしまうので削除していきましょう。 それではすべて削除していきましょう! 削除する順番は、 ・EC2 ・NAT gateway ・Elastic IP ・VPC VPCの削除で依存関係のあるサブネットやinternet gatewayなども削除されます。 終わりに 途中までマスキングしましたが、最後にすべて削除するなら必要なくない?と思い途中からマスキング外しましたw 参考文献
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Lambda のAWS マネージドポリシーが変わり面倒だったこと

内容 新 旧 AWSLambda_FullAccess AWSLambdaFullAccess AWSLambda_ReadOnlyAccess AWSLambdaReadOnlyAccess 2021/3/1日以降、旧ポリシーをアタッチすることができなくなった。 何が面倒かというと、新ポリシーでアクセス許可が全て満たされていたら良いが、満たされていない場合、カスタマー管理ポリシーを作らなければいけないというところ。 例えば、既に開発環境では、旧ポリシーで動作しているが良いが、2021/3/1日以降にステージングや本番環境をデプロイしようとした時に、新ポリシーでないといけない。(もちろん、旧ポリシーのままだとそんな管理ポリシーはないよーと怒られてしまう。) で、そんな仕様について書かれているそキュメントが↓のページ 比較 AWSLambdaFullAccess { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:DescribeChangeSet", "cloudformation:DescribeStackResources", "cloudformation:DescribeStacks", "cloudformation:GetTemplate", "cloudformation:ListStackResources", "cloudwatch:*", "cognito-identity:ListIdentityPools", "cognito-sync:GetCognitoEvents", "cognito-sync:SetCognitoEvents", "dynamodb:*", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "events:*", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:GetRole", "iam:GetRolePolicy", "iam:ListAttachedRolePolicies", "iam:ListRolePolicies", "iam:ListRoles", "iam:PassRole", "iot:AttachPrincipalPolicy", "iot:AttachThingPrincipal", "iot:CreateKeysAndCertificate", "iot:CreatePolicy", "iot:CreateThing", "iot:CreateTopicRule", "iot:DescribeEndpoint", "iot:GetTopicRule", "iot:ListPolicies", "iot:ListThings", "iot:ListTopicRules", "iot:ReplaceTopicRule", "kinesis:DescribeStream", "kinesis:ListStreams", "kinesis:PutRecord", "kms:ListAliases", "lambda:*", "logs:*", "s3:*", "sns:ListSubscriptions", "sns:ListSubscriptionsByTopic", "sns:ListTopics", "sns:Publish", "sns:Subscribe", "sns:Unsubscribe", "sqs:ListQueues", "sqs:SendMessage", "tag:GetResources", "xray:PutTelemetryRecords", "xray:PutTraceSegments" ], "Resource": "*" } ] } AWSLambda_FullAccess { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:DescribeStacks", "cloudformation:ListStackResources", "cloudwatch:ListMetrics", "cloudwatch:GetMetricData", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "kms:ListAliases", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:GetRole", "iam:GetRolePolicy", "iam:ListAttachedRolePolicies", "iam:ListRolePolicies", "iam:ListRoles", "lambda:*", "logs:DescribeLogGroups", "states:DescribeStateMachine", "states:ListStateMachines", "tag:GetResources", "xray:GetTraceSummaries", "xray:BatchGetTraces" ], "Resource": "*" }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": "lambda.amazonaws.com" } } }, { "Effect": "Allow", "Action": [ "logs:DescribeLogStreams", "logs:GetLogEvents", "logs:FilterLogEvents" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/*" } ] } iam:PassRole 今回ひっかっかたのが、この iam:PassRole だ。 iam:PassRole はユーザーがIAMロールをAWSサービスに渡すアクセス許可を定義する。 このアクションが許可されていないと、そもそも IAMロールをパスできない。 旧ポリシーの場合 : パスするIAMロールやパス先サービスを制限せずに、iam:PassRole を丸っと許可しています。 { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "*" } 新ポリシーの場合 : Lambdaに対してのみIAMロールをAWSサービスに渡すアクセスを許可する。 { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": "lambda.amazonaws.com" } ドキュメントは、次のページがシンプルだ。 リンク AWS Lambda AWS IAM
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】IAM Rolesとは?ざっくり解説します no.5

こんにちは、まゆみです。 AWSについての記事をシリーズで書いています。 今回は第5回目になります。 今回の記事では、『IAM Roles』とは何かということに焦点を絞って書いていきます IAM Roles については、シリーズ第2回目の記事でも、IAM Policy と比較しながら少し触れていますので、『IAM Policy』とは何なのか興味のある方はこちらから参考にどうぞ。 ではさっそく始めていきますね。 IAM Roles とは? 以前の記事で、IAM Policyは、ある特定のユーザーもしくは特定のグループに所属する人に与えられるアクセス権限だと説明しました。 IAM Roles がIAM Policyと違う点は、IAM Roles は、AWSのインスタンス(EC2のこと)などに対して付与されるものであることです。 引用元:AWSコンソール では、どんな時にIAM Roles が使われるのかという疑問がわいてくると思います 引用元:AWSコンソール 一般的にRolesが使われるのは、EC2もしくはLambdaに対してになります。 今回の記事では、Roles がEC2に対してどのような時に使われるのか見ていきましょう 例えばEC2からあるファイルを取りに、S3にアクセスしないといけないとします。(EC2とはバーチャルサーバーで、S3はストレージサービスになります) そのような時に、特定のユーザーにアクセス権限を与えるPolicy ではなく、Rolesを与えることになります。 まとめ 今回の記事は短いですが、ここで締めくくらせていただきます。 先ほど少し触れました、EC2やLambdaに関しては、また改めて記事を書いていきますね。 よろしくお願いします。<(_ _)>
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSのVPCについてまとめてみた

VPCとは AWSの仮想ネットワークを作成するサービスです。セキュリティーの設定もここに含まれます。 全てのサービスを作る上で、土台となるネットワークを作成するサービスなので、AWSの勉強をするときには基本的にVPCから学ぶのがおすすめです。 VPCを作成するときに、最初にリージョンの設定を行う必要があります。 リージョン、アベイラビリティゾーン(AZ)について アベイラビリティゾーンはAZと略されることも多いので、今後はAZと表記します。 アベイラビリティゾーン(AZ) サーバーを置いているデータセンターが集合している場所のことです。 リージョン AZを束ねた地域のことです。 世界中にリージョンは存在していて、日本にはTokyoリージョンとoosakaリージョンがあります。 東京リージョンを使用する場合は、下記のような表し方をします。 「ap-northeast」が東京リージョンを表し、末尾の「1」はAZを表します。 東京リージョンのAZは現在下記の3つが主に使われています。 VPCを使うとこの3つのAZを使うことができます。 サブネットについて VPCでネットワークを構成するときに、セキュリティーレベルをあげるためにネットワークを細かく区切ることがあります。 その細かく区切るための小さなネットワークをサブネットと呼びます。 サブネットには「Public subnet」と「Private subnet」と呼ばれる2種類が存在します。 インターネットゲートウェイに接続できるかどうかの違いがあります。 簡単に説明すると「Public subnet」はインターネットで外部からアクセス可能なサブネットで、「Private subnet」はVPCのネットワーク内でのみアクセス可能なサブネットになっています。 AWSの中にVPCを作成し、更にその中にサブネットを複数作成できます。 VPCやサブネットにはIPアドレスを割り当てて使用します。 IPアドレスやサブネット(サブネットマスク・CIDR表記)に関する詳しい説明はこちらにまとめています。 このサブネットの中にEC2などのインスタンスをたてて、サーバーの設置などを行います。 https://qiita.com/a_goto/items/396dee5c6d894392acb3 VPCのネットワークコンポーネントについて ネットワークコンポーネントとはVPCの機能を分解してコンポーネント(部品)として扱えるようにしたものです。 VPCでネットワークを作成し、ネットワーク内でサブネットにIPアドレスをアタッチ(付与)したり、インターネットに繋げれるようにしたり、セキュリティーの設定など様々な機能を追加するのに使います。 ここでは下記について説明します。 ルートテーブル インターネットゲートウェイ NATゲートウェイ ENI Elastic IPアドレス セキュリティグループ ネットワークACL 例えば下記のように、VPCにサブネットを2つ用意し、その中にEC2インスタンスをそれぞれAとBを設置し、様々な機能を追加していくとします。 このEC2のAとBを紐付けて通信通信する場合に必要な機能の説明をします。 ルートテーブル、NetworkACL、セキュリティグループを例に取ります。 ルートテーブルについて ルートテーブルは、サブネットに関連付けて使用するもので、サブネットから外に出る通信を、どこに向けて発信するのかを定義づけるルールのことです。 ルートと呼ばれる下記のようなルールで構成されます。 ターゲットに設定されているLocalというのはVPC内のことを指します。 10.0.0.0/21に向けての通信はVPC内に向けて通信が発信されるようになります。 デフォルトではこの設定がされており、ここにルールを追加していくことが可能です。 基本的にルールは細かく指定したものが優先されるため、細かく通信の制御を設定することで、通信できる範囲を絞ってセキュリティーを高めていくことができます。 例えば下記のようなルールを追加すると、 10.0.0.0/21に向けての通信は上記と同じで、VPC内に向けて通信が発信されて、 それ以外に向けての通信は全て、インターネットに向けての通信が発信されるようになります。 インターネットゲートウェイ インターネットゲートウェイとはVPC内のAWSリソースとインターネットを繋げるための機能です。 VPCのネットワークからインターネットに通信を可能にするためには、下記のようにこのインターネットゲートウェイをVPCにアタッチする必要があります。 インターネットゲートウェイの特徴としては、インターネットからアクセスが集中しても、自動でスケールして対応してくれるため高い可用性があります。 そして、下記の図のようにサブネットのルートテーブルの設定を使用します。 また、サブネットからインターネットゲートウェイへのルーティングは、Public subnetからのみ可能になっています。 使い分けとしては、インターネットからアクセスしても問題ないリソースなどはPublic subnetに配置し、セキュリティレベルを上げたい、データベースなどのリソースはPrivate subnetに配置します。 NATゲートウェイ NATゲートウェイはプライベートサブネットからインターネット接続を可能にする機能です。 ただし、アウトバウンドはできるが、インバウンドはできません。これにより外部からプライベートサブネットには接続できないのでセキュリティが担保される。 ENI(Elastic network interface) 仮想ネットワークインターフェイスの略で、EC2インスタンスなどにIPアドレスをアタッチすることができる機能です。 同じAZ内のインスタンスにアタッチ/デタッチができます。 EC2にはデフォルトでENIが付与されている。 一つのインスタンスに複数のENIを付与することができる。 このENIとインターネットゲートウェイが接続することで、Public subnetとインターネットが接続可能になる。 Elastic IPアドレス 外部のネットワーク同士が接続するためには、外部接続用のIPアドレスが必要になります。 AWSにも外部用のIPアドレスを付与する機能が2つ用意されています。 「Public IP アドレス」「Elastic IP アドレス」の2つです。 Public IP アドレス AWSのIPアドレスプールにより割り当てられる外部接続用のIPアドレスで、インスタンスが再起動、停止、終了したときに開放されます。 開放されることで、確率は低いですが他のネットワークが再度同じIPアドレスを保つ可能性もあります。 設定で有効にしていると、自動で割当されます。 基本的には使わない法が良いと思います。 Elastic IP アドレス 同じく外部接続用のIPアドレスで、インスタンスにアタッチ/デタッチが可能で、 静的なパブリックIPアドレスのため、再起動、停止、終了したときでも同一のIPアドレスになります。 どこにもアタッチしていない場合1時間あたり1円の料金が発生するので注意が必要です。 どこかにアタッチしていれば料金はかかりません。 図が少しややこしいですが、EC2インスタンスはENIを持っており、このENIに外部接続用のElastic IPアドレスがくっついているイメージです。 セキュリティグループ AWSの仮想ファイアーウォールサービスのことです。 ファイアーウォールとは通信を制限するフィルターのようなものです。 インバウンドとアウトバウンド両方の設定を行える。基本的にアウトバウンドの設定をすることはあまりない。 ENIの単位で設定します。 ネットワークACL サブネット単位で設定するファイアーウォールのことです。 ステートレス・インスペクション型といって、アウトバウンドの通信を許可した場合、インバウンドも明示的に設定する必要があるのが特徴です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIでCognitoのFORCE_CHANGE_PASSWORD→CONFIRMEDへ変更

調べた記事で試しても上手くいかないが続き、たどり着いた結論をメモ permanentがミソ awscli $ aws cognito-idp admin-set-user-password \ --user-pool-id <user-pool-id> \ --username <username> --password <password> --permanent トークンのとり方もわかったのでついでで追記 awscli $ aws cognito-idp admin-initiate-auth \ --user-pool-id <user-pool-id> \ --client-id <client-id> \ --auth-flow ADMIN_NO_SRP_AUTH \ --auth-parameters USERNAME="USERNAME",PASSWORD="PASSWORD"
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS アカウントを 40 個抱える 300 人の会社で AWS SSO を導入した話

はじめに 先日、会社の AWS Organizations で AWS Single Sign-On(SSO)を利用できるようにしました。 既存の AWS アカウントが 40 個ほどあり、一気にすべてのアカウントで AWS SSO の利用を強制することは難しかったので、とりあえず新規のアカウントから AWS SSO を使ってもらうことにしました。 ちょうど今週、初申請があったので、記念に記事にしようと思います。 AWS SSO を導入するといっても、組織の規模によって使い方が異なると思います。 ちなみに筆者の会社はデータ分析の受託を主な事業にしていて、スタッフは 300 人ほどです(全員が AWS ユーザーなわけではありません)。 AWS アカウントは、おおよそ顧客単位で分かれています。 みなさんもこの記事を参考にご自身の組織に合った利用方法を見つけていただければ幸いです。 導入のきっかけ 筆者の会社では、コロナ禍で在宅ワークが前提になり、以前からセキュリティ対策の強化が課題でして、1 つのシングルサインオンサービスからあらゆる Web サービスにユーザー認証できる状態を目指していました。 AWS では個々のアカウント毎にシングルサインオンサービスとの紐づけが可能なことは知っていたのですが、アカウントが 40 個ほどあるので設定が面倒だと感じていたところに、(遅ればせながら) AWS SSO を見つけたので提案することにしました。 AWS SSO のメリット AWS SSO には下記のようなメリットがあります。 マスターアカウント上に作成した AWS SSO ユーザーですべての AWS アカウントにサインインできる AWS 以外の ID プロバイダー(Azure 等)のユーザーを丸々同期して持って来ることも可能 スタッフ退職時のユーザー削除が楽 API キーがセッション単位で自動生成されるため、自分で更新する必要がない 各アカウントの IAM ユーザーの場合、自分で API キーを更新する必要がある 各アカウントで誰がどんな権限を持っているか一目できる サインイン時にシングルサインオンサービスのアクセスポリシーを適用できる 筆者の会社では、Azure を ID プロバイダーとし、Azure ユーザーで AWS を使えるようにしています。 さらに Azure とシングルサインオンサービスを連係していて、AWS に Azure ユーザーでサインインする際に、シングルサインオンサービスの下記アクセスポリシーが適用されるようにしています。 VPN の IP アドレスからのアクセスのみを許可 多要素認証を強制 IAM ユーザーは使わないのか AWS SSO のメリットを最大限に活かすためにも、弊社のスタッフには AWS SSO ユーザーで認証してもらい各アカウントの IAM ユーザーは基本的に利用しない方針としましたが、下記の場合は例外として IAM ユーザーを使ってよいことにしました。 外部ユーザー 過去に、データを受領する場合等、顧客や協業する他ベンダーの担当者に自社 AWS アカウントにアクセスしてもらいたいケースがありました。 ほとんどの場合、そういった方々は ID プロバイダーにユーザーがいないので AWS SSO は使えません。 ID プロバイダーにユーザーを用意するにしても、自社スタッフとはアクセスポリシーを分ける必要がある等、設定が煩雑になります。 ということで、弊社では個々の AWS アカウント内に外部ユーザー用の IAM ユーザーを作成してよいことにしました。 バッチユーザー S3 からデータを取得して Redshift にインポートする処理を EC2 から定期的に実行したい場合、EC2 のサービスロールを作成したりしますが、同じような感覚で、特定のスタッフに紐づかない共通の IAM ユーザーを作成してよいことにしました。 運用体制はどうするか 筆者の会社では AWS ユーザーを3区分に分類しています。 役割名 想定人数 主な役割 アカウント管理者 2~3人 AWS アカウントの作成や削除。ルートユーザーの管理。AWS Organizations の全体管理。プロジェクトへのコストの請求。 リソース管理者 数十人 割り当てられた AWS アカウントの管理。コスト監視。各種リソースのセキュリティ設定。一般ユーザーの権限調整。AWS アカウントの作成や削除の申請。 一般ユーザー 数百人 特定の AWS アカウントにおいて、そのアカウントのリソース管理者が決めた権限の範囲内で AWS を操作。 リソース管理者は通常、プロジェクトからスキルマッチしたスタッフを割り当てます。 リソース管理者から AWS アカウントの作成申請があれば、アカウント管理者が AWS アカウントを作成し、リソース管理者にそのアカウントで一番強い権限を付与する仕組みにしています。 一般ユーザーの権限は誰が設定するか 一番難しかったのは、一般ユーザーの権限を誰が設定するのかという点でした。 リソース管理者に任せる場合、マスターアカウントで AWS SSO を操作する権限を付与する必要がありますが、リソース管理者は将来的に何十人にもなる想定だったので、そんな大人数に AWS SSO を操作させることに何となく抵抗がありました。 そのため、当初の提案では、リソース管理者の申請に基づきアカウント管理者が一般ユーザーの権限を設定する仕組みにしていました。 ところが現場マネージャー陣へのレビューのタイミングで「アカウント管理者の作業が増えて運用が回らない」と指摘され、再検討することになりました。 たしかに AWS の権限は実際に動かしながら調整することがほとんどですし、徐々に利用するサービスの種類が増えてそれに合わせて権限も広げていかないといけないことが多いと思います。 ということで、最終的にリソース管理者が AWS SSO を操作し、自分の AWS アカウントに一般ユーザーを割り当てたり、一般ユーザーの権限を編集できるようにしました。 リソース管理者に AWS SSO の操作をどこまで許すか AWS SSO では AWS アカウント、ユーザー、アクセス権限セットの3つを組み合わせることで「どのアカウントで誰が何をできるのか」を設定しますが、リソース管理者にアクセス権限セットの作成や削除を許可してしまうとアクセス権限セットがぐちゃぐちゃになってしまう懸念があったため、アクセス権限セットを作成したり削除できるのはアカウント管理者のみとしました。 つまり、アカウント管理者はアカウント毎に専用の一般ユーザー用アクセス権限セットを作成し、リソース管理者は自分のアカウント用に作成された一般ユーザー用のアクセス権限セットを編集することで一般ユーザーの権限を調整できるようにしました。 一般ユーザー用のアクセス権限セットはデフォルトで3つとし、申請で増やせるようにしました。 このとき、リソース管理者が担当外のアカウントに一般ユーザーを割り当ててしまったり、担当外のアカウントの一般ユーザー用アクセス権限セットを編集してしまったりできないようにする必要がありました。 それを実現するために、リソース管理者が AWS SSO を操作するためのアクセス権限セットにおいて、一般ユーザーの割り当てが可能なアカウントを担当アカウントのみにし、編集可能な一般ユーザー用アクセス権限セットを担当アカウント用に作成されたもののみに限定しました。 なお、リソース管理者の向学のために、担当外のアカウントの一般ユーザー用アクセス権限セットも閲覧はできるようにしています。 アクセス権限セットの使い分け 以上を実現するために下表のとおりアクセス権限セットを使っています。 No. アクセス権限セット名 割り当て先アカウント 割り当てる人 割り当てられる人 1 アカウント管理者権限 すべてのアカウント アカウント管理者 アカウント管理者 2 リソース管理者権限 担当するメンバーアカウント アカウント管理者 リソース管理者 3 一般ユーザー割り当て用権限(〇〇アカウント用) マスターアカウント アカウント管理者 リソース管理者 4 一般ユーザー権限①(〇〇アカウント用) 担当するメンバーアカウント リソース管理者 一般ユーザー 5 一般ユーザー権限②(〇〇アカウント用) 担当するメンバーアカウント リソース管理者 一般ユーザー 6 一般ユーザー権限③(〇〇アカウント用) 担当するメンバーアカウント リソース管理者 一般ユーザー なお、アカウント管理者の作業(1~6の作成と1~3のリソース管理者への割り当て)は PowerShell で自動化しました。 実際に一番大変だったのは マニュアル作成が大変でした。 この記事でも言えることですが、運用自体は簡単なものの、文字で伝えるには話がちょっとややこしかったです。 「AWS 初めてです」というスタッフもいるので、用語を定義したり画面キャプチャを貼ったりしたので、結構時間がかかりました。 おわりに わかりやすくまとめられたか心許ありませんが、事実そのままが伝わらなくとも、感じだけでも掴んでいただいて、みなさんの組織で AWS SSO を導入する際の助けになれば幸いです。 AWS SSO の設定方法は下記記事にも書きましたので、よろしかったら参考にしてください(ほぼリンクですが)。 以上
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CDK で他人が作った環境を自分の環境のスタックにデプロイする

はじめに もはやCFn(CloudFormation)に環境設定を直書きしてる方は絶滅危惧種のようです...(知りませんでした) CFnのような面倒な記述なく、Pythonなどでゴリゴリ書けるCDKがトレンドみたいです。 CI/CDで自動デプロイできるかの検証はまだできてないです(ゴメンナサイ) 【注意】あくまで他人が作ったAWS環境を自分のAWS環境に移行するための手順です。 【注意】あらかじめ他人のAWS環境のCDK構築ファイル群をもらっておく必要があります。 Macユーザー向けです。 AWSを熟知している方、普段からCLIを触っている方、CloudFormationを書いたことある方向けです。 環境に合わせた任意の変数は{}で表現しています。 動作確認済みの環境 バージョン OS MacOS Catalina 10.15.6 Python 3.9.1 pip 20.1.1 Node.js 12.16.1 npm 6.14.8 aws-cdk 1.16.0 aws-cli 2.0.44 事前準備 Homebrewをインストール ?https://brew.sh/index_ja pyenvをインストール $ brew install pyenv PATHを通す $ vim ~/.bash_profile //bashではなくzshを使っている場合は~/.zprofile // 下記の3行を追記する export PYENV_ROOT="$HOME/.pyenv" export PATH="$PYENV_ROOT/bin:$PATH" eval "$(pyenv init -)" // 3行追記して保存(:wq)したら下記コマンドで変更内容を反映する $ source ~/.bash_profile python 3.8.5 をインストール $ pyenv install 3.8.5 $ pyenv global 3.8.5 $ python3 -V //3.8.5であることを確認 aws-cliをインストール ?https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2.html aws-cliとAWSアカウントを紐付ける $ aws configure AWS Access Key ID : {自分のアカウントのアクセスキー} AWS Secret Access Key : {自分のアカウントのシークレットキー} Default region name : ap-northeast-1 Default output format : json CDKによるリソースデプロイ CDKの準備を行う $ mkdir {hoge} $ cd {hoge} //.envがある環境 // 他人が作った環境のCDK資源をhogeフォルダにコピペする $ python3 -m venv .env //初回のみ実行 $ source .env/bin/activate //仮想環境を展開 // 仮想環境から出たい場合は、`$ deactivate` // 仮想環境に入ると、$マークの前に(.env)が表示されます。 (.env)$ pip install -r requirements.txt //(初回実行のみ)ライブラリをインストール // 下記のWARNINGは無視してOK。 // WARNING: You are using pip version xx.x.x; however, version xx.x is available. (.env)$ cdk ls 対象環境にCDK Appを作成する (.env)$ cdk synth //CFnフォーマットに変換されてテンプレートが出力される (.env)$ cdk diff //diffチェックをする 対象環境にCDKでリソースをデプロイする (.env)$ cdk deploy // deployコマンドを流すと、実行するかどうか聞かれるのでyを入力する。 // failed creationエラーが出た場合はwebコンソールから対象スタックを一度削除して再度デプロイする。 デプロイ完了!! Stack ARN: arn:aws:cloudformation:ap-northeast-1:{アカウント番号}:stack/{スタック名}/{スタックID} //上記が出力されればデプロイ完了! //CLIで全てデプロイできたら、webマネジメントコンソールからスタックが出来上がっていることを確認できます。 おわりに CFnの面倒な作業から解放されるCDKなるものがあるとは知りませんでした。 IaCがこんなに簡単に実現できるとは、さすがAWSです?
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む