AWS Certified Solutions Architect - Associate (SAA-C03)

The most secure way for an external service to obtain programmatic access to a customer’s AWS account, especially for a read-only purpose such as describing Amazon EC2 instances and retrieving Amazon CloudWatch metrics, is to allow the external service to assume an IAM role that the customer defines in their own account. The main advantage of cross-account roles is that the company never receives or stores long-term credentials; instead, it obtains temporary credentials through AWS STS when it needs to make API calls. This configuration follows the principle of least privilege and ensures that the permission scope is limited to exactly what the external service requires.

An example scenario would be for the customer to create an IAM role with the necessary read-only permissions for EC2 and CloudWatch, along with a trust policy that trusts the company’s AWS account ID. Whenever the feature in the monitoring service needs to access the customer’s resources, it calls the "AssumeRole" API on the customer’s role using AWS STS. This approach helps reduce risk since no static credentials are shared or stored, and the permissions can be enforced and audited in the customer account.

Storing and encrypting long-term credentials (such as access keys) in one account for multiple customers is generally discouraged because those credentials could be misused if compromised, and rotating them is more challenging. Using cross-account roles with AssumeRole not only reduces this management overhead but also ensures credential transparency, accountability, and easy rotation (each organization can simply update or revoke the trust when needed).

Enabling storage autoscaling in Amazon RDS is the most straightforward way to address low disk space without incurring downtime. By allowing RDS to automatically increase storage capacity as needed, you avoid manual interventions such as taking snapshots, restoring from backups, or changing the instance storage type. Simply modifying the configuration to enable storage autoscaling takes care of unexpected increases in data growth and helps ensure that the database remains available and performant.

Other approaches either do not directly address the underlying storage issue or require more complex, time-consuming procedures that could disrupt application availability. Backing up the database and restoring it would involve additional steps and potential downtime, and changing the instance storage type or instance class alone does not guarantee additional disk space without further action.

Using AWS Service Catalog is the best way to centrally manage and deploy a standard set of solutions and tools that customers can consume for self-service purposes. AWS Service Catalog allows administrators to create, organize, and govern commonly used IT services, and it presents them as products that other users can provision on their own. This structure ensures that deployments remain consistent and aligns with the company's best practices and security requirements. Additionally, it provides fine-grained access control, centralized governance, and the ability to track provisioning and usage, which are key benefits that other services do not directly offer for product-based self-service.

For instance, a consulting firm building a standardized data processing solution could define a product in AWS Service Catalog with an underlying AWS CloudFormation template that includes an Amazon S3 bucket and an Amazon EMR cluster. The company’s customers can then select this product from the catalog and quickly launch a pre-approved, repeatable setup without having to manage the CloudFormation template themselves or worry about adjustable configurations that might cause inconsistencies.

Using Amazon Athena to query AWS CloudTrail logs offers a straightforward way to find and analyze Access Denied or Unauthorized errors without requiring you to write extensive custom code or manage additional infrastructure. Because Athena can query log data directly in Amazon S3 with standard SQL statements, you significantly reduce operational overhead. In contrast, approaches that involve creating custom scripts or building dashboards typically require more time and effort to deploy and maintain, such as writing and updating code or configuring data visualization tools. By leveraging Athena’s integration with AWS CloudTrail and S3, you can rapidly pinpoint errors related to Identity and Access Management (IAM) permissions and speed up incident analysis and troubleshooting.

For example, you could store CloudTrail logs in S3, configure an AWS Glue crawler to make these logs queryable as a table in Athena, and run SQL queries to filter on event names or error messages containing “AccessDenied” or “UnauthorizedOperation.” Instantly returning query results in the Athena console allows you to zero in on any issues with minimal setup time.

Using Amazon RDS Proxy to manage connections for the Aurora PostgreSQL database reduces downtime during failover and scaling events because the proxy handles the underlying database connectivity for the application. When changes occur to the database writer instance, the application’s existing connections remain open through the proxy, minimizing the failover window and requiring far less manual intervention. This results in a much faster switchover and helps avoid dropping or reinitializing client connections.

Other approaches do not match the needs of reducing downtime with minimal operational overhead. Simply creating more read replicas does not minimize writer failover downtime—read replicas primarily serve read requests but do not automatically reduce the failover delay for write operations. Manually setting up a secondary cluster and shifting endpoints requires more operational overhead and is prone to errors if failover procedures are not automated. Using an ElastiCache cluster can offload some read traffic to the cache layer, but it does not address the database failover downtime for write queries.

A multi-Region deployment that uses Amazon Aurora Global Database provides the highest level of fault tolerance with minimal downtime. Aurora Global Database can replicate data across Regions with minimal lag while offering fast local reads and near-instantaneous recovery if a Region becomes unavailable. By deploying the web tier and application tier in the second Region, you have a fully functional stack available for failover. Using Amazon Route 53 health checks with a failover routing policy ensures that traffic is redirected to the healthy Regional endpoint when failures are detected. This setup helps you promote the secondary database cluster to the primary role quickly if the primary Region goes down, reducing downtime significantly.

Other approaches, such as using AWS DMS or stretching an Auto Scaling group across Regions, are either less efficient or not feasible. For instance, AWS DMS is often used for data migration or continuous replication scenarios, but it would not provide the same near real-time failover capabilities that Aurora Global Database offers. Furthermore, an Auto Scaling group operates within a single Region; you would typically set up a separate Auto Scaling group in each Region instead of stretching one group across Regions.

