DEV Community: Natalia Marek

AWS Backup and Logically Air Gapped Vault

Natalia Marek — Fri, 19 Dec 2025 11:39:13 +0000

AWS Backup is a fully managed data protection service that enables you to automate and centralise backup of the data from multiple AWS services. AWS Backup supports cross-region and cross-account backups, incremental and continuous backups and lifecycle management for some supported resources.

AWS Backup can be turned on number of AWS Resources such as RDS, Dynamo DB table, S3 buckets, EBS, Redshift, CloudFormation - here is the list of supported services. The advantage of using AWS Backup beyond data protection include reduced operational overhead, centralised monitoring and simplified compliance monitoring.

Centralised, Cross-account Backup and Monitoring

You can set up AWS Backup in your workload account, however backing up data cross-account improves resilience and reduces blast radius if your account gets compromised.

In the presented pattern the resource being backed up resides in production workload account, the backup policy is created and managed in Organisation management account and the actual backup vaults and backup plan with the backed-up data would be created in a dedicated Backup account.

This way if any if the workload account gets compromised, the backup plan continues as usual and all the Backup recovery points would remain secure in Backup account. Additionally, you can implement IAM policies and SCP (Service Control Policies) to prevent unauthorised deletion of backups, even by administrators in the workload accounts.

Key benefits of cross-account backup:

Blast radius reduction - compromised workload account cannot affect backups
Separation of duties - different teams manage workloads vs backups
Centralised compliance - single pane of glass for audit
Cost optimisation - centralised lifecycle policies and storage tiers (where applicable) -> see backup feature availability

Vault Lock and Logically Air Gapped Vault

With the pattern above AWS Backup vault, policies and plan all stay within AWS Organisation and Backup account. In addition to storing backups in a separate account we can add another layer of protection, by creating logically air-gapped vault or enabling vault lock.

Vault lock

Vault Lock is a feature available on any vault as additional security. There is two modes to choose from:

Governance mode - allows users with specific IAM permissions to remove the vault lock and modify retention settings.
Compliance mode - provides immutable backups where the vault cannot be deleted if any recovery points exist, and the retention period cannot be shortened even by the root user. Once the grace period expires (which is usually 72 hours), the lock becomes permanent and cannot be removed

Using vault locks enforces the retention period set by Backup policy for the resource, protecting against ransomware, accidental deletion.

Logically Air Gapped (LAG)

LAG Vault offers additional layer of protection and security compared to a standard AWS Backup vault. With LAG vault:

AWS-managed encryption - the KMS key used to encrypt backups is owned and managed by AWS, preventing key deletion and modification
Compliance vault lock by default - automatically configured with compliance mode for immutable backups.
Isolated from source account - backups are logically isolated, meaning they cannot be accessed or deleted from the source account
RAM sharing for recovery- uses Resource Access Management (RAM) to share backups with specific accounts - this means that you can setup Backups to be shared for a quick recovery, reducing RTO.
Multi-party approval - optional integration requiring multiple authorises users (approval team, min 3 in a team)created in AWS Organisations to approve access to backups - which can also be obtain even in the event of Backup or management account being compromised .

Use case for LAG vault vs Standard vault:

Use LAG Vault when:

You need to meet strict compliance requirements
Protecting critical production data or financial/sensitive records
You need protection against sophisticated ransomware attacks
You require immutable backups with multi-party approval

Use standard Vault:

You are backing up dev or test workloads
You need flexibility to modify retention policies frequently
Cost optimisation is a priority as LAG vault has slightly higher cost
Your compliance requirements don't mandate immutability

Backup Audit Manager and Notification

Backup Audit Manager

Backup Audit Manager is a compliance tool that allows you to audit existing Backup against chosen controls and requirements:

Monitoring - You can view compliant and non-compliant resources and this way prioritise remediation
Auditing and Compliance - create customised frameworks that are aligned with your compliance requirements and monitor whether existing backup meets internal policies
Reporting -automatically or on demand generate a report delivered to S3 for audit trails.
Build-In controls - includes pre-configured controls for common requirements like backup frequency, retention periods, encryption and cross-region rpelication

Backup Notifications:

You can configure AWS Backup notifications via Amazon SNS for backup job events such as:

Backup job started, completed ot failed
Restore job started, completed or failed
Copy job completed (i.e. to another account)
Recovery point lifecycle transitions

Best Practices for AWS Backup:

Utilise tags - leverage AWS tags to include/exclude resources that need to be backed up.
Implement lifecycle policies - where possible (not all resources support cold storage) utilise cold storage to reduce cost.
Enable cross-account and cross region copy - to protect against regional failure, copy over at least periodically
Use Vault Lock - either in compliance or in governance mode
Monitor - set up notifications for failed Backups/Copy
Document recovery procedures - create and maintain runbooks for different disaster recovery scenarios.

Resources:

Building a Stronger Security Posture with AWS Security Hub

Natalia Marek — Sun, 12 Jan 2025 19:43:48 +0000

Security Hub is the first security service that we will explore. From a monitoring and compliance point of view, it is one of the most significant services that AWS has to offer. It offers continuous checks and monitoring of your infrastructure compliance aligned with the security standards that you choose or require. This means that to monitor your compliance, you do not need external monitoring. In addition to monitoring, you can also configure automatic remediation, which we will delve into later in this post.

Central Management and aggregation

Security Hub allows centralised management of security findings in multi-account organisations. You can now aggregate Security Hub findings into one central management account across multiple regions and organisational units (OUs).

This aggregation ensures that security teams can access all findings from a single place, simplifying operations and reducing the risk of oversight and limiting unauthorised access. It provides an overview of security risks across the organisation, enabling quicker response times and more efficient resource allocation.

This central management could be any delegated administrator of your choice. The primary recommendation is that the admin account should be the same for all security tools, and it should not be the Organisation management account (although this is possible). In our case, we have designated the SecurityOps account as the delegated administrator.

Security Standards

Security standards are predefined frameworks that outline best practices and compliance guidelines to protect your infrastructure and data. By adhering to these standards, organisations can systematically address security risks and meet regulatory or industry-specific requirements.

Security standards that are currently available in Security Hub:

AWS Foundational Security Best Practices v1.0.0: Covers basic security controls for IAM, logging, and encryption.
CIS AWS Foundations Benchmark (Center for Internet Security): Offers prescriptive controls for organisations seeking external validation, often used for audits.
NIST SP 800-53 Rev. 5 (National Institute of Standards and Technology): Designed for projects requiring adherence to U.S. government security standards.
PCI DSS (Payment Card Industry Data Security Standard): Ensures secure handling of payment card transactions, which could be critical for e-commerce platforms.
AWS Resource Tagging Standard: Promotes consistent tagging to improve resource management and cost visibility.

These standards simplify compliance by offering clear guidelines tailored to various industries and use cases. For example, an online retailer might use PCI DSS to ensure secure payment processing, while a government contractor could apply NIST SP 800-53 to meet federal compliance requirements. Security Hub evolves continuously; just in December 2024 Security Hub added 84 new controls.

