AWS入門 AWSを何度か触ってみたことはあるけど毎回毎回学び直して立ち上げており、きちんとまとめないとなと思いまとめたいと思います。また、コマンドの意味などもきちんとわかるようにまとめようと思います。 EC2の立ち上げ 1. インスタンスを起動をクリック 2. Amazon Linux 2 AMI Kernel 4.14, SSD Volume Typeを選択 無料枠で使用できるインスタンスを使用する。 3. t2.microを選択 こちらも無料枠で使用できるスペックにしておく。 4. インスタンスの詳細の設定 ネットワーク EC2を立ち上げる際にVPCがないと立ち上げることができないため, VPCを設定していないがデフォルトで設定されている。 自動割り当てパブリックIP こちらは有効にしておく。有効にしておくと自動でIPを割り当ててくれる。 5. ストレージの選択 ここは特に変更する必要がない。 6. タグの設定 名前を設定することができる。 例えばキー：Name、値：WebServer とかにしておく。 7. セキュリティグループの設定 アクセスできるプロトコルやIPアドレスを設定できる。 0.0.0.0/0は全てのIPからのアクセスを可能にする。 Webサーバの場合は、タイプからHTTPSやHTTPのプロトコルを有効にしておく必要がある。 8. 起動 キーペアをダウンロードした後に起動させる。 SSH接続 Macではターミナルを使ってSSH接続することができる。 mv /Users/xxx/xxx/xxx/xxx/udemySample.pem ~/ .ssh/ .pemファイルを.sshフォルダに移動する。 chmod 400 ~/.ssh/udemySample.pem chmodは権限設定を変更するコマンド。 pemファイルのアクセス権限を400に変更する。 chmodの権限設定についてはこちら。 ssh -i ~/.ssh/udemySample.pem ec2-user@パブリックIP アドレス 以上でSSH接続が可能。

