1. はじめに 自分は業務ではAWSを一切利用しないのですが、会社の方針で受験することになりました。 自分と同じ境遇の方がSAA-C02を受験する際に参考になれば幸いです。 2. 受験前の自分の状態 Microsoft製品専門のインフラエンジニア 2.5年 AWSについては存在くらいしか知らない(S3とかEC2とか聞いたこともない) Azureについては一通り知っている(基本設計〜構築ができる程度) 3. 受験準備 3.1 準備内容 3.1.1 AWSの初心者向け講座 ※Udemyの講座です。講座名は「AWS：ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得」。本ページでは「AWSの初心者向け講座」と呼称インフラの初学者かつAWS初学者におすすめです。また説明も分かりやすいです。試験勉強向けというよりインフラ+AWSの基本的な技術習得向けです。 インフラの基礎(例：ポートとは何か)を説明してくれています。 AWSを始める〜AWS上でWebサーバを構築する、までできるようになりました。 3.1.2 AWSハンズオン AWSを触る機会が少ない人にとてもおすすめです。誰でも利用可能な公式のハンズオン動画です。 AWSのドキュメントを読むときに、内容を頭の中で絵としてイメージできるようになりました。 AWSの代表的なベストプラクティスを数パターン知ることができました。 3.1.3 AWS試験対策の講座(模擬試験とイントロのみ) ※Udemyの講座です。講座名は「これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）」。本ページでは「AWS試験対策の講座」と呼称SAA-C02について説明してくれています。模擬試験は後述のAWS模擬試験問題集と一部重複しています。自分は講義部分は聞いていないですが、周りのSAA-C02取得者が2名(業務でAWSを利用しているインフラエンジニア)が利用していたようで、評判は良かったです。 3.1.4 AWS模擬試験問題集 ※Udemyの講座です。講座名は「【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）」。本ページでは「AWS模擬試験問題集」と呼称模擬試験6回分です。少し難しめですが、勉強になります。AWSはサービス仕様が変更されることがあり、その変更に伴い問題の正解も変わってしまうことがありますが、この模擬試験はそういった変更の反映にも随時対応してくれています。 3.1.5 WEB問題集 1000問以上の問題があります。超基本問題も多くあり、基礎の勉強に役立ちます。答えを入力した後、すぐに解答/解説が見れるので1問単位で隙間時間に学習できて便利です。AWS模擬試験問題集に比べサービス仕様の変更の反映は遅い印象です。 3.2 準備の流れ AWSの初心者向け講座を一通り受講 AWS試験対策の講座のイントロを観て試験に出るサービスを確認 AWSハンズオンのうち自分が気になったハンズオン(5個)を実施 AWS模擬試験問題集の第1-5回を3周とWEB問題集を1周、不明点を調べながら解く 。問題を解くときに意識したことは以下 なぜその答えが正しいのかを頭の中で要約する 不正解の選択肢がなぜ不正解なのかを頭の中で要約する 情報が混乱してしまうことはノートにまとめる(例：各ストレージサービスの用途比較) AWS模擬試験問題集の第6回とAWS試験対策の講座の模擬試験の第1,3回を本番だと思って解く 試験 結果(正答率) AWS模擬試験問題集 第6回 64 % AWS試験対策の講座の模擬試験 第1回 73 % AWS試験対策の講座の模擬試験 第3回 65 % 4と5でわからなかった問題を解き直す AWS試験対策の講座の模擬試験の第2回を本番と思って解く 試験 結果(正答率) AWS試験対策の講座の模擬試験 第2回 63 % 6でまだわからなかった問題、7でわからなかった問題を解き直す→受験当日にやりましたが途中までしかできませんでした 3.3 費やした時間 (休日16日×6時間)+(平日20日×2時間)程度だと思います。 4. 受験当日 4.1 試験内容 準備段階でやった問題を理解して解けていれば、解けるような問題がほとんどでした。 準備段階でやった問題と全く同じ問題は2-3割程度でした(あまり準備段階で実施した問題文自体を具体的に覚えていなかったのでもっと多いかもしれないです)。 4.2 受験環境 テストセンターで受験しました。春先で暖房が効いていたことと、自分が暑がり&乾燥に弱いこともあり、とても喉が乾きました。途中でお手洗いに行けたのでうがいをしてしのぎました。 5. 準備前に戻ったとしたら AWSを学習する初手として、AWSの初心者向け講座の代わりにAWS試験対策の講座を一通り受講すると思います。AWSの初心者向け講座はインフラ初学者にはおすすめですが、経験者の場合、講義内容と自分の知識が重複することが多いと感じたためです。

はじめに https://aws.amazon.com/jp/builders-flash/202002/datalake-on-aws/?awsf.filter-name=*all データレイク?データウェアハウス? 「データを蓄積して分析するための環境」という意味ではデータウエアハウスもデータレイクも同じ データウェアハウス：「目的指向」のため、どういう分析をするのかという目的を決めてから、そのための環境として構築される データレイク：目的を持たずにデータを一元的に管理するもの データレイクを構築するには? まだデータレイク構築はしたことがないという IT エンジニアの方には、「AWS Lake Formation」というサービスをご紹介。 データレイクへのアクセス制御を一元で定義して管理し、データの機密性を強化するビジネスメタデータをデータに付けることで安全なデータレイクを素早く構築できる AWS CloudFormation を使ったデータレイクの構築 AWS CloudFormationを利用することで、AWS クラウド上に、安全で柔軟があり、かつコスト効率の高いデータレイクを短時間でデプロイできます。 このテンプレートを実行すると、上記のように Amazon S3、AWS Glue、Amazon Elasticsearch Service、Amazon DynamoDB、AWS Lambda や Amazon API Gateway などで構成されたデータレイクが、デフォルト設定の場合であれば、約 30 分程度 (目安) で自動デプロイ可能 より運用管理負荷が低いデータレイクを実現するには？ データレイクもサーバーレスで構築できる。 AWS では Amazon Kinesis Data Streams や Amazon Kinesis Data Firehose、Amazon S3 などのサービスを使用したサーバレスデータレイクの設計、構築、および運用もできる。

概要 AWSリソースをコード化してくれるサービスで、テキストファイル(=テンプレート)にリソースの構造を記述してCloud Formationのサービス画面で読み込ませると、AWSリソースを自動作成してくれる。 自動生成だけでなく、変更や削除もできる。 テンプレートのファイル形式はXML,JSONなどあるが、YAMLをオススメしています。 理由: コメントの記述が可能な点、人間にとって読みやすい点です。 スタック テンプレートを読み取って作成されたAWSサービスの集合体のことをスタックと呼びます。 テンプレートの構文途中にエラーがあっても中途半端に生成されることはなく、自動でロールバックされる。 更新時 テンプレートを新しく更新して改めてCloudFormationに読み込ませることで、バージョン2のスタックに更新される。 削除時 スタック単位で作成していたもの全てが削除される。 Drift Detection テンプレートでスタックを作成した後、GUI(手動)でS3を削除した際差分が生まれてしまうケースがあります。 この差分を検知してくれる機能をDrift Detectionと言い、どこに差分があるのか検出できます。 CloudFormationテンプレート テンプレートはAWS独自の記述式となっていて、9つのセクションで分かれている。 1,AWSTemplateFormatVersion 　このテンプレートのバージョン 2,Description 3,Metadata 4,Parameters 　パラメーターを設定する領域 5,Mappings 6,Conditions 7,Transform 8,Resources 　重要なのはResourcesセクションとなっている 9,Outputs Resourcesセクション VPC,EC2,S3など作成したいAWSリソースに対してそれぞれ記述していく。 茶色の文字がCloudFormationで決められた形式で赤文字がユーザー側で記載していく。 Logical IDは論理ID(名前のようなもの)。 Typeは作成するAWSリソースを記載。 PropertiesはTypeについての詳細を記述。 この3セットを作成するリソース分記述する。 必要なプロパティなどは公式ドキュメントを読みながら記述していく。 作成デモ用テンプレートファイル テンプレートファイル (ver 1) AWSTemplateFormatVersion: 2010-09-09 Resources: MyVPC2: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.8.0/21 EnableDnsSupport: true Tags: - Key: Name Value: MyVPC2fromCF subnetName: Type: AWS::EC2::Subnet Properties: AvailabilityZone: "ap-northeast-1a" VpcIp: !Ref MyVPC2 CidrBlock: 10.0.8.0/24 Tags: - Key: Name Value: subnet1formCF <<手順>> AWS CloudFormation < スタックの作成 < 新しいリソースを使用(標準) スタックの作成 テンプレートの準備完了状態にチェック、 テンプレートソースはテンプレートファイルのアップロードにチェック、 上のyamlファイルをアップロードし、次へを選択 (一旦S3にアップロードされて、且つ形式などに誤りがある際はエラーが出る) スタックの名前をつけて次へを選択 テンプレート更新 作成したテンプレートファイル(ver 1)で作成したVPCと紐づいた状態で そのファイルに追加で記述したものを、CloudFormationにアップロードすることで更新される。 更新方法は作成時と似ていて 該当のスタックを選択し、更新するボタンを選択　< 既存テンプレートを置き換えるを選択 ここでテンプレートの指定にテンプレートのアップロードを選択してファイルをアップロードします。(← この辺りは作成時と同じ) テンプレートファイル (ver 2) AWSTemplateFormatVersion: 2010-09-09 Resources: MyVPC2: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.8.0/21 EnableDnsSupport: true Tags: - Key: Name Value: MyVPC2fromCF subnetName: Type: AWS::EC2::Subnet Properties: AvailabilityZone: "ap-northeast-1a" VpcId: !Ref MyVPC2 CidrBlock: 10.0.8.0/24 Tags: - Key: Name Value: subnet1fromCF secGroupName: Type: AWS::EC2::SecurityGroup Properties: GroupName: GroupName-SG GroupDescription: GroupDescription-SG VpcId: !Ref MyVPC2 SecurityGroupIngress: - IpProtocol: tcp FromPort: 22 ToPort: 22 CidrIp: 0.0.0.0/0 Tags: - key: Name Value: SGfromCF 必要なプロパティは公式を検索して記述していく Ref関数 組み込み関数 !Ref (リファレンスの略で参照の意味) 同じテンプレートファイル内で作成されたパラメータまたはリソースの値を返す。 同ファイル内にMyEC2Instanceが使用されていることを条件に プロパティのインスタンスIDにMyEC2Instanceという論理IDを同一にすることで紐付けうことができる。 クロススタック参照 実際の運用では、リソースの種類によってテンプレートファイルを分割する運用を推奨しており、上のテンプレートで作成されたVPC,subnet,SGとは別にEC2を作成するためのテンプレートファイルを作成していく。 その中で、お互いのリソースを参照し合うような状態(例: !Ref関数)が発生する事がある。 これをクロススタックという。 Outputsセクション クロススタックを行うにはOutputsという他のテンプレートから参照させる準備の領域が必要でこの設定を参照元に書いていく。 記述に必要なものは3つ ・論理ID(Subnet1) 　　名前のようなもの ・value 　　同じテンプレート内のデータをvalueとして取得 ・Export 　　他のテンプレートから、Nameに指定した文字をImportValueで参照できる Outputs: Subnet1: Value: !Ref subnetName Export: Name: Subnet1Name Sg1: Value: !GetAtt secGroupName.GroupId Export: Name: SG1Name ImportValue関数 参照したいファイルで記述 別のテンプレートファイルの中身を参照する(クロススタック)際はRef関数でなく、ImportValue関数を使用する。 GetAtt関数 参照させたいファイルで記述 論理IDに.をつなぐことで中身を指定して取得できる。 どんな戻り値を取得できるか調べる際は公式ドキュメントを確認↓ AWS CLIを使用したスタックの基本操作 aws cloudformation deploy AWSにSSH接続した後 スタック作成時のコマンド $ aws cloudformation deploy --template-file stack_s3_param.yml --stack-name s3bucketcreate オプション --template-file → テンプレートを作成するためのファイル名 --stack-name → 作成されるスタックに名前をつける aws cloudformation delete-stack スタック削除時のコマンド $ aws cloudformation delete-stack --stack-name s3bucketcreate --stack-name → スタック名を指定 パラメーター値を指定する コマンドラインで引数を指定 AWSTemplateFormatVersion: "2010-09-09" Description: CloudTechDemoS3 Parameters: S3BucketName: Type: String Description: Type of this BacketName. Resources: S3Bucket: Type: AWS::S3::Bucket Properties: BucketName: !Sub ${S3BucketName} $ aws cloudformation deploy --template-file stack_s3.yml --stack-name s3bucketcreate --parameter-overrides S3BucketName=samplecloudtechbucket オプション --parameter-overrides → S3BucketNameという変数にsamplecloudtechbucketという値を指定。 外部設定ファイルからパラメーターを読み込む ファイルに以下のコードを書いた状態 s3config.cfg S3BucketName=samplecloudtechbucket2 $ aws cloudformation deploy --template-file stack_s3.yml --stack-name s3bucketcreate --parameter-overrides $(cat s3config.cfg) $(cat s3config.cfg)部分でS3のバケット名に ！Sub ${S3BucketName}と記述していたことで、s3config.cfgが使用される CloudFormationで作成したS3Bucketの論理IDを出力できる $ aws cloudformation describe-stack-resource --stack-name s3bucketcreate --logical-resource-id S3Bucket 設定ファイルと分けるメリット テストや本番といった環境の変化によっても一つのテンプレートを使いまわせる。 RDS作成 Stack.yml Stack.yml AWSTemplateFormatVersion: "2010-09-09" Description: CloudTechDemo Parameters: DatabasePassword: Type: String Description: Database password NoEcho: "true" ApplicationSubnets: Type: List<AWS::EC2::Subnet::Id> Description: Target subnets VpcId: Type: AWS::EC2::VPC::Id Description: Target VPC DBinboundCidrIPs: Type: String Description: SecurityGroupInboundIP Resources: ApplicationDatabase: Type: AWS::RDS::DBInstance Properties: Engine: MySQL EngineVersion: 5.7 DBInstanceClass: db.t2.micro AllocatedStorage: 10 StorageType: gp2 MasterUsername: CloudTech MasterUserPassword: Ref: DatabasePassword DBName: CloudTech VPCSecurityGroups: - !Ref ApplicationDatabaseSecurityGroup DBSubnetGroupName: !Ref ApplicationDatabaseSubnetGroup MultiAZ: "false" AvailabilityZone: !Sub ${AWS::Region}a Tags: - Key: Name Value: !Sub ${AWS::StackName}-db ApplicationDatabaseSubnetGroup: Type: AWS::RDS::DBSubnetGroup Properties: DBSubnetGroupDescription: Application Database Subnet Group SubnetIds: !Ref ApplicationSubnets Tags: - Key: Name Value: !Sub ${AWS::StackName}-db-subnet-group ApplicationDatabaseSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: !Sub ${AWS::StackName} Application Database Security Group VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 3306 ToPort: 3306 CidrIp: !Ref DBinboundCidrIPs Tags: - Key: Name Value: !Sub ${AWS::StackName}-db-sg dev.cfg dev.cfg DatabasePassword=xxxx ApplicationSubnets=xxxx VpcId=xxxx DBinboundCidrIPs=xxxx 最後に... デモで作成したRDSはそのままだと料金が発生するのでスタックごと削除します。 $ aws cloudformation delete-stack --stack-name RDSmySQLcreate スタック名がRDSmySQLcreateのスタックを削除するコマンドです。 参考 この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。