Next we will talk about how can we implement those standards across our AWS organisation.

Custom policies

You can create customised configuration policies for your central configuration. The recommended policy when first setting up Security Hub is enabling AWS Foundational Security Best Practices v1.0.0, with all controls across all accounts and any new AWS account automatically enrolled.

However you can change this and create a customised configuration policy for your organisation, and apply different policies across different accounts and/or Organisational Units in AWS Organisation. There might be different reasons for utilising Custom Policies on different accounts, here are some examples:

Different compliance requirements: For example, enabling PCI DSS only for accounts that process payments, while applying less stringent standards to development and sandbox accounts.
Custom control parameters: Adjusting specific checks, such as flagging only public S3 buckets storing sensitive data, instead of all public buckets.

You can enable this in the Configuration settings, under the Policies section.

When creating a new policy, you first select which standards should be used—in this example, we have chosen three, including PCI DSS.

Next, you can enable all controls, disable or enable specific controls. Here we have chosen to disable two controls. In addition, you can customise how specific parameters are evaluated.

Customisation reduces noise from unnecessary alerts and focuses compliance efforts on high-priority risks, so that findings and insights are tailored and custom for our use case, without having to enable standards that are unnecessary in the whole Organisation, which will also save on the cost.

Automated Response and Remediation

Security Hub supports automation through:

Automated Rules
Automated Response and Remediation:

With Automation Rules, you can automatically update and/or suppress findings based on criteria. This is useful for updating severity levels or suppressing findings that match defined criteria. You can set up an automation rule from a template or create a custom rule.

Let’s have a closer look at one of the templates — this one relates to elevating findings in specific production accounts. This is just a template, so we can update any values to match our requirements.

In the Criteria section, you can choose which findings the rule should apply to. One of those keys is the account ID — in this case, we would like it to apply only to the production account.

Next, we choose what automated action will take place against the findings that match our criteria. Here, the severity will be updated to "Critical" and a note will be added stating:
"A resource in production accounts is at risk. Please review ASAP."

Any of these actions can be modified. For instance, for sandbox accounts, we can update the severity to a lower level. You can also add a user defined field—here, we could add a key of Environment with a value of Production or Sandbox. This means that any findings originating from the production account will contain that extra field with environment information.

Automated Response and Remediation involves triggering remediation actions through integrations such as AWS Lambda, EC2 run command, Step Functions, pushing messages to an SNS topic, or sending findings to third-party tools or chats. These actions are automatically sent to EventBridge in near real-time.

For example, when a control detects a publicly accessible S3 bucket, a Lambda function can automatically restrict access. Another example is isolating compromised EC2 instances automatically.

AWS offers a set of templates for cross-account automated responses and remediation that can be deployed using CloudFormation. You can explore this solution here: Automated Security Response on AWS.

Security Hub Dashboards, Insights and Integrations

Dashboard

Security Hub dashboard provides a customisable summary of your security posture, highlighting key metrics such as open findings by severity, compliance scores or resource distribution across regions and accounts. This helps security teams quickly identify trends, track remediation progress, and focus on critical issues. Over time, the dashboard reveals whether compliance and security efforts are improving or require additional attention.

Insights

Security Hub also offers insights— predefined or customisable views/filters that help organisations focus on specific security findings. For instance, you can filter findings based on severity, AWS resources with the most findings, account type, S3 buckets with public write or read permissions etc.

You can also create your own insight/filter to quickly access finding that are a priority for your Organisation.

Integrations

Security Hub integrates with other security AWS services like GuardDuty, Macie, Inspector or IAM Access Analyser, feeding findings directly into the dashboard. You can also integrate third-party services such as Splunk, PagerDuty, SumoLogic and Palo Alto Networks. For better visibility, you can add widgets like Latest Findings from AWS Integrations to the dashboard, centralising all critical information in one place.

Additionally, Security Hub supports custom integrations, allowing you to integrate other custom security products, not listed about. By using the Security Hub custom providers API, you can send findings from other security tools or workflows into Security Hub. This enables a unified and comprehensive view of security across both AWS-native and custom solutions, tailored to your requirements.

Conclusion

Security Hub has come a long way since it was first released, evolving into a powerful tool for managing and automating security in AWS environments. With regular updates like the addition of new controls and enhanced integrations, it’s clear that Security Hub is only getting better. Its ability to centralise findings, customise compliance, and automate responses keeps improving, making it an important consideration for securing you AWS Infrastructure.

Useful resources and training about Security Hub:

Essential AWS Security Services to Safeguard Your AWS Cloud Workloads

Natalia Marek — Thu, 07 Nov 2024 11:05:03 +0000

With how fast things are changing in the digital world, securing your cloud setup is more important than ever. In my upcoming blog posts, I'll be focusing on security, exploring the AWS services you need to effectively protect your cloud environment.

I'm aiming to give an overview of each service—talking about why we should consider using them in AWS Organizations, especially with multi-account architectures in mind. We'll delve into the latest features, implementation strategies, and best practices.

AWS Security Hub

AWS Security Hub is a cloud security posture management service that provides a comprehensive view of your security state within AWS. It aggregates security data from across your AWS accounts and services like Amazon GuardDuty, Amazon Inspector, and Amazon Macie, as well as supported third-party products (e.g., Sumo Logic, Snyk). By consolidating this information into a single dashboard, Security Hub enables you to analyse security trends and prioritise high-priority issues effectively.

The service supports multiple security standards and best practices frameworks, including AWS Foundational Security Best Practices, CIS, PCI DSS, Resource Tagging Standard and NIST. It continuously runs automated security checks against these standards, generating findings to help you assess compliance and calculate security scores.

Features worth mentioning:

Automated Response and Remediation: Security Hub can automate responses to findings by integrating with AWS Systems Manager and AWS Lambda, allowing for quicker mitigation.
Custom Insights and Dashboards: You can create custom insights to focus on specific types of findings and tailor dashboards to meet your organisation's needs.
Integration with AWS Organizations: Security Hub can be set up across multiple AWS accounts using AWS Organizations, simplifying centralised security management.

Amazon Inspector

Amazon Inspector is an automated security assessment service that identifies vulnerabilities and unintended network exposure in EC2 instances, Lambda functions, and container images in Amazon Elastic Container Registry (Amazon ECR). It can also be integrated into your CI/CD pipelines.

Similar to Security Hub, it provides a central place to monitor vulnerabilities for all the services mentioned above.

Features worth mentioning:

Continuous Scanning: Amazon Inspector offers continuous scanning of your workloads, providing near real-time insights into vulnerabilities.
Integration with AWS Security Hub: Findings from Amazon Inspector can be automatically forwarded to AWS Security Hub for centralised management.
Enhanced Scanning for Container Images: It supports enhanced scanning of container images, to identify vulnerabilities before deployment.
Support for AWS Lambda Layers: Inspector can assess vulnerabilities in Lambda layers

