Amazon Web Services (AWS) Solutions Architect Professional Exam (SAP-C00)

Note: I originally wrote this post in 2017 but never published it at the time. Please note that the AWS certification landscape has changed significantly since then; this is provided strictly as a historical reference.

Another year another re:Invent. This year at re:Invent 2017, because my associate was up for renewal again, I decided to sit for the AWS Solutions Architect Professional Exam. The exam is in beta phase where questions are being tested, refined and the exam pass line is being set. I won't find out if I passed until March 2017 and I can't share actual exam questions but I can share advice for others that are interested in the exam in the future. Note that as of Jan 2017 the beta is currently closed as it's proved to be very popular.

Preparation:

I entered the exam cold, drawing only on my working knowledge of AWS and its services so my perspective should be an unbiased view of the exam. There is an exam blueprint but it's been pulled from the AWS website. 

Format:

• ~3hr Exam Time
• > 100 Questions
• Reading Comprehension Questions
• Question Nuances Where Important
• Heavy Focus on Services and Service Components with Security Relationship:
  • IAM
  • WAF
  • CloudFront
  • ACM
  • Security Groups
  • NACLs
  • VPC
  • etc.

My Exam Perspective:

I found the questions to be very long, requiring significant reading and reading comprehension in order to answer questions. I also found the possible answers to be long and requiring reading comprehension. I had to read a number of questions at least twice to pickup on all of their nuances and be able to differentiate answer validity. The questions for the exam had some substantial parallels to security related questions on other exams.

AWS Payment Cryptography in Sydney and AS2805 Support

AWS announced AWS Payment Cryptography is now available in the Asia Pacific (Sydney) Region. You can read the official announcement here: https://aws.amazon.com/about-aws/whats-new/2025/12/aws-payment-cryptography-in-sydney/

This was a particularly difficult launch.

Not because of one major issue, but because there were a lot of moving pieces all happening at once. Hardware deployment issues, firmware rollout problems, feature dependencies colliding near the finish line, compliance requirements, launch timing, and the normal reality that things rarely line up as cleanly in practice as they do on a plan.

A lot of the work near launch was simply making sure everything that needed to happen actually happened, in the right order, without creating new problems somewhere else.

Regional expansion for a service like this is never just turning something on in another place. Every assumption around hardware, operations, and readiness gets tested again.

Those are usually the hardest launches. Not one big failure, just constant pressure across a dozen important things at once.

Multi-Region Keys in AWS Payment Cryptography

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 code. It was proving the design, defending the security model, and making sure the operational path was something we were actually willing to own long term.

Those are often the hardest launches.

Launching AWS Payment Cryptography

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, hardware integration, and how HSM-backed infrastructure would operate inside AWS.

I also led the evaluation and selection of the HSM platform itself. That work involved deep vendor evaluation of the big three payment HSM vendors, prototype testing, operational modeling, and understanding what would actually work for a managed cloud service rather than simply replicating traditional on-premises approaches. 

As the service moved toward launch, a major focus became operational discipline. Observability, operational reviews, and HSM fleet health management were critical to making sure the system would hold up under real customer use, not just pass a design review. Several of the hardware-backed design patterns established during this work are already proving useful beyond this single service.

Launching AWS Payment Cryptography has been one of the most meaningful things I’ve worked on. It was a rare opportunity to help build something from ambiguity to durable production, where architecture, security, and execution all had to hold together at the same time.

EBS Key Rotation Strategies for KMS Master Keys

The AWS Key Management Service (KMS) provides a capability to manage encryption keys with transparent integration to many other AWS services. Of particular significance is transparent data at rest encryption for the AWS Elastic Block Store (EBS) service. When using KMS encryption, the data stream from the underlying storage medium is encrypted/decrypted at the hypervisor level. KMS is a regional AWS account bound service leveraging software key generation and underlying Hardware Security Module (HSM) appliances for encrypted storage of key material. Keys are decrypted as needed, stored in memory for the duration of the operation and then immediately erased from memory. The end user has the ability to effect controls over access to keys used for customer data encryption. As part of a security management plan, the customer may desire or have the requirement to effect a key rotation strategy. Keys may require rotation by policy with a defined validity period or could require rotation due to compromise. AWS encourages customers to encrypt all data both in motion and at rest. This ensures customer privacy while providing an ability to crypto erase data by deleting its encryption key as a mitigation to data spill or need to enforce deleted data protection.