項目 1.AWS責任共有モデル 2.AWSクラウドのセキュリティ 3.IAM 4.セキュリティーグループ 5.「AWS Shield」と「AWS WAF」 6.Inspector ※ 『AWS認定資格試験テキスト AWS認定クラウドプラクティショナー』 の第3章に相当 1.AWS責任共有モデル AWSでは、責任所在が明確になっています。 AWSとユーザーのそれぞれは、責任を負う部分が明確になっており、それぞれが責任を共有して守っていくことを「責任共有モデル」と言います。 （１）クラウド本体のセキュリティ AWSが担当するセキュリティ部分です。 ハードウェア、AWSグローバルインフラストラクチャ、リージョン、アベイラビリティ、エッジロケーションといったデータセンター、マネージドなサービス、そこに含まれる各種サービスが、AWSの担当です。 AWSでは、プライバシー及びデータ保護における"国際的なベストプラクティス"を採用した「セキュリティ保障プログラム」を策定しています。 （２）クラウドないのでセキュリティ クラウド内のセキュリティは、ユーザーの担当です。 オペレーションシステム、アプリケーションの管理、AWSが提供するセキュリティグループファイアーウォールなどの管理を、ユーザー自らがしなければいけません。 2.AWSクラウドのセキュリティ 利点は４つです。 （１）データ保護 ➡️ユーザーの情報を保護するための強力な安全対策が施されている。すべてのデータは、AWSのデータセンターに保存されている。 （２）コンプライアンス要件に準拠 ➡️AWSインフラストラクチャの中で、数多くのコンプライアンスプログラムを活用できる。そのため、サービスを利用するだけで、一部のコンプライアンスを自動的に満たすことができる。 （３）コスト削減 ➡️人員や設備などをコストをかけなくても済む。 （４）迅速なスケーリング ➡️AWSクラウドの使用量に合わせてセキュリティをスケーリングできる。 ○AWSが責任を持つ範囲 ▼物理的なセキュリティ （1）環境レイヤー 様々な災害によるリスクを低減するため、データセンターの設置場所を慎重に選択している。 もし、何らかの処理中に特定のデータセンターが被害を受けても、同じデータセンター群に属している別の場所のデータセンターに処理を移行できる。 （2）物理的な境界防御レイヤー 物理的な位置によって、保安要員、防御壁、進入検知テクノロジー、監視カメラ、そのほかセキュリティ上の装置などが存在している。 （3）インフラストラクチャレイヤー データセンターの建物、各種機器、およびそれらの運用に関わるシステムが存在している。 発電設備や、冷暖房換気空調設備、消化設備などもある。 （4）データレイヤー ユーザーのデータを保持する唯一のエリアとなる。 アクセスを制限し、各レイヤーにおいて特権を分離している。 ▼ハイパーバイザーのセキュリティ管理 ハイパーバイザーのセキュリティは、AWSが担当します。 ハイパーバイザーをターゲットとしたセキュリティ対策は、AWSが行います。 「ハイパーバイザー」とは、コンピュータを仮想化するためのソフトウェアのことです。 物理的なマシンの中に、仮想的なコンピュータを作り出し、実行する際に使用します。 物理的なマシンが1台でも、複数の仮想環境を構築することで、並列して作業を行うことができます。 ▼管理プレーンの保護 これは、ユーザーの責任範囲です。 具体的には、「ID・パスワード」「キーペア」「APIキーの管理」「アクセス制御と権限管理」が該当します。 「ID・パスワード」について、AWSでは、「MFA（多要素認証）デバイス」の利用が可能となっており、サインアップ時に作成したルートアカウントなど、権限の強いアカウントに設定することが望ましいです。 「キーペア」について、EC２などのインスタンスへのログインで使用します。 現在では、公開鍵認証方式を用いたキーペア管理が一般的です。 秘密鍵と公開鍵をセットで管理するのですが、どちらもユーザーの責任で管理しなくてはいけません。そのため、秘密鍵を失くしても、AWSでは対応できません。 「APIキーの管理」については、WEBブラウザで操作を行うAWSマネジメントコンソール、コマンドで操作を行うAWS CLI、プログラムで操作を行うAWS SDKの３つがあります。 AWS CLIとAWS SDKでは、アクセスキーとシークレットアクセスキーのペアで認証します。これらは、IDとパスワードに相当するものであり、各ユーザーに対して作成できます。 そのため、権限の強いアカウントでは発行しないようにし、必要最低限の権限のみ付与することが推奨されています。 特に、ルートアカウント（最も権限の強いアカウント）には、APIキーを発行しないようにしましょう。 ▼マネージドでないサービス Amazon EC2やAmazon VPCなど、（Iaas）にカテゴライズされるサービスは、ユーザーが管理者権限やルート権限を持って管理するため、ユーザーの責任となります。 EC2インスタンスの場合、ゲストOSの管理、インストールするアプリケーションソフトウェア、AWS提供のファイアーウォールの設定などに責任を持たなければいけません。 マネージドでないサービス上に存在するデータやコンテンツも、ユーザーに管理責任があります。 ▼マネージドなサービス データベースサービスであるAmazon RDSやAmazon DynamoDBなどがマネージドなサービスの一例です。 ユーザーから直接見えない部分の責任は、AWSにあります。 オペレーティングシステムや、データベースのパッチ適用、ファイアーウォールの設定、災害対策など、AWSが実行します。 パッチの適用、メンテナンス、ウィルス対策ソフトの導入など、ユーザーは行う必要がなくなります。 マネージドサービスの場合、リソースへのアクセスコントロールの設定と、アカウント認証情報の保護のみがユーザーの責任です。 ○セキュリティのベストプラクティス ユーザーが責任を負う部分について、下記の4点を押さえておく必要があります。 （１）転送中のデータ 適切なプロトコルおよび暗号化アルゴリズムを使用します。 インターネットを介した通信の場合、第三者からその通信内容を秘匿する必要があるので、SCPなどの暗号化されたプロトコルを選択しましょう。 また、脆弱性のある暗号化アルゴリズムを使用することも避けましょう。 （２）蓄積データの保護 蓄積データの物理的な保護はAWSが行ってくれますが、運用上のデータベースやストレージの内容を出力することがあります。 この際、意図しないところで、権限のないスタッフにもアクセス可能な状態となることがあります。 そのため、データベースを扱う際は、データの暗号化を行うことが望ましいです。 AWSにはマネージドなデータベースの暗号化サービスがあるので、それらを有効活用することもできます。 （３）AWSの資格情報の保護 ルートアカウントを多用せず、IAMユーザーを作成し、最小限の権限だけ付与しましょう （４）アプリケーションの安全性の確保 SQLインジェクションやOSコマンドインジェクションなどの対策を行いましょう。 IPAやCSAなどの団体が示している脆弱性関連情報をもとに対策を行うことが望ましいです。 ○第三者認証 AWSは、第三者機関による検査を受けており、そのレポートをAWS Artifactにて提供しています。 3.IAM IAMとは、「AWS Identity and Access Management」の頭文字をとったものです。 これは、ユーザーのAWSクラウドリソースへのアクセス管理サービスです。 AWSにサインアップした時のアカウントを「ルートアカウント」と呼び、すべての権限を持っています。 ルートアカウント内で、IAMユーザーやIAMグループを作成することができます。 IAMユーザーごとに、各種リソースの権限を付与します。 AIMポリシーが相反する時、拒否が優先されます。 APIキーは、IAMユーザーに最大２つまで発行できます。 これは、キーの入れ替えを行う際に、すべての入れ替えが終わるまでアプリケーション側に権限がなくなってしまうのを防ぐためです。 ○IAMロール 現在、APIキーの使用は推奨されていません。 その代わり、IAMロールの使用が推奨されています。 AWSの内部で、IAMロールとEC2を直接紐づけることができるため、キーを管理する必要がありません。 4.セキュリティグループ セキュリティグループは、１つ以上のインスタンスのトラフィックを制御する仮想ファイアーウォールです。 各インスタンスごとに個別のファイアーウォールを設定することができます。 「許可ルールの指定が可能」「拒否ルールの指定は不可能」「インバウンドトラフィックとアウトバウンドトラフィックのルールを個別に指定可能」といった設定ができます。 5.「AWS Shield」と「AWS WAF」 ○AWS Shield AWS Shieldは、マネージド型の分散サービス妨害（DDos攻撃）に対する保護サービスです。 DDos攻撃とは、意図時に通信量を増大させ、通信回線やサーバーに負荷をかけることで、サービス利用を困難にさせたり、ダウンさせたりする攻撃のことです。 AWS Shieldは、StandardとAdvancedといった保護サービスがあります。 ○AWS WAF AWS WAFは、アプリケーションの可用性低下、セキュリティの侵害、リソースの過剰消費などの一般的なWebの脆弱性からWebアプリケーションを保護する、マネージド型のファイアーウォールです。 基本的に無料で、設定については、ユーザー自身で行う必要があります。 AWS ACLでのAWS WAFの適用サービスは、 CDNサービスのCloudFront、ロードバランサーのApplication Load Balancer、API Gatewayから選択します。 6.Inspector AWSのEC2上にデプロイされたアプリケーションのセキュリティとコンプライアンスを向上させるための、脆弱性診断を自動で行うことができるサービスです。 評価が実行されたあと、重大性の順に結果を表示した詳細なリストが作成されます。 Inspectorによって行える診断の項目は、「一般的な脆弱性や漏洩」「ネットワークセキュリティにおけるベストプラクティス」「認証におけるベストプラクティス」「OSのセキュリティにおけるベストプラクティス」「アプリケーションセキュリティにおけるベストプラクティス」「PCI DSS 3.0アセスメント」などです。 以上 ※補足 AWSのコンプライアンスレポートにオンデマンドでアクセスできる無料のサービスAWS Artifactがあります。 また、AWS Key Management Service（KMS）というサービスもあり、AWS上で暗号化キーを簡単に作成・管理し、幅広いAWSのサービスやアプリケーションでの使用を制御できます。 参考書籍 ※ 『AWS認定資格試験テキスト AWS認定クラウドプラクティショナー』 ● Amazonはこちら ● 楽天はこちら

