AWS(Amazon Linux) Linux

この記事のポイント

・AWS Security Lakeは複数アカウントのログをS3に一元集約できる
・OCSFフォーマットに正規化されるため、SIEMとの連携が容易になる
・Organizations委任管理者アカウントで集中管理する設計が基本形
・CloudTrail・VPC Flow Logsなど主要ソースを自動収集できる

この記事のポイント

・ZabbixエージェントはTCP 10050番でサーバーと通信する
・セキュリティグループはIPよりIDを参照元に使うと管理しやすい
・Zabbixプロキシのマルチ配置でAZ障害時も監視を継続できる
・監視対象SGと監視サーバーSGをセットで設計する

この記事のポイント

・aws運用監視はメトリクス収集・ログ管理・アラート設計の3レイヤーで設計する
・マルチアカウント構成では Cross-Account Observability で中央集約する
・Composite Alarmで複数メトリクスの複合条件アラートを実装できる
・ダッシュボードは中央監視アカウントにまとめてチームで共有できる

この記事のポイント

・CloudWatchはAWSリソースの標準メトリクス収集コストが低く、マルチAZ設計との親和性が高い
・DatadogはGCP・Azureを含むマルチクラウドや20台以上の環境で横断ダッシュボードが必要なときに強い
・選定の分かれ目は「AWS専用か否か」と「月次の監視コスト許容額」
・マルチAZ構成では可用性ゾーン別のアラート設計が監視品質を左右する

この記事のポイント

・CloudWatch→SNS→メール通知が「aws監視」の最短パス
・EventBridgeはサービスイベント（EC2停止・RDS障害等）の検知に使う
・SNSトピックを中継点にすると通知先を後から追加しやすい
・通知が届かない原因の9割はサブスクリプション未確認かIAMポリシー不足

この記事のポイント

・CIDRブロックの重複があるとVPC Peering接続要求が通らない（設計段階で分割する）
・PeeringがActiveでも双方のルートテーブルに相手CIDR宛の経路を追加しないと疎通しない
・セキュリティグループはPeering先のCIDRブロックを送信元として明示的に許可する
・enableDnsSupport・enableDnsHostnamesを有効にするとVPC間でDNS名前解決が可能になる

この記事のポイント

・Draw.ioのAWS公式シェイプセットを使えばマルチAZ冗長構成を正確に図示できる
・アーキテクチャ図例は「正常時フロー（実線）」と「障害時フロー（赤破線）」の2層で描く
・VPC・サブネット・セキュリティグループの3層境界を図に含めることが設計の基本
・NATゲートウェイはAZごとに1台ずつ配置しないとAZ障害時にアウトバウンド通信が止まる

この記事のポイント

・VPC Latticeは「ビーピーシー ラティス」と読む（Lattice=格子・網目構造）
・Service Network・Service・Target Groupの3層構造がコア設計
・App Mesh廃止の公式移行先として推奨されている後継サービス
・IAMのAuth Policyで複数VPC・マルチアカウントの通信を制御できる

この記事のポイント

・AWS VPC Latticeはクロスアカウント・クロスVPC間のサービス通信をフルマネージドで制御できる
・マルチAZ冗長設計はターゲットグループに複数AZのターゲットを登録しヘルスチェックを有効化して構成する
・加重ルーティングでBlue/Greenデプロイやカナリアリリースを実現できる
・障害調査はアクセスログをCloudWatch Logsに出力してターゲット別のエラー状況を確認する

この記事のポイント

・AWSサービスのSLAはサービス・構成ごとに99.5%～99.999%と大きく差がある
・S3の99.999999999%は「耐久性」でありSLA（可用性）は99.99%
・RDSはマルチAZでSLA 99.95%、シングルAZは対象外
・Route 53は唯一100% SLAを掲げ、DNS冗長化の要として機能する

この記事のポイント

・S3 StandardはAZ間分散で99.99%可用性を提供する
・One Zone-IAは単一AZ障害でデータが失われるリスクがある
・Gateway型VPCエンドポイントは全AZのルートテーブルに追加が必要
・CRRで別リージョンへレプリケーションしRPOを担保できる

この記事のポイント

・マルチAZ配置でAZ障害時の影響をインスタンス単位に局所化できる
・Auto ScalingグループはAZバランスの「再分散」を自動で行う設定が重要
・ヘルスチェックはEC2タイプよりELBタイプで設定するのが実務の定番
・最小台数は「使用AZ数以上」にするのが可用性設計の基本指針

この記事のポイント

・アーキテクチャ図の各構成要素がTerraformのどのresourceに対応するかを整理
・VPC基本構成・マルチAZ・3層WebのサンプルをHCLコードとセットで解説
・図からコードを読む際の「AZ境界」「サブネット分離」の見方を具体的に説明
・設計ミスを事前に防ぐためのアーキテクチャ図チェックポイントも掲載

この記事のポイント

・タグキーは小文字・ハイフン区切り（env / project / team）で統一するのが業界標準
・VPCのNameタグは vpc-{env}-{project}-{連番} 形式で環境と用途を即座に識別できる設計にする
・マルチアカウント環境では account-alias・ou-path を必須タグとして設計段階から定義する
・SCPとIAMポリシー条件キーを組み合わせて、タグなしリソースの作成を強制ブロックできる

この記事のポイント

