Deploy a Task Manager API to AWS

Deploy a Dockerized Spring Boot API to Elastic Beanstalk with RDS PostgreSQL.

Introduction

30 Second Summary

Your API works perfectly on your laptop, but the moment you close your terminal, it disappears. Deploying to the cloud makes it available to anyone, anywhere, around the clock.

In this project, you will deploy your Dockerized Spring Boot Task Manager API to AWS using Elastic Beanstalk. You will wire it to a managed PostgreSQL database on Amazon RDS and prove that your data survives redeployments.

What You'll Build

Picture pasting a URL into your browser and getting back live JSON responses from your Task Manager API, running on AWS infrastructure you deployed with a single terminal command.

By the end of this project, you'll have:

  • A live API accessible from anywhere via a public URL. Paste the Elastic Beanstalk URL into your browser or a curl command and get back real JSON responses from your Task Manager endpoints.
  • A managed PostgreSQL database that keeps your data safe across redeployments. Create a task, redeploy your app, and the task is still there.
  • A single-command deployment workflow using the EB CLI. Run eb deploy and watch your code go live in minutes.
  • An optional Secret Mission to push your skills further.

Are there any prerequisites?

This project picks up where the prior Task Manager project left off. You need a working Spring Boot Task Manager API with a multi-stage Dockerfile, five CRUD endpoints, an activated AWS account with the AWS CLI configured, Docker installed, and Python with pip available.

Before We Start

You are about to take your Task Manager API from your local machine to a live URL on AWS. Before diving in, take a moment to commit to what you are building and why it matters for your cloud engineering skills.

Set Up the EB CLI

You already have the AWS CLI configured for general AWS operations. Elastic Beanstalk has its own purpose-built CLI that bundles your code, provisions environments, and streams logs in single commands.

Instead of writing dozens of low-level API calls to deploy your app, you can run commands like eb create and eb deploy to go from code to a live environment. In this step, you'll install the EB CLI on your machine.

In this step, get ready to:
  • Install the EB CLI using pip.
  • Verify the installation with a version check.
Install the EB CLI
  • Install the EB CLI by running this command:
pip install awsebcli --upgrade --user

You'll see pip downloading and installing several packages. This takes about a minute.

pip not recognized?

Make sure Python is installed and its scripts directory is in your system PATH. If you installed Python recently, close and reopen your terminal so the PATH changes take effect.

If pip still isn't recognized, try running pip3 instead. On some systems, pip is aliased as pip3.

Help me troubleshoot pip not being recognized in my terminal.

Verify the installation

Before you run the next command, what do you expect to see if the EB CLI installed correctly?

  • Confirm the EB CLI is available by running:
eb --version

✔️ I see a version number

You should see output like EB CLI 3.21.0 (Python 3.12). Your exact version numbers may differ, and that is perfectly fine. The EB CLI is installed and ready to go.

ⓧ Command not found

The EB CLI installed, but your terminal cannot find it because the install directory is not in your PATH. Try these fixes:

  • Close your terminal completely and reopen it. PATH updates from the install may not have taken effect yet.
  • On Windows: add %USERPROFILE%\AppData\Roaming\Python\Python312\Scripts to your PATH environment variable. The Python312 part should match your installed Python version (e.g. Python311 for Python 3.11).
  • On macOS/Linux: add ~/.local/bin to your PATH by running:
export PATH="$HOME/.local/bin:$PATH"

After updating your PATH, run eb --version again.

Help me fix eb command not found after installing the EB CLI with pip.

Your EB CLI is ready. Next up, you'll use it to deploy your Task Manager API to Elastic Beanstalk and get a live, public URL.

Deploy Your API to Elastic Beanstalk

Your EB CLI is installed and ready. Now it is time to put it to work and get your Task Manager API off your laptop and onto the internet.

Right now, your API only works on localhost. Nobody else can reach it. In this step, you will deploy it to Elastic Beanstalk, which provisions a real server, wires up a reverse proxy, and hands you a public URL.

In this step, get ready to:
  • Prepare a new docker-compose.yml for Elastic Beanstalk deployment.
  • Initialize and deploy your application using the EB CLI.
  • Test your live API and discover a critical data persistence gap.
Prepare the project for EB deployment

Elastic Beanstalk looks for a docker-compose.yml in your project root to decide how to run your container. You already have one from your local development setup, but that file includes a PostgreSQL service and local credentials that do not belong on AWS.

