terraform-aws-control_tower_account_factory
terraform-aws-control_tower_account_factory copied to clipboard
aws-ia
Minimising VPC costs
That the VPC used for build steps can be configured to be created on-demand by the pipelines, then removed again after a suitable default period, say an hour.
There is no direct problem with the present situation, but the cost of the VPC far exceeds all other costs for AFT. In enterprise-size installations, this is not a concern even though even there, AFT would hardly be run constantly. In a minimal situation, however, such as for a PoC, minimising costs is useful. If this would be made configurable, with a default behaviour as the present, the feature would be opt-in and wouldn't change the behaviour of existing deployments.
Implementation is in all likelihood straightforward: just a timer that can be set, checked and cleared.
@PeterBengtson thank you for the feature request. I have created a backlog to look into ways to reduce the overall network setup cost for AFT.
Hi @PeterBengtson, we've also had some bill shock by AFT costing over $300 for the first month. We noticed the solution has VPC Endpoints for the AWS services the lambas use, and the VPC endpoints were created by having a variable set to true in one of the tf files. The VPC endpoints cost about $20 per month each and there are 14 endpoints and 2 endpoint gateways.
As you've said above this might make sense for high change enterprise environments, but for PoC's you can set variable aft_vpc_endpoints to false and apply, this will remove the VPC endpoints and the service calls from the lambdas will go over the NAT gateways and the internet gateway and the costs should be reduced by a significant amount without any change to functionality.
Yes, of course @terencewhitenz! I'd completely forgot about aft_vpc_endpoints – that will certainly bring the AFT costs for a PoC down very significantly. Thanks! :)
Hi @snebhu3 I agree with the title of this issue. AFT is powerful solution but a experimental choice as well. So low cost PoC environment to try is needed for most costomers.
As a first step to reduce vpc costs, It would be nice to be able to choose wheter if single AZ or multi AZ for NAT gateway.
For example this popular VPC module allows us to choose that in module's input. https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/latest#nat-gateway-scenarios
Thank you :)
Hi @snebhu3 I agree with the title of this issue. AFT is powerful solution but a experimental choice as well. So low cost PoC environment to try is needed for most costomers.
As a first step to reduce vpc costs, It would be nice to be able to choose wheter if single AZ or multi AZ for NAT gateway.
For example this popular VPC module allows us to choose that in module's input. https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/latest#nat-gateway-scenarios
Thank you :)
Couldn't echo this request enough. Thanks for consideration.
Hi, these costs are exorbitant for what the tool is doing. 2 NATGWs is $70 a month for a process moving close to zero traffic per month.
Please can we get this prioritized to at least allow some control over how the VPC infra is being deployed, either allowing conditional creation of the NATGW so that we can configure it ourselves, or by allowing full control of the networking using TF inputs.
Spent 30mins fiddling with internals of this module and came up with something that works for us. Will try put this up on the TF registry at some point.
Here's a fork with additional feature flag to move all infra to public facing subnets, reducing NATGW costs and EIP allocation. https://github.com/morganrowse/terraform-aws-control_tower_account_factory
Here's a PR to this repo with the change (Please note the AWS-IA team don't welcome contributions at this point) https://github.com/aws-ia/terraform-aws-control_tower_account_factory/pull/267
Adding the below to the forked module seems to do the trick.
aft_feature_disable_private_networking = true
I hope one day your team considers fixing this Ta
👍🏼 for cost optimisation. There could be adoption friction due to costs, while a drop in the ocean for a large org, a start-up/scale-up does not want to be worrying about AFT costs -- especially given how minimal the traffic is vs infra costs.
Without spending a considerable time within the TF AFT code, feature flags for sandbox/PoC, dev and production comes to mind.
@snebhu3 it would be great to know where that backlog item is at vis-a-vis reducing the overall network setup cost for AFT.
@snebhu3 , could you please add the option to deploy AFT into a public VPC without the NAT Gateways
I'm glad to have found: aft_vpc_endpoints in this topic thanks @terencewhitenz this will reduce the overhead by 75% already.
But I would like to second the official adoption of a feature like: aft_feature_disable_private_networking. For those of us not yet adventurous enough to adapt the official module yet. Since everything is security grouped and using TLS, the added benefits for smaller companies are just not there.
Thank you for the great work on AFT, it beats CT click ops by a mile!
Have to agree here. The majority of the use cases are not creating tons of accounts. We are currently paying over $100/month for a NAT. And I've created 11 accounts since May 2022. Must be a way to opt out of this. Thanks.
I agree with all of the previous comments. I have an instance of AFT running on a personal control tower to demo LZ changes, updates to the module, etc. Here is the cost breakdown for anyone else curious (NOTE: This is with private VPC endpoints disabled):
AFT-Management Account:
I should also mention that I had ~$20 of USE1-SC-API-Calls on the management account. I spun up and tore down the entire control tower several times and created 5 accounts, so this is probably a higher than normal value. In addition, there is a configuration item charge in each child account created. The fees are $2-3, but if you plan on creating 100 accounts it's important to know this, as it could be an extra $200 or more you're not anticipating. From what I can tell, this is a one-time cost dependent upon the number of regions you have enabled:
@robbycuenot do you have a link on how to tear down while not in use? Thanks.
@robbycuenot do you have a link on how to tear down while not in use? Thanks.
Tearing the whole thing down once you've started using it to create accounts is definitely not advisable-- I tore it down prior to doing so to document the setup process and add some additional automation (https://github.com/robbycuenot/template-aft-bootstrap). I wrote this very opinionated bootstrap code to create all of the necessary TFC workspaces, tokens, teams, and GitHub repos for setting up AFT. To tear it down, I basically ran "destroy" plans on aft-framework and my bootstrap workspace.
Short of commenting out the NAT code from the module, or switching to @morganrowse fork, there isn't a practical way to save costs on this one. Hopefully the project will be updated to remove the NAT requirement soon.
In the meantime, I would apply for the AWS "Activate Founders" credit to help cover it
@juvi87 I am wondering this too. My bill has been around $130/month. Once the AWS credits I have expire, it'll be harder to justify AFT for personal usage and testing. I'd like to prevent forking the project unless absolutely necessary