・aws resourcegroupstaggingapi get-resources でタグ条件を指定してリソース一覧を取得できる
・Tag Editor はコンソールから複数リージョン・複数サービスを横断検索できるGUIツール
・Resource Groupsでタグ条件をグループ保存するとSystems Managerとの連携が容易になる
・マルチAZ設計では Environment / AZ / Service の3軸タグが運用効率を大きく向上させる

この記事のポイント

・aws providerのdefault_tagsで全リソースに共通タグを自動付与できる
・環境・システム・コスト配分の3軸タグ体系でCost Explorer精度が向上する
・variablesとtfvarsを組み合わせてAZ別リソースのタグを一貫管理できる
・tags = {}上書きによってdefault_tagsが消えるトラブルへの対処法も解説する

この記事のポイント

・AWSタグはリソース作成時に設計しないと後から修正が困難
・Cost Explorerはタグ有効化（Cost Allocation Tags）が必要
・マルチAZのVPC設計ではNAT GW・ALBにもタグが必須
・SCPでタグ付け忘れをポリシーとして防止できる

この記事のポイント

・AWSアーキテクチャ図はVPC境界→サブネット→リソースの順に描くと整理しやすい
・draw.ioで公式AWSアイコンを使うと構成要素の役割が視覚的に伝わる
・aws ec2 describe-vpcsコマンドで実態を随時確認して図と突き合わせる
・Notionのデータベースビューで構成要素・変更履歴・メンテ手順を一元管理できる

この記事のポイント

・サービス境界ごとにサブネット分離しSGで通信経路を明示的に制限する
・ECS FargateタスクはプライベートサブネットへデプロイしNATで外部と通信する
・サービス間通信はService ConnectまたはALB（内部）で制御できる
・VPC CIDRはFargateタスク数を考慮しサブネットは/24以上を確保する

この記事のポイント

・Step FunctionsのRetryにJitterStrategy: FULLを加えると分散リトライになる
・Catchで全エラーを拾い、エラー内容をResultPathに保存して後続処理へ渡せる
・Lambda関数はべき等性設計（DynamoDB条件付き書き込み）で二重実行を防ぐ
・VPC Lambdaは複数AZのサブネットを指定することでマルチAZ冗長になる

この記事のポイント

・AWS RAGはBedrock（LLM・Embedding）＋OpenSearch Serverless（ベクターDB）＋Lambdaの3層構成
・LambdaからBedrockとOpenSearchへはVPC Interface Endpointで閉域通信を実現する
・セキュリティグループはSG ID参照でLambda->VPCエンドポイント間のHTTPS 443のみ許可する
・OpenSearch ServerlessはネットワークポリシーでVPC限定アクセスに設定する

この記事のポイント

・AWSの主要アーキテクチャパターンは3層Web・サーバーレス・イベント駆動・マイクロサービスの4種類
・トラフィック特性・開発体制・コスト構造の3軸で選定基準を整理できる
・単一パターンに縛られず複数パターンを組み合わせるのが現場の実態
・パターン選択の前に「変化しやすい箇所」と「安定している箇所」を分けることが設計の出発点

この記事のポイント

・AWSアーキテクチャ図ツールはDraw.io（GUI）・Diagrams（Python）・cdk-diaの3つが主流
・DiagramsはPip1コマンドで導入し、Pythonコードでマルチ構成図を自動生成できる
・cdk-diaはCDKスタックからVPC/ELB/EC2の関係図を自動出力し、設計書との乖離を防ぐ
・ツール選定は「使うIaCツール」と「図の目的（説明用 vs 仕様書）」で決まる

この記事のポイント

・LucidchartにはAWS公式シェイプライブラリが内蔵されており無料プランでも利用できる
・VPC・パブリックサブネット・プライベートサブネットをグループ化して構成を視覚的に整理できる
・マルチAZ冗長構成はAZ-a/AZ-cに同構成を複製しALBでルーティングする形が基本テンプレート
・設計図はリンク共有でレビュー依頼でき、変更履歴もバージョンとして保存できる

この記事のポイント

・踏み台EC2にはIAMユーザーのアクセスキーではなくIAMロールを割り当てるのが鉄則
・ロールのアクセス許可はSSM Session Manager最低限＋必要なポリシーのみに絞る
・MFA必須条件（aws:MultiFactorAuthPresent）でなりすましリスクを下げる
・CloudTrailで踏み台操作ログを残し、いつ誰が何をしたかを追跡可能にする

この記事のポイント

・aws ssm ファイル転送は「S3 バケット仲介 + SSM Session Manager」が最も安全な設計
・転送データは KMS カスタマーキーで暗号化し S3 バケットポリシーで VPC 外アクセスを遮断する
・EC2 インスタンスロールに S3 読み書き権・KMS 復号権・SSM マネージドポリシーを付与する
・VPC に S3 Gateway Endpoint と SSM Interface Endpoint を設定しインターネットを経由しない

この記事のポイント

・AWS SSM InventoryでWindowsのアプリ・サービス・レジストリを自動収集できる
・インターネット不要の構成はInterface型エンドポイント3つでマルチAZ冗長化できる
・State ManagerのInventory関連付けでタグ指定の全インスタンス一括適用が可能
・収集データはS3+Athenaで横断クエリし、ライセンス台帳の自動更新に活用できる

この記事のポイント