起こったこと AWSのEC2で、GPU搭載のEC2インスタンスタイプ（g4dn.xlarge）のインスタンスをコマンドラインから作成しようとしたところ以下のようなエラーメッセージが出て失敗しました。 10:57:19 AM | CREATE_FAILED | AWS::EC2::Instance | Ec2ForDl-Instance You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit. 初期状態の AWS アカウントでは， GPU 搭載の Gタイプのインスタンスの起動上限が0になっていることがある． これを確認するには， AWS コンソールから EC2 の画面を開き，左のメニューから Limits を選択する． その中の Running On-Demand All G instances という数字が G インスタンスの起動上限を表している． もし，これが 0 になっていた場合は， AWS の自動申請フォームから上限緩和のリクエストを送る必要がある． 詳しくは 公式ドキュメンテーション "Amazon EC2 service quotas" を参照のこと． エラーメッセージの通りなのですが、これですね。 先人の記事を参考にしてリクエストを送りました。ほぼ同じ内容になるのですが一応自分用メモとしても残しておきます。 https://zenn.dev/omakazu/scraps/8ec2e0f868f78b 対応内容 緩和後の上限 上限が0になっているのが問題なわけですが、上限をいくつまで引き上げればいいのでしょうか。これは計算ツールを使って、その結果に従えばいいようです。 結果としては、g4dn.xlargeの場合は上限を4まで引き上げればいいようでした。 申請フォームの入力 上限緩和リクエストは以下のリンク先のフォームで送ります。 http://aws.amazon.com/contact-us/ec2-request 内容は以下の通り。 Create case Service limit increase Case details EC2 インスタンス リージョン アジアパシフィック（東京） プライマリインスタンスタイプ All G instances New limit value 4 Use case description For study.（※これは適当） この内容で送信しました。 今回は申請の6時間半後くらいに完了の連絡が来ました。その後、無事インスタンスを作成できました。