Envelope Encryption

KMS uses an envelope encryption scheme providing two layers of protection for customer data and enabling access controls for the encrypted customer data itself. A data key is stored alongside the customer data that it encrypts in an envelope; containing key and cypher text. The data key is encrypted with a Customer Master Key (CMK) that has management facilities provided via the AWS Console, CLI and SDKs. In order to decrypt a dataset, an end user must have access to the CMK used to encrypt the data key with a forensic audit trail. Without the CMK, a data key cannot be decrypted and hence the underlying customer data cannot be decrypted. The CMK is itself encrypted by an AWS master key stored with physical security controls audited by third party for recovery of CMKs from the underlying HSM if a full region outage were ever to occur and the in-memory copy were lost. There are two different types of CMKs supported by KMS with the difference being ley material origin, these are an AWS generated CMK, “AWS managed CMK”, and a customer imported external CMK “customer managed CMK”.

EBS Service, Snapshots and AMIs

The EBS service provides block storage in the form of mountable volumes for Elastic Compute Cloud (EC2) instances. These volumes are similar to logical volumes presented to a virtual machine with underlying SAN storage. An EBS volume backup can be taken using a Snapshot feature that copies backups of blocks that have changed since the prior snapshot point offering an ability to capture the point in time contents of a volume. Snapshots are taken from an EBS volume and can be used to create new copies of that volume with identical data as of a given point in time. As such, they serve as the primary backup mechanism for EC2 instances as part of a disaster recoverability plan. Snapshots however are without instance configuration as they represent only a single volume and not the machine to which the source volume was attached. For this purpose , AWS offers an instance imaging feature which captures that instance’s current configuration and creates snapshots of all volumes attached to that instance producing what’s called an Amazon Machine Image (AMI). AMIs and Snapshots are store for you in an AWS managed S3 construct making both a regional service component. A copy feature is provided for both an AMI, really just an abstraction of the snapshots tied to the AMI, and an individual snapshot that allows the enablement of encryption and selection of a master key. This selection causes KMS to generate a data key for each of the specific snapshots in question, which is used to encrypt the customer data.

KMS AWS Managed CMK Behaviors

An AWS managed CMK is generated by and populated with key material through the software constructs of the KMS service. A default AWS managed key is automatically generated at the point of AWS account creation for each service that offers native KMS integration across each AWS region. AWS managed CMKs offer an automated rotation feature, when enabled, with a 1-year life cycle. That rotation process would cause the generation of new key material and the archival of old key material within that CMK. This old, deprecated key material is maintained to facilitate decryption of data keys previously encrypted with that key material. The new key material is then used for all encryption operations on customer data for new data sets going forward. In this process, the data keys for customer data are not rotated and existing data keys are not decrypted and re-encrypted with the new key material.

KMS Customer Managed CMK Behaviors

A customer managed CMK is generated as an empty container to which a customer can import a 256-bit symmetric encryption key. The advantage here being that the customer can generate a key either in software or thru their own hardware key management tools. The customer must maintain a copy of that key within their own IT infrastructure and is solely responsible for recovery of that key in the event of a full AWS region outage by re-importing the key material to the CMK. A customer managed CMK can only contain a single set of key material and does not have the capability to manage a history of key material as the AWS managed CMKs do. The ability to re-import key material to such a CMK is provided purely for recovery purposes and if different key material were ever uploaded, all customer data with the CMK in its envelope chain previously encrypted by that CMK would not be decryptable.

Key Rotation Strategies

When using AWS managed CMKs, the customer has minimal control over the deprecation of legacy key material. Though automated rotation does phase out the future use of legacy key material, it does not cause a re-encryption of data keys and customer data remains encrypted with the same data key. Use of customer managed CMKs enables a greater degree of control over key material source but places a responsibility on the customer to implement a key rotation strategy. In each scenario, there are strategies, leveraging behaviors of the KMS service to force certain desired rotation outcomes.

Rotating Only A CMK

For either an AWS managed or customer managed CMK, a customer can effect complete master key rotation. In the case of AWS managed CMKs, this includes phasing out use of legacy key material. A strategy to achieve this outcome would be to initiate a copy of source customer data within the same region and account. This does not cause a change to data keys or cause customer data re-encryption however; it does cause data keys to be re-encrypted with the new CMK.

