AWS

SAAの模試で、DynamoDBを使用してリアルタイムデータ処理を行うWebアプリケーションの構築方法という問題で間違えてしまいました。 AppSyncを使うのが正解らしいのですが、AppSyncってなんぞ！？となったので調べました。 AppSyncとは AWS AppSync は、サーバーレスの GraphQL および Pub/Sub API を作成し、単一のエンドポイントを通じて安全にデータの照会、更新、公開を行うことで、アプリケーションの開発を簡素化します。 サーバーレス GraphQL および Pub/Sub APIs – AWS AppSync – アマゾン ウェブ サービス な、なんか凄そう。 AWSAppSync開発者は、安全でサーバーレスの高性能なGraphQLおよびPub/Sub APIを使用して、アプリケーションやサービスをデータやイベントに接続できます。以下を実行すると、AWSAppSync次の操作を実行できます。 1 つの GraphQL API エンドポイントから 1 つ以上のデータソースのデータにアクセスする。 複数のソースの GraphQL API を 1 つの統合された GraphQL API に結合します。 リアルタイムのデータ更新をアプリケーションに公開します。 組み込みのセキュリティ、モニタリング、ロギング、トレースを活用し、オプションのキャッシュにより低レイテンシを実現できます。 お支払いいただくのは、API リクエストと配信されたリアルタイムメッセージに対してのみです。 AWS AppSync とは - AWS AppSync GraphQL つまり、AppSyncとは「フルマネージドなGraphQLのためのサービス」と言えるでしょう。 （Pub/Sub APIというのはGraphQL WebSocketのことを言っているようです） しかしDynamoDBとAppSyncだけでGraphQLかPub/SubAPIの作成ができるのは結構すごいですね。 （DynamoDB + API Gateway + LambdaでAPI組むより遥かに楽そう） お値段は次の要素で決まるようです。 クエリとデータ変更操作 4.00USD/クエリおよびデータ変更操作 100 万回 リアルタイム更新 2.00USD/リアルタイムアップデート 100 万回 0.08USD/AWS AppSync サービスへの接続 100 万分 キャッシュ データ処理速度を更に加速させる 次の表の通り キャッシュで使用するインスタンスタイプの料金表 料金例は一ヶ月21.29USDとなっており、結構お手頃価格です。 ...

SAA勉強中の備忘録。 EC2インスタンスの削除時にEBSボリュームの削除を行わないようにする EC2の「DeleteOnTermination」というオプションをオフにすればよいです。（デフォルトではオン） Amazon EC2 インスタンスの終了時に EBS ルートボリュームを保持する | AWS re:Post EC2の作成画面では、ボリューム設定の「終了時に削除」という項目がそれに当たります。 ボリュームの設定 感想 むしろデフォルトでオフにしてほしいが、重要なEC2インスタンスを作成する場合などは注意して設定しましょう。

SAA勉強中の備忘録。 ELBにある機能の一つであるConnection Drainingがピンとこなかったので。 Connection Drainingとは 登録解除された、もしくは異常のあるターゲットに対するリクエストを切断するまでの待機時間を設定する機能です。 1 - 3600秒(1時間)まで選択でき、デフォルトでは300秒になっています。 既存のリクエストを完了させ、待機時間中は新規リクエストを対象のターゲットには送らないようにすることで、唐突なリクエストの切断といった事象を防ぎます。 また、この機能はCLB特有の機能です。 ALB、NLBの場合は「Deregistration Delay」という機能がこれと同等の機能を有しています。 Application Load Balancer のターゲットグループ - Elastic Load Balancing 参考 ELB Connection Draining – Remove Instances From Service With Care | AWS News Blog