・SSM AutomationはEC2操作の実行ログがSystems Managerコンソールに残り監査対応にも使える
・EventBridgeスケジューラのcron式でJSTタイムゾーン指定（Asia/Tokyo）が可能
・プライベートサブネット構成ではVPCエンドポイント3本でNATゲートウェイが不要になる
・IAMロールは「SSMAutomationRole」と「EventBridgeSchedulerRole」の2つが必要

この記事のポイント

・SSM Association = State ManagerによるDocumentの定期実行設定
・AWS-RunPatchBaselineでマルチAZパッチ適用を自動化できる
・Rate Controlで同時適用を25%に絞りローリング適用が可能
・PatchGroupタグで環境ごとにターゲットを柔軟に絞り込める

この記事のポイント

・aws ssm start-session でプライベートサブネットのRDS/Redisにローカル接続できる
・VPCエンドポイントは ssm・ssmmessages・ec2messages の3本が必要
・IAMポリシーはドキュメント名とインスタンスIDをResourceで限定して最小権限にする
・セキュリティグループの22番・3306番・5432番の受信ルールは不要になる

この記事のポイント

・SSM DocumentはEC2への手順をYAMLで定義し再利用できる「実行設計図」
・create-documentコマンドで登録しsend-commandで複数AZに一括適用できる
・ドキュメントのバージョン管理により手順変更を安全にロールバックできる
・タグフィルターにMaxConcurrencyを組み合わせて段階展開リスクを制御できる

この記事のポイント

・aws ssm start-sessionコマンドで踏み台なしにプライベートEC2へ接続できる
・ポートフォワーディングでプライベートサブネット内のRDS・Redisへも到達できる
・~/.ssh/configのProxyCommand設定でSSHワークフローをそのまま流用できる
・VPCエンドポイント3本でインターネット非公開のままSSMが動作する

この記事のポイント

・aws ssm send-command でタグ指定した複数EC2に同時実行できる
・IAMロールとSSM Agentで踏み台不要・SSH不要のセキュア実行が可能
・MaxConcurrency/MaxErrorsでリスクをコントロールできる
・get-command-invocationでインスタンス単位に結果確認できる

この記事のポイント

・aws ssm get-parameterでパラメータを環境ごとに安全取得できる
・/dev/, /stg/, /prod/ のパス設計でdev/stg/prod環境を完全分離する
・SecureStringは--with-decryptionオプションで復号して取得する
・IAMポリシーのパスプレフィックス制限で環境間の誤アクセスを防げる

この記事のポイント

・aws ssm agentにはssm・ssmmessages・ec2messagesの3エンドポイントが必要
・エンドポイント作成時は「プライベートDNS名を有効化」が必須設定
・IAMインスタンスプロファイルにAmazonSSMManagedInstanceCoreポリシーを付ける
・DNS解決がプライベートIPになっているかがOffline原因の切り分け起点

この記事のポイント

・aws ssm start-session は踏み台なしでプライベートサブネットのEC2に接続できる
・マルチAZ構成では全AZのEC2に同じIAMインスタンスプロファイルを付けるのが基本設計
・クロスアカウント接続はExternalId付き信頼ポリシーとSTSロール引き受けで実現する
・プライベートサブネットにはssm・ssmmessages・ec2messagesの3エンドポイントが必要

この記事のポイント

・aws fis コマンドでEC2停止やRDSフェイルオーバーを安全に再現できる
・StopCondition（CloudWatchアラーム）で実験の暴走を防ぐ安全装置を付けられる
・フェイルオーバーのRTOをCloudWatchで実測し冗長設計の穴を発見できる
・EC2タグとAZフィルターで障害注入対象を細かく絞り込める

この記事のポイント

・EICEはVPCに作成するエンドポイントで踏み台・VPN不要のSSH接続を実現できる
・aws ec2-instance-connect open-tunnel をSSH ProxyCommandに指定するだけで導入できる
・接続の認可はIAMポリシーで制御し、EC2にSSMエージェントのインストールは不要
・セキュリティグループでEC2へのSSHをEICEのみに制限して最小権限を設計する

この記事のポイント

・各サブネットから先頭4つ＋ブロードキャストの計5つのIPが予約されて使えない
・.0はネットワーク、.1はVPCルーター、.2はAmazon DNS、.3は将来用
・/27（32IP）なら使用可能は27個、/28（16IP）なら11個になる
・必要なホスト数に5を足してCIDRを決めるのが設計の鉄則

この記事のポイント

・Reachability AnalyzerはVPN/Peering経由にも対応
・aws ec2 create-network-insights-pathでパス定義
・ExplanationCodeで遮断箇所を即座に特定できる
・マルチAZ冗長設計の事前検証にも活用できる

この記事のポイント

・MSKブローカーの分散配置はサブネット指定で決まる——AZが異なる3つのサブネットを必ず渡す
・aws kafka create-cluster-v2 の --broker-node-group-info でサブネットIDをAZバラバラに3つ指定する
・レプリケーション係数3＋min.insync.replicas=2でAZ1つ消失してもデータ損失ゼロを実現できる
・ブローカーエンドポイントはTLSポート9094が推奨——sg設定とDNS疎通の確認で接続問題の大半は解消する

この記事のポイント