AWS Identity and Access Management (IAM) and IAM Identity Center (SSO)

AWS Identity and Access Management (IAM) is probably one of the most well-known AWS services, but we'll look at it from the perspective of securing organisational environments further anmd ensuring best practices are in place. IAM enables you to securely manage access to AWS resources by defining who can access what. IAM Identity Center (formerly AWS Single Sign-On) simplifies access management across multiple AWS accounts and applications, allowing centralised user and group permissions.

In our overview, we'll look at how to implement best practices for access management, utilising IAM Access Analyzer, Attribute-Based Access Control and how to use and implement permission boundaries.

Features worth mentioning:

IAM Access Analyzer: Helps identify resources in your organisation and accounts that are shared with an external entity.
Permission Boundaries: Allow you to set the maximum permissions that an IAM entity (user or role) can have, providing an extra layer of security.
Attribute-Based Access Control (ABAC): IAM now supports ABAC, which allows permissions based on tags attached to users and resources, simplifying permission management in large environments.

Amazon GuardDuty

Amazon GuardDuty is a near real-time threat detection service that monitors malicious activity and unauthorised behaviour by analysing AWS CloudTrail logs, DNS logs, and VPC Flow Logs as foundational data sources. It provides insights into potential threats affecting AWS resources. Similar to Security Hub, it allows us to aggregate findings from all accounts.

In addition to the foundational data source analysis mentioned above, GuardDuty now offers malware protection specifically for Amazon EKS, Amazon S3, EC2, RDS, and Lambda functions.

Features worth mentioning:

S3 Protection: GuardDuty can monitor and analyse data events from Amazon S3 to detect suspicious activities like unauthorised data access.
EKS Runtime Monitoring: It provides security monitoring for Amazon EKS clusters, detecting threats at the container and Kubernetes levels.
Integration with AWS Organisations: Enables centralised threat detection across multiple AWS accounts.

AWS Shield and AWS WAF (Web Application Firewall)

AWS Shield and AWS WAF (Web Application Firewall) work in tandem to protect web applications from a wide range of threats. AWS Shield provides managed protection against Distributed Denial of Service (DDoS) attacks, with Shield Standard offering basic DDoS protection at no additional cost and Shield Advanced delivering enhanced safeguards for applications running on EC2 instances, Elastic Load Balancers, Amazon Route 53, AWS Global Accelerator, and more.

In addition, AWS WAF protects your applications from common web exploits that can affect availability, compromise security, or consume excessive resources. It allows you to create custom rules to block common attack patterns such as SQL injection or cross-site scripting (XSS). Together, AWS Shield and AWS WAF can be deployed on services like Amazon CloudFront, Application Load Balancer, Amazon API Gateway, and AWS AppSync, providing a layered defence that secures your applications from both network-level DDoS attacks and application-level vulnerabilities.

We have highlighted some essential services that enhance security within your AWS Organization, it's important to remember that safeguarding your AWS accounts is an ongoing process. Exploring additional features like applying Service Control Policies, ensuring data encryption is in place, and utilising AWS Secrets Manager for managing secrets can further strengthen your security posture. We will also be looking into these. By making the most of AWS's security tools and best practices, you can build a strong and secure cloud environment that's just right for your organisation's needs.

Let's talk about AWS VPC endpoints

Natalia Marek — Wed, 10 Jan 2024 09:53:55 +0000

VPC endpoints enable us to establish private connections between your VPC and supported AWS services, bypassing the need for public internet access, making your infrastructure more secure and improving data protection. In this blog post, we will look into AWS VPC endpoints, specifically focusing on differences between Gateway and Interface endpoints, and explore why it is important to consider them in the context of AWS infrastructure.

Gateway Endpoints

First lets talk about Gateway Endpoints, which are available to connect to S3 and DynamoDB. We would use them if we require connectivity from within AWS network, without having to create internet gateway or NAT device or VPN. Unlike Interface Endpoints, they do not use AWS PrivateLink, are fee of charge and are available only in the Region where you created it.

In a Gateway Endpoint, traffic is routed from your VPC, via the Gateway Endpoint, to S3 or DynamoDB. It serves as a target for a route in your route table for traffic destined for one of these services.

When creating a Gateway Endpoint first you will have to select route table in which to create routes to the service and add resource policy - you can select full access to allow all operations by principals or create a custom policy to enable more granular access, for instance restricting which S3 buckets can be accessed via the gateway endpoint.

Note that Gateway Interfaces do not allow access from on-premises networks, peered VPCs in other AWS Regions, or through a transit gateway - in those instances you will have to use Interface Endpoints.

Interface Endpoints

Interface Endpoints, utilise AWS PrivateLink, that securely connects your VPC to supported AWS services, such as EC2 API, ECS, Secret Manager, Lambda, but also services hosted by other AWS customers, AWS Partner Network (APN) partners in their own VPCs, or allows access from on premises. This is done by creating elastic network interfaces (ENIs) within your VPC that serve as the entry point for traffic destined to these AWS services.

The key difference between Interface and Gateway Endpoints lies in their underlying architecture, cost and usage. While Gateway Endpoints are limited to S3 and DynamoDB and are free of charge, Interface Endpoints support a broader range of services but incur a cost based on the amount of data processed.

When we create an Interface Endpoint, it gets associated with a specific subnet in our VPC and creates an ENI. This ENI is assigned a private IP address from the subnet's IP range. Your VPC traffic to the AWS service then goes through this private IP address, ensuring that the data never goes over the public internet. This setup enhances security and could potentially reduce data transfer costs.

Use Cases of Interface Endpoints for AWS Services

Interface Endpoints are particularly beneficial for secure and private access to AWS services not supported by Gateway Endpoints. For services like Kinesis or Lambda, and when latency and secure data transfer are crucial, Interface Endpoints can provide a consistent, low-latency connection, vital for real-time data processing and serverless computing scenarios.

Next, using AWS Secrets Manager integrated with Interface Endpoints allows you to access Secrets Manager within your VPC without exposing the traffic to the public internet. This would be crucial for applications that need to securely access sensitive information, like database credentials or API keys.

Last example use-case I want to discuss is ECS, which can also be used with Interface Endpoints for secure, private communication with other AWS services. For example, an ECS cluster in a VPC can privately pull images from Amazon Elastic Container Registry (ECR) or securely store logs in CloudWatch, essential for compliance-sensitive applications.

These are just a few examples of the services accessible via Interface Endpoints. You can find the full list of supported services here.

S3: Gateway vs. Interface Endpoints

It's worth noting that S3 supports both Gateway and Interface endpoints. When deciding between them for Amazon S3, consider the following:

Cost: Gateway Endpoints are free, while Interface Endpoints incur charges per hour and per GB of data transferred. Here you can find pricing information.
Access Pattern: Gateway Endpoints are suitable for accessing S3 within the same VPC. Interface Endpoints can be used for accessing S3 from outside the VPC, including from on-premises or from different regions (Gateway Endpoints are limited to the same region).
Bandwidth and Architecture: Interface Endpoints offer high throughput and are beneficial in centralised VPC endpoint architectures, especially when accessing S3 from multiple VPCs. Gateway Endpoints have no inherent throughput limit and are simpler to manage for in-VPC use.
DNS Configuration: Interface Endpoints offer options for DNS configurations, allowing for more flexible connectivity setups, particularly for on-premises and cross-region access patterns.

Gateway Endpoints are ideal for simple, in-VPC access to S3 at no cost, while Interface Endpoints offer more flexibility and higher throughput for more complex architectures and external VPC access.

Here you can read more about types of vpc endpoints for s3.

Conclusion

In this blog post, we have looked into of both Gateway and Interface endpoints. Rather than separating the benefits of each endpoint type, let's look at the advantages of using VPC endpoints as a whole

Enhanced Security: VPC endpoints enable direct, private connectivity to AWS services, such as S3, DynamoDB, Secrets Manger, EC2 and others, reducing the need to expose traffic to the public internet and keeping you data protected.
Cost-effectiveness: This is especially the case(but not only!) with Gateway Endpoints, you can avoid internet egress charges, especially with high-volume data transfers. While Interface Endpoints do incur charges, they can offset these costs by reducing data transfer fees over the public internet.
Improved Performance and Reliability: VPC endpoints often provide lower latency and higher throughput, ensuring faster and more efficient data transfers. This increase in performance is crucial for applications requiring real-time data processing.
Wide Range of supported services: Interface Endpoints support a large number of AWS services, which enables secure connection with various AWS services, facilitating diverse and complex cloud architectures.
Compliance and Security Standards: For organisations with compliance and security requirements, VPC endpoints provide a secure communication channel, meeting various regulatory standards by keeping data within the AWS network.
Flexible Connectivity Options: The ability to customise DNS configurations with Interface Endpoints, as well as the simplicity of Gateway Endpoints, offers diverse connectivity options. This is beneficial for simpler in-VPC scenarios and more complex setups involving cross-region or on-premises access.
Simplified Network Management: VPC endpoints simplify the network architecture by reducing the need for Internet Gateways, NAT devices, or VPN connections, making network management more straightforward and less prone to security risks.

Using VPC endpoints can significantly enhance the security, performance, and efficiency of your cloud infrastructure. It can provide a robust solution for securely accessing AWS services, catering to various architectural needs and use cases.

References/further reading:

Fargate cost optimisation - using Fargate Spot with Terraform

Natalia Marek — Thu, 31 Aug 2023 15:44:02 +0000

AWS Fargate is pay as you go serveless compute for containers. You can use Fargate if you have small, batch, or burst workloads or if you want zero maintenance overhead of your containers, as this is all taken care of by AWS. In this post I will be talking about how to cost optimise your Fargate workloads and utilise Fargate Spot using Terraform.

Fargate Cost Optimisation

Lets start with general overview on how we can make sure that we do not overspend on our Fargate instances.

Right-sizing tasks. Rightsizing is probably one of the first and most important tasks to ensure that you are not over provisioning your tasks, which can lead to unnecessary spending. You can specify value for CPU and Memory in your task definition - however make sure to specify a valid value for both of them.
Utilise auto scaling. Auto-scaling can help you ensure that you are only running the necessary number of tasks, which can help to reduce costs. There are two types of scaling policies Target Tracking and Step Scaling and can be scaled based on Memory and CPU utilisation. Here is more information about ECS autoscaling.
Utilise AWS Savings Plans. To reduce Fargate cost you can use Compute Savings Plans. By purchasing Savings Plan you commit to using a certain amount of compute resources over a period of time. With Compute Savings you commit to 1 or 3 year plans, and you can save up to 66% on your EC2, Fargate, and Lambda costs.
Fargate Spot. You can use spot instances with Fargate to further reduce your costs, which could mean up to 70% discount compared to Fargate On-Demand pricing, and there is no up-front commitment which is an advantage for more unpredictable or new workloads over Compute Savings Plan, however you can also utilise both at the same time to maximise your savings. It is important to note that spot instances can be terminated at any time, so you need to make sure that your application can handle this.

Additionally you can use cost allocation tags to track your AWS costs. You can use tags to group your costs together so that you can see how much you are spending on different parts of your application.

Implementing Fargate Spot with Terraform

As mentioned before when using Fargate Spot you have to be prepared that Spot instances can be terminated at any time, which makes it a good candidate for dev and test environments. However if you configure it correctly you can also utilise it on production, by setting base and weight on your capacity provider strategy to ensure availability of your application.

When creating a Fargate cluster via AWS Console it will have both Fargate and Fargate Spot capacity providers by default. However when creating it via Terrafrom you need to make sure to list them both in "capacity-providers" attribute. Here is example of that:

resource "aws_ecs_cluster" "ecs" {
  name = "my_ecs_cluster"

}

resource "aws_ecs_cluster_capacity_providers" "ecs" {
  cluster_name = aws_ecs_cluster.ecs.name

  capacity_providers = ["FARGATE_SPOT", "FARGATE"]

  default_capacity_provider_strategy {
    base              = 1
    weight            = 100
    capacity_provider = "FARGATE"
  }
}

Here we are creating ECS cluster, setting capacity providers to be Fargate spot and Fargate and setting the default capacity provider strategy to be just Fargate, which we will can later set for each service by defining capacity_provider_strategy on "aws_ecs_service" resource.

Next we will create a service for our ECS cluster with both FARGATE_SPOT and FARGATE set as capacity providers.

resource "aws_ecs_service" "main_service" {
  name    = "my_service"
  cluster = aws_ecs_cluster.ecs.id

  capacity_provider_strategy {
    capacity_provider = "FARGATE"
    weight            = 4
    base              = 3
  }
  capacity_provider_strategy {
    capacity_provider = "FARGATE_SPOT"
    weight            = 2
  }
}

We are setting both base and weight of each capacity provider here. Weight of 4 for FARGATE means that for every 6 tasks, 4 will be running on FARGATE and 2 will be running on FARGATE_SPOT. For dev and test environments we can increase the weight of FARGATE_SPOT utilisation or remove FARGATE all together. BASE set to 3 on FARGATE capacity provider means that we will always have 3 tasks running on FARGATE - this is the configuration that would be important when considering using FARGATE_SPOT on production environments.

Last but not least when using CodeDeploy with Blue/Green deployments for existing ECS service make sure to add CapacityProviderStrategy in the resource section to the appspec.yml file. You can find more information about it over here .

Here is an example of appspec.yml file

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: <TASK_DEFINITION>
        LoadBalancerInfo:
          ContainerName: my_container
          ContainerPort: 80
        CapacityProviderStrategy:
          - Base: 0
            CapacityProvider: FARGATE_SPOT
            Weight: 2
          - Base: 1
            CapacityProvider: FARGATE
            Weight: 4
            Base: 3

