Forem: Ankush

🔐 OWASP API Security — Why Every Developer Should Care (Java + AWS Context)

Ankush — Sat, 20 Sep 2025 06:31:25 +0000

🌍 Summary

APIs are everywhere — they power mobile apps, web services, and cloud-native systems.

But APIs are also one of the most common attack surfaces in modern software.

The OWASP API Security Top 10 (2021) is a developer-focused guide that explains the most critical API security risks.

👉 In this blog, we will:

✅ Go through each of the 10 risks (A01–A10)
🔍 Explain what they mean in developer terms
🛑 Show real-world scenarios and how attacks happen
🛠️ Outline solutions across multiple layers (code, infra, design)
💻 Provide Java (Spring Boot) and AWS examples
🧩 Highlight design patterns that help mitigate risks
📚 Share lessons from real incidents

🎯 The goal is simple:

Help developers design and build secure APIs without slowing down delivery.

📖 What is OWASP API Security Top 10 (2021)?

The Open Web Application Security Project (OWASP) is a global non-profit community that provides trusted guidance on secure software practices.

Its API Security Top 10 highlights the most critical categories of API risks developers must understand.

The 2021 edition is the latest, using codes A01–A10, and is widely adopted as a standard reference by:

👩‍💻 Developers
🏗️ Architects
🕵️ Auditors and Security Reviewers

🔗 Quick Navigation

A01 — Broken Access Control
A02 — Cryptographic Failures
A03 — Injection
A04 — Insecure Design
A05 — Security Misconfiguration
A06 — Vulnerable and Outdated Components
A07 — Identification and Authentication Failures
A08 — Software and Data Integrity Failures
A09 — Logging and Monitoring Failures
A10 — Server-Side Request Forgery (SSRF)

1. A01:2021 — Broken Access Control

🔎 Explanation

Broken Access Control means users can perform actions or access information they are not authorized for.

For example, a customer may change an account ID in the request and access another customer’s account.

This happens when applications do not consistently enforce restrictions.

Proper security requires:

Role-Based Access Control (RBAC): Broad permissions grouped by user roles
Attribute-Based Access Control (ABAC): Finer-grained checks based on user or resource attributes such as ownership or department

📝 Notes & Tools

Insecure Direct Object Reference (IDOR): Exploiting predictable identifiers in API requests
Role-Based Access Control (RBAC): Permissions mapped to roles such as Administrator, Customer, Auditor
Attribute-Based Access Control (ABAC): Permissions based on user or resource attributes (for example, owner ID, branch)
Amazon Cognito / Keycloak: Identity providers that issue JWTs with roles and attributes to enforce both role-based and attribute-based access control

💥 Example Scenario

A banking API endpoint:

/accounts/{id}

👉 Customers can change the id in the URL and view another person’s account because the application does not check ownership.

🛠️ Solutions

Application level: Enforce role-based access control (RBAC) and attribute-based access control (ABAC) using claims in JWTs
Infrastructure level: API Gateway validates tokens before backend services
Database level: Use row-level security (restrict records by ownerId or tenantId)

💻 Code (Spring Boot)

@GetMapping("/accounts/{id}")
@PreAuthorize("hasRole('ADMIN') || #id == authentication.name")
public Account get(@PathVariable String id){ 
    // Fetch account only if user is ADMIN or owner
    return accountService.findById(id);
}

@Bean
Converter<Jwt, ? extends AbstractAuthenticationToken> jwtAuth() {
    return jwt -> {
        var auths = new ArrayList<GrantedAuthority>();
        // Map roles from JWT claim
        jwt.getClaimAsStringList("roles").forEach(r -> 
            auths.add(new SimpleGrantedAuthority("ROLE_" + r)));
        // Map scopes from JWT claim
        jwt.getClaimAsStringList("scope").forEach(s -> 
            auths.add(new SimpleGrantedAuthority("SCOPE_" + s)));
        return new JwtAuthenticationToken(jwt, auths, jwt.getSubject());
    };
}

🎨 Design Pattern

