[freshports-coders] FreshPorts & AWS - trimming excess services

[Alex Samorukov]

Hi Dan,

I am agree with what Ihor told but also would highly recommend to use
infrastructure as a code approach.

I am personally preferring Terraform, but there are other options (CF,
CDK) too.

Some of the benefits its giving to you:

1. Ability to get infra in repeatable manner and audit it before pushing
anything to prod.

2. Ability to re-create infra anytime within just a seconds

3. Auditing of changes using git

4. Ability to create and destroy staging anytime.

I am happy to help to re-create everything you have in a code way,but as
Ihor told, we will need either r/o access or at least set of requirments
to the infra you want to build. In this case it will look like a set of
objects (modules) for VPC, EC2, RDS and everything else needed. We can
have an IRC chat or call to discuss requirements, build diagram and
codify it.

Some references:

[1] https://www.terraform.io/ - Terraform website

[2] https://en.wikipedia.org/wiki/Infrastructure_as_code


On 22.01.2021 1:15, Ihor Antonov wrote:
> On 1/21/21 3:16 PM, Dan Langille wrote:
> 
> 
> Hey Dan
> 
> It is hard to give you concrete recommendations without at least
> read-only access to AWS account. It is totally possible to create IAM
> users with read-only access. Is this something you might consider 
> doing?
> 
> Meanwhile, some some general recommendations:
> 
> 1. All these resources
> 
> > * subnets
> 
> > * VPC
> 
> > * Internet Gateways
> 
> > * Egress Internet Gateways
> 
> > * Network ACLS
> 
> are free. They do not consume money, they won't show up in your bill.
> Although I understand that removing them might be just a matter of
> housekeeping. if you have an unused VPC - make sure there are no EC2
> instances running, and then simply delete. If you are using AWS
> console - it will delete all child resources of that VPC automatically
> (routes, subnets, internet gateways). Delete operation will fail if
> there are instances running in that VPC.
> 
> 2. If you have a VPC that you use there is no need to worry about
> extra subnets that are not currently in use. By default AWS creates 1
> subnet per AZ (AZ == a physically independent data center within that
> region)
> multiplied by subnet type (private/public/nat).
> 
> Example: us-east-1 has 6 AZs. Depending on you VPC setup you might
> have 6*3 subnets.
> 
> Having those subnets around has a benefit too. Sometimes AWS has
> outages or degradation of service quality in different AZs (e.g.
> instance type shortages, networking issues, EBS volume shortages,
> etc.) These are rare situations, but they do happen once in a blue
> moon. Being able to quickly move your workload to another AZ is a good
> thing.
> 
> 3. Please clarify about "my RDS instance has 6 subnets". RDS can't
> "have" subnets. Only VPC can have subnets. Do you mean it is a
> mutli-AZ RDS deployment? or is it deployed in a VPC that has 6 subnets?
> 
> 3. "I also need to change the RDS subnet to a non-routable subnet" -
> there are couple of ways you can go about this - redeploy your RDS to
> a different set of subnets. It requires some RDS downtime. Or you can
> edit the subnet by removing 0.0.0.0/0 route from it. This has a
> downside that this subnet might be also used by something else, and
> generally this is not a preferred way. I'd redeploy RDS to a different
> set of subnets.
> 
> 4. "Right now, it's on 54.242.45.0/24" - can you clarify? AWS VPC
> allows only non-routable address ranges [1]. I think there is some
> mistake here. Having read access to AWS account would be great in
> cases like this.
> 
>