～RDB～ ●AWS RDS(Relation Database Service） AWSのリレーショナル型のデータベースを提供するサービス。 通常データベースを利用する際のサーバ構築等が不要。 Amazon Aurora、MySQL、MariaDB、Oracle、Microsoft SQL Server、PostgreSQLから選択できる。 ※RDSを利用せずにEC2上にRDBをセットアップするやり方もあるが、RDSの方が運用面・可用性でメリットが大きい 　-RDB（リレーショナルデータベース） データを表形式で格納するデータベース 表の行（横）を「レコード」、（縦）を「フィールド」、表を「テーブル」と呼ぶ ●Amazon Aurora MySQL および PostgreSQL と互換性のあるAWS独自のRDB 最大15個のリードレプリカを持ち、高速・高可用性を実現する 　-リードレプリカ： 　更新用データベース（マスター）からレプリケーションされた参照専用のデータベースのこと 　参照用アクセスを分散し性能を向上させることができる -Aurora マルチマスタークラスター 　別AZにライトレプリカを作成する（マルチマスタ）機能（書き込み後の読み込み整合性もを持つ） 　どのノード・AZが落ちてもダウンタイムが０になる ～NoSQL～ ●NoSQL (非リレーショナル) データベース テーブル構造（スキーマ）を固定することなく、そのままの形で格納するデータベース 非定型な構造を持つデータを柔軟に管理することができ key/value stores、wide column、DocumentDBなどのタイプがある ●key-value型データベース 非リレーショナルデータベースの一種で、キーと値によるシンプルな形でデータを保持する ●DynamoDB AWSの提供するフルマネージドのKeyValue型データベースサービス 　-グローバルテーブル： 複数のリージョンでDynamoDBのテーブルを自動で同期する機能 アクセス元の国・地域によるネットワーク遅延をなくし、高速の読み取り/書き込み処理を行うことができる ●Amazon ElastiCache AWSのマネージド型インメモリキャッシュサービスのこと memcachedとRedis　の２種類が利用可能 フルマネージド、高速アクセス、スケーラブルという特長がある。 (補足）キャッシュ データを高速にアクセスする形で（ストレージとは別に）保持しておくこと。 　データを保管しているストレージにアクセスする回数を減らし、データ取得のパフォーマンスをアップさせることができる (補足）インメモリデータベース 　データをディスクや SSDではなく、データストレージ用のメモリに保存するデータベース 　高速にアクセスすることが可能。 　電源を喪失した場合などいにデータが消失する場合があるため、永続性を保つにはデータをバックアップする必要がある (補足）揮発性メモリ 　電源供給が途絶えるとデータが消失するメモリのこと -memcached（memory cache daemon ） 分散型キャッシュシステムを構築することができるソフトウェア。 ・キーとバリューをシンプルな1対1で組み合わせて保存する。 ・キーごとにマルチスレッドで動作する。 ※AWSのElastic　memcachedの場合、ノード間の複製は行わないため障害が発生するとデータは消える -Redis オープンソースの非リレーショナルデータベース ・単純なKey-Valueだけでなく複雑な種類のデータも扱える ・メモリ上のデータをストレージに格納し、永続的に保持する機能がある

●AWS　EC2（Amazon Elastic Compute Cloud） AWS上にLinuxやWindowsなどの仮想サーバを作成できるサービス ●EC2インスタンス EC2を利用した仮想サーバのこと ●インスタンスタイプ サーバのスペック（CPU、メモリ）のこと。 ●AMI（Amazon Machine Images） EC2インスタンスの起動に必要な情報が入ったイメージ ●ゴールデンイメージ 最適なEC2インスタンス構成を反映したAMIのこと ●EC2 Image Builder AMIを作るためのツール ●AWS Marketplace AMIの購入や、自分で作成したAMIを他のユーザへ有償で提供することができるサービス ●インスタンスの利用形態（安い順） -スポットインスタンス： 　 待機しているEC2を安価で利用できるサービス。EC2の利用に中断が発生する可能性がある。 -リザーブドインスタンス： 　 一定期間継続して利用することを前提に、大幅な割引を受けられるサービス -オンデマンドインスタンス： 　利用した分だけ支払う、一般的な利用方法 -Dedicated Hosts： 　コンプライアンス上の理由がある場合などに、物理サーバを専有するサービス ●EBS(Elastic Block Store） EC2インスタンスにアタッチして使われるAWSのストレージサービス 高性能で可用性に優れたブロックストレージ 　-マルチアタッチ： 同じアベイラビリティーゾーンにある複数のインスタンスから同じEBSにアクセスすること ●AWS S3（Amazon Simple Storage Service） AWSのオブジェクトストレージサービス ・容量無制限（1つのファイルについては5TBまで） ・9.999999999%(イレブンナイン)のデータ耐久性（最低3つのアベイラビリティゾーンに自動的に複製して保存される） ・静的コンテンツをホスティングできる （S3に画像、動画、HTMLなどをアップロードするとインターネットからアクセスできるURLを生成できる） ●S3の種類６個 　S3 standard 　　頻繁にアクセスされるデータ向け 　S3 Standard IA(Infrequent Access)： 　　たまにしかアクセスしないデータ向け。standard と比べストレージコストが下がるが、取り出し料・転送量がかかる 　S3 Intelligent-Tiering 　アクセスパターンに基づいてコスト効率の高いストレージ階層に自動で移動してくれる機能 　S3 One Zone-IA 　　1AZしか利用しないので可用性が下がる 　Amazon S3 Glacier 　使用頻度の少ないファイルを長期的に保存（アーカイブ）するためのサービス 　データを取り出す際に数時間かかる。 　S3 Glacier Deep Archive 　 データを取り出すのに12時間かかる

クラウドプラクティショナー頻出の用語についてググった内容のメモ。 ●AZ（Aveilavility Zone） 　お互いに影響を受けないように、地理、電源、ネットワーク的に分離して冗長化したAWSの各データセンター -シングルAZ： 　１つのAZを利用してシステムを構築する構成 -マルチAZ： 　複数のAZを利用してシステムを構築する構成 　一つのAZで大規模な障害が発生しても他の正常なAZを使用して稼動を継続できるため、システムの可用性を向上させることができる -リージョン： 　AWSの施設がある地域（都市）　例）東京リージョン、大阪リージョン -マルチリージョン 　複数のリージョンにシステムをそれぞれ配置する構成 　リージョンが全滅するような災害・障害時にも可用性を担保することができる ※補足 シングルAZ→マルチAZ→マルチリージョンの順に可用性が上がるが、コストと運用の複雑さも上がる ●フェイルオーバー 　稼働中のシステムから待機中のシステムへ切り替わること ●Auto Scaling コンピューティングリソースを必要に応じて自動で増減させる機能 ●AWS CLI（Command Line Interface） AWSのサービスをコマンドラインから操作し、管理するためのツール

先日、AWS認定ソリューションアーキテクトプロフェッショナルの試験を受験し、合格しました！ その記録を残しておきます。 先月AWS認定資格を5個取得し、残りはプロフェッショナル2つのみとなっていました。プロフェッショナル資格は、これまでの試験の出題範囲と重なっているだろうから、まだ勉強した記憶のあるうちに残りも取ってしまおうと考え、まずはソリューションアーキテクトプロフェッショナルを年始に受験しました。心に余裕がある年始のうちにです。 2021年12月の受験履歴 (リンク先は合格体験記) AWS Certified Data Analytics - Specialty AWS Certified SysOps Administrator - Associate AWS Certified Security - Specialty AWS Certified Advanced Networking - Specialty AWS Certified Cloud Practitioner 過去の受験履歴 2019年9月 AWS Certified Solutions Architect - Associate 2019年10月 AWS Certified Big Data - Specialty 2019年11月 AWS Certified Machine Learning – Specialty 2020年10月 AWS Certified Database - Specialty 2021年7月 AWS Certified Developer - Associate 勉強方法 まずは本を読みました。いずれはプロフェッショナルも受験するだろうと思って先月頭に買っておいた本がありました。 AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル | 山下光洋 |本 | 通販 | Amazon これを受験の1週間前から読み始めました。いままでのスペシャリティやアソシエイトの勉強で書いたノートを更新する形で、深堀りしていきます。出題範囲のAWSサービスはいままでの試験と重なっているので、いままでの知識に漏れがあったところを埋めていくような進め方です。 模擬試験も本の巻末にありましたので、全部解いて、解説も読みました。試験の前日に一巡しました。あとはAWSが公式に出しているPDFのサンプル問題と、BenchPrepってやつの模擬試験を前日に解きました。PDFサンプル問題は前日の段階で全問正答でした。そのあとBenchPrepでは正答率85%でした。 先月の連続受験のおかげで、アソシエイトとスペシャリティの内容はある程度頭に残っていたので、復習に近い場面も多く、勉強しやすかったです。 本の巻末の模擬試験は、BenchPrepよりもずっと難しかったです。実際の試験はBenchPrepと同じくらいのレベルです。 ちなみにノートはScrapboxというサービスを私は使っています。試験勉強だけでなく、あらゆるメモや作業ログをScrapboxに残しています。 試験当日 75問180分。一巡するのに170分ぐらいかけてしまいました。1問2分、見直し時間30分と意識して残り時間を見ながら解いていたのですが、文章が長くて難しい問題があると時間を消費してしまい、見直しに充てられる時間は10分でした。その10分で少しだけ見直して、終了となりました。 事前にみんなから聞いていた通り、問題文も選択肢も文章が長いものが多かったです。ただ、これまでにスペシャリティを全部受験してきた私としては、スペシャリティでも十分長いものが多かったので、ソリューションアーキテクトプロフェッショナルだけ特別に大変だったという印象はありませんでした。問題数が少し多い分だけ大変でした。 いままでのAWSの試験に比べると日本語は分かりやすいほうだったと思います。 結果 スコア 803 （合格ライン 750） 所感 出題範囲は試験終了の瞬間に忘れてしまいました。とにかく幅広くいろいろなサービスが出てきました。スペシャリティ（機械学習を除く）の試験で勉強した内容も多かったです。この後、DevOpsエンジニアプロフェッショナル受験のための勉強したときに気が付いたのですが、Codeなんちゃら系のDevOps分野のサービスもソリューションアーキテクトプロフェッショナルの試験にはあまり出てこなかったかもしれません。とはいえ、やっぱりあらゆる領域が出題された印象です。 スペシャリティで出題された領域では、スペシャリティほどは細かいところは問われなかったです。しかし、スペシャリティを1つずつ勉強して受験することで、1分野ずつ積み重ねたおかげで、今回合格できたと思います。逆にスペシャリティよりも先にプロフェッショナルを目指していたら、勉強方法がわからなかったです。スペシャリティをすべて取ってからプロフェッショナルを取るという戦略は私にとっては正解でした。

インスタンスの作成までできたので、 今回はElastic IPとEC2インスタンスの紐付けをしてみます！ Elastic IP(EIP) とは？ 「AWSで使える固定IPアドレス」だそうです。 インスタンスを作成すると、パブリックIPが付与され、 インターネットを介してインスタンスへ接続することができるようになります。 しかし、インスタンスを再起動してしまうとパブリックIPが変わってしまうため、 それを解消するために「Elastic IP」を使用します。 Let's try ! まずAWSコンソールの ネットワーク&セキュリティ > 「 Elastic IP 」 をクリック！ 「 Elastic IP アドレスを割り当てる 」 をクリック！ ネットワークボーダーグループは「 ap-northeast-1 」、 パブリック　IPv4 アドレスプールは 「 Amazon の IPv4 アドレスプール 」 を選択。 「 割り当て 」 というボタンがあるのでクリック！ できなかった...なぜ... こちらに書いてありました。 上限値に達してるので、追加できないよ！ってことみたいです。 割り当てられていないElastic IPアドレスがあったので、それにEC2インスタンスを紐づけることに。 該当のIPアドレスを選択して、右上のアクション >「 Elastic IP アドレスの関連付け 」 をクリック！ 「 インスタンス 」 の部分で紐付けたいインスタンスを選択する。 「 プライベート IP アドレス 」 はそのままでOK！ 右下に「　関連付ける　」ボタンがあるのでクリック！ Elastic IPアドレスを確認して、「 関連づけられたインスタンスID 」にIDが入っていたらOK！ 今回はここまで ( ˆoˆ )ﾉｼ written by 福井

ImageBuilderで作成したカスタムAMIの初回起動時の設定 はじめに 先日、ImageBuilderを使用して、ZabbixAgentとSplunkをインストールしたカスタムAMIを作成しました。 このカスタムAMIを作成してEC2インスタンスを起動したのですが、Splunkが起動していませんでした。 $ cd /opt/splunk/bin $ sudo ./splunk status splunkd 3598 was not running. Stopping splunk helpers... [ OK ] Done. Stopped helpers. Removing stale pid file... done. EC2インスタンスを起動した直後に動作するよう、cronにSplunkを起動する設定を追加して検証します。 参考 システム起動時に１度だけ実行されるCronを設定する ImageBuilderでカスタムAMIを作成 前提 ImageBuilderでカスタムAMIを作成を参考に、ImageBuilderの準備ができていることとします。 ・コンポーネント 　　ZabbixAgent用 　　Splunk用 ・イメージレシピ 　　上記コンポーネントを含んだイメージレシピ ・パイプライン 　　上記イメージレシピを使用するパイプライン ImageBuilderのコンポーネントを追加 既存のコンポーネントに echo '@reboot /opt/splunk/bin/splunk start' | crontab を追記すればよいのですが、ここは共通的なコンポーネントを用意し、そちらに記述することにします。 新たに「CommonCompornent」というコンポーネントを用意しました。 コンポーネントは以下のように記述しています。 name: CommonModule description: This is CommonModule document. schemaVersion: 1.0 phases: - name: build steps: - name: SetCron action: ExecuteBash inputs: commands: - echo '@reboot /opt/splunk/bin/splunk start' | crontab 作成したコンポーネントをイメージレシピに加えます。 既存のレシピを選択し、新バージョンのイメージレシピとして作成します。 コンポーネントは「ZabbixAgent」と「Splunk」の2つだけなので、ここに先ほど作成した「CommonCompornent」を追加します。 最後に、イメージパイプラインを編集モードで開き、使用するイメージレシピを先ほど作成した最新のバージョンに変更します。 これで、「ZabbixAgent」「Splunk」「CommonCompornent」の3つのコンポーネントが含まれたイメージパイプラインが完成します。 あとはパイプラインを実行し、作成されたカスタムAMIを使用してEC2インスタンスを起動。 起動後のEC2インスタンスにSSH接続し、Splunkが起動していることが確認できました。 $ cd /opt/splunk/bin $ sudo ./splunk status splunkd is running (PID: 3283). splunk helpers are running (PIDs: 3287 3389 3469 3473). おわりに この、起動処理を初期処理として外出しするか、インストール用コンポーネントに含めるかは好みのところだと思いますが、今回は、インストールとは別の処理と位置づけ、「初期処理」として別コンポーネントにしてみました。 他にも、環境変数の設定や各種初期設定などがあれば、今回のようなCommonCompornentのように切り出しておくのが良いと思いました。

はじめに 最新情報は、公式サイトで確認して下さい。 ワークショップの詳細が知りたい方は、まとめの配布資料を見てね。　※見れなかったらゴメンなさい...。 受講日時 2022年01月12日(水) 10:00 ～ 10:55 講師 生出 拓馬 (おいで たくま) 様 アジェンダ AWS 認定について 基礎(1)、アソシエイト(3)、プロフェッショナル(2)、専門(5)の11種類 認定の有効期限は3年で、認定更新（再認定）が必要。 次回の受験時に、特典の "50% 割引バウチャー" を利用できる。 AWS Certified Cloud Practitioner 試験について 700/1000（70%）で合格。 試験時間は、90分。 テストセンターか自宅で受験可能。 試験の出題分野 4つの分野から出題され、AWSの全般的な理解が問われます。 分野 試験に占める割合 分野１ クラウドのコンセプト 26 % 分野２ セキュリティとコンプライアンス 25 % 分野３ テクノロジー 33 % 分野４ 請求と料金設定 16 % 合計 100 % 試験準備 ステップ1：試験概要の把握 ステップ2：本番試験の申し込み ステップ3：無料デジタルトレーニングの受講 ※ワークショップで配布された資料は、旧コースのようでした。最新は、AWS スキルビルダーにあります。 コース名：AWS Cloud Practitioner Essentials (Japanese) (日本語実写版) 初心者向け資料 Cloud Practitioner Essentials for Entry ステップ4：技術資料で知識を補強 AWS サービス別資料 ★オススメ AWS よくある質問 AWS ホワイトペーパーとガイド AWS ドキュメント ステップ5：模擬試験の受験 AWS Skill Builder から「AWS Certification Official Practice Question Sets」に登録 試験対策のポイント 分野１ AWS のクラウドが選ばれる 10 の理由 AWS Well-Architected フレームワーク 分野２ AWS 責任共有モデル IAM でのセキュリティのベストプラクティス 分野３ AWS グローバルインフラストラクチャ AWS サービス一覧 AWS サポートのプラン比較 分野４ AWS 料金 サンプル問題にチャレンジ 各分野3問の出題＆解答 まとめ 配布資料はコチラ　※ワークショップ中に受講者以外に配布可能か確認済。 おわりに 次回の受験時に特典の50%OFF使えるの良心的だと感じた。 3年更新はCiscoなどと同じか...個人で更新し続けるのは、正直しんどいなぁ（金銭面で(笑)）。 試験に合格したら、「 #AWS認定 」のハッシュタグを付けて、SNSに投稿しよう。

はじめに 「AWSでデプロイしたはいいけど、デザインを修正したくなったよー」という人に向けた記事です。 デプロイ後の修正を反映させるには masterにpushする まずはローカル環境で修正したファイルをGitHubのmasterブランチにpushします。 $ git push origin master git cloneしたディレクトリにpullする EC2インスタンスが開始されていることを確認してから、sshコマンドで接続します。 $ ssh -i 秘密鍵.pem ユーザー名@ipアドレス デプロイ時にgit cloneしたディレクトリに移動してpullします。 $ git pull origin master アセットをプリコンパイルする 修正がCSSなどの場合、アセットファイルをプリコンパイルする必要があります。 簡単にいうと、JavaScriptやCSSのアセットを通信量削減のためにギュッとまとめる仕組みです。 開発環境ではこの仕組みが自動で働いてましたが、 本番環境では行われないため手動で行います。 $ rails assets:precompile RAILS_ENV=production インスタンスを再起動して確認 EC2インスタンスを再起動し、きちんと反映されていればオッケーです。

AWSにデプロイするSAP　Scale-Out認定構成はピックアップしました。　 ※2022/01/12元時点の公開情報によるまとめ u-6tb1.56xlarge Workload (Scale-out - 16 active nodes: 1 master, 15 worker nodes): OLAP (incl. BW/4HANA & BWoH) Workload (Scale-out up to 4 nodes: 1 master, 3 worker and NO standby node): OLTP (incl. S/4 HANA) u-9tb1.112xlarge Workload (Scale-out up to 4 nodes: 1 master, 3 worker and NO standby node): OLTP (incl. S/4 HANA) u-6tb1.metal Workload (Scale-out - 16 active nodes with BW: 1 master, 15 worker nodes): OLAP (incl. BW/4HANA & BWoH) standby node is not allowed AWS Nitro System next generation (100Gbit/s) must be used Workload (Scale-out up to 4 nodes: 1 master, 3 worker and NO standby node): OLTP (incl. S/4 HANA) Requires SLES 12 SP3 or above / RHEL 7.4 or above For information about S/4 scale-out see SAP Note 2408419 and referenced SAP Notes. Remark: scale-out configuration is without standby node. HA is available via SAP system replication. r5.24xlarge Workload (Scale-out up to 16 nodes) OLAP (incl. BW/4HANA & BWoH) u-12tb1.metal Workload (Scale-out up to 4 nodes: 1 master, 3 worker and NO standby node) OLTP (incl. S/4 HANA) Requires SLES 12 SP3 or above / RHEL 7.4 or above x1.32xlarge Workload (Scale-out up to 25 nodes) OLAP (incl. BW/4HANA & BWoH) Requires SLES 12 SP1 or above / RHEL 7.4 or above Remark: Based on SPS11 (or later) core-to-memory relaxation for OLAP, as of SPS11 customers can make full use of RAM x1e.32xlarge Workload (Scale-out up to 25 nodes) OLAP (incl. BW/4HANA & BWoH) - up to 1.9TiB per node Requires SLES 12 SP1 or above / RHEL 7.4 or above Default scalability guidelines for generic OLAP and OLTP workloads apply. For customer-workload optimized configuration - up to 4TiB per node is supported; see HANA sizing guidelines at https://www.sap.com/about/benchmark /sizing.html for details on customer workload-driven sizing. r3.8xlarge Scale-out (up to 17 nodes, >5 nodes in controlled availability): OLAP (incl. BW/4HANA & BWoH) BPC (special attention has to be paid to table distribution (see SAP notes 2003863 and 2088315) and sizing (see https://www.sap.com/about/benchmark/sizing.html -> Sizing Guidelines -> Analytics -> EPM: SAP Business Planning and Consolidation) u-6tb1.112xlarge Workload (Scale-out up to 4 nodes: 1 master, 3 worker and NO standby node) OLTP (incl. S/4 HANA) Workload (Scale-out up to 16 nodes) OLAP (incl. BW/4HANA & BWoH) u-12tb1.112xlarge Workload (Scale-out up to 4 nodes: 1 master, 3 worker and NO standby node) OLTP (incl. S/4 HANA) 参照リンク：https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=iaas;ve:23