Strategy Pattern — Choose between role-based access control (RBAC) or attribute-based access control (ABAC) strategies dynamically.

✅ Benefits

Prevents unauthorized data access
Ensures consistent enforcement across systems
Builds stronger trust with users

🚨 Real Incidents

Facebook (2019) — A bug in the photo API exposed unpublished and private photos of 6.8M users to third-party apps because permissions were overly broad and access control checks failed.
Instagram (2020) — An authorization flaw allowed attackers to retrieve private user account details by manipulating user IDs in API requests, bypassing ownership checks and exposing sensitive profile information.
Uber (2016) — Weak internal access controls gave employees broad visibility into rider trip data. Overly permissive systems lacked proper segregation of duties and failed to enforce strict authorization boundaries.
Snapchat (2014) — Public API flaw allowed enumeration of usernames and phone numbers, exposing 4.6M accounts. Missing rate limiting and insufficient authorization checks enabled attackers to harvest data at scale.
Microsoft Power Apps (2021) — Misconfigured default OData API settings exposed 38M records including personal and health data. Insecure defaults allowed anonymous public access to sensitive information across multiple organizations.

2. A02:2021 — Cryptographic Failures

🔎 Explanation

Cryptographic failures expose sensitive data when encryption is missing, weak, or misused.

Common mistakes include:

Transmitting data over Hypertext Transfer Protocol (HTTP) instead of Hypertext Transfer Protocol Secure (HTTPS)
Storing passwords in plain text
Failing to rotate keys

Attackers can intercept data, steal secrets, or modify information. Protecting data requires encryption in transit and at rest, and secure storage of secrets.

📝 Notes & Tools

Transport Layer Security (TLS): Encrypts data in transit
Mutual Transport Layer Security (mTLS): Authenticates both client and server
AWS Key Management Service (KMS): Manages encryption keys and rotation
AWS Secrets Manager / HashiCorp Vault: Secure storage and automatic rotation of secrets
BCrypt: Strong hashing algorithm for securely storing passwords

💥 Example Scenario

An API transmits login credentials over plain HTTP.

Attackers on the same Wi-Fi capture usernames and passwords because the connection is unencrypted.

🛠️ Solutions

Application level: Hash passwords with BCrypt; never log sensitive data
Infrastructure level: Use AWS Key Management Service (KMS) to encrypt storage; store secrets in Secrets Manager
Network level: Enforce TLS 1.2+ and configure HTTP Strict Transport Security (HSTS)

💻 Code (Spring Boot + AWS)

resource "aws_kms_key" "cust" { 
  enable_key_rotation = true 
}

resource "aws_db_instance" "rds" {
  storage_encrypted = true
  kms_key_id = aws_kms_key.cust.arn
}

http.requiresChannel(c -> c.anyRequest().requiresSecure())
    .headers(h -> h.httpStrictTransportSecurity(
      hs -> hs.maxAgeInSeconds(31536000)));

PasswordEncoder enc = new BCryptPasswordEncoder();
user.setPassword(enc.encode(rawPassword));

🎨 Design Pattern

Facade Pattern — Centralize all encryption and hashing logic behind a single interface to ensure consistency across services.

✅ Benefits

Prevents sensitive data leaks
Protects communications from eavesdropping
Reduces risk of stolen credentials

🚨 Real Incidents

Equifax (2017) — Poor encryption and unpatched systems led to a breach of 147 million records, including social security numbers and financial data.
Yahoo (2013–2014) — Weak cryptography and stolen credentials resulted in breaches of over 3 billion accounts, exposing email content and personal information.
Heartbleed (2014) — A flaw in OpenSSL’s implementation of TLS allowed attackers to read server memory and extract private keys.
Marriott (2018) — Inadequate cryptographic practices contributed to exposure of 500 million customer records, including passport and payment details.
Panera Bread (2018) — An API exposed customer data such as emails and loyalty card numbers because sensitive endpoints were not secured with HTTPS.

3. A03:2021 — Injection

🔎 Explanation

Injection occurs when untrusted input is executed as part of a command or query.

Classic examples include:

SQL Injection
NoSQL Injection
Command Injection

Attackers manipulate input to change the behavior of queries, retrieve unauthorized data, or run arbitrary commands.

📝 Notes & Tools

Parameterized Queries: Prevent inputs from being executed as code
Input Validation: Enforce data rules with annotations such as @Valid
Web Application Firewall (WAF): Detect and block common injection payloads

💥 Example Scenario

A login form concatenates user input into a SQL query.

Input like ' OR '1'='1 bypasses authentication and returns all users.

🛠️ Solutions

Application level: Use parameterized queries and validate all inputs
Infrastructure level: Deploy a Web Application Firewall (WAF) to detect injection attempts
Database level: Run queries with least-privilege accounts to limit damage

💻 Code (Spring Boot + Java)

@Query("select u from User u where u.username=:u and u.tenantId=:t")
User find(@Param("u") String username, @Param("t") String tenantId);

record LoanReq(@NotBlank String custId, @Positive BigDecimal amt) {}

@PostMapping("/loan")
void loan(@Valid @RequestBody LoanReq req) {
    // Business logic for loan creation
}

🎨 Design Pattern

Builder Pattern — Construct queries safely step by step, ensuring that user inputs are always treated as data, not executable code.

✅ Benefits

Eliminates one of the most common attack methods
Ensures inputs are consistently treated as data, not code
Protects both SQL and NoSQL databases

🚨 Real Incidents

Sony Pictures (2011) — SQL Injection attack leaked millions of records, including customer details and sensitive company data.
TalkTalk (2015) — SQL Injection exposed customer personal data and financial information of over 150,000 users.
Heartland Payment Systems (2008) — SQL Injection exploited payment systems, resulting in the theft of 130 million credit card numbers.
British Airways (2018) — Poor input handling on the airline’s website led to customer data exposure, including names, travel information, and payment details.
Tesla (2018) — A NoSQL Injection vulnerability exposed internal cloud resources, giving attackers the ability to run malicious code and mine cryptocurrency.

4. A04:2021 — Insecure Design

🔎 Explanation

Insecure Design refers to weaknesses in the application’s workflow or architecture.

Even if the code is written securely, poor design can allow attacks such as brute force login attempts, replay attacks, or missing rate limiting.

A secure design must consider abuse cases and build protections into workflows before implementation.

📝 Notes & Tools

Brute Force Protection: Limit repeated login attempts to stop password guessing
Replay Protection: Use nonces or timestamps to prevent request reuse
Multi-Factor Authentication (MFA): Add a second factor for sensitive operations
API Gateway Rate Limits: Control excessive traffic to protect backends

💥 Example Scenario

A login API allows unlimited login attempts.

Attackers run automated bots to try millions of passwords until one succeeds, gaining unauthorized access.

🛠️ Solutions

Application level: Add Multi-Factor Authentication (MFA) and enforce unique nonces for sensitive actions
Infrastructure level: Use API Gateway or Web Application Firewall (WAF) to rate limit requests
Network level: Block Internet Protocol (IP) addresses with repeated failed attempts

💻 Code (Infrastructure Example)

rate_based_statement { 
  limit = 100 
  aggregate_key_type = "IP" 
}

🎨 Design Pattern

Template Method Pattern — Define secure steps in workflows (for example: Login → Multi-Factor Authentication → Success).

✅ Benefits

Reduces risks by embedding security into workflows
Protects against brute force and replay attacks
Ensures sensitive operations always follow strict, secure steps

🚨 Real Incidents

LinkedIn (2012) — Weak password protection and missing brute force defenses allowed attackers to steal 6.5 million password hashes from the social networking platform.
Apple iCloud (2014) — Lack of strong rate limiting enabled brute force attacks on celebrity accounts, leading to leaks of private photos.
PlayStation Network (2011) — Insecure design and inadequate protection layers caused one of the largest breaches in gaming history, exposing personal and payment data of 77 million accounts.
OWASP Juice Shop (Ongoing) — Training application intentionally demonstrates insecure design flaws, such as weak workflows and missing rate limiting, to highlight how insecure patterns are exploited in practice.
Coinbase (2019) — A design flaw allowed replay of valid requests, potentially enabling attackers to repeat transactions or actions without detection.

