Correct option:

Configure SAML-based authentication tied to an IAM role that has the PowerUserAccess managed policy attached to it. Attach a customer-managed policy that denies access to RDS in any AWS Region except us-east-1

Security Assertion Markup Language 2.0 (SAML) is an open federation standard that allows an identity provider (IdP) to authenticate users and pass identity and security information about them to a service provider which is an AWS application or service for the current use-case. With SAML, you can enable a single sign-on experience for your users across many SAML-enabled applications and services. Users authenticate with the IdP once using a single set of credentials, and then get access to multiple applications and services without additional sign-ins.

For the given scenario, the company wants to control access to on-premises as well as AWS Cloud resources (specifically via the AWS Management Console) using Active Directory, so it should use SAML 2.0 federated users to access the AWS Management Console. You also create an IAM role with a trust policy that sets the SAML provider as the principal, which establishes a trust relationship between your organization and AWS. The role's permission policy establishes what users from your organization are allowed to do in AWS. In this case, the role will have a PowerUserAccess managed policy attached. As the PowerUserAccess managed policy will allow the developers to create RDS instances in any Region, therefore, you also need to attach a customer-managed policy that denies access to RDS in any AWS Region except us-east-1.

 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html

At a high-level, it is useful to think of these access privileges in the form of this equation:

PowerUserAccess = AdministrativeAccess - IAM

Incorrect options:

Configure SAML-based authentication tied to an IAM role that has the AdministrativeAccess managed policy attached to it. Attach a customer-managed policy that denies access to RDS in any AWS Region except us-east-1 - Using an IAM role with an AdministrativeAccess managed policy attache to it would violate the key requirement of providing the least privileges for developers. PowerUserAccess provides full access to AWS services and resources but does not allow management of users and groups.

At a high-level, it is useful to think of these access privileges in the form of this equation:

PowerUserAccess = AdministrativeAccess - IAM

So, PowerUserAccess provides just the right access privileges required for the given use-case.

Set up an IAM user for each developer and add them to the developer IAM group that has the PowerUserAccess managed policy attached to it. Attach a customer-managed policy that allows the developers access to RDS only in us-east-1 Region - Setting up an IAM user for each developer and add them to the developer IAM group goes against the requirement of minimizing the operational burden on the DevOps team because this solution does not take advantage of the existing Active Directory that supports SAML-based authentication.

Configure SAML-based authentication tied to an IAM role that has a PowerUserAccess managed policy and a customer-managed policy that denies all the developers access to any AWS services except AWS Service Catalog. Within AWS Service Catalog, create a product containing only RDS service in us-east-1 region - This option is a distractor as it's too restrictive. As the customer-managed policy denies the developers access to any AWS services except AWS Service Catalog, therefore it would limit access to all other services in any Region, hence this option is incorrect.

References:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html

Correct option:

Use Centralized VPC Endpoints for connecting with multiple VPCs, also known as shared services VPC - A VPC endpoint allows you to privately connect your VPC to supported AWS services without requiring an Internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Endpoints are virtual devices that are horizontally scaled, redundant, and highly available VPC components. They allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic.

VPC endpoints enable you to reduce data transfer charges resulting from network communication between private VPC resources (such as Amazon Elastic Cloud Compute—or EC2—instances) and AWS Services (such as Amazon Quantum Ledger Database, or QLDB). Without VPC endpoints configured, communications that originate from within a VPC destined for public AWS services must egress AWS to the public Internet in order to access AWS services. This network path incurs outbound data transfer charges. Data transfer charges for traffic egressing from Amazon EC2 to the Internet vary based on volume. With VPC endpoints configured, communication between your VPC and the associated AWS service does not leave the Amazon network. If your workload requires you to transfer significant volumes of data between your VPC and AWS, you can reduce costs by leveraging VPC endpoints.