Rotating Both A CMK and Data Key

For either an AWS managed or customer managed CMK, a customer can effect complete master and data key rotation. In the case of AWS managed CMKs, this would completely phase out use of legacy key material. A strategy to achieve this outcome would be to initiate a copy of source customer data that crosses an AWS Account and/or AWS Region boundary and then additional copy back to the source. This will cause a new data key to be generated at the destination and enable the selection of an arbitrary CMK at the destination. Note that this will require configuration of KMS CMK access permissions, see https://aws.amazon.com/blogs/aws/new-cross-account-copying-of-encrypted-ebs-snapshots/. Following the reverse process to copy data back to the source will cause a new data key to be generated in the source AWS Account/AWS Region for the customer data and enable the selection of a new CMK in the source AWS Account/AWS Region. Cross region copies would result in cross region data transfer charges.

Conclusion

It is possible to implement a key rotation strategy that meet security and/or compliance requirements through manipulation of AWS service behaviors. The rule of thumb being that data copy actions enable new key selection and crossing an AWS account or AWS Region boundary causes customer data re-encryption with new keys.

Building a Stronger AWS Developer Community

The cloud market continues to get more competitive.

AWS built its early success by winning developers first. Startups and builders were willing to take risks, move fast, and trust new platforms if those platforms made their jobs easier. AWS became the default choice because it gave developers access to infrastructure and services that previously required enormous capital, time, and operational overhead.

That advantage should not be taken for granted.

As the market matures, competitors are closing the gap. Microsoft in particular understands something important: developers and operations professionals are often the real catalyst for cloud adoption inside an enterprise. CIOs, CTOs, and procurement teams may approve the decision, but developers and operators heavily influence which technologies ever make it that far.

If AWS wants to maintain its leadership position, we cannot rely only on top-down executive relationships. We must continue to win the people who actually build and operate systems.

Developers Drive Adoption

Developers and operations professionals make a staggering number of technology decisions.

They are the people looking for better, faster, and more reliable ways to do their jobs. They are also the people who inherit the responsibility when a platform goes into production. Because of that, they tend to trust what they know, avoid unnecessary complexity, and remain loyal to tools and vendors that consistently make their lives easier.

This is one of Microsoft’s greatest strengths.

Microsoft developers and system administrators are often deeply loyal to the Microsoft ecosystem because Microsoft has spent decades investing directly in that relationship. Visual Studio is not just an IDE. It is a platform for influence. Azure services are integrated directly into the development workflow, making Azure feel like the natural cloud choice for many Microsoft developers.

Microsoft has also built dedicated developer and cloud evangelist teams whose sole focus is outreach: creating content, participating in technical communities, supporting conferences, engaging in developer forums, and helping customers solve real implementation problems.

They are not just selling products. They are building loyalty.

AWS Is Drifting Away From Its Original Strength

AWS started by gaining the trust of developers.

Our strategy today has shifted heavily toward executive buy-in: CIOs, CISOs, CTOs, and enterprise leadership. That matters, but it is incomplete.

Our public messaging often targets too broad an audience and lacks the technical depth developers actually need. Developers look past polished marketing language very quickly. They test services, identify limitations, and decide whether a platform will create operational pain or reduce it.

A shiny message does not survive first contact with implementation.

When developers struggle to understand how to use a service, when documentation is fragmented, or when the simplest path is unclear, we create friction that competitors can use against us.

Developers do not choose the most powerful solution. They often choose the clearest one.

Complexity Is Becoming a Competitive Weakness

AWS became successful because it enabled access.

We made computing power available on demand, and we created a platform flexible enough to support nearly any use case. That flexibility became one of our greatest strengths, but it also created a problem: complexity.

We now offer a portfolio of services with countless configuration options, overlapping capabilities, fragmented documentation, and too many places for customers to search for answers.

For a highly experienced engineer, this flexibility can be powerful.

For everyone else, it can be a barrier.

It is easy to get started with AWS. It is much harder to use AWS well.

Many customers do not want to make a second investment in becoming deep experts just to use the services they are already paying for. They want solutions that are clear, well-documented, and operationally manageable.

If we ignore that, our breadth becomes a deterrent rather than an advantage.

What AWS Needs