Aurora Serverless v1 to Serverless v2 - comparison, migration and blue/green deployment

Natalia Marek — Fri, 27 Jan 2023 16:19:46 +0000

In this blog we will go through main differences between Aurora Serverless v1 and v2, how to upgrade your Aurora Serverless v1 cluster to v2 and how utilising blue/green deployment could help mitigate risk and downtime during future upgrades.

Aurora serverless v1 vs v2

Aurora Serverless v2 has become generally available in April 2022, with a promise of "90% cost savings compared to provisioning for peak capacity". Let's have a look at the main differences here:

Aurora Serverless v1	Aurora Serverless v2
- scales only by increasing or decreasing the capacity of the writer	can scale both by changing the size of the DB instance and by adding more DB instances to the cluster, or by adding more regions to Aurora Global database
- all the compute for the cluster runs un a single AZ and region	- Multi AZ the same as in Aurora provisioned
- scaling cannot happen when SQL statements are running	-scaling can happen at any time (no requirement for quiet time
- scales up and down by doubling and halving ACU's	- Scale up and down with minimum increment of 0.5 ACUs
- reader DB instances aren't available, therefore cannot scale.	-reader DB can scales up and down independently of the writer
- best effort failover only, subject to capacity availability	-failover the same as is provisioned Aurora
-	- multi AZ -scaling based on memory -Aurora global databases - exporting snapshots to s3 - associating IAM role -RDS proxy - performance insights

To summarise, upgrading to Aurora Serverless v2 would offer you more granularity with having the ability to scale down to 0.5 in comparison to 1 or 2 with v1. It also offers the same failover as provisioned clusters with multi AZ capability and and option to create Aurora Global database, all of which was not possible with Aurora Serverless V1. Another advantage of the newer version is ability to use RDS proxy.

These are just selected differences, however you can find the full list in AWS documentation.

Upgrading Aurora Serverless v1 to v2

For this demo purposes I will be using Aurora Serverless 2.07.01 MySQL 5.7–compatible and I will provide an approximate time each step should take.

Create a DB cluster snapshot of the Aurora Serverless v1 cluster (around 2-4 mins)

Restore the snapshot to create a new, provisioned (not Aurora Serverless) DB cluster running Aurora MySQL version 2. Choose the latest minor engine version available for the new cluster, which at the time of writing this is 2.11.0 (around 10 minutes)

It should take around 10-15 minutes for the new provisioned cluster to become available.

When Cluster becomes available upgrade the provisioned Aurora MySQL version 2 cluster to a Aurora MySQL version 3 that s compatible with Aurora Serverless v2, i.e. 3.02.2. Here you can check Aurora Serverless v2 compatible versions.

(18-20 mins)

4.Modify the writer DB instance of the provisioned DB cluster to use the Serverless v2 DB instance class. (approx 20 mins).

Total approximate time for the upgrade from taking a snapshot to converting and modyfying DB instance to Serverless v2 should take around 60-70 mins.

Further documentation
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.upgrade.html#aurora-serverless-v2.upgrade-from-serverless-v1-procedure

Blue/Green deployment to minimize risk and downtime

Utilising Blue/Green deployments for you managed databeses means that a staging copy of your production enviroment will be created, that later on can be promoted to production. Staging environment stays in sync with your production database. All of this makes it possible for you to significantly decrease downtime when upgrading your database engine, changing schema or parameters. When you have thoroughly tested and undertaken any changes you wanted to your staging(green) copy, you can do a switchover and promote it to be a production(blue)environment, which usually takes less than a minute.

To create a Blue/Green deployment of your database cluster first you need to make sure that your database cluster is associated with a custom paramater group with binary logging turned on (binlog_format).

After associating your DB with a custom parameter group, you can now create Blue/Green deployment and perform any neccessary upgrades on your new Green(staging) environment

Blue/Green deployments aren't supported for Aurora Serverless v1, however it is available for Aurora provisioned a with MySQL Compatibility 5.6 or higher, Amazon RDS for MariaDB 10.2 and higher and Serverless v2. More information about this here

How to migrate to Terraform Cloud and why should you do it?

Natalia Marek — Fri, 23 Dec 2022 11:36:12 +0000

Terraform cloud is a cloud infrastructure management tool that allows users to easily create and remotely manage their cloud infrastructure in a consistent and efficient manner. You can use it to manage cloud infrastructure, including Amazon Web Services, Google Cloud Platform, and Microsoft Azure.

Why Terraform Cloud?

If you are already running your infrastructure on Terraform, here are some reasons on why you should consider migrating to Terraform Cloud:

store your state remotely and provide easy access to shared state, secret data and access controls - you can add users and assign different permissions to them, i.e. owners or developers
manage infrastructure at scale. This means that users can easily manage large numbers of resources across multiple cloud providers and environments.
use workspaces to manage your collections of infrastructure, which allows to manage multiple resources as well as grant individual users and user groups permissions for each workspace. Read more about how you can take advantage of workspaces features (over here)[https://developer.hashicorp.com/terraform/cloud-docs/workspaces]
store sensitive variables securely - you can store them in variable sets and apply them to the
do it your way - manage Terraform runs through 3 different workflows:
- UI/VCS driven workflow - here you are connecting you VCS to Terraform Cloud - easily integrate version control such as GitHub, GitLab, BitBucket or Azure Devops and automatically initiate Terraform runs when changes are committed to the specified branch with out the box triggers.
- CLI driven workflow - you can use your standard Terraform CLI to trigger remote runs.
- API driven workflow - where you can manage and trigger runs through other tools by triggering calls to Terraform Cloud.

More about VCS workflows

Version Control Workflow in Terraform cloud is something worth spending a bit more time on when configuring your workspace. Here is a few things that I find useful about VCS config in Terraform Cloud:

initiating speculative plans every time a PR is created against the default branch (this is set up by default so you don't have to do anything)
once PR is merged this will trigger plan and apply, however by default apply will require manual approval.
you have various triggers to choose from, and this is where you can really customise your deployment triggers:
- *path changes triggers *(especially useful for monorepos)
  - pattern based triggers (recommended)- use glob patters to select which what changes should trigger runs and ignore others (i.e. /submodule/**/*.tf if you only require a run when .tf in submodule files were changed or /**/networking/**/* any changes in the files that have networking in their path will trigger a run.
  - prefix based triggers - where you select which directory path should be tracked and trigger a run. One of the examples here would be to track changes in modules directory in each workspace.
- git tag based triggers - run will only be triggered when indicated git tag is published.
- you also have an option to always trigger runs, whenever changes are made to any file in the repository.

When setting up your Terraform Cloud organisation and workspaces it is good to assess and implement triggers that are right for your use case and take advantage of all the features offered by Terraform Cloud.

Migrate your existing Terraform infrastructure to Terraform Cloud

First lets start with prerequisites:

Make sure you have [Terraform CLI 1.1](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) or higher installed
*Set up Terraform Cloud account *

Migrating existing state to Terraform Cloud:

Replace your backend config with:

cloud {
    organization = "ORGANIZATION-NAME"
    workspaces {
      name = "staging"
    }
  }

and remove your backend config:

backend "s3" {
}

Run terraform init
Log in to terraform cloud in the CLI by running:
terraform login

You will be taken to Terraform Cloud website where you will create API token, that you need to copy and paste in you command line

(optional) Set up version control - you can set this either for workspace or or for the whole organisation
Set up correct working directory i.e. terraform/infrastructure
After verifying that Terraform migrated your state to Terraform Cloud, remove your local state file.
(optional) Create variable sets with variables that are shared across organisation (note that these can still be overwritten in workspace if necessary)
(optional) Migrate workspace .tfvars variables and assign them values in Terraform Cloud.

What about the cost?

Often there is a misconception that in order to migrate and use Terraform Cloud you have to pay a lot, in fact the opposite is true - if you are working in a small team, and do not need access to advance features such as team management and Policy as code (Sentinel policy as code)you can utilise free plan, which allows up to 5 users - this will allow your organisation to assess whether it's a right tool without incurring any cost.

Monitor and protect sensitive log data with CloudWatch and Terraform

Natalia Marek — Fri, 02 Dec 2022 11:12:00 +0000

New feature for CloudWatch Logs has been announced on the first day of this years AWS Re:Invent - you can now set up a policy for each CloudWatch logs group, which will allow you to mask and audit sensitive log data.

In this post I will write about the details of this functionality and walkthrough how to implement it in the AWS Console and using Terraform.

How does it work?

This new CloudWatch feature will allow you to:

mask any information that you deem sensitive
audit it by setting a destination for it - this could be S3 bucket, Kinesis Data Firehose or/and CloudWatch Logs.

After Data Protection policy is attached to a log group any logs added to that log group will be masked, and only users with logs:Unmask permissions will be able to view them.

Making sure that any sensitive data is protected is

Important to note that any sensitive information in the log groups created prior to setting up sensitive data policy will not be detected.

What types of data you can identify?

AWS gives yo ua choice of 100 data types to choose from, such as

Credentials, such as AWS Access Keys or Private keys
Personally Identifiable information, such as national identification numbers, Social Security Number , drivers license numbers, passport number, addresses, Electoral roll number taxpayers number etc
Protected Health Information (PHI) such as health insurance numbers, NHS numbers, health insurance information
Financial information - bank account numbers, credit card numbers and security codes
Device Identifiers such as IP adress

You can find the whole list of the types along with their ARN identifiers here.

How to create sensitive data policy in the AWS Console

In your AWS console, go to CloudWatch, select Log groups, choose log group you would like to create the policy for, and next select Data protection section, and click on Create policy.

Now you will be able to select Data identifiers you want to mask and audit - for the purpose of this tutorial, we will choose three: Address, BankAccountNumber-GB and BankAccountNumber-US. Next we can select audit destination, here we have selected an existing sensitive-data-audit-example-bucket, however this is optional,

You also have ability to view how your policy looks like in JSON format. This is the example policy that we have just created:



{
  "Name": "data-protection-policy",
  "Description": "",
  "Version": "2021-06-01",
  "Statement": [
    {
      "Sid": "audit-policy",
      "DataIdentifier": [
        "arn:aws:dataprotection::aws:data-identifier/Address",
        "arn:aws:dataprotection::aws:data-identifier/BankAccountNumber-GB",
        "arn:aws:dataprotection::aws:data-identifier/BankAccountNumber-US"
      ],
      "Operation": {
        "Audit": {
          "FindingsDestination": {
            "S3": {
              "Bucket": "sensitive-data-audit-example-bucket"
            }
          }
        }
      }
    },
    {
      "Sid": "redact-policy",
      "DataIdentifier": [
        "arn:aws:dataprotection::aws:data-identifier/Address",
        "arn:aws:dataprotection::aws:data-identifier/BankAccountNumber-GB",
        "arn:aws:dataprotection::aws:data-identifier/BankAccountNumber-US"
      ],
      "Operation": {
        "Deidentify": {
          "MaskConfig": {}
        }
      }
    }
  ]
}

Next click on Activate data protection, and your newly created policy will mask and audit any logs added to the log group after the policy was created.

Create data protection policy for CloudWatch with Terraform

Below you can see example of how to add a Data Protection policy resource in Terraform.

Here we will be setting up similar policy to the one created before - adding Data policy to an existing log_group_example policywith s3 bucket as audit destination, Address and BankAccount data identifiers.




resource "aws_cloudwatch_log_group" "log_group_example" {
  name = "log_group_example"
}

resource "aws_s3_bucket" "sensitive_data_audit-example_bucket" {
  bucket = "sensitive-data-audit-example-bucket"
}

resource "aws_cloudwatch_log_data_protection_policy" "log_group_example" {
  log_group_name = aws_cloudwatch_log_group.log_group_example.name

  policy_document = jsonencode({
    Name    = "data_protection_policy"
    Version = "2021-06-01"

    Statement = [
      {
        Sid = "Audit"
        DataIdentifier = ["arn:aws:dataprotection::aws:data-identifier/Address",
          "arn:aws:dataprotection::aws:data-identifier/BankAccountNumber-US",
        "arn:aws:dataprotection::aws:data-identifier/BankAccountNumber-GB"]
        Operation = {
          Audit = {
            FindingsDestination = {
              S3 = {
                Bucket = aws_s3_bucket.sensitive_data_audit-example_bucket.bucket
              }
            }
          }
        }
      },
      {
        Sid = "Redact"
        DataIdentifier = ["arn:aws:dataprotection::aws:data-identifier/Address",
          "arn:aws:dataprotection::aws:data-identifier/BankAccountNumber-US",
        "arn:aws:dataprotection::aws:data-identifier/BankAccountNumber-GB"]
        Operation = {
          Deidentify = {
            MaskConfig = {}
          }
        }
      }
    ]
  })
}

You can read more about CloudWatch Data Protection policy in the Amazon

How to set up Session Manager and enable SSH over SSM

Natalia Marek — Tue, 11 Jan 2022 18:12:58 +0000

This is a quick guide on how to set up sessions manager on your EC2 instance and enable SSH connections through SSM.

Setting up sessions manager on EC2 instance

1. Create IAM instance profile to allow Sessions Manager to connect to your instance (this is not enabled by default)

You can do that either by creating a new IAM role with Session Manager permissions or by adding inline policy permissions to an existing role already attached to our instance.

To create/add instance profile:

Go to IAM and click on Create role
Select EC2 as trusted entity.
Add AmazonSSMManagedInstanceCore policy to your role or AmazonSSMFullAccess if you require to grant all Systems Manager permissions and click next.
Add tags and then click Create role.
To add SSM permissions to an existing role, find the role that is attached to the instance, and then add SSM permissions as an inline policy.

2. Next add newly created role as your instance profile:

Go to EC2 instances, select the instance you would like to enable SSM on.
Click on Actions, select Security, and then Modify IAM role
Next select IAM role we have created in the previous step

3. You can now connect to your instance through Session Manager.

Your can find out more information about EC2 instance profiles and IAM roles for SSM over here.

Enabling SSH over SSM from your local machine

First of all we need to make sure we meet all the prerequisites:

Have installed latestaws-cliinstalled.
Install Session Manager pluginon the machine you want to connect to your instance from.
Make sure your instance has latest SSM agent installed
Update local .ssh configuration on your machine.

Windows (usually located at: C:\Users\username\.ssh\config):



# SSH over Session Manager
host i-* mi-*
    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

Mac (usually located at: ~/.ssh/config):



# SSH over Session Manager
host i-* mi-*
    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

Add permissions to role/user that you are using to connect to the console.

You can use policy below to allow SSH connections through Sessions Manager.



{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ssm:StartSession",
            "Resource": [
                "arn:aws:ec2:region:987654321098:instance/i-02573cafcfEXAMPLE",
                "arn:aws:ssm:*:*:document/AWS-StartSSHSession"
            ]
        }
    ]
}

Now, after assuming your chosen role/connecting through command line to AWS, you can connect to your instance through SSH over SSM by running this command:

aws ssm start-session --target i-02573cafcfEXAMPLE --region your-chosen-region.

You can remove any port 22 access in your node's security groups - this will no longer be needed to connect to your instance.

Any further reading about this, make sure to check AWS documentation about this.

Note that you can make sure that your instance has the latest SSM agent installed, by Automating Updates to SSM Agent.

Get ready for AWS Developer Associate exam

Natalia Marek — Thu, 18 Nov 2021 16:51:39 +0000

I have decided to write a guide on what resources I have used when preparing for the AWS exam, because I have gone through a variety of them before finding the right ones. Additionally, as AWS Developer Associate was my first AWS exam to take, I will write this post from that perspective. Last but certainly not least, I would also like to make this guide as accessible from economic perspective as possible, so majority of resources mentioned here are completely free to use.

How long should I prepare?

The answer to that is - of course - it depends! I have started using AWS in September and sat down to take the exam in July, which makes it around 10 months, but this can easily be done in around 2-3 months - it all depends on the amount of time you have available for learning, and how often you get to work using AWS, and whether you have taken any AWS exams before.

Especially with the last in mind - if this is not your first AWS exam, you would have gotten used to the way exam questions are phrased, and you would have covered some of the material if you have passed the AWS Solutions Architect Associate exam.

Resources available for free

I would like to start with and mainly focus on resources available, because in my opinion they are absolutely enough to prepare you well for the exam, especially if combined with practical usage of AWS tools and technologies in your everyday work.

*AWS Certified Developer - Associate 2020 from FreeCodeCamp and created by Andrew Brown - this is a very comprehensive 16 hours course, in my opinion better than some paid courses. Andrew Brown goes through and covers all the services in detail and at the end of each section there is a cheat sheet/summary available, that I found extremely helpful for the revision just before the exam.

*Cloud Academy webinars - this is a free webinar, hosted monthly by Cloud Academy instructors and it goes through each domain and exam questions. Some of the past webinars are available on Cloud Academy YouTube channel, so you can access them without having to sign up, but I definitely recommend attending live webinar, as you do get a chance to ask questions. This is a great resource to go through before you sit the exam, it highlights what are the things you should look out for, what do you need to focus on in your revision and what resources are useful to look at.

*Exam Certification Readiness Webinar from AWS - official and very thorough live 3=4 hour walk through all of the domains and exam questions. Worth mentioning that they are available for most certification exams and take place live in different time zones, so it makes it easy to find one that fits your schedule.

*AWS Ramp-Up Guide: Developer - this is by far the best resource, that was recommended during one of the AWS exam prep webinars. Whilst it is not specifically targeted at Developer Associate Exam, it contains links to labs, courses, whitepapers, and many more resources for developers, engineers and DevOps engineers.
*Official Practice Question Set with AWS skills builder . AWS SkillsBuilder is a new AWS learning center offering free digital courses and learning paths, and this is where you can now find Practice Question Set to get used to the way questions are phrased before you sit the exam.

*Developer Learning Plan with AWS Skill Builder- AWS designed this to help anyone, who wants to learn how to develop modern applications on AWS. It will help you learn your ways with serverless solutions, containers and DevOps on AWS. TThis Learning Plan can also help prepare you for the AWS Developer Associate certification eExam.

*AWS Certified Developer – Associate Exam Guide- this documents covers all you need to know about the preparation for your exam, discussing scope of the exam, content, exam domains, technology and tools that might be covered in the exam and services that are out of scope for the exam.

Paid courses and resources

When researching on how to best approach preparation for AWS Developer Associate exam I came across a vast amount of paid courses, however after reading plenty of reviews I have found these courses/resources are the most useful and comprehensive:

*Ultimate AWS Certified Developer Associate 2021 - this is a 32 hours course that will
thoroughly prepare you to sit the exam. in addition to the course itself you also receive slides that were used in the course, which I used to review the material before the exam day. It also comes with 1 full practice exam.

AWS Certified Developer Associate Practice Tests [2021]: 390 AWS Practice Exam Questions with Answers & detailed Explanations - this ebook not only offers you more than enough practice tests, but comes with very detailed explanations to both correct and incorrect answers and walking through each one of them in great details. If there is one resource you are willing to pay for to prepare for the exam - in my opinion that is the one!

What next?

The first thing you should do when starting your exam preparation is book your exam - you probably heard that from other people many times, but it does help with your learning plan, and if anything comes up, you can always reschedule your exam up to two times or cancel it all together for a full refund as long it's more than 24 hours before the exam start date.Book your exam here.

Additionally, if English is not your first language you can request an extra 30 minutes to be added to your exam.

Deploy static Next.js website with CDK and Amplify

Natalia Marek — Mon, 17 May 2021 15:38:54 +0000

In this post we will walk through deploying a Next.js starter website using AWS amplify CDK module.

Let's start with architectural overview of the application that we will be deploying.

We will be creating CodeCommit repository, Amplify app, API gateway and Lambda – all of this will be defined and deployed using AWS CDK.

CDK code will be converted to a CloudFormation template which will be deployed in the target region to create our resources.
We will be adding API gateway REST API that will enable communication between our Next.js app and Lambda.
We will also configure Amplify application to connect to newly created CodeCommit repository and this will trigger Amplify continuous deployment pipeline, in the end Amplify will generate a URL for our Next.js application, which will make our application accessible on the internet.

Before we start make sure that you have installed AWS CLI and Node.js.

Creating Next.js app

We will start by creating a default next.js app by running:
npx create-next-app next-cdk-app.

This will create a basic template for our Next.js application.
Before we start with CDK, we need to make few changes in our newly created Next.js app directory.

We will start by adding amplify.yml to the root of our directory to configure our build settings.

version: 1
frontend:
   phases:
     preBuild:
       commands:
         - npm ci
     build:
       commands:
         - npm run build
   artifacts:
     baseDirectory: out
     files:
       - '**/*'
   cache:
     paths:
       - node_modules/**/*

Next we need to update package.json file and modify build script by adding next export, which will enable fully static build of our Next.jsapplication. Our scripts should now look like this:

"scripts": {
  "dev": "next dev",
  "build": "next build && next export",
  "start": "next start"
}

Initialising CDK app

We will start by creating a new directory for the CDK infrastructure within our Next.js app:

mkdir cdk-infra
cd cdk-infra

In this example project we will be using Typescript, however you can also use Python, JavaScript, Java, C# or Go to define your infrastructure using CDK.

Before we initialise CDK app, lets make sure that we have the latest AWS CDK Toolkit installed by running npm install -g aws-cdk. You can find more information about it over here

Now lets initialise our CDK application by running:

cdk init app --language typescript

This will create several directories necessary for CDK project in typescript to run. Our project structure should look like this:

••cdk-infra-stack.ts•• file in ••lib•• directory is where we will be defining our stack and adding resources.

This is how your cdk-infra-stack.ts should look like:

import * as cdk from '@aws-cdk/core';

export class CdkInfraStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // The code that defines your stack goes here
  }
}