In larger multi-account AWS environments, network design can vary considerably. Consider an organization that has built a hub-and-spoke network with AWS Transit Gateway. VPCs have been provisioned into multiple AWS accounts, perhaps to facilitate network isolation or to enable delegated network administration. When deploying distributed architectures such as this, a popular approach is to build a "shared services VPC, which provides access to services required by workloads in each of the VPCs. This might include directory services or VPC endpoints. Sharing resources from a central location instead of building them in each VPC may reduce administrative overhead and cost.

https://aws.amazon.com/blogs/architecture/reduce-cost-and-increase-security-with-amazon-vpc-endpoints/

Incorrect options:

Use Transit VPC to reduce cost and share the resources across VPCs - Transit VPC uses customer-managed Amazon Elastic Compute Cloud (Amazon EC2) VPN instances in a dedicated transit VPC with an Internet gateway. This design requires the customer to deploy, configure, and manage EC2-based VPN appliances, which will result in additional EC2 instances, and potentially third-party product and licensing charges. Note that this design will generate additional data transfer charges for traffic traversing the transit VPC: data is charged when it is sent from a spoke VPC to the transit VPC, and again from the transit VPC to the on-premises network or to a different AWS Region. Transit VPC is not the right choice here because it's not cost-optimal for the given use-case.

https://d0.awsstatic.com/aws-answers/AWS_Single_Region_Multi_VPC_Connectivity.pdf

Use Fully meshed VPC Peers - This approach creates multiple peering connections to facilitate the sharing of information between resources in different VPCs. This design connects multiple VPCs in a fully meshed configuration, with peering connections between each pair of VPCs. With this configuration, each VPC has access to the resources in all other VPCs. Each peering connection requires modifications to all the other VPCs’ route tables and, as the number of VPCs grows, this can be difficult to maintain. And keep in mind that AWS recommends a maximum of 125 peering connections per VPC. It's complex to manage and isn't the right fit for the current scenario.

https://d0.awsstatic.com/aws-answers/AWS_Single_Region_Multi_VPC_Connectivity.pdf

Use VPCs connected with AWS Direct Connect - This approach is a good alternative for customers who need to connect a high number of VPCs to a central VPC or to on-premises resources, or who already have an AWS Direct Connect connection in place. This design also offers customers the ability to incorporate transitive routing into their network design. For example, if VPC A and VPC B are both connected to an on-premises network using AWS Direct Connect connections, then the two VPCs can be connected to each other via AWS Direct Connect. Direct Connect requires physical cables and takes about a month for setting up. This option is not the best fit for the current scenario as there is no on-premises component for the given IT infrastructure.

References:

https://aws.amazon.com/blogs/architecture/reduce-cost-and-increase-security-with-amazon-vpc-endpoints/

https://d0.awsstatic.com/aws-answers/AWS_Single_Region_Multi_VPC_Connectivity.pdf

Correct option:

Provision On-Demand Instances for the web and application tiers and Reserved Instances for the database tier

EC2 Instances support five different ways to pay for provisioning the servers: On-Demand, Savings Plans, Reserved Instances, Spot Instances and Dedicated Hosts.

 https://aws.amazon.com/ec2/pricing/

An On-Demand Instance is an instance that you use on-demand. You have full control over its lifecycle — you decide when to launch, stop, hibernate, start, reboot, or terminate it. There is no long-term commitment required when you purchase On-Demand Instances. There is no upfront payment and you pay only for the seconds that your On-Demand Instances are running. The price per second for running an On-Demand Instance is fixed. On-demand instances cannot be interrupted. However, On-demand instances are not as cost-effective as Reserved instances.

A Spot Instance is an unused EC2 instance that is available for less than the On-Demand price. Because Spot Instances enable you to request unused EC2 instances at steep discounts (up to 90%), you can lower your Amazon EC2 costs significantly. Spot Instances are well-suited for data analysis, batch jobs, background processing, and optional tasks. These can be terminated at short notice, so these are not suitable for critical workloads that need to run at a specific point in time.

Reserved Instances provide you with significant savings (up to 75%) on your Amazon EC2 costs compared to On-Demand Instance pricing. Reserved Instances are not physical instances, but rather a billing discount applied to the use of On-Demand Instances in your account. You can purchase a Reserved Instance for a one-year or three-year commitment, with the three-year commitment offering a bigger discount. Reserved instances cannot be interrupted.