SAA勉強の備忘録。 オンデマンドキャパシティ予約とは EC2インスタンスを起動するのに必要な領域を予約する機能です。 キャパシティ予約の作成 - Amazon Elastic Compute Cloud これをしないと、「InsufficientInstanceCapacity」というエラーでインスタンスが起動できないことがあるため、注意が必要です。 EC2 インスタンスで発生する InsufficientInstanceCapacity エラーを解決する | AWS re:Post また、セットで語られるのが多い機能として「リザーブドインスタンス」と「Saving Plans」があります。 ただしこの２つとオンデマンドキャパシティ予約を同様のものとしてはいけません。 「リザーブドインスタンス」「Saving Plans」は、1年もしくは3年という単位でコンピュータリソースを購入する際の割引プランというふうに思ってください。 また、かつてEC2には、スケジュールドリザーブドインスタンスというものがありました。 これは、予め指定した時間に起動できるEC2インスタンスを１年間継続的に使用するための機能です。 1年間インスタンスが使用可能になる分、オンデマンドより柔軟性はなくなりますが、その代わり割引しますよ、というものです。 Amazon EC2 の請求および購入オプション - Amazon Elastic Compute Cloud ただし、現在は使用できなくなっています。 リザーブドインスタンスとは オンデマンドインスタンスと比較して、割引を適用できる機能です。 Amazon EC2 のリザーブドインスタンスの概要 - Amazon Elastic Compute Cloud リザーブドインスタンスの適用範囲として、以下の２種類があります。 リージョンリザーブドインスタンス リージョン内で１年または３年単位のコミットメントが必要で、長いほど割引率が高い キャパシティ予約なし 指定リージョンのすべてのAZで割引が適用される ゾーンリザーブドインスタンス AZ内で１年または３年単位のコミットメントが必要で、長いほど割引率が高い キャパシティ予約あり また、リザーブドインスタンスには「スタンダード」クラスと「コンバーティブル」クラスが存在します。 これらは提供クラスと呼ばれ、コンバーティブルの場合は購入後でも「インスタンスファミリー、インスタンスタイプ、OS、テナンシー」の要素を変更可能になります。 リージョンリザーブドインスタンスの購入画面 ゾーンリザーブドインスタンスの購入画面 購入画面を見るとわかりますが、やはりコンバーティブルのほうが高いです。 Saving Plansとは こちらも同じく、コンピュータリソースの予約をすることで割引してくれる機能です。 クラウドコストの削減 – Savings Plans – Amazon Web Services ...

まだ「完全に理解した」みたいな状態で書いていないので悪しからず。。 （理解したとは言っていない） もし間違っている部分あればコメントして頂けると嬉しいです。 とは Direct Connect - AWS Direct Connect 目次 目次 構築手順 1. Direct Connectを使用するためのConnectionを作成する 2. 仮想プライベートゲートウェイを作成する ASN（自律システム番号）とは BGP（ボーダーゲートウェイプロトコル）とは 3. 仮想インターフェースを作成する VLAN（仮想ローカルエリア・ネットワーク）とは オンプレミスサーバーのASN 仮想インターフェース作成時のその他入力項目 4. ルートテーブルに作成した仮想プライベートゲートウェイを設定する 5. セキュリティグループにDirect Connectで使用するIPを設定する 感想 参考 構築手順 なにはともあれ、実際にどうやって構築するのか見てみます。 このブログに丁寧にまとめられていました。 https://oji-cloud.net/2019/12/18/post-3759/ この手順をまとめると、以下のようになります。 Direct Connectを使用するためのConnectionを作成する 仮想プライベートゲートウェイを作成する 仮想インターフェースを作成する ルートテーブルに作成した仮想プライベートゲートウェイを設定する セキュリティグループにDirect Connectで使用するIPを設定する 公式に乗っているフローはこんな感じ。 AWS Direct Connectとオンプレネットワークがどのように連結されるかを大まかに表した図 それぞれの手順にポイントがあります。 1. Direct Connectを使用するためのConnectionを作成する コネクションの作成方法として、「専用接続」と「ホスト型接続」の２種類があります。 AWS Direct Connectとは？基本を解説！メリット・デメリットから利用方法まで｜ブログ｜アイテック阪急阪神ITインフラ・クラウドソリューション それぞれ以下のような特徴があります。 専用接続 専用の物理回線を引く 複数のVPCを使用する場合、料金コストはこちらのほうがよい ホスト型接続 一つの物理回線をシェアする 一つのVPCであればこちらのほうが料金コストはよい また、契約方法も２種類存在します。 直接契約 AWSとDirectConnectを直接契約する 回線引き込みやネットワーク設定など全て自分でやる必要がある 自身がAPNパートナーになる場合はこちら APNパートナーと契約 APNパートナーが代理人となり、各種セッティングを行ってくれる パートナーごとに専用接続・ホスト型接続への対応状況は異なる パートナー一覧はここを確認 直接契約の場合は結構作業が大変なので、通常は「APNパートナーと契約」してConnectionを作成します。 ...