5. A05:2021 — Security Misconfiguration

🔎 Explanation

Security misconfigurations are among the most common issues.

Examples include:

Open ports
Unnecessary services
Default credentials
Overly broad Cross-Origin Resource Sharing (CORS) settings
Missing security headers

They leave APIs vulnerable even when the code itself is correct.

📝 Notes & Tools

Cross-Origin Resource Sharing (CORS) Policy: Restrict requests to trusted domains
Security Headers: Add HTTP Strict Transport Security (HSTS), X-Content-Type-Options, and others
AWS Config: Continuously checks resources against security rules

💥 Example Scenario

An API allows Cross-Origin Resource Sharing (CORS) requests from any origin (*).

Malicious websites can send API requests on behalf of logged-in users, stealing their data or performing unauthorized actions.

🛠️ Solutions

Application level: Configure strict Cross-Origin Resource Sharing (CORS) policies and enable standard security headers
Infrastructure level: Use AWS Config to enforce security baselines across cloud resources
Network level: Restrict open ports using Security Groups or firewall rules

💻 Code (Spring Boot Example)

@Bean 
WebMvcConfigurer cors() {
  return r -> r.addMapping("/**")
    .allowedOrigins("https://bank.com")
    .allowedMethods("GET", "POST")
    .allowCredentials(true);
}

🎨 Design Pattern

Facade Pattern — Centralize configuration in one layer to ensure consistency across all services.

✅ Benefits

Prevents attackers from exploiting weak defaults
Ensures secure settings across environments
Reduces risk of accidental data exposure

🚨 Real Incidents

Capital One (2019) — Misconfigured AWS firewall exposed 100 million records, including credit card applications and customer data.
Microsoft Power Apps (2021) — Misconfigured API settings exposed 38 million records across multiple organizations, including government and healthcare.
NASA (2018) — Misconfigurations in cloud and internal systems exposed sensitive project data and credentials.
Verizon (2017) — An open Amazon Simple Storage Service (S3) bucket exposed millions of customer records, including call center logs.
Accenture (2017) — Misconfigured cloud storage exposed internal company data and access credentials publicly on the internet.

6. A06:2021 — Vulnerable and Outdated Components

🔎 Explanation

This risk arises when applications rely on outdated libraries, frameworks, or runtime environments with known security flaws.

Attackers exploit these weaknesses even if your own code is secure.

Common issues include:

Ignoring dependency updates
Using unpatched container images
Failing to track the software supply chain

📝 Notes & Tools

Software Composition Analysis (SCA): Tools such as OWASP Dependency-Check or Snyk scan dependencies for known vulnerabilities
Software Bill of Materials (SBOM): A complete list of all components; CycloneDX is a standard format
Immutable Images: Rebuild container images regularly to include the latest security patches

💥 Example Scenario

A banking application continues using the vulnerable Log4j library.

Attackers exploit the Log4Shell flaw to execute remote code on the server.

🛠️ Solutions

Application level: Use Software Composition Analysis (SCA) tools in Continuous Integration / Continuous Delivery (CI/CD) pipelines to detect vulnerable libraries
Infrastructure level: Build golden Amazon Machine Images (AMIs) or Docker images and update them regularly
Process level: Generate Software Bill of Materials (SBOMs) and break builds when critical Common Vulnerabilities and Exposures (CVEs) are found

💻 Code (Maven Example)

mvn org.owasp:dependency-check-maven:check

🎨 Design Pattern

Observer Pattern — React automatically when vulnerabilities are discovered (for example, pipeline alerts trigger build failures).

✅ Benefits

Prevents exploitation of known flaws
Keeps applications aligned with security patches
Improves visibility into dependencies

🚨 Real Incidents