・Amazon Data FirehoseはAZ障害を意識せず使える設計（マルチAZ組み込み）
・バッファリング間隔（60秒～15分）の設定がコストと遅延のトレードオフになる
・S3プレフィックスをHive形式に設計するとAthenaのスキャンコストを削減できる
・CloudWatch Logsサブスクリプションフィルターとの組み合わせが最もシンプルな構成

この記事のポイント

・RDS ProxyはLambdaの同時起動による接続数爆発をコネクションプールで解消する
・プライベートサブネットにマルチAZ配置し、RDSフェイルオーバー時の切断を10秒以内に短縮できる
・Secrets ManagerでDB認証情報を管理し、IAMロールでProxyに参照権限を付与する
・LambdaはProxyエンドポイントへの接続文字列変更だけで利用でき、コード改修は不要

この記事のポイント

・ALBの加重ルーティングはターゲットグループに0～999の重みを付けて実現する
・aws elbv2 modify-ruleで重みをリアルタイムに変更できるため再デプロイ不要
・マルチAZ環境ではCross-Zone Load Balancingの動作確認と各AZへの均等登録が重要
・問題発生時は重みを0/100に戻すだけで即座にロールバックが完了する

この記事のポイント

・VPCの/56 IPv6 CIDRはAmazon提供の無料ブロック（GUAアドレス）を使う
・パブリックサブネットはIGW、プライベートサブネットはEgress-Only IGWでIPv6経路を分ける
・セキュリティグループのIPv4ルール（0.0.0.0/0）はIPv6に自動適用されない——別途::/0の追加が必須
・EC2へのIPv6自動割り当てはサブネット側でassign-ipv6-address-on-creationを有効化する

この記事のポイント

・Patch ManagerはSSM AgentとIAMロールがあれば追加インストール不要で動く
・パッチグループはEC2タグで環境（本番/検証）を分離する設計が基本
・メンテナンスウィンドウでスキャンとインストールを別タスクに分けると安全
・コンプライアンス確認でパッチ未適用インスタンスを一覧で把握できる

この記事のポイント

・eb init → eb create の2ステップで環境が作成できる
・ローリングデプロイは .ebextensions/deploy.config の DeploymentPolicy で制御する
・マルチAZ構成は Availability Zones と MinSize を組み合わせて設計する
・VPC統合は eb create --vpc.id / --vpc.ec2subnets / --vpc.elbsubnets で指定する

この記事のポイント

・VPCのCIDRブロックは作成後に変更不可。最初の設計が全てを決める
・複数VPCを計画するなら10.x.0.0/16形式の連番プランニングが基本
・マルチAZの3層サブネット設計は/24 x 9サブネットが現場の標準パターン
・セカンダリCIDRで既存VPCを無停止拡張でき、最大5ブロックまで追加できる

この記事のポイント

・ステートマシンはTask・Parallel・Wait・Choiceなど8種のStateで構成される
・直列連鎖は "Next" で次Stateを指定し、"End:true" で終端を定義する
・Parallel Stateで複数Lambdaを並列実行しWall Clockを短縮できる
・Retry/Catchでエラーハンドリングを宣言的に定義、コード修正不要

この記事のポイント

・Network FirewallはFirewall Subnetを作り、ルートテーブルを変更してインライン配置する
・マルチAZ構成ではAZごとに1つのFirewall Endpointが必要（Traffic Asymmetry防止のため）
・ルールグループはステートレス（5-tuple）とステートフル（Suricata互換）の2層に分かれる
・ドメインリストルールでアウトバウンドのHTTPS通信をFQDN単位で許可リスト管理できる
・サードパーティのNGFWをインライン挿入したい場合はGWLB（Gateway Load Balancer）を使う

この記事のポイント

・1スタックにすべて詰め込むとデプロイ遅延とBlast Radiusが拡大する
・VPC層・セキュリティ層・アプリ層の3層分割がスタック設計の基本型
・スタック間のリソース参照はStack Propsで型安全に渡す
・環境差分（AZ/CIDR）はcdk.jsonのContextに定義して--contextで上書き

この記事のポイント

・CloudFront前段WAF（スコープ: CLOUDFRONT）はus-east-1で作成する
・ALB前段WAF（スコープ: REGIONAL）はALBと同一リージョンで作成する
・マネージドルール追加後はCountモードで正規リクエストへの影響を確認する
・誤検知はRuleActionOverrideでルール単位に細かく調整できる

この記事のポイント

・aws ram create-resource-share でサブネットを参加アカウントに公開できる
・Organizations連携を有効にすると招待承諾が不要になり運用が簡単になる
・ルートテーブル・NACLはオーナー管理、セキュリティグループは参加側が設定する役割分担が基本
・AZ冗長のためマルチAZ分のサブネットをまとめて共有するのが実務上の鉄則

この記事のポイント

・Inspector v2はSSM Agent経由でEC2のCVEをエージェントレスでスキャンできる
・aws inspector2コマンドで有効化からスキャン結果取得まで操作できる
・CVSSスコアと「exploitability」の組み合わせで修正優先度を判断する
・SSMパッチマネージャーと組み合わせることで検出から修正まで自動化できる

この記事のポイント

・AWS KMSには「AWSマネージドキー」「CMK」「データキー」の3層構造がある
・CMKはキーポリシーとIAMポリシーの両方が揃って初めてアクセスできる
・EC2 EBSのデフォルト暗号化はアカウント・リージョン単位で一括有効化できる
・キーローテーションはCMKで年1回の自動ローテーションを必ず有効にする