Next we will start a typescript compiler by writing npm run watch in the command line. This will monitor our project directory for any changes and it will compile any changes to our ts files to js.

Adding resources

In our project we will be creating Lambda function, API Gateway, CodeCommit repository and Amplify app. in order to do that, we need to install CDK modules for each one of them. We can do that by running:

npm install @aws-cdk/aws-codecommit
@aws-cdk/aws-lambda@aws-cdk/aws-apigateway
@aws-cdk/aws-amplify

First we will add CodeCommit repository, that will later on connect to our Amplify app which will set up our continuous deployment with Amplify. If you prefer to connect your project to Github you can skip this step, you will still be able to set up continuous deployment with Amplify.

import * as cdk from '@aws-cdk/core';
npm install @aws-cdk/aws-codecommit

export class CdkInfraStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);


const amplifyNextAppRepository = new codecommit.Repository(this, "AmplifyNextRepo", {
      repositoryName: "amplifyNextAppRepo",
      description: " Next.js app repository that will be used as a source repository for amplify-cdk app"
    }
    )

  }
}

Next we will add simple Lambda function and Api Gateway to establish a communication between the front end of our application and Lambda function. Lambda function code will be added in the Lambda directory in our cdk-infra directory

First lets add those two resources to our stack in ••cdk-infra-stack.ts•• file:

 const helloCDK = new lambda.Function(this, "HelloCDKHandler", {
      runtime: lambda.Runtime.NODEJS_12_X,
      code: lambda.Code.fromAsset("lambda"),
      handler: "hellocdk.handler",
    });

