LoginSignup
0

More than 1 year has passed since last update.

posted at

【AWS】基礎的Webアプリ基盤作ってみた


本記事は Advent Calendar 2020 の2020/12/10分です。
※Advent Calendar 2020 へはHTCのチームメンバー5人で
毎日日替わりで投稿させていただいていますので、暇なときに覗いてください。
※HTCの紹介は本イベント1日目の投稿をご参照ください。


文系学部卒SIer新人のかいとです。

今回は、AWS初心者の私がWebアプリのシステム基盤を作成しましたので、
ネットワーク制御を中心に個人的な備忘録&
初心者でもこんなこと出来るのかという気付きを自分と同じような初心者に提供できればと思います!
※本記事は所属する会社の大先輩よりご教示いただいたものになります。
image.png

はじめに

そもそも、基盤とは?と思う方もいらっしゃると思います。
アプリの駆け出しエンジニアである私はそうでした。。。
ただ、この記事を見て、基盤に最低限必要なサービスと、利用用途を理解していただければ、概要は理解できると思います!
(今回は、詳細な各サービスの設定は省き、個人的にベストプラクティスが分からないネットワーク制御周りに関して書きます。)

それでは、作成した基盤のアーキテクチャ(↓)を念頭に置いていただき、説明に移りたいと思います!
image.png
それでは、早速備忘録スタートです~

利用サービス/使用用途

  • IAM:ユーザーや、サービス間のロール権限
  • VPC:ネットワーク
    • サブネット:ネットワークの中のネットワーク的なもの。
    • ルートテーブル:EC2各インスタンスにひもずける。ルートテーブルには入力し許可したIPが通れる。
    • インターネットゲートウェイ:インターネットとの通信/外部アクセスを仲介する。これがアタッチされたルートテーブルに紐づいたサブネットはプライベートサブネットになる。
    • セキュリティグループ:インスタンス(EC2とか)単位でネットワークの制御をかける。プロトコル/IPなど選択した通信を許可する。
    • ネットワークACL:サブネット単位でネットワーク制御をかける。
  • EC2:Webサーバー
    • Elastic IP:グローバルIPアドレス。EC2はデフォルトでパブリックなIPしかつけることができないので、これを代用。
    • ELB(ALB):ロードバランサー。下記ターゲットグループにアタッチされたEC2にアクセスを分散・冗長化を図る。
    • ターゲットグループ:ALBに使用。ターゲットとなるEC2群をまとめるもの。
    • キーペア:EC2の秘密鍵に使用。
  • RDS:データベース
    • サブネットグループ:DBのMulti-AZ化に必要。要は可用性が上がる。(サブネットも別途作成する)
  • Route53:ドメイン取得
  • ACM:https通信用の証明書発行

ネットワーク

ここでは、社内ネットワークからのアクセスのみを許可するという方針で作成したネットワーク制御を記します。
ただ、個人的に変更したい点もありますので、そちらも一緒に。。

前提

上記で記したように、ネットワーク周りは下記で基本は構成されています。
サブネット:ACL | インスタンス:SG

現状

  • ACL:適当に設定。
  • SG:※すべてがインバウンドのみ制御
    • Webサーバ(EC2・プライマリ/セカンダリ)用:社内IP(http,ssh)、SG(RDS用、ALB用)
    • RDS用:SG(Webサーバ(EC2・プライマリ/セカンダリ)用)
    • ALB用:社内IP(https)

こう変更したい

  • ACL:SGとうまく住み分けをしたい。。。
  • SG:
    • 開発者用:インバウンドに社内IP(http)のみ
    • Webサーバ(EC2・プライマリ/セカンダリ)用
      • インバウンド:SG(RDS用、ALB用、開発者用) ← ALBが障害出たときにユーザー(社員)にEIPで直アクセスで利用してもらえないのが怖い。ほかで担保すべきなのは明らかやけど。
      • アウトバウンド:SG(RDS用、ALB用)← ほかに影響が出そうで怖い。。
    • RDS用:SG(Webサーバ(EC2・プライマリ/セカンダリ)用)
    • ALB用:社内IP(https)

詰まった部分

前回の記事にてCICDを作成したお話をしましたが、CodeBuildにてテストを行う際に、プライベートサブネットに配置したRDSの参照がデフォルトではできませんでした。CodeBuildを同一VPC内のRDSと同じprivate subnetに置き、別のSGをアタッチ、WebサーバーにアタッチしてあるNatゲートウェイを上記private subnetのルートテーブルにアタッチすることで、テストができました。。。

参考資料:AWS公式CodeBuildのVPCサポートについてのドキュメント
https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/vpc-support.html

まとめ

・基盤を作成するにあたり、ドメイン取得やHTTP→HTTPS通信変更、Webサーバー負荷分散/冗長化、DBの冗長化など、
アプリのエンジニアとしてはあまり触れない部分を触れることができ、単純に楽しかったです。。。

・今後は、オンプレのアーキテクチャをそのままAWSにした感の強いこの構成を、よりクラウドチックでサーバレスな基盤、CI/CDに変更したいなと陰ながら思っております~

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
0