<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Aws on ashitaka blog</title>
    <link>https://8fd9c3c3.blog-1xe.pages.dev/tags/aws/</link>
    <description>Recent content in Aws on ashitaka blog</description>
    <generator>Hugo</generator>
    <language>ja-jp</language>
    <lastBuildDate>Sun, 31 Jul 2022 07:37:52 +0900</lastBuildDate>
    <atom:link href="https://8fd9c3c3.blog-1xe.pages.dev/tags/aws/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AWSのアカウントは分けると安心</title>
      <link>https://8fd9c3c3.blog-1xe.pages.dev/2022/07/31/aws-organizations/</link>
      <pubDate>Sun, 31 Jul 2022 07:37:52 +0900</pubDate>
      <guid>https://8fd9c3c3.blog-1xe.pages.dev/2022/07/31/aws-organizations/</guid>
      <description>&lt;p&gt;自分がAWSを触ったのは、大学院時代に友達と簡単なWebサービスをデプロイするときに使ったのが初めてでした。1通り基本的なことを学ぶために、udemyの教材を使って基本的なリソースをマネジメントコンソールから作って削除していました。&lt;/p&gt;
&lt;p&gt;そういった個人的な開発をする中ではなかなかAWSアカウントを複数作ることはなく、1つのAWSアカウントの中にサーバーやデータベースを作ることが多いです。&lt;/p&gt;
&lt;p&gt;しかし、現職に入社してIDaaS経由でAWSの権限をもらったときに大量のアカウントが表示されていてびっくりしました。今ではとても理に適った管理方法だなと思うので、その感想をつらつら書きます。&lt;/p&gt;
&lt;h2 id=&#34;参考&#34;&gt;参考&lt;/h2&gt;
&lt;p&gt;AWSのマルチアカウント戦略ってなに？なぜ必要？【社内勉強会スライド】&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://dev.classmethod.jp/articles/why-aws-multi-accounts/&#34;&gt;https://dev.classmethod.jp/articles/why-aws-multi-accounts/&lt;/a&gt;&lt;/p&gt;
&lt;h2 id=&#34;メリット&#34;&gt;メリット&lt;/h2&gt;
&lt;h3 id=&#34;権限が分離されている安心感がすごい&#34;&gt;権限が分離されている安心感がすごい&lt;/h3&gt;
&lt;p&gt;現職ではサービスの環境をDevelopment、Staging、Productionの3種類にわけていて、アプリケーションをEKSで動かしています。&lt;/p&gt;
&lt;p&gt;1つのAWSアカウント内でこれをやろうとすると、環境ごとのVPC、IAM Role、EKSクラスタを作ったりする必要があり、ちゃんと分離できているのかが不安になります。&lt;/p&gt;
&lt;p&gt;しかし、環境ごとにAWSアカウントを作成するとこんな感じになります。&lt;/p&gt;
&lt;p&gt;&lt;img loading=&#34;lazy&#34; src=&#34;../../wp-content/uploads/2022/07/aws-multi-accounts-separeted-by-environment.jpg&#34;&gt;&lt;/p&gt;
&lt;p&gt;お互いが絶対に干渉しないので、内部の設定ミスによる事故を防いだり、外部からの攻撃の影響範囲を制限することにつながります。&lt;/p&gt;
&lt;h2 id=&#34;工夫が必要な点&#34;&gt;工夫が必要な点&lt;/h2&gt;
&lt;h3 id=&#34;初期に必要なawsリソースをcloudformationで作成&#34;&gt;初期に必要なAWSリソースをCloudFormationで作成&lt;/h3&gt;
&lt;p&gt;Terraformを使って各AWSアカウントのリソースを管理したいところですが、初期の状態ではTerraformを実行するためのIAM Roleもないわけです。それをアカウントごとに作成するのは大変なので、CloudFormationを使って最低限必要なリソースを全てのアカウントに対して作成します。&lt;/p&gt;
&lt;p&gt;AWS Organizationを使ってAWSアカウントをOrganization Unit単位でグルーピングしておけば、より細かいリソース作成が可能になります。&lt;/p&gt;
&lt;p&gt;&lt;img loading=&#34;lazy&#34; src=&#34;../../wp-content/uploads/2022/07/aws-multi-accounts-separeted-by-environment-2.jpg&#34;&gt;&lt;/p&gt;
&lt;h3 id=&#34;transit-gatewayを使ってawsアカウントをまたがった通信を行う&#34;&gt;Transit Gatewayを使ってAWSアカウントをまたがった通信を行う&lt;/h3&gt;
&lt;p&gt;各サービスにおいてEKSクラスタを共有させたいが、DBやStorageは別アカウントで持たせたいということもあると思います。実現する方法の1つとして、Transit Gatewayを用いる方法が挙げられます。&lt;/p&gt;
&lt;p&gt;&lt;img loading=&#34;lazy&#34; src=&#34;../../wp-content/uploads/2022/07/aws-multi-accounts-separeted-by-environment-1.jpg&#34;&gt;&lt;/p&gt;
&lt;p&gt;この記事をとても参考にさせてもらいました🙏&lt;/p&gt;
&lt;p&gt;Transit Gatewayを利用してVPC間で通信してみた&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://dev.classmethod.jp/articles/transit-gateway-vpc/&#34;&gt;https://dev.classmethod.jp/articles/transit-gateway-vpc/&lt;/a&gt;&lt;/p&gt;
&lt;h2 id=&#34;まとめ&#34;&gt;まとめ&lt;/h2&gt;
&lt;p&gt;現職でプロダクトの開発に携わりながら、こういったインフラを扱うSREのタスクもやらせてもらっていて、学んだことを残していこうと思います💪&lt;/p&gt;</description>
    </item>
    <item>
      <title>AWS認定 ソリューションアーキテクト[アソシエイト]</title>
      <link>https://8fd9c3c3.blog-1xe.pages.dev/2020/11/15/aws/</link>
      <pubDate>Sun, 15 Nov 2020 09:06:25 +0900</pubDate>
      <guid>https://8fd9c3c3.blog-1xe.pages.dev/2020/11/15/aws/</guid>
      <description>&lt;p&gt;会社での社内ツールを開発する際にAWSを参考にすることが多いので, &lt;a href=&#34;https://www.amazon.co.jp/AWS%E8%AA%8D%E5%AE%9A%E8%B3%87%E6%A0%BC%E8%A9%A6%E9%A8%93%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-AWS%E8%AA%8D%E5%AE%9A-%E3%82%BD%E3%83%AA%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%88-%E3%82%A2%E3%82%BD%E3%82%B7%E3%82%A8%E3%82%A4%E3%83%88-%E4%BD%90%E3%80%85%E6%9C%A8-%E6%8B%93%E9%83%8E-ebook/dp/B07R1H87Y1&#34;&gt;AWS認定 ソリューションアーキテクト[アソシエイト]&lt;/a&gt; という本を使って一通り勉強してみた。&lt;/p&gt;
