Tyler, when you perform this on an environment where does the granularity for the the traffic identification come from? Is it the account it's coming from and hitting the TGW? Alternatively, are we able to do tagging on the traffic(or other option) if it is based on that account source to help split within one account with multiple showback accounts?
Yes, from the originating account id. You are able to grab the account id contained in metadata in the transit gateway flow logs, or you can go off the CUR data for the central vpc account id and spoke ids. Like they show in the 1st article, you don't even need the TGW flow logs for this but it helps you break it down further if you want to go by byte allocation. The bill for TGW populates in the owner's account so you can use that centralized vpc account id, identify which spoke accounts sent and received traffic through the TGW, and then determine the total % of traffic coming across it and distribute by src. The TGW acts like a filter mechanism and a point-of-query. You can query beyond that for shared services as well. As for tagging, you can apply tags to TGW flow logs by purpose or owner or whatever other convention works.
Do you see then that account structure becoming even more important for this and ability to break things out further or do you feel the two use cases in your article can cover 80% of the scenarios you've seen out in production?
Yes. On top of this, better fit account structure creates a more effective perimeter. Treating the TGW like a checkpoint in this is smart for the combined effect it has on workload traffic management/routing and as something which can be monitored for both security + chargeback requirements. Anyone using a TGW could benefit from viewing it this way, so I'd say 80% is being conservative even!
Tyler, when you perform this on an environment where does the granularity for the the traffic identification come from? Is it the account it's coming from and hitting the TGW? Alternatively, are we able to do tagging on the traffic(or other option) if it is based on that account source to help split within one account with multiple showback accounts?
Yes, from the originating account id. You are able to grab the account id contained in metadata in the transit gateway flow logs, or you can go off the CUR data for the central vpc account id and spoke ids. Like they show in the 1st article, you don't even need the TGW flow logs for this but it helps you break it down further if you want to go by byte allocation. The bill for TGW populates in the owner's account so you can use that centralized vpc account id, identify which spoke accounts sent and received traffic through the TGW, and then determine the total % of traffic coming across it and distribute by src. The TGW acts like a filter mechanism and a point-of-query. You can query beyond that for shared services as well. As for tagging, you can apply tags to TGW flow logs by purpose or owner or whatever other convention works.
Do you see then that account structure becoming even more important for this and ability to break things out further or do you feel the two use cases in your article can cover 80% of the scenarios you've seen out in production?
Yes. On top of this, better fit account structure creates a more effective perimeter. Treating the TGW like a checkpoint in this is smart for the combined effect it has on workload traffic management/routing and as something which can be monitored for both security + chargeback requirements. Anyone using a TGW could benefit from viewing it this way, so I'd say 80% is being conservative even!
Also for anyone trying to do CUR queries...here's the library link: https://catalog.workshops.aws/cur-query-library/en-US/1-cur-library/queries