932 karma · joined February 19, 2014
Not that this disproves the data, or global warming, but climate isn't the only thing changing.
What I saw is that the more you co-locate in an AWS account or Azure subscription, the higher the bar goes on ensuring your cost reporting and access control are also completely aware of resource group boundaries.
You really want to know is that $ for project A or B? You really want to ensure folks on project A have access to their cloud resources, but not project B. You can do that even in AWS, combine them and use IAM to segment things. I think there is just more room for error if you combine.
Also I think Azure has some per subscription quota limits and you may not want team A and B competing for them.
Again, no right answer, but I know we've done projects to split accounts and have never done one to combine them..
As an amateur wine maker, this would be magic, it's very difficult to measure alcohol concentration, ratios of acids etc.
Edit: https://aws.amazon.com/blogs/security/using-aws-security-ser...
GuardDuty In addition to finding the presence of this vulnerability through Inspector, the Amazon GuardDuty team has also begun adding indicators of compromise associated with exploiting the Log4j vulnerability, and will continue to do so. GuardDuty will monitor for attempts to reach known-bad IP addresses or DNS entries, and can also find post-exploit activity through anomaly-based behavioral findings. For example, if an Amazon EC2 instance starts communicating on unusual ports, GuardDuty would detect this activity and create the finding Behavior:EC2/NetworkPortUnusual. This activity is not limited to the NetworkPortUnusual finding, though. GuardDuty has a number of different findings associated with post exploit activity that might be seen in response to a compromised AWS resource. For a list of GuardDuty findings, please refer to this GuardDuty documentation.
Telecom's big fall: https://www.baltimoresun.com/news/bs-xpm-2002-04-07-02040600...