この記事のポイント

・aws ec2 create-vpc-endpoint-service-configurationでエンドポイントサービスを作成する
・NLBをバックエンドにすることでマルチAZ冗長のプライベートサービスを実現できる
・コンシューマー側はInterface型エンドポイントを作成するだけでVPC間接続が可能
・VPCピアリングと異なりCIDRアドレスが重複していても接続できる

この記事のポイント

・VPC内でカスタムドメインを使うにはプライベートホストゾーンが必要
・enableDnsSupportとenableDnsHostnamesを両方ONにしないと解決されない
・マルチVPCや別アカウントのVPCにも追加の関連付けで対応できる
・オンプレミスとの双方向DNS解決はResolver Endpointで実現する

この記事のポイント

・HTTP API（V2）はREST APIより70%安く、aws apigatewayv2コマンドで一気に構築できる
・Lambdaプロキシ統合ではstatusCode+bodyを返す形式を守ることが最重要
・$defaultルートキーで全パスをLambdaにキャッチオールできる
・CognitoオーソライザーでJWT認証をLambda不要で設定できる
・スロットリングとアクセスログは本番公開前に必ず設定する

この記事のポイント

・aws secretsmanager コマンドでシークレットを作成・取得できる
・EC2にIAMロールを付与して認証情報を安全に参照する設計ができる
・RDSパスワードの自動ローテーションをLambdaなしで設定できる
・Secrets ManagerとSSM Parameter Storeの使い分け基準が判断できる

この記事のポイント

・MySQLレプリケーションはbinlogを介してソースからレプリカへ更新を自動同期する仕組み
・binlogポジション方式はFile名+位置で同期、GTID方式は一意IDで自動追跡する
・MySQL 8.4ではCHANGE MASTER TO等の旧構文が廃止。新コマンドへの対応が必須
・SHOW REPLICA STATUSでIO/SQLスレッド両方がYesなら正常動作している

この記事のポイント

・DynamoDBは設定不要でマルチAZ冗長化済み。スキーマレスでスケールが自動
・パーティションキーはカーディナリティが高いものを選ぶのが設計の基本
・グローバルテーブルで複数リージョンへの自動レプリケートが実現できる
・最初はオンデマンド課金で動かし、安定後にプロビジョンドへ移行するのが定石

この記事のポイント

・Auroraはクラスターボリュームを3AZ×6コピーで共有し単一障害に強い
・aws rds create-db-clusterでマルチAZクラスターを作成できる
・failover-db-clusterで手動フェイルオーバーをテストする
・Global Databaseでリージョン障害に備えRPO約1秒を設計できる

この記事のポイント

・ALBはL7（HTTP/HTTPS）、NLBはL4（TCP/UDP）で動作する
・パスベースルーティング・WAF連携が必要ならALB一択
・固定IP・低レイテンシ・DB/MQ接続ならNLBが適切
・マルチAZ設定はaws elbv2コマンドで複数サブネットを指定する

この記事のポイント

・ クラスター配置は低レイテンシ優先（HPC・ML向け）、スプレッドは最大限の物理分離
・ スプレッドはAZあたり最大7インスタンスのハードリミットに注意
・ パーティション配置はHadoop・Kafka向けで7パーティション/AZまで設定可能
・ Placement Groupは起動時のみ指定可能（既存の実行中インスタンスへの後付けは不可）

この記事のポイント

・AWSのEC2はハードウェアを「仮想マシン」として提供するクラウドサービス
・オンプレミスと最も大きく違うのは「責任共有モデル」とコスト構造
・amazon linuxはEC2向けに最適化されたLinuxディストリビューション
・AWSを使いこなすにはLinuxのファイル・プロセス・ネットワーク管理の基礎が必須

この記事のポイント

・EFSはNFSv4を使い、複数EC2から同時に読み書きできる共有ストレージ
・マウントターゲットを複数AZに配置することでAZ障害時も継続してアクセスできる
・aws efs create-file-systemで作成し、各AZのサブネットにマウントターゲットを設ける
・パフォーマンスモードはGeneral Purpose、スループットはElasticを最初に選ぶのが現実解

この記事のポイント

・EKSのマルチAZ設計はノードグループのAZを3つに分散させることが基本
・eksctlのClusterConfig YAMLでVPC・ノードグループの設定を一括定義できる
・プライベートサブネットにはEKS用タグ（kubernetes.io/role/internal-elb: 1）の設定が必須
・PodへのAWS権限はIRSA（IAM Roles for Service Accounts）で最小権限を実現する

この記事のポイント

・CloudFormationのテンプレートはResources（必須）・Parameters・Outputsの3セクションが基本
・VPC + マルチAZサブネット + ALBの冗長構成は1つのYAMLテンプレートで定義できる
・aws cloudformation deployコマンドで変更セットを確認してから安全に更新できる
・ドリフト検知（detect-stack-drift）でコンソールからの手動変更を検出してテンプレートとのズレを把握できる
・スタック削除時の誤消去はDeletionPolicyとTerminationProtectionで防ぐ
・ネストされたスタックでネットワーク層・アプリ層・DB層を分割管理できる

この記事のポイント

