Okay. Hello, cloud gurus, how y'all doing? Scott Pletcher here with another slice of piping hot AWS news straight from the oven. Transit Gateway Network Manager goes multi account. AWS DataSync goes multi-cloud...sort of, and a timely reminder that hackers desperately want your AWS access keys. This is AWS this week.

Well, it is not often at all that AWS even acknowledges the likes of Azure or GCP, but that's just what happened this week. AWS DataSync can now count Google Cloud Storage and Azure Files Storage as potential endpoints, allowing you to use the managed service to shuffle data between even more locations. Now, before you get all excited that AWS has finally come around to the multi-cloud lifestyle, do know that this support isn't exactly native AWS DataSync is using GCPS S3-compatible API to access Google Cloud Storage and is using the existing SMB protocol to access Azure files. Now, as of press time, details on how this all might work aren't very clear. So I can't vouch for how well or how wonky it might be, but to paraphrase Lloyd Christmas, it does seem like AWS is telling us there's a chance.

Good news this week, for all those who manage large multi account networks on AWS, AWS Transit Gateway Network Manager now supports multiple accounts within organizations created using AWS Organizations. This now gives us the ability to have one consolidated network manager dashboard across all our accounts versus having to hop from account to account. This unification also includes CloudWatch metrics and events to watch over your global networking empire for any funny business. And yes, you can now see all your networks across all accounts on a single global geographic map, which no doubt will be projected onto a seven foot screen in your network operation center for no other practical reason than to impress people during data center tours. In the "don't we have enough to worry about" category this week, a popular Python package CTX and a PHP package called pH pass was hacked in an apparent effort to steal environment variables, including AWS keys, and exfiltrate them to a Heroku URL under the perpetrator's control.

The attacker used a method called repo jacking whereby somebody gains unauthorized access to a legitimate repo and can insert malicious code into a new version. It only took a few hours for security researchers to notice the anomaly, but an estimated 20,000 versions of the hacked code had already been downloaded. This attack vector is particularly sneaky in that many will blindly upgrade a new library or package whenever a new version gets released. How can we defend against something like this? Well, one measure is to lock your libraries into specific versions so you control when and how they update. Where possible use IAM rules instead of access keys and lock down outbound traffic to only trusted destinations, which probably would've mitigated this particular attack, but at a bare minimum, if you haven't yet enabled CloudTrail logging do it now.

No I'm serious. Pause this video and go enable it now, then come back, of course. And as we wrap up just a little tidbit for those riding the EC2 train, you can now add stop protection to your instances, to protect them from unintentional stop actions from the console CLI or API. It might be a handy little feature to keep an EC2 instance from being stopped or terminated out from underneath you, in the case of a CloudFormation delete or some automated cost control measures. That my friends is all the AWS news that's fit to print this week, stay safe, take care of one another and keep being awesome cloud gurus.