For the given use-case, only the web and application tiers would be re-engineered using API Gateway and Lambda within a duration of 6 months, so you cannot use Reserved Instances for these tiers as the minimum duration to purchase a Reserved Instance is 1 year. Additionally, using Spot Instances for these tiers is also ruled out because these can be terminated at short notice and would not be able to offer reliability for the web and application tiers. Therefore On-Demand is the best option for the web and application tiers. As the proposed transformation would not impact the database tier running on RDS MySQL, therefore you can purchase Reserved Instances for the database tier as the most cost-effective solution.

Incorrect options:

Provision Reserved Instances for the web, application and database tiers - As explained above, Reserved Instances are not a good fit for running the web and application tiers, so this option is not correct.

Provision Spot Instances for the web and application tiers and Reserved Instances for the database tier - As explained above, Spot Instances are not a good fit for running the web and application tiers, so this option is not correct.

Provision Reserved Instances for the web and application tiers and On-Demand Instances for the database tier - As explained above, Reserved Instances are not a good fit for running the web and application tiers, so this option is not correct. Also using On-Demand Instances for the database tier is not the most cost-effective option as you should use Reserved Instances for the database tier.

Reference:

https://aws.amazon.com/ec2/pricing/

Correct option:

The research assistant does not need to pay any transfer charges for the image upload

There are no S3 data transfer charges when data is transferred in from the internet.

https://aws.amazon.com/s3/pricing/

Also with S3TA, you pay only for transfers that are accelerated. Therefore the research assistant does not need to pay any transfer charges for the image upload because S3TA did not result in an accelerated transfer.

https://aws.amazon.com/s3/transfer-acceleration/

Incorrect options:

The research assistant only needs to pay S3TA transfer charges for the image upload - Since S3TA did not result in an accelerated transfer, there are no S3TA transfer charges to be paid.

The research assistant only needs to pay S3 transfer charges for the image upload - There are no S3 data transfer charges when data is transferred in from the internet. So this option is incorrect.

The research assistant needs to pay both S3 transfer charges and S3TA transfer charges for the image upload - There are no S3 data transfer charges when data is transferred in from the internet. Since S3TA did not result in an accelerated transfer, there are no S3TA transfer charges to be paid.

References:

https://aws.amazon.com/s3/transfer-acceleration/

https://aws.amazon.com/s3/pricing/

Correct option:

Set up a Direct Connect to each on-premises data center from different service providers and configure routing to failover to the other on-premises data center's Direct Connect in case one connection fails. Make sure that no VPC CIDR blocks overlap one another or the on-premises network

AWS Direct Connect links your on-premises data center to an AWS Direct Connect location over a standard Ethernet fiber-optic cable. One end of the cable is connected to your router, the other to an AWS Direct Connect router. With this connection, you can create virtual interfaces directly to public AWS services (for example, to Amazon S3) or to Amazon VPC, bypassing internet service providers in your network path. An AWS Direct Connect location provides access to AWS in the Region with which it is associated.

There are two types of Direct Connect connections:

Dedicated Connection: A physical Ethernet connection associated with a single customer. Customers can request a dedicated connection through the AWS Direct Connect console, the CLI, or the API. This supports speed of 1Gbps and 10Gbps.

Hosted Connection: A physical Ethernet connection that an AWS Direct Connect Partner provisions on behalf of a customer. Customers request a hosted connection by contacting a partner in the AWS Direct Connect Partner Program, who provisions the connection. This supports speed of 50Mbps, 100Mbps, 200Mbps, 300Mbps, 400Mbps, 500Mbps, 1Gbps, 2Gbps, 5Gbps, and 10Gbps.

 https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html

As the use-case requires a hybrid network architecture that is highly available and supports high bandwidth, therefore you should configure the Direct Connect based hybrid network to achieve maximum resiliency for critical workloads by using separate connections from different service providers that terminate on separate devices in more than one location.