・AWS Client VPNで個々のデバイスからVPCへセキュアに接続できる
・相互TLS認証ではEasy-RSAで証明書を発行しACMに登録する
・スプリットトンネルを有効にするとVPC宛の通信のみVPN経由になる
・複数AZのサブネットに関連付けることで冗長性を確保できる

この記事のポイント

・CodePipeline・CodeBuild・CodeDeployの3役割を正しく理解して設計する
・buildspec.ymlとappspec.ymlがCI/CDパイプラインの動作を定義するコアファイル
・ECS Blue/Greenデプロイでゼロダウンタイムリリースと即座のロールバックを実現できる
・IAM権限ミスがパイプライン停止の最大原因、最小権限設計で事前に防ぐ

この記事のポイント

・AWS Direct Connectは専用物理回線でAWSに直結し帯域と遅延が安定する
・VIF 3種類（Private/Public/Transit）の使い分けとDX Gatewayの役割を押さえる
・本番環境はDX＋VPNのアクティブ・スタンバイ冗長構成が定石
・CLIのdescribe-*コマンドでBGP状態と接続状態をリアルタイムに確認できる

この記事のポイント

・Anycast IPで最近傍のAWS PoPからバックボーン経由でルーティングする
・アクセラレーター→リスナー→エンドポイントグループ→エンドポイントの4階層で構成する
・固定IPのままフェイルオーバーは約30秒で完了（DNSキャッシュに依存しない）
・Route 53フェイルオーバーより高速な切り替えが必要な場面に向く

この記事のポイント

・Site-to-Site VPNは1つのVPN接続に2本のIPsecトンネルを持ち、AWSが冗長性を提供する
・BGPを使えばトンネル障害時に自動で経路切り替えが起きる（静的ルーティングは手動対応が必要）
・CGW・VGW・VPN接続の3ステップをCLIで構成しルート伝播で経路をVPCに伝える
・VpwTelemetryのStatusとAcceptedRouteCountでトンネルとBGPの状態を最初に確認する

この記事のポイント

・aws ec2 create-flow-logsでVPC・サブネット・ENIの3レベルで有効化できる
・actionフィールドがREJECTの記録を絞り込むと不審アクセスを素早く特定できる
・S3送信はコストが低く長期保存向き、CloudWatch Logsはリアルタイム分析に強い
・traffic-type REJECTから始めて必要に応じてALLに拡張するのがコスト効率のよい設計

この記事のポイント

・NAT GatewayはパブリックサブネットにEIPと共に作成する
・プライベートサブネットのルートに0.0.0.0/0→NAT GWを追加する
・可用性確保のためAZごとに1台のNAT Gatewayを配置する
・S3はGateway型VPCエンドポイントで迂回するとコスト削減できる
・VPC Flow Logsを有効にするとNAT GW障害の切り分けが格段に速くなる

この記事のポイント

・ルートテーブルの0.0.0.0/0がIGWを向いているかで「パブリック」かが決まる
・プライベートのアウトバウンドはNATゲートウェイ（パブリックサブネット配置）で確保
・セキュリティグループはL3/4止まり——サブネット設計と組み合わせて多層防御を作る
・aws ec2 create-subnetとルートテーブル設定でCLIから段階的に構成できる

この記事のポイント

・NACLはサブネット単位のステートレスFW、SGはインスタンス単位のステートフルFW
・ステートレスのNACLはエフェメラルポートのアウトバウンド許可が必須
・「NACL=不審IP遮断」「SG=インスタンス間の通信制御」で役割を分担する
・SGはSG IDを参照したチェーン設計にすることで、IP変動やオートスケーリングに強くなる
・マルチAZ構成では同じ役割のサブネットに同じNACLを関連付けてルール不一致を防ぐ
・L7のドメイン・ペイロード検査が必要なときはNetwork Firewallを追加する
・Network Firewallのステートフルルールは5タプル・ドメインリスト・Suricata互換の3形式から選べる
・StatefulEngineOptionsはSTRICT_ORDERを指定してルール評価順を明示的に制御する
・複数VPC環境は検査VPC（Inspection VPC）パターンでFirewallをTransit Gateway経由で集中配置できる

この記事のポイント

・ACMはAWSが提供する無料SSL証明書マネージドサービスで、ALB・CloudFrontに適用できる
・Route 53のDNS検証でCNAMEレコードを追加すれば証明書の発行は最短数分で完了する
・ALBのHTTPS（443）リスナーにACM証明書をアタッチするだけでHTTPS化が完成する
・ACM証明書の有効期限は13ヶ月で、Route 53使用時は自動更新が有効になる

この記事のポイント

・Gateway型は無料でS3へのルートを自動追加する
・Interface型はオンプレ・他VPCからも到達できるが有料
・Gateway型への切替えでNATコストを大幅削減できる
・接続確認はaws s3 lsで即座にテストできる

この記事のポイント

・RTOは「何時間以内に復旧するか」、RPOは「どこまでのデータを戻せるか」を決める指標
・DR戦略はバックアップ&リストア・パイロットライト・ウォームスタンバイ・マルチサイトの4段階
・RTO/RPO目標が短いほどコストは指数関数的に上昇する
・まずRTO/RPO目標をビジネス側と合意してから戦略を選ぶ順序が正しい

この記事のポイント