You need a separate, minimal docker-compose.yml that only defines your app service and the port mapping EB expects.

  • Preserve your existing local development file by renaming it. Run this command in your project root:
mv docker-compose.yml docker-compose.local.yml

Windows PowerShell users

If you are using PowerShell instead of Git Bash, run Rename-Item docker-compose.yml docker-compose.local.yml instead.

  • Confirm the rename worked by running:
ls

You should see docker-compose.local.yml in the file listing and no docker-compose.yml.

  • Create a new docker-compose.yml file in your project root with the following content:
services:
  app:
    build: .  # Uses your existing multi-stage Dockerfile
    ports:
      - "80:8080"  # Maps EB's nginx proxy (port 80) to Spring Boot (port 8080)

What does this file do?

This is a stripped-down Docker Compose file designed specifically for Elastic Beanstalk.

  • build: . tells EB to build a Docker image using the Dockerfile already in your project.
  • "80:8080" maps port 80 (where EB's nginx reverse proxy sends traffic) to port 8080 (where Spring Boot listens). Without this mapping, incoming requests would never reach your app.
  • Save docker-compose.yml.

File not saving in the right place?

Make sure the file is saved at the root of your project directory, right next to your Dockerfile and pom.xml. If the file ends up in a subfolder, EB will not find it.

Help me figure out where to save my docker-compose.yml for Elastic Beanstalk.

✔️ Awesome, I've got everything!

Great. Double check you have saved docker-compose.yml and you are ready to initialize EB.

ⓧ I'd like to double check the full code

Here is the complete docker-compose.yml you should have at this point:

services:
  app:
    build: .
    ports:
      - "80:8080"
Initialize the EB application

Before you can deploy, you need to tell the EB CLI which AWS region to use, what to name your application, and which platform to run it on. The eb init command walks you through this with an interactive wizard.

  • Start the initialization wizard by running:
eb init

What prompts will I see?

The eb init command asks a series of questions. Here is what to enter for each one:

  • Select a default region. Choose the region closest to you (e.g. us-east-1).
  • Enter Application Name. Type task-manager-api.
  • Select a platform. Choose Docker.
  • Select a platform branch. Choose 64bit Amazon Linux 2023 running Docker.
  • Do you wish to continue with CodeCommit? Enter n.
  • Do you want to set up SSH? Enter n.
  • Confirm the initialization created a config directory by running:
ls .elasticbeanstalk

You should see a config.yml file. This stores the application name, region, and platform you just selected.

Seeing 'aws-access-id' or credential errors?

The EB CLI reuses your AWS CLI credentials. If you see a credentials error, confirm your AWS CLI is configured by running aws sts get-caller-identity. If that fails, re-run aws configure with your access key and secret key.

Help me fix my EB CLI credential error.

Create the environment and deploy

With the application configured, you are ready to create a live environment on AWS. This single command provisions an EC2 instance, configures security groups, sets up an nginx reverse proxy, builds your Docker image, and starts your container.

  • Create a single-instance environment by running:
eb create task-manager-env --single

Why the --single flag?

The --single flag creates one EC2 instance without a load balancer. A load-balanced environment adds an Application Load Balancer that costs around $16/month and is not covered by free tier credits. Single-instance keeps your deployment free.

If prompted about a service role, allow Elastic Beanstalk to create one for you by accepting the default.

This takes about 5 to 10 minutes. You will see event logs streaming in your terminal as AWS provisions resources. Wait until you see a success message before continuing.

  • Once deployment completes, open your live API in the browser by running:
eb open

Your default browser opens to the EB environment URL. You may see a default page or an error page at the root path. That is expected because your API does not serve anything at /.

  • Copy the URL from your browser's address bar. You need it for the next commands.
  • Test your live API by running this curl command:
curl [[EB_URL="your EB environment URL, e.g. http://task-manager-env.us-east-1.elasticbeanstalk.com"]]/api/tasks

You should see an empty JSON array [] or a JSON list. Your API is live on the internet.

Seeing a connection error or 502?

Your application may still be starting up inside the container. Wait 1 to 2 minutes and try again. If the error persists, check the deployment logs by running eb logs and look for errors in the Spring Boot startup output.

Help me debug my Elastic Beanstalk deployment error.

  • Create a task on your live API by running:
curl -X POST [[EB_URL="your EB environment URL, e.g. http://task-manager-env.us-east-1.elasticbeanstalk.com"]]/api/tasks \
  -H "Content-Type: application/json" \
  -d '{"title": "My first cloud task", "description": "Deployed to AWS"}'

Windows PowerShell users

PowerShell does not support single quotes for JSON. Use double quotes and escape the inner quotes:

curl -X POST [[EB_URL="your EB environment URL"]]/api/tasks `
  -H "Content-Type: application/json" `
  -d '{\"title\": \"My first cloud task\", \"description\": \"Deployed to AWS\"}'
  • Confirm your task was saved by running the GET request again:
curl [[EB_URL="your EB environment URL, e.g. http://task-manager-env.us-east-1.elasticbeanstalk.com"]]/api/tasks

You should see your task in the JSON response, complete with an id field. Your API is working and serving data. Now for the real test.

Before you run the next command, ask yourself: what do you think will happen to that task if you redeploy the application?

  • Trigger a fresh redeployment by running:
eb deploy

Wait for the deployment to finish (3 to 5 minutes). Then retrieve your tasks one more time.

  • Check if your task survived the redeployment:
curl [[EB_URL="your EB environment URL, e.g. http://task-manager-env.us-east-1.elasticbeanstalk.com"]]/api/tasks

Your task is gone. The response is an empty array again.

Why did the data disappear?

Your Spring Boot app is using the default H2 in-memory database. H2 stores everything inside the running Java process. When eb deploy recreates the Docker container, H2 starts fresh with an empty database.

This is the core problem. For data to survive redeployments, restarts, and container crashes, you need a database that lives outside the container entirely.

Your API is live and working, but it forgets everything the moment you redeploy. Next up, you will fix this by adding a managed PostgreSQL database on Amazon RDS that persists data independently of your container.

Add an RDS PostgreSQL Database

Your API is live on AWS, but there is a problem. The data disappears every time you redeploy because H2 runs inside the container and dies with it.

Amazon RDS solves this by giving you a managed PostgreSQL database that lives independently of your application container. In this step, you will provision an RDS instance, wire it to your Spring Boot app with a dedicated Spring profile, and redeploy so your data survives across deployments.

In this step, get ready to:
  • Provision an RDS PostgreSQL instance through the Elastic Beanstalk console.
  • Create an AWS-specific Spring profile to read database credentials from environment variables.
  • Redeploy your application and verify the live API stores data in PostgreSQL.
Add a database to your EB environment

Elastic Beanstalk can provision and manage an Amazon RDS instance that is coupled to your environment. This means EB handles security group rules, injects connection credentials as environment variables, and deletes the database when you terminate the environment.

  • Open the Elastic Beanstalk console in your browser.
  • In the Regions list at the top, select the AWS region you chose when you ran eb init.
  • In the left navigation pane, click Environments.
  • Click the name task-manager-env to open your environment.
  • In the left navigation pane, click Configuration.
  • Find the Database configuration category and click Edit.

You now see the database configuration form. Fill it in with these values:

  • Set Engine to postgres.
  • Set Instance class to db.t3.micro (free tier eligible).
  • Keep Storage at 5 GB.
  • Enter a Username using only letters and numbers (e.g. taskadmin).
  • Enter a Password between 8 and 16 characters. Avoid /, \, and @ characters.
  • Leave Availability on its default (Low, meaning Single-AZ). This keeps costs within free tier.
  • Set Database deletion policy to Delete. This ensures the database is removed when you terminate the environment, preventing orphaned charges.
  • Click Apply at the bottom of the page.

This takes about 10 minutes to provision. Wait for the environment health to return to Ok before continuing.

What just happened?

Elastic Beanstalk provisioned an RDS PostgreSQL instance and coupled it to your environment. It automatically set five environment variables on your EC2 instance: RDS_HOSTNAME, RDS_PORT, RDS_DB_NAME, RDS_USERNAME, and RDS_PASSWORD.

The default database name is ebdb. Your Spring Boot app will read these variables to connect to the database instead of using the in-memory H2 database.

Why a coupled database instead of a standalone one?

A coupled RDS instance is managed entirely by Elastic Beanstalk. EB configures the security groups, injects the connection credentials, and handles the database lifecycle automatically. A standalone RDS instance requires you to configure all of that manually.

The tradeoff is that a coupled database is deleted when you terminate the environment. For a learning project, that is exactly what you want. It prevents orphaned resources from accruing charges.

Create the AWS Spring profile

Your Spring Boot app currently uses the default H2 database. You need a separate configuration profile that tells Spring to connect to the RDS PostgreSQL instance instead. Spring profiles let you swap configuration based on the environment your app is running in.

  • Create a new file at src/main/resources/application-aws.properties and paste the following configuration:
# Connect to the RDS PostgreSQL instance using EB environment variables
spring.datasource.url=jdbc:postgresql://${RDS_HOSTNAME}:${RDS_PORT}/${RDS_DB_NAME}
spring.datasource.username=${RDS_USERNAME}
spring.datasource.password=${RDS_PASSWORD}
spring.datasource.driver-class-name=org.postgresql.Driver

# Use PostgreSQL dialect and auto-create tables
spring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect
spring.jpa.hibernate.ddl-auto=update

What does this configuration do?

Each ${RDS_*} placeholder resolves at runtime to the environment variable that Elastic Beanstalk set on the EC2 host. Spring Boot reads these to build the JDBC connection URL.

The ddl-auto=update setting tells Hibernate to create or update tables automatically based on your entity classes. This means you do not need to run SQL migrations manually.

  • Save application-aws.properties.

The profile file is ready, but two things are still missing. Your Docker container does not know about these environment variables, and nothing tells Spring Boot to activate the aws profile. You will fix both in the docker-compose.yml next.

  • Open docker-compose.yml in your project root and find the current contents:
services:
  app:
    build: .
    ports:
      - "80:8080"
  • Replace the entire file with this updated version that adds the environment variables:
services:
  app:
    build: .
    ports:
      - "80:8080"
    environment:
      # Activate the aws Spring profile
      - SPRING_PROFILES_ACTIVE=aws
      # Pass RDS connection variables from the host into the container
      - RDS_HOSTNAME
      - RDS_PORT
      - RDS_DB_NAME
      - RDS_USERNAME
      - RDS_PASSWORD

Why list variables without values?

In Docker Compose, listing a variable name without an = sign (e.g. - RDS_HOSTNAME) passes through the value from the host machine into the container. Elastic Beanstalk sets these variables on the EC2 host, so Docker Compose picks them up automatically.

The SPRING_PROFILES_ACTIVE=aws variable has an explicit value because it does not come from the host. It tells Spring Boot to load application-aws.properties instead of the default configuration.

  • Save docker-compose.yml.

✔️ Awesome, I've got everything!

Great. Make sure you have saved both application-aws.properties and docker-compose.yml.

ⓧ I'd like to double check the full code

Here is the full application-aws.properties:

spring.datasource.url=jdbc:postgresql://${RDS_HOSTNAME}:${RDS_PORT}/${RDS_DB_NAME}
spring.datasource.username=${RDS_USERNAME}
spring.datasource.password=${RDS_PASSWORD}
spring.datasource.driver-class-name=org.postgresql.Driver
spring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect
spring.jpa.hibernate.ddl-auto=update

And here is the full docker-compose.yml:

services:
  app:
    build: .
    ports:
      - "80:8080"
    environment:
      - SPRING_PROFILES_ACTIVE=aws
      - RDS_HOSTNAME
      - RDS_PORT
      - RDS_DB_NAME
      - RDS_USERNAME
      - RDS_PASSWORD
Deploy the updated configuration and test persistence

Both files are ready. Time to push the changes to Elastic Beanstalk and verify that your API now stores data in RDS PostgreSQL.

  • Deploy the updated application by running:
eb deploy

This takes 3 to 5 minutes. EB rebuilds the Docker image, injects the RDS environment variables, and starts the container with the aws Spring profile active.

Seeing a deployment error?

If deployment fails, check the logs by running:

eb logs
  • Look for YAML syntax errors in docker-compose.yml. Make sure the environment key is indented at the same level as build and ports.
  • Verify that application-aws.properties is saved in src/main/resources/, not in the project root.

Help me debug my EB deployment error.

Once deployment completes, test that your API stores data in the RDS database.

  • Create a task on your live API by running:
curl -X POST [[EB_URL="your-eb-environment-url"]]/api/tasks -H "Content-Type: application/json" -d '{"title": "RDS persistence test", "description": "This task should survive a redeployment"}'

You should see a JSON response with the created task and an id field.

  • Retrieve all tasks to confirm it was saved:
curl [[EB_URL="your-eb-environment-url"]]/api/tasks

You should see the task you just created in the JSON response. Your data is now stored in RDS PostgreSQL, not in-memory H2.

Getting a 502 Bad Gateway or connection error?

  • The application may still be starting up. Wait 1 to 2 minutes and try again.
  • Check that your RDS instance finished provisioning. Return to the EB console, click Configuration, and confirm the Database section shows an endpoint.
  • Run eb logs and look for connection-refused errors pointing at the database hostname.

Help me debug my RDS connection issue.

Before you run this next prediction, think about what will happen. You created a task and it is sitting in the RDS database. If you redeploy now, do you think the task will still be there?

In the next step, you will answer that question by redeploying and running the exact scenario that failed in Step 2.

Verify Persistent Data on Your Live API

Your API is now backed by a managed RDS PostgreSQL database that lives outside the Docker container. In Step 2, you watched your data disappear after running eb deploy because the in-memory H2 database died with the container.

This step reruns the exact same scenario. You will create tasks, redeploy, and check whether the data survives. If RDS is wired correctly, your tasks stick around.

In this step, get ready to:
  • Run a full CRUD cycle to exercise all five endpoints on the live API.
  • Trigger a redeployment and confirm your data persists across it.
Create tasks and exercise all five endpoints

You will use curl to hit every endpoint on your live API. Each command returns a JSON response you can see in the terminal.

Curl on Windows

These commands use bash syntax with single-quoted JSON. If you are on Windows, run them in Git Bash or WSL. In PowerShell, use curl.exe instead of curl and replace single quotes with double quotes (escaping inner quotes with a backslash).

  • Create your first task by running this command:
curl -X POST [[EB_URL="your Elastic Beanstalk environment URL"]]/api/tasks -H "Content-Type: application/json" -d '{"title": "Buy groceries", "description": "Milk, eggs, bread"}'

What should I see?

The API returns a JSON object for the newly created task. Look for the id field in the response. Note this number down. You will need it for the update and delete operations coming up next.

  • Create a second task by running:
curl -X POST [[EB_URL="your Elastic Beanstalk environment URL"]]/api/tasks -H "Content-Type: application/json" -d '{"title": "Write report", "description": "Quarterly summary for the team"}'
  • Create a third task by running:
curl -X POST [[EB_URL="your Elastic Beanstalk environment URL"]]/api/tasks -H "Content-Type: application/json" -d '{"title": "Clean the kitchen", "description": "Dishes and countertops"}'
  • Note the id returned for each task.
  • Retrieve all tasks to confirm they were created by running:
curl [[EB_URL="your Elastic Beanstalk environment URL"]]/api/tasks

You should see a JSON array containing all three tasks, each with the id, title, and description you provided.

  • Update one of your tasks by running this PUT request. Replace the task ID with the actual id from your POST response:
curl -X PUT [[EB_URL="your Elastic Beanstalk environment URL"]]/api/tasks/[[UPDATE_TASK_ID="ID of the task to update"]] -H "Content-Type: application/json" -d '{"title": "Buy groceries", "description": "Milk, eggs, bread, and butter"}'
  • Delete a different task by running this DELETE request. Use the id of a different task than the one you just updated:
curl -X DELETE [[EB_URL="your Elastic Beanstalk environment URL"]]/api/tasks/[[DELETE_TASK_ID="ID of the task to delete"]]
  • Retrieve all tasks one more time to confirm the update and deletion took effect:
curl [[EB_URL="your Elastic Beanstalk environment URL"]]/api/tasks

You should see two remaining tasks. The one you updated has the new description, and the one you deleted is gone. Note the IDs of these two remaining tasks.

Getting a 404 or connection error?

  • Double-check that your URL includes /api/tasks at the end. A bare environment URL without the path returns the default nginx page.
  • If you see a 500 error, the database connection may not be configured. Run eb logs to check for Spring Boot startup errors mentioning the datasource.
  • If the connection times out, confirm your environment is healthy by running eb status and checking that the status shows as ready.
  • Still stuck? Help me troubleshoot my Elastic Beanstalk API returning errors when I send curl requests.
Redeploy and confirm your data persists

This is the moment of truth. In Step 2, redeploying wiped all your data because the H2 database lived inside the container. Now your data lives in Amazon RDS, completely separate from the container lifecycle.

  • Trigger a fresh redeployment by running:
eb deploy

Wait for the deployment to complete. You will see status messages ending with a line that says the environment update completed successfully. This takes 3-5 minutes.

Before you run the next command, think back to Step 2. Do you think your tasks will still be there this time, or will they be gone? Why?

  • Check whether your data survived the redeployment by running:
curl [[EB_URL="your Elastic Beanstalk environment URL"]]/api/tasks

Your tasks are still there, with the same IDs. The container was destroyed and recreated, but the data in RDS was untouched.

Why does this work now?

In Step 2, the H2 database ran inside the Docker container. Every redeployment tore down the old container and started a new one, taking the database with it.

RDS runs on a separate managed instance that Elastic Beanstalk provisions independently from your application container. Your container connects to it over the network using the RDS_HOSTNAME environment variable. Redeploying replaces the container, but the database instance keeps running with all your data intact.

Tasks are gone after redeploying?

  • Check that SPRING_PROFILES_ACTIVE=aws is set in your docker-compose.yml. Without it, Spring Boot falls back to the default H2 profile.
  • Confirm the RDS environment variables (RDS_HOSTNAME, RDS_PORT, RDS_DB_NAME, RDS_USERNAME, RDS_PASSWORD) are listed in the environment section of docker-compose.yml. Without explicit passthrough, the container cannot see the host's environment variables.
  • Run eb logs and search for connection errors in the Spring Boot output. A refused connection to PostgreSQL means the RDS security group or hostname is incorrect.
  • Need more help? Help me figure out why my data is not persisting after redeploying on Elastic Beanstalk with RDS.

Secret mission

Add a Health Check Endpoint

Your API is live, but Elastic Beanstalk has no way to know if your application is truly healthy. It only checks whether the EC2 instance itself is running. Add a dedicated health endpoint and configure EB to use it, so you get a reliable signal that your API code is actually functioning.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses AWS resources covered by Free Tier credits for new accounts, but charges apply once credits are exhausted or expire.

Cost warning

Your Elastic Beanstalk environment runs an EC2 instance and a coupled RDS PostgreSQL instance. These are covered by AWS Free Tier credits for accounts created after July 15, 2025 ($100 to $200 in credits, valid for up to 12 months).

Once your credits expire or are exhausted, leaving these resources running will incur charges. Deleting your resources after completing the project is recommended to avoid unexpected costs.

Resources you used:

  • 1 Elastic Beanstalk environment (task-manager-env) with an EC2 instance, a security group, and an Auto Scaling group.
  • 1 RDS PostgreSQL instance (db.t3.micro, 5 GB storage) coupled to the Elastic Beanstalk environment.
  • EB CLI installed via pip.

Keep everything running

No action needed. Choose this if you are still actively building or testing your API.

  • Your API stays live at the Elastic Beanstalk-provided URL.
  • Monitor your AWS billing dashboard to track credit usage.
  • The EB CLI remains installed on your machine for future deployments.

Pause - I'll come back to this later

Shut down running processes to free up compute charges while keeping your configuration available.

  • You cannot pause the Elastic Beanstalk environment itself. To fully pause costs, you would need to terminate the environment and recreate it later.
  • To stop the RDS instance independently, open the RDS console, select your database instance, and stop it.
  • Storage charges still apply while the RDS instance is stopped.
  • Your local project files and EB CLI remain intact so you can redeploy at any time.

Delete - I don't want to use this again

Remove all project resources and start fresh. This is recommended for this project.

  • Terminate the Elastic Beanstalk environment by running this command in your terminal:
eb terminate task-manager-env
  • When prompted, type the environment name to confirm the termination.
  • This terminates the EC2 instance and deletes the coupled RDS instance, since the deletion policy was set to Delete.
  • Open the RDS console and verify that no database instances remain.
  • Open the EC2 console and verify that no running instances remain.
  • Uninstall the EB CLI by running:
pip uninstall awsebcli
  • When prompted, confirm the uninstall by typing y.

That's a Wrap!

That's a Wrap!

Nice work! You just took a local Spring Boot API and shipped it to the cloud with a managed database that keeps your data safe across redeployments.

You've learned how to:

  • Deploy a Dockerized Spring Boot API to AWS Elastic Beanstalk using the EB CLI, giving your API a live public URL anyone can hit.
  • Provisioned a managed Amazon RDS PostgreSQL database and wired it to your application using environment variables and a Spring profile.
  • Proved data persistence by running a full CRUD cycle on your live API, redeploying, and confirming your tasks survived the redeployment.
  • Completed an optional Secret Mission to push your skills further.

Ready to quiz yourself?