<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Aws on Brave New Geek</title><link>https://bravenewgeek.com/tag/aws/</link><description>Recent content in Aws on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 15 Oct 2020 10:51:25 -0500</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/aws/index.xml" rel="self" type="application/rss+xml"/><item><title>Continuous Deployment for AWS Glue</title><link>https://bravenewgeek.com/continuous-deployment-for-aws-glue/</link><pubDate>Thu, 15 Oct 2020 10:51:25 -0500</pubDate><guid>https://bravenewgeek.com/continuous-deployment-for-aws-glue/</guid><description>&lt;p&gt;&lt;a href="https://aws.amazon.com/glue"&gt;AWS Glue&lt;/a&gt; is a managed service for building ETL (Extract-Transform-Load) jobs. It’s a useful tool for implementing analytics pipelines in AWS without having to manage server infrastructure. Jobs are implemented using Apache Spark and, with the help of &lt;a href="https://docs.aws.amazon.com/glue/latest/dg/dev-endpoints.html"&gt;Development Endpoints&lt;/a&gt;, can be built using Jupyter notebooks. This makes it reasonably easy to write ETL processes in an interactive, iterative fashion. Once finished, the Jupyter notebook is converted into a Python script, uploaded to S3, and then run as a Glue job.&lt;/p&gt;</description></item><item><title>Security by Happenstance</title><link>https://bravenewgeek.com/security-by-happenstance/</link><pubDate>Tue, 26 Mar 2019 11:25:14 -0500</pubDate><guid>https://bravenewgeek.com/security-by-happenstance/</guid><description>&lt;h4 id="key-rotation-auditing-and-securecicd"&gt;Key rotation, auditing, and secure CI/CD&lt;/h4&gt;
&lt;p&gt;Companies often require employees to regularly change their passwords for security purposes. &lt;a href="https://www.pcisecuritystandards.org/document_library?category=pcidss&amp;amp;document=pci_dss"&gt;PCI compliance&lt;/a&gt;, for example, requires that passwords be changed every 90 days. However, NIST, whose guidelines commonly become the foundation for security best practices across countless organizations, &lt;a href="https://www.passwordping.com/surprising-new-password-guidelines-nist/"&gt;recently revised&lt;/a&gt; its recommendations around password security. Its Digital Identity Guidelines (&lt;a href="https://pages.nist.gov/800-63-3/sp800-63b.html"&gt;NIST 800-63-3&lt;/a&gt;) now recommends &lt;em&gt;removing&lt;/em&gt; periodic password-change requirements due to a growing body of research suggesting that frequent password changes actually &lt;a href="https://arstechnica.com/information-technology/2016/08/frequent-password-changes-are-the-enemy-of-security-ftc-technologist-says/"&gt;makes security &lt;em&gt;worse&lt;/em&gt;&lt;/a&gt;. This is because these requirements encourage the use of passwords which are more susceptible to cracking (e.g. incrementing a number or altering a single character) or result in people writing their passwords down.&lt;/p&gt;</description></item><item><title>Multi-Cloud Is a Trap</title><link>https://bravenewgeek.com/multi-cloud-is-a-trap/</link><pubDate>Fri, 14 Sep 2018 11:16:09 -0500</pubDate><guid>https://bravenewgeek.com/multi-cloud-is-a-trap/</guid><description>&lt;p&gt;It comes up in &lt;em&gt;a lot&lt;/em&gt; of conversations with clients. We want to be cloud-agnostic. We need to avoid vendor lock-in. We want to be able to shift workloads seamlessly between cloud providers. Let me say it again: &lt;em&gt;multi-cloud is a trap&lt;/em&gt;. Outside of appeasing a few major retailers who might not be too keen on stuff running in Amazon data centers, I can think of few reasons why multi-cloud should be a priority for organizations of &lt;em&gt;any&lt;/em&gt; scale.&lt;/p&gt;</description></item><item><title>GCP and AWS: What’s the Difference?</title><link>https://bravenewgeek.com/gcp-and-aws-whats-the-difference/</link><pubDate>Tue, 17 Jul 2018 11:58:21 -0500</pubDate><guid>https://bravenewgeek.com/gcp-and-aws-whats-the-difference/</guid><description>&lt;p&gt;AWS has long been leading the charge when it comes to public cloud providers. I believe this is largely attributed to &lt;a href="https://gist.github.com/chitchcock/1281611"&gt;Bezos’ mandate of “APIs everywhere”&lt;/a&gt; in the early days of Amazon, which in turn allowed them to be one of the first major players in the space. Google, on the other hand, has a very different DNA. In contrast to Amazon’s laser-focused product mindset, their approach to cloud has broadly been to spin out services based on internal systems backing Google’s core business. When put in the context of the very different leadership styles and cultures of the two companies, this actually starts to make a lot of sense. But which approach is better, and what does this mean for those trying to settle on a cloud provider?&lt;/p&gt;</description></item></channel></rss>