Log4Shell (2021) — Vulnerability in Log4j impacted millions of systems worldwide, enabling remote code execution.
Equifax (2017) — Failure to patch an Apache Struts vulnerability led to a massive breach, exposing personal data of 147 million people.
Heartbleed (2014) — A flaw in outdated OpenSSL versions allowed attackers to read server memory and steal private keys.
Drupalgeddon (2014) — A critical vulnerability in the Drupal content management system was widely exploited when websites failed to update promptly.
WordPress Plugins (Multiple Years) — Numerous unpatched plugins have caused widespread compromises of websites running WordPress.

7. A07:2021 — Identification and Authentication Failures

🔎 Explanation

Weak authentication or mismanaged sessions allow attackers to impersonate users.

Examples include:

Long-lived tokens
Missing validation of token claims
Weak passwords
Using Basic Authentication between services

Secure APIs require strong identity validation, careful token management, and secure service-to-service authentication.

📝 Notes & Tools

OpenID Connect (OIDC): An identity layer built on top of OAuth 2.0
JSON Web Tokens (JWT): Secure tokens carrying claims, which must always be validated
Mutual Transport Layer Security (mTLS): Ensures services authenticate and trust each other
Amazon Cognito / Keycloak: Platforms that manage users, tokens, and Multi-Factor Authentication (MFA)

💥 Example Scenario

An API issues JWTs valid for 24 hours without validating audience or expiry.

If stolen, attackers can impersonate users for a full day.

🛠️ Solutions

Application level: Validate token issuer, audience, and expiry. Use short-lived tokens
Infrastructure level: Use mTLS between services
Gateway level: Enforce token validation at the API Gateway

💻 Code (Java Example)

JwtDecoder dec = NimbusJwtDecoder.withJwkSetUri(jwksUri).build();
dec.setJwtValidator(new JwtClaimValidator<>("aud", aud -> aud.contains("api://svc")));

🎨 Design Pattern

Decorator Pattern — Enrich tokens with roles or scopes during validation to strengthen identity checks.

✅ Benefits

Stops impersonation from stolen tokens
Ensures only valid, trusted sessions are used
Strengthens identity handling across systems

🚨 Real Incidents

Uber (2016) — Authentication failures exposed driver and rider data, highlighting weak internal token management.
Microsoft (2021) — Token misconfigurations in Azure Active Directory enabled exploits that allowed attackers to escalate privileges.
Facebook (2018) — A flaw in access tokens exposed 50 million accounts, allowing attackers to take over user sessions.
Instagram (2019) — API flaws exposed session tokens, leaving user accounts vulnerable to hijacking.
Google+ (2018) — Bugs in token handling exposed user data, ultimately contributing to the shutdown of the platform.

8. A08:2021 — Software and Data Integrity Failures

🔎 Explanation

This risk arises when code, dependencies, or deployment pipelines are tampered with.

If APIs rely on unsigned packages, compromised container images, or unverified updates, attackers can inject malicious code into production systems.

📝 Notes & Tools

Cosign: Tool to sign and verify container images
Open Policy Agent (OPA): Prevents unsigned or unverified resources from being deployed
Argo Continuous Delivery (Argo CD) with GitOps: Ensures deployments come from trusted Git repositories with full traceability

💥 Example Scenario

An attacker pushes a malicious Docker image to a registry.

The Kubernetes cluster deploys it without verification, running untrusted code in production.

🛠️ Solutions

Pipeline level: Sign all container images with Cosign
Cluster level: Use Open Policy Agent (OPA) Gatekeeper to block unsigned resources
Process level: Adopt GitOps practices to ensure deployments come only from trusted repositories

💻 Code

cosign sign $ECR/app:1.2.3

🎨 Design Pattern

Proxy Pattern — Admission controllers act as intermediaries that intercept and block unverified deployments before they reach production.

✅ Benefits

Prevents supply chain attacks
Ensures only trusted code runs in production
Adds accountability and traceability to deployments

🚨 Real Incidents