new apigw.LambdaRestApi(this, "Endpoint", {
      handler: helloCDK,
    });

Here we are defining a Lambda function, that will be loaded from 'lambda' directory, from hellocdk.js file, with a 'handler' function.

Now lets add our Lambda code. First we will create new lambda directory in CDK-Infra directory, next create new file called hellocdk.js and add this simple lambda that will be returning a 'Hello from CDK!" message.

exports.handler = async (event) => {
    const response = {
        headers: {'Access-Control-Allow-Origin': '*',
              'Access-Control-Allow-Credentials': true,
              "Access-Control-Allow-Headers": 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token'},
        statusCode: 200,
        body: JSON.stringify('Hello from CDK!')
    };
    return response;
  }

Next we will add Amplify app, and set the source code provider to be a CodeCommit repository that have created earlier:

const amplifyApp = new amplify.App(this, "amplifyNextApp", {
      sourceCodeProvider: new amplify.CodeCommitSourceCodeProvider({
        repository: amplifyNextAppRepo,
      }),
    });
    amplifyApp.addBranch("main");

In this code we are creating new Amplify application and connecting it to AmplifyAppNextRepository. We are also adding main branch - any changes pushed to that repository will trigger a new build and deployment in Amplify.
If you would like to set source code provider to be a GitHub repository you can do so by replacing CodeCommit source code with:

sourceCodeProvider: new amplify.GitHubSourceCodeProvider({
        owner: "[Repository-Owner]",
        repository: "[RepositoryName]",
        oauthToken: cdk.SecretValue.secretsManager("[SecretName]", {
          jsonField: "[SecretKey]",
        }),

You can read more about source code provider class and constructs over here

Deployment

Now that we have defined our infrastructure using CDK, lets create/synthesize CloudFormation template by running cdk synth - this will generate and print the CloudFormation template into our CLI.

Next we will deploy our application by running cdk deploy.
After running this, first we will see a warning message and a list of resources that will be created on our behalf. After agreeing for those changes to be made, the stack will be deployed and we should see the output with API gateway endpoint url in the command line along with stack ARN.

Let's copy the endpoint url and add it to our index.js in Next.js ••pages•• directory.

import Head from "next/head";
import { useState, useEffect } from "react";
import styles from "../styles/Home.module.css";

export default function Home() {
  const [message, setMessage] = useState("Something is not working!");

  useEffect(() => {
    const url = process.env.ENDPOINT_URL
    fetch(url)
      .then((response) => response.json())
      .then((data) => setMessage(JSON.stringify(data)));
  }, []);

  return (
    <div className={styles.container}>
      <Head>
        <title>Create Next App with CDK</title>
      </Head>

      <main className={styles.main}>
        <h1 className={styles.title}>
          Welcome to <a href="https://nextjs.org">Next.js </a>with{" "}
          <a href="https://docs.aws.amazon.com/cdk/latest/guide/home.html">CDK!</a>
        </h1>
        <h1>{message}</h1>
        <div className={styles.grid}></div>
      </main>


      </footer>
    </div>
  );
}

Here we have added useEffect hook that will fetch the data from the lambda function after our page is rendered. We will use this to test the functionality of the Lambda function and API gateway. The message should fist say "Something is not working", and after render, the message 'Hello from CDK!" should display. It should look like this:

Setting up continuous deployment

Last step will be initialising git repository in the root of our next-cdk-app, connecting it to CodeCommit repository that we have just created (or GitHub repository if you have created that instead) and pushing all the changes. This will trigger continuous build and deployment.

After pushing the changes to the repository, if we now go to AWS console, in Amplify we should now see our app built and deployed:

Here you can find how application should look like (with some handy links to CDK learning resources). You can also find source code in my GitHub repository

This blog post is based on the CDK Day talk I gave in April 2021, where I was presenting 2 ways of deploying React applications using CDK. You can find the talk over here.