概要 AWSアカウント作ったので、サーバ1台立ち上げたいため、セキュリティ周りの初期設定と、ネットワーク周りの設定を行っていきます。 最終的に以下のような構成を目指します。 サーバーにテストサイトを作って、外部から接続できるようにします。 注意事項 検証用途のため、テストサイトのアクセスであるので、細かな手順やパラメータの説明は省略します。 本番環境での運用では、他のドキュメントなども参照し、セキュリティなども考慮した構成で、構築をご検討ください。 今回実施すること 東京リージョンにVPCを作成します。 VPCとは Virtual Private Cloud (VPC) は、AWS アカウント専用の仮想ネットワークです。VPC は、AWS クラウドの他の仮想ネットワークから論理的に切り離されており、VPC 内には、Amazon EC2 リソースなどの AWS リソースを起動できます。VPC の IP アドレス範囲を指定して、サブネットを追加し、セキュリティグループを関連付けて、ルートテーブルを設定できます。 ・東京の一角に、家を作るイメージ ・パブリックサブネット・プライベートサブネットを使い分けることができる。 ・サブネット単位で内部〜外部、外部〜内部間でアクセス制御することができる。 構成図 動作環境 GoogleChrome 初期設定でおこなったこと ・IAMグループの作成 IAMユーザーを作成する前に、IAMグループを作成する。 グループを作成することで、権限管理を行いやすくする。 マネージドポリシーは、「AdministratorAccess」を選択した。 ※今回はテストサイトの作成用途だが、本番運用では、最低限の権限を付与する ・IAMで管理用アカウントを作成 ルートアカウント（クレジットカード情報を登録した開設時のアカウント）以外に、 ログインできるアカウントを作成する。 ・ルートアカウント、管理者アカウントにMFA（２段階認証）を設定 もしメールアドレスとパスワードが第三者に把握されても、ログインできないようにするため、多要素認証を有効化する TIPS：MFA認証が有効にされたかを確認する方法 実際にログインする以外で、IAMのコンソールから確認方法 ・「アクセス管理」＞「ユーザー」から一覧画面より確認 ・「アクセスレポート」＞「認証情報レポート」から、CSVファイルをダウンロード ・予想請求額をモニタリングする請求アラームの設定 AWSの予想請求額が閾値を超えた場合、メールで通知をしてくれるサービス。 予想請求額のモニタリングを有効化した後、CloudWatchを使用して請求アラームを作成することで実装が可能。 ※ここから先は料金が発生します。 ・CloudTrailの有効化 CloudTrailは操作ログを取得するサービスです。 有効化しておくことで、いつ、どのアカウントが、どのような操作を行ったかを確認することができる。 操作ログをS3に保管することができる。 ・GuardDutyの有効化 AWSアカウント、リソースに対する不審アクティビティを検知するために使用する。 実践 東京リージョンにVPCを作成する ・AWSにログインします。 初回ログインの場合は、右上のドロップダウンメニューから東京リージョンを変更する ・現在の状況 ・左上のメニューに「VPC」と入力し、「VPC」に移動します。 ・一覧で「VPC」をクリックし、「VPCの作成」をクリックします。 ・VPCを作成画面に値を入力します。 項目 入力内容 名前タグ test-website-vpc IPv4 CIDR ブロック 10.0.0.0/16 IPv4 CIDR ブロック ・/16〜/28のCIDRの範囲で入力 ・割り当てられるプライベートIPアドレスの範囲で入力 プライベートIPアドレスの範囲 10.0.0.0 - 10.255.255.255 (10/8 プレフィックス) 172.16.0.0 - 172.31.255.255 (172.16/12 プレフィックス) 192.168.0.0 - 192.168.255.255 (192.168/16 プレフィックス) ※CIDRの範囲は、今回はテストサイトでの利用のため何でも構いませんが、 本番環境では、他の業務システムに割り当てた、IPの範囲とは重複しないようにすることをおすすめします。 ・「VPCを作成」を押して、保存します。 ・現在の状況 以上でVPC作成は完了です。 参照URL ・AWS初学者を導く体系的な動画学習 AWS CloudTech - 株式会社Kurokawa Web Services ・AWSアカウントを作成したら最初にやるべきこと -セキュリティ編- - Qiita ・AWS アカウントのルートユーザー - AWS公式サイト ・IAM でのセキュリティのベストプラクティス　- AWS公式サイト ・AWS の予想請求額をモニタリングする請求アラームの作成　- AWS公式サイト ・IAMユーザーのMFA（多要素認証）は有効になっていますか？現状を確認→是正→適切な状態を維持するまでの流れを整理してみた - クラスメソッド株式会社 ・[初心者向け]VPC作成からEC2インスタンス起動までを構成図見ながらやってみる（その1） - クラスメソッド株式会社

RDSとは AWSで使える高機能なリレーショナルデータベースです。 EC2にデータベースの高度な機能がついたもので、基本的にリレーショナルデータベースはRDSがおすすめです。 EC2自体にデータベースを構築することも可能ですが、RDSを使うことで、より簡単に高機能なデータベースを使うことができます。 RDSで使えるデータベース データベース一覧 MySQL Oracle DB SQL Server PostgreSQL MariaDB Amazon Aurora RDSの機能 リードレプリカ リードレプリカとはレプリケーション（同じデータを複数作成）された読み込み専用のデータベースのことです。 同じデータが複数存在するためデータの安全性が高まるほか、データベースひとつにかかる負荷を分散させることができます。 自動スナップショット スナップショットとは差分式のバックアップのことで、RDSではスナップショットでバックアップを自動で取得してくれます。 自動パッチ パッチとはプログラムの機能追加などのバージョンアップのことです。 RDSは、データベースを強化するソフトウェアのパッチ適用などの作業が自動化されます。 これによりバージョンアップを手動で行わなくても自動でやってくれます。 暗号化 暗号化をすることが可能です。 暗号化することによりRDSのデータを安全に保管することができます。

