Task 2.5: Design a solution to meet performance objectives

• AAmazon Neptune, with accounts, devices and addresses stored as vertices connected by edges

  Correct

  Neptune is a graph database built to store relationships and run queries that navigate highly connected data, such as fraud rings that share devices or addresses.

• BAmazon Redshift, with nightly joins between transaction and account tables

  Incorrect

  Redshift is a data warehouse for analytic queries over large data sets. Nightly batch joins do not answer within milliseconds per transaction.

• CAmazon DynamoDB, with one item per account and a list of linked accounts in each item

  Incorrect

  DynamoDB is fast for key-based access, but following links several hops deep needs many dependent lookups that the application must perform itself.

• DAmazon OpenSearch Service, with one document per transaction and full-text search on the fields

  Incorrect

  OpenSearch Service is built for search and log analytics. It does not traverse relationships between entities several hops deep.

Multi-hop relationship queries are the defining access pattern of a graph database.

• ASwitch the table to on-demand capacity mode so that reads are never throttled

  Incorrect

  On-demand mode changes how throughput is billed and scaled. Reads still come from DynamoDB with single-digit millisecond latency, not microseconds.

• BAdd a global table replica in every Region where the mobile app has users

  Incorrect

  Replicas bring data closer to users, but each read is still a DynamoDB read in milliseconds.

• CPut an Amazon ElastiCache cluster in front of the table and write the caching logic into the service

  Incorrect

  This can reach microsecond reads, but the developers would write and maintain the caching and invalidation code that they want to avoid.

• DAdd a DynamoDB Accelerator (DAX) cluster and switch the service to the DAX client

  Correct

  DAX is a DynamoDB-compatible in-memory cache that delivers microsecond reads for cached items, and it works with existing DynamoDB API calls, so the application does not manage cache data itself.

Microseconds on top of DynamoDB with the same API is DAX; ElastiCache works but brings its own cache code.

• ALaunch the instances in a spread placement group so that each one runs on separate hardware

  Incorrect

  A spread placement group places instances on distinct hardware to limit correlated failures. It does not give the low-latency network that tightly coupled jobs need.

• BLaunch the instances in a cluster placement group in one Availability Zone

  Correct

  A cluster placement group packs instances close together inside one Availability Zone for low-latency, high-throughput networking between nodes.

• CSpread the instances across three Availability Zones with an Auto Scaling group

  Incorrect

  Spreading nodes across zones adds latency between them, which slows a job where nodes exchange messages constantly.

• DAttach an Elastic Fabric Adapter to each instance for the MPI traffic

  Correct

  An Elastic Fabric Adapter lets HPC applications that use MPI communicate between instances with lower latency and higher throughput than standard TCP networking.

• EUse burstable T instances to cut cost when the solver is idle between time steps

  Incorrect

  Burstable instances give a baseline CPU level with short bursts, which does not suit sustained, compute-heavy solver runs.

• FStore the input data on Amazon FSx for Lustre linked to the S3 bucket that holds it

  Correct

  FSx for Lustre is a high-performance file system with sub-millisecond latencies and up to multiple TBps of throughput, and it can be linked to a data repository on Amazon S3.

Tightly coupled HPC needs nodes close together, a low-latency fabric and a parallel file system: cluster placement group, EFA and FSx for Lustre.

• ACreate an Athena capacity reservation and assign the analysts' workgroup to it so that their queries run on dedicated capacity

  Incorrect

  Capacity reservations give dedicated serverless processing capacity and let you prioritize workgroups and control how they are billed. Queries on reserved capacity still read every byte of the CSV files they touch.

• BSplit the hourly CSV files into many files of about 1 MB each so that Athena can read more of them in parallel

  Incorrect

  AWS advises against datasets with many small files: Athena lists every location and pays an overhead for each file, which makes queries slower, and the queries still read all 80 columns.

• CConvert the data to a columnar format such as Apache Parquet with appropriately large files

  Correct

  Columnar formats let Athena read only the columns a query needs and use file metadata to skip unneeded parts of the data, so reading 5 of 80 columns scans a small fraction of the data.