https://docs.aws.amazon.com/directconnect/latest/UserGuide/maximum_resiliency.html

https://docs.aws.amazon.com/directconnect/latest/UserGuide/high_resiliency.html

Incorrect options:

Set up multiple hardware VPN connections between AWS cloud and the on-premises data centers. Configure each subnet's traffic through different VPN connections for redundancy. Make sure that no VPC CIDR blocks overlap one another or the on-premises network

Set up multiple software VPN connections between AWS cloud and the on-premises data centers. Configure each subnet's traffic through different VPN connections for redundancy. Make sure that no VPC CIDR blocks overlap one another or the on-premises network

A VPN connection refers to the connection between your VPC and your own on-premises network. Site-to-Site VPN supports Internet Protocol security (IPsec) VPN connections. VPNs on AWS come in three flavours: hardware only, software only and a mix of hardware/software. The hardware only VPN uses a hardware VPN device to connect the virtual private gateway on the AWS end to a customer VPN gateway on the customers end, via IPsec VPN tunnels.

Hardware only VPNs include both the AWS managed AWS Site-to-Site VPN solution and the AWS VPN CloudHub.

You can also create a VPN connection to your remote network by using an Amazon EC2 instance in your VPC that's running a third party software VPN appliance.

The limitation with both options is that VPNs do not support high bandwidth data transfer as these operate over the public internet infrastructure. VPN Connections are a good solution if you have an immediate need, and have low to modest bandwidth requirements.

https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html

Set up a Direct Connect as primary connection for all on-premises data centers with another VPN as backup. Configure both connections to use the same virtual private gateway and BGP. Make sure that no VPC CIDR blocks overlap one another or the on-premises network - This option has been added as a distractor as you cannot have just one Direct Connect connection for multiple on-premises data centers that are in different locations. Also having a VPN as a backup does not provide a high-bandwidth and high-availability fallback option.

References:

https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html

https://docs.aws.amazon.com/directconnect/latest/UserGuide/maximum_resiliency.html

https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html

https://medium.com/@datapath_io/aws-direct-connect-vs-vpn-vs-direct-connect-gateway-97900cdf7d04

Correct option:

Generate a separate certificate for each FQDN in each AWS Region using AWS Certificate Manager. Associate the certificates with the corresponding ALBs in the relevant AWS Region

AWS Certificate Manager is a service that lets you easily provision, manage, and deploy public and private Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates for use with AWS services and your internal connected resources. SSL/TLS certificates are used to secure network communications and establish the identity of websites over the Internet as well as resources on private networks. AWS Certificate Manager removes the time-consuming manual process of purchasing, uploading, and renewing SSL/TLS certificates.

A fully qualified domain name (FQDN) is the complete DNS name for a computer, website, or other resource connected to a network or to the internet. For example, aws.amazon.com is the FQDN for Amazon Web Services. An FQDN includes all domains up to the top–level domain. For example, [subdomain1].[subdomain2]...[subdomainn].[apex domain].[top–level domain] represents the general format of an FQDN.

To use a certificate with an Application Load Balancer for the same site (the same fully qualified domain name, or FQDN, or set of FQDNs) in a different Region, you must request a new certificate for each Region in which you plan to use it. To use an ACM certificate with Amazon CloudFront, you must request the certificate in the US East (N. Virginia) Region.

Therefore, to migrate the web applications to a multi-Region architecture, you must request a separate certificate for each FQDN in each AWS Region using AWS Certificate Manager and then associate the certificates with the corresponding ALBs in the relevant AWS Region.

https://docs.aws.amazon.com/acm/latest/userguide/acm-regions.html

Incorrect options:

Generate a certificate for each FQDN via AWS Certificate Manager. Associate the same FQDN certificate with the ALBs in the relevant AWS Regions - As explained above, you cannot use the same certificate for a given FQDN across multiple AWS Regions, so this option is incorrect.