緊急事態宣言で暇を持て余していた2021年のGWに、AWSからナイスな機能がリリースされました。 その名も「CloudFront Functions」。CloudFrontでクライアントからのアクセス時にJavaScriptで書かれた処理をかますことができる機能です。 今回は、このCloudFront Functionsを使って、SPA特有の「すべてのアクセスをindex.htmlに向ける」処理を書いてみましたのでご紹介します。 CloudFront Functionsとは？ https://aws.amazon.com/jp/about-aws/whats-new/2021/05/cloudfront-functions/ https://aws.amazon.com/jp/blogs/aws/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale/ 詳しくは以上のAWS公式サイトをご覧いただければと思いますが、要約すると「CloudFrontがリクエストをOriginに転送する前に、1ms以下の実行時間の比較的軽い処理を挟むことができる」という機能です。 同じような機能としてすでにLambda@Edgeが存在しますが、こちらはより軽量版といったところでしょうか。 実行時間が最大1msとかなり厳しく、できる処理はURL・ヘッダーの書き換えだったりとか、リダイレクトとかに限られますが、その代わり高速にレスポンスが返せます。 料金は、100万リクエスト当たり$0.10とのことです。Lambda@Edgeよりも安いですね。 index.htmlへのルーティングをCloudFront Functionsで実装してみる React/Vue/Angular等で作られたシングルページアプリケーション（SPA）は、ルーティングの処理をブラウザで実行されるJSで行うため、サーバー側でルーティングを行う必要がありません。すべての（静的ファイルへのリクエストを除く）リクエストは、index.htmlに向けられる必要があります。でないと、/hogeのようなサブページへのルーティングが404になってしまいます。 下準備 まず、/hogeというサブページを持つAngularアプリケーションを用意しました。 私がAngularの使い手というだけなので、これはVueでもReactでも何でもいいと思います。 用意したSPAアプリケーションを、CloudFront+S3の形でアップロードして公開します。 ここまでで、<ドメイン>/直下、つまりTOPページは正しく表示されます。 しかし、アドレスバーに直接<ドメイン>/hogeと入れて、サブページを表示しようとすると、Access Deniedのエラーが返ってきます。 これは、S3がhogeという名前のファイルを返そうとしているためです。そのようなファイル実体は存在しないので、S3は404を返し、こちらに書かれているようにCloudFrontは403を返します。 なので、/hogeのようなファイル実体が存在しないパスにルーティングしようとした際は、JSでルーティング処理を行わせるために、index.htmlを返す必要があるというわけです。 ということで、ここでCloudFront Functionsの出番です。 CloudFront Functionsの設定 CloudFrontの左側メニューの中に「Functions」が追加されていますので、クリックします。 「Create Function」をクリックします。 適切な名称を入力します。 手順としては4段階、ステージは2つに分かれています。 まず「Build」。コードを書いて保存すると、「Development」ステージに反映されます。この段階では本番反映ではありません。 var indexPage = "index.html" function handler(event) { console.log(event); var request = event.request; var currentUri = request.uri; var doReplace = request.method === "GET" && currentUri.indexOf(".") === -1; if(doReplace) { var indexPath = `/${indexPage}`; request.uri = indexPath; } return request; } 以上のコードを入力して「Save」してください。 やっていることは、リクエストメソッドがGETかつ、URIにドットが入っていない（＝拡張子がない）場合、index.htmlを返すように変更するというものです。 console.log()を含めていますが、ここで取れたログはus-east1リージョンのCloudWatch Logsに保存されます。 何やら懐かしいスタイルのJSコードを書いていますが、今のところES5相当の文法にしか対応していないようです。なんでやねん。 次に「Test」フェーズで、保存されたコードをテストできます。 今回は「Viewer Request」のフェーズで処理を挟みますので、「Event Type」をそのように選択します。 HTTPメソッド、URI、クエリパラメータ、リクエストヘッダー、Cookie、クライアントIPなどを変更できるようです。 「Compute utilization」という値は、最大実行時間の1msを100とした時の、実際の実行時間の値だそうです。最大でも70～80ぐらいに抑えておいたほうがよさそう。 このように、InputのURIに/hogeを入力して、OutputのURIが/index.htmlになっていればOKです。 次に「Publish」をして、この段階で「Live」ステージにもコードがデプロイされます。 最後に「Associate」で、このFunctionを紐づけたいCloudFrontディストリビューションを設定します。 先ほども書いたように、「Viewer Request」のフェーズで処理を挟むので、「Event Type」は「Viewer Request」を選んでください。 ディストリビューションの選択時、自動補完が出てきますが、ディストリビューションIDしか出てこないので、事前に紐づけたいディストリビューションのIDをメモっておいたほうがいいです。 設定が完了すると、/hogeをアドレスバーに直入力しても、正常にサブページが表示されるようになります。 CloudFront Functionsで出来ないこと CloudFront Functionsは、Lambda@Edgeで出来ることをもっとそぎ落として軽量高速化した機能であるため、今のところ以下のようなことはできません。 コード内で別のAWSリソースへのアクセスはできない 最大実行時間が1msを超えるような重い処理はできない 「Origin Request」「Origin Response」イベントタイプの処理はできない このような処理を行いたい場合は、Lambda@Edgeを採用するとよいでしょう。 まとめ 従来、SPAのindex.htmlへのルーティング処理をCloudFrontで行う場合、「Custom Error Response」でオリジンが403を返した時に、ドメイン直下（index.html）を返すように設定するというような、若干ハッキーな手法が多く用いられてきました。その後、Lambda@Edgeが出てきて一応解消できるようにはなりましたが、デプロイまでが結構複雑なので二の足を踏んでいた方も多いと思います。今回のCloudFront Functionsの登場で、よりシンプルに同様の処理を実装できるようになりました。ありがとうAWSさん。

AWS CloudWatch Logsのメトリクスフィルターの基本操作 ANDパターンマッチング スペース区切りでキーワードを入力する。 ちなみに、大文字小文字の区別があるので両方フィルタリングしたい場合は、大文字小文字表記を両方のせる。 ex) フィルター： ERROR request フィルタリング結果： [ERROR] Unable to continue: Failed to process the request ORパターンマッチング スペース区切りでキーワードの頭に?を入力する。 ex) フィルター： ?ERROR ?WARN ?message フィルタリング結果： [ERROR] Unable to continue: Failed to process the request [WARN] Failed to process the request NOTパターンマッチング スペース区切りでキーワードの頭に-を入力する。 ex) フィルター： ERROR -WARN フィルタリング結果： [ERROR] Unable to continue: Failed to process the request ⇒しかし、JSON形式のlogなどでの複雑なパターンはこの組み合わせでは表現できない。 複雑な条件の設定方法 [( a="*error*" || a="*fail*" ) && ( a!="*hoge*" && a!="*fuga*" )] のような形で複雑なフィルタパターンを表現できる。 JSON形式の場合は、$.{変数名} = "Content" のような形にすることで、要素ごとのフィルタリングも可能。

プログラミング勉強日記 2021年5月5日 VPC外部接続 　VPCの外側にあるEC2などの各種サービスとの通信には、パブリックのAWSネットワークとエンドポイントを利用する2つの方法がある。 　インターネットの経路を設定する方法としては、ルートテーブルとCIDRアドレスでルーティングを設定する。ルートテーブルでパケットの行き先を設定し、VPC内はCIDRアドレスでルーティングする。(VPC作成時にはデフォルトで1つルートテーブルが作成される) VPCの設計ポイント 設計時には今後の拡張も考えたアドレッシングや他のネットワークの接続性を考える CIDR(IPアドレス)は既存のVPCなどと被らないアドレスを考慮し、システム構成の将来像も考えながら計画する VPC構成は業務に合わせたVPC単体ではなくVPC全体の関係性も考える 複数のAZを利用して可用性の高いシステムを構築する サブネットは大きいサブネットを使って、パブリック・プライベートサブネットへのリソースの配置をインターネット悪エス可否から検討する セキュリティグループを使ってリソース間のトラフィックを制御する 実装や運用を補助するツールも利用する(VPC Flow Logsなど)

はじめに わけあってビデオチャットを作る方法を調べてみようと思ったので、今回はAmazon Chime SDKを使って見ることにしました。 Amazon Chimeとは Amazon ChimeはAmazonが提供するビデオチャットのサービスです。AWSのセミナーなどでたまに使われているのを見ますね（そらそうか）。このAmazon Chimeそのものは単なるビデオチャットチャットのアプリケーションであるのですが、Amazon Chime SDKを使うとAmazon Chimeの機能を盛り込んだアプリを作ることができます。 このSDKは、Android、iOS、JavaScriptそれぞれが公開されています。今回は、Androidで作成するのでAndroid向けのSDKを使用します。このSDKを用いることで、WebRTCなどの通信周りのことを意識せずにビデオチャットアプリケーションを実装することができます。基本的に今回の実装は公式のデモアプリをベースに行っています。 サーバーの構築 まずはサーバーを構築します。ここで構築するサーバーの役割は、WebRTCとは別で主にはルームの作成・削除や参加者の登録・解除などの管理を行うためのシステムを実装します。 構築したのは↑のようなサーバーです。ソースコードはこちらで公開しています。公式のサンプルから、ルームの作成と削除を行うAPIを実装したものをaws-cdkを使って構築してみました。joinというlambdaでルームの作成を行って、leaveというlambdaでルームの削除を行っています。このAPIを使って以下の２つの情報を登録します。 title:ルームのID name:参加者名 アプリについて ソースコードはこちらです。ビデオチャットアプリをゼロから実装することは大変だったので、公式のデモアプリを参考に実装しました。しかし公式のデモアプリはかなり多くの機能が盛り込まれていたので、簡単のためにビデオチャットだけの機能を実装したものを作成しました。アプリの外観は↓のような感じです。 SDKの導入方法は公式にある手順を参考にしてください。ちなみに構築したサーバーのURLはamazon-chime-sdk-android/app/src/main/res/valuesにあるstrings.xmlのtest_urlに書き込めば大丈夫です。 さいごに とりあえず短い内容でしたが、GWの期間でAmazon ChimeをAndroidでやってみたという内容でした。

前提知識 EC2とは？ AWSが提供している仮想サーバーを作成できるサービス。 Amazon Elastic Compute Cloudの略でAmazon EC2やEC2と呼ばれる。 このサービスで作成された各サーバーの事をインスタンスと呼ぶ SSHとは？ Secure Shellの略で、安全にリモートコンピューターと通信するためのプロトコルをいいます。 通信全てが暗号化されています。 読み解くコマンド $ ssh -i XXX.pem ec2-user@XXX.XXX.XXX.XXX 発生したエラー Warning: Identity file XXX.pem not accessible: No such file or directory. ec2-user@XXX.XXX.XXX.XXX: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). 解読 まず何をしようといているかですが、「AWSサービスの一つEC2で作成したインスタンスにアクセスする」という行為を行おうとしています。 そのためにSSHというプロトコルを使ってインスタンスにアクセスしようとしたがエラーを吐いているという状態です。 まず実行コマンドですが、-i XXX.pemは事前にインスタンス作成時に設定しダウンロードしたキーペアファイルを参照しています。 そしてec2-user@XXX.XXX.XXX.XXXはアクセスするユーザー名とアクセス先のIPアドレスです。 つまりコマンドとエラーを解読すると 「SSHという機能を使って、作成したEC2インスタンス（IPアドレス XXX.XXX.XXX.XXX）にpemの中にあるXXXという鍵を使ってアクセスします」としたが「現在のディレクトリにそんな名前のファイルはありません、だからec-2user〜のアクセスは拒否されました」といった感じになります。 解決 上記の通り、認証するための鍵がディレクトリにないのだから鍵を絶対パスで指定すれば通ります。 $ ssh -i ~/鍵ファイルのあるディレクトリ/XXX.pem ec-2uer@XXX.XXX.XXX.XXX

やること VPNのサブネットを作ったがまだインターネットに接続できるようにしていないので 接続できるようにする。 ルーティングとは 正しいルート（行先）を決めること。 通信において、通信相手までの経路を判断する仕組み。 インターネットではルーターがIPアドレスの行先を管理しているので、ネットワークとネットワークがIPアドレスを通じて接続することができる。 インターネットゲートウェイの作成 インターネットゲートウェイとは VPC内からインターネットに接続するためのゲートウェイです。 これを使うことで、VPC内のシステムがグローバルIPを使えるようになります。 VPCのページからインターネットゲートウェイをクリックします。 インターネットゲートウェイの作成をクリック。 インターネットゲートウェイの名前をつけます。 インターネットゲートウェイの作成をクリックします。 作成されました。しかしDetached接続されていないとなっています。 接続する作業をしていきます。 作ったインターネットゲートウェイを選択してアクションのVPCにアタッチをクリックします。 接続するVPCを選択します。 アタッチできました。 ルートテーブルを作成する ルートテーブルとは ネットワークの経路を設定するコンポーネントです。 サブネット内の通信がどの宛先のネットワークに対して、どのコンポーネント（IGWとかEC2とか）に転送されて欲しいかを設定します。 一つのサブネットに一つのルートテーブルを用意できますが、指定がない場合はVPC作成時に自動生成されるメインルートテーブルがサブネットに割り当てられます。 ルートテーブルをクリックします。 ルートテーブルの作成をクリックしましょう。 ルートテーブルの名前を入力。 VPCを選択します。 ルートテーブルが作成されました。 次にサブネットの関連付けをします。 サブネットの関連付けをクリックします。 サブネットの関連付けの編集をクリック。 パブリックサブネット用に作ったサブネットを選択します。 保存しましょう。 サブネットの関連付けができました。 デフォルトルートをインターネットゲートウェイに設定する ルートテーブルを選択し、下にあるルートを選択します ルートの編集をクリック ルートの追加をします。 送信先を入力します。今回は0.0.0.0/0に設定しました。 続いてターゲットを選択します。 InternetGatewayを選択してください。 するとGateWayが表示されるのでクリックします。 保存しましょう。 これでパプリックサブネットからインターネットに接続することができるようになりました。 参考サイト ルートテーブルシナリオの実際の構築手順（AWSの設定編） 図解/AWS】VPC入門～構成や設計,ルートテーブルの考え方,AZ配置やロードバランサ〜 【ネットワーク】 脱・知ってるつもり！AWSのネットワーク関連用語を基礎からおさらい