SAAの問題で、ELB（Elastic Load Balancer）についての問題に躓いた。 そのため備忘録として残しておきます。 クロスゾーン負荷分散とは 複数のAZにまたがってサーバーが存在する場合に、すべてのサーバーに均等にリクエストを振り分ける機能です。 以下の図はクロスゾーン負荷分散が無効の場合のアーキテクチャです。 「Availability Zone A」には２つのサーバーがあり、それぞれに25％ずつリクエストの振り分けが行われます。 一方で「Availability Zone B」のサーバーは8つもあり、各サーバーは6.25％しかリクエストが振り分けられていません。 サーバーは合計して10個ありますが、均等にリクエストが振り分けられていないような状態になっています。 ここで、クロスゾーン負荷分散を有効にしてみます。 すると、AZ関係なくすべてのサーバーに10%ずつリクエストが振り分けられるようになりました。 これがクロスゾーン負荷分散の仕組みです。 どういう問題だった？ 複数のAZにまたがって複数のEC2インスタンスを起動していて、ELBを使用してどうやって均等にリクエストを割り振るかといった問題でした。 クロスゾーン負荷分散という機能を知らず、選択肢の中にRoute53の加重ルーティングを使用するというものがあり、それを選択してしまいました。。悔しい〜 参考 Elastic Load Balancing の仕組み

まずは以下の表をご覧ください。 このIOPSの値とかが結構SAAで問題として出題されるんですが、これが難しい。。 Amazon EBS ボリュームの種類 どうしたもんかと思ったんですが、問題で出されるときはIOPSとスループットが最適なストレージはどれかというものが多いので、その２点に絞ってまとめていきます。 IOPSだけで考える IOPSだけで考えると、その性能は以下のような順番に並べ変えられます。 io2 Block Express(256,000) »» io2 == io1 (64,000) »» gp3 == gp2 (16,000) »» st1 (500) »» sc1 (250) なんかどんどんインフレしていますね。 （ドラゴンボールの戦闘力？） スループットだけで考える 同じように、スループットも並べ替えてみます。 io2 Block Express(4,000 MiB/秒) »» gp3 == io2 == io1 (1,000 MiB/秒) »» st1 (500 MiB/秒) »» gp2 == sc1 (250 MiB/秒) 面白いことに、gp2（旧世代の汎用SSD）とsc1（コールドストレージ）のスループットが同じという結果になりました。 そもそもIOPSとスループットってなんだっけ？ ここまでやっていて、そもそもの言葉の定義を忘れてしまったので再度まとめておきます。 IOPS（Input/Output Per Second）：1秒あたりにディスクが処理できるI/Oアクセス数のこと スループット：単位時間（上記の場合は秒）あたりに処理できるデータ量のこと スループット とは ストレージのIOPS性能がアプリケーションに与える重要性 まとめ 基本的な概念のはずなんですが、ちょっと離れるとすぐ忘れちゃいますね。。 気をつけねば。。

SAAの問題で間違えたため備忘録。 EC2でインスタンス生成をした際、DNS名が割り振られないことがあります。 その場合、マネジメントコンソールのVPCの設定から、以下の設定がされているか確認してください。 DNS解決を有効化が「true」 DNSホスト名を有効化が「true」 ただこの値、基本的にはどちらもtrueがデフォルトなので、何らかの意図があって編集していないと変更されません。 もしも変更されている場合は確認したほうが良いかもしれません。

SAAの試験勉強で間違えた問題がSCPについての問題だったので少しまとめました。 SCPとは SCP（サービスコントロールポリシー）は、AWS Organizationsにおける組織のアクセス制御に関する設定のことです。 一人のIAMユーザーがある組織に属していたとした場合で考えてみます。 そのIAMユーザーにはIAMポリシーとして「EC2」「RDS」「S3」へのフルアクセス権限が振られていたとします。 しかし、このIAMユーザーの所属する組織のSCPでは「EC2」「ECS」「CloudWatch」のフルアクセス権限が振られています。 この場合どうなるかというと、「EC2」へのフルアクセスのみ可能になります。 ベン図にするとわかりやすいです。 このような形で権限の制御は行われるので、アクセス制御の設計を行う際は気をつけねば。。

NATゲートウェイってどこに設置するんだっけ…？となったので。 NAT ゲートウェイを設定してみる - EC2 NATゲートウェイとは プライベートサブネットに配置されたリソースがインターネットに安全にアクセスするための方法です。 NATゲートウェイを設置することで、リソースは直接インターネットに晒されることなく安全に更新データなどのリクエストが可能になります。 使い方 まずNATゲートウェイはパブリックサブネットに設置します。 次に、プライベートサブネットのルートテーブルに、設置されたNATゲートウェイへのルートを追加します。 これでプライベートサブネットはNATゲートウェイを通じてインターネットにリクエストすることができるようになります。 NATゲートウェイだけでインターネットアクセスができる？ 踏み台となるサーバーがなければできません。 インターネットにアクセスするまでのフローはこんな感じです。