Generate a new certificate for each FQDN in the relevant AWS Region using AWS KMS. Associate the certificate with the corresponding ALBs in the relevant AWS Region

Generate a separate certificate for each FQDN in each AWS Region using AWS KMS. Associate the certificates with the corresponding ALBs in the relevant AWS Region

AWS KMS is a managed service that enables you to easily create and control the keys used for cryptographic operations. You can use KMS to centrally manage the encryption keys that control access to your data so that you can secure your data across AWS services. You cannot use KMS to provision or manage SSL/TLS certificates for an FQDN, so both these options are incorrect.

Reference:

https://docs.aws.amazon.com/acm/latest/userguide/acm-Regions.html

Correct option:

Attach an EFS file system to the on-premises servers to act as the NAS server. Mount the same EFS file system to the AWS based web servers running on EC2 instances to serve the content

Amazon Elastic File System (Amazon EFS) provides a simple, scalable, fully managed elastic NFS file system for use with AWS Cloud services and on-premises resources.

Amazon EFS is a Regional service storing data within and across multiple Availability Zones (AZs) for high availability and durability. Amazon EC2 instances can access your file system across AZs, Regions, and VPCs, while on-premises servers can access using AWS Direct Connect or AWS VPN. You can connect to Amazon EFS file systems from EC2 instances in other AWS Regions using an inter-Region VPC peering connection, and from on-premises servers using an AWS VPN connection. EFS is also POSIX compliant.

 https://aws.amazon.com/efs/

For the given use-case, you can attach an EFS file system to your on-premises servers, copy your data to it, and then process it in the cloud as desired, leaving your data in AWS for the long term. Further, you can mount the EFS file system from the EC2 instances for a concurrent access. Connecting to EFS is similar to connecting to your network drive since it supports NFS protocols, which are standard for network attached storage (NAS) devices. This ensures that the company can migrate the web infrastructure to AWS Cloud without delaying the content updation process as the underlying workflows do not need to be modified.

 https://aws.amazon.com/blogs/aws/amazon-efs-update-on-premises-access-via-direct-connect-vpc/

Incorrect options:

Set up an on-premises file gateway using Storage Gateway to replace the NAS server and then replicate the existing content to AWS. On the AWS Cloud, mount the same Storage Gateway bucket to the EC2 instance based web servers to serve the content

AWS Storage Gateway is a hybrid cloud storage service that gives you on-premises access to virtually unlimited cloud storage. The service provides three different types of gateways – Tape Gateway, File Gateway, and Volume Gateway – that seamlessly connect on-premises applications to cloud storage, caching data locally for low-latency access.

AWS Storage Gateway's file interface, or file gateway, offers you a seamless way to connect to the cloud in order to store application data files and backup images as durable objects on Amazon S3 cloud storage. File gateway offers SMB or NFS-based access to data in Amazon S3 with local caching.

https://docs.aws.amazon.com/storagegateway/latest/userguide/StorageGatewayConcepts.html

The issue with transitioning to Storage Gateway is that you would run into performance issues once the local cache fills up and then the application has to source the data from S3 which is the underlying object based storage. Moreover, S3 is not POSIX compliant and it does not support operations such as file append. The file gateway takes care of these abstractions but it also adds up to making this architecture not as scalable as just mounting EFS on both the on-premises servers as well as EC2 instances. So this option is incorrect.

Provision a cluster of EC2 instances based web servers running behind an Application Load Balancer on AWS. Share an EBS volume among all instances for accessing the content. Develop custom code to periodically synchronize this volume with the NAS server - You cannot share an EBS volume with multiple instances, so this option is incorrect.

Provision EC2 instances based web servers with an Auto Scaling group. Create a nightly data transfer batch job to update the web server instances from the NAS server - Using a nightly data transfer batch job to update the web server instances from the NAS server implies that the solution would delay the content updation process, which is a key requirement of the use-case. So this option is incorrect.

References:

https://aws.amazon.com/efs/

https://aws.amazon.com/blogs/aws/amazon-efs-update-on-premises-access-via-direct-connect-vpc/