&lt;h2 id=&#34;内容&#34;&gt;内容&lt;/h2&gt;
&lt;h4 id=&#34;vpc-virtual-private-cloud&#34;&gt;VPC (Virtual Private Cloud)&lt;/h4&gt;
&lt;p&gt;利用者ごとのプライベートなネットワークを作成できる。セキュリティグループやネットワークACL(Access Control List)を使って通信制御を行う。&lt;/p&gt;
&lt;h4 id=&#34;cloundfront&#34;&gt;CloundFront&lt;/h4&gt;
&lt;p&gt;HTMLファイルやCSS, 画像, 動画といった静的コンテンツをキャッシュし, オリジンサーバーの代わりに配信するCDN(Contents Delivery Network)サービス。ELBやEC2だけでなくS3をオリジンサーバにすることもできる。&lt;/p&gt;
&lt;h4 id=&#34;route53&#34;&gt;Route53&lt;/h4&gt;
&lt;p&gt;ドメイン管理機能と権威DNS機能を持つサービス。以下のような自由なトラフィックルーティングが可能&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;シンプルルーティング&lt;/li&gt;
&lt;li&gt;フェイルオーバールーティング&lt;/li&gt;
&lt;li&gt;位置情報ルーティング&lt;/li&gt;
&lt;li&gt;地理的近接性ルーティング&lt;/li&gt;
&lt;li&gt;レイテンシールーティング&lt;/li&gt;
&lt;li&gt;複数値回答ルーティング&lt;/li&gt;
&lt;li&gt;加重ルーティング&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;ec2-elastic-compute-cloud&#34;&gt;EC2 (Elastic Compute Cloud)&lt;/h4&gt;
&lt;p&gt;仮想サーバーを必要な数だけすぐに立てることができるIaaS型サービス。AMI(Amazon Machine Image)を選んでインスタンスを生成する。スポットインスタンスというAWSが余らせているEC2リソースを入札形式で安く利用する方式なんかもある。&lt;/p&gt;
&lt;h4 id=&#34;elb-elastic-load-balancing&#34;&gt;ELB (Elastic Load Balancing)&lt;/h4&gt;
&lt;p&gt;ロードバランサーを提供するサービス。Auto Scalingという, システムの利用状況に応じて自動的にELBに紐づくインスタンスの台数を増減させる機能がある。&lt;/p&gt;
&lt;h4 id=&#34;ecs-elastic-container-service&#34;&gt;ECS (Elastic Container Service)&lt;/h4&gt;
&lt;p&gt;Dockerコンテナの実行環境を提供するサービス。&lt;/p&gt;
&lt;h4 id=&#34;aws-fargate&#34;&gt;AWS Fargate&lt;/h4&gt;
&lt;p&gt;ECSのCluster用のEC2インスタンスを使わずにコンテナを動かすことのできるサービス。&lt;/p&gt;
&lt;h4 id=&#34;eks-elastic-container-service-for-kubernetes&#34;&gt;EKS (Elastic Container Service for Kubernetes)&lt;/h4&gt;
&lt;p&gt;Kubernetesを利用する際のmasterを提供するサービス。&lt;/p&gt;
&lt;h4 id=&#34;ecr-elastic-container-registry&#34;&gt;ECR (Elastic Container Registry)&lt;/h4&gt;
&lt;p&gt;コンテナイメージを管理するレジストリを提供するサービス。&lt;/p&gt;
&lt;h4 id=&#34;lambda&#34;&gt;Lambda&lt;/h4&gt;
&lt;p&gt;サーバーを用意しなくてもプログラムを実行できる環境を提供するサービス。&lt;/p&gt;
&lt;h4 id=&#34;cloudwatch&#34;&gt;CloudWatch&lt;/h4&gt;
&lt;p&gt;定期的にAWSリソースの状態を取得し, 問題がある場合はそれを運用者に通知するサービス。CPU使用率などの基本的なログをモニタリングするだけでなく, CloudWatch Logsを使ってアプリケーションログをモニタリングしたり, CloudWatch Eventsを使って独自のトリガーと何かしらの後続のアクションとの組み合わせを定義したりできる。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