目次 1.はじめに 2.筆者のスペック 3.学習期間と本番スコア 4.使用教材 5.各期間での学習内容 6.まとめ 1. はじめに はじめまして、某都内ITコンサルに勤務する2年目のエンジニアです。 今年の3月にAWS SAPの取得に成功したので、本記事ではその勉強法と意識の持ち方について書きたいと思います。 取得の目的としては仕事でAWSなどのクラウドを扱うことが多く、AWSを通してクラウド全般の知識を体系的に整理することでした。同じような状況にある方の参考になればと思い、本記事を投稿いたします。 2. 筆者のスペック 保有資格 AWS SAA/SOA 基本・応用情報技術者 大学では応用数学を専攻 競技プログラミングはほとんどしていない 学習開始時の開発経験は2年ほど インターンにて1年、入社後に1年ほど AWS経験は半年ほど (使用経験のあったリソースは以下の通り) EC2/S3/Lambda API Gateway CloudWatch Logs/Events StepFunctions etc. 3. 学習期間と本番スコア 学習期間 1月末から勉強を開始したので、期間としては2ヶ月ほど。 SOAの勉強と併せて行ったので、SAP自体の対策期間としてはもう少し短いです。 各期間での学習内容は後ほど詳述します。 本番スコア 883/1000 (合格ライン750点) でした。 一回目の受験で合格することができました。 （復習すべき箇所が明確です...） 4. 使用教材 Ultimate AWS Certified Solutions Architect Professional 2021 (Udemy) AWSの薄い本　IAMのマニアックな話 AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー AWS WEB 問題集で学習しよう その他、公式ドキュメントやClassmethod社の記事などにも大変お世話になりました。 また、私は利用していませんが、AWSの公式模試 や Udemyの模試 (日本語版) / (英語版)、AWS Black Belt なども有用だと聞いています。 以下、各使用教材についてのレビューです。 Ultimate AWS Certified Solutions Architect Professional 2021 基本的に知識の補充にはこちらを使用しました。 講義で使用したスライドを配布してくれている (動画購入者限定) ので、それをiPadで表示してメモしていました。 特に、AssumeRoleやCognitoなどの処理手順の図は重宝しました。 また、講義自体は英語なのですが、重要なことは基本的にスライドに書かれているので、まずスライドの内容を大雑把に把握してから講義に臨むと理解が容易になると思います。 ただし、本講義はハンズオンではないので注意が必要です。Kinesis などのチュートリアルを行いたい方は AWS Certified DevOps Engineer Professional 2021 - Hands On! などから掻い摘むことをおすすめします。 (Stephane Maarek氏のステマみたいになってますね笑) AWSの薄い本　IAMのマニアックな話 佐々木拓郎氏による、IAMのみにフォーカスした書籍です。 マニアックと謳っていますが基本的な内容が多く、IAMに関する体系的な理解を促す書籍だと思います。 もちろん、スイッチロールやIAMポリシーのハイブリッドパターンなど、少々突っ込んだ内容にも触れられていますが、ポリシーの各条件などは書かれていません。したがって、この本で体系的に理解をして公式ドキュメントで網羅するといった位置づけと考えていただければと思います。 値段もお手頃でサクッと読めるので、SAPを受験されない方にもおすすめの書籍です。 AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー 佐々木拓郎氏による薄い本第二弾です。 こちらではAWSでのセキュリティに関するサービスについて、手広く扱っています。 仕事ではセキュリティまわりのリソースをあまり扱わせてもらえず、Config Rules や Shield Advanced など高価なサービスも多く (どれが高価なサービスかわからず) 個人的利用もしづらいので、この本にはかなり助けられました。 この本を読む前は予防と検知のサービスが分離していることすら認識していませんでしたが、そういった基本的な知識もこの本により補充できた感じます。 AWS WEB 問題集で学習しよう 個人的に問題演習はこのサイトのみで十分だったと感じます。 問題を解き、解説を読んで知識を補充していくことを繰り返しました。 個人的にまとめを作ることに時間を割きすぎるのは得策ではないと感じているので、演習で得られた知識はメモ程度で済ませて頭の中で整理することを心がけていました。特に社会人になると学生のときほど学習に時間を充てられないので、取捨選択が肝になってくると思います。 一方で、手を動かして経験を積むことには時間を割いた方が良いと感じます。問題を解いて特に理解できてないと感じる部分 (筆者の場合は Kinesis や Route53 など) については、会社の学習用ユーザーを利用してリソースを触るようにしていました。 ただし、それも理想論に過ぎません。どうしてもサービスを触る時間がない場合は、以下のようにマネージメントコンソールのスクショを撮って、どういう設定が可能かだけを押さえるのも一つの手だと思います。ご自身のプラン・時間と相談して取捨選択をしていただければと思います。 5. 各期間での学習内容 1月下旬～2月初旬 先述のUdemy教材で学習を開始しました。 すでにSAAを取得していたため、下準備なしで大丈夫だろうと高を括っていましたが、IAMまわりでいきなり躓くことに。 (個人的にSAAとSAPではセキュリティまわりの難易度にかなり差があるように感じました。) そこで、Udemy教材による学習を一旦中断し、上記のAWSの薄い本2冊を用いてセキュリティまわりの知識の補充を優先しました。これらの書籍のおかげでセキュリティまわりの理解がかなり進みました。 2月中旬～3月初旬 Udemy教材での学習を継続し、演習サイトを利用してAWS SOAの演習を行っていました。 Udemyの講義を受ける際は スライドで粗方内容を把握 → 講義のメモをスライドに書き込む を繰り返しました。 SOAの演習はSAPの演習を行う前の基礎固めとして有用でした。筆者の場合、SAAを取得してから半年ほど時間が経っていたので、SAAレベルの知識の復習がてらにSOAの勉強をしました。 3月の初めに試験慣れ・会場慣れの意図も込みでSOAを受験し、取得しました。 3月中旬～下旬 先述の演習サイトを利用して、SAPの演習を進めました。(SAPの全問題を2回ずつ解きました。) 演習を通して得られた知識も先述のスライドに書き込むようにしていたことで、スキマ時間での復習に役立つのはもちろんのこと、仕事でAWSリソースを扱う際にも有用でした。 また、理解が不十分だと感じるサービスについては、会社の学習用ユーザーを活用して経験を積んでいきました。 ただし、Route53 など一部のサービスは触るのに時間を要してしまうので、時間がない場合は理論的学習のみにとどめてしまうのも手だと思います。 試験前日・当日 試験前日と当日は脳を休める意味でも先述のスライドを使っての復習のみにとどめました。部分的に公式ドキュメントやクラスメソッド社の記事を利用し、知識をより強固なものにすることに集中しました。 また、このご時世ですが試験会場で受験しました。自宅受験も可能なようですが、クリアデスクが面倒なのと3時間トイレに行けない (らしい) という制約が嫌だったので、しぶしぶ試験会場に赴きました。 試験中での意識についてですが、「基本的にはわからない問題はあって当たり前、さっさとフラグを立てて次の問題に進む」という心構えで臨みました。また、前半で集中力を大幅に消費してしまうことを回避すべく、問題文が長いものについてもフラグを立てて飛ばしました。(得意分野の問題に関しては飛ばさずに取り掛かるなどの選択をしても良かったなと思います) その結果、90分ほどで1周することができ、わからない問題や面倒な問題に時間と集中力を費やせたと感じます。 後日 試験の正誤が返ってこないので復習は少ししづらいですが、問題文を読んで曖昧だった箇所はスライドを見直しました。 また、現在 DVA/DOP の勉強を行っていますが、SAPのスライドに追加でメモできることは書き込むように心がけています。復習用リソースの統一は、学習に時間を割きづらい社会人にとって有効な手段になると考えています。(スキマ時間での学習の効果が高まります) 6. まとめ 方々から難しいと評される AWS SAP ですが、入社1年目からでもチャレンジ (勉強) する価値は十分あると思います。(受験費用が税込み33,000円と少々お高めなのがネック) 実践的知識ゆえに仕事のモチベーションも高まりますし、何より勉強したこと自体が自信・強みになると思います。 また、知識の獲得・定着方法は人それぞれです。自分にあった方法を模索してみてください。その際、本記事が参考になれば幸いです。 最後に、記事を読んでくださった方々のチャレンジ・合格をお祈り申し上げます。 お読みいただきありがとうございました！

AWS上で自作のテトリス風ゲームを動かした際の備忘録です。 https://github.com/seigot/tetris_game 前提条件 https://github.com/seigot/tetris_gameにアクセスできること AWSアカウントを登録していること EC2を起動していることこと 　（今回は無料枠、ubuntu18.04 server, CPU 1G, メモリ1GB, ストレージ20GBの環境を利用） 起動したEC2にアクセスするための鍵ペアを作成して、秘密鍵をローカルに保存する。（パスは~/.ssh/privatekey） 以降は起動済のEC2がある状態の手順を残す。 起動後にSSH経由でログイン 手元のPCから以下を実行してログインする。 ssh -i ~/.ssh/privatekey ubuntu@xxx.xxx.xxx.xxx #xxx.xxx.xxx.xxxはパブリックipv4アドレス パブリックipv4アドレスはAWSのサイトから以下の通り確認できる。 EC2ダッシュボード -> インスタンス -> 起動しているインスタンス選択し、パブリックipv4アドレスを確認 VNC経由でログイン Desktop環境をインストールする sudo apt install -y ubuntu-desktop xterm x11vnc ifupdownをPurgeする sudo apt purge ifupdown Display manager を lightdm に変更 sudo apt install lightdm 念のためpasswordを設定しておく sudo passwd ubuntu 以下を参考にVNCクライアントからx11vncを接続する https://mixture.dcmnjp.net/linux/ubuntu/x11vnc.html VNC経由でアプリをお試し実行 自作のテトリスをお試し実行する https://github.com/seigot/tetris_game 必要なものをインストール 実行環境(Ubuntuの場合) Need python3, PyQt5 and NumPy to be installed. install pyqt5 and NumPy sudo apt-get install -y python3-pip sudo apt-get install -y python3-pyqt5 pip3 install --upgrade pip pip3 install numpy その他、パッケージのインストール sudo apt-get install -y git 実行 cd ~ git clone https://github.com/seigot/tetris_game cd tetris_game bash start.sh 動いた。でも無料枠(CPU 1G, メモリ1GB, ストレージ20GB)での利用のためか、かなりもっさりします。 MacからEC2にvncが繋がらない 以下の方法だと繋がった。 https://biomodeling.co.jp/2020/04/30/ubuntu18にリモートデスクトップ接続する手順/ ただし毎回以下の設定が要る。 # 5901ポートフォワード ssh -i ~/.ssh/privatekey ubuntu@xxx.xxx.xxx.xxx -L 5901:localhost:5901 # vnc serverの設定 vncserver :1 kswapdが重い swap領域を追加して一旦落ち着いた kswapが頻発してシステムが重い 参考 https://github.com/seigot/tetris_game https://biomodeling.co.jp/2020/04/30/ubuntu18にリモートデスクトップ接続する手順/ kswapが頻発してシステムが重い https://mixture.dcmnjp.net/linux/ubuntu/x11vnc.html