• DPartition the data by date and configure partition projection on the table for the date partition key

  Correct

  Partitioning restricts each query to the matching dates. With partition projection, Athena calculates partition values and locations from table properties, which automates partition management, so new hours need no crawler or manual partition updates.

• ETurn on query result reuse for the workgroup so that Athena returns stored results instead of scanning the data again

  Incorrect

  Result reuse returns the stored result of a previous matching query, which helps when the same query is rerun. These ad hoc queries each use a different date range, so there is nothing to reuse.

The deciding constraints are fewer bytes read per query, staying on Athena, and no manual partition maintenance. Capacity reservations and result reuse change how queries run or are billed, not what a new query scans, and many small files make Athena slower. Parquet cuts the columns read, and date partitions with partition projection cut the rows read while new hours become queryable automatically.

• AInstance store volumes on an instance type that offers them

  Correct

  Instance store disks are physically attached to the host and are ideal for temporary data such as buffers, caches and scratch data.

• BAmazon EFS with Elastic throughput mounted on every instance

  Incorrect

  EFS is shared network storage, not storage attached to the host.

• CAmazon S3 Standard

  Incorrect

  Object storage over the network is not local scratch space.

• DA large gp3 EBS volume with maximum provisioned IOPS

  Incorrect

  EBS volumes are network-attached and persist beyond what the scratch data needs.

Temporary scratch data with the lowest latency goes on instance store.

• APut the function in a VPC

  Incorrect

  VPC access adds network reach, not CPU.

• BAdd reserved concurrency

  Incorrect

  Reserved concurrency limits and guarantees concurrency; it does not speed up one invocation.

• CIncrease the function timeout to 15 minutes

  Incorrect

  A longer timeout lets the function run longer but not faster.

• DIncrease the function's memory setting

  Correct

  Lambda allocates CPU power in proportion to the configured memory, so more memory gives a CPU-bound function more CPU.

More memory means more CPU for a Lambda function.

• AAdd a DAX cluster in front of the table

  Incorrect

  DAX caches reads but does not avoid scanning for a new access pattern.

• BIncrease the table's read capacity

  Incorrect

  More capacity makes scans cost more; they still read the whole table.

• CAdd a global secondary index on customer ID and order date

  Correct

  Global secondary indexes support queries on different attributes than the table's key.

• DExport the table to S3 every night and query it with Athena

  Incorrect

  Nightly exports are a day old and slow for an interactive screen.

New access patterns on DynamoDB are served by global secondary indexes.

• AUNLOAD the tables to Amazon S3 as Parquet every night and let the data science account query the files with Amazon Athena

  Incorrect

  UNLOAD writes query results to files in S3. That is a copy, and a nightly copy is up to a day old, while the team needs the latest committed data.

• BTurn on concurrency scaling for the cluster's queues so that the data science queries run on extra capacity added for them

  Incorrect

  Concurrency scaling adds transient capacity to the same cluster for bursts of concurrent queries, and its charges accrue to the cluster's account, so the data science compute is not billed to the data science account.

• CShare the tables through a Redshift datashare with a Redshift Serverless workgroup in the data science account

  Correct

  Data sharing gives other clusters and Serverless workgroups, also in other accounts, access to live data without copying it. The consumer runs queries on its own compute, which isolates the workloads and lets each account pay for its own queries.

• DUse automatic WLM with the highest priority for the dashboard queue and a low priority for the data science queue

  Incorrect

  Query priorities decide which queries get resources when they contend for the same cluster. The heavy queries still run on, and are paid for by, the dashboard cluster.

Three constraints decide it: live data with no copies, no effect on the dashboards, and compute billed to another account. Concurrency scaling and WLM priorities both keep the work and the bill on the producer cluster, and a nightly UNLOAD is a stale copy. A datashare consumed by a workgroup in the data science account gives read workload isolation and chargeback while everyone reads the same committed data.