SolarWinds (2020) — A supply chain compromise inserted malicious code into software updates, impacting thousands of organizations worldwide.
Codecov (2021) — A malicious update to the Codecov Bash uploader exfiltrated credentials and tokens from customer environments for months before detection.
Event-Stream (2018) — A popular Node Package Manager (NPM) library was backdoored, harvesting cryptocurrency wallet data from applications using the dependency.
Asus Live Update (2019) — Attackers distributed signed malware through Asus’s official Live Update utility, compromising hundreds of thousands of devices.
PHP Git Server (2021) — A backdoored commit was briefly added to the official PHP source code repository, potentially impacting all downstream deployments.

9. A09:2021 — Logging and Monitoring Failures

🔎 Explanation

Without proper logging and monitoring, attacks go undetected.

APIs may fail to log failed login attempts, unusual traffic, or sensitive actions.

Without alerts, security teams cannot respond quickly, allowing attackers to persist undetected for months.

📝 Notes & Tools

Security Information and Event Management (SIEM): Centralize and analyze logs (examples: Splunk, ELK stack, AWS Security Hub)
AWS GuardDuty: Detects anomalies in logs and network traffic
Trace Identifiers (Trace IDs): Correlate logs across distributed services

💥 Example Scenario

A login API does not log failed attempts.

Attackers use brute force techniques for months without detection.

🛠️ Solutions

Application level: Log authentication attempts and assign trace identifiers (Trace IDs)
Infrastructure level: Centralize logs in Amazon CloudWatch or an ELK stack
Monitoring level: Use AWS GuardDuty or similar tools for anomaly alerts

💻 Code (Java Example)

@EventListener
void onFail(AbstractAuthenticationFailureEvent e){
 log.warn("auth_fail user={} reason={}", 
   e.getAuthentication().getName(), e.getException().getMessage());
}

🎨 Design Pattern

Observer Pattern — Events trigger logging and alerting actions automatically.

✅ Benefits

Detects attacks early
Enables forensic investigation
Improves operational visibility

🚨 Real Incidents

Equifax (2017) — Delayed detection of exploitation worsened the impact of an already critical data breach.
Target (2013) — Security alerts were ignored, allowing the breach to persist for weeks.
British Airways (2018) — Poor logging delayed discovery of data theft, exposing hundreds of thousands of customer records.
SolarWinds (2020) — Weak monitoring allowed the supply chain attack to persist undetected for months.
Capital One (2019) — Logs eventually helped investigators trace the AWS metadata breach.

10. A10:2021 — Server-Side Request Forgery (SSRF)

🔎 Explanation

Server-Side Request Forgery (SSRF) occurs when an API makes requests to URLs supplied by users without validation.

Attackers can trick servers into connecting to internal services or cloud metadata endpoints, stealing credentials or bypassing firewalls.

📝 Notes & Tools

AWS Instance Metadata Service v2 (IMDSv2): Requires a session token, mitigating metadata theft
Kubernetes NetworkPolicy: Blocks outbound requests to sensitive IP ranges
Outbound Proxy: Centralizes and filters all outgoing requests

💥 Example Scenario

An API fetches files from a user-supplied URL.

An attacker requests http://169.254.169.254/ and retrieves AWS credentials from the metadata service.

🛠️ Solutions

Application level: Validate URLs and allowlist only trusted partner domains
Network level: Block internal ranges using Kubernetes NetworkPolicy
Cloud level: Enforce AWS IMDSv2 for all instances

💻 Code (Java Example)

String host = InetAddress.getByName(new URL(req.url()).getHost()).getHostAddress();
if (host.startsWith("169.254.") || !ALLOWED.contains(host)) 
    throw new ResponseStatusException(HttpStatus.BAD_REQUEST);

🎨 Design Pattern

Chain of Responsibility Pattern — Multiple validation steps are applied to outbound requests, ensuring only safe traffic is allowed.

✅ Benefits

Stops attackers from abusing internal networks
Protects cloud metadata services
Ensures outbound calls are controlled and secure

🚨 Real Incidents