・Well-Architected Frameworkは6つの柱でAWSアーキテクチャを総合評価する公式指針
・Well-Architected Toolで質問に答えるだけでHRIs（高リスク課題）を自動抽出できる
・改善の優先順位はリスクの大きさと対応コストのバランスで判断する
・フレームワークは一発チェックではなく四半期ごとのPDCAサイクルとして活用する

この記事のポイント

・GuardDutyは脅威検知エンジン、Security Hubはセキュリティ状態の一元集約管理
・GuardDutyはコンソール数クリックで有効化でき、S3・EKS・マルウェア保護も追加可能
・検出結果はEventBridge→SNS→Lambdaのパイプラインで自動通知・対応できる
・マルチアカウントはOrganizations委任管理者でGuardDutyとSecurity Hub両方を一元管理する

この記事のポイント

・SQSは1対1のキューイング、SNSは1対多のファンアウト配信
・SNS+SQSの組み合わせでメッセージの蓄積とファンアウトを両立できる
・VPCエンドポイントでSQS/SNS通信をAWSネットワーク内に閉じセキュリティを強化する
・FIFOトピックとFIFOキューは必ずセットで使う（混在不可）

この記事のポイント

・Lambda＋EventBridgeでEC2夜間自動停止をサーバーレスで実装できる
・Python boto3のタグフィルタで本番EC2への誤操作を防ぐ設計にする
・EventBridge cronはUTC基準（JSTから9時間引いた値）で設定する
・IAMはec2:StopInstances・CreateSnapshot・DescribeInstancesを最小限付与

この記事のポイント

・EBS=ブロックストレージ（EC2に直接アタッチ）、EFS=共有NFS、S3=オブジェクトストレージが3者の基本的な違い
・EC2のOSやDBにはEBS、複数インスタンスでファイル共有するならEFS、APIアクセスでよいならS3を選ぶのが基本判断軸
・コスト比は概算でS3＜EBS＜EFSの順。高機能になるほど割高になる
・AZをまたぐ冗長化要件はEFSとS3が自動対応。EBSは単一AZ内にとどまる

この記事のポイント

・CloudTrailはAPIコール全記録、ConfigはAWSリソースの設定状態変化を記録する
・2つを組み合わせて「変更の操作者」と「リソースの変化前後」を突き合わせた証跡が完成する
・証跡はマルチリージョン＋S3永続保存が前提。改ざん防止にはLogFileValidationを有効化する
・Config Rulesでコンプライアンス違反を自動検出し、修復アクションまで自動化できる

この記事のポイント

・AWS Backupでバックアッププランを1箇所で管理できる
・EC2・RDS・EFSをタグで一括割り当て可能
・バックアップボールトでリカバリポイントを統合管理
・復元テストを定期実施してRPO/RTOを検証することが重要

この記事のポイント

・Cost Explorerのレコメンデーション機能でSavings Plans購入額の目安がわかる
・Compute Savings Plansは1年・前払いなしで最大66%割引、新規にはこれを選ぶ
・スポットインスタンスは最大90%割引、中断2分前通知をメタデータAPIで検知できる
・Reserved InstancesよりSavings Plansのほうが柔軟で新規購入に向いている

この記事のポイント

・AWS OrganizationsはOU（組織単位）でアカウントを階層管理し、SCP（サービスコントロールポリシー）で全体統制する
・SCPはIAMポリシーの上位にある制御層で、AdministratorAccessでも突破できないガードレールを作れる
・OU設計は「本番/開発/セキュリティ/サンドボックス」の4層分離が実務の標準パターン
・Consolidated Billingで全アカウントのコストを一元集計し、RIの割引も組織全体で共有される

この記事のポイント

・AWS WAFはSGと異なりHTTPリクエストの中身（L7）を検査してブロック判定できる
・WebACLにマネージドルールを追加するだけでSQLi・XSS・Bot攻撃を即座にブロック可能
・レートベースルールで同一IPからの過剰アクセスを5分単位で自動遮断できる
・まずカウントモードで誤検知を確認し、段階的にBLOCKへ移行するのが安全な設計手順

この記事のポイント

・バージョニング有効化は put-bucket-versioning --status Enabled の1コマンド
・削除しても削除マーカーが残るため list-object-versions で復元できる
・ライフサイクルポリシーで古いバージョンをGlacierに移行してコストを削減
・CRRはバージョニングが前提条件。既存オブジェクトには自動適用されない点に注意

この記事のポイント

・aws ssm start-session でSSHなし・鍵なしでプライベートサブネットのEC2に接続できる
・IAMロール（AmazonSSMManagedInstanceCore）のアタッチが唯一の前提条件
・Run Commandでタグ指定した複数EC2へ同時コマンドを実行できる
・Parameter Storeは無料で設定値管理向け、Secrets Managerはパスワード自動ローテーションが必要な場合に使い分ける

この記事のポイント

・マルチAZ構成は --automatic-failover-enabled --multi-az-enabled の2オプションで作成する
・プライマリ障害時はリードレプリカが自動昇格（約1～2分）・アプリ側の設定変更は不要
・リーダーエンドポイントで読み取りをレプリカに分散し、レプリカ追加でスループットを線形拡張できる
・CloudWatch の ReplicationLag と CacheHitRate を常時監視して本番品質を担保する
・AUTHトークンはSecrets Managerに格納し、ハードコードを避けるのが現場の鉄則

この記事のポイント