Building a stronger AWS developer community requires coordination and focus.

We already do many things well:

• AWS Lofts

• re:Invent

• launch visibility at major conferences

• strong introductory documentation

• active forums and blogs

• broad service coverage

• a strong technical brand

The problem is fragmentation.

Documentation lives in one place. Examples live somewhere else. Questions are answered somewhere else. Training is disconnected. Developer resources are difficult to discover unless customers already know where to look.

We need a true developer center.

We need developer outreach that feels intentional, not accidental.

That means:

• a clear and visible AWS developer community

• better organization of documentation, examples, forums, and training

• stronger developer-specific events and outreach

• deeper documentation with real-world examples across all major use cases

• stronger investment in tools and integrations that make AWS a natural part of the development cycle

• complete service UI and operational workflows, not just APIs

• SDK and language champions who represent specific developer communities

• less fragmentation and overlap across AWS services

• a stronger emphasis on ease of use in roadmap decisions

Ease of use should be treated as a product feature, not an afterthought.

The Real Competitive Battle

Cloud competition is not just about features.

It is about trust.

Developers trust the platforms that help them succeed under pressure. They trust the vendors whose documentation works at 2 a.m. They trust the tools that reduce ambiguity instead of creating more of it.

That trust creates loyalty, and loyalty creates long-term platform adoption.

AWS won early by earning that trust.

We should make sure we do not lose it.

Amazon Web Services (AWS) Certified Security Specialty (CSS) Beta Exam

*** 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

• Duration: ~3hr Exam Time
• Volume: > 100 Questions (Beta format)
• Style: Heavy focus on reading comprehension and identifying technical nuances.
• Service Focus: High concentration on services with direct security relationships:
  • Identity & Access Management (IAM)
  • AWS WAF & Shield
  • CloudFront & ACM (Certificate Manager)
  • Security Groups, NACLs, and VPC Architecture

My Exam Perspective

I found the questions to be very long, requiring significant reading comprehension to answer accurately. The possible answers were also lengthy, requiring careful differentiation to identify the most valid technical solution. There were substantial parallels to security-related questions found on the Professional-level Architect exams.

Amazon Cognito User Pool Admin Authentication Flow with AWS SDK For .NET

Implementing the Amazon Cognito User Pool Admin Authentication Flow with AWS SDK For .NET offers a path to implement user authentication without management of a host components otherwise needed to signup, verify, store and authenticate a user. Though Cognito is largely framed as a mobile service, it is well suited to support web applications. In order to implement this process you would use the Admin Auth Flow outlined in the AWS produced slide below. This example assumes that you have already configured both a Cognito User Pool w/ an App, ensuring the "Enable sign-in API for server-based authentication (ADMIN_NO_SRP_AUTH)" is checked for that app on the App tab and that no App client secret is defined for that App. App client secrets are not supported in the .NET SDK. It is also assumed that a Federated Identity Pool is configured to point to the before mentioned User Pool.

This auth flow bypasses the use of Secure Remote Password (SRP) protocol protections heavily used by AWS to prevent passwords from even been sent over the wire. As a result, when used in a client server web application, your users passwords would be transmitted to the server and that communication must be encrypted with strong encryption to prevent compromise of user credentials. The below code implements a CognitoAdminAuthenticationProvider with Authenticate and GetCredentials members. The Authenticate method returns a wrapped ChallengeNameType and AuthenticationResultType set of responses. A challenge will only be returned if additional details are needed for authentication, in which case you would simply ensure those details are included in the UserCredentials provided to the authenticate method and call Authenticate again. Once authenticated, a AuthenticationResultType will be included in the result and can be used to call the GetCredentials method and obtain temporary AWS Credentials.

Usage of the above code would look something like the below. This example uses the temporary credentials to call S3 ListBuckets.

As an additional note, the options for the CognitoAWSCredentials Logins dictionary are listed below. This example uses the last listed value.

Logins: {
   'graph.facebook.com': '[FBTOKEN]',
   'www.amazon.com': '[AMAZONTOKEN]',
   'accounts.google.com': '[GOOGLETOKEN]',
   'api.twitter.com': '[TWITTERTOKEN]',
   'www.digits.com': '[DIGITSTOKEN]',
   'cognito-idp.[region].amazonaws.com/[your_user_pool_id]': '[id token]'
}