Capital One (2019) — Server-Side Request Forgery (SSRF) exploited AWS metadata endpoint, exposing 100 million records.
Tesla Cloud (2018) — Server-Side Request Forgery (SSRF) allowed attackers to access cloud systems and run unauthorized cryptocurrency mining.
Alibaba Cloud (2020) — Server-Side Request Forgery (SSRF) flaws exposed internal cloud services of customers.
Microsoft Azure (2017) — Server-Side Request Forgery (SSRF) in services exposed sensitive credentials from metadata endpoints.
Jira (2019) — Server-Side Request Forgery (SSRF) vulnerability in Atlassian Jira exposed internal customer data.

🏁 Final Takeaways

Treat security as a design constraint, not an afterthought.
Apply layered defenses: code, infrastructure, and process.
Bake controls into pipelines and platforms so they are hard to bypass.
Keep documentation and runbooks close to the code so teams can respond fast.

Bottom line: Your APIs are the front door to your business — build them to be safe by default and resilient when things go wrong.

Use this guide as a checklist for design reviews, threat modeling, and production readiness of your APIs.

A Complete Guide To Deploy GitHub Project on Amazon EC2 Using GitHub Actions and AWS CodeDeploy

Ankush — Fri, 28 May 2021 20:08:59 +0000

Auto Deploy in Amazon EC2 on Git Commit. A complete guide to configure CodeDeploy and GitHub CI/CD Action.

Prerequisite

Create a GitHub account.
Create AWS Account.

Create IAM Role for EC2 and CodeDeploy
Create EC2 Instance
Launch EC2 Instance
Install CodeDeploy Agent on EC2 Instance
CodeDeploy Service Configuration
GitHub Project
GitHub Action

Note

Select a particular region of AWS Services which CodeDeploy Agent and GitHub will use.

Create IAM Role For EC2 and CodeDeploy

Create a role for EC2 Instance -

Select AWS Service as trusted entity and EC2 as usecase, click on Next:Permissions.
On the Permissions page, select AmazonEC2RoleforAWSCodeDeploy Policy and Click on Next:Tags
Ignore the tags and click Next:Review.
Provide the role name as EC2_Role on the review page.
Open the EC2_Role and go to Trust Relationships, then Edit Trust Relationship and paste below policy -

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "ec2.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }

Now we will create a role for CodeDeploy.

Select AWS Service as trusted entity and EC2 as usecase, click on Next:Permissions.
On the Permissions page, select the below policy and Click on Next:Tags. AmazonEC2FullAccess, AWSCodeDeployFullAccess, AdministratorAccess, AWSCodeDeployRole
Tags can be ignored, click on Next:Review.
Provide the role name as CodeDeploy_Role on the review page.

Once CodeDeploy Role created, Open the CodeDeploy_Role and go to Trust Relationships then Edit Trust Relationship and use below policy -

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "codedeploy.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Create EC2 Instance

To create an EC2 instance, Go to EC2 Dashboard on AWS Management Console and click on Launch Instance.

On the AIM page, You can select any Volume Type based on your requirement. This article will choose Free Tier Amazon Linux 2 AMI (HVM), SSD Volume Type and 64-bit (x86) Volume and click on select.

Select t2.micro in Choose Instance Typ page and proceed to Configure Instance page.

To establish the connection between EC2 instance and codeDeploy, Select EC2_Role, which we created before.

On the Tag page, add a tag called development. The tag will require creating a codeDeploy service.

In Configure Security Group page Add Rule called All traffic, select source called anywhere.

This rule will enable you to connect the Instance from anywhere.
NOTE - This is not advisable in the Production environment.

Select the review page, then Launch the Instance. Wait for a few minutes to start the EC2 Instance.

If you want to access the Instance (ssh) from your local system, create a new Key Pair and download the key.

Launch EC2 Instance

Once Instance is up and running, Right-click on instance id and click on connect.

On the next page, Take a note of the Public IP Address and connect using the default User name.

Install CodeDeploy Agent on EC2 Instance

TO Deploy the git repo by using CodeDeploy Service, codeDeploy-agent must install in the EC2 instance.

Use the below commands to install codedeploy-agent.

sudo yum update

sudo yum install -y ruby

sudo yum install wget

wget https://bucket-name.s3.region-identifier.amazonaws.com/latest/install