https://aws.amazon.com/about-aws/whats-new/2017/02/aws-storage-gateway-supports-running-file-gateway-in-ec2-and-adds-file-share-security-options/

Correct options:

Use WAF geo match statement listing the countries that you want to block

Use WAF IP set statement that specifies the IP addresses that you want to allow through

AWS WAF is a web application firewall that helps protect your web applications or APIs against common web exploits that may affect availability, compromise security, or consume excessive resources. AWS WAF gives you control over how traffic reaches your applications by enabling you to create security rules that block common attack patterns and rules that filter out specific traffic patterns you define.

You can deploy AWS WAF on Amazon CloudFront as part of your CDN solution, the Application Load Balancer that fronts your web servers or origin servers running on EC2, or Amazon API Gateway for your APIs.

https://aws.amazon.com/waf/

To block specific countries, you can create a WAF geo match statement listing the countries that you want to block, and to allow traffic from IPs of the remote development team, you can create a WAF IP set statement that specifies the IP addresses that you want to allow through. You can combine the two rules as shown below:

https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-geo-match.html

Incorrect options:

Create a deny rule for the blocked countries in the NACL associated to each of the EC2 instances - A network access control list (ACL) is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. NACL does not have the capability to block traffic based on geographic match conditions.

Use ALB geo match statement listing the countries that you want to block

Use ALB IP set statement that specifies the IP addresses that you want to allow through

An Application Load Balancer (ALB) operates at the request level (layer 7), routing traffic to targets – EC2 instances, containers, IP addresses, and Lambda functions based on the content of the request. Ideal for advanced load balancing of HTTP and HTTPS traffic, Application Load Balancer provides advanced request routing targeted at the delivery of modern application architectures, including microservices and container-based applications.

An ALB cannot block or allow traffic based on geographic match conditions or IP based conditions. Both these options have been added as distractors.

References:

https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-geo-match.html

https://aws.amazon.com/blogs/security/how-to-use-aws-waf-to-filter-incoming-traffic-from-embargoed-countries/

Correct option:

Use Enhanced Fanout feature of Kinesis Data Streams to support the desired read throughput for the downstream applications

Amazon Kinesis Data Streams (KDS) is a massively scalable and durable real-time data streaming service. KDS can continuously capture gigabytes of data per second from hundreds of thousands of sources such as website clickstreams, database event streams, financial transactions, social media feeds, IT logs, and location-tracking events. By default, the 2MB/second/shard output is shared between all of the applications consuming data from the stream.

You should use enhanced fan-out if you have multiple consumers retrieving data from a stream in parallel. With enhanced fan-out developers can register stream consumers to use enhanced fan-out and receive their own 2MB/second pipe of read throughput per shard, and this throughput automatically scales with the number of shards in a stream.

https://aws.amazon.com/blogs/aws/kds-enhanced-fanout/

https://aws.amazon.com/blogs/aws/kds-enhanced-fanout/

Incorrect options:

Swap out Kinesis Data Streams with Kinesis Data Firehose to support the desired read throughput for the downstream applications - Amazon Kinesis Data Firehose is the easiest way to reliably load streaming data into data lakes, data stores, and analytics tools. It is a fully managed service that automatically scales to match the throughput of your data and requires no ongoing administration. It can also batch, compress, transform, and encrypt the data before loading it, minimizing the amount of storage used at the destination and increasing security. Kinesis Data Firehose can only write to S3, Redshift, Elasticsearch or Splunk. You can't have applications consuming data streams from Kinesis Data Firehose, that's the job of Kinesis Data Streams. Therefore this option is not correct.

Swap out Kinesis Data Streams with SQS Standard queues to support the desired read throughput for the downstream applications

Swap out Kinesis Data Streams with SQS FIFO queues to support the desired read throughput for the downstream applications

Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. SQS offers two types of message queues. Standard queues offer maximum throughput, best-effort ordering, and at-least-once delivery. SQS FIFO queues are designed to guarantee that messages are processed exactly once, in the exact order that they are sent. As multiple applications are consuming the same stream concurrently, both SQS Standard and SQS FIFO are not the right fit for the given use-case.

