こんにちは、ゆーろんです。 今回は今回はレンタルサーバで動いていた当ブログ(yuuronacademy.com)をAWSのLightSail上に移動(お引越し)させたので、そのことに関してお話ししようと思います。 目次 使用したAWSのサービス LightSail CloudFront Route53 ACM 構築したアーキテクチャ 構築にあたっての小話 使用サービス サービス システム 基盤環境 アクセス解析 今後に関して 使用したAWSのサービス まず、今回利用したAWSのサービスに関して簡単に説明します。 LightSail AWS LightSailはAWSが提供しているVPS（仮想プライベートサーバ）です。 仮想マシンのEC2と異なり、VPCやサブネット等の作成も不要で、月額料金なためコスト見積もりしやすい特徴があります。 CloudFront AWS CloudFrontはAWSが提供しているCDN(コンテンツデリバリネットワーク)です。 サイトコンテンツ(静的・動的なウェブコンテンツ、ビデオ、アプリケーションデータなど)をAWSの管理する世界中のエッジサーバに配置することで効率的にデータを配信することができます。 CDNとは キャッシュサーバなどで構成されたシステムを用いることによって、Webサイト上のコンテンツを迅速にユーザに届けるための仕組み。 通常のWebサイトでは、コンテンツを配信するためのサーバの処理能力やネットワークの帯域幅などの影響で、沢山のユーザーがWebサイトにアクセスするとレスポンスが低下する。 また、物理的に離れた場所からのアクセスに対してネットワーク遅延によりレスポンスが低下する場合がある。そういったものに対処するための仕組みといえる。 Route53 AWS Route53はAWSが提供しているDNS(Domain Name System)です。 Route53ではドメインの登録やDNS、ロードバランサの機能などサイトアクセスのための様々なDNS機能を提供しています。 ゆーろん Route53の名前の由来はDNSのポート番号が53だからなのかな？ ACM AWS Certificate ManagerはAWSが提供しているSSL/TLS証明書のサービスです。 AWS上でホストされるウェブサイトやアプリケーションに対して、暗号化通信を実現するためのSSL/TLS証明書の取得、管理、自動更新を行うことができます。 構築したアーキテクチャ 今回AWSで構築したリソースのインフラ構成図は概ね以下の通りです。 見ての通りLIghtSail+CloudFrontの構成となっています。 HTTPS化にALBの利用などをする方法もありますが、料金を抑えるためにCloudFrontでSSL終端を行う構成にすることにしました。 SSL終端構成により「サーバへ直接クライアントのアクセスをさせない」、「CloudFrontによるキャッシュ/高速化」を実現しています。 またサイトへのアクセスステップは以下のようになっています。 HTTPSによるアクセス(:443) Route53 CloudFront(:80) Route53 Static IP(Lightsail) 構築にあたっての小話 サイトのインフラ基盤の管理にあたって当初Terraformを利用することを計画し、以下のように実行可能なコードを作成をしました。 GitHub - yuron3141/aws-lightsail-tf: This repo is to create the wp lightsail instance with the terraform. GitHub This repo is to create the wp lightsail instance with the terraform. - yuron3141/aws-lightsail-tf 上記コードをAWS Cloud9上で利用し.tfstateはS3で管理するというものです。

こんにちは。ゆーろんです。 12/4に友人と共用で使用するAmazon EC2を作成しました。 苦労した部分や前回EC2を建てたときとの違いや新たな発見や実装内容を記録しておきます。 目次 インフラ構成図 今回の構築で新しく取り組めた内容 AWSに関して Linux(Amazon Linux)に関して まとめと反省点 インフラ構成図 今回作成したEC2のアーキテクチャ図は以下のような感じです。 以前EC2でマイクラサーバを構築した際はELBやCloudWatchは利用しませんでした。 今回の構築で新しく取り組めた内容 今回の構築ではNLBとFlow logを使用しました。 AWSに関して 私だけではなく友人もEC2を停止・起動、なお且つEC2に入れる必要があったため初めてIAMのユーザを作成しました。IAMユーザ(EC2と停止,起動のみの権限)の作成とセキュリティグループの設定は比較的スムーズにできました。 またNLBとFlow Logsをインフラ構築に導入した理由は、EC2へ入ってくる通信を監視するためです。これによりEC2にアクセスをAWSコンソール上で監視できるためです。 Linux(Amazon Linux)に関して EC2には当初「Ubuntu22.04LTS」を入れてましたが、このディストリビューションではssh-rsa がデフォルトで無効になっているためTeraTermでアクセスする際のRSA鍵がうまく認証されませんでした。 修正するにはPowershellからSSH接続で入り、ssh-rsaを有効にする必要がありましたが、それを知ったのは「Amazon Linux」に変えた後でした… 結局RSA鍵で詰まって、以前構成したEC2と同じくAmazon Linuxを入れました。 ちなみにAmazon LinuxはRedHat / CentOS7系のディストリビューションと言われています。そのためPackage管理コマンドはaptではなくyumになります。 また今回初めてLinuxOS内で他のユーザやRSA鍵を生成しました。これによりユーザごとのディレクトリにファイルやディレクトリが構築できるので個人性を持った開発ができると思います。 まとめと反省点 今回は以前EC2を建てたときよりも、インフラ構成やネットワークの知識、Linuxの操作を以前より意識して組むことができたと思います。 ただ構築とLinux内の設定に5,6時間かかってしまったので、もっとAWSやネットワークを理解そしてAWSコンソールに慣れていきたいと思います。 ここまでご覧くださり、ありがとうございました。