シリーズ振り返り：レイヤー別対応早見表

レイヤーオンプレAWS記事
SSL / 証明書認証局購入・手動更新・手動配置ACM（無料・自動更新）+ CloudFront/ALB 2段終端PART 01
HTTP処理Apache httpd（mod_rewrite 等）ALBルール・WAF・CloudFront Functions・S3PART 02
Java受け渡しmod_jk + AJP → TomcatALB → Spring Boot（組込Tomcat）直接HTTPPART 03
セッションTomcatメモリ・レプリケーションElastiCache Redis（Spring Session）PART 03
帳票/ファイルNAS + Apache / Tomcat経由配信S3 + presigned URL（直接授受）PART 04
非同期帳票生成独自キュー / バッチスケジューラSQS + ECS Worker + SNS通知PART 04
DB接続（AP）HikariCP → Oracle / PostgreSQLRDS Proxy + Aurora（Writer/Reader分離）PART 05
バッチ基盤バッチ専用サーバー + JP1 / cronECS Task / AWS Batch + Step FunctionsPART 06
バッチ×DB競合メンテウィンドウで回避（運用対応）Reader分離・Aurora Clone・時間帯制御PART 06

設計思想の対比

オンプレ：サーバーを管理する
物理・仮想サーバーを「自分のもの」として設定・維持する発想。OSパッチ・ミドルウェア更新・証明書更新・バックアップすべてが運用チームの仕事になる。
AWS：サービスを組み合わせる
マネージドサービスを組み合わせて機能を実現する発想。OSパッチ・フェイルオーバー・スケールはサービスが内包する。設計の重心が「どのサービスを選ぶか」に移る。
オンプレ：台数で冗長化
「同じサーバーを2台置く」が冗長化の基本。障害時は人が検知して切り替える。
AWS：冗長性はサービス内蔵
ALB・Aurora・ElastiCacheは可用性設計が内包されている。追加の「冗長化設計」より、正しいサービス選択と設定が重要になる。
オンプレ：境界防御中心
ファイアウォール・DMZで「外と内」を分ける。内部ネットワークに入ると比較的自由。
AWS：多層防御（ゼロトラスト志向）
IAM・Security Group・WAF・VPC Endpointを層で重ねる。「内部だから安全」という前提を持たない。

「変わる部分」と「変わらない部分」

カテゴリ内容
大きく変わる SSL証明書管理（手動 → ACM自動）
Apacheの機能分解（1つのサーバー → 複数のマネージドサービス）
AJP / mod_jk（完全に不要）
セッション管理（JVMメモリ → Redis共有）
ファイル格納・配信（NAS / Apache → S3 + presigned URL）
バッチ基盤（常時稼働サーバー → 実行時のみ起動）
あまり変わらない Javaコード本体（JDBC・JPA・ビジネスロジック）
HikariCPの設定（接続先が変わるだけ）
JasperReports / iTextの帳票生成コード
SQLの書き方（Aurora = PostgreSQL互換）
Spring Bootの実装パターン全般

💡 「AWSで書き直す」は誤解

Javaのビジネスロジック・DBアクセスコードはほぼそのまま動く。変わるのはインフラ側の設計とデプロイ方式だ。「コードをゼロから書き直す」と思い込んでいるエンジニアが移行に過剰な工数を見積もるケースがある。

移行時のハマりポイント集約

各記事のハマりポイント早見表
PART 01 SSL
  ・CloudFront用ACM証明書は us-east-1 で発行（ALBは各リージョン）
  ・DNS検証を選ばないと自動更新が機能しない

PART 02 HTTP
  ・ALBリスナールールは正規表現不可 → 複雑なRewriteはCloudFront Functions へ
  ・ALBルールの優先度（数値が小さい方が先に評価される）に注意

PART 03 Java受け渡し
  ・AJPポート（8009）の明示的な無効化を確認
  ・セッションに格納するオブジェクトの Serializable 実装を確認

PART 04 帳票
  ・S3バケットのCORSポリシー設定漏れに注意
  ・presigned URLはリージョンを明示して生成する

PART 05 DB操作
  ・RDS Proxy + Prepared Statement のピン留め問題
  ・HikariCPの keepalive-time をProxyタイムアウトより短く設定

PART 06 バッチ
  ・Step Functions の HeartbeatSeconds を長時間バッチに合わせる
  ・Aurora Clone はリージョンをまたげない

次のステップ

本シリーズで扱ったのは「オンプレの機能をAWSに対応させる」という移行の視点だ。AWSネイティブな設計を追求するには、以下のテーマが次のステップになる。

IaC（Infrastructure as Code）
Terraform / AWS CDK でインフラをコードで管理する。手動設定を排除し、環境再現性と変更の追跡可能性を確保する。
CI/CD パイプライン
CodePipeline / GitHub Actions でコンテナビルド・ECRプッシュ・ECSへのBlue/Greenデプロイを自動化する。
監視・可観測性
CloudWatch Logs・Metrics・X-Ray でアプリ・インフラの統合監視を構築する。オンプレのZabbix / JP1に相当する仕組みをマネージドで実現する。
コスト最適化
Compute Savings Plans・Reserved Instance・Fargate Spot の活用。AWS Cost Explorer でコストの可視化と分析を継続する。

✅ シリーズ完結

全8記事（PART 00〜07）を通じて、オンプレの大規模JavaシステムをベースにしたAWS構成の「読み替え」を解説した。インデックスページから各記事に戻れる。