https://aws.amazon.com/kinesis/data-streams/faqs/

References:

https://aws.amazon.com/blogs/aws/kds-enhanced-fanout/

https://aws.amazon.com/kinesis/data-streams/faqs/

Correct option:

Set up separate Lambda functions to provision and terminate the Elastic Beanstalk environment. Configure a Lambda execution role granting the required Elastic Beanstalk environment permissions and assign the role to the Lambda functions. Configure cron expression based Amazon CloudWatch Events rules to trigger the Lambda functions

You can configure Lambda functions to make the Elastic Beanstalk API calls for provisioning and terminating the Elastic Beanstalk environment. To perform these API calls on a schedule, you can configure events in Amazon CloudWatch Events to trigger these Lambda functions at a specific time each day via cron expressions. Make sure that you attach the policy with the required Elastic Beanstalk environment permissions to the Lambda execution role.

https://aws.amazon.com/premiumsupport/knowledge-center/schedule-elastic-beanstalk-stop-restart/

https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html

Please review this excellent reference material for a deep-dive on how to stop and restart an Elastic Beanstalk environment on a schedule:

https://aws.amazon.com/premiumsupport/knowledge-center/schedule-elastic-beanstalk-stop-restart/

Incorrect options:

Leverage the activity task of an AWS Step Function to provision and terminate the Elastic Beanstalk environment. Create a role for the Step Function to allow it to provision and terminate the Elastic Beanstalk environment. Execute the Step Function daily and use the "wait state" to control the start and stop time - AWS Step Functions lets you coordinate multiple AWS services into serverless workflows so you can build and update apps quickly. Using Step Functions, you can design and run workflows that stitch together services such as AWS Lambda into feature-rich applications.

 https://aws.amazon.com/step-functions/

This option involves cost components that are not needed. There is no need to keep the Step Function running in a "wait state" for the most part of the day just to control the provisioning and termination of Elastic Beanstalk environment. This is better handled via a "serverless cron" type of solution that can be invoked twice a day for provisioning and termination of Elastic Beanstalk environment.

Configure the Elastic Beanstalk environment to use custom commands in the EC2 instance user data. Leverage the scheduled action for an Auto Scaling group to scale-out EC2 instances in the morning and scale-in the instance count to 0 to terminate the EC2 instances at the end of the day - Scheduled action allows you to set your own scaling schedule for an Auto Scaling group. For example, let's say that every week the traffic to your web application starts to increase on Wednesday, remains high on Thursday, and starts to decrease on Friday. You can plan your scaling actions based on the predictable traffic patterns of your web application. Scaling actions are performed automatically as a function of time and date. A scheduled action sets the minimum, maximum, and desired sizes to what is specified by the scheduled action at the time specified by the scheduled action.

The issue with this option is that it's costly. Firstly, there is a cost element of running the EC2 instances for the day hours. Secondly, Elastic Beanstalk environment is provisioned via custom commands in the EC2 instance user data (it should also be emphasized that EC2 instance user data is not the best place to trigger the creation of an Elastic Beanstalk environment) however the environment itself is not terminated at the end of the day. So the costs for the resources created by Elastic Beanstalk keep accumulating. Hence this option is incorrect.

Provision an EC2 Micro instance. Configure an IAM role with the required Elastic Beanstalk environment permissions and attach it to the instance profile. Create scripts on the instance to provision and terminate the Elastic Beanstalk environment. Set up cron jobs on the instance to execute the scripts - This option involves cost components that are not needed. There is no need to provision an EC2 Micro instance and keep it running just to control the provisioning and termination of Elastic Beanstalk environment. This is better handled via a "serverless cron" type of solution that can be invoked twice a day for provisioning and termination of Elastic Beanstalk environment.

References:

https://aws.amazon.com/premiumsupport/knowledge-center/schedule-elastic-beanstalk-stop-restart/

https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html

https://aws.amazon.com/step-functions/