Example:

Imagine you have a streaming platform that primarily serves users in North America. As your user base expands to Europe, deploying your web and application tiers in a new European Region alongside an Aurora Global Database secondary cluster will allow users there to enjoy low-latency connections. If the primary North American Region comes under stress or experiences an outage, Amazon Route 53 health checks detect the Regional failure and promptly redirect traffic to the European deployment, where the secondary Aurora cluster can quickly be promoted to primary.

A fully managed DB service that supports encryption at rest provides a secure and straightforward way to handle transactional workloads while minimizing administrative efforts. By using Amazon RDS with encryption enabled, it is possible to protect sensitive data on disk and in automated backups without needing to manage the underlying database infrastructure. This approach offloads patching, backups, scaling, and high availability to AWS, thereby reducing operational overhead.

On the other hand, storing databases on Amazon EC2 requires more manual management of backups, patching, and resilience. Using Amazon CloudWatch Logs primarily provides observability rather than comprehensive data encryption. Storing data in Amazon S3 with Amazon Macie helps discover and protect sensitive data in object storage, but this does not address the requirement of hosting transactional databases with reduced overhead—and Macie is not a database solution.

Using AWS Lambda for processing provides automatic scaling, which allows the application to handle varying concurrency without having to manually provision or manage servers. Storing the photos in Amazon S3 is cost-effective and ensures virtually unlimited scalability. Retaining Amazon DynamoDB for the metadata is also ideal because DynamoDB offers consistent performance at any scale, especially when properly using features like auto scaling.

A solution that stores both data and images in DynamoDB alone can become costly and is not typically the recommended practice for storing large objects like photos. Simply increasing the number of Amazon EC2 instances and using Provisioned IOPS volumes can help with performance but does not natively handle highly variable traffic without additional services or elasticity configurations. Using services specifically for streaming and data ingestion is more aligned with continuous data ingestion scenarios, which does not match the real-time image processing requirements as effectively as a serverless approach with Lambda and S3.

In a real-world scenario, this strategy provides a scalable architecture for image processing. For instance, the Lambda function can be triggered each time an object is put into an S3 bucket. The function can then apply the desired transformations or frames to the uploaded photo. DynamoDB remains well-suited for storing metadata such as user preferences, timestamps, and relevant attributes about the photo frames.

In this scenario, a web-based application must read and store a large repository of text documents—totaling 900 TB. Amazon Simple Storage Service (Amazon S3) provides virtually unlimited scalability at a more cost-effective rate compared to alternatives, such as Amazon EBS or Amazon EFS. Employing an object-based storage solution is ideal for this workload because it can handle high throughput and deliver the necessary durability and availability. By contrast, a service like Amazon OpenSearch Service (Amazon Elasticsearch Service) is well-suited for search and analytics but would be prohibitively expensive to store all 900 TB of data long-term.

Using Amazon S3 also offers flexible storage classes (e.g., S3 Standard, S3 Intelligent-Tiering, or S3 Glacier) that can further optimize storage costs, especially for data that is accessed infrequently. This combination of scalability and tiered pricing makes Amazon S3 the most cost-effective choice for hosting and delivering large volumes of static data.

Example

A common approach is to serve static files—such as large text documents—from an S3 bucket using presigned URLs or by fronting S3 with Amazon CloudFront as a content delivery network to reduce latency and offload traffic from origin servers. The combination of S3, CloudFront, and EC2 ensures that the solution can auto scale when needed while minimizing overall costs.

Serving both static and dynamic content through a single Amazon CloudFront distribution—where static content is sourced from Amazon S3 and dynamic content from the Application Load Balancer (ALB)—is a best practice for optimizing performance and reducing latency. CloudFront’s global network of edge locations helps cache and accelerate the delivery of both types of content to end users. By configuring multiple origins (S3 for static assets and ALB for dynamic requests) within the same CloudFront distribution, you can use path-based routing to cache static assets while allowing pass-through of dynamic requests to the ALB. Amazon Route 53 can then provide DNS resolution, typically via an alias record, that points to the CloudFront distribution. This approach simplifies your architecture and reduces cost by eliminating the need to introduce AWS Global Accelerator for this scenario.

Using AWS Global Accelerator is valuable in specific use cases—such as non-HTTP/HTTPS traffic or multi-region active-active ALB deployments—but for a standard web application serving static and dynamic data over HTTP/HTTPS, a single CloudFront distribution is typically sufficient to provide edge caching, global reach, and lower latency. Creating multiple domain names or separate endpoints would overcomplicate the setup and does not offer significant benefits over CloudFront alone in this common web-serving pattern.

Example

Assume you have an S3 bucket named “my-app-static-content” and an ALB with a DNS name of “my-app-alb-123456789.us-east-1.elb.amazonaws.com.” You can configure CloudFront with an origin for the S3 bucket to handle requests for paths like “/static/” and another origin for the ALB to handle “/api/” or “/dynamic/.” Then, you create a behavior in CloudFront that routes “/static/” to the S3 origin and another behavior that routes all other paths to the ALB origin. Finally, use Route 53 to create an alias record pointing to the CloudFront distribution, for example, “app.example.com → d1234abcdef.cloudfront.net.”