Jacob Marks

Note: I originally sketched this post years ago and never finished it. I’m publishing it now as a retrospective on how I think about VPC Flow Logs at scale. VPC Flow Logs: Use Them Intentionally For a long time, the default guidance in AWS environments was simple: enable VPC Flow Logs everywhere. At small to moderate scale, that advice is usually fine. At large scale, it becomes expensive, noisy, and often redundant. There’s an inherent catch-22 with Flow Logs. If you don’t have them enabled, you miss historical data when you need it. If you enable them universally, you can generate massive volumes of duplicated traffic data that few teams ever analyze in a meaningful way. At sufficient scale, AWS can perform network-level analysis across its infrastructure independent of whether an individual account is exporting Flow Logs. Because of that, Flow Logs are not always treated internally as a hard security requirement for every workload. I argued for that shift myself, main...

AWS announced Multi-Region Keys in AWS Payment Cryptography. You can read the official post here: https://aws.amazon.com/blogs/security/multi-region-keys-a-new-approach-to-key-replication-in-aws-payment-cryptography/ This was a meaningful launch because it crossed one of the boundaries AWS takes very seriously: Region isolation. Replicating payment cryptographic keys across Regions meant moving highly sensitive customer material across a boundary that is normally treated as a hard line. That required a lot of design review, security scrutiny, and approvals. Moving critical customer data across Regions is not something anyone treats casually. One of my engineers handled much of the implementation while I drove execution, launch readiness, and stakeholder alignment. Because the launch was time-sensitive, I had to stay deeply involved in approvals, resolving concerns, and making sure decisions were happening fast enough to keep the work moving. A lot of the real work was not writing c...

AWS announced the launch of AWS Payment Cryptography this week, and I’ve had the opportunity to lead the service from its earliest definition through production launch. The official AWS announcement is here: https://aws.amazon.com/about-aws/whats-new/2023/06/aws-payment-cryptography/ . This was one of those projects where the hard part was never just building software. The challenge was defining a service that could meet the expectations of payment processors, issuers, and financial institutions who were used to a vastly different interaction model while operating inside the security, compliance, and operational standards required for payment cryptography. My role started at the beginning: taking early customer input, writing the initial business requirements, and helping shape the architecture that would eventually become the service. That meant defining the threat model, establishing the security posture, and making early decisions around control-plane boundaries, data-plane design, ...

*** NOTE: AWS has pulled this specific certification version, refunding those who took the original beta exam. *** 2026 Status Update: The AWS Certified Security - Specialty is now a mature, standard certification. While the beta period mentioned below ended years ago, the core focus on deep-dive security across IAM, Encryption, and Incident Response remains the primary objective of the current exam version. I had the opportunity to take the AWS Certified Security Specialty Exam at re:Invent 2016. The exam was in a beta phase where questions were being tested, refined, and the exam pass line was being set. While I can't share actual exam questions, I can share advice for others interested in the certification path. Preparation I entered the exam cold, drawing only on my working knowledge of AWS and its services, so my perspective is an unbiased view of the exam's difficulty. While blueprints change, the foundational security pillars remain consistent. Format ...

Note: The US Government cloud security policy landscape has changed significantly since this was originally written. I no longer have the first-hand, current context required to provide a meaningful update to this information, so please treat the following as a historical reference. The Federal Information System Management Act (FISMA), a US Law signed in 2002, defines the information protection requirements for US Government, "government", data and is applicable to all information systems that process any government data regardless of ownership or control of such systems. Systems Integrators (SI) under contract to perform work for the government are almost always provided some government furnished information (GFI) or government furnished equipment(GFE) and FISMA requirements extend to the systems owned and/or operated by these SIs if they store or process government data. Government data always remains under the ownership of the source agency with that agency holding sol...