ＨＯＭＥ ＞ AWS(Amazon Linux)
AWS(Amazon Linux)
AWS(Amazon Linux)：記事リスト
AWS(Amazon Linux)のカテゴリーには以下の記事がリストされています。
AWS EKSでKubernetesクラスターをマルチAZ構成で設計する方法｜マネージドノードグループとVPC設計の実践
「EKSのノードグループをマルチAZにするには、どう設定すればいいのか？」
AWSでEKS（Elastic Kubernetes Service）を本番運用しようとすると、避けて通れないのがこの問いです。
EKSのコントロールプレーン（APIサーバー・ etcd など）はAWSが3つのAZに自動で冗長化してくれます。しかしワーカーノード（データプレーン）は、ClusterConfig YAMLの設定を適切に書かないと1つのAZに偏ります。AWSの障害はAZ単位で発生するため、ノードが1つのAZに集中していると、そのAZが落ちた瞬間にPodが全滅し、サービスが停止します。
この記事では、eksctlを使ってEKSクラスターをマルチAZ構成で設計する実践手順を解説します。VPCサブネットの設計要件、ClusterConfig YAMLの書き方、ノードグループのAZ分散設定、そしてIRSA（IAM Roles for Service Accounts）にPodへの最小権限付与まで、実際の設定ファイルと出力例を交えながら紹介します。
AWSでEKS（Elastic Kubernetes Service）を本番運用しようとすると、避けて通れないのがこの問いです。
EKSのコントロールプレーン（APIサーバー・ etcd など）はAWSが3つのAZに自動で冗長化してくれます。しかしワーカーノード（データプレーン）は、ClusterConfig YAMLの設定を適切に書かないと1つのAZに偏ります。AWSの障害はAZ単位で発生するため、ノードが1つのAZに集中していると、そのAZが落ちた瞬間にPodが全滅し、サービスが停止します。
この記事では、eksctlを使ってEKSクラスターをマルチAZ構成で設計する実践手順を解説します。VPCサブネットの設計要件、ClusterConfig YAMLの書き方、ノードグループのAZ分散設定、そしてIRSA（IAM Roles for Service Accounts）にPodへの最小権限付与まで、実際の設定ファイルと出力例を交えながら紹介します。
この記事のポイント
・EKSのマルチAZ設計はノードグループのAZを3つに分散させることが基本
・eksctlのClusterConfig YAMLでVPC・ノードグループの設定を一括定義できる
・プライベートサブネットにはEKS用タグ（kubernetes.io/role/internal-elb: 1）の設定が必須
・PodへのAWS権限はIRSA（IAM Roles for Service Accounts）で最小権限を実現する
続きを読む "AWS EKSでKubernetesクラスターをマルチAZ構成で設計する方法｜マネージドノードグループとVPC設計の実践"
AWS CloudFormationでインフラをコード管理する方法｜テンプレートの基本構造とマルチAZ構成パターン入門
「AWSのリソースをマネジメントコンソールで手作業で作り続けていると、本番と検証で設定が違う、先月誰かが触って壊れた、復旧しようにも手順書がない——そんな問題が積み重なっていませんか？」
AWS CloudFormationはAWSが公式に提供するInfrastructure as Code（IaC）ツールです。YAMLまたはJSON形式のテンプレートファイルにAWSリソースを宣言的に記述することで、VPCからEC2・ALBに至るまで、複雑なマルチAZ構成を再現性高く構築できます。
この記事では、CloudFormationテンプレートの基本構造から、VPC・サブネット・ALB・Auto Scalingを含むマルチAZ構成のテンプレート化、
AWS CloudFormationはAWSが公式に提供するInfrastructure as Code（IaC）ツールです。YAMLまたはJSON形式のテンプレートファイルにAWSリソースを宣言的に記述することで、VPCからEC2・ALBに至るまで、複雑なマルチAZ構成を再現性高く構築できます。
この記事では、CloudFormationテンプレートの基本構造から、VPC・サブネット・ALB・Auto Scalingを含むマルチAZ構成のテンプレート化、
aws cloudformationコマンドによるスタック操作まで、実機確認結果とともに解説します。Amazon Linux 2023 / RHEL 9.4環境で動作確認済みです。
この記事のポイント
・CloudFormationのテンプレートはResources（必須）・Parameters・Outputsの3セクションが基本
・VPC + マルチAZサブネット + ALBの冗長構成は1つのYAMLテンプレートで定義できる
・aws cloudformation deployコマンドで変更セットを確認してから安全に更新できる
・スタック削除時の誤消去はDeletionPolicyとTerminationProtectionで防ぐ
続きを読む "AWS CloudFormationでインフラをコード管理する方法｜テンプレートの基本構造とマルチAZ構成パターン入門"
AWSのClient VPNでリモートワーカーをVPCにセキュアに接続する方法｜エンドポイント設計と認証・ルーティングの実践
「リモートからVPC内のEC2に直接アクセスしたいが、踏み台サーバーを立てずに済む方法はないか」
「開発チームのメンバー全員にVPNアクセスを配布したいが、どこで設定すればいいのか分からない」
こうした課題を解決するのがAWS Client VPNだ。Site-to-Site VPNがオンプレミスのネットワーク全体をVPCに接続するのに対し、Client VPNはエンジニアのPCなど個々のデバイスからVPCへのリモートアクセスを実現する。
この記事では、Client VPNのエンドポイント設計・証明書の準備・ルーティング設定・動作確認まで実践的な手順を解説する。スプリットトンネルとフルトンネルの使い分け、マルチAZでの冗長設計ポイントも含めて解説するので、セキュアなリモートアクセス環境を設計する際の参考にしてほしい。動作確認はAWS CLI（v2.15）＋Ubuntu 24.04 LTS上のOpenVPN 2.6で実施した。
「開発チームのメンバー全員にVPNアクセスを配布したいが、どこで設定すればいいのか分からない」
こうした課題を解決するのがAWS Client VPNだ。Site-to-Site VPNがオンプレミスのネットワーク全体をVPCに接続するのに対し、Client VPNはエンジニアのPCなど個々のデバイスからVPCへのリモートアクセスを実現する。
この記事では、Client VPNのエンドポイント設計・証明書の準備・ルーティング設定・動作確認まで実践的な手順を解説する。スプリットトンネルとフルトンネルの使い分け、マルチAZでの冗長設計ポイントも含めて解説するので、セキュアなリモートアクセス環境を設計する際の参考にしてほしい。動作確認はAWS CLI（v2.15）＋Ubuntu 24.04 LTS上のOpenVPN 2.6で実施した。
この記事のポイント
・AWS Client VPNで個々のデバイスからVPCへセキュアに接続できる
・相互TLS認証ではEasy-RSAで証明書を発行しACMに登録する
・スプリットトンネルを有効にするとVPC宛の通信のみVPN経由になる
・複数AZのサブネットに関連付けることで冗長性を確保できる
続きを読む "AWSのClient VPNでリモートワーカーをVPCにセキュアに接続する方法｜エンドポイント設計と認証・ルーティングの実践"
AWSのCI/CDパイプライン設計｜CodePipeline・CodeBuild・CodeDeployでBlue/Greenデプロイを自動化する構成パターン入門
「コードを本番サーバーにデプロイするたびにSSHで入って git pull を実行し、アプリを再起動する。その数分間はサービスが止まる」。こうした手作業リリースを続けているシステムは、ヒューマンエラーと属人化のリスクを常に抱えています。
AWSにはこの問題を解消するCI/CDパイプラインのマネージドサービスが揃っています。CodePipeline・CodeBuild・CodeDeployを組み合わせることで、GitへのPushをトリガーにビルド・テスト・デプロイを自動化し、ECSのBlue/Greenデプロイでゼロダウンタイムのリリースを実現できます。
この記事では、3サービスの役割分担と全体アーキテクチャ、buildspec.ymlとappspec.ymlの設計パターン、そしてIAMロールとVPCの最小権限設計までを解説します。Linuxサーバー運用からAWSのインフラ設計に踏み出すエンジニアの入口として読んでください。
AWSにはこの問題を解消するCI/CDパイプラインのマネージドサービスが揃っています。CodePipeline・CodeBuild・CodeDeployを組み合わせることで、GitへのPushをトリガーにビルド・テスト・デプロイを自動化し、ECSのBlue/Greenデプロイでゼロダウンタイムのリリースを実現できます。
この記事では、3サービスの役割分担と全体アーキテクチャ、buildspec.ymlとappspec.ymlの設計パターン、そしてIAMロールとVPCの最小権限設計までを解説します。Linuxサーバー運用からAWSのインフラ設計に踏み出すエンジニアの入口として読んでください。
この記事のポイント
・CodePipeline・CodeBuild・CodeDeployの3役割を正しく理解して設計する
・buildspec.ymlとappspec.ymlがCI/CDパイプラインの動作を定義するコアファイル
・ECS Blue/Greenデプロイでゼロダウンタイムリリースと即座のロールバックを実現できる
・IAM権限ミスがパイプライン停止の最大原因、最小権限設計で事前に防ぐ
続きを読む "AWSのCI/CDパイプライン設計｜CodePipeline・CodeBuild・CodeDeployでBlue/Greenデプロイを自動化する構成パターン入門"
AWS Direct Connectでオンプレミスとの専用線接続を設計する方法｜VPNとの違い・仮想インターフェース・冗長構成パターン
「アクセス回線のVPNで繋いでいたオンプレとAWSの通信が、大量データ転送の時間帯にレイテンシが跳ね上がる」
「毎月のデータ転送コストが想定以上にかかっていて、どう改善すれば良いか分からない」
こういった相談は、AWSを本番稼働させているエンジニアからセミナーでもよく出てきます。Site-to-Site VPNは手軽に構築できますが、インターネット経由という構造上、帯域保証がなく転送コストも高くなりがちです。
この記事では、AWS Direct Connectの基本概念から、仮想インターフェース（VIF）の3種類の使い分け、BGP設定の要点、そして可用性要件に応じた冗長構成パターンまでを解説します。CLIの実行例も交えながら、実務判断に必要な内容を一気にカバーします。
「毎月のデータ転送コストが想定以上にかかっていて、どう改善すれば良いか分からない」
こういった相談は、AWSを本番稼働させているエンジニアからセミナーでもよく出てきます。Site-to-Site VPNは手軽に構築できますが、インターネット経由という構造上、帯域保証がなく転送コストも高くなりがちです。
この記事では、AWS Direct Connectの基本概念から、仮想インターフェース（VIF）の3種類の使い分け、BGP設定の要点、そして可用性要件に応じた冗長構成パターンまでを解説します。CLIの実行例も交えながら、実務判断に必要な内容を一気にカバーします。
この記事のポイント
・AWS Direct Connectは専用物理回線でAWSに直結し帯域が安定する
・VIFはPrivate・Public・Transitの3種類を用途で使い分ける
・本番環境はDX＋VPNのアクティブ・スタンバイ冗長構成が定石
・CLIのdescribe-*コマンドでBGP状態と接続状態を確認できる
続きを読む "AWS Direct Connectでオンプレミスとの専用線接続を設計する方法｜VPNとの違い・仮想インターフェース・冗長構成パターン"
AWS Global Acceleratorでマルチリージョン冗長化を設計する方法｜Anycast IPとエンドポイントグループの実践設定
「グローバルに展開しているWebサービスで、東京リージョンに障害が起きた時、大阪やシンガポールへ自動で切り替えたい。でもRoute 53フェイルオーバーはDNSキャッシュの関係で、切り替わるまで数分かかることがある」
AWS Global Acceleratorを使うと、2つの固定Anycast IPを持ちながら、AWSグローバルバックボーン経由でエンドポイントへルーティングできます。フェイルオーバーはネットワークレイヤーで完結するため約30秒以内に完了し、クライアント側の設定変更も不要です。
この記事では、Global AcceleratorのAnycast IPの仕組みとコンポーネント構成の解説から、AWS CLIを使ったアクセラレーター・リスナー・エンドポイントグループの作成手順、マルチリージョンActive-Passive冗長構成の設計パターンまで実践的に解説します。Amazon Linux 2023（ap-northeast-1 / ap-northeast-3）で動作確認済みです。
AWS Global Acceleratorを使うと、2つの固定Anycast IPを持ちながら、AWSグローバルバックボーン経由でエンドポイントへルーティングできます。フェイルオーバーはネットワークレイヤーで完結するため約30秒以内に完了し、クライアント側の設定変更も不要です。
この記事では、Global AcceleratorのAnycast IPの仕組みとコンポーネント構成の解説から、AWS CLIを使ったアクセラレーター・リスナー・エンドポイントグループの作成手順、マルチリージョンActive-Passive冗長構成の設計パターンまで実践的に解説します。Amazon Linux 2023（ap-northeast-1 / ap-northeast-3）で動作確認済みです。
この記事のポイント
・Anycast IPで最近傍のAWS PoPからバックボーン経由でルーティングする
・アクセラレーター→リスナー→エンドポイントグループ→エンドポイントの4階層で構成する
・固定IPのままフェイルオーバーは約30秒で完了（DNSキャッシュに依存しない）
・Route 53フェイルオーバーより高速な切り替えが必要な場面に向く
続きを読む "AWS Global Acceleratorでマルチリージョン冗長化を設計する方法｜Anycast IPとエンドポイントグループの実践設定"
AWS Site-to-Site VPNでオンプレミスとVPCをセキュアに接続する方法｜Customer GatewayとVGW・BGPフェイルオーバー設計の実践手順
「社内の監視サーバーからAWSのEC2にSSHしたいのに、インターネット越しはセキュリティ的にNGと言われた」
AWSを本番環境として本格活用しはじめると、必ず突き当たるのがこの壁です。オンプレミスの開発環境・監視ツール・CI/CDパイプラインとVPCを安全につなぎたい——そのニーズを実現するのが、AWSのSite-to-Site VPNです。
この記事では、オンプレミスネットワークとAWS VPCをIPsec VPNで暗号化接続するSite-to-Site VPNの仕組み・構成手順・BGPによる2本トンネルの自動フェイルオーバー設計まで、AWS CLIを使って実践的に解説します。Amazon Linux 2023 / RHEL 9.4で動作確認しています。
AWSを本番環境として本格活用しはじめると、必ず突き当たるのがこの壁です。オンプレミスの開発環境・監視ツール・CI/CDパイプラインとVPCを安全につなぎたい——そのニーズを実現するのが、AWSのSite-to-Site VPNです。
この記事では、オンプレミスネットワークとAWS VPCをIPsec VPNで暗号化接続するSite-to-Site VPNの仕組み・構成手順・BGPによる2本トンネルの自動フェイルオーバー設計まで、AWS CLIを使って実践的に解説します。Amazon Linux 2023 / RHEL 9.4で動作確認しています。
この記事のポイント
・Site-to-Site VPNは1つのVPN接続に2本のIPsecトンネルを持ち、AWSが冗長性を提供する
・BGPを使えばトンネル障害時に自動で経路切り替えが起きる（静的ルーティングは手動対応が必要）
・CGW・VGW・VPN接続の3ステップをCLIで構成しルート伝播で経路をVPCに伝える
・VpwTelemetryのStatusとAcceptedRouteCountでトンネルとBGPの状態を最初に確認する
続きを読む "AWS Site-to-Site VPNでオンプレミスとVPCをセキュアに接続する方法｜Customer GatewayとVGW・BGPフェイルオーバー設計の実践手順"
AWS VPC Flow LogsでVPCのネットワーク通信を可視化する方法｜S3・CloudWatch Logs連携と異常検知の設計パターン
「VPCに不審な通信が来ているような気がする——でも本当にセキュリティグループでブロックできているのか、後から確認する手段がない」
AWSでシステムを運用していると、こうした「見えない」不安を感じる場面があります。特にセキュリティインシデントが起きた後に「いつ・どこから・どのポートに対して通信があったか」を遡って調べられない状況は、運用上の深刻なリスクです。
AWS VPC Flow Logsは、VPCを流れるIPトラフィックの情報をS3またはCloudWatch Logsへ記録するマネージドサービスです。セキュリティグループやNACLによるACCEPT・REJECTの記録から、送信元IPアドレス・宛先ポートまで、VPCを通過するすべての通信を可視化できます。この記事では、AWS CLI 2.xで動作確認した手順をもとに、Flow Logsの有効化・レコードの読み方・実務での活用パターン・コスト設計まで解説します。
AWSでシステムを運用していると、こうした「見えない」不安を感じる場面があります。特にセキュリティインシデントが起きた後に「いつ・どこから・どのポートに対して通信があったか」を遡って調べられない状況は、運用上の深刻なリスクです。
AWS VPC Flow Logsは、VPCを流れるIPトラフィックの情報をS3またはCloudWatch Logsへ記録するマネージドサービスです。セキュリティグループやNACLによるACCEPT・REJECTの記録から、送信元IPアドレス・宛先ポートまで、VPCを通過するすべての通信を可視化できます。この記事では、AWS CLI 2.xで動作確認した手順をもとに、Flow Logsの有効化・レコードの読み方・実務での活用パターン・コスト設計まで解説します。
この記事のポイント
・aws ec2 create-flow-logsでVPC・サブネット・ENIの3レベルで有効化できる
・actionフィールドがREJECTの記録を絞り込むと不審アクセスを素早く特定できる
・S3送信はコストが低く長期保存向き、CloudWatch Logsはリアルタイム分析に強い
・traffic-type REJECTから始めて必要に応じてALLに拡張するのがコスト効率のよい設計
続きを読む "AWS VPC Flow LogsでVPCのネットワーク通信を可視化する方法｜S3・CloudWatch Logs連携と異常検知の設計パターン"
AWS NAT GatewayでプライベートサブネットのEC2をインターネットに接続する方法｜マルチAZ冗長設計とコスト最適化の実践手順
「プライベートサブネットのEC2から yum update を実行したら、インターネットに繋がらなくて困った」
AWSでVPCを設計するとき、セキュリティのためにEC2をプライベートサブネットに置くのは正解です。しかし、そのままではインターネットへのアウトバウンド通信ができず、パッケージのアップデートや外部APIへの接続が詰まってしまいます。
この記事では、プライベートサブネットのEC2をインターネットに接続するために使う「NAT Gateway」の仕組み・作成手順・マルチAZ冗長設計・コスト最適化まで、AWS CLIを使って実践的に解説します。Amazon Linux 2023 / RHEL 9.4 で動作確認しています。
AWSでVPCを設計するとき、セキュリティのためにEC2をプライベートサブネットに置くのは正解です。しかし、そのままではインターネットへのアウトバウンド通信ができず、パッケージのアップデートや外部APIへの接続が詰まってしまいます。
この記事では、プライベートサブネットのEC2をインターネットに接続するために使う「NAT Gateway」の仕組み・作成手順・マルチAZ冗長設計・コスト最適化まで、AWS CLIを使って実践的に解説します。Amazon Linux 2023 / RHEL 9.4 で動作確認しています。
この記事のポイント
・NAT GatewayはパブリックサブネットにEIPと共に作成する
・プライベートサブネットのルートに0.0.0.0/0→NAT GWを追加する
・可用性確保のためAZごとに1台のNAT Gatewayを配置する
・S3はGateway型VPCエンドポイントで迂回するとコスト削減できる
・VPC Flow Logsを有効にするとNAT GW障害の切り分けが格段に速くなる
続きを読む "AWS NAT GatewayでプライベートサブネットのEC2をインターネットに接続する方法｜マルチAZ冗長設計とコスト最適化の実践手順"
AWS VPCのサブネット設計入門｜パブリック・プライベート分離とルートテーブルをCLIで実装する方法
「パブリックサブネットとプライベートサブネットを分けないといけないのは分かるが、実際のCIDR設計やルートテーブルの書き方が分からない」「VPCを作ってEC2を置いたが、セキュリティ的に問題がないか不安だ」
こういう迷いは、AWS入門の最初の壁でもある。
VPCのサブネット設計は、AWSインフラのセキュリティと可用性を決める土台だ。ここの判断が曖昧なままだと、意図せずRDSがインターネットに露出したり、プライベートサブネット内のEC2からパッケージ更新ができなくなったりと、後から直すコストが高い問題に発展する。
この記事では、VPCのパブリック・プライベートサブネット分離の設計思想を整理し、AWS CLIを使った実装手順を段階的に解説する。CIDRブロックの設計から、インターネットゲートウェイ・NATゲートウェイの配置、ルートテーブルの設定、マルチAZ展開のパターンまで、実務判断の根拠を示しながら説明していく。
こういう迷いは、AWS入門の最初の壁でもある。
VPCのサブネット設計は、AWSインフラのセキュリティと可用性を決める土台だ。ここの判断が曖昧なままだと、意図せずRDSがインターネットに露出したり、プライベートサブネット内のEC2からパッケージ更新ができなくなったりと、後から直すコストが高い問題に発展する。
この記事では、VPCのパブリック・プライベートサブネット分離の設計思想を整理し、AWS CLIを使った実装手順を段階的に解説する。CIDRブロックの設計から、インターネットゲートウェイ・NATゲートウェイの配置、ルートテーブルの設定、マルチAZ展開のパターンまで、実務判断の根拠を示しながら説明していく。
この記事のポイント
・ルートテーブルの0.0.0.0/0がIGWを向いているかどうかで「パブリック」かが決まる
・プライベートサブネットのアウトバウンドはNATゲートウェイ経由で確保する
・NATゲートウェイ自体はパブリックサブネットに配置する（IGWが必要なため）
・aws ec2 create-subnetとルートテーブル設定でCLIから段階的に構成できる
AWS Network ACLとセキュリティグループで実装するVPCセキュリティ設計｜ステートレス・ステートフルの違いと2層防御の実践パターン
「セキュリティグループでHTTPSの443番ポートを許可したのに、EC2にアクセスできない。」
AWSのVPC設計に取り組み始めたエンジニアが最初にぶつかる壁のひとつです。原因を調べていくと、セキュリティグループとは別に「Network ACL」というファイアウォールが存在することに気づきます。
この記事では、VPCのセキュリティを支えるNetwork ACL（NACL）とセキュリティグループ（SG）の違いと、2層防御として組み合わせる設計パターンを解説します。Amazon Linux 2023 / RHEL 9.4での実機確認コマンドも交え、「SGで許可したのに繋がらない」エラーの切り分け手順まで説明します。
AWSのVPC設計に取り組み始めたエンジニアが最初にぶつかる壁のひとつです。原因を調べていくと、セキュリティグループとは別に「Network ACL」というファイアウォールが存在することに気づきます。
この記事では、VPCのセキュリティを支えるNetwork ACL（NACL）とセキュリティグループ（SG）の違いと、2層防御として組み合わせる設計パターンを解説します。Amazon Linux 2023 / RHEL 9.4での実機確認コマンドも交え、「SGで許可したのに繋がらない」エラーの切り分け手順まで説明します。
この記事のポイント
・NACLはサブネット単位のステートレスFW、SGはインスタンス単位のステートフルFWで役割が異なる
・ステートレスのNACLはインバウンド許可だけでは不十分、アウトバウンドも明示的に設定が必要
・「NACL=サブネット境界の入口制限」「SG=インスタンス間のきめ細かい通信制御」で役割を分ける
・「SGで許可したのに繋がらない」の原因はNACLのエフェメラルポート未許可であることが多い
続きを読む "AWS Network ACLとセキュリティグループで実装するVPCセキュリティ設計｜ステートレス・ステートフルの違いと2層防御の実践パターン"
AWS ACMとRoute 53でHTTPS化する方法｜無料SSL証明書の発行からALB適用・自動更新まで
「AWSでHTTPS化しようとしたら、ACMとRoute 53の設定がわからなくて止まってしまった」という声をよく聞きます。
HTTPS化の手順は、証明書の発行・DNS検証・ロードバランサーへのアタッチという複数ステップに分かれており、各サービスの役割を理解していないと途中で迷子になります。
この記事では、AWS Certificate Manager（ACM）とRoute 53を使った無料SSL証明書の発行から、ALBへのHTTPS（443）リスナー設定・自動更新の仕組みまで、実務で使える手順を解説します。EC2インスタンスへの直接証明書インストールではなく、ALBを介したマネージドHTTPS構成を前提としています。
HTTPS化の手順は、証明書の発行・DNS検証・ロードバランサーへのアタッチという複数ステップに分かれており、各サービスの役割を理解していないと途中で迷子になります。
この記事では、AWS Certificate Manager（ACM）とRoute 53を使った無料SSL証明書の発行から、ALBへのHTTPS（443）リスナー設定・自動更新の仕組みまで、実務で使える手順を解説します。EC2インスタンスへの直接証明書インストールではなく、ALBを介したマネージドHTTPS構成を前提としています。
この記事のポイント
・ACMはAWSが提供する無料SSL証明書マネージドサービスで、ALB・CloudFrontに適用できる
・Route 53のDNS検証でCNAMEレコードを追加すれば証明書の発行は最短数分で完了する
・ALBのHTTPS（443）リスナーにACM証明書をアタッチするだけでHTTPS化が完成する
・ACM証明書の有効期限は13ヶ月で、Route 53使用時は自動更新が有効になる
続きを読む "AWS ACMとRoute 53でHTTPS化する方法｜無料SSL証明書の発行からALB適用・自動更新まで"
AWS VPCエンドポイントでS3へプライベート接続する方法｜Gateway型・Interface型の違いとNATコスト削減設計
「NATゲートウェイの料金明細を見ると、S3へのデータ転送コストが予想以上にかさんでいる」
「プライベートサブネットのEC2からS3へ直接つなぎたいが、Gateway型とInterface型のどちらを使えばいいか分からない」
プライベートサブネット内のEC2がS3へアクセスする場合、デフォルトではNATゲートウェイを経由します。東京リージョンのNATゲートウェイはデータ処理料金として1GBあたり約$0.062が発生し、月に数百GBのS3転送があると無視できない出費になります。
この記事では、AWS VPCエンドポイント（Gateway型・Interface型/PrivateLink）を使ってS3へプライベート接続する設定手順を、実際のAWS CLIコマンドと出力例つきで解説します。両方の違いと選び方、NATゲートウェイのコストを大幅に削減できる設計パターン、オンプレミスや他VPCからのアクセスが必要なケースの設計判断、よくあるトラブルの対処法まで一通り説明します。
動作確認環境：Amazon Linux 2023 / AWS CLI 2.15 / 東京リージョン（ap-northeast-1）
「プライベートサブネットのEC2からS3へ直接つなぎたいが、Gateway型とInterface型のどちらを使えばいいか分からない」
プライベートサブネット内のEC2がS3へアクセスする場合、デフォルトではNATゲートウェイを経由します。東京リージョンのNATゲートウェイはデータ処理料金として1GBあたり約$0.062が発生し、月に数百GBのS3転送があると無視できない出費になります。
この記事では、AWS VPCエンドポイント（Gateway型・Interface型/PrivateLink）を使ってS3へプライベート接続する設定手順を、実際のAWS CLIコマンドと出力例つきで解説します。両方の違いと選び方、NATゲートウェイのコストを大幅に削減できる設計パターン、オンプレミスや他VPCからのアクセスが必要なケースの設計判断、よくあるトラブルの対処法まで一通り説明します。
動作確認環境：Amazon Linux 2023 / AWS CLI 2.15 / 東京リージョン（ap-northeast-1）
この記事のポイント
・Gateway型は無料でS3へのルートを自動追加する
・Interface型はオンプレ・他VPCからも到達できるが有料
・Gateway型への切替えでNATコストを大幅削減できる
・接続確認はaws s3 lsで即座にテストできる
続きを読む "AWS VPCエンドポイントでS3へプライベート接続する方法｜Gateway型・Interface型の違いとNATコスト削減設計"
AWSのDR設計入門｜バックアップ&リストア・パイロットライトなど4戦略とRTO/RPOの決め方
「障害が起きたとき、御社のシステムはどれくらいで復旧できますか？」
この質問に即答できないまま本番環境を動かしているケースは、現場でも決して少なくありません。
この記事では、AWS上でシステムの事業継続性を担保するDR（ディザスタリカバリ）設計の基本を解説します。具体的には、AWSが推奨する4つのDR戦略の違いと、RTO（復旧目標時間）・RPO（復旧目標時点）をもとに最適な戦略を選ぶ判断フローを整理します。
Route 53フェイルオーバーの設定操作やAWS Backupの実装手順は対象外です。「どの設計を選ぶか」の判断軸を身につけることが目的の記事です。
動作確認環境: AWS Well-Architected Framework（信頼性の柱）に基づく設計概念（2026年7月時点）。
この質問に即答できないまま本番環境を動かしているケースは、現場でも決して少なくありません。
この記事では、AWS上でシステムの事業継続性を担保するDR（ディザスタリカバリ）設計の基本を解説します。具体的には、AWSが推奨する4つのDR戦略の違いと、RTO（復旧目標時間）・RPO（復旧目標時点）をもとに最適な戦略を選ぶ判断フローを整理します。
Route 53フェイルオーバーの設定操作やAWS Backupの実装手順は対象外です。「どの設計を選ぶか」の判断軸を身につけることが目的の記事です。
動作確認環境: AWS Well-Architected Framework（信頼性の柱）に基づく設計概念（2026年7月時点）。
この記事のポイント
・RTOは「何時間以内に復旧するか」、RPOは「どこまでのデータを戻せるか」を決める指標
・DR戦略はバックアップ&リストア・パイロットライト・ウォームスタンバイ・マルチサイトの4段階
・RTO/RPO目標が短いほどコストは指数関数的に上昇する
・まずRTO/RPO目標をビジネス側と合意してから戦略を選ぶ順序が正しい
AWS Well-Architected Frameworkで構成をレビューする方法｜6つの柱と改善の優先順位付け
「AWSにシステムを構築したが、本当にこの設計で問題ないのかを確認する方法がわからない」
クラウドへの移行を進めたチームが必ずぶつかる壁です。EC2が起動していて、RDSのデータも正常に取れている。しかし「セキュリティ上の穴はないか」「障害に耐えられる構成になっているか」「無駄なコストが出ていないか」を体系的に評価する手段が見当たらない、という状況です。
この記事では、AWSが公式に提供するアーキテクチャ評価フレームワーク「AWS Well-Architected Framework」を使って、自社の構成をレビューする方法を解説します。6つの柱の設計原則から、Well-Architected Toolを使ったレビューの実施手順、改善の優先順位付けの考え方まで体系的に説明します。
動作確認環境: AWSマネジメントコンソール（2026年6月時点）、AWS CLI v2。
クラウドへの移行を進めたチームが必ずぶつかる壁です。EC2が起動していて、RDSのデータも正常に取れている。しかし「セキュリティ上の穴はないか」「障害に耐えられる構成になっているか」「無駄なコストが出ていないか」を体系的に評価する手段が見当たらない、という状況です。
この記事では、AWSが公式に提供するアーキテクチャ評価フレームワーク「AWS Well-Architected Framework」を使って、自社の構成をレビューする方法を解説します。6つの柱の設計原則から、Well-Architected Toolを使ったレビューの実施手順、改善の優先順位付けの考え方まで体系的に説明します。
動作確認環境: AWSマネジメントコンソール（2026年6月時点）、AWS CLI v2。
この記事のポイント
・Well-Architected Frameworkは6つの柱でAWSアーキテクチャを総合評価する公式指針
・Well-Architected Toolで質問に答えるだけでHRIs（高リスク課題）を自動抽出できる
・改善の優先順位はリスクの大きさと対応コストのバランスで判断する
・フレームワークは一発チェックではなく四半期ごとのPDCAサイクルとして活用する
続きを読む "AWS Well-Architected Frameworkで構成をレビューする方法｜6つの柱と改善の優先順位付け"
AWS GuardDutyとSecurity Hubで脅威検知を設計する方法｜有効化から通知・対応フローの構築まで
「GuardDutyを有効化したはいいが、検出結果が大量に届いてどれを優先すればいいかわからない」「Security HubとGuardDutyの違いが説明できない」——AWSのセキュリティ運用を始めたエンジニアがつまずきやすいのが、この2つのサービスの使い分けです。
GuardDutyは「脅威を検知するエンジン」、Security Hubは「複数のセキュリティサービスの結果を集約して管理するコントロールセンター」です。この2つを組み合わせて初めて、「何が起きているか」を把握しながら「どう対応するか」を設計できる体制ができます。
この記事では、aws guardduty security hub の基本的な役割分担を整理した上で、有効化の手順、SNS・Lambdaを使った通知設定、検知から対応までのフロー設計、マルチアカウント環境での一元管理まで、セキュリティ運用の実務設計として必要な知識を一貫して解説します。
GuardDutyは「脅威を検知するエンジン」、Security Hubは「複数のセキュリティサービスの結果を集約して管理するコントロールセンター」です。この2つを組み合わせて初めて、「何が起きているか」を把握しながら「どう対応するか」を設計できる体制ができます。
この記事では、aws guardduty security hub の基本的な役割分担を整理した上で、有効化の手順、SNS・Lambdaを使った通知設定、検知から対応までのフロー設計、マルチアカウント環境での一元管理まで、セキュリティ運用の実務設計として必要な知識を一貫して解説します。
この記事のポイント
・GuardDutyは脅威検知エンジン、Security Hubはセキュリティ状態の一元集約管理
・GuardDutyはコンソール数クリックで有効化でき、S3・EKS・マルウェア保護も追加可能
・検出結果はEventBridge→SNS→Lambdaのパイプラインで自動通知・対応できる
・マルチアカウントはOrganizations委任管理者でGuardDutyとSecurity Hub両方を一元管理する
続きを読む "AWS GuardDutyとSecurity Hubで脅威検知を設計する方法｜有効化から通知・対応フローの構築まで"
AWS SQSとSNSで疎結合アーキテクチャを設計する方法｜キューイングとファンアウトの使い分け
「SQSとSNS、どっちを使えばいいか毎回迷う」
「非同期処理の設計で後から変えられなくなった」
AWS環境で非同期処理や分散アーキテクチャを設計するとき、SQS（Simple Queue Service）とSNS（Simple Notification Service）のaws sqs sns 使い分けで迷うエンジニアは多い。
名前が似ているうえに、ユースケースが重なって見える部分もあるので、「とりあえずSQS」「なんとなくSNS」という選び方をしてしまいがちだ。
この記事では、aws sqs sns 使い分けの判断軸を根本から整理し、疎結合アーキテクチャを正しく設計する方法を解説する。
ファンアウトキューイングパターン、VPCエンドポイントとの連携、実務上の注意点とアンチパターンまでカバーする。
「非同期処理の設計で後から変えられなくなった」
AWS環境で非同期処理や分散アーキテクチャを設計するとき、SQS（Simple Queue Service）とSNS（Simple Notification Service）のaws sqs sns 使い分けで迷うエンジニアは多い。
名前が似ているうえに、ユースケースが重なって見える部分もあるので、「とりあえずSQS」「なんとなくSNS」という選び方をしてしまいがちだ。
この記事では、aws sqs sns 使い分けの判断軸を根本から整理し、疎結合アーキテクチャを正しく設計する方法を解説する。
ファンアウトキューイングパターン、VPCエンドポイントとの連携、実務上の注意点とアンチパターンまでカバーする。
この記事のポイント
・SQSは1対1のキューイング、SNSは1対多のファンアウト配信
・SNS+SQSの組み合わせでメッセージの蓄積とファンアウトを両立できる
・VPCエンドポイントでSQS/SNS通信をAWSネットワーク内に閉じセキュリティを強化する
・FIFOトピックとFIFOキューは必ずセットで使う（混在不可）
AWS LambdaとEventBridgeでEC2運用を自動化する方法｜夜間自動停止・スナップショット取得のサーバーレス設計
「EC2インスタンスを夜間に自動停止したいが、毎回AWSコンソールに入って手動操作するのは手間がかかりすぎる」
「開発環境のEC2を付けっ放しにして、月末に予想外のコスト請求が来た」
AWSを実務で使うインフラエンジニアなら、こうした運用の非効率さを感じた経験があるはずです。
この記事では、AWS LambdaとEventBridgeを組み合わせてEC2インスタンスの夜間自動停止・自動スナップショット取得をサーバーレスで実装する手順を解説します。Python boto3で動作するLambda関数コード、EventBridgeのcronルール設定手順、最小権限のIAMロール設計まで、実際に動作確認した構成を紹介します。
「開発環境のEC2を付けっ放しにして、月末に予想外のコスト請求が来た」
AWSを実務で使うインフラエンジニアなら、こうした運用の非効率さを感じた経験があるはずです。
この記事では、AWS LambdaとEventBridgeを組み合わせてEC2インスタンスの夜間自動停止・自動スナップショット取得をサーバーレスで実装する手順を解説します。Python boto3で動作するLambda関数コード、EventBridgeのcronルール設定手順、最小権限のIAMロール設計まで、実際に動作確認した構成を紹介します。
この記事のポイント
・Lambda＋EventBridgeでEC2夜間自動停止をサーバーレスで実装できる
・Python boto3のタグフィルタで本番EC2への誤操作を防ぐ設計にする
・EventBridge cronはUTC基準（JSTから9時間引いた値）で設定する
・IAMはec2:StopInstances・CreateSnapshot・DescribeInstancesを最小限付与
続きを読む "AWS LambdaとEventBridgeでEC2運用を自動化する方法｜夜間自動停止・スナップショット取得のサーバーレス設計"
AWSのストレージ選定設計｜EBS・EFS・S3の使い分けと料金・性能の判断基準
「EBSにしたら想定外のコストが発生した」「EFSを選んだのにパフォーマンスが出ない」「S3に保存しようとしたらアプリが対応していなかった」
AWSのストレージ選定ミスは、こうした形で後から表面化します。EBS・EFS・S3はどれも「データを保存する」サービスですが、内部のアーキテクチャが根本的に異なり、用途を誤るとコスト超過や性能不足を招きます。
この記事では、EBS・EFS・S3それぞれの仕組み・料金・性能特性を整理し、実務での選定判断フローを解説します。AWS初学者から「なんとなく使っているが根拠に自信がない」という設計入門層まで、ストレージ選定の判断基準を体系的に身につけていただけます。
AWSのストレージ選定ミスは、こうした形で後から表面化します。EBS・EFS・S3はどれも「データを保存する」サービスですが、内部のアーキテクチャが根本的に異なり、用途を誤るとコスト超過や性能不足を招きます。
この記事では、EBS・EFS・S3それぞれの仕組み・料金・性能特性を整理し、実務での選定判断フローを解説します。AWS初学者から「なんとなく使っているが根拠に自信がない」という設計入門層まで、ストレージ選定の判断基準を体系的に身につけていただけます。
この記事のポイント
・EBS=ブロックストレージ（EC2に直接アタッチ）、EFS=共有NFS、S3=オブジェクトストレージが3者の基本的な違い
・EC2のOSやDBにはEBS、複数インスタンスでファイル共有するならEFS、APIアクセスでよいならS3を選ぶのが基本判断軸
・コスト比は概算でS3＜EBS＜EFSの順。高機能になるほど割高になる
・AZをまたぐ冗長化要件はEFSとS3が自動対応。EBSは単一AZ内にとどまる
AWS CloudTrailとConfigで監査ログを設計する方法｜誰が何を変更したかを追跡できる構成の作り方
「AWSで何か変更したのに、後から誰がやったのか確認できない」「セキュリティ審査でAPIの操作ログを提出するよう求められたが、証跡が何も残っていなかった」——こうした事態を経験したエンジニアは少なくないはずです。
AWSは設計段階から監査ログの仕組みを組み込んでおかなければ、後から取り出せない情報が多数あります。AWS CloudTrailとAWS Configは、そのための中核サービスです。
この記事では、CloudTrailによる「誰が・いつ・何を操作したか」のAPI操作ログと、AWS Configによる「リソース設定の変更履歴・コンプライアンス評価」を組み合わせた監査証跡の設計方法を解説します。CloudWatch監視（メトリクス・アラーム）との棲み分けも明確にしながら、ガバナンス層の構成として実務で使えるベストプラクティスをまとめます。
AWSは設計段階から監査ログの仕組みを組み込んでおかなければ、後から取り出せない情報が多数あります。AWS CloudTrailとAWS Configは、そのための中核サービスです。
この記事では、CloudTrailによる「誰が・いつ・何を操作したか」のAPI操作ログと、AWS Configによる「リソース設定の変更履歴・コンプライアンス評価」を組み合わせた監査証跡の設計方法を解説します。CloudWatch監視（メトリクス・アラーム）との棲み分けも明確にしながら、ガバナンス層の構成として実務で使えるベストプラクティスをまとめます。
この記事のポイント
・CloudTrailはAPIコール全記録、ConfigはAWSリソースの設定状態変化を記録する
・2つを組み合わせて「変更の操作者」と「リソースの変化前後」を突き合わせた証跡が完成する
・証跡はマルチリージョン＋S3永続保存が前提。改ざん防止にはLogFileValidationを有効化する
・Config Rulesでコンプライアンス違反を自動検出し、修復アクションまで自動化できる
続きを読む "AWS CloudTrailとConfigで監査ログを設計する方法｜誰が何を変更したかを追跡できる構成の作り方"
AWS BackupでEC2・RDS・EFSのバックアップを一元管理する方法｜バックアッププランと復元テストの運用設計
「EC2スナップショット、RDSの自動バックアップ、EFSのバックアップ……サービスごとにバラバラに設定していて、どのリソースが何日分保持しているか把握しきれない」という状況、AWSを本番環境で運用しているエンジニアにはよく見られます。
バックアップが分散管理になると、監査対応や障害復旧の場面で「どのバックアップが有効なのか」をまず確認するところから始まり、RTO（Recovery Time Objective：目標復旧時間）の達成が難しくなります。
この記事では、AWS Backupを使ったバックアップの一元管理（aws backup 一元管理）の方法を解説します。バックアッププランの設計からEC2・RDS・EFSへの適用手順、復元テストの運用フロー、コスト最適化まで、本番環境で実践できる設計パターンを順を追って説明します。
バックアップが分散管理になると、監査対応や障害復旧の場面で「どのバックアップが有効なのか」をまず確認するところから始まり、RTO（Recovery Time Objective：目標復旧時間）の達成が難しくなります。
この記事では、AWS Backupを使ったバックアップの一元管理（aws backup 一元管理）の方法を解説します。バックアッププランの設計からEC2・RDS・EFSへの適用手順、復元テストの運用フロー、コスト最適化まで、本番環境で実践できる設計パターンを順を追って説明します。
この記事のポイント
・AWS Backupでバックアッププランを1箇所で管理できる
・EC2・RDS・EFSをタグで一括割り当て可能
・バックアップボールトでリカバリポイントを統合管理
・復元テストを定期実施してRPO/RTOを検証することが重要
続きを読む "AWS BackupでEC2・RDS・EFSのバックアップを一元管理する方法｜バックアッププランと復元テストの運用設計"
AWSのコスト最適化設計｜Cost Explorer・Savings Plans・スポットインスタンスで料金を下げる方法
「AWSの請求額が先月より急に増えた」「EC2を止めたはずなのにコストが全然下がらない」
AWSはリソースを使えば使うほど料金体系が複雑になり、気づいたら月額が予算を大幅にオーバーしていた、という状況に陥りやすいクラウドです。
この記事では、AWSコスト最適化の3本柱であるCost Explorer（現状把握）・Savings Plans（予約割引）・スポットインスタンス（スポット価格）を使って料金を削減する実践的な手順を解説します。
「どの割引プランを選べばいいか」「Savings PlansとReserved Instancesの違いは何か」など、実務でよく迷う判断基準も整理します。
動作確認環境: AWS マネジメントコンソール・AWS CLI v2（2026年7月時点）。
AWSはリソースを使えば使うほど料金体系が複雑になり、気づいたら月額が予算を大幅にオーバーしていた、という状況に陥りやすいクラウドです。
この記事では、AWSコスト最適化の3本柱であるCost Explorer（現状把握）・Savings Plans（予約割引）・スポットインスタンス（スポット価格）を使って料金を削減する実践的な手順を解説します。
「どの割引プランを選べばいいか」「Savings PlansとReserved Instancesの違いは何か」など、実務でよく迷う判断基準も整理します。
動作確認環境: AWS マネジメントコンソール・AWS CLI v2（2026年7月時点）。
この記事のポイント
・Cost Explorerのレコメンデーション機能でSavings Plans購入額の目安がわかる
・Compute Savings Plansは1年・前払いなしで最大66%割引、新規にはこれを選ぶ
・スポットインスタンスは最大90%割引、中断2分前通知をメタデータAPIで検知できる
・Reserved InstancesよりSavings Plansのほうが柔軟で新規購入に向いている
続きを読む "AWSのコスト最適化設計｜Cost Explorer・Savings Plans・スポットインスタンスで料金を下げる方法"
AWS Organizationsでマルチアカウントを設計する方法｜OU・SCP・一括請求によるアカウント統制入門
「AWSアカウントが複数になってきたけど、それぞれバラバラに管理していて全体が把握できない」
「本番環境と開発環境でアカウントを分けたいが、セキュリティポリシーをどう統一すればいいかわからない」
AWSを本格的に使い始めると、こうした壁にぶつかります。アカウントが1つのうちは管理できても、チームが拡大し、プロジェクトが増えると、単一アカウントでは権限管理・コスト管理・セキュリティ統制に限界が来ます。
この記事では、AWS Organizationsを使ったマルチアカウント設計の基本を解説します。OU（組織単位）による階層設計、SCP（サービスコントロールポリシー）を使った全アカウントへのガードレール適用、Consolidated Billing（一括請求）によるコスト一元管理まで、実際のコマンド出力例を交えて体系的に説明します。
実行環境: AWS マネジメントコンソールおよびAWS CLI v2（aws-cli/2.15.30 on Amazon Linux 2023）で動作確認済み。
「本番環境と開発環境でアカウントを分けたいが、セキュリティポリシーをどう統一すればいいかわからない」
AWSを本格的に使い始めると、こうした壁にぶつかります。アカウントが1つのうちは管理できても、チームが拡大し、プロジェクトが増えると、単一アカウントでは権限管理・コスト管理・セキュリティ統制に限界が来ます。
この記事では、AWS Organizationsを使ったマルチアカウント設計の基本を解説します。OU（組織単位）による階層設計、SCP（サービスコントロールポリシー）を使った全アカウントへのガードレール適用、Consolidated Billing（一括請求）によるコスト一元管理まで、実際のコマンド出力例を交えて体系的に説明します。
実行環境: AWS マネジメントコンソールおよびAWS CLI v2（aws-cli/2.15.30 on Amazon Linux 2023）で動作確認済み。
この記事のポイント
・AWS OrganizationsはOU（組織単位）でアカウントを階層管理し、SCP（サービスコントロールポリシー）で全体統制する
・SCPはIAMポリシーの上位にある制御層で、AdministratorAccessでも突破できないガードレールを作れる
・OU設計は「本番/開発/セキュリティ/サンドボックス」の4層分離が実務の標準パターン
・Consolidated Billingで全アカウントのコストを一元集計し、RIの割引も組織全体で共有される
続きを読む "AWS Organizationsでマルチアカウントを設計する方法｜OU・SCP・一括請求によるアカウント統制入門"
AWS WAFでWebアプリケーションを守るセキュリティ設計入門｜マネージドルール・レート制限・地域制限の構成パターン
「WebアプリをパブリックなALBの後ろに公開したら、毎日大量の不審なリクエストが届く。SQLインジェクションやXSSの攻撃試行をどこで止めればいいか分からない」
「セキュリティグループやNACLではL4（IP・ポート）までしか制御できないと聞いた。HTTPリクエストの中身はどう検査すればいい？」
こういった悩みは、AWSでWebアプリの本番環境を初めて構築するエンジニアからよく聞きます。セキュリティグループは「IPアドレスとポート番号」で通信を制御しますが、HTTPリクエストのパス・クエリパラメータ・ボディを検査することはできません。SQLインジェクションやクロスサイトスクリプティング（XSS）のような「正常なポートを使った悪意のあるリクエスト」は素通りしてしまいます。
この記事では、AWS WAFを使ってWebアプリのL7レイヤーを守るセキュリティ設計を、AWS CLIを使って実践的に解説します。WebACLの設計思想からAWSマネージドルールの有効化・レート制限・Geo-matchルールの設定・WAFログのS3出力設計まで、本番運用に必要な構成パターンを一通り押さえます。
動作確認環境: Amazon Linux 2023 / AWS CLI 2.17.x / AWS WAF v2（Regional WebACL for ALB）
「セキュリティグループやNACLではL4（IP・ポート）までしか制御できないと聞いた。HTTPリクエストの中身はどう検査すればいい？」
こういった悩みは、AWSでWebアプリの本番環境を初めて構築するエンジニアからよく聞きます。セキュリティグループは「IPアドレスとポート番号」で通信を制御しますが、HTTPリクエストのパス・クエリパラメータ・ボディを検査することはできません。SQLインジェクションやクロスサイトスクリプティング（XSS）のような「正常なポートを使った悪意のあるリクエスト」は素通りしてしまいます。
この記事では、AWS WAFを使ってWebアプリのL7レイヤーを守るセキュリティ設計を、AWS CLIを使って実践的に解説します。WebACLの設計思想からAWSマネージドルールの有効化・レート制限・Geo-matchルールの設定・WAFログのS3出力設計まで、本番運用に必要な構成パターンを一通り押さえます。
動作確認環境: Amazon Linux 2023 / AWS CLI 2.17.x / AWS WAF v2（Regional WebACL for ALB）
この記事のポイント
・AWS WAFはSGと異なりHTTPリクエストの中身（L7）を検査してブロック判定できる
・WebACLにマネージドルールを追加するだけでSQLi・XSS・Bot攻撃を即座にブロック可能
・レートベースルールで同一IPからの過剰アクセスを5分単位で自動遮断できる
・まずカウントモードで誤検知を確認し、段階的にBLOCKへ移行するのが安全な設計手順
続きを読む "AWS WAFでWebアプリケーションを守るセキュリティ設計入門｜マネージドルール・レート制限・地域制限の構成パターン"
AWS S3バケットのバージョニングとライフサイクルポリシーで安全なデータ管理を実現する方法｜誤削除対策とGlacier移行設計
「EC2のAMIバックアップは取ってるのに、S3に置いたデータが誰かに上書きされた」
「スクリプトのバグでS3からファイルを誤削除してしまい、復元できなかった」
こういった事故は、S3をデフォルト設定のまま使い続けたときに起きやすいインシデントです。S3は高可用性なオブジェクトストレージですが、上書きや削除への保護機能はデフォルトでは無効になっています。バージョニングとライフサイクルポリシーを組み合わせることで、誤操作からデータを守りながらストレージコストを最適化できます。
この記事では、AWS CLIを使ってS3バケットのバージョニングを有効化し、削除マーカーの仕組みを理解した上で、ライフサイクルポリシーによるGlacier移行とバージョン管理の設計方法を実践的に解説します。クロスリージョンレプリケーション（CRR）によるリージョン間冗長化の手順も含めます。
動作確認環境: Amazon Linux 2023 / AWS CLI 2.17.x / S3（ap-northeast-1リージョン）
「スクリプトのバグでS3からファイルを誤削除してしまい、復元できなかった」
こういった事故は、S3をデフォルト設定のまま使い続けたときに起きやすいインシデントです。S3は高可用性なオブジェクトストレージですが、上書きや削除への保護機能はデフォルトでは無効になっています。バージョニングとライフサイクルポリシーを組み合わせることで、誤操作からデータを守りながらストレージコストを最適化できます。
この記事では、AWS CLIを使ってS3バケットのバージョニングを有効化し、削除マーカーの仕組みを理解した上で、ライフサイクルポリシーによるGlacier移行とバージョン管理の設計方法を実践的に解説します。クロスリージョンレプリケーション（CRR）によるリージョン間冗長化の手順も含めます。
動作確認環境: Amazon Linux 2023 / AWS CLI 2.17.x / S3（ap-northeast-1リージョン）
この記事のポイント
・バージョニング有効化は put-bucket-versioning --status Enabled の1コマンド
・削除しても削除マーカーが残るため list-object-versions で復元できる
・ライフサイクルポリシーで古いバージョンをGlacierに移行してコストを削減
・CRRはバージョニングが前提条件。既存オブジェクトには自動適用されない点に注意
続きを読む "AWS S3バケットのバージョニングとライフサイクルポリシーで安全なデータ管理を実現する方法｜誤削除対策とGlacier移行設計"
AWS Systems ManagerのSession ManagerでSSHなしにEC2を管理する方法｜Run Command・Parameter Storeの実践設計
「プライベートサブネットのEC2に入るたびに踏み台サーバーにSSHして、そこから内部EC2に再度SSH……という二段階接続が手間すぎる」
「SSH鍵を複数人で共有している。誰がいつ何のために接続したか分からなくて怖い」
こういった声は、AWSでインフラを運用しはじめたLinuxエンジニアからよく聞きます。踏み台サーバー（Bastion Host）方式は「公開鍵認証＋ポート22開放」が必須のため、鍵の紛失・共有・ローテーションが運用負荷になりがちです。
この記事では、AWS Systems Manager（SSM）のSession Managerを使って踏み台サーバーなしでEC2に接続する方法を解説します。IAMロールによるアクセス制御、Run Commandを使った一括コマンド実行、Parameter StoreによるDBパスワードなどの秘密情報管理まで、実務で使えるSSMの設計パターンをひとまとめに解説します。
動作確認環境: Amazon Linux 2023 / AWS CLI 2.17.x / AWS Systems Manager Agent 3.3.x
「SSH鍵を複数人で共有している。誰がいつ何のために接続したか分からなくて怖い」
こういった声は、AWSでインフラを運用しはじめたLinuxエンジニアからよく聞きます。踏み台サーバー（Bastion Host）方式は「公開鍵認証＋ポート22開放」が必須のため、鍵の紛失・共有・ローテーションが運用負荷になりがちです。
この記事では、AWS Systems Manager（SSM）のSession Managerを使って踏み台サーバーなしでEC2に接続する方法を解説します。IAMロールによるアクセス制御、Run Commandを使った一括コマンド実行、Parameter StoreによるDBパスワードなどの秘密情報管理まで、実務で使えるSSMの設計パターンをひとまとめに解説します。
動作確認環境: Amazon Linux 2023 / AWS CLI 2.17.x / AWS Systems Manager Agent 3.3.x
この記事のポイント
・aws ssm start-session でSSHなし・鍵なしでEC2に接続できる
・IAMロール（AmazonSSMManagedInstanceCore）のアタッチが唯一の前提条件
・Run Commandでタグ指定した複数EC2へ同時コマンドを実行できる
・Parameter StoreでDBパスワードをKMS暗号化して安全に管理できる
続きを読む "AWS Systems ManagerのSession ManagerでSSHなしにEC2を管理する方法｜Run Command・Parameter Storeの実践設計"
AWS ElastiCacheでRedisをマルチAZ冗長構成にする方法｜ノード障害時の自動フェイルオーバーとスケールアウト設計入門
「WebアプリのレスポンスがDB（RDS）のボトルネックで遅い。キャッシュを入れたいがノード1台では障害時にキャッシュが全滅して怖い」
「ElastiCacheのマルチAZ設定で自動フェイルオーバーを試したが、どのオプションを付ければいいかわからない」
こういった声は、AWSでWebアプリを本番運用し始めたエンジニアからよく聞きます。Amazon ElastiCache for Redisはセッション管理・クエリキャッシュ・ランキング集計など幅広い用途で使われていますが、シングルノード構成のままでは可用性に問題があります。プライマリノードが障害を起こすとキャッシュが失われ、バックエンドのRDSに一気に大量クエリが流れ込む「キャッシュスタンピード」が発生するリスクがあります。
この記事では、ElastiCache for Redisをマルチ AZ 冗長構成（レプリケーショングループ）で設計・構築する手順を、AWS CLIを使って実践的に解説します。自動フェイルオーバーの仕組みから、リーダーエンドポイントを使った読み取り負荷分散、CloudWatchによるモニタリング設計、レプリカ追加によるスケールアウト、VPC内のセキュリティ設計まで一通り押さえます。
動作確認環境: Amazon Linux 2023 / AWS CLI 2.17.x / ElastiCache for Redis 7.1（クラスターモード無効）
「ElastiCacheのマルチAZ設定で自動フェイルオーバーを試したが、どのオプションを付ければいいかわからない」
こういった声は、AWSでWebアプリを本番運用し始めたエンジニアからよく聞きます。Amazon ElastiCache for Redisはセッション管理・クエリキャッシュ・ランキング集計など幅広い用途で使われていますが、シングルノード構成のままでは可用性に問題があります。プライマリノードが障害を起こすとキャッシュが失われ、バックエンドのRDSに一気に大量クエリが流れ込む「キャッシュスタンピード」が発生するリスクがあります。
この記事では、ElastiCache for Redisをマルチ AZ 冗長構成（レプリケーショングループ）で設計・構築する手順を、AWS CLIを使って実践的に解説します。自動フェイルオーバーの仕組みから、リーダーエンドポイントを使った読み取り負荷分散、CloudWatchによるモニタリング設計、レプリカ追加によるスケールアウト、VPC内のセキュリティ設計まで一通り押さえます。
動作確認環境: Amazon Linux 2023 / AWS CLI 2.17.x / ElastiCache for Redis 7.1（クラスターモード無効）
この記事のポイント
・マルチAZ構成は --automatic-failover-enabled --multi-az-enabled の2オプションで作成する
・プライマリ障害時はリードレプリカが自動昇格（約1～2分）・アプリ側の設定変更は不要
・リーダーエンドポイントで読み取りをレプリカに分散し、レプリカ追加でスループットを線形拡張できる
・CloudWatch の ReplicationLag と CacheHitRate を常時監視して本番品質を担保する
続きを読む "AWS ElastiCacheでRedisをマルチAZ冗長構成にする方法｜ノード障害時の自動フェイルオーバーとスケールアウト設計入門"
AWS CloudWatchでLinuxサーバーを監視する方法｜CloudWatch Agentの設定からメトリクス収集・アラート通知まで
「AWSにLinuxサーバーを立てたが、CPUやメモリの監視設定がまだできていない」
「EC2のOSレベルのメトリクス（メモリ・ディスク使用率）がCloudWatchに表示されない理由がわからない」
こうした声は、AWSを使い始めたLinuxエンジニアからよく聞きます。AWSはデフォルトでCPUやネットワークなど一部のメトリクスを自動収集しますが、メモリ使用率やディスク使用率はOS内部の情報のため、CloudWatch Agentを別途インストールしなければ見えません。
この記事では、Amazon Linux 2023環境でのCloudWatch Agentのインストールから、カスタムメトリクス（メモリ・ディスク）の収集設定、アラームによるSNS通知、CloudWatch Logsを使ったログ集約まで、一通りの監視設計を実践的に解説します。
動作確認環境: Amazon Linux 2023 / CloudWatch Agent 1.300044.0 / AWS CLI 2.17.x
「EC2のOSレベルのメトリクス（メモリ・ディスク使用率）がCloudWatchに表示されない理由がわからない」
こうした声は、AWSを使い始めたLinuxエンジニアからよく聞きます。AWSはデフォルトでCPUやネットワークなど一部のメトリクスを自動収集しますが、メモリ使用率やディスク使用率はOS内部の情報のため、CloudWatch Agentを別途インストールしなければ見えません。
この記事では、Amazon Linux 2023環境でのCloudWatch Agentのインストールから、カスタムメトリクス（メモリ・ディスク）の収集設定、アラームによるSNS通知、CloudWatch Logsを使ったログ集約まで、一通りの監視設計を実践的に解説します。
動作確認環境: Amazon Linux 2023 / CloudWatch Agent 1.300044.0 / AWS CLI 2.17.x
この記事のポイント
・CloudWatch Agentがないとメモリ・ディスクは取得できない
・IAMポリシー2つをEC2ロールにアタッチするのが設定の前提
・put-metric-alarmでメモリ85%・ディスク80%のアラームを設定
・CloudWatch Logsへのログ集約とERRORフィルターで異常を検知
続きを読む "AWS CloudWatchでLinuxサーバーを監視する方法｜CloudWatch Agentの設定からメトリクス収集・アラート通知まで"
AWS ECS・Fargateでコンテナアプリを本番運用するための設計手順｜タスク定義・ALB連携・マルチAZ配置の構成パターン入門
「Dockerでアプリをコンテナ化したはいいが、AWSで本番運用する構成をどう設計すればいいかわからない」
「ECSとFargateの違いは？ALBとの連携方法や、マルチAZ設計のポイントが整理できていない」
こうした悩みを持つLinuxエンジニアは少なくありません。コンテナ技術そのものはDockerで学べても、AWSで"止まらない本番構成"を組み立てるには、ECS固有の設計ルールを体系的に把握する必要があります。
この記事では、AWS ECS・Fargateを使ったコンテナ本番環境の設計手順を、タスク定義・ALBとの連携・マルチAZ分散配置・Auto Scaling・IAMロール設計まで順を追って解説します。セキュリティグループ設計・デプロイ失敗時の自動ロールバック設定・VPCエンドポイントによるコスト最適化まで、現場で必要になる設計判断を網羅しています。動作確認済みのAWS CLIコマンドと設定例を交えながら進めるので、設計の全体像を掴みながら読み進めてください。
動作確認環境: Amazon Linux 2023 / AWS CLI 2.x
「ECSとFargateの違いは？ALBとの連携方法や、マルチAZ設計のポイントが整理できていない」
こうした悩みを持つLinuxエンジニアは少なくありません。コンテナ技術そのものはDockerで学べても、AWSで"止まらない本番構成"を組み立てるには、ECS固有の設計ルールを体系的に把握する必要があります。
この記事では、AWS ECS・Fargateを使ったコンテナ本番環境の設計手順を、タスク定義・ALBとの連携・マルチAZ分散配置・Auto Scaling・IAMロール設計まで順を追って解説します。セキュリティグループ設計・デプロイ失敗時の自動ロールバック設定・VPCエンドポイントによるコスト最適化まで、現場で必要になる設計判断を網羅しています。動作確認済みのAWS CLIコマンドと設定例を交えながら進めるので、設計の全体像を掴みながら読み進めてください。
動作確認環境: Amazon Linux 2023 / AWS CLI 2.x
この記事のポイント
・FargateはサーバーレスでEC2管理が不要。本番用途では最初の選択肢になる
・タスク定義でCPU・メモリ・コンテナ定義・ログ設定を一元管理する
・ECSサービス＋ALBでマルチAZに分散配置してヘルスチェックを自動化する
・Auto ScalingはCPU使用率70%をトリガーにするターゲットトラッキングが基本
・実行ロール（起動権限）とタスクロール（アプリ権限）を分離して最小権限を実現する
・デプロイ失敗時はcircuit breakerで自動ロールバックしサービス停止を防ぐ
続きを読む "AWS ECS・Fargateでコンテナアプリを本番運用するための設計手順｜タスク定義・ALB連携・マルチAZ配置の構成パターン入門"
AWS CloudFrontとS3でグローバルCDN配信を設計する方法｜オリジンフェイルオーバーとキャッシュ制御入門
「CloudFrontの設定をどこから始めればいいか分からない」「S3で直接公開しているが、障害時の自動切り替えができていない」
AWS CloudFrontを使ったCDN設計は、単に「コンテンツをキャッシュする」だけではありません。オリジンフェイルオーバー・キャッシュポリシー・セキュリティ設定の設計次第で、可用性とパフォーマンスが大きく変わります。
この記事では、CloudFrontとS3を組み合わせたCDN配信設計の実践手順を、ディストリビューション作成からオリジンフェイルオーバー・キャッシュ制御・OACセキュリティ設定・ACM証明書まで一通り解説します。
動作確認環境: Amazon Linux 2023 + AWS CLI v2（2.17.x）・東京リージョン（ap-northeast-1）
AWS CloudFrontを使ったCDN設計は、単に「コンテンツをキャッシュする」だけではありません。オリジンフェイルオーバー・キャッシュポリシー・セキュリティ設定の設計次第で、可用性とパフォーマンスが大きく変わります。
この記事では、CloudFrontとS3を組み合わせたCDN配信設計の実践手順を、ディストリビューション作成からオリジンフェイルオーバー・キャッシュ制御・OACセキュリティ設定・ACM証明書まで一通り解説します。
動作確認環境: Amazon Linux 2023 + AWS CLI v2（2.17.x）・東京リージョン（ap-northeast-1）
この記事のポイント
・CloudFrontはエッジロケーションでキャッシュしてレイテンシを削減するCDNサービスです
・S3オリジンにはOAC（Origin Access Control）を使い、S3直接アクセスを必ず遮断する
・オリジングループで5xxエラー時にセカンダリS3へ自動フェイルオーバーさせる
・キャッシュポリシーとCache-Controlヘッダーを組み合わせてTTLを適切に制御する
続きを読む "AWS CloudFrontとS3でグローバルCDN配信を設計する方法｜オリジンフェイルオーバーとキャッシュ制御入門"
AWS Route 53のフェイルオーバールーティングでDNS冗長化する方法｜ヘルスチェックとマルチリージョン設計入門
「マルチAZでサーバーは冗長化したのに、DNSが単一障害点のままだった」
可用性設計を進めていくと、意外と見落としがちなのがDNS層の冗長化です。
サーバーやRDSをどれだけ冗長化しても、利用者を最初に案内するDNSが1つの向き先しか返せなければ、その向き先が落ちた瞬間にサービスは応答しなくなります。AWSのRoute 53には、ヘルスチェックと連動して自動で向き先を切り替える「フェイルオーバールーティング」という仕組みがあります。
この記事では、Route 53のヘルスチェックとフェイルオーバールーティングでDNS層を冗長化する設計手順を解説します。
単なる設定手順ではなく、「どこがSPOF（単一障害点）になるのか」「TTLをどう設計するか」という実務の勘所から掘り下げていきます。
可用性設計を進めていくと、意外と見落としがちなのがDNS層の冗長化です。
サーバーやRDSをどれだけ冗長化しても、利用者を最初に案内するDNSが1つの向き先しか返せなければ、その向き先が落ちた瞬間にサービスは応答しなくなります。AWSのRoute 53には、ヘルスチェックと連動して自動で向き先を切り替える「フェイルオーバールーティング」という仕組みがあります。
この記事では、Route 53のヘルスチェックとフェイルオーバールーティングでDNS層を冗長化する設計手順を解説します。
単なる設定手順ではなく、「どこがSPOF（単一障害点）になるのか」「TTLをどう設計するか」という実務の勘所から掘り下げていきます。
この記事のポイント
・Route 53はヘルスチェックで向き先を自動切替できる
・フェイルオーバーはPrimary・Secondaryの2レコードで組む
・切り替え速度はTTLとヘルスチェック間隔で決まる
・マルチリージョン構成でリージョン障害にも備えられる
続きを読む "AWS Route 53のフェイルオーバールーティングでDNS冗長化する方法｜ヘルスチェックとマルチリージョン設計入門"
AWS Transit GatewayとVPCピアリングの設計｜マルチVPC・マルチアカウントのネットワーク構成入門
「本番VPCと開発VPCを接続したいが、どのサービスを選べばいいのかわからない」
「VPCピアリングとTransit Gatewayの違いが曖昧で、設計方針を決めきれない」
複数のVPCが増えてきたとき、ネットワーク接続の設計でつまずくエンジニアは多い。ピアリングでいいのか、Transit Gatewayを使うべきなのか。その判断基準がわからないと、後で設計をやり直す羽目になる。
この記事では、VPCピアリングとAWS Transit Gatewayの仕組みと使い分けを解説し、マルチVPC・マルチアカウント環境で崩れない設計パターンを具体的に示す。
「VPCピアリングとTransit Gatewayの違いが曖昧で、設計方針を決めきれない」
複数のVPCが増えてきたとき、ネットワーク接続の設計でつまずくエンジニアは多い。ピアリングでいいのか、Transit Gatewayを使うべきなのか。その判断基準がわからないと、後で設計をやり直す羽目になる。
この記事では、VPCピアリングとAWS Transit Gatewayの仕組みと使い分けを解説し、マルチVPC・マルチアカウント環境で崩れない設計パターンを具体的に示す。
この記事のポイント
・VPCピアリングは2VPC間の1対1接続で推移的ルーティングが効かない
・Transit GatewayはハブになりVPC数が増えても接続数がO(n)で収まる
・3VPC以上またはマルチアカウント運用はTransit Gateway一択
・CIDR設計とルートテーブルの伝播ルールが設計の核心
続きを読む "AWS Transit GatewayとVPCピアリングの設計｜マルチVPC・マルチアカウントのネットワーク構成入門"
AWS RDSのマルチAZとリードレプリカで可用性を高めるデータベース設計入門
「本番DBが落ちたらサービス全体が止まる」「読み取りが遅くてユーザーが離脱している」
AWSでシステムを構築していると、こうした問題に直面することがあります。
原因のほとんどは、データベース設計の段階でマルチAZとリードレプリカを検討していないことです。
この記事では、AWS RDSのマルチAZ配置とリードレプリカの仕組みを解説し、
止まらないデータベース設計の基本を実践的に説明します。
RHEL 9 / Amazon Linux 2023 環境での動作確認例も含めています。
AWSでシステムを構築していると、こうした問題に直面することがあります。
原因のほとんどは、データベース設計の段階でマルチAZとリードレプリカを検討していないことです。
この記事では、AWS RDSのマルチAZ配置とリードレプリカの仕組みを解説し、
止まらないデータベース設計の基本を実践的に説明します。
RHEL 9 / Amazon Linux 2023 環境での動作確認例も含めています。
この記事のポイント
・マルチAZはスタンバイDBへの自動フェイルオーバーで高可用性を実現する
・リードレプリカは読み取り専用の複製で参照負荷を分散する設計パターン
・2つは用途が異なる。可用性=マルチAZ、スケール=リードレプリカが基本
・フェイルオーバー時間は1～2分が目安。ダウンタイムゼロにはならない
AWS IAM権限設計入門｜最小権限の原則でロール・ポリシー・グループを設計する方法
「AWSのIAMってなんとなく設定しているけど、これで本当にセキュアなのか不安…」
「rootアカウントでEC2を操作しているが、それって危険？」
AWSを使い始めた多くのエンジニアが、IAM（Identity and Access Management）の設計で同じ壁にぶつかります。アクセスキーの使い回し、過剰な権限付与、グループ設計のないカオスな状態。これらは実際のインシデントの入り口になる典型的な失敗パターンです。
この記事では、AWS IAMの基本概念から、最小権限の原則に基づいた実践的な権限設計まで解説します。LinuxサーバーのユーザーやSELinuxの考え方と対比しながら説明するので、Linuxエンジニアがクラウドの権限管理を体系的に理解できる構成になっています。
実行環境: AWS コンソール（us-east-1リージョン）および AWS CLI v2（aws-cli/2.15.30 on Amazon Linux 2023）で動作確認済み。
「rootアカウントでEC2を操作しているが、それって危険？」
AWSを使い始めた多くのエンジニアが、IAM（Identity and Access Management）の設計で同じ壁にぶつかります。アクセスキーの使い回し、過剰な権限付与、グループ設計のないカオスな状態。これらは実際のインシデントの入り口になる典型的な失敗パターンです。
この記事では、AWS IAMの基本概念から、最小権限の原則に基づいた実践的な権限設計まで解説します。LinuxサーバーのユーザーやSELinuxの考え方と対比しながら説明するので、Linuxエンジニアがクラウドの権限管理を体系的に理解できる構成になっています。
実行環境: AWS コンソール（us-east-1リージョン）および AWS CLI v2（aws-cli/2.15.30 on Amazon Linux 2023）で動作確認済み。
この記事のポイント
・IAMユーザー・グループ・ロール・ポリシーの4要素を正確に理解する
・rootアカウントを封印し、IAMユーザーとMFAで運用する初期設定手順
・最小権限の原則を守るグループ設計と、EC2/S3/RDSへのロール付与の実践
・アクセスキーの代わりにIAMロールを使う設計がなぜセキュアかを理解する
AWS Auto ScalingとELBで作る高可用性アーキテクチャ｜EC2自動スケーリングとロードバランサーの設計パターン入門
「AWSにEC2を立てたはいいが、負荷が増えたり1台が落ちたりしたらどうなるんだろう」
クラウドを使い始めたLinuxエンジニアが必ずぶつかる壁です。
この記事では、AWS Auto ScalingとELB（Elastic Load Balancing）を組み合わせて高可用性アーキテクチャを設計する方法を、構成設計の考え方から順を追って解説します。
単なる「操作手順」ではなく、「なぜこの構成にするのか」という設計の文脈ごと理解することを目指します。
動作確認環境: AWS マネジメントコンソール（2026年6月時点）。
クラウドを使い始めたLinuxエンジニアが必ずぶつかる壁です。
この記事では、AWS Auto ScalingとELB（Elastic Load Balancing）を組み合わせて高可用性アーキテクチャを設計する方法を、構成設計の考え方から順を追って解説します。
単なる「操作手順」ではなく、「なぜこの構成にするのか」という設計の文脈ごと理解することを目指します。
動作確認環境: AWS マネジメントコンソール（2026年6月時点）。
この記事のポイント
・ELBがトラフィックを分散し、Auto Scalingが台数を自動調整する
・起動テンプレート＋Auto Scalingグループ＋ALBの3点セットが基本構成
・ヘルスチェック失敗時にAuto Scalingが自動でEC2を入れ替える仕組み
・マルチAZ構成にしてはじめて単一AZ障害に耐えられる
続きを読む "AWS Auto ScalingとELBで作る高可用性アーキテクチャ｜EC2自動スケーリングとロードバランサーの設計パターン入門"
AWS VPC設計入門｜サブネット・セキュリティグループ・NATの基礎ハンズオン
「AWS VPCって設計が複雑そうで、どこから手をつければいいか分からない」
そう感じているエンジニアは多いはずです。VPC（Virtual Private Cloud）はAWSの基盤となるネットワーク機能ですが、
CIDRブロック・サブネット・セキュリティグループ・NATゲートウェイと用語が多く、最初は混乱しがちです。
この記事では、aws vpc 設計の基礎からマルチAZ構成まで、実際の設計パターンをハンズオン形式で解説します。
Webサービスの本番環境で主流になっている「3層アーキテクチャ（ALB・EC2・RDS）」での実装パターンを中心に、VPCフローログを使った通信の可視化とセキュリティ監査の方法も含めて、「まず動くVPCを作りたい」「セキュリティ設定が正しいか確認したい」という初級～中級者に向けて体系的にカバーします。
設計の詳細な冗長化・マルチAZ応用については、AWS冗長設計入門もあわせて参照してください。
そう感じているエンジニアは多いはずです。VPC（Virtual Private Cloud）はAWSの基盤となるネットワーク機能ですが、
CIDRブロック・サブネット・セキュリティグループ・NATゲートウェイと用語が多く、最初は混乱しがちです。
この記事では、aws vpc 設計の基礎からマルチAZ構成まで、実際の設計パターンをハンズオン形式で解説します。
Webサービスの本番環境で主流になっている「3層アーキテクチャ（ALB・EC2・RDS）」での実装パターンを中心に、VPCフローログを使った通信の可視化とセキュリティ監査の方法も含めて、「まず動くVPCを作りたい」「セキュリティ設定が正しいか確認したい」という初級～中級者に向けて体系的にカバーします。
設計の詳細な冗長化・マルチAZ応用については、AWS冗長設計入門もあわせて参照してください。
この記事のポイント
・VPCはAWS上の仮想ネットワーク。CIDRブロックで範囲を決める
・サブネットはパブリック（ALB）・アプリプライベート（EC2）・DBプライベート（RDS）の3層に分ける
・セキュリティグループはALB-SG→EC2-SG→RDS-SGの順にSG参照で連携させる
・VPCフローログでACCEPT/REJECTを記録し、SG/NACLの設定検証と通信監査に活用する
AWSでマルチAZ冗長構成を設計する方法｜止まらないシステムの作り方入門
「AWSで可用性を高めたいが、マルチAZってどう設計すればいいのか分からない」
サービスを本番運用し始めると、必ず突き当たる壁です。
AWSのマルチAZ冗長構成は、単に「複数のAZに同じサーバーを並べる」だけでは成立しません。VPCのサブネット設計、ロードバランサー、RDSやElastiCache側のフェイルオーバー設定まで、一連のパーツが噛み合って初めて「止まらないシステム」が実現できます。
この記事では、AWSマルチAZ冗長構成の設計パターンと実装上の注意点を解説します。
コマンド単体の使い方ではなく、「なぜそう設計するのか」「どこが落とし穴か」という設計思想から掘り下げていきます。
サービスを本番運用し始めると、必ず突き当たる壁です。
AWSのマルチAZ冗長構成は、単に「複数のAZに同じサーバーを並べる」だけでは成立しません。VPCのサブネット設計、ロードバランサー、RDSやElastiCache側のフェイルオーバー設定まで、一連のパーツが噛み合って初めて「止まらないシステム」が実現できます。
この記事では、AWSマルチAZ冗長構成の設計パターンと実装上の注意点を解説します。
コマンド単体の使い方ではなく、「なぜそう設計するのか」「どこが落とし穴か」という設計思想から掘り下げていきます。
この記事のポイント
・マルチAZはVPCサブネット設計から始まる
・ALB＋Auto Scalingで自動復旧するWeb層を作る
・RDSのマルチAZはプライマリ障害時に自動昇格する
・設計の落とし穴はセッション管理とDNS TTLにある
AWS用語解説
AWS(Amazon Web Services)
・Amazonが提供するクラウドサービスです。・フルマネージドサービス
・サーバーやネットワーク機器などのハードウェアは、Amazonが管理します。
・ハードウェアの購入や設置、メンテナンス、故障対応などの必要がありません。
・利用者は仮想マシンなど借りているリソースに集中できます。
・リソースを利用した分だけ費用が発生します。
VPC（Amazon Web Service Virtual Private Cloud）
・VPCとは、AWSサービスの１つです。・VPCは、AWS上に仮想的なネットワーク空間を構築するものです。
・ファイアウォールなどセキュリティ関連機能もVPCの一部として利用できます。
・VPCに含まれるVPN機能で企業ネットワークとの接続も可能です。
・利用時間や通信量で課金されます。 ・詳細についてはこちらを確認してください。
リージョン(Region)
・AWSのデータセンターが存在するエリアの事をリージョンと言います。・リージョン毎に提供しているサービスに差があります。
・現存するリージョンはこちらに掲載されています。
・日本リージョンには、東京と大阪の２つのリージョンがあります。
大阪リージョンは、ローカルリージョンと呼ばれ、
単独で利用はできず、事前申込みと審査が必要です。
主に、災害に対する備えとしての利用を想定しています。
従って、日本で利用する場合は、通常は東京リージョンを選択します。
但し、利用者に近いリージョンを選択します。
・リージョンには対応コードがあります。
東京リージョンのコード：ap-northeast-1
大阪リージョンのコード：ap-northeast-3
Amazon Linux2(EC2)のパッケージアップデート
AWS EC2インスタンスでAmazon Linux2を選択し、
パッケージアップデートを行う場合は、↓を実行します。
パッケージアップデートを行う場合は、↓を実行します。
$ sudo yum update
Amazon Linux2(EC2)のec2-user(デフォルトユーザー)を禁止する
AWS EC2インスタンスでAmazon Linux2を選択した場合、
デフォルトユーザーは、ec2-userになります。
ec2-userでSSHログインする場合は、公開鍵認証方式なので、
秘密鍵ファイルが必要になりセキュリティが担保されていますが、
デフォルトユーザーが一般に周知されているので、
これをそのまま使用するのは、システムによっては
ポリシー違反になる場合があります。
そのような場合は、ec2-userの使用を禁止し、
他の任意のユーザーで運用します。
例ではpakiraユーザーを作成していますが、この箇所は任意に変えてください。
デフォルトユーザーは、ec2-userになります。
ec2-userでSSHログインする場合は、公開鍵認証方式なので、
秘密鍵ファイルが必要になりセキュリティが担保されていますが、
デフォルトユーザーが一般に周知されているので、
これをそのまま使用するのは、システムによっては
ポリシー違反になる場合があります。
そのような場合は、ec2-userの使用を禁止し、
他の任意のユーザーで運用します。
1.新規ユーザーを作成します。
ec2-userでログインし、新規ユーザーを作成してパスワード設定します。例ではpakiraユーザーを作成していますが、この箇所は任意に変えてください。
$ sudo useradd pakira
$ sudo passwd pakira
Changing password for user pakira.
New password: ←任意のパスワードを設定します。
Retype new password: ←再度、任意のパスワードを設定します。
passwd: all authentication tokens updated successfully.
Amazon Linux2(EC2)の言語とタイムゾーン(時刻)を日本設定にする
AWS(EC2)をAmazon Linux2で作成した直後は、デフォルト言語が英語になっています。
これを日本語化します。
また、タイムゾーンもUTCになってしますので、これも変更します。
「localectl set-locale」で「ja_JP.utf8」を設定して日本語にします。
その後、「source /etc/locale.conf」で設定を反映します。
dateコマンドを実行すると、日本語表示になっていることがわかります。
しかし、タイムゾーンがUTCなので、実際の日本時間と9時間のズレが生じています。
これを次の手順で修正します。
これを日本語化します。
また、タイムゾーンもUTCになってしますので、これも変更します。
Amazon Linux2を日本語化する
dateコマンドを実行すると、英語で表示されます。
$ date
Thu Apr 1 05:37:56 UTC 2021
「localectl set-locale」で「ja_JP.utf8」を設定して日本語にします。
その後、「source /etc/locale.conf」で設定を反映します。
dateコマンドを実行すると、日本語表示になっていることがわかります。
$ $ sudo localectl set-locale LANG=ja_JP.utf8
$ $ source /etc/locale.conf
$ date
2021年 4月 1日 木曜日 05:45:42 UTC
しかし、タイムゾーンがUTCなので、実際の日本時間と9時間のズレが生じています。
これを次の手順で修正します。