はじめに 流石にそろそろAWSコンソールではなく、aws-cliを使おうと思った時、dockerでやりたいと思い調べたら2020年にaws cliのdockerイメージが公開されていました。 公式にも日本語化されたインストール手順の対象にdockerがありましたので、試してみたところ、 少しつまずいたので記事にしました。 AWS CLIインストール ユーザガイド（Docker） つまずいた手順 まず、つまずいた手順をそのまま記載します。 こちらに従って、進めていきます。 AWS CLIインストール ユーザガイド（Docker） $ docker run --rm -it amazon/aws-cli --version // imageがない場合は、pullされます aws-cli/2.2.2 Python/3.8.8 Linux/4.19.121-linuxkit docker/x86_64.amzn.2 prompt/off aliasの設定 docker imageを使う場合、docker run --rm -it amazon/aws-cliがawsとイコールになります。 長いのでエイリアスを設定することでdockerを意識せずに使えるようになります。 $ alias aws='docker run --rm -it amazon/aws-cli' // エイリアス設定前 $ aws --version -bash: aws: command not found // エイリアス設定後 $ aws --version aws-cli/2.2.2 Python/3.8.8 Linux/4.19.121-linuxkit docker/x86_64.amzn.2 prompt/off なお、時が経った時、macにawscliをインストールしたと勘違いする可能性があるため、実際にはawsから少し変えています。以後記事内ではこちらを使っていきます。 実際の設定 $ alias dockeraws='docker run --rm -it amazon/aws-cli' 認証情報の設定（つまずいた部分✳︎） ここからアクセスキーとシークレットアクセスキーを取得（ない場合、忘れた場合は新規作成）し、AWSアカウントとの紐付けを行います。 https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-quickstart.html //aws configreの実行 $ dockeraws configure AWS Access Key ID [None]: AKXXXXXXXXXXXXXXXXX AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Default region name [None]: ap-northeast-1 Default output format [None]: *この記事の通りに設定している方はいないと思いますが、この手順は意味がないので不要です。後述を参照してください。 何が起こったか Amazon Kinesis DataStreamsのストリームを作成しようとしました。 あまり本筋とは関係ないですが、こちらを参考にして作ろうとしていました。 https://docs.aws.amazon.com/ja_jp/streams/latest/dev/fundamental-stream.html ストリーム名は、my-sample、初期シャード数は1とします。 $ dockeraws kinesis create-stream --stream-name my-sample --shard-count 1 You must specify a region. You can also configure your region by running "aws configure". なるほど・・・？ aws configureでリージョン指定していたが？と思いつつ一旦エラー解消のため素直にregionを指定します。 $ dockeraws kinesis create-stream --stream-name my-sample --shard-count 1 --region ap-northeast-1 Unable to locate credentials. You can configure credentials by running "aws configure". 仕方ないので、調べてみたら前手順で設定したはずの情報が確かにない。 $ dockeraws configure list Name Value Type Location ---- ----- ---- -------- profile <not set> None None access_key <not set> None None secret_key <not set> None None region <not set> None None 原因 よく考えれば当たり前なのですが、コンテナを常時起動しているわけではなくイメージを都度立ち上げているので、前手順の作業はその瞬間立ち上がっていたコンテナに設定されてすぐ破棄されています。 以下２行はそれぞれ別のコンテナに対して行われているので、当然前者のconfigureで入力した内容が後者のコマンド実行時に反映されるわけがありません。 $ dockeraws configure //コンテナ１ $ dockeraws configure list // コンテナ２ AWSもaws-cliとdockerをあえて使おうとしている人間が、まさかこんな当たり前すぎることでつまずくとは思わなかったでしょう。 このことは特に公式の手順にはなかったのですが、以下の記述があったことを思い出す。 私はaws-cliを利用するのが初めてだったのでホスト側にawsの認証情報は存在していませんでした。 ですのでマウントする対象のファイルはなく、今から設定すれば良いという考えて飛ばしていました。 解消手順 自身のmacにaws-cliをインストールしたこともする予定もありませんが、コンテナのライフサイクル上、configureにより作成される認証ファイルはコンテナ実行都度読み込ませる必要があります。 読み込みされる対象のファイルを手でホスト側（自身のmac）に作っていきます。 （もし既にPCにaws-cliがインストールされている場合、aws configureを自分のPCコンソールで実行すればファイル作成されるのでこの手順は不要です） 1.マウントする場所を作る 私は、普段開発で使っているworkディレクトリ配下にdockeraws/.awsを作りました。 $ mkdir {任意の場所}/dockeraws $ mkdir {任意の場所}/dockeraws/.aws $ cd {任意の場所}/dockeraws/.aws 2.~/.aws/credentialsにマウントするファイル作成 ファイルの構成はこちらを参考にしました。 設定ファイルと認証情報ファイルの設定 $ vi credentials credentials [default] aws_access_key_id=XXXXXXXXXXXX aws_secret_access_key=XXXXXXXXXXXXXXXXXXXXXXXX 3.~/.aws/configにマウントするファイル作成 ファイルの構成はこちらを参考にしました。 設定ファイルと認証情報ファイルの設定 $ vi config config [default] region=ap-northeast-1 output=json 4.aliasに設定 この段階で、読み込まれるか動作確認します。 $ docker run --rm -it -v {任意の場所}/dockeraws/.aws:/root/.aws amazon/aws-cli configure list Name Value Type Location ---- ----- ---- -------- profile <not set> None None access_key ****************2DLO shared-credentials-file secret_key ****************Re2n shared-credentials-file region ap-northeast-1 config-file ~/.aws/config 問題なさそうです。 しかし、aliasはマウント設定をふくまないコマンドのままのため未だこの結果となります。 $ dockeraws configure list Name Value Type Location ---- ----- ---- -------- profile <not set> None None access_key <not set> None None secret_key <not set> None None region <not set> None None $ alias alias dockeraws='docker run --rm -it amazon/aws-cli' alias設定を変更します。 $ alias aws='docker run --rm -it -v {任意の場所}/dockeraws/.aws:/root/.aws amazon/aws-cli' こちらでも触れていますが、私はawsにしてしまうと勘違いする恐れがあるのでエイリアス名をdockerawsにしています。 実際の設定 $ alias dockeraws='docker run --rm -it -v /Users/yukokanai/work/aws/dockeraws/.aws:/root/.aws amazon/aws-cli' // 上記手順で上書きされますが、万が一aliasを消したい場合は、unalias {エイリアス名} $ unalias dockeraws 5.動作確認 先ほどは、Noneだった認証情報が表示されるようになりました。 $ dockeraws configure list Name Value Type Location ---- ----- ---- -------- profile <not set> None None access_key ****************2DLO shared-credentials-file secret_key ****************Re2n shared-credentials-file region ap-northeast-1 config-file ~/.aws/config 最後に、当初やりたかったコマンドを再実行します。 $ dockeraws kinesis create-stream --stream-name my-sample --shard-count 1 $ dockeraws kinesis list-streams { "StreamNames": [ "my-sample" ] } 当初はこのコマンド実行するごとにエラーが出たのでてっきりsuccessなど出るかと思ったのでレスポンス無で虚をつかれる。 きちんとストリームが作成されていることを確認しました。 おわりに つまずくところが初歩すぎてつらい。 あまりに初歩すぎてかさっと検索した限りでは見つけられませんでしたが、自己解決できてよかったです。 お疲れ様でした。

はじめに 前回の記事 では、Amazon SageMaker を使って異常検知のサンプルアーキテクチャをご紹介しました。 AWSにはSageMakerの他にも異常検知に便利なサービスがあるので、本記事にて代表的なものをいくつかご紹介いたします。 Amazon Monitron Amazon Monitron は、機械学習を使用して産業機械の異常な動作を検出し、予知保全によってダウンタイムを低減することを可能にすることができます。 産業機械にMonitronセンサーを取り付け 振動や熱を計測し、そのデータをクラウド上に転送して機械学習によって異常な動作を検知します。 ※2021/05/10時点で米国、英国、およびEUのみでデバイス購入可能、利用できるリージョンは米国東部 (バージニア北部) および欧州 （アイルランド）のみです。 Amazon Monitron に含まれるもの 振動と温度のデータを取得する Amazon Monitron センサー AWS にデータを安全に転送する Amazon Monitron ゲートウェイ 機械学習を使用して機械の異常パターンのデータを分析する Amazon Monitron サービス およびデバイスをセットアップし、機械の潜在的な障害を追跡するためのコンパニオンモバイルアプリ Amazon Lookout for Equipment Amazon Lookout for Equipment は、機器のセンサーで得られたデータを自動で分析して、機器の異常検知や予知保全を実現します。 リアルタイムでセンサーデータを分析して、機械障害につながる可能性のある早期警告の兆候を正確に特定します。 Amazon Lookout for Vision Amazon Lookout for Vision は、コンピュータービジョン を使用して視覚表現の欠陥や異常を発見する機械学習サービスです。 正常な製品と欠陥のある製品を示す画像をアップロードしてタグ付けをすることで、欠陥を検出するモデルを自動で作成することができます。 AWS IoT AWS IoT を使用すれば、機器の状態、正常性、性能を継続的にモニタリングおよび推測して、問題をリアルタイムで検知できます。 引用元：https://aws.amazon.com/jp/iot/solutions/industrial-iot/?c=i&sec=uc1 AWS IoT Analytics AWS IoT Analytics に事前に定義されているテンプレートを使用して、強力な予知保全モデルを簡単に構築し、フリートに適用できます。 例えば、AWS IoT Analytics を使用して、接続された貨物車で冷暖房装置が故障するタイミングを予測できるため、適切な補修を行って輸送上の損傷を防ぐことができます。 引用元：https://aws.amazon.com/jp/iot-analytics/?c=i&sec=srv AWS IoT Events AWS IoT Events は、複数の IoT センサーやアプリケーションのデータを継続的に監視し、AWS IoT Core や AWS IoT Analytics といった他のサービスと統合してイベントの早期検出と固有の分析を可能にします。 引用元：https://aws.amazon.com/jp/iot-events/?c=i&sec=srv AWS IoT Core AWS IoT Core を使用すれば、IoT デバイスを AWS クラウドに接続できます。 引用元：https://aws.amazon.com/jp/iot-core/ AWS Lambda、Amazon Kinesis、Amazon S3、Amazon SageMaker、などといった Amazon のサービスを簡単に使用して、接続されたデバイスで生成されたデータを収集、処理、分析し、そのデータに基づいてアクションを起こす IoT アプリケーションを構築できます。 まとめ このように、AWSには異常検知をする上でたくさんのサービスが用意されています。 やりたいことに合わせて使うサービスを検討することができるのも、AWSなどのクラウドサービスを使うメリットだと思いました。

はじめに AWS ソリューションライブラリーにて提供されている 機械学習を利用した予知保全 の実装をやってみます。 用意されているAWS CloudFormation テンプレートを使用するので簡単にデプロイできます。 Amazon SageMakerとは Amazon SageMaker は、機械学習モデルを短期間で簡単に構築、トレーニング、デプロイできるようにするフルマネージド型サービスです。 あらゆる作業を効率化する機能が提供されているため、人手をかけずに異常検知をやりたいときに最適なサービスです。 本記事のゴール 機械学習モデルとターボファンの劣化シミュレーションデータのサンプルデータセットをデプロイして、潜在的な設備故障を認識するようにモデルをトレーニングするというサンプルアーキテクチャを紹介します。 アーキテクチャ図は以下の通りです。 このアーキテクチャでは、サンプルデータセットを使って、 設備故障の評価対象としてRUL（残存耐用期間）を計算し、予測値と観測値を比較して異常検知します。 トレーニングデータとテストデータは、S3バケットに格納します。 これをAWS Lambda などを使って1日に1回スケジュール実行します。 実装手順 手順は大まかに以下の4つです。 スタックを起動する ML モデルをトレーニング CloudWatch Events ルールを有効にする Lambda 関数がデータを処理していることを確認する 1. スタックを起動する 機械学習を利用した予知保全 から CloudFormationテンプレートをダウンロードします。 テンプレートに含まれているもの： Amazon CloudWatch Events ルール AWS Lambda 関数 Amazon SageMaker ノートブックインスタンス Amazon S3 バケット AWS CloudFormationに移動 → 「スタックの作成」を選択します。 ダウンロードしたテンプレートをアップロード → 「次へ」を選択します。 スタックの名前を入力します。 S3バケットの名前を入力 → SageMaker ノートブックインスタンスをデプロイす る VPC Id、Subnet Id を選択 → 「次へ」で次に進みます。 オプションの設定はスキップします。 「次へ」を選択します。 設定を見直します。 テンプレートが AWS IAM リソースを作成することを確認するチェックボックスをオンにして → 「スタックの作成」を選択します。 CREATE_COMPLETE のステータスが表示されたら、デプロイが完了したということです。 5分ほどかかりました。 2. Amazon SageMaker でノートブックを実行する Amazon SageMaker では、任意の深層学習フレームワークを使用してカスタム深層学習モデルをトレーニングできます。 このソリューションでは、カスタムの Stack LSTM ニューラルネットワークを活用して、時系列データから履歴パターンを学習します。 Amazon SageMaker コンソールに移動 → 「SageMaker Studio」を選択します。 「ノートブックインスタンス」 → 「PredictiveMaintenceNotebookInstance」を選択します。 「Jupyterを開く」を選択します。 sagamaker_predictive_maintenance.ipynb のノートブックを開きます。 全てのセルを実行します。 3. CloudWatch Events ルールを有効にする 1日に1回実行するように設定されてます Amazon SageMaker バッチ変換ジョブを作成する AWS Lambda 関数をトリガーするように設定されており、AWS SageMaker バッチ変換ジョブはトレーニング済みモデルを使用してデータのサンプルから残存耐用年数を予測します。 AWS Lambda コンソールに移動 → 「関数」 → 「predivtive-maintenance-batch-transformer」を選択します。 「EventBridge(CloudWatch Events)」を選択します。 predictive-maintenance-ScheduledRule-を選択します。 「有効にする」を選択し、を有効にします。 「有効にする」を選択します。 4. Lambda 関数がデータを処理していることを確認する [モニタリング] を選択し、[Invocations] グラフにアクティビティが表示されているこを確認します。 テスト結果はS3バケットに格納されます。 画像のように、RUL（残存耐用年数）の列が追加されていることが確認できます。 さいごに 今回は、Amazon SageMakerを使って異常検知のアーキテクチャ実装を試してみました。 AWS CloudFormation テンプレートを使用することで、モデルのトレーニングからノートブックのスケジュール実行の設定まで数分で出来ました。 今回はサンプルデータを使用していますが、任意のデータセットを使用するようにソリューションを変更できることもできるようなので、次回はトライしてみたいです。 参考