・CloudWatch Agentがないとメモリ・ディスクは取得できない
・IAMポリシー2つをEC2ロールにアタッチするのが設定の前提
・put-metric-alarmでメモリ85%・ディスク80%のアラームを設定
・CloudWatch Logsへのログ集約とERRORフィルターで異常を検知

この記事のポイント

・FargateはサーバーレスでEC2管理が不要。本番用途では最初の選択肢になる
・タスク定義でCPU・メモリ・コンテナ定義・ログ設定を一元管理する
・ECSサービス＋ALBでマルチAZに分散配置してヘルスチェックを自動化する
・maximumPercent=200／minimumHealthyPercent=100でゼロダウンタイムデプロイを実現する
・force_new_deployment=trueを設定するとタスク定義更新時にサービスの再デプロイが自動でトリガーされる
・Auto ScalingはCPU使用率70%をトリガーにするターゲットトラッキングが基本
・実行ロール（起動権限）とタスクロール（アプリ権限）を分離して最小権限を実現する
・デプロイ失敗時はcircuit breakerで自動ロールバックしサービス停止を防ぐ
・TerraformでIaC管理する場合はjsonencodeかテンプレートファイルでコンテナ定義を管理し、lifecycle.ignore_changesでCI/CDと共存する
・ECSはVPC・ALBと別のState（ディレクトリ）に分割して変更頻度の違いを吸収するのが本番設計の鉄則
・コンソールの手動変更は変更履歴が残らず構成ドリフトを招く。Terraformのgit PRでレビューする体制が本番運用の基本
・Terraformモジュール化とfor_eachで複数サービスをDRYに管理できる。modules/ecs_service/に切り出してenvironments/から呼び出す

この記事のポイント

・CloudFrontはエッジロケーションでキャッシュしてレイテンシを削減するCDNサービスです
・S3オリジンにはOAC（Origin Access Control）を使い、S3直接アクセスを必ず遮断する
・オリジングループで5xxエラー時にセカンダリS3へ自動フェイルオーバーさせる
・キャッシュポリシーとCache-Controlヘッダーを組み合わせてTTLを適切に制御する

この記事のポイント

・Route 53はヘルスチェックで向き先を自動切替できる
・フェイルオーバーはPrimary・Secondaryの2レコードで組む
・切り替え速度はTTLとヘルスチェック間隔で決まる
・マルチリージョン構成でリージョン障害にも備えられる

この記事のポイント

・VPCピアリングは2VPC間の1対1接続で推移的ルーティングが効かない
・Transit GatewayはハブになりVPC数が増えても接続数がO(n)で収まる
・3VPC以上またはマルチアカウント運用はTransit Gateway一択
・CIDR設計とルートテーブルの伝播ルールが設計の核心

この記事のポイント

・マルチAZはスタンバイDBへの自動フェイルオーバーで高可用性を実現する
・リードレプリカは読み取り専用の複製で参照負荷を分散する設計パターン
・2つは用途が異なる。可用性=マルチAZ、スケール=リードレプリカが基本
・フェイルオーバー時間は1～2分が目安。ダウンタイムゼロにはならない

この記事のポイント

・IAMユーザー・グループ・ロール・ポリシーの4要素を正確に理解する
・rootアカウントを封印し、IAMユーザーとMFAで運用する初期設定手順
・最小権限の原則を守るグループ設計と、EC2/S3/RDSへのロール付与の実践
・アクセスキーの代わりにIAMロールを使う設計がなぜセキュアかを理解する

この記事のポイント

・ELBがトラフィックを分散し、Auto Scalingが台数を自動調整する
・スケーリングポリシーはまずターゲット追跡を試し、段階制御が必要ならステップに切り替える
・ヘルスチェック失敗時にAuto Scalingが自動でEC2を入れ替える仕組み
・マルチAZ構成にしてはじめて単一AZ障害に耐えられる

この記事のポイント

・VPCのCIDRは作成後に変更できない——最初に余裕を持った/16で設計することが鉄則
・サブネットはパブリック（ALB）・アプリプライベート（EC2）・DBプライベート（RDS）の3層に分ける
・セキュリティグループはALB-SG→EC2-SG→RDS-SGの順にSG参照で連携させる
・S3・DynamoDB向けGateway型VPCエンドポイント（無料）でNATゲートウェイのコストを削減できる
・VPCフローログでACCEPT/REJECTを記録し、SG/NACLの設定検証と通信監査に活用する
・デフォルトVPC＝全サブネットがパブリック。本番は必ずカスタムVPCで設計する

この記事のポイント

・マルチAZはVPCサブネット設計から始まる
・ALB＋Auto Scalingで自動復旧するWeb層を作る
・RDSのマルチAZはプライマリ障害時に自動昇格する
・設計の落とし穴はセッション管理とDNS TTLにある

$ sudo yum update

$ sudo yum update
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
No packages marked for update

＜PR＞手元に置いて学びを深める1冊

実践 Amazon Linux

EC2上でAmazon Linuxのyum updateやパッケージ管理を体系的に学べる一冊。まず無料メルマガで基礎を押さえ、手元に置いてAWS実務力をさらに深めるのに最適。

$ date
Thu Apr 1 05:37:56 UTC 2021

$ $ sudo localectl set-locale LANG=ja_JP.utf8
$ $ source /etc/locale.conf
$ date
2021年 4月 1日 木曜日 05:45:42 UTC