1. はじめに
前回、VPC・EC2・RDS・ELB・S3の5サービスについて、それぞれの役割とハンズオンで行ったことを整理しました。その後も学習を進め、DNS・CDN・セキュリティ・運用ツールと、扱うサービスの幅が広がってきました。
今回は、Route 53・CloudFront・WAF・AWS CLI・AWS SDKについて、前回と同じ形式で「どんなサービスか」「ハンズオンで行ったこと」を整理します。
CLIとSDKは厳密には「AWSサービス」ではなく「AWSを操作する手段」なので、今回は「サービス編」と「運用ツール編」に分けてまとめます。
2. サービス編
2-1. Route 53
・Route 53とは
DNS（ドメイン名などからリソースの名前解決を行う仕組み）を提供するマネージドサービスです。
ドメインの取得から、レコードの管理、複数のルーティングポリシーの利用までを、GUI・CLI・CloudFormationのいずれからでも操作できます。SLAは100%と定義されており、条件を満たさない場合はサービスクレジットが提供されます。
主なレコードタイプは以下の通りです。
| レコード | 役割 |
|---|---|
| Aレコード | ドメインとIPアドレスを対応させる。Route 53ではエイリアス機能でALBやCloudFrontのDNS名を直接指定できる |
| NSレコード | ドメイン名の解決に必要なネームサーバー情報を指定する |
| SOAレコード | ドメインの責任者などの管理情報を格納する |
| CNAMEレコード | ドメインの別名をマッピングする(例：ACMでのドメイン所有確認) |
・ハンズオンで行ったこと
- Route 53のレジストラでドメインを取得(1年分の料金が発生。登録完了まで15〜20分ほど待機)。登録完了後、ホストゾーンが自動作成され、NSレコード・SOAレコードが追加されていることを確認
- 取得したドメインに「simpleblog」というサブドメインでAレコードを作成し、エイリアスを有効化してALB(Application Load Balancer)のエンドポイントを指定。サブドメインでアクセスするとSimple Blogが表示されることを確認(シンプルルーティング)
- ALBをPrimary、S3の静的WebサイトをSecondaryとしてフェイルオーバールーティングを設定。PrimaryのALBについては「Evaluate Target Health」を有効にし、ALBのターゲットヘルスに応じてRoute 53がPrimary/Secondaryを切り替える構成にしました。
sudo systemctl stop httpd
Webサーバーを疑似的に停止させたところ、DNSキャッシュなどの影響でしばらく502エラーが表示されましたが、時間をおいてリロードするとSorryページへフェイルオーバーすることを確認しました。Apacheを再起動すると、しばらくして元のALB側に切り戻る(フェイルバック)ことも確認しました。
- 検証後は、セカンダリー側のAレコードを削除し、ルーティングポリシーをシンプルルーティングに戻した上で、Sorryページ用のS3バケットも削除
ルートテーブルによってサブネットからの通信経路が決まるのと同じように、DNSのルーティングも「設定した条件に応じて名前解決先を切り替える」という仕組みを実際に確認できました。
2-2. CloudFront
・CloudFrontとは
AWSのCDN(コンテンツデリバリーネットワーク)マネージドサービスです。
Webサーバーの前段に配置し、コンテンツをキャッシュすることでサーバー負荷を下げ、ユーザーへのレスポンスも高速化します。世界中のエッジロケーションでキャッシュを提供するため、特定のリージョンに紐づかない「グローバル」なリソースである点が、これまで扱ってきたEC2やRDSと異なります。設定の中心は「オリジン(配信元)」と「ビヘイビア(パスごとの振る舞い)」の2つです。
・ハンズオンで行ったこと
- カスタムキャッシュポリシー(TTL 15秒、検証用の値)を作成し、オリジンをALBのみとしてディストリビューションを作成(ビヘイビアにはキャッシュを有効にした設定を適用)
- 開発者ツールのネットワークタブで「x-cache」ヘッダーを確認し、Miss/Hit/RefreshHitの違いを確認。画像もページ本体(DB経由)も一律キャッシュされてしまう課題が判明
- 画像配信用のS3バケットをオリジンに追加。オリジンアクセスコントロール(OAC)を設定し、CloudFront経由のみアクセス許可となるようS3バケットポリシーを更新
- /images/* に一致するパスにのみキャッシュポリシーを適用するビヘイビアを作成し、デフォルトのビヘイビア(それ以外のパス)はキャッシュしない設定(CachingDisabled)に変更
- 画像を差し替えてアップロードし、TTL経過前後のアクセスでMiss/RefreshHit/Hitの違いを確認。RDSのレコードの画像パスをCloudFrontのディストリビューションドメイン名に変更し、Simple Blog経由でもキャッシュが効くことを確認
- (オプショナル)ディストリビューションに代替ドメイン名を追加し、ACM(AWS Certificate Manager)でパブリック証明書をリクエスト。Route 53でDNS検証用レコードを作成し、発行された証明書をディストリビューションに割り当て。Route 53のAレコードをALBからCloudFrontへのエイリアスに変更し、ビヘイビアの「Viewer Protocol Policy」をHTTPS必須(Redirect HTTP to HTTPS)に変更
画像はキャッシュされ、動的なページ本体はキャッシュされない、という意図した挙動を実際に確認できました。キャッシュTTLの設計は短すぎても長すぎてもダメで、ビジネス要件と照らし合わせて設計する必要があること、CloudWatchでの監視や人気オブジェクトレポートを使った定期的な見直しも大切だということを学びました。
2-3. WAF
・WAFとは
Webアプリケーションファイアウォールのマネージドサービスです。
CloudFrontやALBと連携し、リクエストをルールに基づいて許可・拒否できます。独自ルールに加え、あらかじめ用意されたマネージドルール(コアルールセット、Botコントロールなど)も利用できます。
・ハンズオンで行ったこと
- 自分の作業環境(CloudShell)のIPアドレスをIPセットとして登録
- Web ACLを作成し、CloudFrontディストリビューションに関連付け。「IPセットに一致したら拒否(Block)」というカスタムルールを追加
curl https://<ディストリビューションドメイン名>
ブラウザからのアクセスは許可される一方、登録したIPアドレス(CloudShell)からのcurlは403エラーで拒否されることを確認しました。
- マネージドルールグループ(AWSマネージドルールなど)の存在も確認
- 検証後、Web ACLの関連付けを解除し、Web ACL・IPセットを削除
IPアドレスでのブロックだけでなく、マネージドルールを使えば既存のルールセットをそのまま適用できることも分かり、運用の負担を抑えられそうだと感じました。
3. 運用ツール編
3-1. AWS CLI
・AWS CLIとは
コマンドラインからAWSリソースを操作できるツールです。
全てのコマンドを覚える必要はなく、公式ドキュメントを都度参照しながら使うのが基本的な進め方です。「AWS CLI + サービス名」で検索してドキュメントを開き、Examplesを参照しながら必須/任意パラメータを確認する、という調べ方の型で進めました。
・ハンズオンで行ったこと
aws ec2 stop-instances --instance-ids <instance-id>
aws ec2 create-image --instance-id <instance-id> --name WebAMIfromCLI
aws ec2 start-instances --instance-ids <instance-id>
マネジメントコンソールで行っていた「EC2の停止→AMI作成→起動」の一連の操作を、コマンドラインから実行できることを確認しました。
aws s3 mb s3://<バケット名>
続くSDKハンズオンで使うファイル連携用のS3バケットも、CLIから作成しました。
「AWS CLI + サービス名」で検索してドキュメントを開き、Examplesを見ながら試行錯誤する、という調べ方の型が身についたのが一番の収穫でした。
3-2. AWS SDK(boto3)
・AWS SDKとは
プログラミング言語に組み込んで使えるライブラリ群です。
Python用のSDKはboto3と呼ばれ、コード上からEC2やS3などのAWSリソースを操作できます。
・ハンズオンで行ったこと
- パブリックサブネットにバッチサーバー用のEC2インスタンスを作成し、RDS用セキュリティグループにバッチサーバー用セキュリティグループからのMySQL通信を許可
- Python3(3.9系)を確認し、pip・boto3・MySQLコネクタをインストール
import boto3
s3_client = boto3.client('s3')
s3_client.download_file(
'バケット名', 'course_data.csv', 'course_data.csv'
)
boto3を使ってS3からCSVファイルをダウンロード。最初は認証情報(クレデンシャル)がなくエラーになりましたが、IAMユーザーのアクセスキーを発行しaws configureでEC2上に設定することで解決しました。
- GitHubからサンプルコード(MySQLコネクタを使ってRDSに接続する処理)を取得し、RDSのエンドポイントのみ書き換えて使用。postテーブルをTRUNCATEした後、取得したCSVの内容でINSERTし直すバッチ処理を実行(RDS接続部分はSDKではなくMySQLプロトコルによる直接接続)
- Simple Blogをリロードし、新しいレコードが反映されていることを確認
- ハンズオンで発行したIAMアクセスキーは、検証後に無効化した上で削除
IAMユーザーのアクセスキーを使った認証は動作したものの、長期的な認証情報をEC2上に配置する方法は漏洩リスクがあるため推奨されないことを学びました。より安全な方法として、EC2自体に権限を割り当てる「IAMロール」があるとのことなので、次回のIAM学習で試してみたいと思います。
4. まとめ
今回は、Route 53・CloudFront・WAFの「サービス編」と、AWS CLI・AWS SDKの「運用ツール編」に分けて、ハンズオンで行ったことを整理しました。
Route 53でドメインを取得してALBに名前解決し、CloudFrontでキャッシュを効かせ、WAFでアクセスを制御する。ここまでで、Webシステムを外部に公開する際に押さえておきたい「配信」と「防御」の基本が一通り揃った感覚があります。
また、CLIとSDKに触れたことで、これまでマネジメントコンソールで手作業していた操作をコマンドやコードに置き換えられることも実感できました。特にSDKでのアクセスキーの扱いは、セキュリティ面でまだ改善の余地があると感じたので、次回のIAM学習でIAMロールについて学び、より安全な権限管理の方法を身につけたいと思います。