AWSのデータ分析系のサービスを体系的に学ぶため、UdemyのAWS Certified Data Analytics Specialty 2021 - Hands onコースを受けました。 一般的なデータ分析流れに含まれるステップ、データ収集、データ保存、データ処理、データ分析、データ可視化に、それぞれが利用するサービスを学び、マインドマップに整理しました。 今回はデータ保存編のS３です。 ※ こちらの記事は、AWSのホワイトペーパー、クラウドサービス活用資料集とUdemyにあるAWS Certified Data Analytics Specialty 2021 - Hands onというコースを参照しております。

AWSのデータ分析系のサービスを体系的に学ぶため、UdemyのAWS Certified Data Analytics Specialty 2021 - Hands onコースを受けました。 一般的なデータ分析流れに含まれるステップ、データ収集、データ保存、データ処理、データ分析、データ可視化に、それぞれが利用するサービスを学び、マインドマップに整理しました。 今回はデータ保存編のS３です。 ※ こちらの記事は、AWSのホワイトペーパー、クラウドサービス活用資料集とUdemyにあるAWS Certified Data Analytics Specialty 2021 - Hands onというコースを参照しております。

AWSのデータ分析系のサービスを体系的に学ぶため、UdemyのAWS Certified Data Analytics Specialty 2021 - Hands onコースを受けました。 一般的なデータ分析流れに含まれるステップ、データ収集、データ保存、データ処理、データ分析、データ可視化に、それぞれが利用するサービスを学び、マインドマップに整理しました。 今回はデータ保存編のS３です。 ※ こちらの記事は、AWSのホワイトペーパー、クラウドサービス活用資料集とUdemyにあるAWS Certified Data Analytics Specialty 2021 - Hands onというコースを参照しております。

はじめに 先日からGCPを触っているが、その際にPrometheusからGCPの監視データを取得してくれるstackdriver_exporterを見つけた。 今回はこのstackdriver_exporterをAWS(EC2)上に構築してそこからGCPのデータを取得してみようと思う。 なお、大きく使う予定がないのでAWS-GCP間の連携にWorkload Identityは使用しない。 前提 GCP上のIAMで「閲覧者」のサービスアカウントとキーを作成しておくこと。 (github上では「roles/monitoring.viewer」でいいと書いてあるが動かなかったので) GCP設定ファイル設置 作成したキーファイルを配置して参照用の環境変数ファイルを設置しておく。 暫定で今回は/root/.gcp.jsonに設置した前提とする。 /root/gcpenv GOOGLE_APPLICATION_CREDENTIALS=/root/.gcp.json バイナリ取得 バイナリ取得 wget https://github.com/prometheus-community/stackdriver_exporter/releases/download/v0.11.0/stackdriver_exporter-0.11.0.linux-amd64.tar.gz tar -zxf stackdriver_exporter-0.11.0.linux-amd64.tar.gz mv stackdriver_exporter-0.11.0.linux-amd64/stackdriver_exporter /usr/local サービス化とコンフィグファイル作成 stackdriver_exporterはコマンド実行時に監視項目などOptionを指定する作りになっているのでこのままサービス化しても使いづらい。 他のPrometheus系のRPMのようにOptionを/etc/default/stackdriver_exporterから参照できるよう設定を少しいじっている。 ※併せてGOOGLE_APPLICATION_CREDENTIALSも参照設定も入れている。 サービス用コンフィグ /usr/lib/systemd/system/stackdriver_exporter.service [Unit] Description=stackdriver-exporter After=network.target [Service] EnvironmentFile=-/etc/default/stackdriver_exporter EnvironmentFile=/root/gcpenv Type=simple User=root ExecStart=/usr/local/stackdriver_exporter $STACKDRIVER_EXPORTER_OPTS [Install] WantedBy=multi-user.target stackdriver_exporterコンフィグ ここにコマンドオプションを切り出しているので監視項目を変更する際はここを変更する。 この例ではGCPインスタンスcpu,memory,disk,network全てを取得する設定としている。 /etc/default/stackdriver_exporter STACKDRIVER_EXPORTER_OPTS='--monitoring.metrics-type-prefixes "compute.googleapis.com/instance/cpu,compute.googleapis.com/instance/disk,compute.googleapis.com/instance/memory,compute.googleapis.com/instance/network"' サービス登録&起動 サービス登録&起動 systemctl enable stackdriver_exporter systemctl start stackdriver_exporter Prometheus設定追加 prometheusに参照設定を入れてreloadする。 /etc/prometheus/prometheus.yml - job_name: stackdriver-exporter static_configs: - targets: ['localhost:9255'] 以下のような感じでGCPのインスタンスの情報が取得できる。 あとがき クラウドサービスはそれぞれで監視機能を持っているのでマルチクラウドなところだと各環境毎に監視サーバを持ってしまっているケースってよくみる。 それ自体は悪いことではないのだけどやっぱり本末転倒な気がするので、今回新たに専用のインスタンスを増やさずGCPを監視させる形を作れたのはよかった。 なんかできそうな感じがするので次回はこれまで作ってきたprometheusをGCPに複製してAWS-GCP間で冗長化する、という記事を書こうかと思っている。 なお、なんでもかんでもAWS・Prometheus前提になっているが私はそのあたりからの回し者ではない。全然別の記事も書きたい。

はじめに こんにちはrattsl(@rattsl)です。 今回はAWS IAMについてハンズオンで色々いじったのでメモとして残します。 間違って認識しているところがあったらご指摘ください。 やっていくこと IAMの仕組み理解 IAM設計 IAMグループへのポリシー適応 IAMロールへのポリシー適応 IAMロールの権限移譲 IAMアクセスアナライザの設定 AWS Organizationsの設定 IAMとは IAMとはユーザの権限を設定してAWSリソースへのアクセスを制限する仕組み。個人にポリシーをアタッチ、またグループにポリシーをアタッチすることで実現する。 IAMの種類 利用者は権限を付与されたIAMエンティティ（ユーザ、グループ、ロール）として設定される。 ユーザー 詳細 ルートユーザー アカウント生成時に付与されるユーザー IAMユーザー 管理者権限の許可がおりたユーザー パワーユーザー(IAMユーザー) IAM以外の全てのサービスにフルアクセスできるユーザー ルートユーザで日常的なタスクはせず、管理者権限を付与されたIAMユーザで操作することが推奨されているが、ルートユーザにしかできない設定もあるので随時切り替えて管理する。 IAMロールとは AWSリソース（エンティティ）に対してポリシーをアタッチすること。 ex）EC2からS3にのみアクセスを許可する 狭義にはサービスだけではなくユーザに対してや別のSNSアカウントに一時的に権限を付与する役割も持つ。 IAMロールの信頼ポリシーとしてIAMロールは監査人などに一時的な権限を委譲する際も利用する。 IAM設計 IAM設計する際はAWSを利用するユーザの役割や会社のセキュリティポリシーと兼ね合わせて設計する必要がある。新しいIAMユーザを登録する際は必要最低限のパーミッションを付与する。 数人程度のAWS利用を今後続けていくようだったらIAMユーザーを個々で設定していくのでもいいが今後人数が増えていくことを想定しているケースだったら初めからグループで設定していく方が運用が楽になる。 IAMアクセスアナライザーの設定 AWSリソースへのアクセスをモニタリングするサービス。 AWS Organizations AWS Organizationsとは複数のアカウント自体を管理するサービス。 IAMとの違いはアカウント内のユーザーを管理するのに対してOrganizatiopnsはアカウント自体を管理するためレイヤーが違う。 管理者ルートにマスターアカウントを設定し、既存のアカウントをメンバーアカウントとして組織内に追加するという流れ。 組織単位でOUを設定し管理することも可能。 Organizationsのサービスコントロールポリシー（SCP）でリソースの境界を決める。 Access Adviser IAMエンティティが最後にAWSサービスにアクセスした日付と時刻を表示する機能を有する。 インラインポリシーとは 自身で作成、及び管理できるポリシーのこと。1つのプリンシパルエンティティ（グループ、ユーザ、ロール）にアタッチすることが可能。 EC2インスタンスへのIAMロールのアタッチ方法 EC2マネジメントコンソールからアクション操作でアタッチする。 パワーユーザーのアクセス権限について パワーユーザーはIAMユーザーやグループ管理以外のAWSリソースへのフルアクセス権限を持っている。 ユーザー管理以外できるとイメージする。 IAMユーザーのデフォルト設定 IAMユーザーが作られた時点ではそのユーザー自体はどのリソースにもアクセス権限を持っていない。