bucket-name is the Amazon S3 bucket containing the CodeDeploy Resource Kit files for your region. region-identifier is the identifier for your region.
list of bucket names and region identifiers

For example - wget https://aws-codedeploy-ap-south-1.s3.ap-south-1.amazonaws.com/latest/install

chmod +x ./install

sudo ./install auto

sudo service codedeploy-agent start

CodeDeploy Service Configuration

AWS CodeDeploy Service will automate the GitHub application deployment to EC2.

Create an Application name called Git_Application with compute platform EC2/On-premises.

GitHub Action will use the application name.

Once Application Created, Create a Deployment Group and name development_gropup. Get the Role ARN from CodeDeploy_Role, which we created before and put in the service role.

GitHub Action will use the deployment Group name.

Choose In-place Deployment type. Select Amazon Ec2 Instances environment configuration and Tag key development to create AWS EC2 instance.

Select a schedule manager to install the CodeDeploy agent. Set OneAtATime deployment setting and Create Deployment Group without a load balancer.

Once Deployment Group created, test the deployment by creating a Deployment with any name.

Select Revision Type My application is stored in GitHub, and select Connect to GitHub by providing the GitHub token.

Once connected to GitHub, Provide the repository name and last Commit ID. Select Overwrite the content and Create Deployment.

Wait for a few minutes ⏳ .

If Deployment status is unsuccessful, verify the deployment logs from ec2 instance /var/log/aws/codedeploy-agent/codedeploy-agent.log.

Recreate the deployment and fix this first. Once it's successful, you can access the application from a web browser or postman.

curl --location --request GET 'http://{{[ec2_public_ip]}}:8080/student'

Get ec2_public_ip from EC2 Instance

GitHub Project

Fork the spring-boot demo repository.

This project is a spring-boot project which uses MongoDB.
For project deployment, we will use docker-compose, which includes MongoDB.

The appspec.yml file used by codeDeploy to manage the deployment.

The setup.sh will install docker and docker-compose.

The run.sh is used for docker-compose up.

version: 0.0
os: linux
files:
  - source: .
    destination: /home/ec2-user/spring-boot-mongo/
hooks:
  AfterInstall:
   - location: setup.sh
     timeout: 300
     runas: root
  ApplicationStart:
   - location: run.sh
     timeout: 300
     runas: root

GitHub Action

First, create an IAM user with full AWSCodeDeployFullAccess policy and generate an access key and secret access for the user to configure GitHub Action.

Before configuring Action, set the environment in the GitHub repository.

GitHub repository changes will trigger GitHub Action, which has two CI/CD job -

The continuous-integration job will compile the code and run the JUnit Test cases.
The continuous-deployment job will call AWS CodeDeploy Service -

application - Git_Application
deployment-group - development_gropup

Paste below YAML in action configuration and commit.

name: CI/CD Pipeline
on:
  push:
    branches: [ main ]

jobs:
  continuous-integration:
    runs-on: ubuntu-latest
    steps:
      # Step 1
      - uses: actions/checkout@v2
      # Step 2
      - name: Set up JDK 11
        uses: actions/setup-java@v2
        with:
          java-version: '11'
          distribution: 'adopt'
      # Step 3
      - name: Build Application and Run unit Test
        run: mvn -B test --file student-service/pom.xml

  continuous-deployment:
    runs-on: ubuntu-latest
    needs: [continuous-integration]
    if: github.ref == 'refs/heads/main'
    steps:
     # Step 1
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
     # Step 2
      - name: Create CodeDeploy Deployment
        id: deploy
        run: |
          aws deploy create-deployment \
            --application-name Git_Application \
            --deployment-group-name development_gropup \
            --deployment-config-name CodeDeployDefault.OneAtATime \
            --github-location repository=${{ github.repository }},commitId=${{ github.sha }}

Now make a change to your repository. Your changes should automatically deploy to your EC2 server.

Access the application from a web browser or postman.

curl --location --request GET 'http://{{[ec2_public_ip]}}:8080/student'

Get ec2_public_ip from EC2 Instance