はじめに たまに（かつ、急に）舞い込んでくるデモ機会のために、過去に作った WEB サービスを動かしておきたいけど、動かしっぱなしにしておくと無駄なランニングコストがかかってしまいもったいない、というニッチな課題を解決してみます。 方針 「必要なときにだけ」「特別な手順無しで」WEB サービスを立ち上げる方法1を考えます。 課題解決の方針は以下の図の通りです。 ざっくり書き下すと・・・ デモしたい WEB サービスは ECS Fargate 上のコンテナで動かす。 WEB サービスへのリクエストを Application Load Balancer (ALB) で受けて、コンテナが起動済みならリクエストをそのまま転送、コンテナが停止済みならコンテナを新たに起動する。 ALB のリスナールールに以下2つのターゲットを登録 target-1: コンテナにリクエストを転送 target-2: コンテナを起動するための Lambda 関数（sample-service-start）をコール コンテナの状態に応じてターゲットの重みを変更し、選択されるターゲットを制御 コンテナ起動済み → target-1 を選択（target-1 の重み = 1, target-2 の重み = 0） コンテナ停止済み → target-2 を選択（target-1 の重み = 0, target-2 の重み = 1） WEB サービスへのリクエストが一定時間無ければコンテナを停止する。 CloudWatch Alarm で両ターゲットへのリクエストを監視 リクエストが一定時間無かった場合には、コンテナを停止するための Lambda 関数（sample-service-stop）をコール 実装のポイント 本記事では各サービスの具体的な設定については触れませんが、ポイントになる Lambda 関数2つと CloudWatch Alarm 周りの設定のみ、以下でまとめておきます。 前準備 まず前準備として、2つのターゲットグループ（コンテナにリクエストを転送するための target-1 と、起動用 Lambda 関数をコールするための target-2）を作成して、ALB のリスナールールに登録しておきます。これらの「重み」を、コンテナを起動・停止するための Lambda 関数で変更することで、コンテナの状態に応じて ALB で選択されるターゲットを制御できます。 コンテナの起動・停止と ALB リスナールールの設定変更を行うための Lambda 関数 Python3.8 で書くとそれぞれ以下のような感じです。 また、これらの関数の実行には、デフォルトで付与されるログ出力関連の権限に加えて、以下の権限も必要になるので、適宜ポリシーを設定します。 ecs:DescribeServices ecs:UpdateService elasticloadbalancing:Describe* elasticloadbalancing:ModifyRule 起動用 Lambda 関数（sample-service-start） 「コンテナの起動」と「コンテナにリクエストを転送するためのターゲットグループの重み変更」を行う関数です。 sample-service-start import boto3 from botocore.exceptions import ClientError def lambda_handler(event, context): response = { "statusCode": 200, "statusDescription": "200 OK", "isBase64Encoded": False, "headers": { "Content-Type": "application/json; charset=utf-8" } } try: # sample-serviceを起動 (ECSのタスク数に1を設定) client = boto3.client('ecs') cluster_name = 'mycluster' service_name = 'sample-service' ecs_response = client.update_service( cluster = cluster_name, service = service_name, desiredCount = 1 ) print(ecs_response) # ALBリスナールールを更新 client = boto3.client('elbv2') alb_response = client.modify_rule( RuleArn='ALBリスナールールのARN', Actions=[{ 'Type': 'forward', 'ForwardConfig': { 'TargetGroups': [ { 'TargetGroupArn': 'target-1のARN', 'Weight': 1 }, { 'TargetGroupArn': 'target-2のARN', 'Weight': 0 } ] } }] ) print(alb_response) response['body'] = '{"message":"sample-service starting..."}' except ClientError as e: print("error: %s" % e) response['body'] = '{"message":"sample-service start error"}' return response このサンプルでは200 OKと共に、JSON のメッセージを返却してますが、このあたりは使い方に応じて工夫できると思います。 停止用 Lambda 関数（sample-service-stop） 「コンテナの停止」と「起動用 Lambda 関数をコールするためのターゲットグループの重み変更」を行う関数です。 sample-service-stop import boto3 from botocore.exceptions import ClientError def lambda_handler(event, context): try: # sample-serviceを停止 (ECSのタスク数に0を設定) client = boto3.client('ecs') cluster_name = 'mycluster' service_name = 'sample-service' ecs_response = client.update_service( cluster = cluster_name, service = service_name, desiredCount = 0 ) print(ecs_response) # ALBリスナールールを更新 client = boto3.client('elbv2') alb_response = client.modify_rule( RuleArn='ALBリスナールールのARN', Actions=[{ 'Type': 'forward', 'ForwardConfig': { 'TargetGroups': [ { 'TargetGroupArn': 'target-1のARN', 'Weight': 0 }, { 'TargetGroupArn': 'target-2のARN', 'Weight': 1 } ] } }] ) print(alb_response) except ClientError as e: print("error: %s" % e) こちらは、次で説明する CloudWatch Alarm のイベントを受けてコールされる関数なので、レスポンスは返しません。 リクエストが一定時間無かった場合に停止用 Lambda 関数をコールするための CloudWatch Alarm target-1 と target-2 への RequestCount の合計（SUM）が 0 になったら発報するアラームを作成します。 アラームの発報は EventBridge で受け取ります2。EventBridge にルールを設定するために必要な、「ALARM」イベント受信用のイベントパターンは以下の通りです。 event_pattern { "source": ["aws.cloudwatch"], "detail-type": ["CloudWatch Alarm State Change"], "detail": { "state": { "value": ["ALARM"] } }, "resources": ["アラームのARN"] } CloudWatch Alarm → EventBridge → Lambda とつなぐことで、WEB サービスへのリクエストが一定時間無くなった時点でコンテナを停止できるようになります。 おわりに コンテナの起動に数十秒から数分かかってしまうため、本番運用している WEB サービスに適用するのは難しいですが、デモ用途であれば十分実用的です。CPU/GPU やメモリを大量に消費するサービスなどを動かす必要があってコスト面の心配が大きい場合には、定期的にコンテナの稼働状態を確認したり停止用 Lamda 関数をコールしたりするためのルールを EventBridge に追加しておくとより安心できるかもしれません。 参考 【節約】ECSを自動起動・自動停止する！【コスト削減】｜HikariBlog 検証環境のFargateのタスクを定期停止・定期起動してみた #Fargate | DevelopersIO ALBリスナールールとLambdaだけでメンテナンスページへの切替が簡単にできる仕組みを作る | DevelopersIO ぼくのかんがえた さいきょうの AWS 向け WordPress 環境を構築してみた | ハックノート Lambda 関数におけるコールドスタート的なものを ECS Fargate 上の自前コンテナで実現するイメージでした。 ↩ 公式ドキュメント（アラームイベントと EventBridge - Amazon CloudWatch）が参考になります。 ↩

Terraform構築 基本コマンド # aws configure profile作成 profile名：default $ aws configure --profile default # aws configure 確認・編集 $ vim ~/.aws/credentials # aws configure 削除 $ rm -r ~/.aws # terraformでモジュール単位でリソース作成 $ terraform apply -target module.VPC # Ansible Role作成 $ ansible-galaxy init nginx ディレクトリ構成 tree ├── backend.tf ├── main.tf ├── modules │   ├── alb │   │   ├── alb.tf │   │   ├── outputs.tf │   │   └── variables.tf │   ├── ec2 │   │   ├── ec2.tf │   │   └── variables.tf │   ├── security_group │   │   ├── outputs.tf │   │   ├── security-group.tf │   │   └── variables.tf │   └── vpc │   ├── outputs.tf │   └── vpc.tf backend.tf backend.tf provider "aws" { region = "ap-northeast-1" } terraform { backend "s3" { bucket = "tfstate-s3bucket" // 事前にs3バケットを作成する key = "terraform.tfstate" shared_credentials_file = "~/.aws/credentials" profile = "default" // 事前にprofile作成する region = "ap-northeast-1" } } main.tf main.tf module vpc { source = "./modules/vpc" } module security_group { source = "./modules/security_group" config = { // vpc.tfでoutputする vpc_id = module.vpc.vpc_id } } module ec2 { source = "./modules/ec2" config = { // vpc.tfでoutputする subnet-a_id = module.vpc.subnet-a_id subnet-c_id = module.vpc.subnet-c_id security_group_id = module.security_group.security_group_id } } module alb { source = "./modules/alb" config = { // vpc.tfでoutputする vpc_id = module.vpc.vpc_id subnet-a_id = module.vpc.subnet-a_id subnet-c_id = module.vpc.subnet-c_id // security_group.tfでoutputする security_group_id = module.security_group.security_group_id } } vpcモジュール modules/vpc/vpc.tf ## VPCの設定 resource "aws_vpc" "public-vpc" { cidr_block = "10.0.0.0/16" instance_tenancy = "default" enable_dns_support = true enable_dns_hostnames = true tags = { Name = "public-vpc" } } ##サブネットの作成 resource "aws_subnet" "public-subnet-a" { vpc_id = aws_vpc.public-vpc.id cidr_block = "10.0.16.0/24" availability_zone = "ap-northeast-1a" tags = { Name = "public-subnet-a" } } resource "aws_subnet" "public-subnet-c" { vpc_id = aws_vpc.public-vpc.id cidr_block = "10.0.32.0/24" availability_zone = "ap-northeast-1c" tags = { Name = "public-subnet-c" } } ##ルートテーブルの追加(0.0.0.0/0) resource "aws_route_table" "public-route" { vpc_id = aws_vpc.public-vpc.id route { cidr_block = "0.0.0.0/0" gateway_id = aws_internet_gateway.example_GW.id } } ##ルートテーブルの追加 resource "aws_route_table_association" "puclic-subnet-a" { subnet_id = aws_subnet.public-subnet-a.id route_table_id = aws_route_table.public-route.id } resource "aws_route_table_association" "puclic-subnet-c" { subnet_id = aws_subnet.public-subnet-c.id route_table_id = aws_route_table.public-route.id } ##ゲートウェイの設定 resource "aws_internet_gateway" "example_GW" { vpc_id = aws_vpc.public-vpc.id } modules/vpc/outputs.tf output "vpc_id" { value = aws_vpc.public-vpc.id } output "subnet-a_id" { value = aws_subnet.public-subnet-a.id } output "subnet-c_id" { value = aws_subnet.public-subnet-c.id } security_groupモジュール modules/security_group/security-group.tf ## security group resource "aws_security_group" "example_SG" { name = "example_SG" description = "example_SG" vpc_id = var.config.vpc_id ingress { from_port = 80 to_port = 80 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } ingress { from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } egress { from_port = 0 to_port = 0 protocol = "-1" ipv6_cidr_blocks = ["::/0"] } tags = { Name = "example_SG" } } modules/security_group/variables.tf variable "config" { type = object({ vpc_id = string }) } modules/security_group/outputs.tf output "security_group_id" { value = aws_security_group.example_SG.id } EC2モジュール modules/ec2/ec2.tf ##EC2(example_EC2) resource "aws_instance" "example_EC2" { ami = var.ami instance_type = var.instance_type disable_api_termination = false key_name = "EC2-key" vpc_security_group_ids = [var.config.security_group_id] subnet_id = var.config.subnet-a_id root_block_device { volume_type = "gp2" volume_size = var.volume_size } tags = { Name = "example_EC2" } } ##EIP(example_EC2) resource "aws_eip" "example_EC2" { instance = "${aws_instance.example_EC2.id}" vpc = true } modules/ec2/variables.tf variable "config" { type = object({ subnet-a_id = string subnet-c_id = string security_group_id = string }) } variable "ami" { default = "ami-XXXXXXXXXXXX" } variable "instance_type" { default = "t2.micro" } variable "volume_size" { default = "8" } ALBモジュール modules/alb/alb.tf resource "aws_alb" "alb" { name = "alb" security_groups = [var.config.security_group_id] subnets = [var.config.subnet-a_id, var.config.subnet-c_id] internal = false enable_deletion_protection = false } resource "aws_alb_target_group" "target-group" { name = "target-group" depends_on = [aws_alb.alb] port = 80 protocol = "HTTP" vpc_id = var.config.vpc_id target_type = "ip" health_check { protocol = "HTTP" path = "/ping" port = 80 unhealthy_threshold = 5 timeout = 5 interval = 10 matcher = 200 } } resource "aws_alb_listener" "listener" { load_balancer_arn = aws_alb.alb.arn port = 80 protocol = "HTTP" default_action { target_group_arn = aws_alb_target_group.target-group.arn type = "forward" } } resource "aws_alb_listener_rule" "rule" { depends_on = [aws_alb_target_group.target-group] listener_arn = aws_alb_listener.listener.arn priority = 100 action { type = "forward" target_group_arn = aws_alb_target_group.target-group.arn } condition { path_pattern { values = ["*"] } } } modules/alb/variables.tf variable "config" { type = object({ vpc_id = string subnet-a_id = string subnet-c_id = string security_group_id = string }) } modules/alb/outputs.tf output "dns_name" { value = aws_alb.alb.dns_name } ansible構築 ディレクトリ構成 Role作成 $ ansible-galaxy init nginx tree ├── nginx │   ├── README.md │   ├── defaults │   │   └── main.yml │   ├── files │   ├── handlers │   │   └── main.yml │   ├── meta │   │   └── main.yml │   ├── tasks │   │   └── main.yml │   ├── templates │   ├── tests │   │   ├── inventory │   │   └── test.yml │   └── vars │   └── main.yml ├── playbook.yml ├── aws_ec2.yml aws_ec2.yml aws_ec2.yml plugin: aws_ec2 aws_access_key_id: XXXXXXXX aws_secret_access_key: XXXXXXXX aws_security_token: regions: - ap-northeast-1 hostnames: - tag:Name groups: nginx: "'<EC2インスタンス名>' in tags.Name" compose: ansible_host: public_ip_address playbook.yml playbook.yml - hosts: nginx become: true vars_files: - ./nginx/vars/main.yml roles: - nginx Nginx Role nginx/tasks/main.yml - name: Enable amzn2extra-nginx1.12 repository shell: amazon-linux-extras enable nginx1.12 changed_when: false - name: Install Nginx packages from amazon-linux-extras yum: name: nginx state: present nginx/vars/main.yml # vars file for nginx ansible_ssh_user: ec2-user ansible_ssh_private_key_file: ~/.ssh/EC2-key.pem 実行コマンド $ ansible-playbook -i aws_ec2.yml playbook.yml 参考文献 AnsibleでEC2のAmazon Linux 2にNginxをインストールする方法の検討（古いJinja2でもOK） AnsibleでAmazonLinux2 + Laravel + mysql5.7 + nginx + SSL環境を構築する。 【AWS・Ansible】 コマンド１つでAmazon EC2インスタンス作成 Ansibleでnginx+php構築 TerraformでALBを作成する 特定のresourceだけ terraform {plan|apply} したい Ansibleでできることを中の人が教えます - インストールと実行～EC2へのNginx投入までを学ぼう [Terraform][Backends][v0.9]tfstateファイルの管理方法

背景 ローカルのAWS構成情報一覧を表示しようと思い、 $ aws configure list-profiles を実行したが、AWS CLIのバージョンが古いみたく、実行失敗した。 2系のAWSCLIにバージョンアップする必要があるので、その手順をメモ程度にざざっと書く。 前提 $ aws --version aws-cli/1.18.43 Python/2.7.16 Darwin/17.7.0 botocore/1.15.43 バージョンアップ実行 $ curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg" $ sudo installer -pkg AWSCLIV2.pkg -target / 確認 $ aws --version aws-cli/2.2.2 Python/3.8.8 Darwin/17.7.0 exe/x86_64 prompt/off 2系のaws-cliにバージョンアップできました！ aws-cli以外にも変更されてるのは、他作業で変わってしまったかもしれないですm(_ _)m 参考

今回EC2上にデプロイする時にDockerfileのせいで詰まってしまいました。 なのでその解決方法を書いて生きたおと思います。 まず、Dockerfileの記述に足りないところがありました。 それは、yarnとNode.jsをインストールする記述が足りませんでした。 Rails6では、上の2つがないと行けないのですが、それを入れなくてもローカルでは動いていました。 なぜかというと、Dockerに乗せていないRails6のアプリケーションを作った時にローカル上にすでに入っていたからです。 しかし、EC2内のOSではローカルとは環境が違うのでそれらは入っていません。 なので、そのアプリケーションを入れる必要があります。 問題のコード Before これは本番環境で詰まってしまった時に書いていたコードです。 YarnやNode.jsを入れる記述がないのでエラーになってしまいました。 FROM ruby:2.5.3 # railsコンソール中で日本語入力するための設定 <- NEW ENV LANG C.UTF-8 # RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs # /var/lib/apt/lists配下のキャッシュを削除し容量を小さくする <- NEW RUN apt-get update -qq && \ apt-get install -y build-essential \ libpq-dev \ nodejs \ && rm -rf /var/lib/apt/lists/* # 作業ディレクトリの設定 RUN mkdir /app_name ENV APP_ROOT /app_name WORKDIR $APP_ROOT # gemfileを追加する ADD ./src/Gemfile $APP_ROOT/Gemfile ADD ./src/Gemfile.lock $APP_ROOT/Gemfile.lock # gemfileのinstall RUN bundle install ADD ./src/ $APP_ROOT この記述だと、Yarnなどが履いていないのがわかると思います。 なのでそれをこういった記述に変えた所エラーが出なくなりました。 FROM ruby:2.6.5 # 必要なパッケージのインストール（基本的に必要になってくるものだと思うので削らないこと） RUN apt-get update -qq && \ apt-get install -y build-essential \ libpq-dev # yarnパッケージ管理ツールをインストール RUN apt-get update && apt-get install -y curl apt-transport-https wget && \ curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && \ echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list && \ apt-get update && apt-get install -y yarn # Node.jsをインストール RUN curl -sL https://deb.nodesource.com/setup_7.x | bash - && \ apt-get install nodejs # 作業ディレクトリの作成、設定 RUN mkdir /app_name ##作業ディレクトリ名をAPP_ROOTに割り当てて、以下$APP_ROOTで参照 ENV APP_ROOT /app_name WORKDIR $APP_ROOT # ホスト側（ローカル）のGemfileを追加する（ローカルのGemfileは【３】で作成） ADD ./Gemfile $APP_ROOT/Gemfile ADD ./Gemfile.lock $APP_ROOT/Gemfile.lock # Gemfileのbundle install RUN bundle install ADD . $APP_ROOT まとめ 基本的にDockerに乗せている状態で動いているのなら、本番環境でも動きます。 しかし、ローカル環境と本場環境後外から出てきてしまうエラーというのもあるので、それらに気をつけて開発していくことを心がけていきたいと思います。 ありがとうございました。

前回やってみたけど、やっぱりめんどくさいので、マーケットプレイス版で立ち上げてみた。 ここからSubscribeしてみる。 マーケットプレイスでの起動 Continue to Configurationをクリックして 素直に、Continue to Launch EC2 Instance Typeは無料枠でやる場合はt2.microを選択 Key Pair SettingsはSSH接続するために必要なのでいつも使っているものを選択 そしてLaunch 起動確認 .bashrc alias awscheck="aws ec2 describe-instances --query 'Reservations[*].Instances[].{ID: InstanceId,PublicIpAddress: PublicIpAddress,State: State.Name}' --output text" function sshec2() { command ssh -i ~/.ssh/XXX.pem -o CheckHostIP=no -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ec2-user@$1 } ec2での起動を確認するaliasなどはこちら。 Splunkにログインする時にも、インスタンスIDとIPアドレスは必要なので、設定しておくと便利だと思う。 % awscheck i-09f8a6cc53ff73XXX 3.227.12.XXX running となったら、ブラウザからIPアドレス:8000でアクセス 最初はadminとSPLUNK-{インスタンスID}この場合だとSPLUNK-i-09f8a6cc53ff73XXXでログイン 無事に起動できた。 コマンドでの起動 runsplunk.sh aws ec2 run-instances --image-id ami-07d6726fc57ebfe52 --count 1 --instance-type t2.micro \ --key-name XXX --subnet-id subnet-ff249aXX --security-group-ids sg-005477fbf24cebeXX \ --output text Webで起動した際のAMI image IDとsecurity groupを控えておけば、次回以降はこんな感じで起動できる。 デフォルトのセキュリティグループは ポート範囲 プロトコル ソース セキュリティグループ 8000 TCP 0.0.0.0/0 Splunk Enterprise-8-1-1-AutogenByAWSMP- 554 TCP 0.0.0.0/0 Splunk Enterprise-8-1-1-AutogenByAWSMP- 22 TCP 0.0.0.0/0 Splunk Enterprise-8-1-1-AutogenByAWSMP- 8089 TCP 0.0.0.0/0 Splunk Enterprise-8-1-1-AutogenByAWSMP- 9997 TCP 0.0.0.0/0 Splunk Enterprise-8-1-1-AutogenByAWSMP- とアクセス元を絞っていないので、curl https://checkip.amazonaws.comで調べて登録したほうがいいかも 制限など ESBストレージは20GBで、$SPLUNK_HOMEが設定されていない　 稼働状況 tutorialデータをアップロードして検索してみても違和感なし。 まとめ 起動してしまえばAPIでユーザとか追加できるし、一時的に使う分には十分だと思います。 S3にＣＳＶを溜め込んでいるので、あとで読み込み方を調べよう。

こんにちは、まゆみです。 AWSについての記事をシリーズで書いています。 今回は第9回目になります。 第7回目の記事では、実際にEC2インスタンスを作る方法を解説させていただきました。 今回の記事では、そのEC2インスタンス(Linux)に接続する方法を解説していこうと思います ではさっそく始めていきますね。 注意 EC2インスタンスを作る際、AMI(普段のパソコンで言えばOSのようなもの)にLinuxを選択したインスタンスへの接続方法を書いています。Windowsを選んだインスタンスではこの記事の内容は適応できませんので注意です。 EC2(Linuxインスタンス)接続方法、早見表 SSH Putty EC2 Instance Connect Mac OK OK Linux OK OK Windows(10以前) OK OK Windows(10以降) OK OK OK PuTTyを使った接続方法 上記の早見表のようにEC2インスタンス(Linux)に接続する方法はいくつかあるのですが、今回はPuTTyを使った接続方法に的を絞って解説してきます PuTTyを使ってインスタンスに接続するには ①PuTTygen を使って、pemファイルをppkファイルに変更する ②ppkファイルのプライベートキーを使ってSSHで接続する PuTTyのインストール PuTTyをインストールしていない方は、こちらからどうぞ 下記のようなページにアクセスできますので、赤で囲んだところから選択してクリックして、そのまま『Next』をクリックし続けて、インストールを終えてくださいね。 PuTTygenを起動させる Windowsのスタートメニューに『putty』と入力すると、PuTTygenというのが表示されるので、それをクリックして起動させます Loadをクリックする ①All Files に変え 　 ②pkkファイルに変更したいpemファイルを選択します Save Private Key をクリックします ppkファイルとして保存し、PuTTygen を閉じます PuTTyを起動させる PuTTy　Configuration の Connection > SSH > Auth をクリックし、先ほど作ったppkファイルを探します ①Session をクリックして ②『ec2-user@』の後にパブリックIPアドレスを入力し ③Open をクリックします 下記のようになれば、成功しています まとめ 今回の記事は以上で締めくくります。 インスタンスのOSや、あなたの使っているOSによってEC2インスタンスへの接続方法も変わってきますので、そこを注意深く見ながらAWSの情報を集めてみてくださいね。

ssh するだけのユーザをつくる sudo は許可しない 環境 サーバ Ubuntu 14.04 LTS クライアント Ubuntu 20.04 LTS クライアントで鍵ファイル作成 今回は、鍵ファイルにパスフレーズをつけました。 $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/nanbuwks/.ssh/id_rsa): ./hogehoge Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in ./hogehoge. Your public key has been saved in ./hogehoge.pub. The key fingerprint is: SHA256:IVTCsgbteJ/XiZmY2n0v7TcDFgYJ20qFqSIqzPzgmH8 nanbuwks@nanbuwks-ThinkPad-X230 The key's randomart image is: +---[RSA 3072]----+ | . .o.o+.. | | . o...o+o | | + o..+ .. | | o * .o o o | |+. + o +S= o . | |o= = = o o | |+.o o o o . | |o. .E . . o . + | | ... . +o. o | +----[SHA256]-----+ 秘密鍵と公開鍵ができたことを確認します。 $ ls hogehoge* hogehoge hogehoge.pub 秘密鍵の名前を変更しておきます。 $ mv hogehoge hogehoge.pem サーバでユーザ追加 パスワード無しで追加 $ sudo adduser hogehoge --disabled-password Adding user `hogehoge' ... Adding new group `hogehoge' (1007) ... Adding new user `hogehoge' (1007) with group `hogehoge' ... The home directory `/home/hogehoge' already exists. Not copying from `/etc/skel'. Changing the user information for hogehoge Enter the new value, or press ENTER for the default Full Name []: Room Number []: Work Phone []: Home Phone []: Other []: Is the information correct? [Y/n] サーバで hogehoge ユーザのログオン環境を調整 まず hogehoge ユーザでログオンしてユーザディレクトリなどを作成してもらう $ sudo su - hogehoge 次に SSH に必要なファイルなどを作成する $ mkdir .ssh $ chmod 700 .ssh $ touch .ssh/authorized_keys $ chmod 600 .ssh/authorized_keys public キーを登録する scp などでクライアントからサーバに公開鍵を転送し、登録する 例えば /tmp/hogehoge.pub に転送していたとした場合： $ cp /tmp/hogehoge.pub .ssh/authorized_keys クライアントからアクセスしてみる $ ssh -i hogehoge.pem hogehoge@www.example.com Enter passphrase for key 'hogehoge.pem': . . . hogehoge@example:~$ アクセスできました。うまくいったので、 pem ファイルを秘密の場所に保存し、400 にパーミッションを変更しておきましょう。